From ntd at users.sourceforge.net Thu Jun 15 07:01:12 2006 From: ntd at users.sourceforge.net (Fontana Nicola) Date: Thu, 15 Jun 2006 11:01:12 +0000 Subject: GObject extension propose (GContainer) Message-ID: <200606151101.12868.ntd@users.sourceforge.net> Hi all, I'm a GObject based libraries (for UI purpose and not) user and I often need a generic container to derive my own types. In my opinion, I think this generic container must be included inside the GObject library ... it could be used by a lot of derived libraries providing a common approach. I published my solution - that is, what I am currently using - on sourceforge. http://sourceforge.net/projects/gcontainer/ Is it a good idea? Is something planned in this direction? Am I totally wrong? I need feedbacks ... Nicola From mclasen at redhat.com Thu Jun 15 09:56:26 2006 From: mclasen at redhat.com (Matthias Clasen) Date: Thu, 15 Jun 2006 09:56:26 -0400 Subject: GTK+ 2.10, the endgame Message-ID: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> I want to have GTK+ 2.10 ready at or immediately after GUADEC. I did not declare 2.9.3 api frozen in the release announcement, because we were still holding the door open for Kris' work on the new tooltips api. But he has run into some difficulties with the implementation which will take some time to overcome, so we have decided to punt this feature and try to get it into 2.12 early. Therefore, I want to consider 2.9.3 api frozen, and take a look at what still needs to happen before 2.10. Here are some things I personally would like get worked on (not sure how much time I can free to look into these myself): - I think the async filechooser conversion has caused some regressions, I noticed that .hidden support seems broken and autocompletion also behaved badly for me recently. - There is a number of FIXMEs and unimplemented bits in the print code. - The print backends need a careful look wrt to memory leaks and error reporting. Are there other important bugs or regressions that need attention before 2.10 ? Another thing I have slacked off about is organizing a GTK+ team meeting at GUADEC. So, who of the GTK+ team is there and at what times ? Should we try to find a free hour during the core days, or does everybody stay for the after hours ? If so, it may be easier to do a team meeting on Thursday... Matthias From timj at imendio.com Thu Jun 15 10:52:17 2006 From: timj at imendio.com (Tim Janik) Date: Thu, 15 Jun 2006 16:52:17 +0200 (CEST) Subject: GObject extension propose (GContainer) In-Reply-To: <200606151101.12868.ntd@users.sourceforge.net> References: <200606151101.12868.ntd@users.sourceforge.net> Message-ID: On Thu, 15 Jun 2006, Fontana Nicola wrote: > Hi all, > > I'm a GObject based libraries (for UI purpose and not) user and I often need > a generic container to derive my own types. In my opinion, I think this > generic container must be included inside the GObject library ... it could > be used by a lot of derived libraries providing a common approach. > > I published my solution - that is, what I am currently using - on > sourceforge. > > http://sourceforge.net/projects/gcontainer/ > > Is it a good idea? Is something planned in this direction? Am I totally > wrong? > > I need feedbacks ... hi. your gcontainer-1.0.0 looks like an interesting approach to me, but i'm not sure it's generally good to put that into stock libgobject. the main reason is that container needs are probably pretty variable out there (i've come across at least 4 different gobject container implementations in free software projects i'm woorking on) and that both, making too little assumptions in the child/container interface isn't going to be very helpful, albeit making too many has the same problem. i guess we could add a link to your project from the libgobject docs (it should probably have a Contrib section), for people possibly looking for a GObject container implementation. that way, gcontainer-1.0.0 gets a chance of being reused and maybe extended to something generally usefull for GObject applications out there. > Nicola --- ciaoTJ From timj at imendio.com Thu Jun 15 10:31:44 2006 From: timj at imendio.com (Tim Janik) Date: Thu, 15 Jun 2006 16:31:44 +0200 (CEST) Subject: GTK+ meeting at GUADEC (Re: GTK+ 2.10, the endgame) In-Reply-To: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> References: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> Message-ID: On Thu, 15 Jun 2006, Matthias Clasen wrote: > I want to have GTK+ 2.10 ready at or immediately after GUADEC. > Another thing I have slacked off about is organizing a GTK+ > team meeting at GUADEC. So, who of the GTK+ team is there > and at what times ? Should we try to find a free hour during > the core days, or does everybody stay for the after hours ? > If so, it may be easier to do a team meeting on Thursday... i think i volounteered to take on arrangement of that to some extend. at least, we intended to have a meeting on GTK+ linking issues, and could probably merge that with the GTK+ team meeting during guadec. the plan for that was to send out en email next friday/saturday (i.e right at the guadec start) to figure/suggest dates suitable for everyone to attend. > Matthias --- ciaoTJ From hfiguiere at teaser.fr Thu Jun 15 11:51:29 2006 From: hfiguiere at teaser.fr (Hubert Figuiere) Date: Thu, 15 Jun 2006 11:51:29 -0400 Subject: GTK+ 2.10, the endgame In-Reply-To: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> References: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> Message-ID: <44918201.6010605@teaser.fr> Matthias Clasen wrote: > I want to have GTK+ 2.10 ready at or immediately after GUADEC. Can somebody summarize the Mac port status? Hub From tristan.van.berkom at gmail.com Thu Jun 15 13:00:54 2006 From: tristan.van.berkom at gmail.com (Tristan Van Berkom) Date: Thu, 15 Jun 2006 13:00:54 -0400 Subject: GObject extension propose (GContainer) In-Reply-To: References: <200606151101.12868.ntd@users.sourceforge.net> Message-ID: <44919246.8060301@gnome.org> Tim Janik wrote: >On Thu, 15 Jun 2006, Fontana Nicola wrote: > > > >>Hi all, >> >>I'm a GObject based libraries (for UI purpose and not) user and I often need >>a generic container to derive my own types. In my opinion, I think this >>generic container must be included inside the GObject library ... it could >>be used by a lot of derived libraries providing a common approach. >> >>I published my solution - that is, what I am currently using - on >>sourceforge. >> >>http://sourceforge.net/projects/gcontainer/ >> >>Is it a good idea? Is something planned in this direction? Am I totally >>wrong? >> >>I need feedbacks ... >> >> As a side note... I've been working on container --> child relationships and honing them down inside the glade builder... objects may for example have object delagates that are "owned" and in turn may "own" other delagates... this is all functional with libglade facilities and the future gtk builder also (from the design as of yet...)... this concept of "types of container relationships" is also usefull for GtkMenuShell --> GtkMenu for example (not just any GtkWidget can be added to a menushell). All of that just to say... I cannot count the times I've thought to myself that GtkContainer should really just be GContainerIface, and implemented by whatever interested objects that want to parent other objects... I think that what we need is not really "yet another container api", but a container api that is a unified front for generic handling of the GTK object hierarchy at runtime. Cheers, -Tristan From federico at ximian.com Thu Jun 15 12:50:29 2006 From: federico at ximian.com (Federico Mena Quintero) Date: Thu, 15 Jun 2006 11:50:29 -0500 Subject: GTK+ 2.10, the endgame In-Reply-To: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> References: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> Message-ID: <1150390229.17566.191.camel@cacharro.xalalinux.org> On Thu, 2006-06-15 at 09:56 -0400, Matthias Clasen wrote: > Therefore, I want to consider 2.9.3 api frozen, and take a > look at what still needs to happen before 2.10. Here are some > things I personally would like get worked on (not sure > how much time I can free to look into these myself): > > - I think the async filechooser conversion has caused some > regressions, I noticed that .hidden support seems broken > and autocompletion also behaved badly for me recently. Yes, it's quite broken at the moment. I don't think we can do any more productive debugging (fixing something breaks something else) until we have a good set of automated tests for the basic behaviors. > - There is a number of FIXMEs and unimplemented bits in > the print code. > > - The print backends need a careful look wrt to memory leaks > and error reporting. I'm rather worried of declaring the printing API as stable and just unleashing it to the world. Is any software *really* using it? Does it contemplate things like - sites with thousands of printers - sites which want to lock-down certain printers - color management for apps that need it > Another thing I have slacked off about is organizing a GTK+ > team meeting at GUADEC. So, who of the GTK+ team is there > and at what times ? Should we try to find a free hour during > the core days, or does everybody stay for the after hours ? > If so, it may be easier to do a team meeting on Thursday... I'll be there since Sunday morning. Thursday is the Advisory Board meeting, so I'm afraid I won't have that day free for the GTK+ meeeting. Federico From mclasen at redhat.com Thu Jun 15 13:15:37 2006 From: mclasen at redhat.com (Matthias Clasen) Date: Thu, 15 Jun 2006 13:15:37 -0400 Subject: GTK+ 2.10, the endgame In-Reply-To: <1150390229.17566.191.camel@cacharro.xalalinux.org> References: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> <1150390229.17566.191.camel@cacharro.xalalinux.org> Message-ID: <1150391737.3187.33.camel@dhcp83-98.boston.redhat.com> On Thu, 2006-06-15 at 11:50 -0500, Federico Mena Quintero wrote: > On Thu, 2006-06-15 at 09:56 -0400, Matthias Clasen wrote: > > > Therefore, I want to consider 2.9.3 api frozen, and take a > > look at what still needs to happen before 2.10. Here are some > > things I personally would like get worked on (not sure > > how much time I can free to look into these myself): > > > > - I think the async filechooser conversion has caused some > > regressions, I noticed that .hidden support seems broken > > and autocompletion also behaved badly for me recently. > > Yes, it's quite broken at the moment. I don't think we can do any more > productive debugging (fixing something breaks something else) until we > have a good set of automated tests for the basic behaviors. Quite unfortunate. We spent too much time working on finetuning the filechooser behaviour to leave it broken now... > > - There is a number of FIXMEs and unimplemented bits in > > the print code. > > > > - The print backends need a careful look wrt to memory leaks > > and error reporting. > > I'm rather worried of declaring the printing API as stable and just > unleashing it to the world. Is any software *really* using it? Does it > contemplate things like Typical chicken and egg problem that won't be solved by keeping it unreleased for another year. There is no way to get any software _really_ using it without releasing it first. We got quite a bit of feedback from people looking at porting real apps to it (e.g gedit, OOo and epiphany), so it is not as if we release it straight from the whiteboard. > - sites with thousands of printers > > - sites which want to lock-down certain printers > > - color management for apps that need it No doubt that we may have to add new api in 2.12 to accomodate things like this, but all of these are special cases. From muntyan at tamu.edu Thu Jun 15 15:04:58 2006 From: muntyan at tamu.edu (Yevgen Muntyan) Date: Thu, 15 Jun 2006 14:04:58 -0500 Subject: Printing and blocking ui Message-ID: <4491AF5A.2050702@tamu.edu> Hi there, I print a text document from GtkTextView here. There is a problem with pagination: pagination is potentially slow, so some sort of progress dialog should be shown during it. From the other hand, the text buffer must not be modified during pagination. How to solve it? Should I show my own modal dialog and make sure user doesn't modify the buffer, or GtkPrintOperation can take care of it? Actually, it would be good to ensure printing blocks the text widget too, since in this case it wouldn't be necessary to calculate and store all the pango layouts in begin-print. Maybe just show a modal dialog between begin-print and end-print. Thanks, Yevgen From richard at imendio.com Thu Jun 15 15:06:56 2006 From: richard at imendio.com (Richard Hult) Date: Thu, 15 Jun 2006 21:06:56 +0200 Subject: GTK+ 2.10, the endgame In-Reply-To: <44918201.6010605@teaser.fr> References: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> <44918201.6010605@teaser.fr> Message-ID: <4491AFD0.5000408@imendio.com> Hubert Figuiere skrev: > Matthias Clasen wrote: >> I want to have GTK+ 2.10 ready at or immediately after GUADEC. > > Can somebody summarize the Mac port status? The basic functionality is implemented and what's next in the pipeline is bug fixing, and after that looking into tighter integration with the platform in various areas. /Richard From muntyan at tamu.edu Thu Jun 15 15:11:42 2006 From: muntyan at tamu.edu (Yevgen Muntyan) Date: Thu, 15 Jun 2006 14:11:42 -0500 Subject: GTK+ 2.10, the endgame In-Reply-To: <1150390229.17566.191.camel@cacharro.xalalinux.org> References: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> <1150390229.17566.191.camel@cacharro.xalalinux.org> Message-ID: <4491B0EE.3040900@tamu.edu> Federico Mena Quintero wrote: >On Thu, 2006-06-15 at 09:56 -0400, Matthias Clasen wrote: > > >>- The print backends need a careful look wrt to memory leaks >> and error reporting. >> >> > >I'm rather worried of declaring the printing API as stable and just >unleashing it to the world. Is any software *really* using it? > > Yes, there is software which is going to use gtk printing as soon as gtk-2.10 is released. And there will be much more when gtk has printing. Just think for a moment about gtk-but-not-gnome applications (win32 comes to mind too). > - sites with thousands of printers > > - sites which want to lock-down certain printers > > - color management for apps that need it > > If gtk can print to a single user's printer, it's already worth releasing. Again, there are applications which do not have printing, because they can't use gnomeprint, and developers don't feel like implement their own printing while gtk is going to get it. IMHO, etc., you know. Best regards, Yevgen From jasonspiro4+news at gmail.com Thu Jun 15 15:15:34 2006 From: jasonspiro4+news at gmail.com (Jason Spiro) Date: Thu, 15 Jun 2006 19:15:34 +0000 (UTC) Subject: Imagine: what if points in Bugzilla had a significant effect? Message-ID: Imagine: what if points did something in Bugzilla, like, the more points you have, the more votes you get? I think this would encourage people to file more bug reports, both good bug reports and not-so-good ones. Would that be a net gain or a net loss for GTK+? Regards, Jason Spiro -- Jason Spiro: computer consulting with a smile. Specializing in Linux: Red Hat AS / ES, Debian, and others. Serving homes and companies globally via remote access tools. Fair rates. Just email jasonspiro4 at gmail.com or call Skype ID jasonspiro. From murrayc at murrayc.com Fri Jun 16 04:52:10 2006 From: murrayc at murrayc.com (Murray Cumming) Date: Fri, 16 Jun 2006 10:52:10 +0200 Subject: GTK+ 2.10, the endgame In-Reply-To: <1150391737.3187.33.camel@dhcp83-98.boston.redhat.com> References: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> <1150390229.17566.191.camel@cacharro.xalalinux.org> <1150391737.3187.33.camel@dhcp83-98.boston.redhat.com> Message-ID: <1150447930.5806.4.camel@localhost.localdomain> I'm also concerned about the recent files stuff. Do we now have UIManager integration of that? -- Murray Cumming murrayc at murrayc.com www.murrayc.com www.openismus.com From murrayc at murrayc.com Thu Jun 15 17:20:27 2006 From: murrayc at murrayc.com (Murray Cumming) Date: Thu, 15 Jun 2006 23:20:27 +0200 Subject: GTK+ 2.10, the endgame In-Reply-To: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> References: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> Message-ID: <1150406427.30234.1.camel@localhost.localdomain> On Thu, 2006-06-15 at 09:56 -0400, Matthias Clasen wrote: > I want to have GTK+ 2.10 ready at or immediately after GUADEC. [snip] I'd rather it was after rather than before. That gives us just a little more time to get everything wrapped quickly for gtkmm, which might show some small problems that need fixing. Maybe I haven't been paying attention, but I'm surprised (again) by the freeze announcement. -- Murray Cumming murrayc at murrayc.com www.murrayc.com www.openismus.com From mgiannakidis at gmail.com Thu Jun 15 11:27:45 2006 From: mgiannakidis at gmail.com (Michalis Giannakidis) Date: Thu, 15 Jun 2006 18:27:45 +0300 Subject: gslice allocator: general impresions. Message-ID: <200606151827.45477.mgiannakidis@gmail.com> Dear Glib team, I have recently used the glib-glice allocator in a very malloc intensive application, and I would like to share a few observations I made, with you. The typical size I send to g_slice_alloc is 20 and 76 bytes (32 bit build). The total memory consumed by my application has decreased - which is great! However it `seems' to me, that this decrease in size is larger for the 64bit build compared to the 32bit build. (I have modified gslice to align a chunk to its own size so that I don't have unused memory between chunks eg: request 20 and get 24...) In my application now I use both g_slice_alloc and malloc.Testing the new allocator in linux I came accross the following: After using g_slice_alloc to alloc a great amount of data (eg 1500mb), each of them being 20 or 76 bytes in size, subsequent calls to malloc(8*1024) or similar sizes take much longer (the allocation does _not_ got to the swap). Also if I chage the min_page_size from 128 to 4096, then the subsequent calls to malloc(8*1024) or similar sizes take even longer. It takes for ever in the 64 bit build! Moreover, even with min_page_size set to 128, the calls to malloc take for ever on a Linux 2.4.20 glibc-2.2.4(glibc up to 2.2.5 has a broken posix_memalign so I fallback to memalign). In all of the cases above, malloc responds much faster when the gslice allocator is turned off. I know I should be providing sample code and test programms here to back up my observations. I also understand that I should provide execution times instead of just stating that the calls to malloc take for ever. I would like to ask you, if there are any known issues in mixing gslice and malloc calls in malloc intensive applications. Any suggested readings would be most welcome. Regards Michalis -- Michalis Giannakidis From timj at imendio.com Fri Jun 16 07:28:35 2006 From: timj at imendio.com (Tim Janik) Date: Fri, 16 Jun 2006 13:28:35 +0200 (CEST) Subject: GObject extension propose (GContainer) In-Reply-To: <1150456522.5305.12.camel@localhost.localdomain> References: <200606151101.12868.ntd@users.sourceforge.net> <44919246.8060301@gnome.org> <1150456522.5305.12.camel@localhost.localdomain> Message-ID: On Fri, 16 Jun 2006, Gustavo J. A. M. Carneiro wrote: > Qui, 2006-06-15 ?s 13:00 -0400, Tristan Van Berkom escreveu: >> All of that just to say... I cannot count the times I've thought to >> myself that >> GtkContainer should really just be GContainerIface, and implemented by >> whatever interested objects that want to parent other objects... > > That's interesting, but I wonder what is the runtime penalty of > interface lookup compared to normal class structure lookup? Is it > really OK to use an interface for this, or is it better just to add a > new virtual methods to the GObject class? the lookup penalties are negligible. type node/class lookups and is_a checks are O(1); interface class lookups and conforms_to checks are O(ld(N)), where N is the number of interfaces a type node conforms to. > Gustavo J. A. M. Carneiro --- ciaoTJ From gjc at inescporto.pt Fri Jun 16 07:15:21 2006 From: gjc at inescporto.pt (Gustavo J. A. M. Carneiro) Date: Fri, 16 Jun 2006 12:15:21 +0100 Subject: GObject extension propose (GContainer) In-Reply-To: <44919246.8060301@gnome.org> References: <200606151101.12868.ntd@users.sourceforge.net> <44919246.8060301@gnome.org> Message-ID: <1150456522.5305.12.camel@localhost.localdomain> Qui, 2006-06-15 ?s 13:00 -0400, Tristan Van Berkom escreveu: > Tim Janik wrote: > > >On Thu, 15 Jun 2006, Fontana Nicola wrote: > > > > > > > >>Hi all, > >> > >>I'm a GObject based libraries (for UI purpose and not) user and I often need > >>a generic container to derive my own types. In my opinion, I think this > >>generic container must be included inside the GObject library ... it could > >>be used by a lot of derived libraries providing a common approach. > >> > >>I published my solution - that is, what I am currently using - on > >>sourceforge. > >> > >>http://sourceforge.net/projects/gcontainer/ > >> > >>Is it a good idea? Is something planned in this direction? Am I totally > >>wrong? > >> > >>I need feedbacks ... > >> > >> > As a side note... I've been working on container --> child relationships and > honing them down inside the glade builder... objects may for example have > object delagates that are "owned" and in turn may "own" other delagates... > this is all functional with libglade facilities and the future gtk > builder also > (from the design as of yet...)... this concept of "types of container > relationships" > is also usefull for GtkMenuShell --> GtkMenu for example (not just any > GtkWidget > can be added to a menushell). > > All of that just to say... I cannot count the times I've thought to > myself that > GtkContainer should really just be GContainerIface, and implemented by > whatever interested objects that want to parent other objects... That's interesting, but I wonder what is the runtime penalty of interface lookup compared to normal class structure lookup? Is it really OK to use an interface for this, or is it better just to add a new virtual methods to the GObject class? > I think > that what we need is not really "yet another container api", but a container > api that is a unified front for generic handling of the GTK object > hierarchy at runtime. Actually, for the python language bindings we could use a generic GObject container interface. See http://bugzilla.gnome.org/show_bug.cgi?id=303266 Regards. -- Gustavo J. A. M. Carneiro The universe is always one step beyond logic From alan at clueserver.org Fri Jun 16 12:53:44 2006 From: alan at clueserver.org (alan) Date: Fri, 16 Jun 2006 09:53:44 -0700 (PDT) Subject: Imagine: what if points in Bugzilla had a significant effect? In-Reply-To: References: Message-ID: On Thu, 15 Jun 2006, Jason Spiro wrote: > Imagine: what if points did something in Bugzilla, like, the more points > you have, the more votes you get? Slashzilla? -- "Waiter! This lambchop tastes like an old sock!" - Sheri Lewis From ntd at users.sourceforge.net Fri Jun 16 16:44:11 2006 From: ntd at users.sourceforge.net (Fontana Nicola) Date: Fri, 16 Jun 2006 20:44:11 +0000 Subject: GObject extension propose (GContainer) In-Reply-To: References: <200606151101.12868.ntd@users.sourceforge.net> Message-ID: <200606162044.11716.ntd@users.sourceforge.net> > On Thu, 15 Jun 2006, Fontana Nicola wrote: > > Hi all, > > > > I'm a GObject based libraries (for UI purpose and not) user and I often > > need a generic container to derive my own types. In my opinion, I think > > this generic container must be included inside the GObject library ... it > > could be used by a lot of derived libraries providing a common approach. > > > > I published my solution - that is, what I am currently using - on > > sourceforge. > > > > http://sourceforge.net/projects/gcontainer/ > > > > Is it a good idea? Is something planned in this direction? Am I totally > > wrong? > > > > I need feedbacks ... > > hi. your gcontainer-1.0.0 looks like an interesting approach to me, but > i'm not sure it's generally good to put that into stock libgobject. > the main reason is that container needs are probably pretty variable > out there (i've come across at least 4 different gobject container > implementations in free software projects i'm woorking on) and that > both, making too little assumptions in the child/container interface > isn't going to be very helpful, albeit making too many has the > same problem. Some time ago I've started a communication library based on libgobject and I feeled the need of two things: a base object with floating reference and a container. After some time, I started an experimental cairo canvas and I had the same needs. In both cases, no gtk dependency was requested. Briefly, I'm not talking about a container that cover all needs and tastes but instead about "moving the GtkContainer logic and complexity" from gtk to gobject, something similar to what was done for GtkObject and its floating reference. I wrote gcontainer with this in mind (the GContainerable interface is "compatible" with GtkContainer and GChildable with GtkWidget). Anyway, my solution presents some serious problems: I'm misusing the interface to hide as much technical details as possible to the implementing objects. I know it is a huge task but consider this as an idea or a looooong term project: I don't think to be the only one with these needs. > > i guess we could add a link to your project from the libgobject docs > (it should probably have a Contrib section), for people possibly looking > for a GObject container implementation. that way, gcontainer-1.0.0 gets > a chance of being reused and maybe extended to something generally > usefull for GObject applications out there. > > > Nicola > > --- > ciaoTJ Of course I'll be glad to have a link in the gobject documentation. Thank you for your availability. Nicola From tristan.van.berkom at gmail.com Fri Jun 16 14:36:44 2006 From: tristan.van.berkom at gmail.com (Tristan Van Berkom) Date: Fri, 16 Jun 2006 14:36:44 -0400 Subject: GObject extension propose (GContainer) In-Reply-To: <200606162044.11716.ntd@users.sourceforge.net> References: <200606151101.12868.ntd@users.sourceforge.net> <200606162044.11716.ntd@users.sourceforge.net> Message-ID: <4492FA3C.5060106@gmail.com> Fontana Nicola wrote: [...] >I wrote gcontainer with this in mind (the GContainerable interface is >"compatible" with GtkContainer and GChildable with GtkWidget). Anyway, my >solution presents some serious problems: I'm misusing the interface to hide >as much technical details as possible to the implementing objects. > >I know it is a huge task but consider this as an idea or a looooong term >project: I don't think to be the only one with these needs. > > I think you may be overcomplicating things, if for example; the GContainerable or GContainerIface were implemented by GtkContainer; then nothing in GtkContainer derivatives would really have to change (unless the api was drasticly different... but I doubt that). Then this could be extended to other object sets and other needs without having to rewrite large pieces of code. Cheers, -Tristan From behdad at cs.toronto.edu Fri Jun 16 14:57:22 2006 From: behdad at cs.toronto.edu (Behdad Esfahbod) Date: Fri, 16 Jun 2006 14:57:22 -0400 Subject: Imagine: what if points in Bugzilla had a significant effect? In-Reply-To: References: Message-ID: <1150484242.15469.17.camel@home> On Thu, 2006-06-15 at 15:15 -0400, Jason Spiro wrote: > Imagine: what if points did something in Bugzilla, like, the more points > you have, the more votes you get? > > I think this would encourage people to file more bug reports, both good > bug reports and not-so-good ones. Would that be a net gain or a net loss > for GTK+? It has evolved to be like that already. The more points one has, the more he (or she, in the near future) respects bugs/comments from high-point others. Or at least that's been my experience. behdad > Regards, > Jason Spiro > > -- > Jason Spiro: computer consulting with a smile. > Specializing in Linux: Red Hat AS / ES, Debian, and others. > Serving homes and companies globally via remote access tools. Fair rates. > Just email jasonspiro4 at gmail.com or call Skype ID jasonspiro. > > _______________________________________________ > gtk-devel-list mailing list > gtk-devel-list at gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-devel-list -- behdad http://behdad.org/ "Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill" -- Dan Bern, "New American Language" From grakic at devbase.net Fri Jun 16 16:11:33 2006 From: grakic at devbase.net (Goran Rakic) Date: Fri, 16 Jun 2006 22:11:33 +0200 Subject: Imagine: what if points in Bugzilla had a significant effect? In-Reply-To: References: Message-ID: <1150488693.2273.3.camel@localhost> Lary Osterman has a nice writing on this topic titled "Measuring testers by test metrics doesn't." ? ?et, 15. 06 2006. ? 19:15 +0000, Jason Spiro ????: > Imagine: what if points did something in Bugzilla, like, the more points > you have, the more votes you get? > > I think this would encourage people to file more bug reports, both good > bug reports and not-so-good ones. Would that be a net gain or a net loss > for GTK+? > > Regards, > Jason Spiro From ame1 at extratech.com Fri Jun 16 17:01:26 2006 From: ame1 at extratech.com (Alan M. Evans) Date: Fri, 16 Jun 2006 14:01:26 -0700 Subject: GObject extension propose (GContainer) In-Reply-To: References: <200606151101.12868.ntd@users.sourceforge.net> <44919246.8060301@gnome.org> <1150456522.5305.12.camel@localhost.localdomain> Message-ID: <1150491686.19405.355.camel@zosma.extratech.com> On Fri, 2006-06-16 at 04:28, Tim Janik wrote: > On Fri, 16 Jun 2006, Gustavo J. A. M. Carneiro wrote: > > > Qui, 2006-06-15 ?s 13:00 -0400, Tristan Van Berkom escreveu: > > >> All of that just to say... I cannot count the times I've thought to > >> myself that > >> GtkContainer should really just be GContainerIface, and implemented by > >> whatever interested objects that want to parent other objects... > > > > That's interesting, but I wonder what is the runtime penalty of > > interface lookup compared to normal class structure lookup? Is it > > really OK to use an interface for this, or is it better just to add a > > new virtual methods to the GObject class? > > the lookup penalties are negligible. > type node/class lookups and is_a checks are O(1); > interface class lookups and conforms_to checks are O(ld(N)), where > N is the number of interfaces a type node conforms to. Your assertion that the penalties are negligable is not really supported by your response, unless the constant is also known for both orders. From ebassi at gmail.com Fri Jun 16 20:05:50 2006 From: ebassi at gmail.com (Emmanuele Bassi) Date: Sat, 17 Jun 2006 01:05:50 +0100 Subject: GTK+ 2.10, the endgame In-Reply-To: <1150447930.5806.4.camel@localhost.localdomain> References: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> <1150390229.17566.191.camel@cacharro.xalalinux.org> <1150391737.3187.33.camel@dhcp83-98.boston.redhat.com> <1150447930.5806.4.camel@localhost.localdomain> Message-ID: <1150502750.2668.12.camel@localhost> Hi Murray, On Fri, 2006-06-16 at 10:52 +0200, Murray Cumming wrote: > I'm also concerned about the recent files stuff. Do we now have > UIManager integration of that? No, and I am to blame because I had less time to spend on fixing this issue. Mostly, I've been stuck on how to implement an action for both the menu and toolbars using the same tag. In the meantime, a nice and clean way to integrate the GtkRecentChooserMenu inside a GtkUIManager is to subclass GtkAction into a custom action that automatically adds a recent chooser menu to the menu item it creates, and use a placeholder in the UI definition (most applications using EggRecentViewUIManager already have that placeholder present). A working example is available here: http://www.gnome.org/~ebassi/test-uimanager.c The action code itself is one hundred lines long and can easily be hidden inside an helper file; it's approximately how GtkRecentAction would be implemented, anyway. I hereby give permission to do whatever you want to do with it. I understand that it's sub-optimal, and hopefully this should really go away once there's an action inside GTK. Ciao, Emmanuele. -- Emmanuele Bassi, E: ebassi at gmail.com W: http://www.emmanuelebassi.net B: http://log.emmanuelebassi.net From behdad at behdad.org Mon Jun 12 17:44:37 2006 From: behdad at behdad.org (Behdad Esfahbod) Date: Mon, 12 Jun 2006 17:44:37 -0400 Subject: Pango-1.13.2 released [unstable] Message-ID: <1150148678.10765.8.camel@home> Pango-1.13.2 is now available for download at: ftp://ftp.gtk.org/pub/gtk/v2.11/ or http://download.gnome.org/sources/pango/1.13/ 28a6ea9d43c4cd398e7352032f775401 pango-1.13.2.tar.bz2 17d78473c05fece044c6a3b44519b61f pango-1.13.2.tar.gz This is a development release leading up to Pango-1.14.0, which will be released just in time for GNOME-2.16. Notes: * This is unstable development release. While it has had fairly extensive testing, there are likely bugs remaining to be found. This release should not be used in production. * Installing this version will overwrite your existing copy of Pango-1.12. If you have problems, you'll need to reinstall Pango-1.12.x * Bugs should be reported to http://bugzilla.gnome.org. About Pango =========== Pango is a library for layout and rendering of text, with an emphasis on internationalization. Pango can be used anywhere that text layout is needed, though most of the work on Pango so far has been done in the context of the GTK+ widget toolkit. Pango forms the core of text and font handling for GTK+-2.x. Pango is designed to be modular; the core Pango layout engine can be used with different font backends. There are three basic backends, with multiple options for rendering with each. - Client side fonts using the FreeType and fontconfig libraries. Rendering can be with with Cairo or Xft libraries, or directly to an in-memory buffer with no additional libraries. - Native fonts on Microsoft Windows. (Optionally using Uniscribe for complex-text handling). Rendering can be done via Cairo or directly using the native Win32 API. - Native fonts on MacOS X, rendering via Cairo. The integration of Pango with Cairo (http://cairographics.org) provides a complete solution with high quality text handling and graphics rendering. Dynamically loaded modules then handle text layout for particular combinations of script and font backend. Pango ships with a wide selection of modules, including modules for Hebrew, Arabic, Hangul, Thai, and a number of Indic scripts. Virtually all of the world's major scripts are supported. As well as the low level layout rendering routines, Pango includes PangoLayout, a high level driver for laying out entire blocks of text, and routines to assist in editing internationalized text. More information about Pango is available from http://www.pango.org/. Pango 1.13.2 depends on version 2.10.0 or newer of the GLib library and version 1.1.2 or newer of the cairo library (if the cairo backend is desired); more information about GLib and cairo can be found at http://www.gtk.org/ and http://cairographics.org/ respectively. Overview of changes between 1.13.1 and 1.13.2 ============================================== * Improved hexbox drawing, and font metrics calculations. * Synthesize italic variants on win32 [Hans Breuer] * New public API: - pango_cairo_show_error_underline - pango_cairo_error_underline_path - pango_font_describe_with_absolute_size * Misc fixes. * Bugs fixed in this release: Bug 326960 ? hex box drawing for win32 and atsui backends of cairo Bug 343717 ? License information in unclear. Bug 343355 ? Add pango_cairo_show_error_underline & pango_cairo_error_underline_path Bug 343966 ? pango Cygwin build fixes Patch from Cygwin Ports maintainer. Bug 343796 ? Italic Chinese character can't be show correctly in Win32. Bug 314114 ? max_x_advance not appropriate for approximate_(char|digit)_width Bug 341138 ? Using TTC font, Gtk2 programs begin to eating big memory and have many cpu usage. Patch from Yong Li. Bug 336153 ? Mark to mark positioning (Lookup Type 6) isn't correct when using MarkAttchmentType Patch from Tin Myo Htet. Bug 333984 ? pango_language_from_string improvements Bug 125378 ? Better underline thickness handling Bug 339730 ? Pango needlessly falls back away from a Type 1 font into a TTF font Bug 342562 ? Support absolute sizes in pango_font_description_to/from_string Bug 341922 ? pango should handle more characters as zero width Patch from Roozbeh Pournader Bug 342525 ? With PangoFc and PangoWin32, approximate digit width is not what it says Bug 342079 ? pangoatsui-private.h missing from release Behdad Esfahbod 12 June 2006 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://mail.gnome.org/archives/gtk-devel-list/attachments/20060612/a6496ff8/attachment-0001.bin From Klaus.Stengel at asamnet.de Tue Jun 13 06:56:34 2006 From: Klaus.Stengel at asamnet.de (Klaus Stengel) Date: Tue, 13 Jun 2006 12:56:34 +0200 Subject: Pango memory leak in get_ruleset() in modules/basic/basic-fc.c Message-ID: <1150196194.9594.16.camel@aquarian.nathanet.lan> Hi, while working with the diagram editor "dia" I noticed a major memory leak when editing text objects. I tracked this down to a problem in the above function. From what I understand the function looks for an ruleset associated with the given font face and in case there is none, the ruleset is created with pango_ot_ruleset_new() and finally attached to the font face. The g_object_unref() is given as "notification callback" so that the ruleset is destroyed when the font face is finalized. In theory this should work, but unfortunately it doesn't in practice, because pango_ot_ruleset_new() internally references "info" itself, thus creating a circular dependency that keeps the objects alive indefinitely. Unfortunately I don't see an simple solution, except to drop that kind of caching again... Bye, Klaus. P.S.: Please reply to my email address as well, as I'm not subscribed to the list. From newren at gmail.com Sat Jun 17 01:53:32 2006 From: newren at gmail.com (Elijah Newren) Date: Fri, 16 Jun 2006 23:53:32 -0600 Subject: Imagine: what if points in Bugzilla had a significant effect? In-Reply-To: References: Message-ID: <51419b2c0606162253pfe0e7edsba8af3f8a1573477@mail.gmail.com> On 6/15/06, Jason Spiro wrote: > Imagine: what if points did something in Bugzilla, like, the more points > you have, the more votes you get? > > I think this would encourage people to file more bug reports, both good > bug reports and not-so-good ones. Would that be a net gain or a net loss > for GTK+? This isn't the right list for this email; bugzilla-devel or filed in bugzilla (against the bugzilla.gnome.org module) would be much better. Thanks, Elijah From timj at imendio.com Sat Jun 17 07:43:57 2006 From: timj at imendio.com (Tim Janik) Date: Sat, 17 Jun 2006 13:43:57 +0200 (CEST) Subject: gslice allocator: general impresions. In-Reply-To: <200606151827.45477.mgiannakidis@gmail.com> References: <200606151827.45477.mgiannakidis@gmail.com> Message-ID: On Thu, 15 Jun 2006, Michalis Giannakidis wrote: > Dear Glib team, > > I have recently used the glib-glice allocator in a very malloc intensive > application, and I would like to share a few observations I made, with you. > > The typical size I send to g_slice_alloc is 20 and 76 bytes (32 bit build). > The total memory consumed by my application has decreased - which is great! > However it `seems' to me, that this decrease in size is larger for the 64bit > build compared to the 32bit build. (I have modified gslice to align a chunk > to its own size so that I don't have unused memory between chunks eg: request > 20 and get 24...) you mean you've set P2ALIGNMENT to 1 * sizeof(void*) to get better granularity of the slices? have you left NATIVE_MALLOC_PADDING at 2*sizeof(void*) at least? (if not, memory fragmentation on some glibc systems and on all 64bit systems can become etxremely bad). > In my application now I use both g_slice_alloc and malloc.Testing the new > allocator in linux I came accross the following: > After using g_slice_alloc to alloc a great amount of data (eg 1500mb), each of > them being 20 or 76 bytes in size, subsequent calls to malloc(8*1024) or > similar sizes take much longer (the allocation does _not_ got to the swap). this is a magnitude of memory allocations where gslice hasn't been well tested. (my machine only has 1GB of memory for instance). while gslice should perform well even much beyond 1GB, i'd suspect that malloc()/memalign() don't, and thus could result in *some* GSlice slowdown as well. > Also if I chage the min_page_size from 128 to 4096, then the subsequent calls > to malloc(8*1024) or similar sizes take even longer. It takes for ever in the > 64 bit build! maybe due to your alignment tweaks. but maybe also because some malloc() buckets will have even longer lists that way. > Moreover, even with min_page_size set to 128, the calls to malloc take for > ever on a Linux 2.4.20 glibc-2.2.4(glibc up to 2.2.5 has a broken > posix_memalign so I fallback to memalign). broken in what way? > In all of the cases above, malloc responds much faster when the gslice > allocator is turned off. aparently some malloc implementations aren't too good at handling large numbers of page allocations. if modifying GSlice is an option for you, you could try to work around this at the expense of read-only allocation of the memory used by GSlice. to do that, you need to disable the HAVE_COMPLIANT_POSIX_MEMALIGN, HAVE_MEMALIGN and HAVE_VALLOC branches in allocator_memalign() and allocator_memfree() so the read-only malloc()-based fallback allocator is enabled. on 32bit systems, that'll by default allocate 16*4096=64k areas to allocate pages from. by doing: - const guint n_pages = 16; + const guint n_pages = 2560; you'll instead allocate 10MB areas, which should put far less stress on the system malloc() (that way, to fill 1GB, a maximum of 100 allocations are required). > I know I should be providing sample code and test programms here to back up > my observations. I also understand that I should provide execution times > instead of just stating that the calls to malloc take for ever. test programs would be great. allthough this kind of stress test can only be run and examined on a limited set of machines. e.g. the development machines i use have just 1GB and normally have only 30%-40% of free memory to spare for tests during runs like make check -C glib/test ;) > I would like to ask you, if there are any known issues in mixing gslice and > malloc calls in malloc intensive applications. > Any suggested readings would be most welcome. you've already seen the two papers cited in the big comment block at the start of gslice.c? it links to: http://citeseer.ist.psu.edu/bonwick94slab.html http://citeseer.ist.psu.edu/bonwick01magazines.html the first of which describes a kernel page allocator which isn't implemented by GSlice. we use memalign() instead, on the assumption that this is good enough for the vast majority of applications out there. if malloc is too stressed out by the aligned allocations gslice makes in your scenario, implementing this page allocator on top of mmap() and using that as a base allocator for gslice may be another option. > Regards > Michalis --- ciaoTJ From tristan.van.berkom at gmail.com Sat Jun 17 12:18:39 2006 From: tristan.van.berkom at gmail.com (Tristan Van Berkom) Date: Sat, 17 Jun 2006 12:18:39 -0400 Subject: GObject extension propose (GContainer) In-Reply-To: <1150491686.19405.355.camel@zosma.extratech.com> References: <200606151101.12868.ntd@users.sourceforge.net> <44919246.8060301@gnome.org> <1150456522.5305.12.camel@localhost.localdomain> <1150491686.19405.355.camel@zosma.extratech.com> Message-ID: <44942B5F.2090903@gnome.org> Alan M. Evans wrote: [...] >>the lookup penalties are negligible. >>type node/class lookups and is_a checks are O(1); >>interface class lookups and conforms_to checks are O(ld(N)), where >>N is the number of interfaces a type node conforms to. >> >> > >Your assertion that the penalties are negligable is not really supported >by your response, unless the constant is also known for both orders. > > From my swift glance at gtype.c, it seems that in the case of an interface, the implementing interface is searched on that class's list of implementing interfaces... so when classes implement hundreds of interfaces it might be a performance hit. I dont think we've yet reached the day that we have to ditch good design and avoid using interfaces because of performance woes, that would be sorry day indeed... (I also dont think GTK+ code will be the only OO code needing major refactoring in those areas too... if these interface lookups weren't negligable) Cheers, -Tristan From chris at gnome-de.org Sat Jun 17 12:57:54 2006 From: chris at gnome-de.org (Christian Neumair) Date: Sat, 17 Jun 2006 18:57:54 +0200 Subject: GtkFileChooser/GnomeVFS backend still messing up authentication manager? (was: GTK+ 2.10, the endgame) In-Reply-To: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> References: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> Message-ID: <1150563475.24534.12.camel@localhost.localdomain> Am Donnerstag, den 15.06.2006, 09:56 -0400 schrieb Matthias Clasen: > I want to have GTK+ 2.10 ready at or immediately after GUADEC. > > I did not declare 2.9.3 api frozen in the release announcement, > because we were still holding the door open for Kris' work on > the new tooltips api. But he has run into some difficulties > with the implementation which will take some time to overcome, > so we have decided to punt this feature and try to get it > into 2.12 early. > > Therefore, I want to consider 2.9.3 api frozen, and take a > look at what still needs to happen before 2.10. Here are some > things I personally would like get worked on (not sure > how much time I can free to look into these myself): > > - I think the async filechooser conversion has caused some > regressions, I noticed that .hidden support seems broken > and autocompletion also behaved badly for me recently. > > - There is a number of FIXMEs and unimplemented bits in > the print code. > > - The print backends need a careful look wrt to memory leaks > and error reporting. > > Are there other important bugs or regressions that need > attention before 2.10 ? Some months ago I investigated an issue where the GtkFileChooser requested file info for all shortcuts and caused mass login requests for all bookmarked remote locations on startup that require login with the GnomeVFS backend. I think the issue was that the file chooser has no way of requesting file info, but signalling at the same time that failure due to unavailability of resources or access constraints isn't fatal, allowing the GnomeVFS backend to not request login data when it is invoked through gtkfilechooserdefault.c:shortcuts_reload_icons. In that case, we may want to fall back to a folder icon. >From reading the GTK+ HEAD source code, the shortcut code still doesn't seem to pass any special flags, so it still seems to be relevant. -- Christian Neumair From gcottenc at gmail.com Sat Jun 17 13:22:54 2006 From: gcottenc at gmail.com (Guillaume Cottenceau) Date: Sat, 17 Jun 2006 19:22:54 +0200 Subject: GTK+ 2.10, the endgame In-Reply-To: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> References: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> Message-ID: On 6/15/06, Matthias Clasen wrote: > Therefore, I want to consider 2.9.3 api frozen, and take a Does this mean that http://developer.gnome.org/doc/API/2.0/gtk/ix07.html (and equivalents for gdk, pango, atk) is now a fully stable source for bindings which want to support new features of 2.10? -- Guillaume Cottenceau - http://zarb.org/~gc/ From timj at imendio.com Sun Jun 18 07:30:56 2006 From: timj at imendio.com (Tim Janik) Date: Sun, 18 Jun 2006 13:30:56 +0200 (CEST) Subject: GObject extension propose (GContainer) In-Reply-To: <44942B5F.2090903@gnome.org> References: <200606151101.12868.ntd@users.sourceforge.net> <44919246.8060301@gnome.org> <1150456522.5305.12.camel@localhost.localdomain> <1150491686.19405.355.camel@zosma.extratech.com> <44942B5F.2090903@gnome.org> Message-ID: On Sat, 17 Jun 2006, Tristan Van Berkom wrote: > Alan M. Evans wrote: > [...] > >>> the lookup penalties are negligible. >>> type node/class lookups and is_a checks are O(1); >>> interface class lookups and conforms_to checks are O(ld(N)), where >>> N is the number of interfaces a type node conforms to. >>> >>> >> >> Your assertion that the penalties are negligable is not really supported >> by your response, unless the constant is also known for both orders. >> >> > From my swift glance at gtype.c, it seems that in the case of > an interface, the implementing interface is searched on that class's > list of implementing interfaces... so when classes implement > hundreds of interfaces it might be a performance hit. no there won't be a performance hit. that's because gtype.c uses a binary search for the lookups (as indicated in my last email by the O(ld(N)) complexity). the function used for frequent interface lookups is: gpointer g_type_interface_peek (gpointer instance_class, GType iface_type); and in a nutshell, it does: { TypeNode *node = lookup_type_node_I (class->g_type); // O(1) TypeNode *iface = lookup_type_node_I (iface_type); // O(1) IFaceEntry *entry = type_lookup_iface_entry_L (node, iface); // O(ld(N)) return entry->vtable; } take a look at gtype.c and type_lookup_iface_entry_L() to confirm. using a binary lookup in type_lookup_iface_entry_L() means, lookups in terms of number of interfaces and node visits during the search relate like this: interfaces-per-node | visits-per-lookup 1 | 1.0 2 | 2.0 3 | 2.6 4 | 3.0 5 | 3.3 6 | 3.6 8 | 4.0 16 | 5.0 32 | 6.0 64 | 7.0 128 | 8.0 256 | 9.0 512 | 10.0 1024 | 11.0 65536 | 17.0 262144 | 19.0 1048576 | 21.0 67108864 | 27.0 268435456 | 29.0 2147483648 | 32.0 that is, for all practical purposes, interface lookups are negligible even for many thausands of interfaces implemented per node. and now, please show me the OO system that gets into the hundreds at least... > Cheers, > -Tristan --- ciaoTJ From nicola at effe-gi.it Wed Jun 14 16:17:53 2006 From: nicola at effe-gi.it (Fontana Nicola) Date: Wed, 14 Jun 2006 20:17:53 +0000 Subject: GObject extension propose (GContainer) Message-ID: <200606142017.53525.nicola@effe-gi.it> Hi all, I'm a GObject based libraries (for UI purpose and not) user and I often need a generic container to derive my own types. In my opinion, I think this generic container must be included inside the GObject library ... it could be used by a lot of derived libraries providing a common approach. I published my solution - that is, what I am currently using - on sourceforge. http://sourceforge.net/projects/gcontainer/ Is it a good idea? Is something planned in this direction? Am I totally wrong? I need feedbacks ... Nicola From tristan.van.berkom at gmail.com Sun Jun 18 12:59:16 2006 From: tristan.van.berkom at gmail.com (Tristan Van Berkom) Date: Sun, 18 Jun 2006 12:59:16 -0400 Subject: GObject extension propose (GContainer) In-Reply-To: References: <200606151101.12868.ntd@users.sourceforge.net> <44919246.8060301@gnome.org> <1150456522.5305.12.camel@localhost.localdomain> <1150491686.19405.355.camel@zosma.extratech.com> <44942B5F.2090903@gnome.org> Message-ID: <44958664.4050704@gmail.com> Tim Janik wrote: [...] > no there won't be a performance hit. [...] > 268435456 | 29.0 > 2147483648 | 32.0 > > that is, for all practical purposes, interface lookups are negligible > even > for many thausands of interfaces implemented per node. > Those stats look great Tim, sorry for any confusion I may have unwillingly caused in this thread, I think its of great importance that people not fear the GInterface. Cheers, -Tristan From jnoreiko at yahoo.com Sun Jun 18 15:19:02 2006 From: jnoreiko at yahoo.com (Joachim Noreiko) Date: Sun, 18 Jun 2006 20:19:02 +0100 (BST) Subject: GtkFileChooser/GnomeVFS backend still messing up authentication manager? (was: GTK+ 2.10, the endgame) In-Reply-To: Message-ID: <20060618191902.1540.qmail@web32405.mail.mud.yahoo.com> > Date: Sat, 17 Jun 2006 18:57:54 +0200 > From: Christian Neumair > Subject: GtkFileChooser/GnomeVFS backend still > > Are there other important bugs or regressions that > need > > attention before 2.10 ? Yes! Please could you implement a help button in the filechooser. The documentation is already written and is ready to be linked to. ___________________________________________________________ All new Yahoo! Mail "The new Interface is stunning in its simplicity and ease of use." - PC Magazine http://uk.docs.yahoo.com/nowyoucan.html From alexl at redhat.com Mon Jun 19 05:10:51 2006 From: alexl at redhat.com (Alexander Larsson) Date: Mon, 19 Jun 2006 11:10:51 +0200 Subject: Printing and blocking ui In-Reply-To: <4491AF5A.2050702@tamu.edu> References: <4491AF5A.2050702@tamu.edu> Message-ID: <1150708251.1962.23.camel@greebo> On Thu, 2006-06-15 at 14:04 -0500, Yevgen Muntyan wrote: > Hi there, > > I print a text document from GtkTextView here. There is a problem > with pagination: pagination is potentially slow, so some sort of progress > dialog should be shown during it. From the other hand, the text buffer > must not be modified during pagination. > How to solve it? Should I show my own modal dialog and make sure user > doesn't modify the buffer, or GtkPrintOperation can take care of it? This is supported now with the Gtkprintoperation::paginate signal and gtk_print_operation_set_show_progress(). > Actually, it would be good to ensure printing blocks the text widget too, > since in this case it wouldn't be necessary to calculate and store all > the pango > layouts in begin-print. Maybe just show a modal dialog between begin-print > and end-print. Locking the editing widget is probably something you have to do yourself. You could also do a snapshot of the data at print time. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's an otherworldly guerilla ex-con with a secret. She's a scantily clad belly-dancing widow who can talk to animals. They fight crime! From muntyan at tamu.edu Mon Jun 19 06:16:00 2006 From: muntyan at tamu.edu (Yevgen Muntyan) Date: Mon, 19 Jun 2006 05:16:00 -0500 Subject: Printing and blocking ui In-Reply-To: <1150708251.1962.23.camel@greebo> References: <4491AF5A.2050702@tamu.edu> <1150708251.1962.23.camel@greebo> Message-ID: <44967960.3060609@tamu.edu> Alexander Larsson wrote: >On Thu, 2006-06-15 at 14:04 -0500, Yevgen Muntyan wrote: > > >>Hi there, >> >>I print a text document from GtkTextView here. There is a problem >>with pagination: pagination is potentially slow, so some sort of progress >>dialog should be shown during it. From the other hand, the text buffer >>must not be modified during pagination. >>How to solve it? Should I show my own modal dialog and make sure user >>doesn't modify the buffer, or GtkPrintOperation can take care of it? >> >> > >This is supported now with the Gtkprintoperation::paginate signal and >gtk_print_operation_set_show_progress(). > > I don't know how paginate works, but the dialog which shows up during printing is not modal, and it appears only after some delay. I can erase text in the buffer between clicking Print button and the time when progress dialog appears. >>Actually, it would be good to ensure printing blocks the text widget too, >>since in this case it wouldn't be necessary to calculate and store all >>the pango >>layouts in begin-print. Maybe just show a modal dialog between begin-print >>and end-print. >> >> > >Locking the editing widget is probably something you have to do >yourself. You could also do a snapshot of the data at print time. > > Well, locking is easy, but I have to tell user about what's happening. So I guess the solution is to have my own modal progress dialog. Regards, Yevgen From mardy at users.sourceforge.net Mon Jun 19 10:10:17 2006 From: mardy at users.sourceforge.net (Alberto Mardegan) Date: Mon, 19 Jun 2006 16:10:17 +0200 Subject: GtkLabel as a child of a windowless widget Message-ID: <20060619141017.GA31744@pupilla> Hi all! I'm creating a Widget based on GtkFrame, with little differences: 1) It's not a container 2) It has the GTK_NO_WINDOW flag set. I'm going to use this widget inside a GtkFixed container, with the only goal of having it paint its frame (and draw its label) on the screen. I want it windowless, so that I can insert other widgets which will appear to be inside it, but which will be actually be owned by the GtkFixed. I know this is not really senseful, but I need such a widget for porting lots of applications from Prolific's Panther GUI to Gtk+. The problem I have, is that the frame label isn't drawn. I'm not sure if there are any operation I should do on it... I just create it, and call gtk_widget_set_parent(). On size_allocate, I'm not sure whether the child's x and y members of the size_allocation struct should be relative to (0,0) or to the parent widget's x and y allocation (since the parent is windowless, too). But this won't work in any case... Any hints? I have no clue. -- Saluti, Mardy http://interlingua.altervista.org Chiacchiera con i tuoi amici in tempo reale! http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com From ame1 at extratech.com Mon Jun 19 11:11:21 2006 From: ame1 at extratech.com (Alan M. Evans) Date: Mon, 19 Jun 2006 08:11:21 -0700 Subject: GObject extension propose (GContainer) In-Reply-To: <44942B5F.2090903@gnome.org> References: <200606151101.12868.ntd@users.sourceforge.net> <44919246.8060301@gnome.org> <1150456522.5305.12.camel@localhost.localdomain> <1150491686.19405.355.camel@zosma.extratech.com> <44942B5F.2090903@gnome.org> Message-ID: <1150729881.19405.420.camel@zosma.extratech.com> On Sat, 2006-06-17 at 09:18, Tristan Van Berkom wrote: > Alan M. Evans wrote: > >>the lookup penalties are negligible. > >>type node/class lookups and is_a checks are O(1); > >>interface class lookups and conforms_to checks are O(ld(N)), where > >>N is the number of interfaces a type node conforms to. > > > >Your assertion that the penalties are negligable is not really supported > >by your response, unless the constant is also known for both orders.> > > > From my swift glance at gtype.c, it seems that in the case of > an interface, the implementing interface is searched on that class's > list of implementing interfaces... so when classes implement > hundreds of interfaces it might be a performance hit. My impression from the original question, which I didn't ask, was not so much about access to a large number of members. If a single variable needs to be examined many times then the performance penalty of a generic interface lookup can add up. In any case, I merely observed an assertion, "the lookup penalties are negligible," and the what appeared to be supporting data, the order of the lookups. This doesn't tell us what the penalty is, only that there is a penalty that gets worse as the number of members increases. Maybe the penalty is negligible, but the data presented didn't say so. That's all I was saying. > I dont think we've yet reached the day that we have to ditch good design > and avoid using interfaces because of performance woes, that would > be sorry day indeed... (I also dont think GTK+ code will be the only OO code > needing major refactoring in those areas too... if these interface > lookups weren't negligable) Indeed. I would certainly not advocate dispensing with good design. In fact, I usually advocate the purist design in my own software, and let Moore's Law fix the performance issues. But some cases still call for direct access for essential performance. I, too, would like to know the performance penalty of the generic interface. Being lazy, I suppose I will set up some experiment to discover it pragmatically. From federico at ximian.com Mon Jun 19 13:22:31 2006 From: federico at ximian.com (Federico Mena Quintero) Date: Mon, 19 Jun 2006 12:22:31 -0500 Subject: GtkFileChooser/GnomeVFS backend still messing up authentication manager? (was: GTK+ 2.10, the endgame) In-Reply-To: <20060618191902.1540.qmail@web32405.mail.mud.yahoo.com> References: <20060618191902.1540.qmail@web32405.mail.mud.yahoo.com> Message-ID: <1150737751.8452.77.camel@cacharro.xalalinux.org> On Sun, 2006-06-18 at 20:19 +0100, Joachim Noreiko wrote: > Yes! > Please could you implement a help button in the > filechooser. The documentation is already written and > is ready to be linked to. Do we have a mechanism for this? I see that GtkColorSelectionDialog creates a Help button but hides it by default, and it gives GTK_RESPONSE_HELP when pressed. Does that get captured anywhere so that it can take you to the right help page? Federico From tvb at gnome.org Mon Jun 19 14:31:56 2006 From: tvb at gnome.org (Tristan Van Berkom) Date: Mon, 19 Jun 2006 14:31:56 -0400 Subject: GtkLabel as a child of a windowless widget In-Reply-To: <20060619141017.GA31744@pupilla> References: <20060619141017.GA31744@pupilla> Message-ID: <4496ED9C.3090009@gnome.org> Alberto Mardegan wrote: [...] > > Any hints? I have no clue. This mailing list is for the discussion of GTK+ development itself, for questions related to writing applications in gtk+ please write to gtk-app-devel-list at gnome.org or gtk-list at gnome.org. FYI: Widgets do not overlap in any containers in gtk+ (I've heard that there is z-ordering in gnomecanvas... you might want to check that out). You can: - Draw the frame yourself in the GtkFixed and place a child label where the frames label would be - Add a fixed as the child widget of the frame (probably what you want anyway). Cheers, -Tristan From federico at ximian.com Mon Jun 19 22:47:24 2006 From: federico at ximian.com (Federico Mena Quintero) Date: Mon, 19 Jun 2006 21:47:24 -0500 Subject: GtkLabel as a child of a windowless widget In-Reply-To: <20060619141017.GA31744@pupilla> References: <20060619141017.GA31744@pupilla> Message-ID: <1150771645.8452.94.camel@cacharro.xalalinux.org> On Mon, 2006-06-19 at 16:10 +0200, Alberto Mardegan wrote: > Hi all! > I'm creating a Widget based on GtkFrame, with little differences: > 1) It's not a container > 2) It has the GTK_NO_WINDOW flag set. > > I'm going to use this widget inside a GtkFixed container, with the only > goal of having it paint its frame (and draw its label) on the screen. > I want it windowless, so that I can insert other widgets which will > appear to be inside it, but which will be actually be owned by the > GtkFixed. First, can you simply use a GtkFrame inside a GtkFixed, and just not put a child inside the frame? > The problem I have, is that the frame label isn't drawn. I'm not sure if > there are any operation I should do on it... I just create it, and call > gtk_widget_set_parent(). > On size_allocate, I'm not sure whether the child's x and y members of > the size_allocation struct should be relative to (0,0) or to the parent > widget's x and y allocation (since the parent is windowless, too). But > this won't work in any case... Allocations are always with respect to the parent window. So if you have a windowed parent, then inside it a no-window container at (10, 20), and a child of that container which is supposed to be offset (3, 4) pixels from the container's top-left corner, then the child's allocation will be at (13, 24). Federico From mclasen at redhat.com Tue Jun 20 09:26:36 2006 From: mclasen at redhat.com (Matthias Clasen) Date: Tue, 20 Jun 2006 09:26:36 -0400 Subject: GTK+ team meeting Message-ID: <1150809996.15532.50.camel@golem.boston.redhat.com> After a few weeks, we should probably have a team meeting today. The meeting is intended for the GTK+ team, but everybody is welcome to come and listen. The meeting logs will be posted on the GTK+ website (http://www.gtk.org/plan/meetings). Place: irc.gnome.org:#gtk-devel Time: 19:30 UTC (15:30 EDT), Tue, Jun 20 Possible agenda items: - GUADEC meeting - 2.10 + when to release + what needs to be on the 2.10 milestone but isn't ? Matthias From mclasen at redhat.com Tue Jun 20 11:21:20 2006 From: mclasen at redhat.com (Matthias Clasen) Date: Tue, 20 Jun 2006 11:21:20 -0400 Subject: GLib 2.11.4 released Message-ID: <1150816880.15532.58.camel@golem.boston.redhat.com> GLib 2.11.4 is now available for download at: ftp://ftp.gtk.org/pub/gtk/v2.11/ http://ftp.gnome.org/pub/GNOME/sources/glib/2.11/ glib-2.11.4.tar.bz2 md5sum: 9d3a94baa4bfcd9a579b45eea6de3a8c glib-2.11.4.tar.gz md5sum: f7768bc7ed524c6b40cb87daccb6c2b2 This is a development release leading up to GLib 2.12. Notes: * This is unstable development release. While it has had a bit of testing, there are certainly plenty of bugs remaining to be found. This release should not be used in production. * Installing this version will overwrite your existing copy of GLib 2.10. If you have problems, you'll need to reinstall GLib 2.10. * GLib 2.12 will be source and binary compatible with the GLib 2.10.x series (for some caveats, see the README). At this point, the API additions in the 2.11.x series are finished. * Bugs should be reported to http://bugzilla.gnome.org. About GLib ========== GLib is the low-level core library that forms the basis for projects such as GTK+ and GNOME. It provides data structure handling for C, portability wrappers, and interfaces for such runtime functionality as an event loop, threads, dynamic loading, and an object system. More information about GLib is available at: http://www.gtk.org/ An installation guide for the GTK+ libraries, including GLib, can be found at: http://developer.gnome.org/doc/API/2.0/gtk/gtk-building.html Overview of Changes from GLib 2.11.3 to GLib 2.11.4 =================================================== * GBookmarkFile: - g_bookmark_file_remove_item returns a boolean * g_mkstemp accepts the XXXXXX in the middle of the template * Bugs fixed: 344868 g_key_file_to_data should separate groups * Updated translations (de,es,fr,gu,hi,ko,th) A list of all bugs fixed in this release can be found at: http://bugzilla.gnome.org/buglist.cgi?bug_id=344868 Thanks to everybody who has contributed to this release, in the form of bug reports or patches: Emmanuele Bassi, Christian Persch, Federico Mena Quintero Matthias Clasen June 20, 2006 From mgiannakidis at gmail.com Mon Jun 19 08:20:48 2006 From: mgiannakidis at gmail.com (Michalis Giannakidis) Date: Mon, 19 Jun 2006 15:20:48 +0300 Subject: gslice allocator: general impresions. In-Reply-To: References: <200606151827.45477.mgiannakidis@gmail.com> Message-ID: <200606191520.48220.mgiannakidis@gmail.com> Dear Tim > > (I have modified gslice > > to align a chunk to its own size so that I don't have unused memory > > between chunks eg: request 20 and get 24...) > > you mean you've set P2ALIGNMENT to 1 * sizeof(void*) to get better > granularity of the slices? have you left NATIVE_MALLOC_PADDING at > 2*sizeof(void*) at least? (if not, memory fragmentation on some glibc > systems and on all 64bit systems can become etxremely bad). > I didn't change P2ALIGNMENT . I modified SLAB_INDEX to (asize - 1), SLAB_CHUNK_SIZE to (ix + 1) I also modified P2ALIGN to (size) for all occurances of P2ALIGN except for SLAB_INFO_SIZE. I understand that this will create different memory pools for each size I alloc for, but this is accpeted since I only call g_slice_alloc for two sizes. The tweak seem to be OK since I don't get any segfaults. > maybe due to your alignment tweaks. but maybe also because some malloc() > buckets will have even longer lists that way. > The slowdown also occurred without the alignment tweaks. My understanding is that it is a general malloc slowdown that occurres of the many small mallocs done in the application plus the many larger mallocs done by the gslice allocator. I have read the references available in the gslice allocator comments and were very helpful. What I am looking for know is some sort of comparisons in memory usage and speed in applications changing from malloc to gslice. Also, any tweaks in the gslice allocation sizes providing a more responsive malloc would be great! Any suggestions would be very welcome. Thank you very much. Michalis -- Michalis Giannakidis From the introduction of 2396: This document updates and merges "Uniform Resource Locators" [RFC1738] and "Relative Uniform Resource Locators" [RFC1808] in order to define a single, generic syntax for all URI. It excludes those portions of RFC 1738 that defined the specific syntax of individual URL schemes ... Seems you missed the second sentence. That's why 2396 is not obsoleting 1738 in a formal sense, it only update a part of 1738 and this part doesn't include the definition of the FILE scheme. > from a usability standpoint, i really enjoy not having to type 3 /s in a row > (even though konqi does let you do that too) It's a completely different problem, you should even be able to enter /usr/local and have the software expand/remap to a valid URL. I don't use Konqueror but I'm pretty sure Netscape does this, the goal is that once entered the user is exposed to a valid URL. This should also include escaping of reserved or forbiden characters, the goal is to provide something correct for selection or drag and drop as well as teaching the user. Daniel -- Daniel Veillard | Red Hat Network http://redhat.com/products/network/ veillard@redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From my quick look at the RFC (1459), IRC should be able to support SJIS, UTF-8 and most of the Latin encodings -- the control stream is ASCII. But there is no indication of the encoding in use, making it necessary to use some OOB information to set the right encoding. Nor is there any indication of the language, making selection of an appropriate Han glyph set rather difficult. Pretty primitive protocol. I guess there are sufficient per-channel conventions to resolves these issues. > You may well be well right that we should have worked on making > GdkFont still work; it's certainly a bit of a API hole that there > isn't a conventional character-by-character text drawing API > available. If this is a reasonable course, then perhaps the right idea is to create a new function that returns an Xft font for use by the rendering routines; that way legacy applications would continue to see only GDK_FONT_FONT and GDK_FONT_FONTSET but minor source modifications could switch applications to Xft fonts instead. That would make porting existing Gtk+ apps to use Xft would require few changes rather than a wholesale conversion to Pango. > But considering that we are releasing this weekend, it's not something > we can go back and revisit at this point. > > (While adding a 3rd type of font may seem like a small API compatible, > change, it's actually something that can easily crash applications > that aren't expecting it.) Adding new APIs after the release that preserve source and binary compatibility for existing applications would probably be a better way than whacking gdk_font_load to return a new kind of object; the key is to require applications call a new function to get the new kind of gdk_font object. Keith Packard XFree86 Core Team Compaq Cambridge Research Lab From mardy@users.sourceforge.net Thu Jun 1 07:04:29 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 633423B0C7E for ; Thu, 1 Jun 2006 07:04:29 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28962-04 for ; Thu, 1 Jun 2006 07:04:28 -0400 (EDT) Received: from smtp010.mail.ukl.yahoo.com (smtp010.mail.ukl.yahoo.com [217.12.11.79]) by menubar.gnome.org (Postfix) with SMTP id 690073B013F for ; Thu, 1 Jun 2006 07:04:27 -0400 (EDT) Received: (qmail 61490 invoked from network); 1 Jun 2006 11:04:26 -0000 Received: from unknown (HELO pupilla) (mardy78@151.42.226.237 with login) by smtp010.mail.ukl.yahoo.com with SMTP; 1 Jun 2006 11:04:26 -0000 Received: by pupilla (Postfix, from userid 1000) id 038336B7FF; Thu, 1 Jun 2006 13:03:17 +0200 (CEST) Date: Thu, 1 Jun 2006 13:03:17 +0200 From: Alberto Mardegan To: gtk-devel-list@gnome.org Message-ID: <20060601110317.GA23802@pupilla> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Accept-Language: it,ia,en,bg,es,fr User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.599 tagged_above=-999 required=2 tests=[BAYES_00=-2.599] X-Spam-Score: -2.599 X-Spam-Level: Subject: Histogram widget X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2006 11:04:29 -0000 Hi all! I'm going to write a widget for displaying histograms. Would it be elegant/smart/useful if it were to fetch the data from a GtkTreeModel, or would it be an unneeded complexity and just some GArrays are better? I'm thinking of a GtkTreeModel, in which every row is a histogram bar; hence we would/could have a double field for the value, a string field for the label in the X axis, maybe a GdkColor for the color and whatever can come to mind. Many thanks in advance to all those who will share their thoughts on the matter. -- Saluti, Mardy http://www.interlingua.com ___________________________________ Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB http://mail.yahoo.it From matthias.clasen@gmail.com Thu Jun 1 09:35:39 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 44D6D3B0213 for ; Thu, 1 Jun 2006 09:35:39 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06492-04 for ; Thu, 1 Jun 2006 09:35:37 -0400 (EDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.190]) by menubar.gnome.org (Postfix) with ESMTP id 2B1463B019C for ; Thu, 1 Jun 2006 09:35:37 -0400 (EDT) Received: by nf-out-0910.google.com with SMTP id l37so564726nfc for ; Thu, 01 Jun 2006 06:35:36 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=AXg4pkieJhFwK/fsPTG5BVq6Sv29H8f6t8wbUeiehWS8QFuJL4sEqqu5dTplyA7vdRrz50uICadI8ZT1y2rp+BasRLmOBacUSSXY1blUEAIWfvb1udC+bqhsXFVhdU6V4+2wZCjIuaczx07TxLq1x+v9zHm4YPkA8kydW+5SycA= Received: by 10.48.31.10 with SMTP id e10mr779574nfe; Thu, 01 Jun 2006 06:33:48 -0700 (PDT) Received: by 10.48.215.7 with HTTP; Thu, 1 Jun 2006 06:33:48 -0700 (PDT) Message-ID: Date: Thu, 1 Jun 2006 09:33:48 -0400 From: "Matthias Clasen" To: "Kristian Rietveld" In-Reply-To: <20060531200823.GA7846@babi-pangang.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20060531200823.GA7846@babi-pangang.org> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.742 tagged_above=-999 required=2 tests=[AWL=-0.700, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.558, SPF_PASS=-0.001] X-Spam-Score: -1.742 X-Spam-Level: Cc: gtk-devel-list@gnome.org, timj@imendio.com Subject: Re: Tooltips progress X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2006 13:35:39 -0000 > Attached is some sample code using the new API. Opinions, comments, > suggestions are appreciated. > I don't remember too much of the original proposal, so I'll just go by what I see in the examples... What is the relation between the tooltip-markup and has-tooltip properties ? Is has-tooltip automatically set when setting tooltip-markup ? Or do you only need to set has-tooltip if you want to connect to query-tooltip ? Is the tooltip window available as a property too ? (The example uses a dedicated setter for it). The example doesn't show tooltips constructed using the old tooltips api, but I assume those will continue to work as before, right ? Using x == -1 to indicate a keyboard-triggered tooltip looks a bit odd to me; how about adding a boolean parameter for this ? Regarding dedicated treeview api, I think we can do without it (at least initially), if we have a good example in the docs. Though lots of people will forget the selection_changed thing for keyboard tooltips... Could you enhance your demo with an example of text view tooltips on a tag ? Matthias From jean.brefort@normalesup.org Thu Jun 1 09:58:21 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 479CD3B0171 for ; Thu, 1 Jun 2006 09:58:03 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08512-08 for ; Thu, 1 Jun 2006 09:58:01 -0400 (EDT) Received: from smtp4-g19.free.fr (smtp4-g19.free.fr [212.27.42.30]) by menubar.gnome.org (Postfix) with ESMTP id 84A533B0CBB for ; Thu, 1 Jun 2006 09:57:52 -0400 (EDT) Received: from che21-1-82-239-125-56.fbx.proxad.net (che21-1-82-239-125-56.fbx.proxad.net [82.239.125.56]) by smtp4-g19.free.fr (Postfix) with ESMTP id DE3EA54C0D; Thu, 1 Jun 2006 15:57:50 +0200 (CEST) From: Jean =?ISO-8859-1?Q?Br=E9fort?= To: Alberto Mardegan In-Reply-To: <20060601110317.GA23802@pupilla> References: <20060601110317.GA23802@pupilla> Content-Type: text/plain; charset=utf-8 Date: Thu, 01 Jun 2006 16:00:49 +0200 Message-Id: <1149170449.11316.1.camel@athlon.brefort.fr> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.884 tagged_above=-999 required=2 tests=[AWL=-0.354, BAYES_00=-2.599, SPF_NEUTRAL=1.069] X-Spam-Score: -1.884 X-Spam-Level: Cc: gtk-devel-list@gnome.org Subject: Re: Histogram widget X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2006 13:58:21 -0000 Le jeudi 01 juin 2006 13:03 +0200, Alberto Mardegan a crit : > Hi all! > I'm going to write a widget for displaying histograms. Would it be > elegant/smart/useful if it were to fetch the data from a GtkTreeModel, > or would it be an unneeded complexity and just some GArrays are better? > > I'm thinking of a GtkTreeModel, in which every row is a histogram bar; > hence we would/could have a double field for the value, a string field > for the label in the X axis, maybe a GdkColor for the color and whatever > can come to mind. > > Many thanks in advance to all those who will share their thoughts on the > matter. Do you want histograms or column charts? Anyway both already exist in goffice and we have the GOGraphWidget widget to display a large variety of 2D charts. Regards, Jean Brfort From mitch@gimp.org Thu Jun 1 10:37:41 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 9C8673B0253 for ; Thu, 1 Jun 2006 10:37:41 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12026-06 for ; Thu, 1 Jun 2006 10:37:40 -0400 (EDT) Received: from mitch.gimp.org (p549C9506.dip0.t-ipconnect.de [84.156.149.6]) by menubar.gnome.org (Postfix) with ESMTP id 630D53B0171 for ; Thu, 1 Jun 2006 10:37:40 -0400 (EDT) Received: from mitch by mitch.gimp.org with local (Exim 3.36 #1 (Debian)) id 1FloKa-0005tI-00; Thu, 01 Jun 2006 16:39:24 +0200 From: Michael Natterer To: Kristian Rietveld In-Reply-To: <20060531200823.GA7846@babi-pangang.org> References: <20060531200823.GA7846@babi-pangang.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Thu, 01 Jun 2006 16:39:24 +0200 Message-Id: <1149172764.5721.13.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-0.468 tagged_above=-999 required=2 tests=[AWL=-1.996, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, RCVD_IN_NJABL_DUL=1.946, RCVD_IN_SORBS_DUL=2.046] X-Spam-Score: -0.468 X-Spam-Level: Cc: gtk-devel-list@gnome.org, timj@imendio.com Subject: Re: Tooltips progress X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2006 14:37:41 -0000 On Wed, 2006-05-31 at 22:08 +0200, Kristian Rietveld wrote: > Currently, we are using the following query-tooltips signal: > > gboolean (*query_tooltip) (GtkWidget *widget, > gint x, > gint y, > GtkTooltip *tooltip); > > But if a user sets a custom using gtk_widget_set_custom_window(), we don't > have to pass a GtkTooltip around. So currently I just set the tooltip > field to NULL, so the user knows he has to use his own custom tooltip > window (and we assume he has a reference to that). Is this okay or do > we want to change this? We could also move the _set_custom_window() > functions into GtkTooltip for example. I would very much appreciate if the GtkTooltip object also kept track of the custom window. IMHO it makes no sense to handle this differently. gtk_tooltip_set_markup() vs. gtk_tooltip_set_window() simply feels much better than the asymmetry in gtk_tooltip_set_markup() vs. gtk_widget_set_tooltip_window() The current approach even limits the new tooltip system's use cases, since you have to set the custom window *outside* the callback. There is no way to decide *in* the callback if a standard tooltip is sufficient, or if a custom window is needed. Another problem is the assymetry in getting the relevant data to the callback. With markup, the GtkTooltip can be queried for the markup, if it's a custom window, you have to get it to the callback somehow. In your example code it's passed as user_data, but user_data is often not available since it's needed for other things, so you have to add a "GtkWidget *tooltip_window" to the "other thing". If "other thing" is e.g. the application toplevel window, which of the sub-widget's tooltips should it keep? All of them? People will in many cases end up attaching the tooltip window to the widget. I also fail to see why the "has-tooltip" property has to be set to TRUE, even tho a tooltip window was set on the widget. ciao, --mitch From islewind@gmail.com Thu Jun 1 11:16:53 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id CCF0F3B027D for ; Thu, 1 Jun 2006 11:16:53 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15167-10 for ; Thu, 1 Jun 2006 11:16:52 -0400 (EDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.181]) by menubar.gnome.org (Postfix) with ESMTP id EBDF73B02A2 for ; Thu, 1 Jun 2006 11:16:51 -0400 (EDT) Received: by py-out-1112.google.com with SMTP id x31so492875pye for ; Thu, 01 Jun 2006 08:16:51 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=TJcxirCpCUc11Q5e90yGryvZPvt6/4y9oixknOJbU9D0ul2vMJTRqtCSsnJU4SxRLn9lAKaOyN+GZ5nbxOOcf0T99ZPfjnqzOA3KseyOVQ4Ap+A8c67skU0CG6t40az7MwaWe4KCKIFXgrpOCN10KzuNVCisW4dtldpMgxlx5bQ= Received: by 10.35.36.13 with SMTP id o13mr1010511pyj; Thu, 01 Jun 2006 08:16:51 -0700 (PDT) Received: by 10.35.10.17 with HTTP; Thu, 1 Jun 2006 08:16:50 -0700 (PDT) Message-ID: <7bf6f2dc0606010816q15d512aejc30a6c93bc165e6@mail.gmail.com> Date: Thu, 1 Jun 2006 17:16:50 +0200 From: "=?ISO-8859-1?Q?=D8yvind_Kol=E5s?=" Sender: islewind@gmail.com To: "=?ISO-8859-1?Q?Carlos_Eduardo_Rodrigues_Di=F3genes?=" In-Reply-To: <1149104973.27709.4.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <1149104973.27709.4.camel@localhost.localdomain> X-Google-Sender-Auth: aee248fb7aae0f83 X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.571 tagged_above=-999 required=2 tests=[AWL=0.029, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.571 X-Spam-Level: Cc: gtk-devel-list@gnome.org Subject: Re: Color space transformations in GTK X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2006 15:16:54 -0000 On 5/31/06, Carlos Eduardo Rodrigues Di=F3genes = wrote: > Hi, > > There is any plan to add color spaces conversions in GTK+ (GDK or > Gdk-Pixbuf)? If the answear is no, why not? Pixel format conversions is not a small piece of code and the needed pixel formats varies from scenario to scenario. Most programs will not need such a large general infrastructure and the ones that really need it would probably not be satisfied with a simpler solution. What functionality is it you miss that you think fits into a GUI toolkit? (color management is a seperate issue to color space(pixel format) conversions according to my interpretation of your question). /=D8yvind K. --=20 =ABThe future is already here. It's just not very evenly distributed=BB -- William Gibson http://pippin.gimp.org/ http://ffii.org/ From timj@gtk.org Thu Jun 1 11:17:09 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 565CF3B0DC9 for ; Thu, 1 Jun 2006 11:17:09 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15377-03 for ; Thu, 1 Jun 2006 11:17:02 -0400 (EDT) Received: from webmail.hansenet.de (mail01.hansenet.de [213.191.73.61]) by menubar.gnome.org (Postfix) with ESMTP id 8AFEE3B0DB5 for ; Thu, 1 Jun 2006 11:17:00 -0400 (EDT) Received: from birnet.org (213.39.195.111) by webmail.hansenet.de (7.2.059) id 447D3FB2000502B1; Thu, 1 Jun 2006 17:16:59 +0200 Received: from master.birnet.private (localhost [127.0.0.1]) by birnet.org (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k51FGvIU003186 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 1 Jun 2006 17:16:57 +0200 Received: (from timj@localhost) by master.birnet.private (8.13.4/8.13.4/Submit) id k51FGpl3003183; Thu, 1 Jun 2006 17:16:51 +0200 Date: Thu, 1 Jun 2006 17:16:51 +0200 (CEST) From: Tim Janik X-X-Sender: timj@master.birnet.private To: Kristian Rietveld In-Reply-To: <20060531183045.GA7564@babi-pangang.org> Message-ID: References: <20060314132538.GA3526@babi-pangang.org> <443B4A8A.8000302@imendio.com> <20060425103017.GA15762@babi-pangang.org> <20060531183045.GA7564@babi-pangang.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.431 tagged_above=-999 required=2 tests=[AWL=0.168, BAYES_00=-2.599] X-Spam-Score: -2.431 X-Spam-Level: Cc: Gtk+ Developers , Soeren Sandmann Subject: Re: Callback based tooltips (Re: New tooltips API, continued) X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2006 15:17:10 -0000 On Wed, 31 May 2006, Kristian Rietveld wrote: > On Tue, Apr 25, 2006 at 03:08:12PM +0200, Soeren Sandmann wrote: >> I once wrote down how tooltips should behave: > > I mostly like the behaviour you described below. > >> - Tooltips are too intrusive. The text should be smaller, and not sure if this has been raised already... the font size of the tooltips should be exactly as large as the default font size (module tooltip markup of course) to avoid reducing usability of the tooltips in contrast to normal text (labels). >> they should to the right of the cursor, and a little below >> the cursor's center. --- ciaoTJ From timj@gtk.org Thu Jun 1 12:12:43 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id E5C0F3B0171 for ; Thu, 1 Jun 2006 12:12:42 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19272-05 for ; Thu, 1 Jun 2006 12:12:40 -0400 (EDT) Received: from webmail.hansenet.de (mail03.hansenet.de [213.191.73.10]) by menubar.gnome.org (Postfix) with ESMTP id 9C9433B015C for ; Thu, 1 Jun 2006 12:12:39 -0400 (EDT) Received: from birnet.org (213.39.195.111) by webmail.hansenet.de (7.2.059) id 447C08450012767E; Thu, 1 Jun 2006 18:12:37 +0200 Received: from master.birnet.private (localhost [127.0.0.1]) by birnet.org (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k51GCZTL005312 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 1 Jun 2006 18:12:35 +0200 Received: (from timj@localhost) by master.birnet.private (8.13.4/8.13.4/Submit) id k51GCY4h005311; Thu, 1 Jun 2006 18:12:34 +0200 Date: Thu, 1 Jun 2006 18:12:34 +0200 (CEST) From: Tim Janik X-X-Sender: timj@master.birnet.private To: Kristian Rietveld In-Reply-To: <20060531200823.GA7846@babi-pangang.org> Message-ID: References: <20060531200823.GA7846@babi-pangang.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.434 tagged_above=-999 required=2 tests=[AWL=0.165, BAYES_00=-2.599] X-Spam-Score: -2.434 X-Spam-Level: Cc: Gtk+ Developers , Matthias Clasen Subject: Re: Tooltips progress X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2006 16:12:43 -0000 On Wed, 31 May 2006, Kristian Rietveld wrote: > Last week I've been working on the tooltips implementation, using the > callback-based approach/interface discussed earlier on this mailing list. > The basics are working already including keyboard support and custom > windows. Before I can finalize a patch for reviewal, I have some comments > and questions. > > > In a follow up to his original mail, Tim is talking about adding the > following function: > > gdk_display_force_query_display (GdkDisplay *); > > I am not sure if this really belongs in GdkDisplay. Currently I have a: > > gtk_widget_force_query_tooltip (GtkWidget *widget); > > which works just fine for forcably updating a tooltip, in both keyboard > and mouse mode. I guess most people will usually know which widget's > tooltip to update. Opinions? yes, in most cases the widget will be known, but not in all. the trivial example is changing per-display settings like ::display-tooltips = off or the timeout. also, since we support nesting/overlaying of widgets. even the display might not be clear, which is why i actually proposed: void gtk_display_force_tooltip_query (GdkDisplay*); /* display may be NULL */ /* because of nesting/overlapping tooltips, widget is not always known * http://mail.gnome.org/archives/gtk-devel-list/2006-April/msg00030.html */ but you have a point here, since in most cases the widget will indeed be known, it'll be most convenient to also provide: void gtk_widget_force_query_tooltip (GtkWidget *widget) { gtk_display_force_tooltip_query (gtk_widget_get_display (widget)); } > Currently, we are using the following query-tooltips signal: > > gboolean (*query_tooltip) (GtkWidget *widget, > gint x, > gint y, > GtkTooltip *tooltip); > > But if a user sets a custom using gtk_widget_set_custom_window(), we don't > have to pass a GtkTooltip around. So currently I just set the tooltip > field to NULL, so the user knows he has to use his own custom tooltip > window (and we assume he has a reference to that). my original proposal http://mail.gnome.org/archives/gtk-devel-list/2006-April/msg00010.html included: GtkWindow* gtk_widget_get_tooltip_window (GtkWidget *widget); so the user doesn't need to duplicate tracking of this window. > Is this okay or do > we want to change this? We could also move the _set_custom_window() > functions into GtkTooltip for example. no, i intentionally didn't put it there. the reasoning for this was: - the setter should go along with a getter - the user should get at the custom window but *not* the tooltips window used by gtk. the latter is violated with a getter on GtkTooltip. > Implementing GtkTreeView tooltips in your application is now pretty easy, > just set up a query_tooltip callback and call gtk_tree_view_get_path_at_pos() > with the coordinates which are provided to you (but if x == -1, the keyboard > mode is enabled and then you should really call gtk_tree_view_get_cursor()). using x==-1&&y==-1 for keyboard mode was a bit of an aftermath patchup to my original proposal. Matthias Clasen now pointed out: > Using x == -1 to indicate a keyboard-triggered tooltip looks a bit > odd to me; how about adding a boolean parameter for this ? and i thnk he is right. another indication that we'd not want (-1,-1) is that you already talk about querying the cursor yourself. so it's probably better to adapt the signal to: gboolean (*query_tooltip) (GtkWidget *widget, gint x, gint y, gboolean keyboard_tip, GtkTooltip *tooltip); and preserve the x,y position. > Would this be sufficient, or do we want to add some special API for supporting > tooltips in the tree view, like having GtkTreeView implement the query > tooltip callback and have tooltip-markup properties on cell renderers. > Personally I think implementing the query-tooltip yourself is easy enough > for people to do and also really flexible, so there's no need for more API. i'd say let's first nail the basic tooltip API. GtkWidget already comes with a default handler. we can still add treeview convenience API later on if that is required. (and for that, i think it'd be easiest to forward the query_tooltip() signal to signals on the columns and cell renderers). > Since we re-query for a tooltip on mouse motion, I was wondering what we > should do in keyboard mode if a key is pressed in, for example, GtkTreeView. > A key press there might change the cursor and we might want to update the > tooltip contents. Do we want stock GTK+ to take care of this, or should the > user do this himself? (For example by calling gtk_widget_force_tooltip_query > from the GtkTreeSelection::changed callback). i think i'd handle key press events like mouse motion and scroll events, i.e. re-query. that eases things on the user side and is consistent with movement. (the basic idea behind my proposal was that gtk+ takes care of the required granularity whenever possible, so gtk_display_force_tooltip_query() needs to allmost never be used). > thanks, > > -kris. > --- ciaoTJ From timj@gtk.org Thu Jun 1 12:21:35 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 96AD53B0E27 for ; Thu, 1 Jun 2006 12:21:35 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19725-05 for ; Thu, 1 Jun 2006 12:21:33 -0400 (EDT) Received: from webmail.hansenet.de (mail02.hansenet.de [213.191.73.62]) by menubar.gnome.org (Postfix) with ESMTP id AE4893B0115 for ; Thu, 1 Jun 2006 12:21:33 -0400 (EDT) Received: from birnet.org (213.39.195.111) by webmail.hansenet.de (7.2.059) id 447C276B001342DD; Thu, 1 Jun 2006 18:21:31 +0200 Received: from master.birnet.private (localhost [127.0.0.1]) by birnet.org (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k51GLTmR005587 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 1 Jun 2006 18:21:29 +0200 Received: (from timj@localhost) by master.birnet.private (8.13.4/8.13.4/Submit) id k51GLTBN005586; Thu, 1 Jun 2006 18:21:29 +0200 Date: Thu, 1 Jun 2006 18:21:29 +0200 (CEST) From: Tim Janik X-X-Sender: timj@master.birnet.private To: Matthias Clasen In-Reply-To: Message-ID: References: <20060531200823.GA7846@babi-pangang.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.436 tagged_above=-999 required=2 tests=[AWL=0.163, BAYES_00=-2.599] X-Spam-Score: -2.436 X-Spam-Level: Cc: Gtk+ Developers , Kristian Rietveld Subject: Re: Tooltips progress X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2006 16:21:35 -0000 On Thu, 1 Jun 2006, Matthias Clasen wrote: >> Attached is some sample code using the new API. Opinions, comments, >> suggestions are appreciated. >> > > I don't remember too much of the original proposal, so I'll just go > by what I see in the examples... > > What is the relation between the tooltip-markup and has-tooltip > properties ? setting ::tooltip-markup should automatically set ::has-tooltip=TRUE; as mentioned in the original proposal: http://mail.gnome.org/archives/gtk-devel-list/2006-April/msg00010.html > Is has-tooltip automatically set when setting tooltip-markup ? > Or do you only need to set has-tooltip if you want to connect to > query-tooltip ? the idea behind ::has-tooltip is to reduce the number of required signal emissions to figure a tooltip. e.g. by adding a PRIVATE_GTK_* flag that indicates if the ::query-tooltips() emission is neccessary. maybe it'd helpt to rename that property to ::can-tooltip? > Is the tooltip window available as a property too ? (The example uses > a dedicated setter for it). i don't quite see a need for that. the custom window is only useful if you implement your own ::query-tooltip() handler anyway and there you could simply use the getter. (if you want to argue consistency with other things settable/gettable on widgets though, then yes, you have a point for also exporting it as a property) > The example doesn't show tooltips constructed using the old tooltips > api, but I assume those will continue to work as before, right ? that was the plan, i.e. you'd basically just do: void gtk_tooltips_set_tip (GtkTooltips *tooltips, GtkWidget *widget, const gchar *tip_text, const gchar *tip_private) { g_object_set (widget, "tooltip-markup", tip_text, NULL); } > Matthias --- ciaoTJ From timj@gtk.org Thu Jun 1 12:37:26 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 777F13B0DE5 for ; Thu, 1 Jun 2006 12:37:26 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20777-08 for ; Thu, 1 Jun 2006 12:37:17 -0400 (EDT) Received: from webmail.hansenet.de (mail03.hansenet.de [213.191.73.10]) by menubar.gnome.org (Postfix) with ESMTP id DD7453B0E15 for ; Thu, 1 Jun 2006 12:37:16 -0400 (EDT) Received: from birnet.org (213.39.195.111) by webmail.hansenet.de (7.2.059) id 447C084500128D01; Thu, 1 Jun 2006 18:36:53 +0200 Received: from master.birnet.private (localhost [127.0.0.1]) by birnet.org (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k51Gaj8T006024 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 1 Jun 2006 18:36:45 +0200 Received: (from timj@localhost) by master.birnet.private (8.13.4/8.13.4/Submit) id k51Gaj0d006023; Thu, 1 Jun 2006 18:36:45 +0200 Date: Thu, 1 Jun 2006 18:36:45 +0200 (CEST) From: Tim Janik X-X-Sender: timj@master.birnet.private To: Michael Natterer In-Reply-To: <1149172764.5721.13.camel@localhost> Message-ID: References: <20060531200823.GA7846@babi-pangang.org> <1149172764.5721.13.camel@localhost> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.439 tagged_above=-999 required=2 tests=[AWL=0.160, BAYES_00=-2.599] X-Spam-Score: -2.439 X-Spam-Level: Cc: Gtk+ Developers , Kristian Rietveld Subject: Re: Tooltips progress X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2006 16:37:26 -0000 On Thu, 1 Jun 2006, Michael Natterer wrote: > On Wed, 2006-05-31 at 22:08 +0200, Kristian Rietveld wrote: > >> Currently, we are using the following query-tooltips signal: >> >> gboolean (*query_tooltip) (GtkWidget *widget, >> gint x, >> gint y, >> GtkTooltip *tooltip); >> >> But if a user sets a custom using gtk_widget_set_custom_window(), we don't >> have to pass a GtkTooltip around. So currently I just set the tooltip >> field to NULL, so the user knows he has to use his own custom tooltip >> window (and we assume he has a reference to that). Is this okay or do >> we want to change this? We could also move the _set_custom_window() >> functions into GtkTooltip for example. > > I would very much appreciate if the GtkTooltip object also kept track > of the custom window. IMHO it makes no sense to handle this differently. the widget is meant to do that: void gtk_widget_set_tooltip_window (GtkWidget *widget, GtkWindow *custom_window); GtkWindow* gtk_widget_get_tooltip_window (GtkWidget *widget); for reasons outlined in a previous reply from me to kris. > gtk_tooltip_set_markup() vs. gtk_tooltip_set_window() > > simply feels much better than the asymmetry in > > gtk_tooltip_set_markup() vs. gtk_widget_set_tooltip_window() well, you'd not use GtkTooltip at all if you used gtk_widget_set_tooltip_window() before. in that way, the "asymmetry" simply reflects your usage. > The current approach even limits the new tooltip system's use cases, > since you have to set the custom window *outside* the callback. There > is no way to decide *in* the callback if a standard tooltip is > sufficient, or if a custom window is needed. i don't think it'd be clear that/if the custom window will be available in the GtkTooltip object again upon the next ::query-tooltip() emission. especially since users are not supposed to access GtkTooltip objects/structures in anyway *outside* of ::query-tooltip(), as outlined originally: http://mail.gnome.org/archives/gtk-devel-list/2006-April/msg00010.html also, passing GtkTooltip as NULL is meant to be as a clear indication that the user has to tinker with gtk_widget_get_tooltip_window() instead of the tooltip object. this avoids ambiguities like: static gboolean query_tooltip (GtkWidget *widget, gint x, gint y, GtkTooltip *tooltip) { gtk_tooltip_set_markup (tooltip, "See Me?"); g_object_new (GTK_TYPE_BUTTON, "parent", gtk_widget_get_tooltip_window(), "label", "Can You Click Me?", NULL); gtk_tooltip_set_icon (tooltip, messup_pixbuf); } what's the tooltip code supposed to do here? and yes, the API basically enforces that you decide per widget if an own tooltip window is needed or not. but i don't think that is a strong limitation, we have been discussing usage cases quite some in thise thread and nothing required to defer this decision into the callback (and no existing tooltip code i know of requires this either). so giving the benefits in API (and implementation) this provides, i think it is a reasonable limitation to make. > Another problem is the assymetry in getting the relevant data to the > callback. With markup, the GtkTooltip can be queried for the markup, > if it's a custom window, you have to get it to the callback somehow. Kris just forgot the getter for the custom window on the widget, so signal handler user_data is left alone. > In your example code it's passed as user_data, but user_data is > often not available since it's needed for other things, so you > have to add a "GtkWidget *tooltip_window" to the "other thing". > If "other thing" is e.g. the application toplevel window, which > of the sub-widget's tooltips should it keep? All of them? People > will in many cases end up attaching the tooltip window to the > widget. > > I also fail to see why the "has-tooltip" property has to be > set to TRUE, even tho a tooltip window was set on the widget. > i think this can be come by if we implement: - gtk_widget_set_tooltip_window() should automatically set: GtkWidget::has-tooltip = (custom_window != NULL || GtkWidget::tooltip-markup != ""); - setting GtkWidget::tooltip-markup should automatically set: GtkWidget::has-tooltip = (custom_window != NULL || GtkWidget::tooltip-markup != ""); right? > ciao, > --mitch > --- ciaoTJ From tkomulai@gmail.com Thu Jun 1 15:14:41 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 5A7023B0D70 for ; Thu, 1 Jun 2006 15:14:41 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31172-10 for ; Thu, 1 Jun 2006 15:14:40 -0400 (EDT) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.174]) by menubar.gnome.org (Postfix) with ESMTP id D35083B0CA3 for ; Thu, 1 Jun 2006 15:14:39 -0400 (EDT) Received: by ug-out-1314.google.com with SMTP id o2so222332uge for ; Thu, 01 Jun 2006 12:14:38 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=pkJ9GUF7tBRSDYTFZk62hCunrEDWh/ETW5JoJhlQx7UdB4QeOLJv/qztCngXO4Co/DiXf7ruqlpPxLBRYMp1hjNHoS2y4j0YEr7klSoN2TI6/rPnna1ZG+sfsuFqJaUK0lPq+fzd8NFeO3Vaf+6D8oJI9g3JXpXVTm3KfKENqYU= Received: by 10.78.47.15 with SMTP id u15mr181197huu; Thu, 01 Jun 2006 12:14:38 -0700 (PDT) Received: by 10.78.41.17 with HTTP; Thu, 1 Jun 2006 12:14:38 -0700 (PDT) Message-ID: <68bd3e050606011214i6c36109chff11c7242268b84@mail.gmail.com> Date: Thu, 1 Jun 2006 22:14:38 +0300 From: "Tommi Komulainen" Sender: tkomulai@gmail.com To: gtk-devel-list@gnome.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20060314132538.GA3526@babi-pangang.org> <443B4A8A.8000302@imendio.com> <20060425103017.GA15762@babi-pangang.org> <20060531183045.GA7564@babi-pangang.org> X-Google-Sender-Auth: 6188435c8e783fb2 X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.792 tagged_above=-999 required=2 tests=[AWL=-0.750, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.558, SPF_PASS=-0.001] X-Spam-Score: -1.792 X-Spam-Level: Subject: Re: Callback based tooltips (Re: New tooltips API, continued) X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2006 19:14:41 -0000 On 6/1/06, Tim Janik wrote: > On Wed, 31 May 2006, Kristian Rietveld wrote: > > > On Tue, Apr 25, 2006 at 03:08:12PM +0200, Soeren Sandmann wrote: > >> I once wrote down how tooltips should behave: > > > > I mostly like the behaviour you described below. > > > >> - Tooltips are too intrusive. The text should be smaller, and > > not sure if this has been raised already... > the font size of the tooltips should be exactly as large as the default > font size (module tooltip markup of course) to avoid reducing usability > of the tooltips in contrast to normal text (labels). As long as the font (and other things) are easily themable, the default values are not as important. And as gtk+ doesn't currently have any kind of design for using different font sizes in different contexts, I'd say the default font is a good default. Until someone comes up with a plan that looks at the bigger picture. -- Tommi Komulainen tommi.komulainen@iki.fi From mclasen@redhat.com Thu Jun 1 19:12:39 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id B0B143B0135 for ; Thu, 1 Jun 2006 19:12:39 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12736-06 for ; Thu, 1 Jun 2006 19:12:36 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id 567E43B0061 for ; Thu, 1 Jun 2006 19:12:36 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k51NCZWS017685 for ; Thu, 1 Jun 2006 19:12:35 -0400 Received: from lacrosse.corp.redhat.com (lacrosse.corp.redhat.com [172.16.52.154]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k51NCZpf020363 for ; Thu, 1 Jun 2006 19:12:35 -0400 Received: from [172.16.83.142] (vpn83-142.boston.redhat.com [172.16.83.142]) by lacrosse.corp.redhat.com (8.12.11.20060308/8.11.6) with ESMTP id k51NCXoG026214 for ; Thu, 1 Jun 2006 19:12:33 -0400 From: Matthias Clasen To: gtk-devel-list@gnome.org Content-Type: multipart/mixed; boundary="=-xjDvOKJb0tdB52kmWdgp" Organization: Red Hat Date: Thu, 01 Jun 2006 19:13:59 -0400 Message-Id: <1149203639.27455.9.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.7.2.1 (2.7.2.1-4) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.466 tagged_above=-999 required=2 tests=[AWL=-0.019, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, TW_GT=0.077, TW_XD=0.077] X-Spam-Score: -2.466 X-Spam-Level: Subject: Print preview api X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2006 23:12:39 -0000 --=-xjDvOKJb0tdB52kmWdgp Content-Type: text/plain Content-Transfer-Encoding: 7bit Ok, after a lot of work (mostly by John and Alex), we finally have a proposal for a print preview api that will allow us to use an external viewer by default, but also support internal preview. It consists of the following pieces: 1) GtkPrintOperation gets a new signal gboolean (*preview) (GtkPrintOperation *operation, GtkPrintOperationPreview *preview, GtkPrintContext *context, GtkWindow *parent); This signal is emitted when the user clicks the preview button. It the application does not handle it, the default handler will arrange for the external viewer to be spawned. An application that handles the preview internally should return TRUE from the signal handler. The GtkPrintOperationPreview that is passed to the signal handler lets the application control the preview. 2) The GtkPrintOperationPreview interface has a number of signals: void (*ready) (GtkPrintOperationPreview *preview, GtkPrintContext *context); The ready signal is emitted when pagination is done. The GtkPrintOperation::preview handler should connect to this signal to know when it is safe to start displaying pages. void (*got_page_size) (GtkPrintOperationPreview *preview, GtkPrintContext *context, GtkPageSetup *page_setup); The got-page-size signal is emitted for every rendered page, when the page setup for the page is know. This signal can be used to adjust the cairo context used for rendering the page (e.g. for resizing the preview window). And methods: void gtk_print_operation_preview_render_page (GtkPrintOperationPreview *preview, gint page_nr) Renders the requested page to the cairo context currently set on the print context for the preview. void gtk_print_operation_preview_end_preview (GtkPrintOperationPreview *preview) Must be called to clean up when the preview is finished. 3) A new way of handling the cairo context associated with a GtkPrintContext. A print context is no longer directly associated with a cairo surface. Instead, a cairo context is set with void gtk_print_context_set_cairo_context (GtkPrintContext *context, cairo_t *cr, double dpi_x, double dpi_y); And this can be repeated, typically in a got-page-size handler. The attached patch against current cvs has a very basic preview implementation in print-editor.c that demonstrates this api. Comments appreciated, Matthias --=-xjDvOKJb0tdB52kmWdgp Content-Disposition: attachment; filename=gtk-print-preview-7.diff Content-Type: text/x-patch; name=gtk-print-preview-7.diff; charset=UTF-8 Content-Transfer-Encoding: 7bit Index: gtk/Makefile.am =================================================================== RCS file: /cvs/gnome/gtk+/gtk/Makefile.am,v retrieving revision 1.308 diff -u -p -r1.308 Makefile.am --- gtk/Makefile.am 22 May 2006 17:19:09 -0000 1.308 +++ gtk/Makefile.am 1 Jun 2006 20:34:39 -0000 @@ -4,6 +4,7 @@ SUBDIRS=theme-bits if OS_UNIX SUBDIRS += xdgmime +GTK_PRINT_PREVIEW_COMMAND="evince %f" endif DIST_SUBDIRS=theme-bits xdgmime @@ -25,6 +26,7 @@ INCLUDES = \ -DGTK_HOST=\"$(host)\" \ -DGTK_COMPILATION \ -DGTK_PRINT_BACKENDS=\"$(GTK_PRINT_BACKENDS)\" \ + -DGTK_PRINT_PREVIEW_COMMAND=\"$(GTK_PRINT_PREVIEW_COMMAND)\" \ -I$(top_builddir)/gtk \ -I$(top_srcdir) -I../gdk \ -I$(top_srcdir)/gdk \ @@ -231,6 +233,7 @@ gtk_public_h_sources = \ gtkpreview.h \ gtkprintcontext.h \ gtkprintoperation.h \ + gtkprintoperationpreview.h \ gtkprintsettings.h \ gtkprivate.h \ gtkprogress.h \ @@ -487,6 +490,7 @@ gtk_c_sources = \ gtkpreview.c \ gtkprintcontext.c \ gtkprintoperation.c \ + gtkprintoperationpreview.c \ gtkprintsettings.c \ gtkprintutils.c \ gtkprogress.c \ Index: gtk/gtkmarshalers.list =================================================================== RCS file: /cvs/gnome/gtk+/gtk/gtkmarshalers.list,v retrieving revision 1.67 diff -u -p -r1.67 gtkmarshalers.list --- gtk/gtkmarshalers.list 22 May 2006 17:19:09 -0000 1.67 +++ gtk/gtkmarshalers.list 1 Jun 2006 20:34:39 -0000 @@ -32,6 +32,7 @@ BOOLEAN:OBJECT,INT,INT,UINT BOOLEAN:OBJECT,STRING,STRING,BOXED BOOLEAN:OBJECT,BOXED BOOLEAN:OBJECT,BOXED,BOXED +BOOLEAN:OBJECT,OBJECT,OBJECT BOOLEAN:OBJECT,STRING,STRING BOOLEAN:INT BOOLEAN:INT,INT Index: gtk/gtkprintbackend.c =================================================================== RCS file: /cvs/gnome/gtk+/gtk/gtkprintbackend.c,v retrieving revision 1.7 diff -u -p -r1.7 gtkprintbackend.c --- gtk/gtkprintbackend.c 1 Jun 2006 05:02:56 -0000 1.7 +++ gtk/gtkprintbackend.c 1 Jun 2006 20:34:39 -0000 @@ -200,7 +200,6 @@ _gtk_print_backend_create (const char *b GtkPrintBackendModule *pb_module; GtkPrintBackend *pb; - /* TODO: make module loading code work */ for (l = loaded_backends; l != NULL; l = l->next) { pb_module = l->data; @@ -255,6 +254,11 @@ gtk_print_backend_initialize (void) GTK_PRINT_BACKENDS, GTK_PARAM_READWRITE)); + gtk_settings_install_property (g_param_spec_string ("gtk-print-preview-command", + P_("Default command to run when displaying a print preview"), + P_("Command to run when displaying a print preview"), + GTK_PRINT_PREVIEW_COMMAND, + GTK_PARAM_READWRITE)); initialized = TRUE; } } Index: gtk/gtkprintbackend.h =================================================================== RCS file: /cvs/gnome/gtk+/gtk/gtkprintbackend.h,v retrieving revision 1.8 diff -u -p -r1.8 gtkprintbackend.h --- gtk/gtkprintbackend.h 24 May 2006 10:50:56 -0000 1.8 +++ gtk/gtkprintbackend.h 1 Jun 2006 20:34:39 -0000 @@ -140,6 +140,9 @@ void gtk_print_backend_print_stre GList * gtk_print_backend_load_modules (void); void gtk_print_backend_destroy (GtkPrintBackend *print_backend); +/* Methods private to gtk */ +GtkPrintBackend * _gtk_print_backend_create (const char *backend_name); + /* Backend-only functions for GtkPrintBackend */ void gtk_print_backend_add_printer (GtkPrintBackend *print_backend, Index: gtk/gtkprintcontext.c =================================================================== RCS file: /cvs/gnome/gtk+/gtk/gtkprintcontext.c,v retrieving revision 1.4 diff -u -p -r1.4 gtkprintcontext.c --- gtk/gtkprintcontext.c 31 May 2006 13:38:10 -0000 1.4 +++ gtk/gtkprintcontext.c 1 Jun 2006 20:34:39 -0000 @@ -40,6 +40,9 @@ struct _GtkPrintContext GtkPageSetup *page_setup; PangoFontMap *fontmap; + gdouble surface_dpi_x; + gdouble surface_dpi_y; + gdouble pixels_per_unit_x; gdouble pixels_per_unit_y; }; @@ -60,8 +63,8 @@ gtk_print_context_finalize (GObject *obj if (context->page_setup) g_object_unref (context->page_setup); - cairo_destroy (context->cr); - + if (context->cr) + cairo_destroy (context->cr); G_OBJECT_CLASS (gtk_print_context_parent_class)->finalize (object); } @@ -83,15 +86,31 @@ gtk_print_context_class_init (GtkPrintCo GtkPrintContext * _gtk_print_context_new (GtkPrintOperation *op) { - GtkPrintOperationPrivate *priv = op->priv; GtkPrintContext *context; context = g_object_new (GTK_TYPE_PRINT_CONTEXT, NULL); context->op = op; - context->cr = cairo_create (priv->surface); + context->cr = NULL; + context->fontmap = pango_cairo_font_map_new (); + + return context; +} + +void +gtk_print_context_set_cairo_context (GtkPrintContext *context, + cairo_t *cr, + double dpi_x, + double dpi_y) +{ + if (context->cr) + cairo_destroy (context->cr); + + context->cr = cairo_reference (cr); + context->surface_dpi_x = dpi_x; + context->surface_dpi_y = dpi_y; - switch (priv->unit) + switch (context->op->priv->unit) { default: case GTK_UNIT_PIXEL: @@ -100,34 +119,31 @@ _gtk_print_context_new (GtkPrintOperatio context->pixels_per_unit_y = 1.0; break; case GTK_UNIT_POINTS: - context->pixels_per_unit_x = priv->dpi_x / POINTS_PER_INCH; - context->pixels_per_unit_y = priv->dpi_y / POINTS_PER_INCH; + context->pixels_per_unit_x = dpi_x / POINTS_PER_INCH; + context->pixels_per_unit_y = dpi_y / POINTS_PER_INCH; break; case GTK_UNIT_INCH: - context->pixels_per_unit_x = priv->dpi_x; - context->pixels_per_unit_y = priv->dpi_y; + context->pixels_per_unit_x = dpi_x; + context->pixels_per_unit_y = dpi_y; break; case GTK_UNIT_MM: - context->pixels_per_unit_x = priv->dpi_x / MM_PER_INCH; - context->pixels_per_unit_y = priv->dpi_y / MM_PER_INCH; + context->pixels_per_unit_x = dpi_x / MM_PER_INCH; + context->pixels_per_unit_y = dpi_y / MM_PER_INCH; break; } cairo_scale (context->cr, context->pixels_per_unit_x, context->pixels_per_unit_y); - context->fontmap = pango_cairo_font_map_new (); /* We use the unit-scaled resolution, as we still want fonts given in points to work */ pango_cairo_font_map_set_resolution (PANGO_CAIRO_FONT_MAP (context->fontmap), - priv->dpi_y / context->pixels_per_unit_y); - - return context; + dpi_y / context->pixels_per_unit_y); } + void _gtk_print_context_rotate_according_to_orientation (GtkPrintContext *context) { - GtkPrintOperationPrivate *priv = context->op->priv; cairo_t *cr = context->cr; cairo_matrix_t matrix; GtkPaperSize *paper_size; @@ -136,9 +152,9 @@ _gtk_print_context_rotate_according_to_o paper_size = gtk_page_setup_get_paper_size (context->page_setup); width = gtk_paper_size_get_width (paper_size, GTK_UNIT_INCH); - width = width * priv->dpi_x / context->pixels_per_unit_x; + width = width * context->surface_dpi_x / context->pixels_per_unit_x; height = gtk_paper_size_get_height (paper_size, GTK_UNIT_INCH); - height = height * priv->dpi_y / context->pixels_per_unit_y; + height = height * context->surface_dpi_y / context->pixels_per_unit_y; switch (gtk_page_setup_get_orientation (context->page_setup)) { @@ -188,8 +204,8 @@ _gtk_print_context_translate_into_margin top = gtk_page_setup_get_top_margin (context->page_setup, GTK_UNIT_INCH); cairo_translate (context->cr, - left * priv->dpi_x / context->pixels_per_unit_x, - top * priv->dpi_y / context->pixels_per_unit_y); + left * context->surface_dpi_x / context->pixels_per_unit_x, + top * context->surface_dpi_y / context->pixels_per_unit_y); } void @@ -272,7 +288,7 @@ gtk_print_context_get_width (GtkPrintCon width = gtk_page_setup_get_page_width (context->page_setup, GTK_UNIT_INCH); /* Really dpi_x? What about landscape? what does dpi_x mean in that case? */ - return width * priv->dpi_x / context->pixels_per_unit_x; + return width * context->surface_dpi_x / context->pixels_per_unit_x; } /** @@ -300,8 +316,8 @@ gtk_print_context_get_height (GtkPrintCo else height = gtk_page_setup_get_page_height (context->page_setup, GTK_UNIT_INCH); - /* Really dpi_x? What about landscape? what does dpi_x mean in that case? */ - return height * priv->dpi_y / context->pixels_per_unit_y; + /* Really dpi_y? What about landscape? what does dpi_y mean in that case? */ + return height * context->surface_dpi_y / context->pixels_per_unit_y; } /** @@ -320,7 +336,7 @@ gtk_print_context_get_dpi_x (GtkPrintCon { g_return_val_if_fail (GTK_IS_PRINT_CONTEXT (context), 0); - return context->op->priv->dpi_x; + return context->surface_dpi_x; } /** @@ -339,7 +355,7 @@ gtk_print_context_get_dpi_y (GtkPrintCon { g_return_val_if_fail (GTK_IS_PRINT_CONTEXT (context), 0); - return context->op->priv->dpi_y; + return context->surface_dpi_y; } /** @@ -376,10 +392,16 @@ PangoContext * gtk_print_context_create_pango_context (GtkPrintContext *context) { PangoContext *pango_context; + cairo_font_options_t *options; g_return_val_if_fail (GTK_IS_PRINT_CONTEXT (context), NULL); pango_context = pango_cairo_font_map_create_context (PANGO_CAIRO_FONT_MAP (context->fontmap)); + + options = cairo_font_options_create (); + cairo_font_options_set_hint_metrics (options, CAIRO_HINT_METRICS_OFF); + pango_cairo_context_set_font_options (pango_context, options); + cairo_font_options_destroy (options); return pango_context; } Index: gtk/gtkprintcontext.h =================================================================== RCS file: /cvs/gnome/gtk+/gtk/gtkprintcontext.h,v retrieving revision 1.3 diff -u -p -r1.3 gtkprintcontext.h --- gtk/gtkprintcontext.h 31 May 2006 13:38:10 -0000 1.3 +++ gtk/gtkprintcontext.h 1 Jun 2006 20:34:39 -0000 @@ -51,6 +51,11 @@ PangoFontMap *gtk_print_context_get_pang PangoContext *gtk_print_context_create_pango_context (GtkPrintContext *context); PangoLayout *gtk_print_context_create_pango_layout (GtkPrintContext *context); +/* Needed for preview implementations */ +void gtk_print_context_set_cairo_context (GtkPrintContext *context, + cairo_t *cr, + double dpi_x, + double dpi_y); G_END_DECLS Index: gtk/gtkprintjob.c =================================================================== RCS file: /cvs/gnome/gtk+/gtk/gtkprintjob.c,v retrieving revision 1.8 diff -u -p -r1.8 gtkprintjob.c --- gtk/gtkprintjob.c 16 May 2006 16:13:48 -0000 1.8 +++ gtk/gtkprintjob.c 1 Jun 2006 20:34:39 -0000 @@ -212,14 +212,14 @@ gtk_print_job_constructor (GType job = GTK_PRINT_JOB (object); priv = job->priv; - g_assert (priv->printer_set && - priv->settings_set && + g_assert (priv->settings_set && priv->page_setup_set); - - _gtk_printer_prepare_for_print (priv->printer, - job, - priv->settings, - priv->page_setup); + + if (priv->printer) + _gtk_printer_prepare_for_print (priv->printer, + job, + priv->settings, + priv->page_setup); return object; } @@ -545,8 +545,12 @@ gtk_print_job_set_property (GObject case GTK_PRINT_JOB_PROP_PRINTER: priv->printer = GTK_PRINTER (g_value_dup_object (value)); - priv->printer_set = TRUE; - priv->backend = g_object_ref (gtk_printer_get_backend (priv->printer)); + + if (priv->printer != NULL) + { + priv->printer_set = TRUE; + priv->backend = g_object_ref (gtk_printer_get_backend (priv->printer)); + } break; case GTK_PRINT_JOB_PROP_PAGE_SETUP: Index: gtk/gtkprintoperation-private.h =================================================================== RCS file: /cvs/gnome/gtk+/gtk/gtkprintoperation-private.h,v retrieving revision 1.11 diff -u -p -r1.11 gtkprintoperation-private.h --- gtk/gtkprintoperation-private.h 1 Jun 2006 12:38:07 -0000 1.11 +++ gtk/gtkprintoperation-private.h 1 Jun 2006 20:34:39 -0000 @@ -46,9 +46,11 @@ struct _GtkPrintOperationPrivate guint print_pages_idle_id; guint show_progress_timeout_id; + GtkPrintContext *print_context; + /* Data for the print job: */ - cairo_surface_t *surface; - gdouble dpi_x, dpi_y; + /* cairo_surface_t *surface; */ + /* gdouble dpi_x, dpi_y; */ GtkPrintPages print_pages; GtkPageRange *page_ranges; @@ -84,11 +86,23 @@ GtkPrintOperationResult _gtk_print_opera GError **error); typedef void (* GtkPrintOperationPrintFunc) (GtkPrintOperation *op, - GtkWindow *parent); + GtkWindow *parent, + gboolean is_preview); void _gtk_print_operation_platform_backend_run_dialog_async (GtkPrintOperation *op, GtkWindow *parent, GtkPrintOperationPrintFunc print_cb); + +void _gtk_print_operation_platform_backend_launch_preview (GtkPrintOperation *op, + GtkWindow *parent, + const char *filename); + +cairo_surface_t *_gtk_print_operation_platform_backend_create_preview_surface (GtkPrintOperation *operation, + gdouble width, + gdouble heigh, + gdouble *dpi_x, + gdouble *dpi_y, + const gchar *target); void _gtk_print_operation_set_status (GtkPrintOperation *op, GtkPrintStatus status, Index: gtk/gtkprintoperation-unix.c =================================================================== RCS file: /cvs/gnome/gtk+/gtk/gtkprintoperation-unix.c,v retrieving revision 1.19 diff -u -p -r1.19 gtkprintoperation-unix.c --- gtk/gtkprintoperation-unix.c 1 Jun 2006 12:38:07 -0000 1.19 +++ gtk/gtkprintoperation-unix.c 1 Jun 2006 20:34:39 -0000 @@ -25,6 +25,9 @@ #include #include #include +#include +#include +#include #include "gtkprintoperation-private.h" #include "gtkmarshal.h" @@ -41,13 +44,17 @@ #include "gtkalias.h" #include "gtkintl.h" - typedef struct { - GtkPrintJob *job; /* the job we are sending to the printer */ - gulong job_status_changed_tag; GtkWindow *parent; /* just in case we need to throw error dialogs */ GMainLoop *loop; gboolean data_sent; + + /* Real printing (not preview: */ + GtkPrintJob *job; /* the job we are sending to the printer */ + cairo_surface_t *surface; + gulong job_status_changed_tag; + + } GtkPrintOperationUnix; typedef struct _PrinterFinder PrinterFinder; @@ -62,21 +69,24 @@ unix_start_page (GtkPrintOperation *op, GtkPrintContext *print_context, GtkPageSetup *page_setup) { + GtkPrintOperationUnix *op_unix; GtkPaperSize *paper_size; cairo_surface_type_t type; double w, h; + op_unix = op->priv->platform_data; + paper_size = gtk_page_setup_get_paper_size (page_setup); w = gtk_paper_size_get_width (paper_size, GTK_UNIT_POINTS); h = gtk_paper_size_get_height (paper_size, GTK_UNIT_POINTS); - type = cairo_surface_get_type (op->priv->surface); + type = cairo_surface_get_type (op_unix->surface); if (type == CAIRO_SURFACE_TYPE_PS) - cairo_ps_surface_set_size (op->priv->surface, w, h); + cairo_ps_surface_set_size (op_unix->surface, w, h); else if (type == CAIRO_SURFACE_TYPE_PDF) - cairo_pdf_surface_set_size (op->priv->surface, w, h); + cairo_pdf_surface_set_size (op_unix->surface, w, h); } static void @@ -102,6 +112,112 @@ op_unix_free (GtkPrintOperationUnix *op_ g_free (op_unix); } +static char * +shell_command_substitute_file (const gchar *cmd, + const gchar *filename) +{ + const char *inptr, *start; + char *result; + GString *final; + + g_return_val_if_fail (cmd != NULL, NULL); + g_return_val_if_fail (filename != NULL, NULL); + + result = NULL; + final = g_string_new (NULL); + + start = inptr = cmd; + + while ((inptr = strchr (inptr, '%')) != NULL) + { + g_string_append_len (final, start, inptr - start); + inptr++; + switch (*inptr) + { + case 'f': + g_string_append (final, filename ? filename : ""); + break; + + case '%': + g_string_append_c (final, '%'); + break; + + default: + g_string_append_c (final, '%'); + if (*inptr) + g_string_append_c (final, *inptr); + break; + } + if (*inptr) + inptr++; + start = inptr; + } + g_string_append (final, start); + + result = final->str; + + g_string_free (final, FALSE); + + return result; +} + +void +_gtk_print_operation_platform_backend_launch_preview (GtkPrintOperation *op, + GtkWindow *parent, + const char *filename) +{ + int argc; + gchar **argv; + gchar *cmd; + gchar *preview_cmd; + GtkSettings *settings; + gchar *quoted_filename; + GdkScreen *screen; + GError *error = NULL; + + settings = gtk_settings_get_default (); + g_object_get (settings, "gtk-print-preview-command", &preview_cmd, NULL); + + quoted_filename = g_shell_quote (filename); + cmd = shell_command_substitute_file (preview_cmd, quoted_filename); + g_shell_parse_argv (cmd, &argc, &argv, &error); + + if (error !=NULL) + goto out; + + if (parent) + screen = gtk_window_get_screen (parent); + else + screen = gdk_screen_get_default (); + + gdk_spawn_on_screen (screen, NULL, argv, NULL, G_SPAWN_SEARCH_PATH, NULL, NULL, NULL, &error); + + out: + if (error != NULL) + { + GtkWidget *edialog; + edialog = gtk_message_dialog_new (parent, + GTK_DIALOG_DESTROY_WITH_PARENT, + GTK_MESSAGE_ERROR, + GTK_BUTTONS_CLOSE, + _("Error launching preview") /* FIXME better text */); + gtk_message_dialog_format_secondary_text (GTK_MESSAGE_DIALOG (edialog), + "%s", error->message); + gtk_window_set_modal (GTK_WINDOW (edialog), TRUE); + g_signal_connect (edialog, "response", + G_CALLBACK (gtk_widget_destroy), NULL); + + gtk_window_present (GTK_WINDOW (edialog)); + + g_error_free (error); + } + + g_free (cmd); + g_free (quoted_filename); + g_free (preview_cmd); + g_strfreev (argv); +} + static void unix_finish_send (GtkPrintJob *job, void *user_data, @@ -129,6 +245,7 @@ unix_finish_send (GtkPrintJob *job, } op_unix->data_sent = TRUE; + if (op_unix->loop) g_main_loop_quit (op_unix->loop); } @@ -140,6 +257,8 @@ unix_end_run (GtkPrintOperation *op, { GtkPrintOperationUnix *op_unix = op->priv->platform_data; + cairo_surface_finish (op_unix->surface); + if (cancelled) return; @@ -147,10 +266,11 @@ unix_end_run (GtkPrintOperation *op, op_unix->loop = g_main_loop_new (NULL, FALSE); /* TODO: Check for error */ - gtk_print_job_send (op_unix->job, - unix_finish_send, - op_unix, NULL, - NULL); + if (op_unix->job != NULL) + gtk_print_job_send (op_unix->job, + unix_finish_send, + op_unix, NULL, + NULL); if (wait) { @@ -253,64 +373,66 @@ finish_print (PrintResponseData *rdata, { GtkPrintOperation *op = rdata->op; GtkPrintOperationPrivate *priv = op->priv; + gboolean is_preview; - priv->start_page = unix_start_page; - priv->end_page = unix_end_page; - priv->end_run = unix_end_run; + g_print ("finish_print\n"); + + is_preview = rdata->result == GTK_PRINT_OPERATION_RESULT_PREVIEW; if (rdata->do_print) { - GtkPrintOperationUnix *op_unix; - gtk_print_operation_set_print_settings (op, settings); - - op_unix = g_new0 (GtkPrintOperationUnix, 1); - op_unix->job = gtk_print_job_new (priv->job_name, - printer, - settings, - page_setup); + op->priv->print_context = _gtk_print_context_new (op); - gtk_print_job_set_track_print_status (op_unix->job, priv->track_print_status); - - rdata->op->priv->surface = gtk_print_job_get_surface (op_unix->job, rdata->error); - if (op->priv->surface == NULL) + if (!is_preview) { - rdata->do_print = FALSE; - op_unix_free (op_unix); - rdata->result = GTK_PRINT_OPERATION_RESULT_ERROR; - goto out; - } - - _gtk_print_operation_set_status (op, gtk_print_job_get_status (op_unix->job), NULL); - op_unix->job_status_changed_tag = - g_signal_connect (op_unix->job, "status-changed", - G_CALLBACK (job_status_changed_cb), op); - - op_unix->parent = rdata->parent; - - priv->dpi_x = 72; - priv->dpi_y = 72; - - priv->platform_data = op_unix; - priv->free_platform_data = (GDestroyNotify) op_unix_free; - - priv->print_pages = op_unix->job->print_pages; - priv->page_ranges = op_unix->job->page_ranges; - priv->num_page_ranges = op_unix->job->num_page_ranges; - - priv->manual_num_copies = op_unix->job->num_copies; - priv->manual_collation = op_unix->job->collate; - priv->manual_reverse = op_unix->job->reverse; - priv->manual_page_set = op_unix->job->page_set; - priv->manual_scale = op_unix->job->scale; - priv->manual_orientation = op_unix->job->rotate_to_orientation; + GtkPrintOperationUnix *op_unix; + cairo_t *cr; + + op_unix = g_new0 (GtkPrintOperationUnix, 1); + priv->platform_data = op_unix; + priv->free_platform_data = (GDestroyNotify) op_unix_free; + op_unix->parent = rdata->parent; + + priv->start_page = unix_start_page; + priv->end_page = unix_end_page; + priv->end_run = unix_end_run; + + op_unix->job = gtk_print_job_new (priv->job_name, + printer, + settings, + page_setup); + gtk_print_job_set_track_print_status (op_unix->job, priv->track_print_status); + /* TODO: handle error */ + op_unix->surface = gtk_print_job_get_surface (op_unix->job, rdata->error); + cr = cairo_create (op_unix->surface); + gtk_print_context_set_cairo_context (op->priv->print_context, + cr, 72, 72); + cairo_destroy (cr); + + _gtk_print_operation_set_status (op, gtk_print_job_get_status (op_unix->job), NULL); + + op_unix->job_status_changed_tag = + g_signal_connect (op_unix->job, "status-changed", + G_CALLBACK (job_status_changed_cb), op); + + priv->print_pages = op_unix->job->print_pages; + priv->page_ranges = op_unix->job->page_ranges; + priv->num_page_ranges = op_unix->job->num_page_ranges; + + priv->manual_num_copies = op_unix->job->num_copies; + priv->manual_collation = op_unix->job->collate; + priv->manual_reverse = op_unix->job->reverse; + priv->manual_page_set = op_unix->job->page_set; + priv->manual_scale = op_unix->job->scale; + priv->manual_orientation = op_unix->job->rotate_to_orientation; + } } - - out: + if (rdata->print_cb) { if (rdata->do_print) - rdata->print_cb (op, rdata->parent); + rdata->print_cb (op, rdata->parent, is_preview); else _gtk_print_operation_set_status (op, GTK_PRINT_STATUS_FINISHED_ABORTED, NULL); } @@ -319,7 +441,7 @@ finish_print (PrintResponseData *rdata, rdata->destroy (rdata); } -static void +static void handle_print_response (GtkWidget *dialog, gint response, gpointer data) @@ -330,6 +452,8 @@ handle_print_response (GtkWidget *dialog GtkPageSetup *page_setup = NULL; GtkPrinter *printer = NULL; + g_print ("handle_print_response\n"); + if (response == GTK_RESPONSE_OK) { rdata->result = GTK_PRINT_OPERATION_RESULT_APPLY; @@ -345,14 +469,24 @@ handle_print_response (GtkWidget *dialog g_signal_emit_by_name (rdata->op, "custom-widget-apply", rdata->op->priv->custom_widget); } + else if (response == GTK_RESPONSE_APPLY) + { + /* print preview */ + rdata->result = GTK_PRINT_OPERATION_RESULT_PREVIEW; + rdata->do_print = TRUE; + settings = gtk_print_unix_dialog_get_settings (GTK_PRINT_UNIX_DIALOG (pd)); + page_setup = gtk_print_unix_dialog_get_page_setup (GTK_PRINT_UNIX_DIALOG (pd)); + } + out: finish_print (rdata, printer, page_setup, settings); if (settings) g_object_unref (settings); - + gtk_widget_destroy (GTK_WIDGET (pd)); + } @@ -436,6 +570,19 @@ _gtk_print_operation_platform_backend_ru } } +cairo_surface_t * +_gtk_print_operation_platform_backend_create_preview_surface (GtkPrintOperation *op, + gdouble width, + gdouble height, + gdouble *dpi_x, + gdouble *dpi_y, + const gchar *target) +{ + g_print ("pdf surface size: %f x %f\n", width, height); + *dpi_x = *dpi_y = 72; + return cairo_pdf_surface_create (target, width, height); +} + GtkPrintOperationResult _gtk_print_operation_platform_backend_run_dialog (GtkPrintOperation *op, GtkWindow *parent, @@ -459,6 +606,7 @@ _gtk_print_operation_platform_backend_ru if (op->priv->show_dialog) { pd = get_print_dialog (op, parent); + response = gtk_dialog_run (GTK_DIALOG (pd)); handle_print_response (pd, response, &rdata); } Index: gtk/gtkprintoperation-win32.c =================================================================== RCS file: /cvs/gnome/gtk+/gtk/gtkprintoperation-win32.c,v retrieving revision 1.9 diff -u -p -r1.9 gtkprintoperation-win32.c --- gtk/gtkprintoperation-win32.c 23 May 2006 16:30:45 -0000 1.9 +++ gtk/gtkprintoperation-win32.c 1 Jun 2006 20:34:39 -0000 @@ -492,6 +492,7 @@ win32_end_run (GtkPrintOperation *op, GlobalFree(op_win32->devmode); GlobalFree(op_win32->devnames); + cairo_surface_finish (op->priv->surface); cairo_surface_destroy (op->priv->surface); op->priv->surface = NULL; Index: gtk/gtkprintoperation.c =================================================================== RCS file: /cvs/gnome/gtk+/gtk/gtkprintoperation.c,v retrieving revision 1.24 diff -u -p -r1.24 gtkprintoperation.c --- gtk/gtkprintoperation.c 1 Jun 2006 12:38:07 -0000 1.24 +++ gtk/gtkprintoperation.c 1 Jun 2006 20:34:39 -0000 @@ -19,6 +19,10 @@ */ #include "config.h" + +#include +#include + #include #include "gtkprintoperation-private.h" #include "gtkmarshalers.h" @@ -41,6 +45,7 @@ enum { STATUS_CHANGED, CREATE_CUSTOM_WIDGET, CUSTOM_WIDGET_APPLY, + PREVIEW, LAST_SIGNAL }; @@ -65,7 +70,15 @@ enum { static guint signals[LAST_SIGNAL] = { 0 }; static int job_nr = 0; -G_DEFINE_TYPE (GtkPrintOperation, gtk_print_operation, G_TYPE_OBJECT) +static void preview_iface_init (GtkPrintOperationPreviewIface *iface); +static GtkPageSetup *create_page_setup (GtkPrintOperation *op); +static void common_render_page (GtkPrintOperation *op, + gint page_nr); + + +G_DEFINE_TYPE_WITH_CODE (GtkPrintOperation, gtk_print_operation, G_TYPE_OBJECT, + G_IMPLEMENT_INTERFACE (GTK_TYPE_PRINT_OPERATION_PREVIEW, + preview_iface_init)) /** * gtk_print_error_quark: @@ -146,6 +159,60 @@ gtk_print_operation_init (GtkPrintOperat } static void +preview_iface_render_page (GtkPrintOperationPreview *preview, + gint page_nr) +{ + GtkPrintOperation *op; + + op = GTK_PRINT_OPERATION (preview); + common_render_page (op, page_nr); +} + +static void +preview_iface_end_preview (GtkPrintOperationPreview *preview) +{ + GtkPrintOperation *op; + + op = GTK_PRINT_OPERATION (preview); + + g_signal_emit (op, signals[END_PRINT], 0, op->priv->print_context); + + if (op->priv->rloop) + g_main_loop_quit (op->priv->rloop); + + op->priv->end_run (op, op->priv->is_sync, TRUE); +} + +static void +preview_iface_init (GtkPrintOperationPreviewIface *iface) +{ + iface->render_page = preview_iface_render_page; + iface->end_preview = preview_iface_end_preview; +} + +static void +preview_start_page (GtkPrintOperation *op, + GtkPrintContext *print_context, + GtkPageSetup *page_setup) +{ + g_signal_emit_by_name (op, "got-page-size",print_context, page_setup); +} + +static void +preview_end_page (GtkPrintOperation *op, + GtkPrintContext *print_context) +{ +} + +static void +preview_end_run (GtkPrintOperation *op, + gboolean wait, + gboolean cancelled) +{ +} + + +static void gtk_print_operation_set_property (GObject *object, guint prop_id, const GValue *value, @@ -256,6 +323,158 @@ gtk_print_operation_get_property (GObjec } } +typedef struct +{ + GtkPrintOperationPreview *preview; + GtkPrintContext *print_context; + GtkWindow *parent; + cairo_surface_t *surface; + gchar *filename; + guint page_nr; + gboolean wait; +} PreviewOp; + +static void +preview_print_idle_done (gpointer data) +{ + GtkPrintOperation *op; + PreviewOp *pop = (PreviewOp *) data; + + op = GTK_PRINT_OPERATION (pop->preview); + + _gtk_print_operation_platform_backend_launch_preview (op, + pop->parent, + pop->filename); + + g_free (pop->filename); + cairo_surface_finish (pop->surface); + cairo_surface_destroy (pop->surface); + + gtk_print_operation_preview_end_preview (pop->preview); + g_free (pop); +} + +static gboolean +preview_print_idle (gpointer data) +{ + PreviewOp *pop; + GtkPrintOperation *op; + gboolean retval = TRUE; + cairo_t *cr; + + GDK_THREADS_ENTER (); + + pop = (PreviewOp *) data; + op = GTK_PRINT_OPERATION (pop->preview); + + gtk_print_operation_preview_render_page (pop->preview, pop->page_nr); + + cr = gtk_print_context_get_cairo_context (pop->print_context); + cairo_show_page (cr); + + /* TODO: print out sheets not pages and follow ranges */ + pop->page_nr++; + if (op->priv->nr_of_pages <= pop->page_nr) + retval = FALSE; + + GDK_THREADS_LEAVE (); + + return retval; +} + +static void +preview_got_page_size (GtkPrintOperationPreview *preview, + GtkPrintContext *context, + GtkPageSetup *page_setup, + PreviewOp *pop) +{ + GtkPrintOperation *op = GTK_PRINT_OPERATION (preview); + GtkPaperSize *paper_size; + double w, h; + + paper_size = gtk_page_setup_get_paper_size (page_setup); + + w = gtk_paper_size_get_width (paper_size, GTK_UNIT_POINTS); + h = gtk_paper_size_get_height (paper_size, GTK_UNIT_POINTS); + + /* TODO: don't hardcode pdf */ + cairo_pdf_surface_set_size (pop->surface, w, h); +} + +static void +preview_ready (GtkPrintOperationPreview *preview, + GtkPrintContext *context, + PreviewOp *pop) +{ + + pop->page_nr = 0; + pop->print_context = context; + + g_idle_add_full (G_PRIORITY_DEFAULT_IDLE, + preview_print_idle, + pop, + preview_print_idle_done); + +} + +/** + * gtk_print_operation_preview_handler: + * + * Default handler for preview operations + **/ +static gboolean +gtk_print_operation_preview_handler (GtkPrintOperation *op, + GtkPrintOperationPreview *preview, + GtkPrintContext *context, + GtkWindow *parent) +{ + gdouble width, height, dpi_x, dpi_y; + gchar *tmp_dir; + gchar *dir_template; + gchar *preview_filename; + PreviewOp *pop; + GtkPrintSettings *settings; + cairo_t *cr; + + dir_template = g_build_filename (g_get_tmp_dir (), "print-preview-XXXXXX", NULL); + + /* use temp dirs because apps like evince need to have extentions + to determine the mine type */ + tmp_dir = mkdtemp(dir_template); + + preview_filename = g_build_filename (tmp_dir, + "Print Preview.pdf", + NULL); + + g_free (dir_template); + + pop = g_new0 (PreviewOp, 1); + pop->filename = preview_filename; + pop->preview = preview; + pop->parent = parent; + + settings = op->priv->print_settings; + + width = gtk_print_settings_get_paper_width (settings, GTK_UNIT_POINTS); + height = gtk_print_settings_get_paper_height (settings, GTK_UNIT_POINTS); + + pop->surface = + _gtk_print_operation_platform_backend_create_preview_surface (op, + width, height, + &dpi_x, &dpi_y, + pop->filename); + + cr = cairo_create (pop->surface); + gtk_print_context_set_cairo_context (op->priv->print_context, cr, + dpi_x, dpi_y); + cairo_destroy (cr); + + g_signal_connect (preview, "ready", (GCallback) preview_ready, pop); + g_signal_connect (preview, "got-page-size", (GCallback) preview_got_page_size, pop); + + return TRUE; +} + static GtkWidget * gtk_print_operation_create_custom_widget (GtkPrintOperation *operation) { @@ -287,7 +506,8 @@ gtk_print_operation_class_init (GtkPrint gobject_class->set_property = gtk_print_operation_set_property; gobject_class->get_property = gtk_print_operation_get_property; gobject_class->finalize = gtk_print_operation_finalize; - + + class->preview = gtk_print_operation_preview_handler; class->create_custom_widget = gtk_print_operation_create_custom_widget; g_type_class_add_private (gobject_class, sizeof (GtkPrintOperationPrivate)); @@ -530,6 +750,33 @@ gtk_print_operation_class_init (GtkPrint g_cclosure_marshal_VOID__OBJECT, G_TYPE_NONE, 1, GTK_TYPE_WIDGET); + /** + * GtkPrintOperation::preview: + * @operation: the #GtkPrintOperation on which the signal was emitted + * @preview: the #GtkPrintPreviewOperation for the current operation + * @context: the #GtkPrintContext that will be used + * @parent: the #GtkWindow to use as window parent, or NULL + * + * Gets emitted when a preview is requested from the native dialog. + * If you handle this you must set the cairo_context on the printing context. + * + * Returns: #TRUE if the listener wants to take over control of the preview + * + * Since: 2.10 + */ + signals[PREVIEW] = + g_signal_new (I_("preview"), + G_TYPE_FROM_CLASS (gobject_class), + G_SIGNAL_RUN_LAST, + G_STRUCT_OFFSET (GtkPrintOperationClass, preview), + _gtk_boolean_handled_accumulator, NULL, + _gtk_marshal_BOOLEAN__OBJECT_OBJECT_OBJECT, + G_TYPE_BOOLEAN, 3, + GTK_TYPE_PRINT_OPERATION_PREVIEW, + GTK_TYPE_PRINT_CONTEXT, + GTK_TYPE_WINDOW); + + /** * GtkPrintOperation:default-page-setup: * @@ -1436,6 +1683,7 @@ pdf_start_page (GtkPrintOperation *op, GtkPageSetup *page_setup) { GtkPaperSize *paper_size; + cairo_surface_t *surface = op->priv->platform_data; double w, h; paper_size = gtk_page_setup_get_paper_size (page_setup); @@ -1443,7 +1691,7 @@ pdf_start_page (GtkPrintOperation *op, w = gtk_paper_size_get_width (paper_size, GTK_UNIT_POINTS); h = gtk_paper_size_get_height (paper_size, GTK_UNIT_POINTS); - cairo_pdf_surface_set_size (op->priv->surface, w, h); + cairo_pdf_surface_set_size (surface, w, h); } static void @@ -1462,9 +1710,10 @@ pdf_end_run (GtkPrintOperation *op, gboolean cancelled) { GtkPrintOperationPrivate *priv = op->priv; + cairo_surface_t *surface = priv->platform_data; - cairo_surface_destroy (priv->surface); - priv->surface = NULL; + cairo_surface_finish (surface); + cairo_surface_destroy (surface); } static GtkPrintOperationResult @@ -1475,6 +1724,8 @@ run_pdf (GtkPrintOperation *op, { GtkPrintOperationPrivate *priv = op->priv; GtkPageSetup *page_setup; + cairo_surface_t *surface; + cairo_t *cr; double width, height; /* This will be overwritten later by the non-default size, but we need to pass some size: */ @@ -1484,13 +1735,19 @@ run_pdf (GtkPrintOperation *op, height = gtk_page_setup_get_paper_height (page_setup, GTK_UNIT_POINTS); g_object_unref (page_setup); - priv->surface = cairo_pdf_surface_create (priv->pdf_target, + surface = cairo_pdf_surface_create (priv->pdf_target, width, height); - cairo_pdf_surface_set_dpi (priv->surface, 300, 300); - - priv->dpi_x = 72; - priv->dpi_y = 72; + cairo_pdf_surface_set_dpi (surface, 300, 300); + + priv->platform_data = surface; + priv->free_platform_data = (GDestroyNotify) cairo_surface_destroy; + cr = cairo_create (surface); + gtk_print_context_set_cairo_context (op->priv->print_context, + cr, 72, 72); + cairo_destroy (cr); + + priv->print_pages = GTK_PRINT_PAGES_ALL; priv->page_ranges = NULL; priv->num_page_ranges = 0; @@ -1524,10 +1781,11 @@ typedef struct gint page, start, end, inc; - GtkPageSetup *initial_page_setup; - GtkPrintContext *print_context; + gboolean initialized; GtkWidget *progress; + + gboolean is_preview; } PrintPagesData; static void @@ -1599,12 +1857,9 @@ print_pages_idle_done (gpointer user_dat if (data->progress) gtk_widget_destroy (data->progress); - g_object_unref (data->print_context); - g_object_unref (data->initial_page_setup); - g_object_unref (data->op); - if (priv->rloop) + if (priv->rloop && !data->is_preview) g_main_loop_quit (priv->rloop); g_free (data); @@ -1640,15 +1895,62 @@ update_progress (PrintPagesData *data) } } +static void +common_render_page (GtkPrintOperation *op, + gint page_nr) +{ + GtkPrintOperationPrivate *priv = op->priv; + GtkPageSetup *page_setup; + GtkPrintContext *print_context; + cairo_t *cr; + + print_context = priv->print_context; + + page_setup = create_page_setup (op); + + g_signal_emit (op, signals[REQUEST_PAGE_SETUP], 0, + print_context, page_nr, page_setup); + + _gtk_print_context_set_page_setup (print_context, page_setup); + + /* TODO: override for preview */ + priv->start_page (op, print_context, page_setup); + + cr = gtk_print_context_get_cairo_context (print_context); + + cairo_save (cr); + if (priv->manual_scale != 1.0) + cairo_scale (cr, + priv->manual_scale, + priv->manual_scale); + + if (priv->manual_orientation) + _gtk_print_context_rotate_according_to_orientation (print_context); + + if (!priv->use_full_page) + _gtk_print_context_translate_into_margin (print_context); + + g_signal_emit (op, signals[DRAW_PAGE], 0, + print_context, page_nr); + + /* TODO: override for preview */ + priv->end_page (op, print_context); + + cairo_restore (cr); + + g_object_unref (page_setup); +} + static gboolean print_pages_idle (gpointer user_data) { PrintPagesData *data; GtkPrintOperationPrivate *priv; GtkPageSetup *page_setup; - cairo_t *cr; gboolean done = FALSE; + g_print ("print_pages_idle\n"); + GDK_THREADS_ENTER (); data = (PrintPagesData*)user_data; @@ -1656,15 +1958,15 @@ print_pages_idle (gpointer user_data) if (priv->status == GTK_PRINT_STATUS_PREPARING) { - if (!data->print_context) + if (!data->initialized) { - data->print_context = _gtk_print_context_new (data->op); - data->initial_page_setup = create_page_setup (data->op); - - _gtk_print_context_set_page_setup (data->print_context, - data->initial_page_setup); + data->initialized = TRUE; + page_setup = create_page_setup (data->op); + _gtk_print_context_set_page_setup (priv->print_context, + page_setup); + g_object_unref (page_setup); - g_signal_emit (data->op, signals[BEGIN_PRINT], 0, data->print_context); + g_signal_emit (data->op, signals[BEGIN_PRINT], 0, priv->print_context); if (priv->manual_collation) { @@ -1684,7 +1986,7 @@ print_pages_idle (gpointer user_data) { gboolean paginated = FALSE; - g_signal_emit (data->op, signals[PAGINATE], 0, data->print_context, &paginated); + g_signal_emit (data->op, signals[PAGINATE], 0, priv->print_context, &paginated); if (!paginated) goto out; } @@ -1751,36 +2053,18 @@ print_pages_idle (gpointer user_data) goto out; } } + + if (data->is_preview) + { + done = TRUE; - page_setup = gtk_page_setup_copy (data->initial_page_setup); - g_signal_emit (data->op, signals[REQUEST_PAGE_SETUP], 0, - data->print_context, data->page, page_setup); - - _gtk_print_context_set_page_setup (data->print_context, page_setup); - priv->start_page (data->op, data->print_context, page_setup); - - cr = gtk_print_context_get_cairo_context (data->print_context); - - cairo_save (cr); - if (priv->manual_scale != 1.0) - cairo_scale (cr, - priv->manual_scale, - priv->manual_scale); - - if (priv->manual_orientation) - _gtk_print_context_rotate_according_to_orientation (data->print_context); - - if (!priv->use_full_page) - _gtk_print_context_translate_into_margin (data->print_context); - - g_signal_emit (data->op, signals[DRAW_PAGE], 0, - data->print_context, data->page); - - priv->end_page (data->op, data->print_context); - - cairo_restore (cr); - - g_object_unref (page_setup); + g_object_ref (data->op); + + g_signal_emit_by_name (data->op, "ready", priv->print_context); + goto out; + } + + common_render_page (data->op, data->page); out: @@ -1791,11 +2075,9 @@ print_pages_idle (gpointer user_data) done = TRUE; } - if (done) + if (done && !data->is_preview) { - g_signal_emit (data->op, signals[END_PRINT], 0, data->print_context); - - cairo_surface_finish (priv->surface); + g_signal_emit (data->op, signals[END_PRINT], 0, priv->print_context); priv->end_run (data->op, priv->is_sync, priv->cancelled); } @@ -1833,15 +2115,19 @@ show_progress_timeout (PrintPagesData *d static void print_pages (GtkPrintOperation *op, - GtkWindow *parent) + GtkWindow *parent, + gboolean is_preview) { GtkPrintOperationPrivate *priv = op->priv; PrintPagesData *data; - + + g_print ("print_pages\n"); + _gtk_print_operation_set_status (op, GTK_PRINT_STATUS_PREPARING, NULL); data = g_new0 (PrintPagesData, 1); data->op = g_object_ref (op); + data->is_preview = is_preview; if (priv->show_progress) { @@ -1862,6 +2148,37 @@ print_pages (GtkPrintOperation *op, data->progress = progress; } + if (is_preview) + { + gboolean handled; + + g_signal_emit_by_name (op, "preview", + GTK_PRINT_OPERATION_PREVIEW (op), + op->priv->print_context, + parent, + &handled); + + if (!handled || + gtk_print_context_get_cairo_context (priv->print_context) == NULL) { + /* TODO: handle error */ + } + + priv->start_page = preview_start_page; + priv->end_page = preview_end_page; + priv->end_run = preview_end_run; + + /* TODO: Do we really need to set these? */ + priv->print_pages = GTK_PRINT_PAGES_ALL; + priv->page_ranges = NULL; + priv->num_page_ranges = 0; + priv->manual_num_copies = 1; + priv->manual_collation = FALSE; + priv->manual_reverse = FALSE; + priv->manual_page_set = GTK_PAGE_SET_ALL; + priv->manual_scale = 1.0; + priv->manual_orientation = TRUE; + } + priv->print_pages_idle_id = g_idle_add_full (G_PRIORITY_DEFAULT_IDLE, print_pages_idle, data, @@ -1877,9 +2194,10 @@ print_pages (GtkPrintOperation *op, GDK_THREADS_LEAVE (); g_main_loop_run (priv->rloop); GDK_THREADS_ENTER (); + + g_main_loop_unref (priv->rloop); + priv->rloop = NULL; } - g_main_loop_unref (priv->rloop); - priv->rloop = NULL; } /** @@ -1964,7 +2282,7 @@ gtk_print_operation_run (GtkPrintOperati &do_print, error); if (do_print) - print_pages (op, parent); + print_pages (op, parent, result == GTK_PRINT_OPERATION_RESULT_PREVIEW); else _gtk_print_operation_set_status (op, GTK_PRINT_STATUS_FINISHED_ABORTED, NULL); @@ -2006,7 +2324,7 @@ gtk_print_operation_run_async (GtkPrintO { run_pdf (op, parent, &do_print, NULL); if (do_print) - print_pages (op, parent); + print_pages (op, parent, FALSE); else _gtk_print_operation_set_status (op, GTK_PRINT_STATUS_FINISHED_ABORTED, NULL); } Index: gtk/gtkprintoperation.h =================================================================== RCS file: /cvs/gnome/gtk+/gtk/gtkprintoperation.h,v retrieving revision 1.10 diff -u -p -r1.10 gtkprintoperation.h --- gtk/gtkprintoperation.h 24 May 2006 16:15:14 -0000 1.10 +++ gtk/gtkprintoperation.h 1 Jun 2006 20:34:39 -0000 @@ -29,6 +29,7 @@ #include "gtkpagesetup.h" #include "gtkprintsettings.h" #include "gtkprintcontext.h" +#include "gtkprintoperationpreview.h" G_BEGIN_DECLS @@ -84,7 +85,13 @@ struct _GtkPrintOperationClass GtkWidget *(*create_custom_widget) (GtkPrintOperation *operation); void (*custom_widget_apply) (GtkPrintOperation *operation, GtkWidget *widget); + + gboolean (*preview) (GtkPrintOperation *operation, + GtkPrintOperationPreview *preview, + GtkPrintContext *context, + GtkWindow *parent); + /* Padding for future expansion */ void (*_gtk_reserved1) (void); void (*_gtk_reserved2) (void); @@ -98,7 +105,8 @@ struct _GtkPrintOperationClass typedef enum { GTK_PRINT_OPERATION_RESULT_ERROR, GTK_PRINT_OPERATION_RESULT_APPLY, - GTK_PRINT_OPERATION_RESULT_CANCEL + GTK_PRINT_OPERATION_RESULT_CANCEL, + GTK_PRINT_OPERATION_RESULT_PREVIEW } GtkPrintOperationResult; #define GTK_PRINT_ERROR gtk_print_error_quark () Index: gtk/gtkprintoperationpreview.c =================================================================== RCS file: gtk/gtkprintoperationpreview.c diff -N gtk/gtkprintoperationpreview.c --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ gtk/gtkprintoperationpreview.c 1 Jun 2006 20:34:39 -0000 @@ -0,0 +1,107 @@ +/* GTK - The GIMP Toolkit + * gtkprintoperationpreview.c: Abstract print preview interface + * Copyright (C) 2006, Red Hat, Inc. + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2 of the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library; if not, write to the + * Free Software Foundation, Inc., 59 Temple Place - Suite 330, + * Boston, MA 02111-1307, USA. + */ + +#include "config.h" + +#include "gtkprintoperationpreview.h" +#include "gtkmarshalers.h" +#include "gtkintl.h" + +static void gtk_print_operation_preview_base_init (gpointer g_iface); + +GType +gtk_print_operation_preview_get_type (void) +{ + static GType print_operation_preview_type = 0; + + if (!print_operation_preview_type) + { + static const GTypeInfo print_operation_preview_info = + { + sizeof (GtkPrintOperationPreviewIface), /* class_size */ + gtk_print_operation_preview_base_init, /* base_init */ + NULL, /* base_finalize */ + NULL, + NULL, /* class_finalize */ + NULL, /* class_data */ + 0, + 0, /* n_preallocs */ + NULL + }; + + print_operation_preview_type = + g_type_register_static (G_TYPE_INTERFACE, I_("GtkPrintOperationPreview"), + &print_operation_preview_info, 0); + + g_type_interface_add_prerequisite (print_operation_preview_type, G_TYPE_OBJECT); + } + + return print_operation_preview_type; +} + +static void +gtk_print_operation_preview_base_init (gpointer g_iface) +{ + static gboolean initialized = FALSE; + + if (!initialized) + { + g_signal_new (I_("ready"), + GTK_TYPE_PRINT_OPERATION_PREVIEW, + G_SIGNAL_RUN_LAST, + G_STRUCT_OFFSET (GtkPrintOperationPreviewIface, ready), + NULL, NULL, + g_cclosure_marshal_VOID__OBJECT, + G_TYPE_NONE, 1, + G_TYPE_OBJECT); + + g_signal_new (I_("got-page-size"), + GTK_TYPE_PRINT_OPERATION_PREVIEW, + G_SIGNAL_RUN_LAST, + G_STRUCT_OFFSET (GtkPrintOperationPreviewIface, ready), + NULL, NULL, + _gtk_marshal_VOID__OBJECT_OBJECT, + G_TYPE_NONE, 2, + GTK_TYPE_PRINT_CONTEXT, + GTK_TYPE_PAGE_SETUP); + + initialized = TRUE; + } +} + + +void +gtk_print_operation_preview_render_page (GtkPrintOperationPreview *preview, + gint page_nr) +{ + g_return_if_fail (GTK_IS_PRINT_OPERATION_PREVIEW (preview)); + + GTK_PRINT_OPERATION_PREVIEW_GET_IFACE (preview)->render_page (preview, + page_nr); +} + +void +gtk_print_operation_preview_end_preview (GtkPrintOperationPreview *preview) +{ + g_return_if_fail (GTK_IS_PRINT_OPERATION_PREVIEW (preview)); + + GTK_PRINT_OPERATION_PREVIEW_GET_IFACE (preview)->end_preview (preview); +} + Index: gtk/gtkprintoperationpreview.h =================================================================== RCS file: gtk/gtkprintoperationpreview.h diff -N gtk/gtkprintoperationpreview.h --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ gtk/gtkprintoperationpreview.h 1 Jun 2006 20:34:39 -0000 @@ -0,0 +1,75 @@ +/* GTK - The GIMP Toolkit + * gtkprintoperationpreview.h: Abstract print preview interface + * Copyright (C) 2006, Red Hat, Inc. + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2 of the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library; if not, write to the + * Free Software Foundation, Inc., 59 Temple Place - Suite 330, + * Boston, MA 02111-1307, USA. + */ + +#ifndef __GTK_PRINT_OPERATION_PREVIEW_H__ +#define __GTK_PRINT_OPERATION_PREVIEW_H__ + +#include +#include + +#include "gtkprintcontext.h" + +G_BEGIN_DECLS + +#define GTK_TYPE_PRINT_OPERATION_PREVIEW (gtk_print_operation_preview_get_type ()) +#define GTK_PRINT_OPERATION_PREVIEW(obj) (G_TYPE_CHECK_INSTANCE_CAST ((obj), GTK_TYPE_PRINT_OPERATION_PREVIEW, GtkPrintOperationPreview)) +#define GTK_IS_PRINT_OPERATION_PREVIEW(obj) (G_TYPE_CHECK_INSTANCE_TYPE ((obj), GTK_TYPE_PRINT_OPERATION_PREVIEW)) +#define GTK_PRINT_OPERATION_PREVIEW_GET_IFACE(obj) (G_TYPE_INSTANCE_GET_INTERFACE ((obj), GTK_TYPE_PRINT_OPERATION_PREVIEW, GtkPrintOperationPreviewIface)) + +typedef struct _GtkPrintOperationPreview GtkPrintOperationPreview; /*dummy typedef */ +typedef struct _GtkPrintOperationPreviewIface GtkPrintOperationPreviewIface; + + +struct _GtkPrintOperationPreviewIface +{ + GTypeInterface g_iface; + + /* signals */ + void (*ready) (GtkPrintOperationPreview *preview, + GtkPrintContext *context); + void (*got_page_size) (GtkPrintOperationPreview *preview, + GtkPrintContext *context, + GtkPageSetup *page_setup); + + /* methods */ + void (*render_page) (GtkPrintOperationPreview *preview, + gint page_nr); + void (*end_preview) (GtkPrintOperationPreview *preview); + + /* Padding for future expansion */ + void (*_gtk_reserved1) (void); + void (*_gtk_reserved2) (void); + void (*_gtk_reserved3) (void); + void (*_gtk_reserved4) (void); + void (*_gtk_reserved5) (void); + void (*_gtk_reserved6) (void); + void (*_gtk_reserved7) (void); +}; + +GType gtk_print_operation_preview_get_type (void) G_GNUC_CONST; + +void gtk_print_operation_preview_render_page (GtkPrintOperationPreview *preview, + gint page_nr); +void gtk_print_operation_preview_render_sheet (GtkPrintOperationPreview *preview, + gint page_nr); +void gtk_print_operation_preview_end_preview (GtkPrintOperationPreview *preview); + + +#endif /* __GTK_PRINT_OPERATION_PREVIEW_H__ */ Index: gtk/gtkprintunixdialog.c =================================================================== RCS file: /cvs/gnome/gtk+/gtk/gtkprintunixdialog.c,v retrieving revision 1.22 diff -u -p -r1.22 gtkprintunixdialog.c --- gtk/gtkprintunixdialog.c 1 Jun 2006 04:58:18 -0000 1.22 +++ gtk/gtkprintunixdialog.c 1 Jun 2006 20:34:39 -0000 @@ -275,7 +275,8 @@ gtk_print_unix_dialog_init (GtkPrintUnix (GCallback) gtk_print_unix_dialog_destroy, NULL); - gtk_dialog_add_buttons (GTK_DIALOG (dialog), + gtk_dialog_add_buttons (GTK_DIALOG (dialog), + GTK_STOCK_PRINT_PREVIEW, GTK_RESPONSE_APPLY, GTK_STOCK_CANCEL, GTK_RESPONSE_CANCEL, GTK_STOCK_PRINT, GTK_RESPONSE_OK, NULL); Index: tests/print-editor.c =================================================================== RCS file: /cvs/gnome/gtk+/tests/print-editor.c,v retrieving revision 1.7 diff -u -p -r1.7 print-editor.c --- tests/print-editor.c 31 May 2006 14:06:02 -0000 1.7 +++ tests/print-editor.c 1 Jun 2006 20:34:39 -0000 @@ -262,6 +262,7 @@ begin_print (GtkPrintOperation *operatio int num_lines; int line; + g_print ("begin-print\n"); width = gtk_print_context_get_width (context); height = gtk_print_context_get_height (context); @@ -304,6 +305,7 @@ begin_print (GtkPrintOperation *operatio print_data->page_breaks = page_breaks; + g_print ("found %d pages\n", g_list_length (page_breaks)); } static void @@ -317,6 +319,9 @@ draw_page (GtkPrintOperation *operation, int start, end, i; PangoLayoutIter *iter; double start_pos; + + g_print ("draw-page %d\n", page_nr); + if (page_nr == 0) start = 0; else @@ -430,17 +435,205 @@ custom_widget_apply (GtkPrintOperation * data->font = g_strdup (selected_font); } +typedef struct +{ + GtkPrintOperation *op; + GtkPrintOperationPreview *preview; + GtkWidget *spin; + GtkWidget *area; + gint page; + PrintData *data; + gdouble dpi_x, dpi_y; +} PreviewOp; + +static gboolean +preview_expose (GtkWidget *widget, + GdkEventExpose *event, + gpointer data) +{ + PreviewOp *pop = data; + + gdk_window_clear (pop->area->window); + gtk_print_operation_preview_render_page (pop->preview, + pop->page - 1); + + return TRUE; +} + +static void +preview_ready (GtkPrintOperationPreview *preview, + GtkPrintContext *context, + gpointer data) +{ + PreviewOp *pop = data; + gint n_pages; + + g_object_get (pop->op, "n-pages", &n_pages, NULL); + g_print ("ready to preview %d pages\n", n_pages); + + gtk_spin_button_set_range (GTK_SPIN_BUTTON (pop->spin), + 1.0, n_pages); + + g_signal_connect (pop->area, "expose_event", + G_CALLBACK (preview_expose), + pop); + + gtk_widget_queue_draw (pop->area); +} + +static void +preview_got_page_size (GtkPrintOperationPreview *preview, + GtkPrintContext *context, + GtkPageSetup *page_setup, + gpointer data) +{ + PreviewOp *pop = data; + GtkPaperSize *paper_size; + double w, h; + cairo_t *cr; + gdouble dpi_x, dpi_y; + + paper_size = gtk_page_setup_get_paper_size (page_setup); + + w = gtk_paper_size_get_width (paper_size, GTK_UNIT_INCH); + h = gtk_paper_size_get_height (paper_size, GTK_UNIT_INCH); + + cr = gdk_cairo_create (pop->area->window); + + dpi_x = pop->area->allocation.width/w; + dpi_y = pop->area->allocation.height/h; + + g_print ("new dpi: %f, %f\n", dpi_x, dpi_y); + if (fabs (dpi_x - pop->dpi_x) > 0.001 || + fabs (dpi_y - pop->dpi_y) > 0.001) + { + gtk_print_context_set_cairo_context (context, cr, dpi_x, dpi_y); + pop->dpi_x = dpi_x; + pop->dpi_y = dpi_y; + } + + pango_cairo_update_layout (cr, pop->data->layout); + cairo_destroy (cr); +} + +static void +update_page (GtkSpinButton *widget, + gpointer data) +{ + PreviewOp *pop = data; + + pop->page = gtk_spin_button_get_value_as_int (widget); + g_print ("go to page %d\n", pop->page); + gtk_widget_queue_draw (pop->area); +} + +static void +preview_destroy (GtkWindow *window, + PreviewOp *pop) +{ + gtk_print_operation_preview_end_preview (pop->preview); + g_object_unref (pop->op); + + g_free (pop); +} + +static gboolean +do_preview (GtkPrintOperation *op, + GtkPrintOperationPreview *preview, + GtkPrintContext *context, + GtkWindow *parent, + gpointer data) +{ + GtkPrintSettings *settings; + GtkWidget *window, *close, *page, *hbox, *vbox, *da; + gdouble width, height; + cairo_t *cr; + PreviewOp *pop; + PrintData *print_data = data; + + pop = g_new0 (PreviewOp, 1); + + pop->data = print_data; + settings = gtk_print_operation_get_print_settings (op); + +#if 0 + /* FIXME need to figure out the size */ + width = gtk_print_settings_get_paper_width (settings, GTK_UNIT_PIXEL); + height = gtk_print_settings_get_paper_height (settings, GTK_UNIT_PIXEL); + + g_print ("%f x %f\n", width, height); +#endif + width = 200; + height = 300; + window = gtk_window_new (GTK_WINDOW_TOPLEVEL); + gtk_window_set_transient_for (GTK_WINDOW (window), + GTK_WINDOW (main_window)); + vbox = gtk_vbox_new (FALSE, 0); + gtk_container_add (GTK_CONTAINER (window), vbox); + hbox = gtk_hbox_new (FALSE, 0); + gtk_box_pack_start (GTK_BOX (vbox), hbox, + FALSE, FALSE, 0); + page = gtk_spin_button_new_with_range (1, 100, 1); + gtk_box_pack_start (GTK_BOX (hbox), page, FALSE, FALSE, 0); + + close = gtk_button_new_from_stock (GTK_STOCK_CLOSE); + gtk_box_pack_start (GTK_BOX (hbox), close, FALSE, FALSE, 0); + + da = gtk_drawing_area_new (); + gtk_widget_set_size_request (GTK_WIDGET (da), width, height); + gtk_box_pack_start (GTK_BOX (vbox), da, TRUE, TRUE, 0); + + gtk_widget_set_double_buffered (da, FALSE); + + gtk_widget_realize (da); + + cr = gdk_cairo_create (da->window); + + /* TODO: What dpi to use here? This will be used for pagination.. */ + gtk_print_context_set_cairo_context (context, cr, 72, 72); + cairo_destroy (cr); + + pop->op = op; + pop->preview = preview; + pop->spin = page; + pop->area = da; + pop->page = 1; + + g_signal_connect (page, "value-changed", + G_CALLBACK (update_page), pop); + g_signal_connect_swapped (close, "clicked", + G_CALLBACK (gtk_widget_destroy), window); + + g_signal_connect (preview, "ready", + G_CALLBACK (preview_ready), pop); + g_signal_connect (preview, "got-page-size", + G_CALLBACK (preview_got_page_size), pop); + + g_signal_connect (window, "destroy", + G_CALLBACK (preview_destroy), pop); + + gtk_widget_show_all (window); + + return TRUE; +} + +/* FIXME had to move this to the heap, since previewing + * returns too early from the sync api + */ +PrintData *print_data; + static void do_print (GtkAction *action) { GtkWidget *error_dialog; GtkPrintOperation *print; - PrintData print_data; GtkPrintOperationResult res; GError *error; - print_data.text = get_text (); - print_data.font = g_strdup ("Sans 12"); + print_data = g_new0 (PrintData, 1); + + print_data->text = get_text (); + print_data->font = g_strdup ("Sans 12"); print = gtk_print_operation_new (); @@ -452,12 +645,15 @@ do_print (GtkAction *action) if (page_setup != NULL) gtk_print_operation_set_default_page_setup (print, page_setup); - g_signal_connect (print, "begin_print", G_CALLBACK (begin_print), &print_data); - g_signal_connect (print, "draw_page", G_CALLBACK (draw_page), &print_data); - g_signal_connect (print, "create_custom_widget", G_CALLBACK (create_custom_widget), &print_data); - g_signal_connect (print, "custom_widget_apply", G_CALLBACK (custom_widget_apply), &print_data); - + g_signal_connect (print, "begin_print", G_CALLBACK (begin_print), print_data); + g_signal_connect (print, "draw_page", G_CALLBACK (draw_page), print_data); + g_signal_connect (print, "create_custom_widget", G_CALLBACK (create_custom_widget), print_data); + g_signal_connect (print, "custom_widget_apply", G_CALLBACK (custom_widget_apply), print_data); + g_signal_connect (print, "preview", G_CALLBACK (do_preview), print_data); + error = NULL; + +#if 1 res = gtk_print_operation_run (print, GTK_WINDOW (main_window), &error); if (res == GTK_PRINT_OPERATION_RESULT_ERROR) @@ -467,7 +663,7 @@ do_print (GtkAction *action) GTK_MESSAGE_ERROR, GTK_BUTTONS_CLOSE, "Error printing file:\n%s", - error->message); + error ? error->message : "no details"); g_signal_connect (error_dialog, "response", G_CALLBACK (gtk_widget_destroy), NULL); gtk_widget_show (error_dialog); g_error_free (error); @@ -489,10 +685,15 @@ do_print (GtkAction *action) g_signal_connect (print, "status_changed", G_CALLBACK (status_changed_cb), NULL); } +#else + gtk_print_operation_run_async (print, GTK_WINDOW (main_window)); +#endif g_object_unref (print); +#if 0 g_free (print_data.text); g_free (print_data.font); +#endif } static void --=-xjDvOKJb0tdB52kmWdgp-- From tomasek@ebed.etf.cuni.cz Fri Jun 2 03:11:55 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 2F96F3B01C7 for ; Fri, 2 Jun 2006 03:11:55 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05061-05 for ; Fri, 2 Jun 2006 03:11:53 -0400 (EDT) Received: from ebed.etf.cuni.cz (ebed.etf.cuni.cz [195.113.5.3]) by menubar.gnome.org (Postfix) with ESMTP id 3EDBD3B011A for ; Fri, 2 Jun 2006 03:11:53 -0400 (EDT) Received: from ebed.etf.cuni.cz (localhost.localdomain [127.0.0.1]) by ebed.etf.cuni.cz (8.12.11.20060308/8.12.11) with ESMTP id k5270gLE004827 for ; Fri, 2 Jun 2006 09:00:42 +0200 Received: (from tomasek@localhost) by ebed.etf.cuni.cz (8.12.11.20060308/8.12.11/Submit) id k5270gdU004825 for gtk-devel-list@gnome.org; Fri, 2 Jun 2006 09:00:42 +0200 Date: Fri, 2 Jun 2006 09:00:42 +0200 From: Petr Tomasek To: gtk-devel-list@gnome.org Message-ID: <20060602070042.GA3470@ebed.etf.cuni.cz> References: <1149203639.27455.9.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1149203639.27455.9.camel@localhost.localdomain> User-Agent: Mutt/1.4.1i X-Homepage: http://www.etf.cuni.cz/~tomasek/ X-Echelon: bomb Arafat Intifada bus kach drugs mafia boss heroin spy Semtex Saddam Al-Qaida Usama bin Ladin Bush Sharon X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.534 tagged_above=-999 required=2 tests=[AWL=0.065, BAYES_00=-2.599] X-Spam-Score: -2.534 X-Spam-Level: Subject: Re: Print preview api X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 07:11:55 -0000 On Thu, Jun 01, 2006 at 07:13:59PM -0400, Matthias Clasen wrote: > Ok, after a lot of work (mostly by John and Alex), > we finally have a proposal for a print preview > api that will allow us to use an external viewer > by default, but also support internal preview. Hi! I think, this is very unfortunate. Many people will not want to use the external viewer (for reasons discused earlier), so everyone will write his own preview widget? Why not just have official internal preview widget like gnome-print has and support it by deafult? P.T. -- Petr Tomasek From shree_poroly@yahoo.com Fri Jun 2 06:49:17 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id DD9063B03E7 for ; Fri, 2 Jun 2006 06:49:10 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19278-08 for ; Fri, 2 Jun 2006 06:49:06 -0400 (EDT) Received: from web53308.mail.yahoo.com (web53308.mail.yahoo.com [206.190.49.98]) by menubar.gnome.org (Postfix) with SMTP id 574673B110A for ; Fri, 2 Jun 2006 06:48:56 -0400 (EDT) Received: (qmail 1625 invoked by uid 60001); 2 Jun 2006 10:48:55 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=opsX4ZJJjJ3RSp61u8057G5DaMkib9ROhHy+AzeYX+l7J8HSwJa+UppJPxFDKOjVDg5ivFj+xumB8simRH1oUSf2tMk9h8YEuyY6OEPoTApYincgsxe7YmLfJe3+jDCaLeD7TV1kXmnpIstEupgel4fQt9kXW1CGDMkwXy+xReA= ; Message-ID: <20060602104855.1623.qmail@web53308.mail.yahoo.com> Received: from [61.246.61.209] by web53308.mail.yahoo.com via HTTP; Fri, 02 Jun 2006 03:48:55 PDT Date: Fri, 2 Jun 2006 03:48:55 -0700 (PDT) From: shree nidhi To: gtk dev MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-596188450-1149245335=:1049" Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=1.399 tagged_above=-999 required=2 tests=[AWL=-3.076, BAYES_50=0.001, DNS_FROM_RFC_ABUSE=0.2, DNS_FROM_RFC_WHOIS=1.447, HTML_40_50=0.496, HTML_IMAGE_ONLY_12=1.867, HTML_IMAGE_RATIO_02=0.463, HTML_MESSAGE=0.001] X-Spam-Score: 1.399 X-Spam-Level: * Subject: Fwd: test X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 10:49:17 -0000 --0-596188450-1149245335=:1049 Content-Type: multipart/alternative; boundary="0-601274911-1149245335=:1049" --0-601274911-1149245335=:1049 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Note: forwarded message attached. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --0-601274911-1149245335=:1049 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit

Note: forwarded message attached.

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com --0-601274911-1149245335=:1049-- --0-596188450-1149245335=:1049 Content-Type: message/rfc822 X-Apparently-To: shree_poroly@yahoo.com via 206.190.49.100; Thu, 01 Jun 2006 21:38:26 -0700 X-Originating-IP: [202.71.129.68] Authentication-Results: mta129.mail.mud.yahoo.com from=galieosoft.com; domainkeys=neutral (no sig) Received: from 202.71.129.68 (EHLO smx1.net4india.com) (202.71.129.68) by mta129.mail.mud.yahoo.com with SMTP; Thu, 01 Jun 2006 21:38:26 -0700 Received: from [125.22.33.12] by smx1.net4india.com with smtp (Exim 4.51) id 1Fm1a8-00025h-AB; Fri, 02 Jun 2006 10:18:21 +0530 OM-Header: origin=omniqube Received: from unknown (192.168.0.89) by SMTP-Receiver; Fri, 2 Jun 2006 10:07:06 +0530 Subject: test From: Nidhi To: nidhi@galieosoft.com, shree_poroly@yahoo.com Content-Type: multipart/mixed; boundary="=-k0bJJnk7Qaq1V0+G97NB" Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-1) Date: Fri, 02 Jun 2006 10:12:00 +0530 Content-Length: 21206 --=-k0bJJnk7Qaq1V0+G97NB Content-Type: multipart/alternative; boundary="=-rVG5rqf50PHPN/AXL0Ln" --=-rVG5rqf50PHPN/AXL0Ln Content-Type: text/plain Content-Transfer-Encoding: 7bit I have developed an application for an handheld device, the initial window will look like this : But the device is having rectangular display if i place the window as it is my drawing area will look compressed, so i dont want to compress my drawing area. If i can tilt the window and display i hope my drawing area will look like enlarged. Is there any way to tilt an application window as shown please help me out. --=-rVG5rqf50PHPN/AXL0Ln Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
I have developed an application for an handheld device, the initial window will look like this :









But the device is having rectangular display if i place the window as it is my drawing area will look compressed, so i dont want to compress my drawing area. If i can tilt the window and display i hope my drawing area will look like enlarged.







Is there any way to tilt an application window as shown please help me out.


--=-rVG5rqf50PHPN/AXL0Ln-- --=-k0bJJnk7Qaq1V0+G97NB Content-Disposition: attachment; filename=test1.map Content-Type: application/octet-stream; name=test1.map Content-Transfer-Encoding: 7bit --=-k0bJJnk7Qaq1V0+G97NB Content-Disposition: attachment; filename=test2.map Content-Type: application/octet-stream; name=test2.map Content-Transfer-Encoding: 7bit --=-k0bJJnk7Qaq1V0+G97NB Content-Disposition: attachment; filename=wintilt.sxw Content-Type: application/vnd.sun.xml.writer; name=wintilt.sxw Content-Transfer-Encoding: base64 UEsDBBQAAAAAAJZQwTSAkGt+mxsAAJsbAAAtAAAAUGljdHVyZXMvMTAwMDAyMDEwMDAwMDEzNzAw MDAwMTM0REUzMjdBMTMucG5niVBORw0KGgoAAAANSUhEUgAAATcAAAE0CAYAAABJtnScAAAABHNC SVQICAgIfAhkiAAAABV0RVh0U29mdHdhcmUARXllIG9mIEdub21lCx+PrwAAGzFJREFUeJzt3X1w XOVh7/Hfvmglr23ZMS/BAWNbmBcrYPOSmCQ0kUMgwYQyIS+9uDdphyZtYzFzk6bJVWZaT5JbXXqH zjT3TlM70Et7XQ+95OIggkOhxAnrtBjiYBAGS7Zky/KLkLEl68162Zdzzv1jdY53VytZu9rVrh5/ PzMaafe8PUe757fPeZ7nnPVJcoQ5o2phtQLBoIb7zqY97/f7S1QioPzYtq2gJLUeP65jp8+oZ2BA I9FYqcuFHLR3dWn3rl165I+/qurqas2bN08VFRWEHS5Kw8PDuu222yQpGW7HTp/RL99sLmmhkJ+9 e/cqeu6cBgcHFQ6HFQwGVVlZqWAwmHX+eDw+5fp8Pp/3t9/v9x47jiPbtuU4U1f0Z7p8IaSWYap5 UuebbBm3vJP9Lib2Y6LJyu++1/r6+7zHQUk609+ffPM5jvzTKAjKh+M4io+NanR0VJZlye/3q7Ky UhUVFZLST1dt21ZVVZUcx5HjOGlvKPfNMZ03IlBuotGogsGgomNR77mgJA2NjimWSMhxHAXGD4Zd zzbJTiRkJRJy3E9cx5HcN3/G3z6/Xz6/Xxse3Di7e3URsx1HtmUpOjysnp4eLViwQBUVFXIcR6FQ SBUVFV7ISclaWzwel2VZXrgFAgFvvmAwmFbbAqbrBz/4gWKxmOLxuBKJxJS1dJ/Pl6xZBYN69NFH C7L82NiYqqqqNDY25s0XlKR4IqGEZcm2HVl+W5KUiMX01P/+Bx1+t1vv9fVraHR0yp07fvq0Xvjn bYolEjn+WzAjjqPoyIh+9PQOVS2sVmU4rGBlpQIVFfrhw5tUVVWlYDCoh//u72UnEkrEYrIty/tw 8gcC+uHDmzR//nxvXtrrkKvh4WE9/vjj055/3759euSRR3Tu3LmCLH/69GktXLhQI8PD3jxBSUpY luIJS5ZtezU3Kx7XoZNdemnfmxNOVbOdvr75H/+u6MiI4glr2gXMxcZP1mk0GtWze14ryvoLvb3N //lBLZo/X99+/IkClyzd6rU364H77kt77uCJk3o98rK6urq0ePFiVVRUKDYyoi3f26yO7lN6r69f w2Njajl+Qm/sjqirq0uXXHKJFi5cqKqqKgUCgaKWGeYZHa/8dHZ2Tmv+nTt3qr+/31tupsufPXtW Pp9PwyMj3jxBSYolEorG40pYloLjb2w7kdDx02cUz1ITc09pUtmWpUR0TNGMButt3/mWJKntZJf+ +//9iff81++7Vx9dfYOOnz6jzdu2X3BnPrl2jfrOndNPdv/7tHY+1Z9/8QGtWblS3/mHf9Tp/n5J 0lc+dafuuvVm/d3Pdur1tnZJ0t233qIvfvwOPfyjrTPaniQtmDdP1eHwhP9HMbzVcTTtcfv+tzQ6 OKCenh75fD5VVVUpEY2q7WSXdr62N+t8qaems9HIDLO4HVUX6rBKNTIyosR4vmQuf91116mtrS1t /sznUpcfGRnRggULstfcYu6p6fgb27Ys9Z87p2g8ntbj5fP50t787jTbtmUnEpOell575QdUWVGh odFRBQMBra1ZmVynnGmdym7860cvOM9k9nd0as3Klbph2VU62dMjSfrgiqu9cu1paZUk3bRyhfYf 7dRINDqj7UnJsz5Js3Kanvl6OLat2MiIBgYGFA6HZdu2ErGYTvb0euVxxtvr3Pmqq6sVDofT2unc Dgba4HAhlpU8Y0vk8H6PxWKybXvC8rW1tZKSYdbS0iJJWZ9LXd5tSx5JaT7zam5j420xCbfmZlmK xuNT1jz8Pt/5MEwkZFuWxmITx8n1DA7q0upq3bhiuV5+a7/W1tQoFo8rXFkpx3E0Fovp0upq/ZcH 7tc1S5dqXiikd3vP6p9e+oX2tR+WJDV97y/VOzSkr/3t/0p7/I8vvqSv3vNphSsr9c+7fqUXfvv6 hO2/3tauL3/qk/rg8qv189/s1WWLFmnpkiWSpBuWXaWxWEyVFRWqXX61Hnv+BY3FYjlvryIQ0B/d 82l94qYbFa6s9LY9FovJJ+l3P3K77l33IV26aJF6Bgb0r3tf187f7JXjOPq9uo9r4/o6ffvxJ3Sk u1t/9vnP6RM33aiGJ/5JbSe79J0vfUFDIyP68fMvTPo6uNxOhkQ06oVbNBpVIhrV2aGhtNfHGQ+9 oaEhDQ4OKhQKeZ0RwWDQq8kRcLgQ9wM2l3CzbdsLp9Tl9+/frzVr1kg6H2qu/fv3e9tIXd6yLNm2 PbFDQUq2sdmWJcfdmG0rlkjImiLcUlvXbCvZ25pt/n2H2nT3bbfqtmtXadfr+7TuulV6rfWg7vnw h7xlApLeaGvXthdfUlUopL/88u/r4fvv0x/+j785v6KM9S8Kh7VxfZ1+vf9tfe6Oj2nj+k/o53te nbD9o+++q75z53TTyhWSZemm5VdraGRER0+9p5tWrtC8YFA3LLtKFYGAXm89eH4bOWxvY90ndM+H btPOV1/TL99o1l899AdaGA7Lisd1/8c+qoc+c7d+03pQf/OTHfpi3cf10GfulmPbevaVPXrnSIe0 vk6rr7pS7SdO6IPLx2uVS5fqYOcx3bhiubb+bGfW/21qE4H7t21ZSsRievKlXygUDisQDMq2LDW3 tav70MHMFejJX+xSKBxWRdU8BUMhBSoq9N8e+kOFw2FvzBydDJiKG065nJZK52tsmcvv27fPG4zr 2rdv34T1u8vbti3LsjQWzRgK4krEYvK7NTfbTvaiZqmJZWOPDy/INv/g8LDeOdqpW69dJb9t6/Yb btD/3PFTL9wSsZiOd3frxKlTWrpkiRYtWKC+oSEtveSS9PU5SnscTyT07S0/1uDwsNavXaPFCxZM Wt4329p15623aOXll+vmmpV6s/2wjp16T2tqVuq6DyzVrauu0ZGud3W6tzev7a1fm/yk+ZeXdmlg eFixeML7n957+4clSY/9bKdOnT2rH/ed1UdW36B7b1+nHS9HdKDjqBKWpdrlV+vVt9/RwnBYPQMD uu7KD2jZkiWqDof1Zlv7tF+Ly1bWaP2nP5323IH2w3r7317wPsAc25bP79fTTz2lA8eOqaunV4Mj IzrQflhdB95RT0+PlozXbiXRyYAp5VNzcxxnQrhNtXzmtNTl3RpcIiX80sLNisckhdwllbDs5LAB yTsYvBVneazxU6IJO2E7eu1Ai9ZcU6MHPv47CldVqnm8EV9OMhhXXXWl/uIPvqIlCxfqxOnTuqS6 OlnotPWlr39kbEz9g4PJsrs7mWX7kvTGoTbdeestuvXaVVq7apWeeP5f1XXmjL7ymbt148oV+vD1 1+tX+97Ie3uXLkqWt39oaPyFOt92edmiRZKkU729sm1b7/Umrwu9bPGi5Km8ZantxEl9cMUKralZ qdbOY+o/d06rl1+tNdfUqOPdbm+7U3Fr3ZK0f7wd0XW644jsREIbbl+nyspK+f1+Pffqa3qr46ie +eWvzs935LDGhgbV29vrnZYGAgE6GTAlL1zGA+iOO+7IOt8rr7zi/e04Ttop5oWWv/322ydd3v2d 2nySHm7jA3ndjcUSCSViUU3H+ZrbxPltK6FXmpv1J/ffp4133ak9b7+j0ZHh8QLaSsSiemjDPVp6 yRJ9+Xs/0KmzZ/XYd/+rrrnyyrT1OY4mfewee5OV97cHDkiS7vvYR1Q9P6zfvvOO+oaGFIvH9anb btX7Fi7Uq2/vz3t7o9Go5s+bp4WVIQ2PjqoqFPKmn+7r15WXXapLFoTV3dOrK8ZrRGf6+rzl97e3 q3bFcn32ox/RK2+/reHRUdXdvFbrb1mrNw4enPbrMBnHtmUlEgoGg1qwYEGyXS0UUkd3d9q63UHB fX193nWqktI6Gc7/P85fApN5xQOdEReX1Ib9qaROdxxHsfGzkdTl169f780TiUQkyXvujjvu8J5L XT5bjS8t3Bzblp3yd8KyZMXjaTW0bNzTnElrbo6jE6dO6fip93T1Fe/XfzQ3n59vvObmNorX3XKz zo2O6qrLL5ckfej667V3vHcksyaV/vh8TSmbM2fPqrO7WyuWLtWJ997TqfFe05ajnbr5ums1NDyi lo6j3j851+292dau31m7Rn/24O8pVBFS5Xi42ZalZyMRPfylL+rrD3xOT774b/r98VPGZ3f/2lu+ ua1ND959l6656kr9/Y6fKuZ2iS9bpv+z8/lJasTJsrqvj1ubzvwtSXYinrzixLK8Ed7y+dQzOOSd qvr8fq+9bnBwUPPnz5ff71c8HlcoFFIgEPA6GNxPTbch1w03v9/vXfUQCAQIuItEZm/prl27ss6X GkK2bXvhlLr8rl27dNddd2nXrl1p68t8LnX5bDJOS+Nem5scR/HxS6/s8QMis/FaShkK4p6mZRsX Nz5M5IdP/ouWXfF+7Wl+K2U+R3YiocefadJffPUh/dH9v6vd+97QE8/+TH/8wOf0n+7+lF7bv//8 PyRj/Rd6nOr1Ay1asXSpXm9p9eZrPnRIN193rX5z4J2sbVrT3d6Pn96hZZdfrjXXXqutT+/Q8ive r0sXL5adSGjHrl/KL58+f+cn9aNv/7neO3tWW3f8VE//YpfX2/x2W3uyp9O21XL4sKzxNs+A36+3 Dh70tpM5xtBxHCkl+Hxu0GT8dod+PP/qawrNmyd/ICDbttXeckC9x48ll3VfW9vWT3f/WqGqKgUr KxUMheQPVuhbX/qCd0r76P/b4V2el7ziwZZ8fvkDAX3rS1/QvHnzvF5Xws18maeV0xUd7wDIXP7F F1+csK5sz7nLZ7tRhE+Ss3nbdjW3tevsyRPeJ/3hPa9o1cfuUHdry4SFJtNzrFM33XPvtOdHAbjn xz5f+vW+Wea7+vob0p463nZIR3+793wnw3hwPvnUU3rj8BEdPXVK/eeGdbztkM50HNHX7vusFixY oGAwqB89+5z+tvGv0uc7dFBnjnboa/d9VosWLVI4HPZqfDDbY489pkceeUQ7d+6c9jLPPPOMvv/9 7xdk+Wg0qiuuuEKRSESNjY2SspyWpjYcH9r9cvJaxPELWeVM0qg8fjriHx9ygPLUmfFB1XfyhKx4 XB9fc5NCoZD8fr9ebn5L+9oP69mf/zxtvrGhIfX29sqyLIVCIcWjY1POJ52/zRHhZj7HcfTNb35T IyMjyXGVKe33mXw+n3drLndc2kyXr15UPWG4Ulq42Zbl1dxWfnhdfjuZ1maFcpZsckh2MsyfPz/Z ThYK6dDJrrTX0bFtxUZHNTAwoIqKiuSdG2KxKeerqqryApNwM9/GjfndDcg9rZzp8u9bvESZNxWf UHPD3DDV0Ixs7aKpl865v5N/+71PwVAoJH8goJ6BgbQauHepVizmvZkcy7rgfGNjY4QbZsWSJe/T 0NBQ2nMTWuHOnjwxawVC6dl2MoxGR0eT99FKJNR9sFX93e+mz2clNDw87PWExsbGppyvv79fiUTC 64AAimlRdbV3hxDXhHBr+/XuWSsQysNPjhxJe3zsjX1Z53sqc759E6/jzTYfUGzf+MY3JvTKp4Vb YHygZilHo7e2tl54JgAYV1tbm/UO0tm/RUSlCZna2lrvdiYAMBNl0xjiXlIBAIVQNuEGAIVEuAEw 0qRtbuUq8/Q19Q4Cc5WJ+wSU2pwJNzcA6uvrJ0zbsmXLnAwEE/cJKBc5hVvm/cxdqV/ikO3vmYpE Il4AZBum4vP58gqDfMpYqP0q5D5dqEyl7IWmBxylknObW0tLy4Sf1GnFNNn4u3zG5bkH3WSBPVsK tU+T7Uep9w8olYJ2KEx1INXW1no/uXBrOBc62Ddt2qRIJKLVq1fntP5sMsvoPs787f6d636VYp9S TVbm1P2bbNpUj/N5fYFimZXeUreW5P6U+gBIPVXKpTypy6Supxz2K9v2s50SXqjMqdOnuz/l9H8A XDl3KGS+cWlPmVsu9Hrl83ryHkA5yjnc8n0jl9unebmVpxDcWlPq72yKse8m/j8xt83aUJB8Q3G6 PaBbt27Vpk2bLnhN7GQH/Wz26hV6n3KRuZ+FCKVirBOYqZJcoZDrm3/Lli0l+5KRYh2oxdqnC9Xa CoHwwlwwKzW3zEbmXA+89evXa8uWLV5NJtXWrVslqaA1nNTy5tLonst+zfY+pZYxs8zTCcOp/if5 rhMoprRvv+o9fkx7tm+T4zizfssjd3jEhQ6IzEuV3GCYy/eBM3GfgNlSW1urvr4+dXZ2qqmpKfu3 X80FmbUcEwLAxH0CSm3OhZuJB76J+wSUGrc8AmAkwg2AkQg3AEaass2N7zUAMFdNGm4M1AQwl2UN t9bW1oIMwCz0rXoAmKdYowWKPhSEYQ4AJlPMK1noUABQEsVu0y9quJXqYneUL9pyMVvm3BUKMMtM bqgATIVwQ8lkuw8cAYdCoc0NgJEINwBGItwAGIlwA2Akwg2AkegtRdFMNqaNXlHMBsINRTPZt8+7 wTbTLw4CpkK4oagmC7jU6UAx0OaGokutqQGzhXDDrCDYMNtm5bSUi6WRivcDZkNRw81xHO4MAqAk soZb6h108w0nx3G0fv161dXV5VcyABeF5557rijrnbTm5t5BN9+2Ep/PR7ABmJaGhoa8lrNtW9/9 7nezTivKaSltKgByletXEtTW1sqyrEmn01sKYM6Zzi3KCTcARiLcAJStmTRxEW4AypIbbPkGHOEG oOxkBlo+AUe4ASgrU90qKxfcFQRAWSnUdcjU3AAYiXADYCTCDYCRaHMDUDamc+XBdBFuAMpCoa9J J9wAlAXHcXJexrbtSacRbgDKAncFAXDR464gAC5ahBsAIxFuAIxEuAEwEuEGwEiEGwAjEW4AjES4 ATAS4QbASIQbACMRbgCMRLgBMBLhBsBIhBsAIxFuAIxEuAEwEuEGwEiEGwAjFfU7FGrW1aQ97tjb wXSmM53pWacXmk+Ss3nbdjW3tav3+DHt2b5NjuPk/GUNqdyv6KqrqytQMQGYasOGDWpoaMgpcyKR iOrr62VZlgKBgPr6+tTZ2ammpiY1NjZK4rQUgKEINwBGItwAGIlwA2Akwg2AkQg3AEYi3AAYiXAD YCTCDYCRCDcARiLcABiJcANgJMINgJEINwBGItwAGIlwA2Akwg2AkQg3AEYi3AAYiXADYCTCDYCR CDcARiLcABiJcANgJMINgJEINwBGItwAGIlwA2Akwg2AkQg3AEYi3AAYiXADYCTCDYCRCDcARiLc ABgpWMyV16yrSXvcsbeD6UxnOtOzTi80nyRn87btam5rV+/xY9qzfZscx1Fra2veK62trZUk1dXV FaiYAEy1YcMGNTQ05JQ5kUhE9fX1sixLgUBAfX196uzsVFNTkxobGyVxWgrAUIQbACMRbgCMRLgB MBLhBsBIhBsAIxFuAIxEuAEwEuEGwEiEGwAjEW4AjES4ATAS4QbASIQbACMRbgCMRLgBMBLhBsBI hBsAIxFuAIxEuAEwEuEGwEiEGwAjEW4AjES4ATAS4QbASIQbACMRbgCMRLgBMBLhBsBIhBsAIxFu AIxEuAEwEuEGwEiEGwAjBUtdAFw8Irt3e3+vr6srYUlwMbhguNXW1ua98pp1NWmPO/Z2MP0inq6U cCvH8jG9xO+PAvNJcjZv267mtnb1Hj+mPdu3yXEctba25r1SNxDr+HRGCmpuyGbDhg1qaGjIKXMi kYjq6+tlWZYCgYD6+vrU2dmppqYmNTY2SsrhtDS1BtfS0pJD0YEkAg2zaVrhVltbmxZomY8BoNzQ WwrASIQbACMRbgCMRLgBMBLhBsBIhBsAI01rKEhLSwvj3ADMKdMexEugAZhLOC0FYCTCDYCRCDcA RiLcABiJcANgpBmH20xuZgkAxVKQmhsBB6DcFOy0lIADUE4K2uZGwAEoFwUNN65iAFAuChZuBBuA clKQcCPYAJSbGYcbwQagHDGIF4CRCDcARiLcABiJcANgJMINgJEINwBGItwAGIlwA2Akwg2AkQg3 AEYi3AAYadpfypyPmnU1aY879nYwnelMZ3rW6YXmk+Rs3rZdzW3t6j1+THu2b5PjOGptbc17pe5N K+vq6gpUTACm2rBhgxoaGnLKnEgkovr6elmWpUAgoL6+PnV2dqqpqUmNjY2SOC0FYCjCDYCRCDcA RiLcABiJcANgJMINgJEINwBGItwAGIlwA2Akwg2AkQg3AEYi3AAYiXADYCTCDYCRCDcARiLcABiJ cANgJMINgJEINwBGItwAGIlwA2Akwg2AkQg3AEYi3AAYiXADYCTCDYCRCDcARiLcABiJcANgJMIN gJEINwBGItwAGIlwA2Akwg2AkQg3AEYKFnPlNetq0h537O1gOtOZzvSs0wvNJ8nZvG27mtva1Xv8 mPZs3ybHcdTa2pr3SmtrayVJdXV1BSomAFNt2LBBDQ0NOWVOJBJRfX29LMtSIBBQX1+fOjs71dTU pMbGRkmclgIwFOEGwEiEGwAjEW4AjES4ATAS4QbASIQbACMRbgCMRLgBMBLhBsBIhBsAIxFuAIxE uAEwEuEGwEiEGwAjEW4AjES4ATAS4QbASEX9DgUAyEUkEinYugg3AGXB/e6VQiHcAJQFx3FyXsa2 7UmnEW4AykKu37hXW1sry7ImnU6HAoA5Zzptc4QbACMRbgCMRJsbgLIyVa9pS0vLtNdDzQ1AWZks wHIJNolwA1CGMoMs12CTCDcAZcoNtHyCTSLcAJSxfINNItwAGIpwA2AkhoIAKBuzdleQQm4IAKYy a3cFKfSGAGAytm1PeRF8PrKGW2tr64x6KVzPPffcjNcBwGz333+/Dh06VPD1Fr3NraGhodibADBH 2bZdlGCTZqlDIZ/7NDmOk/NyAGZfvsfrhe7HNlNlNxSETgxg7sj3eJ2N47yk4UanBWCuUh/fJQu3 Uu84gOIr5XFeknAj2ICLR6mO91kPN4INuPiU4rif9XArxPg5AHNLKY77kpyWEnDAxaNUx3vJOhQI OMB8pTzOSzoUhIADzFXq47vsBvECQCHM2v3cynkkM4DCKKfjdVbCLd9uYIaNAHNHuR2vRQ+3fO/T VIz7OwEojnI8XrOGW6GqltXV1XrssccKsi4AyEXWcNu0adNslwMA8lJfX5/1+bRws+JxSZLP5yt+ iQCgCGzblpQRbpdfs0qbt20vSYEAFEZzW7sORn6lTV/4vFavXq1ly5bpgT/9uh78kz/Ne/rixYtV WVmpQCAwZyo/E05Lm9vaS1EOAAVy+shhxcbG1Nvbq+7ubklSbGxMUvL4zmf6wMCAKisr5ff751a4 uTsEwAznes6oublZXV1dWrx4cfJxynGe6/SqqioFg0H5/XNn3L9PklPqQgBAoc2dGAaAHPx/YMnV s9b8aj0AAAAASUVORK5CYIJQSwMEFAAAAAAAllDBNLasV216HwAAeh8AAC0AAABQaWN0dXJlcy8x MDAwMDIwMTAwMDAwMTM0MDAwMDAxMzdBQjUxQTdGMS5wbmeJUE5HDQoaCgAAAA1JSERSAAABNAAA ATcIBgAAACQVvTEAAAAEc0JJVAgICAh8CGSIAAAAFXRFWHRTb2Z0d2FyZQBFeWUgb2YgR25vbWUL H4+vAAAfEElEQVR4nO3de3hc5WEm8PecGd1tSb6C8QUsbNcShRAMsg2bWoBJIFwCXdJC+zRZIKGR S7fbbGG7adNsku4fLm36bLtIlDalSdjCEggEtgmlEMZJHYIxxBgs2QZ8wYCNbUmj0Whmzn3/kM7x jOZyzpyZo/nm6P09jx+kkWbmNbZef+c73/mOBMACAFmWQURUD0zTLPh4lEVGRGERBYDXXnsNqqZC ySjIZDJITU5iMpVCanISqXQamUwGGUWBrmmQJKnWmYmIcnzjG98AMF1obW1tWNS8CK2trdB1HWNj Y0gmk1AUBYZhwDRNGIZR8IVkWYYsy4hGo2hoaEA0GoUkSSw+IpoVTz31lPNx1P7Asizouo5MJoOJ iQmMjo4ilUpB0zSn1EzThK7r0HV96snRKJqbmzG/fT4WdC7E/Pnz0dHejuaWFs7JEVHgjhw5kvO5 U2imaaKpqQlNTU2IRCLo7OyErutOkRmGAcMwoOs6VFWFqqpQlKlD1MR4AqdOnkImk8GJEyec4R8R UVDGxsbyHosW+L6qGBoaCuqlq+qZZ57BvffeW+sYRHPCgQMHKnp+LBZDf39/0Sktp9Dsb7jvvvsw MjKCeDyOVCoFVVWdU6SWZTm/7MdkWUZDQwPuueeeioLWkizLvub8LMviXCHNOX7/3hebh6+mvBGa ruv4yle+gmeffdbzizzxxBNVDVULQ0NDiMVinr9/27Ztvp5HVM/8/r23nxe0vBGaaZrYsGEDFi1a BE3TnJMAxT5++eWXnZME9a6vr8/T9838g/T6PKJ65vfv/Wz+g593KtKyrJzPe3p68p408zcy8zlE RLXgFFqhY+J169YBAC666CLnsSuuuAIAsHXr1qCzCaFQoRNRLlF+TkouFjt48KDz8YYNG7Bx40bn 8xdeeCG4VIIQ5Q+JqB6I8PPiuvq10PKLuTAJLsIfDlG9qfXPDZfzF1DrPxSielbLnx/XQvNyUiBs 6mVRMJGIavnzk1do2ScH7JMCwNSOHK+88orzefZJgTAuLmWpEZWv1j83TqHZSy+yLyq3Twrs3bvX eWznzp0Ack8KRKOBXUFVU7X+wyGqJyL8vOSN0GaWk5eTAk1NTdVNJRAR/pCIRCfKz0ne0KqhoQEA cN5553l6gcWLF+PFF1+saijRhX0OkagQv3/vZ/PnJWc/NABobGzE3XffjXQ67eyFNvOidHs7Ifvj lpaWWQsclO7u7rK+3/7/Ve7ziOqZ37/32RtaBCmv0L72ta8hmUwinU573g8tk8lAUZTAwwZl+/bt tY5ANCfcdNNNgb5+3c7md3d3V+Xs6pYtW6qQpnq6ertwaNehWsfIwUzuRMsDiJkJQEX7D7ot6s8r tHraD62SrXtmazsTIsrld/9BL/up1f1+aGGboBfxX1RmcidaHkDMTLag9lPLK7S5vB8aEc2eIPZT c90PzQvuh0ZEIij74vQrrrgidId5RBQO3G1DMF29XbWOkIeZ3ImWBxAzUynV2KWDhUZENWeXWaWl lndxOhHRbJpZYpWUGkdoRFQzxcrLb6nlLdvws+AtjPuh1YqIa4eYyZ1oeQAxM81U7V068gotez+0 Qnbu3OmsQ3NeJKT7oRFRfXHdD82LMO+HRkT1g/uhEZHQyln3mldoc3U/NFGIuEMCM7kTLQ8gZiZb UPup5RXaXNwPjYhm16zttkFEFLRZ222DiGg2zMpuG1RbIs55MJM70fIAYmYKGguNiEKDhUZEdcle eZGNhUZEdSl76ZiNhSYYEfewYiZ3ouUBxMxUTYqiQFGUnMswWWhEVJfi8TgSiQQymYzzGAuNiOrS sWPHcPz4ccTjcecxrkMjoro0PDyMkZERnDp1ynmMhSYYEdcOMZM70fIAYmaqpsEnfwA1k0HyNAuN iOrc+r6rcPLdd4C16zBy9CgAzqERUZ26eN1aLD1/Tc5jHKERUd26eN1a7Mn6nCM0wYi4doiZ3ImW BxAzUzU99tDf4bt/87/w80e+4zzGQiOiuvTU3z2IB//8m/idW25xHmOhEVFdKrkOjbeiI6J6wnVo dUDEtUPM5E60PICYmaqp5Do0jtCIqJ5wHRoRhUbJdWgcoRFRveE6NMGJuHaImdyJlgcQM1M1lVyH xhEaEdUTrkMjotDgfmhEFBpch1YHRFw7xEzuRMsDiJmpmrgfGhGFBtehEVFoFFqH5hTazBt2EhHV G47QBCPi2iFmcidaHkDMTEFjoRFRaPCQk4hCg4VGRKHBQ07BiLh2iJnciZYHEDNT0FhoRBQaLDQi Cg0WGhGFBgtNMCKuHWImd6LlAcTMFDQWGhGFBguNiEKDhUZEocGFtYIRce0QM7kTLQ8gZqagcYRG RKHBQiOi0GChEVFosNAEI+LaIWZyJ1oeQMxMQWOhEVFosNCIKDRYaEQUGiw0wYi4doiZ3ImWBxAz U9BYaEQUGiw0IgoNFhoRhQYLTTAirh1iJnei5QHEzBQ0FhoRhQYLjYhCg4VGRKHBQhOMiGuHmMmd aHkAMTMFjYVGRKHBQiOi0GChEVFosNAEI+LaIWZyJ1oeQMxMQWOhEVFosNCIKDRYaEQUGiw0wYi4 doiZ3ImWBxAzU9CcQpMkqZY5iIgqxhEaEYUGR2hEFBocoQlGxLVDzOROtDyAmJmCxhEaEYUGR2hE FBocoRFRaHCEJhgR1w4xkzvR8gBiZgoaC42IQoOFRkShwUIjotBgoQlGxLVDzOROtDyAmJmC5hSa ZVm1zEFEVDGO0IgoNFhoRBQaPOQUjIhrh5jJnWh5ADEzBY2FRkShwUNOIgoNFhoRhQYLTTAirh1i Jnei5QHEzBQ0FhoRhQYLjYhCg4VGRKHBQhOMiGuHmMmdaHkAMTMFjYVGRKHBhbVEFBocoRFRaLDQ BCPi2iFmcidaHkDMTEFjoRFRaLDQiCg0WGhEFBosNMGIuHaImdyJlgcQM1PQWGhEFBosNCIKDRYa EYUGC00wIq4dYiZ3ouUBxMwUNBYaEYUGC42IQoOFRkShwUITjIhrh5jJnWh5ADEzBY2FRkShwUIj otCI1jpANfX09BT92tDQ0CwmIaJaCE2h9fT0lCwtt6+Loqu3S7i5D2ZyJ1oeQMxMQeMhJxGFBguN iEIjNIecQ0NDnEMjmuNCU2hAOEpLxDkPZnInWh5AzExBC1WhFVMvJwTIm9iOHc7HfVu21DAJiSYU hVbqULOc7yGi+uYUmiRJtcxREbfRV3aZ2d/LgiMKH+cspyzPjROeoheZiHtYiZapb8sW3HnvHUId bor2/wgQM1PQnBar5xFaOTiXRhRevufQLMuCZVkwDCPnl2mars/1MkoKonhYZkTh5hSaZVmen2SX ma7rUFUV6XQamUwGmUwGiqK4Pr8WxcIyIwo/55DTy8jKZo/MVFVFKpVCIpHA2NgY4vE4kslkxaGq Pc9VT2Um4tohZnInWh5AzExB83XIaVkWNE1DOp3G+Pg4RkZGMD4+DlVVMTk5WdZrFSqveiogIhKH 7zk0wzDwre8/icxEApmJCajpNEzDgGnonl8je8FrsY+JiLzyPYdmmiZMw8CS1V0Yee8oWtrbnbm1 U+++G0hYIqJSfC0+s4sLlolVv7IeC1asxIIVK9F5zvJq55tzRFw7xEzuRMsDiJkpaL4KTZKkqXVr kozOeW2+3zx7hwz7Yx5uEpFfvubQJEmCLMuQIxGsPvts7KkgQHZ5sciIqBK+TwpEIhFEolFcsuZ8 WDfcgAPvf4DT4+Owylj+QURUTb5HaNFoFHI0ii//6VehKRnoqgrLMKBmMp5fhxsy5hNx7RAzuRMt DyBmpqD5HqFJkoT7fuNWjI+PY2JiApOTk1BVFaOjo3jgtd2eXqNQaXEOjYj88r3Fhr10w778SVVV KIoCTdMqCuS2lTYRUTG+9kOzr+NUFAXJZBLxeNz3lQJERNXiFFq5+6FV60qBQubyIaeI91JkJnei 5QHEzBQ0TyM0+/DS3iJI0zSoqgpT17Ck63yMHD3i60qBuVxcRFR9ricFsrcKUhQFmUwGyWQSExMT 0FUVq9b9CkzDgDV9KdTYB+/PRm4iojyu13LOnC+bmJjA+Pg4xsfHoStKRVcKADzsJKLqcQqt2H5o 9lZBqVQKo6OjGBkZwdjYGBKJBNRMpqIrBbhEI5+Icx7M5E60PICYmYLmaR2aruv4s4e/g8zEBDIT CSiTk1MLaU2TVwoQkTDyCq3YCQBD07D8gl/FiYMH0NLROT1vZuC3b7sN0cZGRBobIUciMHXvZznt NWccpRFRNeTMoWUvlrXvEZBOp5FIJKCrKi5YuwamYUBXFZiGgVOH3oVlWbjy4o+hvb0dzc3NSKVS GHz9NU9vbs+fcddaIqqGnBGafQIgk8lgYmICiUQCk5OTSCQS0DJptLe2nvle04RlWZAkCaZpQtM0 yLJc1pUCLK18Iq4dYiZ3ouUBxMwUtJxCs4tpcnISIyMjOH36tHOtpppKYfniRc73StMLcSVZnlqT ZppIp9NQVbXiUDwMJSI/8ubQNE3DHz4wiFQ8jnRiHGoqBV1VAcvCBeeei1+/+iocOn4cpxMTMDQN 8Q8/xM/2vgnT0CFJMkzTKCsADzeJqFryDjkNw4BpGLhkSx+GXn8tZ9HsZ2+7DQ3NzYg2NgKSBEPT sPqyXowcPeIcgpZzpQBvkkJE1ZRXaFP3CrDQs2olNF2HomlQNA3vv/UmLNPETZs3obOzE7Is43v/ +jyvFKgyEec8mMmdaHkAMTMFLafQztwrQEJbc7PzmPN1WYZpmlBVdepkgJF7eFnOjh1ERNWWV2iR SARyJIKzFnTmfbMky1AUxVmjpqbTOV8v51Z4QO46tJk3TCEiKpdTaA0NDc5/o42N6Fp2Nm7c1Iv3 T49gdGLqBMDpI4fx41d2wdB1mLpelREab5JCRNWSM0KTZRkNDQ2Qo1Fs+/o3oSsKdFWFrihQ0yl0 X3k1jh/YPzVfpmuwLAvvHdjvPL/cERrlE3HtEDO5Ey0PIGamoBW8lvOB3/89jI6OIplMIpVKIR6P 468efQwXrF0DQ9Ng6BpMw4ChaTmjNK8jNC9bbHO0RkTlKlhouq5D0zTn0qdMJgOjwDWaMwvM6wiN 82VEFISCVwpkMhnE43HnSoHx8akFttnsdWd+Za85y/6ciMgvb1cKTM+lZZNkGdKMrYIqOSnAYpsi 4pwHM7kTLQ8gZqagRQE4O2xkbxV0ad+VeOu13c6CWdMwsO/td5wnVjpCm4nFRkSVigJTozLLsqCq KuLxOHRFwfqVK6BoGlRdR2a65LJHaYVGaJUUHIuMiCoVBYB0Og1d12EYBkZHR6FkzZdZlgVZkqDP KCtnhFbhKI1FRkTVIgNAIpHAiRMn8N577+HIkSPITCTyvtGeH8veNmj6C77euKenJ+cqAZrS1dtV 6wh5mMmdaHkAMTMFLWqaJr7y99+GkkxCy6ShTE7mjNBc+RihZa9D412fiKhaogCwZetW7Nq1a2oL bsMALAv7j03tmiFJEkx7F44sldwMhWVFREGIAsDa5cuB3t6pEwO6Dt0woOnu12naO3MQEYlAznvA Y0E5c2hUVSKuHWImd6LlAcTMFDS5bcHCqr0Y90MjolqSC12j6RV31yAikciFlmh4xREZEYnE00TY l66/Dldc0IP2trag88x5Iq4dYiZ3ouUBxMwUtILbB800v7UV/Z+5Ee2trTj04XG8vn8/Xt9/AG/s 349EMun7zbu7u3M+Hx4e9v1aRESeCu3+7z8JU9excuFCXHR+F/o+/jHcetWVME0TW75wt+83Hxwc zPm8v78fAIuNiPzxVGjrVizH2mXLsG75OVi/aiWWLlgAADB8Lq6NxWIAzhSYzS64/v5+lhoRlc1T oW2/6w4AwOnxcew7fARPvhTDvncP4cDhw2W/YSwWw7Zt2wqeIbULbnBwcM6Wmohrh5jJnWh5ADEz Bc3TSYGfvvkWRhIJtLe1oXPePLS1tKCxoQERH4tri5UZEVGlPI3Q/voHT8PUdSyZNw8Xda3G9Zs3 4XPXXQvdMHDlF3/X85vZh5pu+vv75/QojYj88VRo5y9bhu4Vy9Fz7ipccN55aG9rBTB12zsiIlF4 KrS/vPsuAIBuGDh47H3s/fnb2HPwIN48+Hag4eYiEe+lyEzuRMsDiJkpaJ4K7dHYDrz17iHsO3QY mUwGuqpM3WeggsumiIiqzVOhPb7jZ1P3FNC0it6sr68PAwMDkCSp5ImBwcFB9PX1cf6MiMriqdAk ScLNV1yOT2/sxZLODpwaG8PTO36Kx//1eRjuTy/6moVKTZIkDAwM+HxVIprLPBXajRt7ccenrnE+ P3vRInzp12+BZZr45x/9uKw3tEdpQOGL2wcGBtDX11fWa4aJiHMezOROtDyAmJmC5qnQPt17KX4x vB8PPv1DfDQyikVtrfjSLTfj5r4tZRcaAKewZo7E5nKREVHlPBXa4o4O3P9/n8DJsTgsy8KJ0VH8 8/PP43//0X+t6M1ZYERUTZ4Wkp0eH8dnt3wCZy9cCFmWsWzxIvz2tZ/CqbF40PmIiDzzNEL70a7d uONT12Bj9/qcxwe//2QgoeYyEdcOMZM70fIAYmYKmqdCe/YXr8AwDHx642VY0tGBk2NxPB2L4YkX Xgw6HxGRZ54KzQLwzM9fxg9iO2AahrOwlheZE5FIihbaX959F9pbW11f4BN3fqGqgYiI/CpaaOOT kzBME5YFLJw/DxOpFFRNB2ChubERTY2NiE9MzGLUuUHEOQ9mcidaHkDMTEErWmjf/D+PQdE0qLqO R//7ffjqw9/FwaNHYRoGIpaJb9z9Rbz06quzmZWIqCRPyzZSioKrL7kYHW1tkCQJbS0tUDUV/Z+9 Neh8RESeeTop8NM338KNmzfhxs2bch4/evxExQF6enryHhsaGqr4dYlo7vE0QvvH557H47Gf4uRY HKZpYjKdxr+/sRd/8kBlF5H39PRgaGgo71ehkpsrRLyXIjO5Ey0PIGamoHkaoWmGgUdeeBH/9KMf 5yzb4H5oRCQS7qFNRKHhaYR23WWX4va+X8P8AuvSKlmHVuzwknNoROSHp0L73Nar0NzYiHgyCcMw MHWBQHWuEmB55RJx7RAzuRMtDyBmpqB5KrSUouC5V3fjoR8+W9U5NPukgNfHiYhK8VRo337uedze twWPtbUhnkhU/KbZh5lz+YwmEVWXp0K789pPoqO1FQ//8b1IZTI5h5y3fPmPyn5Te/TFkRgRVZOn s5yL5s9HNBJBS1MTFnV0YHFnBxZ3dmJxZ2dFb84yyyfi2iFmcidaHkDMTEHzNEK75et/PnUbO1Wt +hxaMSw7IiqXp0ILCk8IEFE1FS20my/fhM093dj2twP4hy//AWBZ09NmVsVzaKXYa9NYakRUrqKF 1tLUhAXz5gGYmkOj2SHi2iFmcidaHkDMTEErWmiPvrQDj7z4EoDZn0Pj6IyI/Cg5h/bAPf3Ye/gI dh04iN3D+3FyZKSqb87iIqJqKlloT/xsJy5cfR5+9/rrcM9NN+DdDz7ErqFhvPzmXgwdOgxzlkIS EXlRstD+7fVf4l92vQrLstCzcgUuWXM+rtpwCW6/5mpMTKbwyr638PUHH6pamOxD0Lk6ehPxXorM 5E60PICYmYLmadmGomnY/94xmLqOjKLg6g2XYMH8+dja21txobHEiKhaShbapevWYu3yc7B+5Qqc u3QpJEkCAKiahj0H38aeAwd8v7FdZNmXQRERVaJkof3+Z250Pt576DDeePsdvPHOO9j3zjtQFMX3 WU6uMyOiIJS8lvOF1/fg+OgoAGD12Wfh3LPPwvIlS7CgwnVp9uJZjsryiTjnwUzuRMsDiJkpaCVH aN978SdQdR3zW1pw4bmrcHHXatx1/afxh79xK4599BF2Dw3jW997xNcb81CTiKrN00mBU+Pj+Mkv 9+DwBx/i6ImPcMPlm7DyrLOw8qyzfBeaLfvQkycIiKgSJQttaWcn1q9cgQvOXYULV5+HtuZm52tH jh/H7n3VLR2WGBFVomSh3f/FO52Px5JJvPL6L/H6gYN4dd8+nBod5W3sAiDi2iFmcidaHkDMTEEr WWh7Dx/G3kNHsPvg2zj84YfQFMW5lpOISDQlC+2vnngKqq4jo6qwrOrc5YmIKCi80TARhQYLTTAi znkwkzvR8gBiZgoaC42IQqOm9xTo7u7O+Xx4eLhGSYgoDDwV2nWXXYrb+34N81tb8772iTu/4PvN BwcHcz7v7+8HwGIjIn88Fdrntl6F5sZGxJNJGIaRc5MUP2KxGIAzBWazC66/v3/OlpqIa4eYyZ1o eQAxMwXNU6GlFAXPvbobD/3w2YrvKRCLxbBt27aCy0DsghscHJzTpUZE/ng6KfDt557HpevWob2t reI3LFZmRESV8jRCu/PaT6KjtRUP//G9SGUyvu/LaR9quunv7+cojYjK5qnQ7PtyRiMRtDQ1BRpo rhNxzoOZ3ImWBxAzU9A8FVpQ9+UkIqomLqwlotAoOkK7+fJN2NzTjW1/O4B/+PIfAJY1PW1m+Z5D 6+vrw8DAACRJKnliYHBwEH19fZw/I6KyFB2htTQ1YcG8eQCm5tAWtbdjUUc7FnV0YHFnBxZ3dmJx Z6fvN7bvIOX18bmiq7er1hHyMJM70fIAYmYKWtER2qMv7cA/Pf8CgOrOodmjNKBweQ0MDKCvr6/s 1yUi8n0tZ29PD37zmqvxn7ffX/Zz7cKyi23m40REfngqtA1r1+D3brrBOQS1aRWe5WSBEZGbcnrC U6Hd8clr0NLYiOMjI1jU3o5jJ09ixdKl+PbTP/SbkYoQce0QM7kTLQ8gZibbzJ123FiWBdM0Xb/P U6Gds2ghvvrwd5BOZ9D/mRvxpe1/gesv34yPrVlTVigiIsDfyT/DMFy/x1OhpVUVGVXFeDKJlUuX 4uyFCzGvpQVbNlxSdigioqGhIc+XQgJT14B74anQ3j1+HBd2rcbjL76E0YkJPPL1rwEA3j95suhz uru7A12CwQvcieqb17mxcorPU6H9zVPPIIKpEvmf3/0e7rjuWsiShId+8FTJ55Xbwl55bet6JOIe VszkTrQ8gJiZguap0E4nEjA0DQDwzvsf4L89MOB5HVq1z2QGUZBEFA4lC+2bn/8dWLBgWWd+wQIs y3Qug/pPf/Y/ZiUoEZGbkoW2aumS2cpBRHNQT09P0a8NDQ2V/XolC+3l4f34WNdqqJqGXwzvx869 b2LPwbeRTk1y+6CAiDjnwUzuRMsDiJlppqGhoYKl5qfMAJdCe/D//QimZeH8ZcvQu24N/sut/xGt zU14Zd8Q/n3PHvx8zxuYSCZ9vbEt+zdj/+b8/maIqP7MLLVKfv5d90PTDQNvHDqEB5/9F9y1/X48 /pMYLr/wV/Gnd96BrRt7fb8xAKe8sn8DxRqbiMLL7oBKBzOuZznnt7Rgc/d6bFi7BpesXYOWxkYA wHsnPsKxEx9V9OZERLZqHJmVLLQ/uf03sXb5OZAkCaZp4q3DR/CLfUPYuWcPjp04wTm0AIi4doiZ 3ImWBxAzU9BKFtq6FcsBTK1De+3AQSQmJ9E5bx6u27xpahmHaWLw8e/7fvOZh5f2x5xDIyJb1Xfb WNzejk9ddmnBr1VSaEDtyotzdUS1U5PdNj5//7eg6joyqirkXZ/s/yl+rxm1LIt7shHNsu3bt/t+ bnt7e8mv+96xthJeRkZuI7fsG6j4HeUNDw8jFosJdR+DHTt21DpCHmZyJ1oeQMxMg4ODFT3f7dLH mhSaSHNkkiTx8JMoJGpSaCISqWTJHRdg15dYLDYru+TkFdqPH3sUaioFJZWCrmRg6jpMw8i6OP3M fwEAkgQ5EsH6vqs8v6n9l7Ha13ER+cWCDIe8QrNME9d97vPYFYtNTfyb5nSpTRebaeb99/SRw2W9 abVWBRNVg/0PK0ut/hUstFVLl0L7D5+AomlFz3IamgbLNPH+m3s9nU4lEtHMowSWWn3Lv5bT4xk/ Sc56apnbYXMCnkRQ7O8h/37WL9eTApZlQZYkFLrfSrX29ee/ilQL/DsXPvkjtAIlZWY9ZvHwkogE lT9Cmz7kNO2zmTO/nHWoKdKCVJq7eLacbEUPOWVJgjT9i0hUbtMVnM6YW/ILbcaorNQ8WSVzaIXO LmXjX0IiKlfRQ84zn+Z+nj2H5nytzFEcy4qIgpBXaJIkYX5LS9EnZM+h2SM0WXbdyZsoELzihLLl F5os46wFnc6ZzWKHlZZpOiM0OcpLQql2WFpky2uiSDSKNecswyc3fBzvnTyFeDLpXDGg6Tp0w4Sq 69ANA5quw9B1JE7W770FLMvK2YqI6gNLjArJKzQ5GsVtX/giDE1zLkx3rt00TWB650hr+mPLshBp aJy1wNyQkaj+zNbPbV6hbb35lunRmFHyWk57x1pDP3PR+kzlbrPrVbVHVUHlJKIzZuNoKLDJL65f I6IglNpXLQoArU1Th4ymZcEwTZjm1H91w4A+fchp/zI0NW/7IEzfAcoyTSw4Zzk23vZbiDQ0zM7v jojmHEPTsOfg23mPRwFgcUcHgDNXB8iyhIgsIxqJwLQs6JEILNNEY0sLUGJJBxFRLUUB4NylS3D1 xy/GqXgcE+nM9NlMwzmbqfKGwkQkqD1ZH0sAqrMHEBFRjf1/WwoQUouhLCMAAAAASUVORK5CYIJQ SwMEFAAIAAgAllDBNAAAAAAAAAAAAAAAAAsAAABjb250ZW50LnhtbMVXbVPjNhD+3l+xdaedduYc JwSGIyW5gQtc6YSXKTDTflQkxdYgS64kJ+R+fVfySxIg4a50rh+wo9WzL9p9di2OPzzmEubcWKHV MOp1uhFwRTUTKh1G93fn8fvow+i74+/H1x/v/ro5Az2bCcoHTNMy58rFVCuHb7i5P51cfIQoTpLr gqvrAOtokybJ+G4M1XpcawH6SZKzqwiiyl6HORaNjrcZxxiVHVS7wyhzrhgkiUY3euVmr9vtJtU6 qhWsW8rd+IBo4I4/up1oD2jBZPqK7YBo4MyQxU60B2DOG/xMt+jFYtFZ9AOyd3R0lPx5O0nOtclJ G8ujFOphKz7sNlBV5lNudkdCHNnIi52nLxmvEjhvQ6YZMbvzFxCrjPTZKxnpswaMh822HPB9comb 4XE5WaXP5DuNe0B7PmpEsTvyChI17KeSWDuMKj7Uso0eaqlcKSbteoaMjhmn0o6OQ5JXEqjWiuTI qxMjiIR7JbAVOVzeRjDTFXRGciGXw+gnUmj761NcJY1gzXYhHMXkzQlCPSOT3Z5/+wSXQtFMw0Sk mYPft7l+Bny77yuRT0sLf+icKLjSRzDZ5vw58gXvlUqccsWNoMPIePRr8SUvVKoWkdKhBSdoHEy0 JQzPjYPc9Vo3ddiBK41CYZBkxglu2+MtuE/iMJpqyUIYa6a3+5mZZ45SQ4pMUNvIC2L8KA2LuNL6 1EBeiKcSZNqIzxgWkTFmdRhRNMFN9HzXcDmM0AUJbhtALozROGWUVjxUkEpRYP45dT93aQ5rf79E 4EffQJa5UET5+d79sZb58W9wFq2JDGdrq9RwrtbWU1mu66ckzwk2ZGtOahML1XbqjEjL6010pGzI FcUkxr3uWhReLcf+GkbWEcWIeaFCyVaO1BtTzZajY0+DgeV/l+iHN/R6LoQgYsIWkixjXTqc4TyW fO7TjZ/osF0V80LK0mL0Do/kw3qTsbumC95mxXP9rUbG9QfRZ3p71opKZZ3dt02NRheQkTkH5s0j wRngrCBFIQUN2UJiGi/KEJ9xyTwQK/UOXMahDj4ZCSWcn7EYDNMLfEkJUusHkOKBI1RYGNQRFl8Q VPINMaPjQGCRk5RXXF6HhdkRpBtToVdXgfjRbmK3LPhmh8/TwUIw/z0+7Bzs9WleybJ6gB129g96 XhhMf8Z+Y/wxFDdcRAaZ4bNh9MONoK403CbYad3uXje8ur3+Yf3eH5/19w5Pev1OEW5FQbcKxoq8 CLeTILOZxpsVx2sNa0QETROHSK0mmrAVhf6rAo1OSxdYUjEGkAPINGQr+BFHVFpKYqCmOYgZCMBf lAedmkjEgnBeM19CffkDHD9kjWFU5wWmyHL2DqxGIwwHIiwIPpxud58a6MCFd0iR2U5It+FTsVVU kGFP7PAe+M0VniTlrAP/A8f/FX/3voa/NVU3+VuTepO/vS/k737D45PTg97J4XnvW/O3GbuFr/9T FN5LRhfWU8JwZMMSybT0XApEeTIdVzz1ISpkMCeWA07KAnIOOLw7zWRGX1/ZYsnGVzHZ8o/f6B9Q SwcIVrL7yYQEAACfDgAAUEsDBBQACAAIAJZQwTQAAAAAAAAAAAAAAAAKAAAAc3R5bGVzLnhtbO1Y S2/jNhC+91eoLNqbLNmJmziNsmg3+2iRx6JJgPZIS5TFViIFkrKT/fUdkqJk2ZSTwkBPzSGION88 9XFmlMt3z1UZrImQlLMETScxCghLeUbZKkFPjx/Dc/Tu6pvLb6/v3z/++eVDwPOcpuQi42lTEaZC qV5KIoMvT7/c/Po+QGEU3deE3RvUhItVFF0/Xgf2+bpVCsBNFH24QwGy5iaZytDV5YhtiJDJCytM UKFUfRFFHLzw3sssjuPIPqNWwWgfxBuEgyvyrA6iNaAD4+Urtg3CwTOBNwfRGgAVd/icd+jNZjPZ nBjkdLFYRH883EQfuahwF8tzSdnfo3gjdVDWVEsiDkeCFR7URa5XPuO2gOsu5LTA4nD9DKKvyEn2 SkVOMgeGZIuRBM+jWxCaX7c3fflEddC4BnT5pYLWhyO3EOS4P7gtHWtzDozNSFrKq0tTwP4ksM8M V8CZnwXFZfDEKFwyEtw+oCDnFprjipYvCfoB11z+tIuzpyjYsl1TlUJh1higmm3RYc+fPwW3lKUF D27oqlDBb2Ou94DH+76j1bKRwe+8wiy444vgZsz5PtLj3aqEK8KIoGmChEa/Fl/keVPtke00LoWM 5Lgp2/7jjLZBrgSuC5pK5MC1AMoIRaFR6VsMpoDmIdw6Esoap3Crw4IL+hWc4jJB8WR2fpIC+8bA a20s3YcSlr3V6h7UYxOKn/KSQzP4LjY/g+q9/tIk/QqI6UzfCzgrMVs1eAVHhLXGG6YEFOzpYc9y iCXFzEvILaT24JDWjxU6V07GOCNO1nr1iXrvKa/qkjz7ruKu+w7qDaCT+kLwCvUMCXGjuH4zUCya EW4YFeKyLrCD1Q1LVYMVdJlwA+IESaqtdRHol7sUBEPflwpugOroCHMHeMtrqQm/y9DuaMDwt9C+ xgKbQH28/59L/y2XoCTFS10QhhUUKcelHB5q2ghSYcpCPXRDYyZBsz1Q3cjiFUiJs4x0csahsVRU Hc3nAvI2C88ooYMhn8OMQrNk2slsMovnuodZxEZQpZtcBYVPUClCtUTRYaZvM9zS8wFsZ1hkaJT3 7pWUWMoEmWUwGrf3yY2JfzE+tM0LrDkMObzUZOh9vboAAsQmb/j7xf3d1kAXdZs6ruWHMDshXF7v CQQpPfn1U8VqprCIE+GR7qj3FW8rbbLhjbKDyHNWkjUp22ZjBOYArodzBttqmJtVN0Ha/pu0Z0dp nxylfXqU9vwo7R+P0j47Svv8KO3FUdrTeEw9GmVgzrliXBEJbY3ldNUI05o8doCLRsPuaWtcNnAr 4/awNwM3hSrzSVBDLx/o2E8u3Z+0Pfdp26UHq9rbIqH+SJwdnWPvamjMAKzQrIWymxm2QnkuidKr 4eli0bcUXxlaI326JclVK4PhCzOH6Ckx39623WrdPuphATZpGg53bl24sIJPTyIGjbSupiMrh9HY 0Ex/G86mk/miXWvNeUH0FgCCs8nidDQpZ5bCjIbOBsHj9jVyoQSmdh+psIBZFUIP1bNnftr6aY+X XEFGPokuDrSUyfRsPhQIG1sncZuCpRNU4bmLX/f4/suqBUhSu75v048n8fS8t+RGZbgkkKzBa8w0 nnowOIeSeyE4+6uRyr5S+6LtOXT+ru7z7/tdZbAB+tfPdooQrHcK8xBtZ7d1GO3RoqfUPodagQXu MKs91JYOjvwtV2HPvS0m71iP/P+uuvoHUEsHCFT8PRwABQAAUxMAAFBLAwQUAAAAAACWUME0gbtD aWIEAABiBAAACAAAAG1ldGEueG1sPD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgi Pz4KPCFET0NUWVBFIG9mZmljZTpkb2N1bWVudC1tZXRhIFBVQkxJQyAiLS8vT3Blbk9mZmljZS5v cmcvL0RURCBPZmZpY2VEb2N1bWVudCAxLjAvL0VOIiAib2ZmaWNlLmR0ZCI+PG9mZmljZTpkb2N1 bWVudC1tZXRhIHhtbG5zOm9mZmljZT0iaHR0cDovL29wZW5vZmZpY2Uub3JnLzIwMDAvb2ZmaWNl IiB4bWxuczp4bGluaz0iaHR0cDovL3d3dy53My5vcmcvMTk5OS94bGluayIgeG1sbnM6ZGM9Imh0 dHA6Ly9wdXJsLm9yZy9kYy9lbGVtZW50cy8xLjEvIiB4bWxuczptZXRhPSJodHRwOi8vb3Blbm9m ZmljZS5vcmcvMjAwMC9tZXRhIiBvZmZpY2U6dmVyc2lvbj0iMS4wIj48b2ZmaWNlOm1ldGE+PG1l dGE6Z2VuZXJhdG9yPk9wZW5PZmZpY2Uub3JnIDEuMC4yIChMaW51eCk8L21ldGE6Z2VuZXJhdG9y PjwhLS1TUkM2NDFfWzc2NjNdX0xJTlVYX0lOVEVMX19zeWx2ZXN0ZXIuZGV2ZWwucmVkaGF0LmNv bV9hdF8yLzIwLzAzXzEyOjMzOjQ1LS0+PG1ldGE6Y3JlYXRpb24tZGF0ZT4yMDA2LTA2LTAxVDEw OjQ1OjU1PC9tZXRhOmNyZWF0aW9uLWRhdGU+PGRjOmRhdGU+MjAwNi0wNi0wMVQxMTowNDo0NDwv ZGM6ZGF0ZT48ZGM6bGFuZ3VhZ2U+ZW4tVVM8L2RjOmxhbmd1YWdlPjxtZXRhOmVkaXRpbmctY3lj bGVzPjI8L21ldGE6ZWRpdGluZy1jeWNsZXM+PG1ldGE6ZWRpdGluZy1kdXJhdGlvbj5QVDE4TTQ5 UzwvbWV0YTplZGl0aW5nLWR1cmF0aW9uPjxtZXRhOnVzZXItZGVmaW5lZCBtZXRhOm5hbWU9Iklu Zm8gMSIvPjxtZXRhOnVzZXItZGVmaW5lZCBtZXRhOm5hbWU9IkluZm8gMiIvPjxtZXRhOnVzZXIt ZGVmaW5lZCBtZXRhOm5hbWU9IkluZm8gMyIvPjxtZXRhOnVzZXItZGVmaW5lZCBtZXRhOm5hbWU9 IkluZm8gNCIvPjxtZXRhOmRvY3VtZW50LXN0YXRpc3RpYyBtZXRhOnRhYmxlLWNvdW50PSIwIiBt ZXRhOmltYWdlLWNvdW50PSIyIiBtZXRhOm9iamVjdC1jb3VudD0iMCIgbWV0YTpwYWdlLWNvdW50 PSIxIiBtZXRhOnBhcmFncmFwaC1jb3VudD0iMTIiIG1ldGE6d29yZC1jb3VudD0iNzkiIG1ldGE6 Y2hhcmFjdGVyLWNvdW50PSI0MTUiLz48L29mZmljZTptZXRhPjwvb2ZmaWNlOmRvY3VtZW50LW1l dGE+UEsDBBQACAAIAJZQwTQAAAAAAAAAAAAAAAAMAAAAc2V0dGluZ3MueG1s7Vjdd6I4FH/fv8Ll dY8F7Uxbe1rngAq1H9YKYutbJLdKJyRsCKLz129AbacVZrsqe/ZhOceDITe/e3NzP3PxbRGQyhx4 5DN6qdSONKUC1GPYp9NLZeiY1TPlW/O3i9/b9y3nqd+psOdn34NzzLw4ACqqEQghaaNKf2jcdlsV paqq9yHQ+4zuiPGpqraddmU1bq+XVSQjVe30lIqyAjzCAivNi0J0KSWNzlfTl8pMiPBcVZnkw974 1DVNU1djZb1gQXz6/ZU+SZKj5DijrTUaDTWb3ZB6jD77019g19QVibLRwTutvcq+Ebl5sSJfA1d9 AUG6n8r6M0WB3Mnch+R1l0remvf0rqTXOSCHhcpmRixDOeNToTTrF+o2wudRb+FZ5MFq+8GOfCxm ueIe1xun+2FfgT+d5QpdO67VjncDt2csGQCW5gGtGaJTiD4wmDBGAFGlKXgMu/O4AoSBj2Y+AYOz JJJGUMToGZFoD04mY6J8Tl2agcMdw3AQ+GqAwqpPMSwAb59/vsNka2Tw4MvPWVEXfxA1EjxVTzP1 zT0cqsiZvtRO97D5Isf/enK6s5dG/oTAwX0/Qz10nMpAB0Uun8aTk72gDSYECw4cTsaMBY5E+mhn M8Z3V3AKaiJPMJ4PW9N2BO5GNhDwBGCTyw87+HHOx5+dsmh67ef5BDJHfi6jrgYxR0Lm5n+SWnWM +4gjB0kzsEPklRMi+zK2iAGktQN8DDyHwL+VJc0wxEjkBeGNaewGLVMhlwYHvMWCkEOUFj8HN+tM P7bUPYFrNinMu/ueQB+FwE3OAhtE/DFEHYxLGlP7qJTyIcPPbLUE8PSkhR4LtrKkkqRvMRkPGClL OcBzzxZFcPLF8CniS6UZT2//UDVMJoG7RKO76fDqOpzQAfGm+n/yGWrYdIhhu39POtL1O/nqZgNV PTN1yxjqevtsIsd20PAHlqk92fqiRQ2596/a+LHbGNTdePx4HT4tjQcvIDG23GUraMh5V/43NTRq xH3XmHt0sHwaEa0V9OaeRYj3Q5M4vZen0YL0nc7NZGQux3USjy3zT/zY0ybp+rYm7uzk7fcQvkzq i7kXSH1fDVjf6WpSlh8Ty62PR0njTn+bxwF5GTta0iLGw6DTm6dnBJ3BDFudm6Fl0rHbCyEYnjiW q6Uyl3oI/z//5nO5RwjQKWUiKwSKk+GOeUoPQ7IcRsDbSKDDRzDTB4LLjMA2moO7usC4py3CosM0 bNtMLMImiGwuftLypIyk3o1ugFM98hHtx9QTcXbqJTDSiT+lMu/agoV9FvklsWnFnEt1pcaVZqz0 bbOYe1tGvOpV1U/nxN52Sb/pdy2gwH2vsqbcw+9MtCjm81lZsy6vpOopp9bXhS1k1VNawclZFMqu qix8i6Nw5ntlFIPvTVEW/wGiOKfw3+e6YF2UT8FA3vcpZzEtbI4OvZP9rLTNUZI1mOUUsQaR+jBl obxL0Czso9Wtu2q16Oa9+RdQSwcIYIjI8FgEAAAiGAAAUEsDBBQACAAIAJZQwTQAAAAAAAAAAAAA AAAVAAAATUVUQS1JTkYvbWFuaWZlc3QueG1svZNRa8IwEMff9ymyvDfXqMMhVlGrMNimD/qwx9Be a6BNQ3M6/faLY1VBYThkeblcuPv9/+G4/nBXFmyLtdOVibgUIWdokirVJo/4ajkLnvlw8NB/jOeT 5cdiykpldIaOes2FLVbj15cJ4wHA3KKZZ5lOUFR1DhAvY/bW1Hk2wPSdM948iZRS7uGXTG/KuGMa 8TWR7QFUnl+d+K0wlNAUeRA7kTJdYICG6v2ZY0y1CmhvMeLK2kInivyvYWtS4TZGeFHxWWvCmp+a sk1RBFbROuLA4SYNXaocwZr8Om6hE9rU6ECG/rTC7xDKdvcnduJpu9UdybY4IP5FutNYGI2f5Kg7 k3+Q/kXxRhrhjsAP5jo1qQz55sPk7sp1tC/Q3R1bIqn7e0Uiv6xHt324WKfBF1BLBwhaFbNOMAEA AOYDAABQSwECFAAUAAAAAACWUME0gJBrfpsbAACbGwAALQAAAAAAAAAAAAAAAAAAAAAAUGljdHVy ZXMvMTAwMDAyMDEwMDAwMDEzNzAwMDAwMTM0REUzMjdBMTMucG5nUEsBAhQAFAAAAAAAllDBNLas V216HwAAeh8AAC0AAAAAAAAAAAAAAAAA5hsAAFBpY3R1cmVzLzEwMDAwMjAxMDAwMDAxMzQwMDAw MDEzN0FCNTFBN0YxLnBuZ1BLAQIUABQACAAIAJZQwTRWsvvJhAQAAJ8OAAALAAAAAAAAAAAAAAAA AKs7AABjb250ZW50LnhtbFBLAQIUABQACAAIAJZQwTRU/D0cAAUAAFMTAAAKAAAAAAAAAAAAAAAA AGhAAABzdHlsZXMueG1sUEsBAhQAFAAAAAAAllDBNIG7Q2liBAAAYgQAAAgAAAAAAAAAAAAAAAAA oEUAAG1ldGEueG1sUEsBAhQAFAAIAAgAllDBNGCIyPBYBAAAIhgAAAwAAAAAAAAAAAAAAAAAKEoA AHNldHRpbmdzLnhtbFBLAQIUABQACAAIAJZQwTRaFbNOMAEAAOYDAAAVAAAAAAAAAAAAAAAAALpO AABNRVRBLUlORi9tYW5pZmVzdC54bWxQSwUGAAAAAAcABwDaAQAALVAAAAAA --=-k0bJJnk7Qaq1V0+G97NB-- --0-596188450-1149245335=:1049-- From kris@babi-pangang.org Fri Jun 2 07:03:22 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 7783B3B03DE for ; Fri, 2 Jun 2006 07:03:22 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20299-05 for ; Fri, 2 Jun 2006 07:03:21 -0400 (EDT) Received: from nasi-goreng.babi-pangang.org (nasi-goreng.babi-pangang.org [83.166.137.20]) by menubar.gnome.org (Postfix) with ESMTP id 0CC793B0196 for ; Fri, 2 Jun 2006 07:03:20 -0400 (EDT) Received: by nasi-goreng.babi-pangang.org (Postfix, from userid 1000) id 417E73DCA0; Fri, 2 Jun 2006 13:03:18 +0200 (CEST) Date: Fri, 2 Jun 2006 13:03:17 +0200 From: Kristian Rietveld To: Tim Janik Message-ID: <20060602110317.GA10757@babi-pangang.org> References: <20060314132538.GA3526@babi-pangang.org> <443B4A8A.8000302@imendio.com> <20060425103017.GA15762@babi-pangang.org> <20060531183045.GA7564@babi-pangang.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.563 tagged_above=-999 required=2 tests=[AWL=0.036, BAYES_00=-2.599] X-Spam-Score: -2.563 X-Spam-Level: Cc: Gtk+ Developers , Soeren Sandmann Subject: Re: Callback based tooltips (Re: New tooltips API, continued) X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 11:03:22 -0000 On Thu, Jun 01, 2006 at 05:16:51PM +0200, Tim Janik wrote: > On Wed, 31 May 2006, Kristian Rietveld wrote: > > >On Tue, Apr 25, 2006 at 03:08:12PM +0200, Soeren Sandmann wrote: > >>I once wrote down how tooltips should behave: > > > >I mostly like the behaviour you described below. > > > >> - Tooltips are too intrusive. The text should be smaller, and > > not sure if this has been raised already... > the font size of the tooltips should be exactly as large as the default > font size (module tooltip markup of course) to avoid reducing usability > of the tooltips in contrast to normal text (labels). The text for default/simple tooltips using toolip-markup are drawn using the default GTK+ font at this point. FireFox does this too, it seems. -kris. From lists@nabble.com Fri Jun 2 07:11:06 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 15ADC3B10CE for ; Fri, 2 Jun 2006 07:11:06 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20935-09 for ; Fri, 2 Jun 2006 07:11:04 -0400 (EDT) Received: from talk.nabble.com (www.nabble.com [72.21.53.35]) by menubar.gnome.org (Postfix) with ESMTP id 7B8A53B0E85 for ; Fri, 2 Jun 2006 07:11:04 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=talk.nabble.com) by talk.nabble.com with esmtp (Exim 4.50) id 1Fm7YV-00067i-S9 for gtk-devel-list@gnome.org; Fri, 02 Jun 2006 04:11:03 -0700 Message-ID: <4677819.post@talk.nabble.com> Date: Fri, 2 Jun 2006 04:11:03 -0700 (PDT) From: heavenscape To: gtk-devel-list@gnome.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-Sender: masonduan1@sina.com X-Nabble-From: heavenscape X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.564 tagged_above=-999 required=2 tests=[AWL=0.037, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.564 X-Spam-Level: Subject: strange trouble in displaying a 8bit monochromy grey scale image X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 11:11:06 -0000 I need to display a 8 bit monochromy image with size of 2048x2048 pixels, all the image data are already loaded into memory, and out of which I created a 24 bit RGB buffer for the GdkPixbuf (please see code below) Well, the result is: The GtkImage widget was expanded to size of 2048x2048 pixels, THREE exactly same images tile in a row in the top of the GtkImage widget, each with size shrinked to 684x684 pixels, and all the lower 2/3 space is left blank.(see the attached image below) Can anyone please look at my code and give me some suggestion on this problem? I have been debugging is problem for almost one week time! Or I wonder if there is any other alternative mean to display a grey scale monochromy image. Any help is highly appriciated! following is my code: ...... char* pDisplayBuf = malloc(sizeX*sizeY*3); for(i=0;i X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 129D43B0401 for ; Fri, 2 Jun 2006 07:42:43 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22729-02 for ; Fri, 2 Jun 2006 07:42:41 -0400 (EDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.204]) by menubar.gnome.org (Postfix) with ESMTP id AACEB3B03DC for ; Fri, 2 Jun 2006 07:42:41 -0400 (EDT) Received: by wx-out-0102.google.com with SMTP id i30so488730wxd for ; Fri, 02 Jun 2006 04:42:41 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=gT1j5ejSD/b/CcxQn0QQsSvUHhFufm/g+0pbZR2i/XzGfNpGoCbQpb21JCQ8031mkn0Ki6u8pLPOMj7RR8l3DAglKtDDYSYHma6DaM5dCPwAcVKD9bRfW3lU8+yvbKvGFEapsCpgbG/Y1Pe5Z3GQWmSp7m88CvcAjjuc1aYqX10= Received: by 10.70.62.1 with SMTP id k1mr2290069wxa; Fri, 02 Jun 2006 04:42:41 -0700 (PDT) Received: by 10.70.96.6 with HTTP; Fri, 2 Jun 2006 04:42:40 -0700 (PDT) Message-ID: <522c6460606020442q5704285jefadb260aa5ceda1@mail.gmail.com> Date: Fri, 2 Jun 2006 12:42:40 +0100 From: "John Cupitt" To: heavenscape In-Reply-To: <4677819.post@talk.nabble.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4677819.post@talk.nabble.com> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.554 tagged_above=-999 required=2 tests=[AWL=0.046, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.554 X-Spam-Level: Cc: gtk-devel-list@gnome.org Subject: Re: strange trouble in displaying a 8bit monochromy grey scale image X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 11:42:43 -0000 On 6/2/06, heavenscape wrote: > char* pDisplayBuf = malloc(sizeX*sizeY*3); > for(i=0;i { > //create a gray scale img in the display buffer > pDisplayBuf[i+1]=pDisplayBuf[i+1]=pDisplayBuf[i+2] = pixel_value; > } This isn't going to work. You're only filling the first third of the memory area. How about (untested): // malloc() can return NULL: you need to test the result // g_malloc() cannot fail char *p = g_malloc(sizeX * sizeY * 3); char *q; int i; // i loops for number of pixels // q loops pointing at each RGB triplet in turn for (q = p, i = 0; i < sizeX * sizeY; i++, q += 3) q[0] = q[1] = q[2] = pixel_value; // or alternatively in this special case memset( p, sizeX * sizeY * 3, pixel_value ) From jcupitt@gmail.com Fri Jun 2 07:44:31 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C18CD3B0402 for ; Fri, 2 Jun 2006 07:44:31 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22729-06 for ; Fri, 2 Jun 2006 07:44:30 -0400 (EDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.202]) by menubar.gnome.org (Postfix) with ESMTP id 8F0073B0413 for ; Fri, 2 Jun 2006 07:44:30 -0400 (EDT) Received: by wx-out-0102.google.com with SMTP id i30so489124wxd for ; Fri, 02 Jun 2006 04:44:29 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=EMOfucJIundQbGeCrVxW4fD6Iz3tUALWFaW8hgWFjuzmGzy3HlOTtgzn8QGVrywRA62j6kzikELTcAJL+GvTNGqGag3vtyJIcBhy5nQKUdv8v5Gm6dzT8SPDVoRKsWY874GU5fTfTuEc6cSK5TYAaWH6Ezj7csUQ73y/uo1NF/8= Received: by 10.70.128.5 with SMTP id a5mr2255574wxd; Fri, 02 Jun 2006 04:44:29 -0700 (PDT) Received: by 10.70.96.6 with HTTP; Fri, 2 Jun 2006 04:44:29 -0700 (PDT) Message-ID: <522c6460606020444q6963f934g8d7b671fb87905b0@mail.gmail.com> Date: Fri, 2 Jun 2006 12:44:29 +0100 From: "John Cupitt" To: heavenscape In-Reply-To: <522c6460606020442q5704285jefadb260aa5ceda1@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4677819.post@talk.nabble.com> <522c6460606020442q5704285jefadb260aa5ceda1@mail.gmail.com> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.555 tagged_above=-999 required=2 tests=[AWL=0.045, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.555 X-Spam-Level: Cc: gtk-devel-list@gnome.org Subject: Re: strange trouble in displaying a 8bit monochromy grey scale image X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 11:44:31 -0000 On 6/2/06, John Cupitt wrote: > memset( p, sizeX * sizeY * 3, pixel_value ) Ahem, of course that should be memset (p, pixel_value, sizeX * sizeY * 3); From cerdiogenes@yahoo.com.br Fri Jun 2 09:09:23 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id BD1CF3B03D8 for ; Fri, 2 Jun 2006 09:09:23 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27976-05 for ; Fri, 2 Jun 2006 09:09:21 -0400 (EDT) Received: from cac-bdc03.unioeste.br (pop3.unioeste.br [200.201.8.21]) by menubar.gnome.org (Postfix) with ESMTP id 8FFCD3B0351 for ; Fri, 2 Jun 2006 09:09:20 -0400 (EDT) Received: from [200.201.81.39] (200.201.81.39 [200.201.81.39]) by cac-bdc03.unioeste.br with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id L71GDA45; Fri, 2 Jun 2006 10:07:46 -0300 From: Carlos Eduardo Rodrigues =?ISO-8859-1?Q?Di=F3genes?= To: =?ISO-8859-1?Q?=D8yvind_Kol=E5s?= In-Reply-To: <7bf6f2dc0606010816q15d512aejc30a6c93bc165e6@mail.gmail.com> References: <1149104973.27709.4.camel@localhost.localdomain> <7bf6f2dc0606010816q15d512aejc30a6c93bc165e6@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Date: Fri, 02 Jun 2006 10:01:52 -0300 Message-Id: <1149253312.4847.21.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.221 tagged_above=-999 required=2 tests=[AWL=0.043, BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.221 X-Spam-Level: Cc: gtk-devel-list@gnome.org Subject: Re: Color space transformations in GTK X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 13:09:23 -0000 On Thu, 2006-06-01 at 17:16 +0200, =D8yvind Kol=E5s wrote: > On 5/31/06, Carlos Eduardo Rodrigues Di=F3genes wrote: > > Hi, > > > > There is any plan to add color spaces conversions in GTK+ (GDK or > > Gdk-Pixbuf)? If the answear is no, why not? >=20 > Pixel format conversions is not a small piece of code and the needed > pixel formats varies from scenario to scenario. Most programs will not > need such a large general infrastructure and the ones that really need > it would probably not be satisfied with a simpler solution. I think that I understand your last argument. And what I really have in mind is a simple solution, more below... >=20 > What functionality is it you miss that you think fits into a GUI > toolkit? (color management is a seperate issue to color space(pixel > format) conversions according to my interpretation of your question). I had to make RGB <-> HSL conversions, because it's more intuitive change some color properties in the HSL color space. I thinked that we could have something like GdkColor for other color spaces and functions to convert between GdkColor and the other color spaces. I think that it will help who want to play with colors in a quick way. I don't find this in any other library, and I thinked that GTK+ could be a good place for this, because it will become easiest to work with other colors representations in GTK+ applications. >=20 > /=D8yvind K. --=20 Carlos Eduardo Rodrigues Di=F3genes Projeto xLupa - http://www.unioeste.br/projetos/xlupa From murrayc@murrayc.com Fri Jun 2 09:28:59 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id A768B3B112B for ; Fri, 2 Jun 2006 09:28:59 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28843-09 for ; Fri, 2 Jun 2006 09:28:58 -0400 (EDT) Received: from webmail1.sd.dreamhost.com (webmail1.sd.dreamhost.com [66.33.201.159]) by menubar.gnome.org (Postfix) with ESMTP id 953E83B111A for ; Fri, 2 Jun 2006 09:28:58 -0400 (EDT) Received: from webmail.murrayc.com (localhost [127.0.0.1]) by webmail1.sd.dreamhost.com (Postfix) with ESMTP id 9A66F2CAF2; Fri, 2 Jun 2006 06:23:41 -0700 (PDT) Received: from 194.138.18.132 (proxying for unknown) (SquirrelMail authenticated user murrayc@murrayc.com) by webmail.murrayc.com with HTTP; Fri, 2 Jun 2006 15:23:41 +0200 (CEST) Message-ID: <1464.194.138.18.132.1149254621.squirrel@webmail.murrayc.com> In-Reply-To: <1149253312.4847.21.camel@localhost.localdomain> References: <1149104973.27709.4.camel@localhost.localdomain> <7bf6f2dc0606010816q15d512aejc30a6c93bc165e6@mail.gmail.com> <1149253312.4847.21.camel@localhost.localdomain> Date: Fri, 2 Jun 2006 15:23:41 +0200 (CEST) From: "Murray Cumming" To: Carlos Eduardo Rodrigues =?iso-8859-1?Q?Di=F3genes?= User-Agent: SquirrelMail/1.4.6 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.481 tagged_above=-999 required=2 tests=[AWL=-0.036, BAYES_00=-2.599, TW_GT=0.077, TW_TK=0.077] X-Spam-Score: -2.481 X-Spam-Level: Cc: gtk-devel-list@gnome.org, =?iso-8859-1?Q?=D8yvind_Kol=E5s?= Subject: Re: Color space transformations in GTK X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 13:28:59 -0000 > On Thu, 2006-06-01 at 17:16 +0200, yvind Kols wrote: >> On 5/31/06, Carlos Eduardo Rodrigues Digenes >> wrote: >> > Hi, >> > >> > There is any plan to add color spaces conversions in GTK+ (GDK or >> > Gdk-Pixbuf)? If the answear is no, why not? >> >> Pixel format conversions is not a small piece of code and the needed >> pixel formats varies from scenario to scenario. Most programs will not >> need such a large general infrastructure and the ones that really need >> it would probably not be satisfied with a simpler solution. > > I think that I understand your last argument. And what I really have in > mind is a simple solution, more below... > >> >> What functionality is it you miss that you think fits into a GUI >> toolkit? (color management is a seperate issue to color space(pixel >> format) conversions according to my interpretation of your question). > > I had to make RGB <-> HSL conversions, because it's more intuitive > change some color properties in the HSL color space. I thinked that we > could have something like GdkColor for other color spaces and functions > to convert between GdkColor and the other color spaces. > > I think that it will help who want to play with colors in a quick way. I > don't find this in any other library, and I thinked that GTK+ could be a > good place for this, because it will become easiest to work with other > colors representations in GTK+ applications. In case it's useful, we have some old undocumented RGB <-> HSL color value conversion code in gtkmm here: http://cvs.gnome.org/viewcvs/gtkmm/gdk/src/color.ccg?view=markup (See set_hsl(), for instance) Murray Cumming murrayc@murrayc.com www.murrayc.com www.openismus.com From timj@gtk.org Fri Jun 2 10:28:42 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 270163B043C for ; Fri, 2 Jun 2006 10:28:42 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32586-01 for ; Fri, 2 Jun 2006 10:28:40 -0400 (EDT) Received: from webmail.hansenet.de (mail04.hansenet.de [213.191.73.12]) by menubar.gnome.org (Postfix) with ESMTP id 4C4283B0272 for ; Fri, 2 Jun 2006 10:28:40 -0400 (EDT) Received: from birnet.org (213.39.189.161) by webmail.hansenet.de (7.2.059) id 447C34F100154F1E; Fri, 2 Jun 2006 16:28:37 +0200 Received: from master.birnet.private (localhost [127.0.0.1]) by birnet.org (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k52ESaZY028846 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 2 Jun 2006 16:28:36 +0200 Received: (from timj@localhost) by master.birnet.private (8.13.4/8.13.4/Submit) id k52ESPMh028844; Fri, 2 Jun 2006 16:28:25 +0200 Date: Fri, 2 Jun 2006 16:28:25 +0200 (CEST) From: Tim Janik X-X-Sender: timj@master.birnet.private To: Stefan Kost In-Reply-To: <1148567274.9054.4.camel@fluffy.local> Message-ID: References: <1148567274.9054.4.camel@fluffy.local> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.442 tagged_above=-999 required=2 tests=[AWL=0.157, BAYES_00=-2.599] X-Spam-Score: -2.442 X-Spam-Level: Cc: Gtk+ Developers Subject: Re: Serialization in libgobject X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 14:28:42 -0000 On Thu, 25 May 2006, Stefan Kost wrote: > Hi Tim, > > thanks for the extensive comments and detailed concerns. Don't you think > it would be good to keep the buzzgilla issue open. Its an enhancement > request after all and there seems to be several people wanting to have > it. well, my concern is that most of them want/think different things about serialization which was the main point of my last email. i.e. if you want to cover beast's serialization need, you already need 2 different serializers. if you then also want to cover GStreamer needs, and maybe properly human digestible config files, you can easily end up with 3 or 4 sets of mutually exclusive requirements. so without precise definition of the usage cases: - the exact required behaviour of a GLib serializer isn't clear; - we'll end up with lots of projects still rolling their own serializer because the glib one doesn't cover their needs; - the serializer will be used in scenarios that it's unplanned and suboptimal for. i'm not saying the technical issues i raised are unsolvable, in fact each one has been adressed in one way or the other in beast's serializers. rather, i'm asking: 1) what exactly do we want in glib? (i.e. which use cases should be covered) 2) which use cases should be rejected by the glib implementation(s)? 3) do the answers to (1) and (2) really cover a broad range of serialization applications out there? and i think one of the best way to be sure and positively answer (3) could be the independent development of a serialization lib outside of glib. such a library could be included into glib at a later point, once its mature enough and has an adequate track record of applications. > The bugzilla issue could serve as a tracker item. And now maybe some > more people know about thsi and add their thoughts and ideas. if you still think this should be tracked in glib bugzilla as an enhancement, you can always reopen the report. > @Andrew: is you implementation public? If so where can I find the > sources, if not can you make the serialisation part public? > > Maybe we can find a SoC student for the next summer to look at the > solutions used in our application as come up with a good proposal that > suites most apps. > > Stefan > --- ciaoTJ From timj@gtk.org Fri Jun 2 12:59:30 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id AFEC23B0140 for ; Fri, 2 Jun 2006 12:59:30 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09573-08 for ; Fri, 2 Jun 2006 12:59:29 -0400 (EDT) Received: from webmail.hansenet.de (mail01.hansenet.de [213.191.73.61]) by menubar.gnome.org (Postfix) with ESMTP id 53B8C3B00A5 for ; Fri, 2 Jun 2006 12:59:29 -0400 (EDT) Received: from birnet.org (213.39.189.161) by webmail.hansenet.de (7.2.059) id 447D3FB2000A3052; Fri, 2 Jun 2006 18:59:16 +0200 Received: from master.birnet.private (localhost [127.0.0.1]) by birnet.org (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k52GxEAY001423 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 2 Jun 2006 18:59:14 +0200 Received: (from timj@localhost) by master.birnet.private (8.13.4/8.13.4/Submit) id k52GxETr001415; Fri, 2 Jun 2006 18:59:14 +0200 Date: Fri, 2 Jun 2006 18:59:13 +0200 (CEST) From: Tim Janik X-X-Sender: timj@master.birnet.private To: Owen Taylor Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.445 tagged_above=-999 required=2 tests=[AWL=0.154, BAYES_00=-2.599] X-Spam-Score: -2.445 X-Spam-Level: Cc: Gtk+ Developers Subject: locking around source_funcs->finalize X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 16:59:30 -0000 hi Owen. reading up on g_source_unref() again, i notice that the GMainContext lock is removed and re-acquired around callback_funcs->unref(), but not around source_funcs->finalize(); supposing you're unlocking around unref() so that the handler may do things like adding a new idle handler to the context, shouldnt the same semantics be provided for source_funcs->finalize() as well? > static void > g_source_unref_internal (GSource *source, > GMainContext *context, > gboolean have_lock) > { > gpointer old_cb_data = NULL; > GSourceCallbackFuncs *old_cb_funcs = NULL; > > g_return_if_fail (source != NULL); > > if (!have_lock && context) > LOCK_CONTEXT (context); > > source->ref_count--; > if (source->ref_count == 0) > { > old_cb_data = source->callback_data; > old_cb_funcs = source->callback_funcs; > > source->callback_data = NULL; > source->callback_funcs = NULL; > > if (context && !SOURCE_DESTROYED (source)) > { > g_warning (G_STRLOC ": ref_count == 0, but source is still attached to a context!"); > source->ref_count++; > } > else if (context) > g_source_list_remove (source, context); > > if (source->source_funcs->finalize) > source->source_funcs->finalize (source); lock is being held if have_lock || context. > > g_slist_free (source->poll_fds); > source->poll_fds = NULL; > g_free (source); > } > > if (!have_lock && context) > UNLOCK_CONTEXT (context); > > if (old_cb_funcs) > { > if (have_lock) > UNLOCK_CONTEXT (context); > > old_cb_funcs->unref (old_cb_data); no lock is being held. > > if (have_lock) > LOCK_CONTEXT (context); > } > } --- ciaoTJ From matthias.clasen@gmail.com Fri Jun 2 13:14:22 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 181063B0178 for ; Fri, 2 Jun 2006 13:14:22 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10341-10 for ; Fri, 2 Jun 2006 13:14:21 -0400 (EDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.188]) by menubar.gnome.org (Postfix) with ESMTP id A84F33B0115 for ; Fri, 2 Jun 2006 13:14:20 -0400 (EDT) Received: by nf-out-0910.google.com with SMTP id l37so1131753nfc for ; Fri, 02 Jun 2006 10:14:19 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=IIiw0EjBJce9nDArNbjwYFffpCUCNPuYeqI8uOIN+ycf/KtiNjAY9VtWweGXWApORefDRcNkzdsGRROn1FJvCDC494mL9vZcz0WpDA5tNFO1IZSXHXsfZPz+YqQUJ6orpi6MA7hmCcT7pTYK8vEfd8Pic7cApyoegcqYqJXL1U8= Received: by 10.49.1.9 with SMTP id d9mr941927nfi; Fri, 02 Jun 2006 10:14:19 -0700 (PDT) Received: by 10.48.215.7 with HTTP; Fri, 2 Jun 2006 10:14:19 -0700 (PDT) Message-ID: Date: Fri, 2 Jun 2006 13:14:19 -0400 From: "Matthias Clasen" To: "Tim Janik" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.699 tagged_above=-999 required=2 tests=[AWL=-0.734, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.558, SPF_PASS=-0.001, TW_GT=0.077] X-Spam-Score: -1.699 X-Spam-Level: Cc: Owen Taylor , Gtk+ Developers Subject: Re: locking around source_funcs->finalize X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 17:14:22 -0000 On 6/2/06, Tim Janik wrote: > hi Owen. > > reading up on g_source_unref() again, i notice that the > GMainContext lock is removed and re-acquired around > callback_funcs->unref(), but not around source_funcs->finalize(); > supposing you're unlocking around unref() so that the > handler may do things like adding a new idle handler > to the context, shouldnt the same semantics be provided > for source_funcs->finalize() as well? > Interesting observation Tim. We actually ran into a deadlock in the gtk print module code where a source finalize function was trying to add another idle... So fixing this would help GTK+; it would allow us to unload the print backends. Matthias From matthias.clasen@gmail.com Fri Jun 2 13:22:11 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id B05EA3B01BA for ; Fri, 2 Jun 2006 13:22:11 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10854-10 for ; Fri, 2 Jun 2006 13:22:10 -0400 (EDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.186]) by menubar.gnome.org (Postfix) with ESMTP id 691F63B007B for ; Fri, 2 Jun 2006 13:22:10 -0400 (EDT) Received: by nf-out-0910.google.com with SMTP id l37so1137364nfc for ; Fri, 02 Jun 2006 10:22:09 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=WQtzpP4N8ZyKSiiDfpj/VtLI/AxhPsWp029H1Nvd+SG7mq6Rf64PWWm4vH8TCDmIyieOgUdMr0+Y64igzWX+Liq5FKe/p14IvHTVc7Jf8A3g/lkQrbeGGqzHTAEGhQsu+lwlvRhqNYJVH8XXuOcmjrJxkEXrBrcqWzQyQ9CuNTg= Received: by 10.48.14.19 with SMTP id 19mr950281nfn; Fri, 02 Jun 2006 10:22:09 -0700 (PDT) Received: by 10.48.215.7 with HTTP; Fri, 2 Jun 2006 10:22:09 -0700 (PDT) Message-ID: Date: Fri, 2 Jun 2006 13:22:09 -0400 From: "Matthias Clasen" To: "Petr Tomasek" In-Reply-To: <20060602070042.GA3470@ebed.etf.cuni.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1149203639.27455.9.camel@localhost.localdomain> <20060602070042.GA3470@ebed.etf.cuni.cz> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.733 tagged_above=-999 required=2 tests=[AWL=-0.691, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.558, SPF_PASS=-0.001] X-Spam-Score: -1.733 X-Spam-Level: Cc: gtk-devel-list@gnome.org Subject: Re: Print preview api X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 17:22:11 -0000 On 6/2/06, Petr Tomasek wrote: > On Thu, Jun 01, 2006 at 07:13:59PM -0400, Matthias Clasen wrote: > > Ok, after a lot of work (mostly by John and Alex), > > we finally have a proposal for a print preview > > api that will allow us to use an external viewer > > by default, but also support internal preview. > > Hi! > > I think, this is very unfortunate. Many people will > not want to use the external viewer (for reasons discused > earlier), so everyone will write his own preview > widget? Why not just have official internal > preview widget like gnome-print has and support > it by deafult? You are more than welcome to on a high-quality print preview widget and propse it for inclusion; it is a considerable amount of work though (duplicating things that are already in evince), and we are not going to hold the 2.10 release for it. Defaulting to external preview allows us to release 2.10 with preview support, which seems better than no preview support at all. In other news, Alex has just committed the preview patch with some fixes. Matthias From kris@babi-pangang.org Fri Jun 2 19:04:03 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 6F8D73B051E for ; Fri, 2 Jun 2006 19:04:03 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29568-08 for ; Fri, 2 Jun 2006 19:04:02 -0400 (EDT) Received: from nasi-goreng.babi-pangang.org (nasi-goreng.babi-pangang.org [83.166.137.20]) by menubar.gnome.org (Postfix) with ESMTP id 2B5243B04C8 for ; Fri, 2 Jun 2006 19:04:01 -0400 (EDT) Received: by nasi-goreng.babi-pangang.org (Postfix, from userid 1000) id BC1643DCA0; Sat, 3 Jun 2006 01:03:59 +0200 (CEST) Date: Sat, 3 Jun 2006 01:03:59 +0200 From: Kristian Rietveld To: Matthias Clasen Message-ID: <20060602230359.GB10757@babi-pangang.org> References: <20060531200823.GA7846@babi-pangang.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.525 tagged_above=-999 required=2 tests=[AWL=-0.003, BAYES_00=-2.599, TW_GT=0.077] X-Spam-Score: -2.525 X-Spam-Level: Cc: gtk-devel-list@gnome.org, timj@imendio.com Subject: Re: Tooltips progress X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 23:04:03 -0000 On Thu, Jun 01, 2006 at 09:33:48AM -0400, Matthias Clasen wrote: > Using x == -1 to indicate a keyboard-triggered tooltip looks a bit > odd to me; how about adding a boolean parameter for this ? Good idea, fixed this. > Regarding dedicated treeview api, I think we can do without it > (at least initially), if we have a good example in the docs. Though > lots of people will forget the selection_changed thing for keyboard > tooltips... I'll make sure some nice example code will appear in gtk-demo, where we can point people at. > Could you enhance your demo with an example of text view > tooltips on a tag ? Will do. -kris. From kris@babi-pangang.org Fri Jun 2 19:08:42 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 1CF883B11C6 for ; Fri, 2 Jun 2006 19:08:42 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29930-06 for ; Fri, 2 Jun 2006 19:08:40 -0400 (EDT) Received: from nasi-goreng.babi-pangang.org (nasi-goreng.babi-pangang.org [83.166.137.20]) by menubar.gnome.org (Postfix) with ESMTP id 89C933B11CD for ; Fri, 2 Jun 2006 19:08:40 -0400 (EDT) Received: by nasi-goreng.babi-pangang.org (Postfix, from userid 1000) id 411F73DCA0; Sat, 3 Jun 2006 01:08:37 +0200 (CEST) Date: Sat, 3 Jun 2006 01:08:37 +0200 From: Kristian Rietveld To: Tim Janik Message-ID: <20060602230837.GC10757@babi-pangang.org> References: <20060531200823.GA7846@babi-pangang.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.563 tagged_above=-999 required=2 tests=[AWL=0.036, BAYES_00=-2.599] X-Spam-Score: -2.563 X-Spam-Level: Cc: Gtk+ Developers Subject: Re: Tooltips progress X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 23:08:42 -0000 On Thu, Jun 01, 2006 at 06:21:29PM +0200, Tim Janik wrote: > On Thu, 1 Jun 2006, Matthias Clasen wrote: > the idea behind ::has-tooltip is to reduce the number of required signal > emissions to figure a tooltip. e.g. by adding a PRIVATE_GTK_* flag that > indicates if the ::query-tooltips() emission is neccessary. > maybe it'd helpt to rename that property to ::can-tooltip? Or maybe ::enable-query-tooltip? > (if you want to argue consistency with other things settable/gettable > on widgets though, then yes, you have a point for also exporting it > as a property) I would tend to add the property just for consistency. > >The example doesn't show tooltips constructed using the old tooltips > >api, but I assume those will continue to work as before, right ? > > that was the plan, i.e. you'd basically just do: I am not 100% if we can implement the complete old API using the new one, for example the public fields in the old structures and GtkTipsQuery come to mind ... I'll investigate once I get a first patch out. -kris. From exe522@hotmail.com Mon Jun 5 10:30:49 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id E7BDF3B0420 for ; Mon, 5 Jun 2006 10:30:48 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06214-09 for ; Mon, 5 Jun 2006 10:30:45 -0400 (EDT) Received: from hotmail.com (bay104-f19.bay104.hotmail.com [65.54.175.29]) by menubar.gnome.org (Postfix) with ESMTP id 81AC13B030D for ; Mon, 5 Jun 2006 10:30:44 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 5 Jun 2006 07:30:43 -0700 Message-ID: Received: from 65.54.175.200 by by104fd.bay104.hotmail.msn.com with HTTP; Mon, 05 Jun 2006 14:30:41 GMT X-Originating-IP: [83.202.13.252] X-Originating-Email: [exe522@hotmail.com] X-Sender: exe522@hotmail.com In-Reply-To: <44747D3E.8020902@imendio.com> From: "Malik NakaMura" To: richard@imendio.com Date: Mon, 05 Jun 2006 14:30:41 +0000 Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed X-OriginalArrivalTime: 05 Jun 2006 14:30:43.0753 (UTC) FILETIME=[A0A49190:01C688AC] X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-0.739 tagged_above=-999 required=2 tests=[AWL=-1.535, BAYES_05=-1.11, DNS_FROM_RFC_ABUSE=0.2, DNS_FROM_RFC_POST=1.708, MSGID_FROM_MTA_HEADER=0, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -0.739 X-Spam-Level: Cc: otaylor@redhat.com, ben2004uk@googlemail.com, scott@asofyet.org, gtk-devel-list@gnome.org Subject: Re: GTK+ >> Cocoa Native Port X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2006 14:30:49 -0000 Hi, I'm trying to implement this function : _gdk_quartz_copy_to_image (gdkimage-quartz.c) I would like to know if it is possible to get the pixels table from a GdkPixmap structure ? this is the code : GdkImage * _gdk_quartz_copy_to_image (GdkDrawable *drawable, GdkImage *image, gint src_x, gint src_y, gint dest_x, gint dest_y, gint width, gint height) { /* FIXME: Implement */ // Image Creation image = g_object_new (gdk_image_get_type (), NULL); image->width = width; image->height = height; image->byte_order = (G_BYTE_ORDER == G_LITTLE_ENDIAN) ? GDK_LSB_FIRST : GDK_MSB_FIRST; image->bpp = 4; image->bpl = image->width * image->bpp; image->bits_per_pixel = image->bpp * 8; // Get the Visual GdkColormap *colormap = gdk_drawable_get_colormap (drawable); if(colormap != NULL) { image->visual = gdk_colormap_get_visual (colormap); } // Get the depth image->depth = GDK_PIXMAP_OBJECT (drawable)->depth; // Get the pixels ??? image->mem = g_malloc (image->bpl * image->height); memset (image->mem, 0x00, image->bpl * image->height); image->mem = gdk_pixbuf_get_pixels (GDK_PIXBUF (drawable)); return image; } I think that drawable is a GdkPixmap structure, so I cant do GDK_PIXBUF (drawable), but is there a function to get the pixbuf from a pixmap ? From domlachowicz@gmail.com Mon Jun 5 10:52:51 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id B05E13B0543 for ; Mon, 5 Jun 2006 10:52:51 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08008-05 for ; Mon, 5 Jun 2006 10:52:48 -0400 (EDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.205]) by menubar.gnome.org (Postfix) with ESMTP id 0DD8B3B03E7 for ; Mon, 5 Jun 2006 10:52:47 -0400 (EDT) Received: by wx-out-0102.google.com with SMTP id i30so1182797wxd for ; Mon, 05 Jun 2006 07:52:47 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=mBHtGZClxJk0twUjUBnjIyhM/WAD6Uo9my7i+D5hoC4J+tCoUbUHFxNQxrI4rHUN+ozS7wnRgFO+uMkkEg6Pg2xZje4D8Xja5Bt7lmKFvCh6pSZMS6uV+5TpBquvMmVoaoFkNDoZEDJjdLqt3Wj9IaLQ/ggRMyfDTkEaz5x0TcU= Received: by 10.70.49.6 with SMTP id w6mr6127550wxw; Mon, 05 Jun 2006 07:52:44 -0700 (PDT) Received: by 10.70.116.12 with HTTP; Mon, 5 Jun 2006 07:52:44 -0700 (PDT) Message-ID: <2672cf4d0606050752o12a6d0d2gcb4c355cc0f35d79@mail.gmail.com> Date: Mon, 5 Jun 2006 10:52:44 -0400 From: "Dominic Lachowicz" To: "Malik NakaMura" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <44747D3E.8020902@imendio.com> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.457 tagged_above=-999 required=2 tests=[AWL=0.143, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.457 X-Spam-Level: Cc: gtk-devel-list@gnome.org Subject: Re: GTK+ >> Cocoa Native Port X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2006 14:52:51 -0000 > I think that drawable is a GdkPixmap structure, so I cant do GDK_PIXBUF > (drawable), but is there a function to get the pixbuf from a pixmap ? You might want to look at gdk_pixbuf_get_from_drawable(). Best, Dom -- Counting bodies like sheep to the rhythm of the war drums. From mclasen@redhat.com Mon Jun 5 14:15:03 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 744343B09D3; Mon, 5 Jun 2006 14:15:03 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20278-06; Mon, 5 Jun 2006 14:15:01 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id D637E3B0988; Mon, 5 Jun 2006 14:15:00 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k55IF08I024331; Mon, 5 Jun 2006 14:15:00 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k55IF0I9021827; Mon, 5 Jun 2006 14:15:00 -0400 Received: from golem.boston.redhat.com (golem.boston.redhat.com [172.16.80.24]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id k55IExAV012588; Mon, 5 Jun 2006 14:14:59 -0400 From: Matthias Clasen To: gnome-announce-list@gnome.org, gtk-devel-list@gnome.org, gtk-app-devel-list@gnome.org, gtk-list@gnome.org Content-Type: text/plain; charset=UTF-8 Date: Mon, 05 Jun 2006 14:14:59 -0400 Message-Id: <1149531299.4071.35.camel@golem.boston.redhat.com> Mime-Version: 1.0 X-Mailer: Evolution 2.7.1 (2.7.1-1) Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.543 tagged_above=-999 required=2 tests=[AWL=0.058, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.543 X-Spam-Level: Cc: Subject: GLib 2.11.2 released X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gnome-hackers@gnome.org List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2006 18:15:03 -0000 GLib 2.11.2 is now available for download at: ftp://ftp.gtk.org/pub/gtk/v2.11/ http://ftp.gnome.org/pub/GNOME/sources/glib/2.11/ glib-2.11.2.tar.bz2 md5sum: 18464b85bfd589f83897623c637a1553 glib-2.11.2.tar.gz md5sum: f728cd295ac98d4b95d850fe91c05fd5 This is a development release leading up to GLib 2.12. Notes: * This is unstable development release. While it has had a bit of testing, there are certainly plenty of bugs remaining to be found. This release should not be used in production. * Installing this version will overwrite your existing copy of GLib 2.10. If you have problems, you'll need to reinstall GLib 2.10. * GLib 2.12 will be source and binary compatible with the GLib 2.10.x series (for some caveats, see the README). At this point, the API additions in the 2.11.x series are almost finished. * Bugs should be reported to http://bugzilla.gnome.org. About GLib ========== GLib is the low-level core library that forms the basis for projects such as GTK+ and GNOME. It provides data structure handling for C, portability wrappers, and interfaces for such runtime functionality as an event loop, threads, dynamic loading, and an object system. More information about GLib is available at: http://www.gtk.org/ An installation guide for the GTK+ libraries, including GLib, can be found at: http://developer.gnome.org/doc/API/2.0/gtk/gtk-building.html Overview of Changes from GLib 2.11.1 to GLib 2.11.2 =================================================== * Add g_ascii_stroll to parse signed 64bit integers * GMarkup: add a flag to treat CDATA as text * GHashTable: add functions to remove all entries * GMainLoop: add functions to find the currently running source, and determine if it is destroyed * Bug fixes: 342563 g_atomic_thread_init() needs to be called before other _g_*_thread_init() functions 343548 Potential use after free in callers of g_string_free() 168538 Wish: Clearing contents of GHashTables 321886 GTK+ cannot be reliably used in multi-threaded applications 341826 goption.c: 'strtoll' is C99's function 343899 g_ascii_formatd dosn't work as expected for all format strings 317793 Make GEnumValue strings const 337129 Compile warnings in G_IMPLEMENT_INTERFACE 303622 What is G_TYPE_CHAR? * Updated translations (bg,dz,eu,gl,ja,nl,th,vi) A list of all bugs fixed in this release can be found at: http://bugzilla.gnome.org/buglist.cgi?bug_id=341826,342563,343548,168538,168538,321886,343899,321886,317793,337129,303622 Thanks to everybody who has contributed to this release, in the form of bug reports or patches: Peter Kjellerstedt, Kazuki Iwamoto Leonard den Ottolander, Chris Wilson, Behdad Esfahbod, Matt Barnes, ystein Johansen, Tim Janik Morten Welinder Matthias Clasen June 5, 2006 From mclasen@redhat.com Mon Jun 5 16:21:34 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 09B113B0543; Mon, 5 Jun 2006 16:21:34 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28553-01; Mon, 5 Jun 2006 16:21:32 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id 0F8903B0012; Mon, 5 Jun 2006 16:21:31 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k55KLVn7006951; Mon, 5 Jun 2006 16:21:31 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k55KLUBq020469; Mon, 5 Jun 2006 16:21:31 -0400 Received: from golem.boston.redhat.com (golem.boston.redhat.com [172.16.80.24]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id k55KLUAV025318; Mon, 5 Jun 2006 16:21:30 -0400 From: Matthias Clasen To: gnome-announce-list@gnome.org, gtk-devel-list@gnome.org, gtk-app-devel-list@gnome.org, gtk-list@gnome.org Content-Type: text/plain Date: Mon, 05 Jun 2006 16:21:30 -0400 Message-Id: <1149538890.4071.40.camel@golem.boston.redhat.com> Mime-Version: 1.0 X-Mailer: Evolution 2.7.1 (2.7.1-1) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.429 tagged_above=-999 required=2 tests=[AWL=-0.059, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, TW_GD=0.077, TW_GT=0.077, TW_XI=0.077] X-Spam-Score: -2.429 X-Spam-Level: Cc: Subject: GTK+ 2.9.2 released X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gnome-hackers@gnome.org List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2006 20:21:34 -0000 GTK+ 2.9.2 is now available for download at: http://ftp.gnome.org/pub/gnome/sources/gtk+/2.9/ gtk+-2.9.2.tar.gz md5sum: c63e7d0cf7c4e983206c3088a0fb8862 gtk+-2.9.2.tar.bz2 md5sum: 17629437af44fce03485101371c8f041 This is a development release leading up to GTK+ 2.10. Notes: * This is unstable development release. There are certainly plenty of bugs remaining to be found. This release should not be used in production. * Installing this version will overwrite your existing copy of GTK+ 2.8. If you have problems, you'll need to reinstall GTK+ 2.8. * GTK+ 2.10 will be source compatible with the GTK+ 2.8 series; the new API additions in GTK+ 2.9.0 are not yet completely finalized, so there are likely incompatibilies between this release and the final 2.10 release. * The ABI version has been bumped from 2.4.0 to 2.10.0, since the filechooser backend interface has been changed. Third-party filechooser backends need to be ported to the new interface. Other third-party modules (input methods, image loaders, etc) just need to be reinstalled in the proper location for GTK+ to find them. * Remaining issues for GTK+ 2.10 can be found with following bugzilla query: http://bugzilla.gnome.org/buglist.cgi?product=gtk%2b&target_milestone=2.10+API+Freeze&target_milestone=2.10+Freeze&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED * Bugs should be reported to http://bugzilla.gnome.org. What is GTK+ ============ GTK+ is a multi-platform toolkit for creating graphical user interfaces. Offering a complete set of widgets, GTK+ is suitable for projects ranging from small one-off tools to complete application suites. GTK+ has been designed from the ground up to support a range of languages, not only C/C++. Using GTK+ from languages such as Perl and Python (especially in combination with the Glade GUI builder) provides an effective method of rapid application development. GTK+ is free software and part of the GNU Project. However, the licensing terms for GTK+, the GNU LGPL, allow it to be used by all developers, including those developing proprietary software, without any license fees or royalties. Where to get more information about GTK+ ======================================== Information about GTK+ including links to documentation can be found at: http://www.gtk.org/ An installation guide for GTK+ 2.x is found at: http://developer.gnome.org/doc/API/2.4/gtk/gtk-building.html Common questions: http://developer.gnome.org/doc/API/2.4/gtk/gtk-question-index.html http://www.gtk.org/faq/ Overview of Changes from GTK+ 2.9.1 to 2.9.2 ============================================ * GtkPrintOperation - Support asynchronous pagination with the ::paginate signal - Add gtk_print_operation_cancel - Support application-specific widgets - Allow disabling features based on application capabilities - Optionally show progress - Change some function names in GtkPrintContext to be longer and better - Support preview, the default implementation spawns evince, but the api allows for an internal preview implementation * GtkCellView - Add a model property * GtkStatusIcon - Allow to obtain screen geometry * GtkTreeView - Many bug fixes, in particular for RTL handling - Separate sensitive and selectable properties of rows - Optionally allow rubberband selection * GtkButton - Add image-spacing style property - Add image-position property * GtkToolButton - Add icon-spacing style property * Make GTK+ work as an untrused X client * Bugs fixed: 343838 gtkprintoperationpreview.h guards 305530 Crashes while creating source code w/GtkFontSelection 341327 Memory corruption inside glib 341734 cursor blocked to dnd mode after using shift and dnd on a GtkCalendar 343453 G_DEFINE_TYPE messes up internal typenames of GdkWindow and GdkPixmap 136571 Problems running as untrusted client 168105 the right edge tab does not appear when switching tab 172535 Add support for UI builders in gtk+ 302556 GtkTreeView widget signals are badly documented 324480 Selecting first item with keyboard is difficult 340428 small cleanup 340444 don't run the custom page size dialogue 340839 Critical warnings in GtkTreeModelFilter 341898 gtk_tree_view_insert_column_with_attributes doesn't work with fixed_height_mode 342003 DnD: Conditional jump or move depends on uninitialised value 342072 Wrong drop location in GtkEntry 342096 GtkImage animation CRITICALS on switching themes 342513 widget class style property with type module 342529 gdk should set resolution on PangoCairoFontmap, not PangoCairoContext 342535 Add documentation for new GtkWidget style properties (including Since tags) 342543 can't compile gtk+ on opensolaris using sun cc 342569 Typo in decl of gdk_color_parse 342752 Need a way to specify custom tab label for custom page in Print dialog 342754 print-editor: font button dialog doesn't get focus if main window has a window group 342781 GtkPrintUnixDialog: Collate should be insensitive unless Copies is > 1 342783 GtkPrintUnixDialog: Range textinput area should be insensitive unless range radiobutton is selected 342894 Use after free inside gtk_text_view_set_buffer 342930 GtkButton should offer a way to position the image relative to the text 343088 Some typos in the PO file 343425 "grab-notify"-signal is not correctly propagated for internal children 343438 gtk_color_button_set_color() doesn't emit "color-set" signal 343475 page setup unix dialog confusion 343625 allow to get only some info from gtk_status_icon_get_geometry 343677 GtkWindow chains key-release to key-press 320431 Text too close when using East/West in a GtkToolButton 321523 GtkTreeView's test_expand_row signal emitting impractical on row expand all 342007 Warning in gtk_paned_compute_position 343233 gdk_rectangle_intersect doc 333284 expander animation not working in RTL mode 343444 change color of gtk-demo source-buffer comment color from red to DodgerBlue 343630 Small inconsistence in migration documentation 80127 Rubberbanding for GtkTreeView 341450 status icon + libnotify 341679 Allow absolute filenames in the options entries * Updated translations (bg,cy,de,el,es,et,eu,gl,gu,it,ja, nb,nl,pt_BR,th,vi) Thanks to everybody who has contributed to this release, in the form of bug reports or patches: Alexander Larsson, Behdad Esfahbod, Benjamin Berg, Caolan McNamara, Carlos Garnacho Parro, Carol Spears, Christian Persch, Chris Wilson, Claudio Saavedra, Clytie Siddall, Damon Chaplin, Daniel Lindenaar, Dan Winship, Diana Fong, Ed Catmur, Emmanuele Bassi, Havoc Pennington, Henrique Romano, Hiroyuki Ikezoe, James Moger, Johan Dahlin, Kouhei Sutou, Kristian Rietveld, Markku Vire, Mart Raudsepp, Masatake Yamato, Michael Emmel, Michael Natterer, Murray Cumming, Olexiy Avramchenko, Paolo Borelli, Patrick Monnerat, Richard Hult, Sampo Savolainen, Sebastien Bacher, Srirama Sharma, Stefan Kost, Tim Janik, Tommi Komulainen, Tor Lillqvist, Yevgen Muntyan A list of all bugs fixed in this release can be found at: http://bugzilla.gnome.org/buglist.cgi?bug_id=342072,342096,342003,341734,305530,168105,342007,342529,342535,342543,342569,341679,342752,172535,342513,342781,342783,342754,136571,341450,333284,340428,340839,341898,321523,343088,343233,324480,342894,320431,342930,343453,343425,343438,343444,340444,343475,302556,343677,343625,80127,343838,341327,168105,343630 Matthias Clasen June 5, 2006 From otaylor@redhat.com Mon Jun 5 18:10:18 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 606843B039F for ; Mon, 5 Jun 2006 18:10:18 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03967-08 for ; Mon, 5 Jun 2006 18:10:17 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id CAF5C3B0389 for ; Mon, 5 Jun 2006 18:10:16 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k55MAGwn013331; Mon, 5 Jun 2006 18:10:16 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k55MAGNr013297; Mon, 5 Jun 2006 18:10:16 -0400 Received: from localhost.localdomain (sebastian-int.corp.redhat.com [172.16.52.221]) by devserv.devel.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k55MAFJC021457; Mon, 5 Jun 2006 18:10:15 -0400 From: Owen Taylor In-Reply-To: <2672cf4d0606050752o12a6d0d2gcb4c355cc0f35d79@mail.gmail.com> References: <44747D3E.8020902@imendio.com> <2672cf4d0606050752o12a6d0d2gcb4c355cc0f35d79@mail.gmail.com> Content-Type: text/plain Date: Mon, 05 Jun 2006 15:10:09 -0400 Message-Id: <1149534609.2441.107.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 (2.6.1-1.fc5.2) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.187 tagged_above=-999 required=2 tests=[AWL=-0.199, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.478, FORGED_RCVD_HELO=0.135, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.187 X-Spam-Level: Cc: gtk-devel-list@gnome.org Subject: Re: GTK+ >> Cocoa Native Port X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2006 22:10:18 -0000 On Mon, 2006-06-05 at 10:52 -0400, Dominic Lachowicz wrote: > > I think that drawable is a GdkPixmap structure, so I cant do GDK_PIXBUF > > (drawable), but is there a function to get the pixbuf from a pixmap ? > > You might want to look at gdk_pixbuf_get_from_drawable(). Not going to help here, I think .. copy_to_image() is the backend function used to implement gdk_pixbuf_get_from_drawable(). :-) This is the point in the code where you need to figure out how to copy pixels from a native drawable into an image buffer, which is going to involve native graphics system calls. If you can find docs on how to take a screenshot of a window in OS X, that will be similar code to what is needed here. Owen From rpmcruz@clix.pt Mon Jun 5 21:41:34 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id B9E363B03FB for ; Mon, 5 Jun 2006 21:41:34 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15260-05 for ; Mon, 5 Jun 2006 21:41:33 -0400 (EDT) Received: from mailrly02.isp.novis.pt (mailrly02.isp.novis.pt [195.23.133.212]) by menubar.gnome.org (Postfix) with ESMTP id 84DA33B0076 for ; Mon, 5 Jun 2006 21:41:32 -0400 (EDT) Received: (qmail 21302 invoked from network); 6 Jun 2006 01:41:30 -0000 Received: from unknown (HELO mailfrt04.isp.novis.pt) ([195.23.133.196]) (envelope-sender ) by mailrly02.isp.novis.pt with compressed SMTP; 6 Jun 2006 01:41:30 -0000 Received: (qmail 17342 invoked from network); 6 Jun 2006 01:41:29 -0000 Received: from unknown (HELO [10.0.0.2]) (Sent_by_authenticated_user_x2476431@[87.196.74.232]) (envelope-sender ) by mailfrt04.isp.novis.pt with SMTP; 6 Jun 2006 01:41:29 -0000 From: Ricardo Cruz To: gtk-devel-list@gnome.org Date: Tue, 6 Jun 2006 02:48:21 +0100 User-Agent: KMail/1.9.1 X-Face: $29d{(U~(^/X.rR|7i6syM3jeJ}N+*%U-#Bzl5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200606060248.21205.rpmcruz@clix.pt> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.657 tagged_above=-999 required=2 tests=[AWL=-0.917, BAYES_20=-0.74] X-Spam-Score: -1.657 X-Spam-Level: Subject: GtkComboBoxEntry -- changing entry line value X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2006 01:41:34 -0000 Hi there, Is there a way to set a value for a GtkComboBoxEntry line entry? I am currently just adding an entry, set it as selected and remove it, which is a pretty nasty work-around. By the way, is it planned to add a GtkEditable interface for it? That would be really sweet and, if affirmitive, I could work on making a patch. Cheers, Ricardo -- Fourth Law of Thermodynamics: If the probability of success is not almost one, it is damn near zero. -- David Ellis From markku.vire@kolumbus.fi Tue Jun 6 04:39:15 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 5E3DD3B0C57 for ; Tue, 6 Jun 2006 04:39:15 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23318-01 for ; Tue, 6 Jun 2006 04:39:13 -0400 (EDT) Received: from fep02-app.kolumbus.fi (fep02-0.kolumbus.fi [193.229.0.44]) by menubar.gnome.org (Postfix) with ESMTP id C21BF3B0A19 for ; Tue, 6 Jun 2006 04:37:26 -0400 (EDT) Received: from smtp.kolumbus.fi ([193.229.55.124]) by fep02-app.kolumbus.fi with ESMTP id <20060606083725.NGAZ5174.fep02-app.kolumbus.fi@smtp.kolumbus.fi>; Tue, 6 Jun 2006 11:37:25 +0300 X-Mailer: Openwave WebEngine, version 2.8.12 (webedge20-101-197-20030912) X-Originating-IP: [62.236.91.3] From: To: Ricardo Cruz , Date: Tue, 6 Jun 2006 11:37:24 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <20060606083725.NGAZ5174.fep02-app.kolumbus.fi@smtp.kolumbus.fi> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.504 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, NO_REAL_NAME=0.961, SPF_PASS=-0.001] X-Spam-Score: -1.504 X-Spam-Level: X-Mailman-Approved-At: Tue, 06 Jun 2006 07:05:18 -0400 Cc: Subject: Re: GtkComboBoxEntry -- changing entry line value X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2006 08:39:15 -0000 Hi, You can get the entry by calling gtk_bin_get_child(box); and then using any methods of GtkEntry to manipulate the text. > Is there a way to set a value for a GtkComboBoxEntry line entry? I am > currently just adding an entry, set it as selected and remove it, which is a > pretty nasty work-around. -Markku- From markku.vire@kolumbus.fi Tue Jun 6 04:39:55 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 544743B0B78 for ; Tue, 6 Jun 2006 04:39:55 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23288-09 for ; Tue, 6 Jun 2006 04:39:52 -0400 (EDT) Received: from fep02-app.kolumbus.fi (fep02-0.kolumbus.fi [193.229.0.44]) by menubar.gnome.org (Postfix) with ESMTP id BD56C3B0A19 for ; Tue, 6 Jun 2006 04:39:51 -0400 (EDT) Received: from smtp.kolumbus.fi ([193.229.55.124]) by fep02-app.kolumbus.fi with ESMTP id <20060606083950.NHYK5174.fep02-app.kolumbus.fi@smtp.kolumbus.fi>; Tue, 6 Jun 2006 11:39:50 +0300 X-Mailer: Openwave WebEngine, version 2.8.12 (webedge20-101-197-20030912) X-Originating-IP: [62.236.91.3] From: To: Ricardo Cruz , Date: Tue, 6 Jun 2006 11:39:50 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <20060606083950.NHYK5174.fep02-app.kolumbus.fi@smtp.kolumbus.fi> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.504 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, NO_REAL_NAME=0.961, SPF_PASS=-0.001] X-Spam-Score: -1.504 X-Spam-Level: X-Mailman-Approved-At: Tue, 06 Jun 2006 07:05:18 -0400 Cc: Subject: Re: GtkComboBoxEntry -- changing entry line value X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2006 08:39:55 -0000 Hi, You can get the entry by calling gtk_bin_get_child(box); and then using any methods of GtkEntry to manipulate the text. > Is there a way to set a value for a GtkComboBoxEntry line entry? I am > currently just adding an entry, set it as selected and remove it, which is a > pretty nasty work-around. -Markku- From federico@ximian.com Tue Jun 6 11:45:51 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id A23E83B00FF for ; Tue, 6 Jun 2006 11:45:51 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01904-10 for ; Tue, 6 Jun 2006 11:45:35 -0400 (EDT) Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) by menubar.gnome.org (Postfix) with ESMTP id 6D4083B0ADD for ; Tue, 6 Jun 2006 11:45:33 -0400 (EDT) Received: (qmail 15590 invoked from network); 6 Jun 2006 15:45:31 -0000 Received: from localhost (HELO ?164.99.120.162?) (127.0.0.1) by localhost with SMTP; 6 Jun 2006 15:45:31 -0000 From: Federico Mena Quintero To: GTK+ development mailing list Content-Type: text/plain Date: Tue, 06 Jun 2006 10:41:22 -0500 Message-Id: <1149608483.14088.54.camel@cacharro.xalalinux.org> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.574 tagged_above=-999 required=2 tests=[AWL=0.025, BAYES_00=-2.599] X-Spam-Score: -2.574 X-Spam-Level: Cc: Michael.meeks@novell.com Subject: Default timeouts X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2006 15:45:51 -0000 In gtksettings.c we have #define DEFAULT_TIMEOUT_INITIAL 200 #define DEFAULT_TIMEOUT_REPEAT 20 for the "gtk-timeout-initial" and "gtk-timeout-repeat" settings, respectively. This means we wait for a fifth of a second before we start repeating, but then we try to repeat 50 times per second. Isn't the repeat timeout way too short? This is why clicking on a calendar arrow takes you back tens of months in no time, and also makes it hard to use spin buttons. Also, Michael Meeks has the following words of wisdom in a Novell bug about the calendar in gnome-panel's clock: > In essence the timeout is way too short for switching days; also - > in the panel applet the timeout has a higher priority than the > queued resize of the display (and hence the redraw) - so in > essence we skip days even faster since we never have to render > them. > > Lowering the priority there, and lengthening the timeouts gives > a far more reasonable, usable experience without getting rid > of the whole auto-repeat principle [...] I.e. instead of using g_timeout_add() in gtkcalendar, we would use g_timeout_add_full (G_PRIORITY_DEFAULT_IDLE, ...), or perhaps (GDK_PRIORITY_REDRAW + positive_constant): both are lower priority than GTK_PRIORITY_RESIZE. Federico From michael.meeks@novell.com Tue Jun 6 12:33:58 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 74B9F3B0197 for ; Tue, 6 Jun 2006 12:33:58 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05177-09 for ; Tue, 6 Jun 2006 12:33:57 -0400 (EDT) Received: from gwia-smtp.id2.novell.com (public.id2-vpn.continvity.gns.novell.com [195.33.99.129]) by menubar.gnome.org (Postfix) with ESMTP id 3714E3B014F for ; Tue, 6 Jun 2006 12:33:57 -0400 (EDT) Received: from [192.168.0.8] (l4-client.id2.novell.com [::ffff:149.44.117.251]) by gwia-smtp.id2.novell.com with ESMTP (TLS encrypted); Tue, 06 Jun 2006 17:33:30 +0100 From: Michael Meeks To: Federico Mena Quintero In-Reply-To: <1149608483.14088.54.camel@cacharro.xalalinux.org> References: <1149608483.14088.54.camel@cacharro.xalalinux.org> Content-Type: text/plain Organization: Novell, Inc. Date: Tue, 06 Jun 2006 17:37:54 +0100 Message-Id: <1149611874.2202.2.camel@t60p.site> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.427 tagged_above=-999 required=2 tests=[AWL=-0.028, BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2] X-Spam-Score: -2.427 X-Spam-Level: Cc: GTK+ development mailing list Subject: Re: Default timeouts X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: michael.meeks@novell.com List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2006 16:33:58 -0000 On Tue, 2006-06-06 at 10:41 -0500, Federico Mena Quintero wrote: > > In essence the timeout is way too short for switching days; also - > > in the panel applet the timeout has a higher priority than the > > queued resize of the display (and hence the redraw) - so in > > essence we skip days even faster since we never have to render > > them. Of course - this is particularly applicable for the calendar where it really makes sense to actually see the month rendered each time you switch to a different month or year. Of course with a spin-button I guess throttling the spin rate to that of the refresh rate would (perhaps) be problematic. Then again re-rendering a spin-button is presumably an extremely fast operation. HTH, Michael. -- michael.meeks@novell.com <><, Pseudo Engineer, itinerant idiot From carlosgc@gnome.org Wed Jun 7 07:48:25 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id BACA33B0C6A for ; Wed, 7 Jun 2006 07:48:25 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08136-01 for ; Wed, 7 Jun 2006 07:48:23 -0400 (EDT) Received: from localhost.localdomain (gsyc090.dat.escet.urjc.es [193.147.71.90]) by menubar.gnome.org (Postfix) with ESMTP id D0D083B01EA for ; Wed, 7 Jun 2006 07:48:22 -0400 (EDT) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 945E110F28E for ; Wed, 7 Jun 2006 13:48:19 +0200 (CEST) From: Carlos Garcia Campos To: GTK+ development mailing list Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-hBJf7M2jws0KBkd4rYip" Date: Wed, 07 Jun 2006 13:48:17 +0200 Message-Id: <1149680898.3302.9.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.285 tagged_above=-999 required=2 tests=[AWL=0.179, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.285 X-Spam-Level: Subject: Evince preview mode X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 11:48:25 -0000 --=-hBJf7M2jws0KBkd4rYip Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi,=20 since gtk+ is using evince as an external printing previewer, I'm implementing a preview mode in evince, available through the command line (--preview). It's based on the ephy printing previewer where the menubar is hidden and the toolbar contains navigation items and a close button. Here is an screenshot: http://carlosgc.linups.org/files/evince-preview-mode.png Any other thing expected by a previewer? --=20 Carlos Garcia Campos (KaL) elkalmail@yahoo.es carlosgc@gnome.org http://carlosgc.linups.org PGP key: http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0x523E6462 --=-hBJf7M2jws0KBkd4rYip Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQBEhr0BjxBOalI+ZGIRAmSgAJ9Ksy9L8QqVxpvNQCtbejp/0HRZXACeNcmq O8LT0nzkGzw+qcPFuVqZ3y8= =xZYn -----END PGP SIGNATURE----- --=-hBJf7M2jws0KBkd4rYip-- From hfiguiere@teaser.fr Wed Jun 7 08:28:18 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id AC8923B0CE2; Wed, 7 Jun 2006 08:28:18 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11220-01; Wed, 7 Jun 2006 08:28:15 -0400 (EDT) Received: from xandros.com (smtp1.xandros.com [209.87.238.70]) by menubar.gnome.org (Postfix) with ESMTP id EC3713B0CD7; Wed, 7 Jun 2006 08:28:14 -0400 (EDT) Received: from [172.18.1.132] (toronto-hs-216-138-231-194.s-ip.magma.ca [216.138.231.194]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by xandros.com (Postfix) with ESMTP id E7D80C028; Wed, 7 Jun 2006 08:28:12 -0400 (EDT) Message-ID: <4486C65A.5060800@teaser.fr> Date: Wed, 07 Jun 2006 08:28:10 -0400 From: Hubert Figuiere User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: Carlos Garcia Campos References: <1149680898.3302.9.camel@localhost.localdomain> In-Reply-To: <1149680898.3302.9.camel@localhost.localdomain> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.499 tagged_above=-999 required=2 tests=[AWL=0.100, BAYES_00=-2.599] X-Spam-Score: -2.499 X-Spam-Level: Cc: GTK+ development mailing list Subject: Re: Evince preview mode X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 12:28:19 -0000 Carlos Garcia Campos wrote: > Hi, > > since gtk+ is using evince as an external printing previewer, I'm > implementing a preview mode in evince, available through the command > line (--preview). It's based on the ephy printing previewer where the > menubar is hidden and the toolbar contains navigation items and a close > button. Here is an screenshot: > > http://carlosgc.linups.org/files/evince-preview-mode.png > > Any other thing expected by a previewer? It think it should have a menu bar, even if it is way simplier than Evince, and the button to close in the toolbar should be removed because it is "uncommon" and in fact confuse the user on what to do. Closing the window should be all that needed, or doing a file->close in the menu, Also, zoom in and zoom out are very useful. Hub From paolo.maggi@gmail.com Wed Jun 7 08:15:10 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 9C3E63B08CC for ; Wed, 7 Jun 2006 08:15:10 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10407-05 for ; Wed, 7 Jun 2006 08:15:09 -0400 (EDT) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.172]) by menubar.gnome.org (Postfix) with ESMTP id 8B7343B0303 for ; Wed, 7 Jun 2006 08:15:08 -0400 (EDT) Received: by ug-out-1314.google.com with SMTP id c2so258875ugf for ; Wed, 07 Jun 2006 05:15:07 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:subject:from:to:cc:content-type:date:message-id:mime-version:x-mailer:content-transfer-encoding; b=K90OlbUivfHjc3p7Mf7NxXYQ7dM8ZBxC+0BsgOJcKZJuB7jHCl0ZAGBW4g8105rAzePSP5EyfdcA7LlHJh+VEWxuXvCS7dbrv6RMBVJzQ/vwIPq71eGzz8nn2EwMpB2LP+LFhmJsovQOwZfLUn1MKDz4iRRATWR1zOQleW/WqEg= Received: by 10.67.105.19 with SMTP id h19mr435594ugm; Wed, 07 Jun 2006 05:15:06 -0700 (PDT) Received: from elilix.polito.it ( [130.192.16.224]) by mx.gmail.com with ESMTP id q1sm888781uge.2006.06.07.05.15.05; Wed, 07 Jun 2006 05:15:06 -0700 (PDT) From: Paolo Maggi To: carlosgc@gnome.org Content-Type: text/plain Date: Wed, 07 Jun 2006 14:15:04 +0200 Message-Id: <1149682504.5804.33.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.6 tagged_above=-999 required=2 tests=[AWL=0.000, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.6 X-Spam-Level: X-Mailman-Approved-At: Wed, 07 Jun 2006 09:03:01 -0400 Cc: gtk-devel-list@gnome.org Subject: Re: Evince preview mode X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 12:15:10 -0000 Hi, cia > since gtk+ is using evince as an external printing previewer, I'm > implementing a preview mode in evince, available through the command > line (--preview). It's based on the ephy printing previewer where the > menubar is hidden and the toolbar contains navigation items and a close > button. Here is an screenshot: > > http://carlosgc.linups.org/files/evince-preview-mode.png > > Any other thing expected by a previewer? - Zoom - Direct jump to a given page Please, look also at the gedit 2.14.x print previewer. Probably we also need a way to specify paper orientation on the command line (or is orientation already specified in the PDF file?) Ciao, Paolo From matthias.clasen@gmail.com Wed Jun 7 09:13:05 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id E24273B0D07 for ; Wed, 7 Jun 2006 09:13:04 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14781-07 for ; Wed, 7 Jun 2006 09:13:02 -0400 (EDT) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.202]) by menubar.gnome.org (Postfix) with ESMTP id 00C823B0B41 for ; Wed, 7 Jun 2006 09:13:01 -0400 (EDT) Received: by nz-out-0102.google.com with SMTP id 9so196545nzo for ; Wed, 07 Jun 2006 06:13:01 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=saqMihVje8FYa9UdpyLa1+dlefvQoIGQxKH7/1Zo60aYxymeM8Pd6GyFWAgY0o+p1vKDz7amMyAC6pjntEQBEcP8uj0rJL3yYZX1hequAVkJsd5sQslhyn8T44EZjEA/hsuQz0+1EdqmPuNMRK0Lseu0seEU88n8Ei5Ii1IMFBQ= Received: by 10.37.13.40 with SMTP id q40mr711105nzi; Wed, 07 Jun 2006 06:13:00 -0700 (PDT) Received: by 10.37.21.14 with HTTP; Wed, 7 Jun 2006 06:13:00 -0700 (PDT) Message-ID: Date: Wed, 7 Jun 2006 09:13:00 -0400 From: "Matthias Clasen" To: "Carlos Garcia Campos" In-Reply-To: <1149680898.3302.9.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1149680898.3302.9.camel@localhost.localdomain> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.508 tagged_above=-999 required=2 tests=[AWL=0.092, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.508 X-Spam-Level: Cc: GTK+ development mailing list Subject: Re: Evince preview mode X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 13:13:05 -0000 On 6/7/06, Carlos Garcia Campos wrote: > Hi, > > since gtk+ is using evince as an external printing previewer, I'm > implementing a preview mode in evince, available through the command > line (--preview). It's based on the ephy printing previewer where the > menubar is hidden and the toolbar contains navigation items and a close > button. Here is an screenshot: > > http://carlosgc.linups.org/files/evince-preview-mode.png > > Any other thing expected by a previewer? A print button. From n1huq@hotmail.com Wed Jun 7 13:11:51 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 04F873B04FC for ; Wed, 7 Jun 2006 13:11:51 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32024-05 for ; Wed, 7 Jun 2006 13:11:49 -0400 (EDT) Received: from hotmail.com (bay114-dav5.bay114.hotmail.com [65.54.169.77]) by menubar.gnome.org (Postfix) with ESMTP id 192433B00F5 for ; Wed, 7 Jun 2006 13:11:49 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 7 Jun 2006 10:11:48 -0700 Message-ID: Received: from 68.0.250.43 by BAY114-DAV5.phx.gbl with DAV; Wed, 07 Jun 2006 17:11:46 +0000 X-Originating-IP: [68.0.250.43] X-Originating-Email: [n1huq@hotmail.com] X-Sender: n1huq@hotmail.com From: "Sydney Faria" To: Date: Wed, 7 Jun 2006 13:15:56 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-OriginalArrivalTime: 07 Jun 2006 17:11:48.0135 (UTC) FILETIME=[75E3BB70:01C68A55] X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=1.984 tagged_above=-999 required=2 tests=[BAYES_50=0.001, DNS_FROM_RFC_ABUSE=0.2, DNS_FROM_RFC_POST=1.708, MSGID_FROM_MTA_HEADER=0, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, TW_GT=0.077] X-Spam-Score: 1.984 X-Spam-Level: * Subject: combo box problem X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 17:11:51 -0000 The following simple example of a gtk_combo_box compiles and works OK it the select_cb() is empty. The line marked gives a compiler error: undefined reference to gtk_combo_box_get_active_text. I am befuddled! sydney #include #include GtkWidget *window, *combo; static gboolean delete_event(GtkWidget *widget, GdkEvent *event, gpointer data) { return FALSE; } static void destroy(GtkWidget *widget, gpointer data) { gtk_main_quit(); } static void select_cb(GtkWidget *widget, gpointer data) { /* comment out following 2 lines and program compiles and works OK */ gchar *str = gtk_combo_box_get_active_text(GTK_COMBO_BOX(combo)); /* compile error */ g_print("active text: %s\n", str); } int main( int argc, char *argv[] ) { GtkWidget *button, *hbox; gtk_init (&argc, &argv); /* init gtk */ window = gtk_window_new (GTK_WINDOW_TOPLEVEL); gtk_container_set_border_width(GTK_CONTAINER(window), 10); g_signal_connect(G_OBJECT(window), "delete_event", G_CALLBACK(delete_event), NULL); g_signal_connect(G_OBJECT(window), "destroy", G_CALLBACK(destroy), NULL); hbox = gtk_hbox_new(TRUE, 20); gtk_container_add(GTK_CONTAINER(window), hbox); button = gtk_button_new_with_label("Select text"); g_signal_connect(G_OBJECT(button), "clicked", G_CALLBACK(select_cb), NULL); gtk_box_pack_start(GTK_BOX(hbox), button, FALSE, FALSE, 0); combo = gtk_combo_box_new_text(); gtk_box_pack_start(GTK_BOX(hbox), combo, FALSE, FALSE, 0); gtk_combo_box_insert_text(GTK_COMBO_BOX(combo), 0, "Astring"); gtk_combo_box_append_text(GTK_COMBO_BOX(combo), "Bstring"); gtk_combo_box_append_text(GTK_COMBO_BOX(combo), "Cstring"); gtk_combo_box_append_text(GTK_COMBO_BOX(combo), "Dstring"); gtk_combo_box_append_text(GTK_COMBO_BOX(combo), "Estring"); gtk_combo_box_insert_text(GTK_COMBO_BOX(combo), 3, "xxxxx"); gtk_widget_show_all(window); gtk_main(); return 0; } From ali@avrc.city.ac.uk Wed Jun 7 13:20:43 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id B9C6A3B0D3D for ; Wed, 7 Jun 2006 13:20:43 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32493-04 for ; Wed, 7 Jun 2006 13:20:42 -0400 (EDT) Received: from firewall.avrc.city.ac.uk (optosun2.city.ac.uk [138.40.167.2]) by menubar.gnome.org (Postfix) with ESMTP id ACA3B3B0BDC for ; Wed, 7 Jun 2006 13:20:40 -0400 (EDT) Received: from tom.avrc.city.ac.uk (IDENT:U2FsdGVkX1/zwWSA4Vc+XKbUWVXUavCLm3rPqXMMlDg@tom [192.168.137.104]) by firewall.avrc.city.ac.uk (8.9.3/8.9.3) with ESMTP id SAA27971; Wed, 7 Jun 2006 18:10:27 +0100 Received: from tom.avrc.city.ac.uk (localhost.localdomain [127.0.0.1]) by tom.avrc.city.ac.uk (8.13.1/8.13.1) with ESMTP id k57HTT2Y031243; Wed, 7 Jun 2006 18:29:29 +0100 Date: Wed, 07 Jun 2006 17:29:28 +0000 From: "J. Ali Harlow" To: Sydney Faria References: In-Reply-To: (from n1huq@hotmail.com on Wed Jun 7 18:15:56 2006) X-Mailer: Balsa 2.2.6 Message-Id: <1149701368l.5713l.3l@tom.avrc.city.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; DelSp=Yes; Format=Flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.525 tagged_above=-999 required=2 tests=[AWL=-0.003, BAYES_00=-2.599, TW_GT=0.077] X-Spam-Score: -2.525 X-Spam-Level: Cc: gtk-devel-list@gnome.org Subject: Re: combo box problem X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 17:20:43 -0000 On 07/06/06 18:15:56, Sydney Faria wrote: > The following simple example of a gtk_combo_box compiles and works OK > it the select_cb() is empty. The line marked gives a compiler error: =20 > undefined reference to gtk_combo_box_get_active_text. gtk_combo_box_get_active_text was added in Gtk+ v2.6 Ali. From carlosgc@gnome.org Wed Jun 7 14:37:47 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id D45D43B0546 for ; Wed, 7 Jun 2006 14:37:47 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05339-08 for ; Wed, 7 Jun 2006 14:37:46 -0400 (EDT) Received: from localhost.localdomain (gsyc090.dat.escet.urjc.es [193.147.71.90]) by menubar.gnome.org (Postfix) with ESMTP id 3EC7D3B03F7 for ; Wed, 7 Jun 2006 14:37:46 -0400 (EDT) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 0ABE610F28E for ; Wed, 7 Jun 2006 20:37:40 +0200 (CEST) From: Carlos Garcia Campos To: gtk-devel-list@gnome.org In-Reply-To: References: <1149680898.3302.9.camel@localhost.localdomain> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-WdU94ldj/PvL1mhYRti9" Date: Wed, 07 Jun 2006 20:37:39 +0200 Message-Id: <1149705460.3302.25.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.354 tagged_above=-999 required=2 tests=[AWL=0.110, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.354 X-Spam-Level: Subject: Re: Evince preview mode X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 18:37:48 -0000 --=-WdU94ldj/PvL1mhYRti9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable El mi=C3=A9, 07-06-2006 a las 09:13 -0400, Matthias Clasen escribi=C3=B3: > On 6/7/06, Carlos Garcia Campos wrote: > > Hi, > > > > since gtk+ is using evince as an external printing previewer, I'm > > implementing a preview mode in evince, available through the command > > line (--preview). It's based on the ephy printing previewer where the > > menubar is hidden and the toolbar contains navigation items and a close > > button. Here is an screenshot: > > > > http://carlosgc.linups.org/files/evince-preview-mode.png > > > > Any other thing expected by a previewer? >=20 > A print button. >=20 hmm, when the user selects preview from the print dialog, the dialog disappears and evince is launched, so that if evince has a print button we should print the document directly without showing the print dialog again. I see several problems in this approach. First of all we can't know the print settings selected by the user from evince. And, should we close evince or keep it opened after clicking on print? Is it possible to print a pdf file with the new gtk+ api without showing any dialog?=20 I think it's very confused. The best solution would be not to hide the dialog when the previewer is launched, so that once the user is happy with the results showed in evince, he simply clicks on print button.=20 --=20 Carlos Garcia Campos (KaL) elkalmail@yahoo.es carlosgc@gnome.org http://carlosgc.linups.org PGP key: http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0x523E6462 --=-WdU94ldj/PvL1mhYRti9 Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQBEhxzzjxBOalI+ZGIRAsatAJ4+rfTQPQwp9+YtbRKpPmVlDuEG9ACfclx7 9c9NhlEvkjGZjMS42o6vmHM= =TbYL -----END PGP SIGNATURE----- --=-WdU94ldj/PvL1mhYRti9-- From matthias.clasen@gmail.com Wed Jun 7 19:34:00 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 62A323B036A for ; Wed, 7 Jun 2006 19:34:00 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23001-06 for ; Wed, 7 Jun 2006 19:33:56 -0400 (EDT) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.203]) by menubar.gnome.org (Postfix) with ESMTP id A86BE3B0E6E for ; Wed, 7 Jun 2006 19:33:56 -0400 (EDT) Received: by nz-out-0102.google.com with SMTP id o37so261498nzf for ; Wed, 07 Jun 2006 16:33:55 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=LpgZtLrjc9Sc3giRUzuWDX2naMTMsbgrizT1aggkQjCN27Pm9kFPU1c5Bra0LikmJaw1sDQO0paAD7N3OQwY1+3Y9JTdMwkT9YBnlgCbMohSYLzhRt6yPFasRtdkLK24rM8sI5l8EdJ/+dpxDSU/+GFlNbztpO8kky973RVbTmY= Received: by 10.36.103.6 with SMTP id a6mr1426226nzc; Wed, 07 Jun 2006 16:33:53 -0700 (PDT) Received: by 10.37.21.14 with HTTP; Wed, 7 Jun 2006 16:33:52 -0700 (PDT) Message-ID: Date: Wed, 7 Jun 2006 19:33:52 -0400 From: "Matthias Clasen" To: "Carlos Garcia Campos" In-Reply-To: <1149705460.3302.25.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1149680898.3302.9.camel@localhost.localdomain> <1149705460.3302.25.camel@localhost.localdomain> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.509 tagged_above=-999 required=2 tests=[AWL=0.091, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.509 X-Spam-Level: Cc: gtk-devel-list@gnome.org Subject: Re: Evince preview mode X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 23:34:00 -0000 On 6/7/06, Carlos Garcia Campos wrote: > hmm, when the user selects preview from the print dialog, the dialog > disappears and evince is launched, so that if evince has a print button > we should print the document directly without showing the print dialog > again. I see several problems in this approach. First of all we can't > know the print settings selected by the user from evince. And, should we > close evince or keep it opened after clicking on print? Is it possible > to print a pdf file with the new gtk+ api without showing any dialog? Sure, figuring out the best way to transfer the print settings to evince is part of this. And yes, printing preformatted pdf is supported. > > I think it's very confused. The best solution would be not to hide the > dialog when the previewer is launched, so that once the user is happy > with the results showed in evince, he simply clicks on print button. > Apple does it too, so it can't be all bad... Matthias From hfiguiere@teaser.fr Wed Jun 7 21:05:56 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 3CAD23B051D for ; Wed, 7 Jun 2006 21:05:56 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27783-02 for ; Wed, 7 Jun 2006 21:05:53 -0400 (EDT) Received: from xandros.com (smtp1.xandros.com [209.87.238.70]) by menubar.gnome.org (Postfix) with ESMTP id 31DC43B0414 for ; Wed, 7 Jun 2006 21:05:53 -0400 (EDT) Received: from [172.18.1.132] (toronto-hs-216-138-231-194.s-ip.magma.ca [216.138.231.194]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by xandros.com (Postfix) with ESMTP id A37413E02E; Wed, 7 Jun 2006 21:05:51 -0400 (EDT) Message-ID: <448777ED.1020804@teaser.fr> Date: Wed, 07 Jun 2006 21:05:49 -0400 From: Hubert Figuiere User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: Matthias Clasen References: <1149680898.3302.9.camel@localhost.localdomain> <1149705460.3302.25.camel@localhost.localdomain> In-Reply-To: X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.506 tagged_above=-999 required=2 tests=[AWL=0.093, BAYES_00=-2.599] X-Spam-Score: -2.506 X-Spam-Level: Cc: gtk-devel-list@gnome.org Subject: Re: Evince preview mode X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 01:05:56 -0000 >> I think it's very confused. The best solution would be not to hide the >> dialog when the previewer is launched, so that once the user is happy >> with the results showed in evince, he simply clicks on print button. >> > > Apple does it too, so it can't be all bad... That is the kind of blind thinking that lead to nowhere. Remember just one thing: if it does not please Steve Jobs, it does not goes. That how it works at Apple. Bottom line: wrong argument. Hub From alexl@redhat.com Thu Jun 8 08:09:59 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 5B8C83B0EF5; Thu, 8 Jun 2006 08:09:59 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32659-09; Thu, 8 Jun 2006 08:09:58 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id B35BC3B075A; Thu, 8 Jun 2006 08:09:57 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k58C9u9M020757; Thu, 8 Jun 2006 08:09:56 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k58C9u0T021240; Thu, 8 Jun 2006 08:09:56 -0400 Received: from [127.0.0.1] (sebastian-int.corp.redhat.com [172.16.52.221]) by devserv.devel.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k58C9tGO011054; Thu, 8 Jun 2006 08:09:56 -0400 From: Alexander Larsson To: Matthias Clasen In-Reply-To: References: <1149680898.3302.9.camel@localhost.localdomain> <1149705460.3302.25.camel@localhost.localdomain> Content-Type: text/plain Date: Thu, 08 Jun 2006 14:09:55 +0200 Message-Id: <1149768596.3023.11.camel@greebo> Mime-Version: 1.0 X-Mailer: Evolution 2.7.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.587 tagged_above=-999 required=2 tests=[AWL=0.014, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.587 X-Spam-Level: Cc: gtk-devel-list@gnome.org Subject: Re: Evince preview mode X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 12:09:59 -0000 On Wed, 2006-06-07 at 19:33 -0400, Matthias Clasen wrote: > On 6/7/06, Carlos Garcia Campos wrote: > > > hmm, when the user selects preview from the print dialog, the dialog > > disappears and evince is launched, so that if evince has a print button > > we should print the document directly without showing the print dialog > > again. I see several problems in this approach. First of all we can't > > know the print settings selected by the user from evince. And, should we > > close evince or keep it opened after clicking on print? Is it possible > > to print a pdf file with the new gtk+ api without showing any dialog? > > Sure, figuring out the best way to transfer the print settings to evince > is part of this. And yes, printing preformatted pdf is supported. This is tricky. What if the preview was launched without even showing the dialog, or if the user hadn't picked the right printer yet when clicking on preview. Also, it will print differently by generating pdf and then converting that to postscript, instead of generating postscript directly. Ideally this should produce as-good output, but thats not really guaranteed. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl@redhat.com alla@lysator.liu.se He's an immortal umbrella-wielding cyborg with no name. She's a tortured green-skinned Hell's Angel from a different time and place. They fight crime! From lists@nabble.com Thu Jun 8 21:35:27 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id BFE263B0E9B for ; Thu, 8 Jun 2006 21:35:27 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18339-04 for ; Thu, 8 Jun 2006 21:35:26 -0400 (EDT) Received: from talk.nabble.com (www.nabble.com [72.21.53.35]) by menubar.gnome.org (Postfix) with ESMTP id 602DC3B05AC for ; Thu, 8 Jun 2006 21:35:26 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=talk.nabble.com) by talk.nabble.com with esmtp (Exim 4.50) id 1FoVuE-0000rb-3p for gtk-devel-list@gnome.org; Thu, 08 Jun 2006 18:35:24 -0700 Message-ID: <4785900.post@talk.nabble.com> Date: Thu, 8 Jun 2006 18:35:22 -0700 (PDT) From: darknecro To: gtk-devel-list@gnome.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-Sender: darknecromancer@dodgeit.com X-Nabble-From: darknecro X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-0.316 tagged_above=-999 required=2 tests=[AWL=2.285, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -0.316 X-Spam-Level: Subject: GTK Masks X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2006 01:35:27 -0000 I am attempting to create a single mask that would cover several items with in the GUI. There will by 16 circles created with gdk_pixmap_create_from_xpm_d, and I can currently do this, but only one item would be 'created' in the mask, so when i apply the mask to the window, only one of the items will be visible. I have done a lot of searching, and I have only been able to come up with that you can xor 2 masks together somehow and create one that contains both. Any help that anyone could shed on this would be greatly appreciated. -- View this message in context: http://www.nabble.com/GTK-Masks-t1759366.html#a4785900 Sent from the Gtk+ - Dev - General forum at Nabble.com. From mitch@gimp.org Fri Jun 9 06:31:35 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id D2D0C3B0216 for ; Fri, 9 Jun 2006 06:31:34 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14877-07 for ; Fri, 9 Jun 2006 06:31:33 -0400 (EDT) Received: from mitch.gimp.org (p549C9439.dip0.t-ipconnect.de [84.156.148.57]) by menubar.gnome.org (Postfix) with ESMTP id EB4033B01DA for ; Fri, 9 Jun 2006 06:31:30 -0400 (EDT) Received: from mitch by mitch.gimp.org with local (Exim 3.36 #1 (Debian)) id 1FoeIj-0003cx-00; Fri, 09 Jun 2006 12:33:13 +0200 From: Michael Natterer To: Federico Mena Quintero In-Reply-To: <1149608483.14088.54.camel@cacharro.xalalinux.org> References: <1149608483.14088.54.camel@cacharro.xalalinux.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Fri, 09 Jun 2006 12:33:12 +0200 Message-Id: <1149849193.3010.23.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=1.06 tagged_above=-999 required=2 tests=[AWL=-0.545, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, RCVD_IN_NJABL_DUL=1.946, RCVD_IN_SORBS_DUL=2.046, TW_GT=0.077] X-Spam-Score: 1.06 X-Spam-Level: * Cc: GTK+ development mailing list , Michael.meeks@novell.com Subject: Re: Default timeouts X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2006 10:31:35 -0000 On Tue, 2006-06-06 at 10:41 -0500, Federico Mena Quintero wrote: > In gtksettings.c we have > > #define DEFAULT_TIMEOUT_INITIAL 200 > #define DEFAULT_TIMEOUT_REPEAT 20 > > for the "gtk-timeout-initial" and "gtk-timeout-repeat" settings, > respectively. This means we wait for a fifth of a second before we > start repeating, but then we try to repeat 50 times per second. > > Isn't the repeat timeout way too short? This is why clicking on a > calendar arrow takes you back tens of months in no time, and also makes > it hard to use spin buttons. Yes, that's way too short. When doing the settings patch, I unified timeouts without actually changing them (the 20 ms was there before). However in some places I introduced a factor of 5 so all existing timeouts could be done with the two values from GtkSettings. See comment #10 of http://bugzilla.gnome.org/show_bug.cgi?id=142582 Actually, it may make sense to simply use the user's configured key repeat and delay for these two setting values. What do you think? ciao, --mitch > Also, Michael Meeks has the following words of wisdom in a Novell bug > about the calendar in gnome-panel's clock: > > > In essence the timeout is way too short for switching days; also - > > in the panel applet the timeout has a higher priority than the > > queued resize of the display (and hence the redraw) - so in > > essence we skip days even faster since we never have to render > > them. > > > > Lowering the priority there, and lengthening the timeouts gives > > a far more reasonable, usable experience without getting rid > > of the whole auto-repeat principle [...] > > I.e. instead of using g_timeout_add() in gtkcalendar, we would use > g_timeout_add_full (G_PRIORITY_DEFAULT_IDLE, ...), or perhaps > (GDK_PRIORITY_REDRAW + positive_constant): both are lower priority than > GTK_PRIORITY_RESIZE. > > Federico > > _______________________________________________ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-devel-list From ross@burtonini.com Fri Jun 9 07:15:10 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 1192B3B0099 for ; Fri, 9 Jun 2006 07:15:10 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18418-03 for ; Fri, 9 Jun 2006 07:15:08 -0400 (EDT) Received: from smtp.nildram.co.uk (smtp.nildram.co.uk [195.112.4.54]) by menubar.gnome.org (Postfix) with ESMTP id 279213B0081 for ; Fri, 9 Jun 2006 07:15:07 -0400 (EDT) Received: from burtonini.com (althur.gotadsl.co.uk [84.12.135.175]) by smtp.nildram.co.uk (Postfix) with ESMTP id 1DDA833C3F2; Fri, 9 Jun 2006 12:11:26 +0100 (BST) Received: from 127.0.0.1 (ident=unknown) by burtonini.com with esmtp (masqmail 0.2.21) id 1Foetj-17d-00; Fri, 09 Jun 2006 12:11:27 +0100 From: Ross Burton To: Michael Natterer In-Reply-To: <1149849193.3010.23.camel@localhost> References: <1149608483.14088.54.camel@cacharro.xalalinux.org> <1149849193.3010.23.camel@localhost> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-DKvhrUfzvCjsapgkUotZ" Date: Fri, 09 Jun 2006 12:11:27 +0100 Message-Id: <1149851487.2333.2.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.456 tagged_above=-999 required=2 tests=[AWL=0.008, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.456 X-Spam-Level: Cc: Federico Mena Quintero , GTK+ development mailing list , Michael.meeks@novell.com Subject: Re: Default timeouts X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2006 11:15:10 -0000 --=-DKvhrUfzvCjsapgkUotZ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2006-06-09 at 12:33 +0200, Michael Natterer wrote: > Actually, it may make sense to simply use the user's configured > key repeat and delay for these two setting values. What do you > think? That's probably a very good idea, on the grounds that people set the keyboard delay/repeat to values they can handle (i.e. my Dad has slowed them down as he isn't as fast as he used to be). What are the system defaults for the keyboard delay/repeat? Ross --=20 Ross Burton mail: ross@burtonini.com jabber: ross@burtonini.com www: http://www.burtonini.com./ PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF --=-DKvhrUfzvCjsapgkUotZ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQBEiVdeLQnkR9C0M98RAp+DAJ9s9H2qD2A4AQ6kXwgB+B6ka0ve8QCfZcQL IPi9sLP/fY2zOVLCX+eSrvo= =LNZu -----END PGP SIGNATURE----- --=-DKvhrUfzvCjsapgkUotZ-- From timj@gtk.org Fri Jun 9 13:30:55 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 1CAD23B00E9 for ; Fri, 9 Jun 2006 13:30:55 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10186-10 for ; Fri, 9 Jun 2006 13:30:52 -0400 (EDT) Received: from webmail.hansenet.de (mail03.hansenet.de [213.191.73.10]) by menubar.gnome.org (Postfix) with ESMTP id E3A183B011B for ; Fri, 9 Jun 2006 13:30:51 -0400 (EDT) Received: from birnet.org (80.171.4.161) by webmail.hansenet.de (7.2.059) id 4487A06D0006D98F; Fri, 9 Jun 2006 19:30:40 +0200 Received: from master.birnet.private (localhost [127.0.0.1]) by birnet.org (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k59HUdVg010604 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 9 Jun 2006 19:30:39 +0200 Received: (from timj@localhost) by master.birnet.private (8.13.4/8.13.4/Submit) id k59HUPEO010599; Fri, 9 Jun 2006 19:30:25 +0200 Date: Fri, 9 Jun 2006 19:30:25 +0200 (CEST) From: Tim Janik X-X-Sender: timj@master.birnet.private To: "Kaveh R. Ghazi" In-Reply-To: <200606091630.k59GUaES013244@caipclassic.rutgers.edu> Message-ID: References: <20060609152646.GE20719@space.twc.de> <200606091630.k59GUaES013244@caipclassic.rutgers.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.469 tagged_above=-999 required=2 tests=[AWL=0.130, BAYES_00=-2.599] X-Spam-Score: -2.469 X-Spam-Level: Cc: gcc@gcc.gnu.org, Gtk+ Developers Subject: Re: Problem with type safety and the "sentinel" attribute X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2006 17:30:55 -0000 thanks for the quick response Kaveh. On Fri, 9 Jun 2006, Kaveh R. Ghazi wrote: > > > void print_string_array (const char *array_name, > > const char *string, ...) __attribute__ > > ((__sentinel__)); > > > > print_string_array ("empty_array", NULL); /* gcc warns, but shouldn't */ > > > > The only way out for keeping the sentinel attribute and avoiding the > > warning is using > > > > static void print_string_array (const char *array_name, ...) > > __attribute__ ((__sentinel__)); > > I think you could maintain typesafety and silence the warning by > keeping the more specific prototype and adding an extra NULL, e.g.: > > print_string_array ("empty_array", NULL, NULL); > > Doesn't seem elegant, but it does the job. this is an option for a limited set of callers, yes. > > By the way, there is already an existing gcc bug, which is about the > > same thing (NULL passed within named args), but wants to have it the > > way it works now: > > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21911 > > Correct, the feature as I envisioned it expected the sentinel to > appear in the variable arguments only. This PR reflects when I found > out it didn't do that and got around to fixing it. Note the "buggy" > behavior wasn't exactly what you wanted either because GCC got fooled > by a sentinel in *any* of the named arguments, not just the last one. > > > > so if it gets changed, then gcc might need to support both > > - NULL termination within the last named parameter allowed > > - NULL termination only allowed within varargs parameters (like it is > > now) > > I'm not against this enhancement, but you need to specify a syntax > that allows the old behavior but also allows doing it your way. > > Hmm, perhaps we could check for attribute "nonnull" on the last named > argument, if it exists then that can't be the sentinel, if it's not > there then it does what you want. This is not completely backwards > compatible because anyone wanting the existing behavior has to add the > attribute nonnull. But there's precedent for this when attribute > printf split out whether the format specifier could be null... > > We could also create a new attribute name for the new behavior. This > would preserve backwards compatibility. I like this idea better. i agree here. as far as the majority of the GLib and Gtk+ APIs are concerned, we don't really need the flexibility of the sentinel attribute but rather a compiler check on whether the last argument used in a function call is NULL or 0 (regardless of whether it's the last named arg or already part of the varargs list). that's also why the actual sentinel wrapper in GLib looks like this: #define G_GNUC_NULL_TERMINATED __attribute__((__sentinel__)) so, if i was to make a call on this issue, i'd either introduce __attribute__((__null_terminated__)) with the described semantics, or have __attribute__((__sentinel__(-1))) work essentially like __attribute__((__sentinel__(0))) while also accepting 0 in the position of the last named argument. > Next you need to recruit someone to implement this enhancement, or > submit a patch. :-) Although given that you can silence the warning by > adding an extra NULL at the call site, I'm not sure it's worth it. i would say this is definitely worth it, because the issue also shows up in other code that is widely used: gpointer g_object_new (GType object_type, const gchar *first_property_name, ...); that's for instance a function which is called in many projects. putting the burden on the caller is clearly the wrong trade off here. so please take this as a vote for the worthiness of a fix ;) > --Kaveh > -- > Kaveh R. Ghazi ghazi@caip.rutgers.edu --- ciaoTJ From nshmyrev@yandex.ru Sat Jun 10 02:06:32 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 347973B00D0 for ; Sat, 10 Jun 2006 02:06:32 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12492-03 for ; Sat, 10 Jun 2006 02:06:28 -0400 (EDT) Received: from chen.mtu.ru (chen.mtu.ru [195.34.34.232]) by menubar.gnome.org (Postfix) with ESMTP id 78AC43B0126 for ; Sat, 10 Jun 2006 02:06:28 -0400 (EDT) Received: from gnome.local (ppp83-237-50-138.pppoe.mtu-net.ru [83.237.50.138]) by smtp.MTU.RU (Postfix) with ESMTP id D51B453DA7E; Sat, 10 Jun 2006 10:06:25 +0400 (MSD) (envelope-from nshmyrev@yandex.ru) From: "Nickolay V. Shmyrev" To: gtk-devel-list@gnome.org, gnome-i18n@gnome.org Content-Type: text/plain Date: Sat, 10 Jun 2006 10:06:30 +0400 Message-Id: <1149919590.2305.18.camel@gnome.local> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 (2.6.2-1.fc5.3) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.758 tagged_above=-999 required=2 tests=[AWL=-0.440, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, SPF_NEUTRAL=1.069, TW_GT=0.077] X-Spam-Score: -1.758 X-Spam-Level: Cc: Subject: Translation of gtk tuturial X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2006 06:06:32 -0000 Hello all. I now there was done quite amazing work about translation of gtk tutorial and I know there were some other translations http://linfoline.homedns.org/gtk/book1.html http://kldp.org/KoreanDoc/html/GtkTutorial/GtkTutorial.html What about making gtk tutorial translatable with docutils like all user documentation and merging those translations upstream? I don't ask about reference manual translation but it's also interesting, although not realistic. Probably it's not sensible to distribute tutorial with gtk package itself but use something like a web-based Rosetta. From matthias.clasen@gmail.com Sat Jun 10 10:02:35 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id A74883B0280 for ; Sat, 10 Jun 2006 10:02:35 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06778-09 for ; Sat, 10 Jun 2006 10:02:33 -0400 (EDT) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.200]) by menubar.gnome.org (Postfix) with ESMTP id 1C56D3B01C3 for ; Sat, 10 Jun 2006 10:02:33 -0400 (EDT) Received: by nz-out-0102.google.com with SMTP id z3so947001nzf for ; Sat, 10 Jun 2006 07:02:32 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=jUGG9w5BYrTkFmK4uobvwaXzJ1w3H4k8DuZIFGIHoBjFn1kgtf//lWo+engDAz0ImbOYOsKrWjvA9YAXvpwCcamcXXpE51E09vtpA8lmZKxAt+RA6AWeMX4blO5srWeestsf+E6dRd0OwZUmD3OCksEXAdLAjQcGBJBiKLVKPnQ= Received: by 10.37.15.76 with SMTP id s76mr5772218nzi; Sat, 10 Jun 2006 07:02:32 -0700 (PDT) Received: by 10.37.21.6 with HTTP; Sat, 10 Jun 2006 07:02:32 -0700 (PDT) Message-ID: Date: Sat, 10 Jun 2006 10:02:32 -0400 From: "Matthias Clasen" To: "Nickolay V. Shmyrev" In-Reply-To: <1149919590.2305.18.camel@gnome.local> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1149919590.2305.18.camel@gnome.local> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.471 tagged_above=-999 required=2 tests=[AWL=0.052, BAYES_00=-2.599, SPF_PASS=-0.001, TW_GT=0.077] X-Spam-Score: -2.471 X-Spam-Level: Cc: gnome-i18n@gnome.org, gtk-devel-list@gnome.org Subject: Re: Translation of gtk tuturial X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2006 14:02:35 -0000 On 6/10/06, Nickolay V. Shmyrev wrote: > Hello all. > > I now there was done quite amazing work about translation of gtk > tutorial and I know there were some other translations > > http://linfoline.homedns.org/gtk/book1.html > > http://kldp.org/KoreanDoc/html/GtkTutorial/GtkTutorial.html > > What about making gtk tutorial translatable with docutils like all > user documentation and merging those translations upstream? > > I don't ask about reference manual translation but it's also interesting, > although not realistic. Probably it's not sensible to distribute tutorial > with gtk package itself but use something like a web-based Rosetta. > The first step towards making the tutorial more useful would be updating its 2.0 era content, remove deprecated apis, and cover at least some of the important new apis. From lists@nabble.com Sat Jun 10 13:20:05 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id BB53E3B01B8 for ; Sat, 10 Jun 2006 13:20:05 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16672-08 for ; Sat, 10 Jun 2006 13:20:04 -0400 (EDT) Received: from talk.nabble.com (www.nabble.com [72.21.53.35]) by menubar.gnome.org (Postfix) with ESMTP id 2730A3B01D7 for ; Sat, 10 Jun 2006 13:20:04 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=talk.nabble.com) by talk.nabble.com with esmtp (Exim 4.50) id 1Fp77z-0000O0-FG for gtk-devel-list@gnome.org; Sat, 10 Jun 2006 10:20:03 -0700 Message-ID: <4809607.post@talk.nabble.com> Date: Sat, 10 Jun 2006 10:20:03 -0700 (PDT) From: mikecorn To: gtk-devel-list@gnome.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-Sender: mikecorn@t-online.de X-Nabble-From: mikecorn X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.565 tagged_above=-999 required=2 tests=[AWL=0.036, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.565 X-Spam-Level: Subject: GTK window edge detection sensitivity X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2006 17:20:05 -0000 To: GTK developers The resizable windows in Gnome are slick, but I often have a minor problem: After the mouse cursor changes form, indicating that the window edge is in-range for dragging, I often find myself dragging across the window behind, because the edge range was lost shortly after it was found. I ask you to consider possible improvements to make this work more reliably and with less precision required (which also means faster for the user). 1. increase the edge-detection threshold by 2x or more, or make it user-adjustable. 2. once the edge is detected, increase the threshold for losing it (time or distance). regards Mike C. -- View this message in context: http://www.nabble.com/GTK-window-edge-detection-sensitivity-t1767067.html#a4809607 Sent from the Gtk+ - Dev - General forum at Nabble.com. From marcel@telka.sk Sat Jun 10 23:05:18 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 2D8C03B05D2 for ; Sat, 10 Jun 2006 23:05:18 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06780-08 for ; Sat, 10 Jun 2006 23:05:16 -0400 (EDT) Received: from tortuga.telka.sk (unknown [193.86.173.20]) by menubar.gnome.org (Postfix) with SMTP id 7D8283B0543 for ; Sat, 10 Jun 2006 23:05:15 -0400 (EDT) Received: (qmail 14272 invoked by uid 0); 11 Jun 2006 02:57:43 -0000 Date: 11 Jun 2006 02:57:43 -0000 Message-ID: <20060611025743.14269.qmail@tortuga.telka.sk> To: From: Marcel Telka X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.443 tagged_above=-999 required=2 tests=[AWL=0.156, BAYES_00=-2.599] X-Spam-Score: -2.443 X-Spam-Level: Subject: gtk+: Missing translatable files X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jun 2006 03:05:18 -0000 Hi. I have tested module gtk+ (CVS branch HEAD) which lives in GNOME CVS for missing translatable files with `intltool-update -m` command. Here is a content of the 'missing' file: gtk/gtkfilechoosersettings.c gtk/gtkprintoperationpreview.c Please put these files into POTFILES.in or POTFILES.skip files. Thanks. Note: This report is generated automatically and you are not required to reply to this mail. If you are not maintainer of the 'gtk+' module or this CVS branch is obsolete or you don't want similar report in future, tell me and I will stop this report generation. Regards. -- +-------------------------------------------+ | Marcel Telka e-mail: marcel@telka.sk | | homepage: http://telka.sk/ | | jabber: marcel@jabber.sk | +-------------------------------------------+ From easy-b@freesurf.ch Sun Jun 11 16:22:48 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id ABE753B0159 for ; Sun, 11 Jun 2006 16:22:48 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32516-10 for ; Sun, 11 Jun 2006 16:22:46 -0400 (EDT) Received: from mail-fs.sunrise.ch (mta-fs-be-04.sunrise.ch [194.158.229.33]) by menubar.gnome.org (Postfix) with ESMTP id A306E3B00CA for ; Sun, 11 Jun 2006 16:22:45 -0400 (EDT) Received: from [10.0.1.2] (84.227.173.50) by mail-fs.sunrise.ch (7.2.073) id 44858C490024803A; Sun, 11 Jun 2006 22:21:55 +0200 In-Reply-To: References: <20060522160033.F1A8E3B1CE4@menubar.gnome.org> <772588ED-500A-4A11-8829-DA80B9A35D1F@freesurf.ch> <44720B8C.3080903@imendio.com> <0A34FCC9-6650-4737-B86D-1B503D8A9072@freesurf.ch> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7D6367DC-8689-453B-8FD7-217632BC1DAE@freesurf.ch> Content-Transfer-Encoding: 7bit From: Easy B Date: Sun, 11 Jun 2006 22:21:54 +0200 To: Gregor Riepl X-Mailer: Apple Mail (2.749.3) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.312 tagged_above=-999 required=2 tests=[AWL=-0.787, BAYES_00=-2.599, DNS_FROM_RFC_POST=1.708, FORGED_RCVD_HELO=0.135, TW_BG=0.077, TW_GD=0.077, TW_GT=0.077] X-Spam-Score: -1.312 X-Spam-Level: Cc: gtk-devel-list@gnome.org Subject: Mac OS X Framework X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jun 2006 20:22:48 -0000 Hoi Gregor Thanx for the Tips. This would make the Framework more like one. The ability to include it into the application bundle would be very handy. If I look at other Frameworks I always find a single library in the top directory, for example: /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ Frameworks/ImageIO.framework/ImageIO If I do "otool -L /System/Library/Frameworks/ ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/ ImageIO", I get references to many other libraries that are located inside the framework bundle: /System/Library/Frameworks/ApplicationServices.framework/ Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/ libJPEG.dylib (compatibility version 1.0.0, current version 1.0.0) /System/Library/Frameworks/ApplicationServices.framework/ Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/ libJP2.dylib (compatibility version 1.0.0, current version 1.0.0) /System/Library/Frameworks/ApplicationServices.framework/ Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/ libGIF.dylib (compatibility version 1.0.0, current version 1.0.0) /System/Library/Frameworks/ApplicationServices.framework/ Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/ libRaw.dylib (compatibility version 1.0.0, current version 1.0.0) /System/Library/Frameworks/ApplicationServices.framework/ Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/ libTIFF.dylib (compatibility version 1.0.0, current version 1.0.0) /System/Library/Frameworks/ApplicationServices.framework/ Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/ libPng.dylib (compatibility version 1.0.0, current version 1.0.0) /System/Library/Frameworks/ApplicationServices.framework/ Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/ libRadiance.dylib (compatibility version 1.0.0, current version 1.0.0) In my Gtk+.framework I have tons of libraries. Would it be possible to create something like the above for gtk? Would it make sense? Right now I just use pkg-config to find the libraries and the result looks like this: /Applications/Shity Apps/Gtk-Demo.app/Contents/MacOS/gtk-demo: /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libgdk_pixbuf-2.0.0.dylib (compatibility version 902.0.0, current version 902.0.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libgdk-quartz-2.0.0.dylib (compatibility version 902.0.0, current version 902.0.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libgtk-quartz-2.0.0.dylib (compatibility version 902.0.0, current version 902.0.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libpangocairo-1.0.0.dylib (compatibility version 1301.0.0, current version 1301.1.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libpangoft2-1.0.0.dylib (compatibility version 1301.0.0, current version 1301.1.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libpango-1.0.0.dylib (compatibility version 1301.0.0, current version 1301.1.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libatk-1.0.0.dylib (compatibility version 1115.0.0, current version 1115.0.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libgobject-2.0.0.dylib (compatibility version 1102.0.0, current version 1102.0.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libgmodule-2.0.0.dylib (compatibility version 1102.0.0, current version 1102.0.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libglib-2.0.0.dylib (compatibility version 1102.0.0, current version 1102.0.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libcairo.2.dylib (compatibility version 9.0.0, current version 9.0.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libpng12.0.dylib (compatibility version 11.0.0, current version 11.0.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libfontconfig.1.dylib (compatibility version 2.0.0, current version 2.4.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libfreetype.6.dylib (compatibility version 10.0.0, current version 10.8.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libxml2.2.dylib (compatibility version 9.0.0, current version 9.24.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libintl.3.dylib (compatibility version 8.0.0, current version 8.3.0) What do you think? Cheers, Ezra. On 11.06.2006, at 10:22, Gregor Riepl wrote: > Hi Ezra > >> Well it's looking better now. I even ended up with ready to use >> Installers. I still got my pkg-config/headers problem though so >> the script still has some ugly hard links in it., besides all the >> other debugging ugliness. I'm also not sure if the framework is >> usable the way it's now. I will first have to try to compile some >> apps against it. I'll definitely come with more problems soon. > > To make a framework fully usable, it's dynamic library paths need > to be adapted with install_name_tool. > For example, its the self-reference should be > @executable_path/../Frameworks/.framework/ > Versions/A/ > This makes the library includable in application bundles, instead > of having to install it. > But you may of course also use /Library/Frameworks/ framework>.framework/Versions/A/ > Have a look at the output of otool -L for some system and user- > installed libraries, i.e. > > $ otool -L /System/Library/Frameworks/Cocoa.framework/Cocoa > /System/Library/Frameworks/Cocoa.framework/Cocoa: > /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa > (compatibility version 1.0.0, current version 11.0.0) > /System/Library/Frameworks/AppKit.framework/Versions/C/ > AppKit (compatibility version 45.0.0, current version 822.0.0) > /System/Library/Frameworks/CoreData.framework/Versions/A/ > CoreData (compatibility version 1.0.0, current version 46.0.0) > /System/Library/Frameworks/Foundation.framework/Versions/C/ > Foundation (compatibility version 300.0.0, current version 566.0.0) > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, > current version 88.0.0) > > or > > $ otool -L /Library/Frameworks/SDL_image.framework/SDL_image > /Library/Frameworks/SDL_image.framework/SDL_image: > @executable_path/../Frameworks/SDL_image.framework/Versions/ > A/SDL_image (compatibility version 1.0.0, current version 1.0.0) > @executable_path/../Frameworks/SDL.framework/Versions/A/SDL > (compatibility version 1.0.0, current version 1.0.0) > /usr/lib/libz.1.dylib (compatibility version 1.0.0, current > version 1.0.0) > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, > current version 71.1.1) > > If a library has a lot of dependencies, you may run into a problem > here: The Mach-O header's area for library references isn't of > variable size, and install_name_tool may refuse to change all > paths. There's afaik no other way then to relink the binary with > the option -headerpad_max_install_names (see man ld). > From mclasen@redhat.com Mon Jun 12 12:04:32 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 41C3B3B000C; Mon, 12 Jun 2006 12:04:32 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09149-04; Mon, 12 Jun 2006 12:04:29 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id 7270D3B009D; Mon, 12 Jun 2006 12:04:29 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5CG3bc9030255; Mon, 12 Jun 2006 12:03:37 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5CG3bc3007778; Mon, 12 Jun 2006 12:03:37 -0400 Received: from golem.boston.redhat.com (golem.boston.redhat.com [172.16.80.24]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id k5CG3blQ018463; Mon, 12 Jun 2006 12:03:37 -0400 From: Matthias Clasen To: gnome-announce-list@gnome.org, gtk-devel-list@gnome.org, gtk-app-devel-list@gnome.org, gtk-list@gnome.org Content-Type: text/plain Date: Mon, 12 Jun 2006 12:03:36 -0400 Message-Id: <1150128216.15532.14.camel@golem.boston.redhat.com> Mime-Version: 1.0 X-Mailer: Evolution 2.7.1 (2.7.1-1) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.426 tagged_above=-999 required=2 tests=[AWL=-0.056, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, TW_LQ=0.077, TW_RX=0.077, TW_TR=0.077] X-Spam-Score: -2.426 X-Spam-Level: Cc: Subject: GLib 2.11.3 released X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gome-hackers@gnome.org List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2006 16:04:32 -0000 GLib 2.11.3 is now available for download at: ftp://ftp.gtk.org/pub/gtk/v2.11/ http://ftp.gnome.org/pub/GNOME/sources/glib/2.11/ glib-2.11.3.tar.bz2 md5sum: 41931c4965f7e1848f81b800914905cd glib-2.11.3.tar.gz md5sum: cd78ebc535e29cdef0fed9487aa21dac This is a development release leading up to GLib 2.12. Notes: * This is unstable development release. While it has had a bit of testing, there are certainly plenty of bugs remaining to be found. This release should not be used in production. * Installing this version will overwrite your existing copy of GLib 2.10. If you have problems, you'll need to reinstall GLib 2.10. * GLib 2.12 will be source and binary compatible with the GLib 2.10.x series (for some caveats, see the README). At this point, the API additions in the 2.11.x series are almost finished. * Bugs should be reported to http://bugzilla.gnome.org. About GLib ========== GLib is the low-level core library that forms the basis for projects such as GTK+ and GNOME. It provides data structure handling for C, portability wrappers, and interfaces for such runtime functionality as an event loop, threads, dynamic loading, and an object system. More information about GLib is available at: http://www.gtk.org/ An installation guide for the GTK+ libraries, including GLib, can be found at: http://developer.gnome.org/doc/API/2.0/gtk/gtk-building.html Overview of Changes from GLib 2.11.2 to GLib 2.11.3 =================================================== * GBookmarkFile: - g_bookmark_file_move_item: Return TRUE in case of an empty target * Bugs fixed: 343919 gunicollate.c: strxfrm bug on VC8 * Updated translations (fi) A list of all bugs fixed in this release can be found at: http://bugzilla.gnome.org/buglist.cgi?bug_id=343919 Thanks to everybody who has contributed to this release, in the form of bug reports or patches: Emmanuele Bassi, Kazuki Iwamoto, Tor Lillqvist Matthias Clasen June 12, 2006 From mclasen@redhat.com Mon Jun 12 15:43:04 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 851123B00E5; Mon, 12 Jun 2006 15:43:04 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27729-06; Mon, 12 Jun 2006 15:43:02 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id 5B16F3B0010; Mon, 12 Jun 2006 15:43:02 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5CJZWav007572; Mon, 12 Jun 2006 15:35:32 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5CJZWUd001833; Mon, 12 Jun 2006 15:35:32 -0400 Received: from golem.boston.redhat.com (golem.boston.redhat.com [172.16.80.24]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id k5CJZWlQ009694; Mon, 12 Jun 2006 15:35:32 -0400 From: Matthias Clasen To: gnome-announce-list@gnome.org, gtk-devel-list@gnome.org, gtk-app-devel-list@gnome.org, gtk-list@gnome.org Content-Type: text/plain Date: Mon, 12 Jun 2006 15:35:31 -0400 Message-Id: <1150140931.15532.18.camel@golem.boston.redhat.com> Mime-Version: 1.0 X-Mailer: Evolution 2.7.1 (2.7.1-1) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.541 tagged_above=-999 required=2 tests=[AWL=0.060, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.541 X-Spam-Level: Cc: Subject: GTK+ 2.8.19 released X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gnome-hackers@gnome.org List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2006 19:43:04 -0000 GTK+ 2.8.19 is now available for download at: ftp://ftp.gtk.org/pub/gtk/v2.8/ http://ftp.gnome.org/pub/GNOME/sources/gtk+/2.8/ gtk+-2.8.19.tar.bz2 md5sum: 1a03dbed4b794194a610e9d7eb175b06 gtk+-2.8.19.tar.gz md5sum: 604d3263498994c58af378f0ec076e6f This is a bugfix release in the 2.8.x series. It fixes a rare memory corruption issue when using the deprecated GdkFont API. What is GTK+ ============ GTK+ is a multi-platform toolkit for creating graphical user interfaces. Offering a complete set of widgets, GTK+ is suitable for projects ranging from small one-off tools to complete application suites. GTK+ has been designed from the ground up to support a range of languages, not only C/C++. Using GTK+ from languages such as Perl and Python (especially in combination with the Glade GUI builder) provides an effective method of rapid application development. GTK+ is free software and part of the GNU Project. However, the licensing terms for GTK+, the GNU LGPL, allow it to be used by all developers, including those developing proprietary software, without any license fees or royalties. Where to get more information about GTK+ ======================================== Information about GTK+ including links to documentation can be found at: http://www.gtk.org/ An installation guide for GTK+ 2.8 is found at: http://developer.gnome.org/doc/API/2.0/gtk/gtk-building.html Common questions: http://developer.gnome.org/doc/API/2.0/gtk/gtk-question-index.html http://www.gtk.org/faq/ Overview of Changes from GTK+ 2.8.18 to GTK+ 2.8.19 =================================================== Bugs fixed: 341327 Memory corruption inside glib 337491 _gdk_win32_drawable_release_dc: DeleteDC() called on a GetDC() handle 343425 "grab-notify"-signal is not correctly propagated for internal children 344244 Window resizing not working when keeping the aspect fixed 344496 CRLF converting via Clipboard Updated translations (ne) A list of all bugs fixed in this release can be found at: http://bugzilla.gnome.org/buglist.cgi?bug_id=343425,341327,344244,337491,344496 Thanks to everybody who has contributed to this release, in the form of bug reports or patches: Markku Vire, Sampo Savolainen, Tim Janik, Tor Lillqvist, Chris Wilson June 12, 2006 Matthias Clasen From mclasen@redhat.com Tue Jun 13 02:09:16 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 72FE93B00AF; Tue, 13 Jun 2006 02:09:16 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12183-04; Tue, 13 Jun 2006 02:09:13 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id B2F773B000C; Tue, 13 Jun 2006 02:09:13 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5D681s3022181; Tue, 13 Jun 2006 02:08:01 -0400 Received: from lacrosse.corp.redhat.com (lacrosse.corp.redhat.com [172.16.52.154]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5D67uRP017686; Tue, 13 Jun 2006 02:07:56 -0400 Received: from [172.16.83.145] (vpn83-145.boston.redhat.com [172.16.83.145]) by lacrosse.corp.redhat.com (8.12.11.20060308/8.11.6) with ESMTP id k5D67tQC015619; Tue, 13 Jun 2006 02:07:56 -0400 From: Matthias Clasen To: gnome-announce-list@gnome.org, gtk-devel-list@gnome.org, gtk-app-devel-list@gnome.org, gtk-list@gnome.org Content-Type: text/plain; charset=UTF-8 Organization: Red Hat Date: Tue, 13 Jun 2006 02:09:42 -0400 Message-Id: <1150178982.4081.13.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.7.2.1 (2.7.2.1-4) Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.426 tagged_above=-999 required=2 tests=[AWL=-0.056, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, TW_GD=0.077, TW_GT=0.077, TW_KB=0.077] X-Spam-Score: -2.426 X-Spam-Level: Cc: Subject: GTK+ 2.9.3 released X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gnome-hackers@gnome.org List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2006 06:09:16 -0000 GTK+ 2.9.3 is now available for download at: ftp://ftp.gtk.org/pub/gtk/v2.9/ http://ftp.gnome.org/pub/gnome/sources/gtk+/2.9/ gtk+-2.9.3.tar.bz2 md5sum: d73039a3b5847c352f5740ac908be7d2 gtk+-2.9.3.tar.gz md5sum: 0156eef91d2bbb23f1b6ccb49335fae5 This is a development release leading up to GTK+ 2.10. Notes: * This is unstable development release. There are certainly plenty of bugs remaining to be found. This release should not be used in production. * Installing this version will overwrite your existing copy of GTK+ 2.8. If you have problems, you'll need to reinstall GTK+ 2.8. * GTK+ 2.10 will be source compatible with the GTK+ 2.8 series; the new API additions in GTK+ 2.9.0 are not yet completely finalized, so there are likely incompatibilies between this release and the final 2.10 release. * The ABI version has been bumped from 2.4.0 to 2.10.0, since the filechooser backend interface has been changed. Third-party filechooser backends need to be ported to the new interface. Other third-party modules (input methods, image loaders, etc) just need to be reinstalled in the proper location for GTK+ to find them. * Remaining issues for GTK+ 2.10 can be found with following bugzilla query: http://bugzilla.gnome.org/buglist.cgi?product=gtk%2b&target_milestone=2.10+API+Freeze&target_milestone=2.10+Freeze&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED * Bugs should be reported to http://bugzilla.gnome.org. What is GTK+ ============ GTK+ is a multi-platform toolkit for creating graphical user interfaces. Offering a complete set of widgets, GTK+ is suitable for projects ranging from small one-off tools to complete application suites. GTK+ has been designed from the ground up to support a range of languages, not only C/C++. Using GTK+ from languages such as Perl and Python (especially in combination with the Glade GUI builder) provides an effective method of rapid application development. GTK+ is free software and part of the GNU Project. However, the licensing terms for GTK+, the GNU LGPL, allow it to be used by all developers, including those developing proprietary software, without any license fees or royalties. Where to get more information about GTK+ ======================================== Information about GTK+ including links to documentation can be found at: http://www.gtk.org/ An installation guide for GTK+ 2.x is found at: http://developer.gnome.org/doc/API/2.4/gtk/gtk-building.html Common questions: http://developer.gnome.org/doc/API/2.4/gtk/gtk-question-index.html http://www.gtk.org/faq/ Overview of Changes from GTK+ 2.9.2 to 2.9.3 ============================================ * GtkPrintOperation: - Introduce an allow-async property - Introduce a GtkPrintOperationAction enumeration - Rename pdf_target to export_filename - Allow to hide "Print to PDF" in the low-level API * GtkNotebook: - Add a destroy notify to gtk_notebook_set_window_creation_hook. * GtkTreeView: - Support grid lines * GtkRange: - Add a number of new stle properties which allow more fexible stepper theming * Bugs fixed: 153212 Have the Paste kbd shortcut jump to the location in the buffer 337491 _gdk_win32_drawable_release_dc: DeleteDC() called on a GetDC() handle 339739 gtk/gtkprintoperation-win32.c: 3 compile error 342339 GtkRange::stepper-spacing style property not implemented correctly 343945 Buttons of a GtkAssistant are not accessible 344148 Wrong reqs for ATK 344209 gtk_notebook_set_window_creation_hook() has no destroy func. 344232 GtkEntry's "Delete" context menu item is sensitive on a non-editable GtkEntry 344244 Window resizing not working when keeping the aspect fixed 344288 gtk_print_operation_preview_is_selected must return a value 344386 gdk-2.0-uninstalled.pc.in and gdkconfig.h 344496 CRLF converting via Clipboard 344504 GtkPrintCapabilities not in gtktypebuiltins.h 344505 Wrong signal registration for create_custom_widget 344512 cvs build issue 344513 pdf print module's print_stream not calling destroy notify 344518 NULL unref in page setup dialogue 344543 gtk_progress_bar_pulse calls gtk_progress_bar_paint directly 344560 gtk_print_settings_[sg]et_scale shouldn't be in percent 344607 memory leaks in gtkrecentchooserdefault.c and gtkrecentchoosermenu.c 344624 Memory leak in gtk_tree_model_filter_finalize: User data not freed 337603 Possible off-by-one in gdk_pango_layout_line_get_clip_region 344239 Wrong filename for gtk-find stock item. 344528 comma at end of GtkPrintOperationAction enum causes mozilla compilation error 344290 horizontal-padding not take into account when placing submenus 344558 document print dialogue response codes 339592 Add print-to-postscript 342249 Allow to draw upper and lower sides of GtkRange's trough differently 344530 gtk_recent_chooser_widget_new_for_manager and gtk_recent_chooser_menu_new_for_manager should allow NULL manager arg * Updated translations (es,fi,gu,ko,th,wa) A list of all bugs fixed in this release can be found at: http://bugzilla.gnome.org/buglist.cgi?bug_id=153212,337491,339739,342339,343945,344148,344209,344232,344244,344288,344386,344496,344504,344505,344512,344513,344518,344543,344560,344607,344624,337603,344239,344528,344290,344558,339592,342249,344530 Thanks to everybody who has contributed to this release, in the form of bug reports or patches: Behdad Esfahbod, Bastian Nocera, Alexander Larsson, Jrg Billeter, Murray Cumming, Milosz Derezynski, Tor Lillqvist, Kazuki Iwamoto, Chris Wilson, Michael Natterer, Benjamin Berg, Marko Anastasov, Christian Persch, Masatake Yamamoto, Elijah Newren, John Finlay, Emmanuele Bassi, David Malcolm, John Darrington, Christian Weiske, Yvgen Muntyan, Martyn Russell, Kristian Rietveld June 13, 2006 Matthias Clasen From exe522@hotmail.com Tue Jun 13 09:17:01 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 1FF7B3B000A for ; Tue, 13 Jun 2006 09:17:01 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24109-07 for ; Tue, 13 Jun 2006 09:17:00 -0400 (EDT) Received: from hotmail.com (bay104-f2.bay104.hotmail.com [65.54.175.12]) by menubar.gnome.org (Postfix) with ESMTP id 4C4843B00AF for ; Tue, 13 Jun 2006 09:17:00 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 13 Jun 2006 06:16:02 -0700 Message-ID: Received: from 65.54.175.200 by by104fd.bay104.hotmail.msn.com with HTTP; Tue, 13 Jun 2006 13:15:57 GMT X-Originating-IP: [86.212.127.235] X-Originating-Email: [exe522@hotmail.com] X-Sender: exe522@hotmail.com In-Reply-To: <2672cf4d0606050752o12a6d0d2gcb4c355cc0f35d79@mail.gmail.com> From: "Malik NakaMura" To: domlachowicz@gmail.com Date: Tue, 13 Jun 2006 13:15:57 +0000 Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed X-OriginalArrivalTime: 13 Jun 2006 13:16:02.0831 (UTC) FILETIME=[851C21F0:01C68EEB] X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-0.736 tagged_above=-999 required=2 tests=[AWL=-1.532, BAYES_05=-1.11, DNS_FROM_RFC_ABUSE=0.2, DNS_FROM_RFC_POST=1.708, MSGID_FROM_MTA_HEADER=0, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -0.736 X-Spam-Level: Cc: gtk-devel-list@gnome.org Subject: Re: GTK+ >> Cocoa Native Port X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2006 13:17:01 -0000 This is my first version of _gdk_quartz_copy_to_image. The only problem is that I didnt succeed in getting the color map from "drawable"... so the image is displayed without its original colors GdkImage * _gdk_quartz_copy_to_image (GdkDrawable *drawable, GdkImage *image, gint src_x, gint src_y, gint dest_x, gint dest_y, gint width, gint height) { GdkPixbuf *pixbuf; //printf("_gdk_quartz_copy_to_image : To Implement\n"); pixbuf = NULL; image = g_object_new (gdk_image_get_type (), NULL); image->type = GDK_TYPE_IMAGE; image->width = width; image->height = height; image->byte_order = (G_BYTE_ORDER == G_LITTLE_ENDIAN) ? GDK_LSB_FIRST : GDK_MSB_FIRST; image->bpp = 4; image->bpl = image->width * image->bpp; image->bits_per_pixel = image->bpp * 8; image->colormap = (GdkColormap *)g_malloc(sizeof(GdkColormap)); memcpy(image->colormap, GDK_DRAWABLE_IMPL_QUARTZ (&(GDK_PIXMAP_IMPL_QUARTZ (drawable)->parent_instance))->colormap, sizeof(GdkColormap)); if(image->colormap != NULL) { image->visual = (GdkVisual *)g_malloc(sizeof(GdkVisual)); memcpy(image->visual, gdk_colormap_get_visual (image->colormap), sizeof(GdkVisual)); if (image->visual) { void *data; int x, y; guint32 *pix, *pixels; image->depth = image->visual->depth; image->mem = g_malloc (image->bpl * image->height); memset (image->mem, 0x00, image->bpl * image->height); data = GDK_PIXMAP_IMPL_QUARTZ (drawable)->data; pixels = (guint32 *)data; for (y = 0; y < image->height; y++) { pix = pixels+((image->height - 1 - y)*width); for (x = 0; xwidth; x++) { gdk_image_put_pixel (image, x, y, *pix); pix++; } } return image; } } g_free(image); image = NULL; return NULL; } From kloczek@rudy.mif.pg.gda.pl Tue Jun 13 09:41:41 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 2C9B33B008F for ; Tue, 13 Jun 2006 09:41:41 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24974-03 for ; Tue, 13 Jun 2006 09:41:37 -0400 (EDT) Received: from rudy.mif.pg.gda.pl (rudy.mif.pg.gda.pl [153.19.42.16]) by menubar.gnome.org (Postfix) with ESMTP id 59FF13B000C for ; Tue, 13 Jun 2006 09:41:37 -0400 (EDT) X-Virus-Scanned: at rudy.mif.pg.gda.pl Received: by rudy.mif.pg.gda.pl (plum, from userid 2732) id 39ED2233B7; Tue, 13 Jun 2006 15:40:54 +0200 (CEST) Date: Tue, 13 Jun 2006 15:40:53 +0200 (CEST) From: =?ISO-8859-2?Q?Tomasz_K=B3oczko?= To: gtk-devel-list@gnome.org Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1270146782-1150206053=:31655" X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.579 tagged_above=-999 required=2 tests=[AWL=0.022, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.579 X-Spam-Level: Subject: gtk+ 2.9.3 compilation fail X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2006 13:41:41 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1270146782-1150206053=:31655 Content-Type: TEXT/PLAIN; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 8BIT gcc -DG_DISABLE_DEPRECATED -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -o .libs/gtk-query-immodules-2.0 queryimmodules.o ./.libs/libgtk-x11-2.0.so -L/lib64 /home/users/prac/nd/kloczek/rpm/BUILD/gtk+-2.9.3/gdk/.libs/libgdk-x11-2.0.so -latk-1.0 ../gdk-pixbuf/.libs/libgdk_pixbuf-2.0.so ../gdk/.libs/libgdk-x11-2.0.so -lpangocairo-1.0 -lpango-1.0 -lcairo -lfontconfig -lXext -lXrender -lX11 -lXinerama -lXi -lXrandr -lXcursor -lXfixes /home/users/prac/nd/kloczek/rpm/BUILD/gtk+-2.9.3/gdk-pixbuf/.libs/libgdk_pixbuf-2.0.so -lgmodule-2.0 -ldl -lgobject-2.0 -lglib-2.0 -lm ./.libs/libgtk-x11-2.0.so: undefined reference to `cairo_surface_set_fallback_resolution' collect2: ld returned 1 exit status make[4]: *** [gtk-query-immodules-2.0] Error 1 make[4]: Leaving directory `/home/users/prac/nd/kloczek/rpm/BUILD/gtk+-2.9.3/gtk' $ rpm -q cairo cairo-1.1.6-6 kloczek -- ----------------------------------------------------------- *Ludzie nie maj problemw, tylko sobie sami je stwarzaj* ----------------------------------------------------------- Tomasz Koczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek@rudy.mif.pg.gda.pl* --0-1270146782-1150206053=:31655-- From federico@ximian.com Tue Jun 13 12:13:42 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 31B0B3B0071 for ; Tue, 13 Jun 2006 12:13:42 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29632-05 for ; Tue, 13 Jun 2006 12:13:41 -0400 (EDT) Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) by menubar.gnome.org (Postfix) with ESMTP id 9C36B3B000A for ; Tue, 13 Jun 2006 12:13:40 -0400 (EDT) Received: (qmail 22968 invoked from network); 13 Jun 2006 16:11:48 -0000 Received: from localhost (HELO 164-99-120-90.boston.ximian.com) (127.0.0.1) by localhost with SMTP; 13 Jun 2006 16:11:48 -0000 From: Federico Mena Quintero To: Michael Natterer In-Reply-To: <1149849193.3010.23.camel@localhost> References: <1149608483.14088.54.camel@cacharro.xalalinux.org> <1149849193.3010.23.camel@localhost> Content-Type: text/plain Date: Tue, 13 Jun 2006 11:07:30 -0500 Message-Id: <1150214850.17566.118.camel@cacharro.xalalinux.org> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.574 tagged_above=-999 required=2 tests=[AWL=0.025, BAYES_00=-2.599] X-Spam-Score: -2.574 X-Spam-Level: Cc: GTK+ development mailing list , Michael.meeks@novell.com Subject: Re: Default timeouts X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2006 16:13:42 -0000 On Fri, 2006-06-09 at 12:33 +0200, Michael Natterer wrote: > However in some places I introduced a factor of 5 so all existing > timeouts could be done with the two values from GtkSettings. > > See comment #10 of http://bugzilla.gnome.org/show_bug.cgi?id=142582 > > Actually, it may make sense to simply use the user's configured > key repeat and delay for these two setting values. What do you > think? Yeah, it makes perfect sense to make it the same as the key repeat rate. You'll then get the same rate of change whether you use the mouse or the keyboard. Federico From stefan@space.twc.de Tue Jun 13 14:33:13 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id A37933B02D9 for ; Tue, 13 Jun 2006 14:33:13 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01854-06 for ; Tue, 13 Jun 2006 14:33:08 -0400 (EDT) Received: from space.twc.de (port-83-236-178-131.static.qsc.de [83.236.178.131]) by menubar.gnome.org (Postfix) with ESMTP id 1C3EE3B00C9 for ; Tue, 13 Jun 2006 14:33:07 -0400 (EDT) Received: from stefan by space.twc.de with local (Exim 4.50) id 1FqEOs-0007KV-NR; Tue, 13 Jun 2006 21:18:06 +0200 Date: Tue, 13 Jun 2006 21:18:06 +0200 To: Tim Janik Message-ID: <20060613191806.GA28032@space.twc.de> References: <20060609152646.GE20719@space.twc.de> <200606091630.k59GUaES013244@caipclassic.rutgers.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i From: Stefan Westerfeld X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.305 tagged_above=-999 required=2 tests=[AWL=0.159, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.305 X-Spam-Level: Cc: "Kaveh R. Ghazi" , Gtk+ Developers , gcc@gcc.gnu.org Subject: Re: Problem with type safety and the "sentinel" attribute X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2006 18:33:13 -0000 Hi! On Fri, Jun 09, 2006 at 07:30:25PM +0200, Tim Janik wrote: > On Fri, 9 Jun 2006, Kaveh R. Ghazi wrote: > >> void print_string_array (const char *array_name, > >> const char *string, ...) __attribute__ > >> ((__sentinel__)); > >> > >> print_string_array ("empty_array", NULL); /* gcc warns, but shouldn't > >*/ > >> > >> The only way out for keeping the sentinel attribute and avoiding the > >> warning is using > >> > >> static void print_string_array (const char *array_name, ...) > >> __attribute__ ((__sentinel__)); > > > >I think you could maintain typesafety and silence the warning by > >keeping the more specific prototype and adding an extra NULL, e.g.: > > > >print_string_array ("empty_array", NULL, NULL); > > > >Doesn't seem elegant, but it does the job. > > this is an option for a limited set of callers, yes. For the statistics, by adding the __sentinel__ attribute to the beast codebase, I have about 50 of those sentinel warnings that I don't need. So the double NULL termination would make quite some code more messy than it should be. > >> By the way, there is already an existing gcc bug, which is about the > >> same thing (NULL passed within named args), but wants to have it the > >> way it works now: > >> > >> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21911 > > > >Correct, the feature as I envisioned it expected the sentinel to > >appear in the variable arguments only. This PR reflects when I found > >out it didn't do that and got around to fixing it. Note the "buggy" > >behavior wasn't exactly what you wanted either because GCC got fooled > >by a sentinel in *any* of the named arguments, not just the last one. Ah, I see. > >> so if it gets changed, then gcc might need to support both > >> - NULL termination within the last named parameter allowed > >> - NULL termination only allowed within varargs parameters (like it is > >> now) > > > >I'm not against this enhancement, but you need to specify a syntax > >that allows the old behavior but also allows doing it your way. > > > >Hmm, perhaps we could check for attribute "nonnull" on the last named > >argument, if it exists then that can't be the sentinel, if it's not > >there then it does what you want. This is not completely backwards > >compatible because anyone wanting the existing behavior has to add the > >attribute nonnull. But there's precedent for this when attribute > >printf split out whether the format specifier could be null... > > > >We could also create a new attribute name for the new behavior. This > >would preserve backwards compatibility. I like this idea better. > > i agree here. as far as the majority of the GLib and Gtk+ APIs are > concerned, > we don't really need the flexibility of the sentinel attribute but rather > a compiler check on whether the last argument used in a function call > is NULL or 0 (regardless of whether it's the last named arg or already part > of the varargs list). > that's also why the actual sentinel wrapper in GLib looks like this: > > #define G_GNUC_NULL_TERMINATED __attribute__((__sentinel__)) > > so, if i was to make a call on this issue, i'd either introduce > __attribute__((__null_terminated__)) with the described semantics, > or have __attribute__((__sentinel__(-1))) work essentially like > __attribute__((__sentinel__(0))) while also accepting 0 in the position > of the last named argument. I also like the backwards compatible way better than trying to somehow modifying the attribute; it may break something now, or - which would also be bad - it may make something that somebody will want to check with the sentinel attribute in some future program impossible. The only case that I ever needed was NULL termination, so I think implementing one of the two proposals Tim made would be sufficient. Personally I like __attribute__((__null_terminated__)) better, because a -1 sentinel may be less intuitive to read in the source code. So this would be my suggestion for a "syntax specification". > >Next you need to recruit someone to implement this enhancement, or > >submit a patch. :-) Although given that you can silence the warning by > >adding an extra NULL at the call site, I'm not sure it's worth it. > > i would say this is definitely worth it, because the issue also shows up in > other code that is widely used: > gpointer g_object_new (GType object_type, > const gchar *first_property_name, > ...); > that's for instance a function which is called in many projects. > putting the burden on the caller is clearly the wrong trade off here. > > so please take this as a vote for the worthiness of a fix ;) Good. Of course I would be happy if somebody with knowledge of the compiler source could implement it. I never hacked gcc code before. But since you suggested sending a patch, I'll at least try to implement a new __null_terminated__ attribute, and ask for help if I can't figure out what to do. Cu... Stefan -- Stefan Westerfeld, Hamburg/Germany, http://space.twc.de/~stefan From easy-b@freesurf.ch Tue Jun 13 16:37:46 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 1FEC53B03CF for ; Tue, 13 Jun 2006 16:37:46 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05861-06 for ; Tue, 13 Jun 2006 16:37:45 -0400 (EDT) Received: from mail-fs.sunrise.ch (mta-fs-be-01.sunrise.ch [194.158.229.16]) by menubar.gnome.org (Postfix) with ESMTP id B948D3B00C8 for ; Tue, 13 Jun 2006 16:37:44 -0400 (EDT) Received: from [10.0.1.2] (84.226.131.17) by mail-fs.sunrise.ch (7.2.073) id 44795C850064786C; Tue, 13 Jun 2006 22:36:45 +0200 In-Reply-To: <89C1D6F0-EDC8-495C-B76B-9909E6388E62@freesurf.ch> References: <20060522160033.F1A8E3B1CE4@menubar.gnome.org> <772588ED-500A-4A11-8829-DA80B9A35D1F@freesurf.ch> <44720B8C.3080903@imendio.com> <0A34FCC9-6650-4737-B86D-1B503D8A9072@freesurf.ch> <7D6367DC-8689-453B-8FD7-217632BC1DAE@freesurf.ch> <89C1D6F0-EDC8-495C-B76B-9909E6388E62@freesurf.ch> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2B5653F8-341D-440C-9D5C-F166B296F94E@freesurf.ch> Content-Transfer-Encoding: 7bit From: Easy B Date: Tue, 13 Jun 2006 22:36:44 +0200 To: Gregor Riepl X-Mailer: Apple Mail (2.749.3) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-0.997 tagged_above=-999 required=2 tests=[AWL=-0.549, BAYES_00=-2.599, DNS_FROM_RFC_POST=1.708, FORGED_RCVD_HELO=0.135, TW_BG=0.077, TW_GD=0.077, TW_GT=0.077, TW_PK=0.077] X-Spam-Score: -0.997 X-Spam-Level: Cc: gtk-devel-list@gnome.org Subject: Re: Mac OS X Framework X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2006 20:37:46 -0000 Hi So i understand that we only need to link against one library that is linked to all the other ones, right? If I look at libgtk-quartz-2.0.dylib I see following: libgtk-quartz-2.0.dylib: /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libgtk-quartz-2.0.0.dylib (compatibility version 902.0.0, current version 902.0.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libgdk_pixbuf-2.0.0.dylib (compatibility version 902.0.0, current version 902.0.0) /usr/lib/libiconv.2.dylib (compatibility version 5.0.0, current version 5.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.1.5) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libgdk-quartz-2.0.0.dylib (compatibility version 902.0.0, current version 902.0.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libpangoft2-1.0.0.dylib (compatibility version 1301.0.0, current version 1301.1.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libpng12.0.dylib (compatibility version 11.0.0, current version 11.0.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libfontconfig.1.dylib (compatibility version 2.0.0, current version 2.4.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libfreetype.6.dylib (compatibility version 10.0.0, current version 10.8.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libxml2.2.dylib (compatibility version 9.0.0, current version 9.24.0) /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.3) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libpangocairo-1.0.0.dylib (compatibility version 1301.0.0, current version 1301.1.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libpango-1.0.0.dylib (compatibility version 1301.0.0, current version 1301.1.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libatk-1.0.0.dylib (compatibility version 1115.0.0, current version 1115.0.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libgobject-2.0.0.dylib (compatibility version 1102.0.0, current version 1102.0.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libgmodule-2.0.0.dylib (compatibility version 1102.0.0, current version 1102.0.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libglib-2.0.0.dylib (compatibility version 1102.0.0, current version 1102.0.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libcairo.2.dylib (compatibility version 9.0.0, current version 9.0.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libintl.3.dylib (compatibility version 8.0.0, current version 8.3.0) So I guess everything what we need is there. But I don't really get how to satisfy configure of a gtk app so that it only uses "- framework Gtk+". Sorry for my ignorance I'm pretty much a newbe on these things. Cheers, Ezra. On 12.06.2006, at 08:47, Gregor Riepl wrote: >> Thanx for the Tips. This would make the Framework more like one. >> The ability to include it into the application bundle would be >> very handy. >> >> If I look at other Frameworks I always find a single library in >> the top directory, for example: >> >> /System/Library/Frameworks/ApplicationServices.framework/Versions/ >> A/Frameworks/ImageIO.framework/ImageIO > that's right, this is the dynamic library itself. it doesn't have > the dylib suffix, but you may specify one if you like. > executables need to be linked against that, then, just -framework X > doesn't work. on the other hand, it's a good idea to either make > the "main" library (like libgtk-2.0.0.dylib) the framework (and > include all dependent libraries as either frameworks on their own > or dylibs) or just create an empty stub library that links against > those libraries or frameworks. to do that, make an empty .c source, > compile and link it against all the dylibs/frameworks you need. but > i can't tell if that's a good idea. > >> If I do "otool -L /System/Library/Frameworks/ >> ApplicationServices.framework/Versions/A/Frameworks/ >> ImageIO.framework/ImageIO", I get references to many other >> libraries that are located inside the framework bundle: > i guess that would be such a stub library, but maybe there's other > functionality contained? > otool can help you getting the symbols from mach-o binaries, much > like objdump. > >> In my Gtk+.framework I have tons of libraries. Would it be >> possible to create something like the above for gtk? Would it make >> sense? Right now I just use pkg-config to find the libraries and >> the result looks like this: >> >> /Applications/Shity Apps/Gtk-Demo.app/Contents/MacOS/gtk-demo: >> /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ >> libgdk_pixbuf-2.0.0.dylib (compatibility version 902.0.0, current >> version 902.0.0) >> ....... >> /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ >> libintl.3.dylib (compatibility version 8.0.0, current version 8.3.0) >> >> What do you think? > you should use /Library/Frameworks/Gtk+.framework/Versions/2.9.1/Gtk > + as the main library. it doesn't matter if that's just a stub or > the last library in the build chain (yes, i don't see > libgtk-2.0.0.dylib anywhere?). binaries then wouldn't require to be > linked against all those libs mentioned above. > this way you can also link gtk software with -framework Gtk+ and > nothing else, which you could even move into the pkconfig file and > thus facilitate porting. > i did something similar with the readily-available SDL framework > fpr mac os x, but it doesn't work very well because of the missing > startup code. with gtk it's easier i guess. > > have a nice day > gregor > > p.s.: on second thought, there could be a problem. afaik if a > binary loads a dylib, only that dylib's symbols become available > for it. the dependent symbols from libs that dylib's linked against > stay local for that dylib... maybe there's a workaround for this or > you come up with a better idea? From ntd@users.sourceforge.net Thu Jun 15 04:25:32 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 382C53B0324 for ; Thu, 15 Jun 2006 04:25:32 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22415-07 for ; Thu, 15 Jun 2006 04:25:29 -0400 (EDT) Received: from mailout01.albacom.net (mailout01.albacom.net [217.220.34.13]) by menubar.gnome.org (Postfix) with SMTP id 0694D3B0311 for ; Thu, 15 Jun 2006 04:25:28 -0400 (EDT) Received: (qmail 13668 invoked by uid 508); 15 Jun 2006 08:25:00 -0000 Received: from ntd@users.sourceforge.net by mailout01.albacom.net with qmail-scanner (spamassassin: ???. Clear:RC:1(217.221.76.9):SA:0(0.0/15.0):. Processed in 0.697195 secs); 15 Jun 2006 08:25:00 -0000 Received: from unknown (HELO sviluppo.internet.local) (postmaster@effe-gi.it@217.221.76.9) by mailout01.albacom.net with SMTP; 15 Jun 2006 08:24:59 -0000 Content-Disposition: inline From: Fontana Nicola Organization: Elettronica EFFE-GI s.n.c. To: gtk-devel-list@gnome.org Subject: GObject extension propose (GContainer) Date: Thu, 15 Jun 2006 11:01:12 +0000 User-Agent: KMail/1.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200606151101.12868.ntd@users.sourceforge.net> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.599 tagged_above=-999 required=2 tests=[BAYES_00=-2.599] X-Spam-Score: -2.599 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 08:25:32 -0000 Hi all, I'm a GObject based libraries (for UI purpose and not) user and I often need a generic container to derive my own types. In my opinion, I think this generic container must be included inside the GObject library ... it could be used by a lot of derived libraries providing a common approach. I published my solution - that is, what I am currently using - on sourceforge. http://sourceforge.net/projects/gcontainer/ Is it a good idea? Is something planned in this direction? Am I totally wrong? I need feedbacks ... Nicola From mclasen@redhat.com Thu Jun 15 09:54:37 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 88F2B3B00F3 for ; Thu, 15 Jun 2006 09:54:37 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14500-10 for ; Thu, 15 Jun 2006 09:54:36 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id 12BF23B0261 for ; Thu, 15 Jun 2006 09:54:36 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5FDsZ1W022208 for ; Thu, 15 Jun 2006 09:54:35 -0400 Received: from lacrosse.corp.redhat.com (lacrosse.corp.redhat.com [172.16.52.154]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5FDsZa4019641 for ; Thu, 15 Jun 2006 09:54:35 -0400 Received: from [172.16.83.98] (dhcp83-98.boston.redhat.com [172.16.83.98]) by lacrosse.corp.redhat.com (8.12.11.20060308/8.11.6) with ESMTP id k5FDsZL7008811 for ; Thu, 15 Jun 2006 09:54:35 -0400 Subject: GTK+ 2.10, the endgame From: Matthias Clasen To: gtk-devel-list@gnome.org Content-Type: text/plain Organization: Red Hat Date: Thu, 15 Jun 2006 09:56:26 -0400 Message-Id: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> Mime-Version: 1.0 X-Mailer: Evolution 2.7.3 (2.7.3-2) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.542 tagged_above=-999 required=2 tests=[AWL=0.059, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.542 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 13:54:37 -0000 I want to have GTK+ 2.10 ready at or immediately after GUADEC. I did not declare 2.9.3 api frozen in the release announcement, because we were still holding the door open for Kris' work on the new tooltips api. But he has run into some difficulties with the implementation which will take some time to overcome, so we have decided to punt this feature and try to get it into 2.12 early. Therefore, I want to consider 2.9.3 api frozen, and take a look at what still needs to happen before 2.10. Here are some things I personally would like get worked on (not sure how much time I can free to look into these myself): - I think the async filechooser conversion has caused some regressions, I noticed that .hidden support seems broken and autocompletion also behaved badly for me recently. - There is a number of FIXMEs and unimplemented bits in the print code. - The print backends need a careful look wrt to memory leaks and error reporting. Are there other important bugs or regressions that need attention before 2.10 ? Another thing I have slacked off about is organizing a GTK+ team meeting at GUADEC. So, who of the GTK+ team is there and at what times ? Should we try to find a free hour during the core days, or does everybody stay for the after hours ? If so, it may be easier to do a team meeting on Thursday... Matthias From timj@gtk.org Thu Jun 15 10:53:17 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id BBF963B04EA for ; Thu, 15 Jun 2006 10:53:17 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17592-10 for ; Thu, 15 Jun 2006 10:53:16 -0400 (EDT) Received: from holken.mikan.net (holken.mikan.net [83.145.56.183]) by menubar.gnome.org (Postfix) with ESMTP id 035EF3B04E7 for ; Thu, 15 Jun 2006 10:53:15 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by holken.mikan.net (Postfix) with ESMTP id C0DB83352B4; Thu, 15 Jun 2006 16:52:21 +0200 (CEST) Received: from holken.mikan.net ([127.0.0.1]) by localhost (holken.mikan.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16765-03; Thu, 15 Jun 2006 16:52:18 +0200 (CEST) Received: from birnet.org (c152167.adsl.hansenet.de [213.39.152.167]) by holken.mikan.net (Postfix) with ESMTP id E3B0433529D; Thu, 15 Jun 2006 16:52:17 +0200 (CEST) Received: from master.birnet.private (localhost.localdomain [127.0.0.1]) by birnet.org (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k5FEqH2d008152 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 15 Jun 2006 16:52:18 +0200 Received: (from timj@localhost) by master.birnet.private (8.13.4/8.13.4/Submit) id k5FEqHpN008151; Thu, 15 Jun 2006 16:52:17 +0200 Date: Thu, 15 Jun 2006 16:52:17 +0200 (CEST) From: Tim Janik X-X-Sender: timj@master.birnet.private To: Fontana Nicola Subject: Re: GObject extension propose (GContainer) In-Reply-To: <200606151101.12868.ntd@users.sourceforge.net> Message-ID: References: <200606151101.12868.ntd@users.sourceforge.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at holken.mikan.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.38 tagged_above=-999 required=2 tests=[AWL=0.084, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.38 X-Spam-Level: Cc: Gtk+ Developers X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 14:53:17 -0000 On Thu, 15 Jun 2006, Fontana Nicola wrote: > Hi all, > > I'm a GObject based libraries (for UI purpose and not) user and I often need > a generic container to derive my own types. In my opinion, I think this > generic container must be included inside the GObject library ... it could > be used by a lot of derived libraries providing a common approach. > > I published my solution - that is, what I am currently using - on > sourceforge. > > http://sourceforge.net/projects/gcontainer/ > > Is it a good idea? Is something planned in this direction? Am I totally > wrong? > > I need feedbacks ... hi. your gcontainer-1.0.0 looks like an interesting approach to me, but i'm not sure it's generally good to put that into stock libgobject. the main reason is that container needs are probably pretty variable out there (i've come across at least 4 different gobject container implementations in free software projects i'm woorking on) and that both, making too little assumptions in the child/container interface isn't going to be very helpful, albeit making too many has the same problem. i guess we could add a link to your project from the libgobject docs (it should probably have a Contrib section), for people possibly looking for a GObject container implementation. that way, gcontainer-1.0.0 gets a chance of being reused and maybe extended to something generally usefull for GObject applications out there. > Nicola --- ciaoTJ From timj@gtk.org Thu Jun 15 11:31:19 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 642E33B02ED for ; Thu, 15 Jun 2006 11:31:19 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19431-03 for ; Thu, 15 Jun 2006 11:31:18 -0400 (EDT) Received: from holken.mikan.net (holken.mikan.net [83.145.56.183]) by menubar.gnome.org (Postfix) with ESMTP id 2E9543B0155 for ; Thu, 15 Jun 2006 11:31:18 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by holken.mikan.net (Postfix) with ESMTP id B5DB533524B; Thu, 15 Jun 2006 16:32:01 +0200 (CEST) Received: from holken.mikan.net ([127.0.0.1]) by localhost (holken.mikan.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16412-10; Thu, 15 Jun 2006 16:31:58 +0200 (CEST) Received: from birnet.org (c152167.adsl.hansenet.de [213.39.152.167]) by holken.mikan.net (Postfix) with ESMTP id D5D7E335256; Thu, 15 Jun 2006 16:31:57 +0200 (CEST) Received: from master.birnet.private (localhost.localdomain [127.0.0.1]) by birnet.org (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k5FEVrL1007682 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 15 Jun 2006 16:31:53 +0200 Received: (from timj@localhost) by master.birnet.private (8.13.4/8.13.4/Submit) id k5FEVis7007681; Thu, 15 Jun 2006 16:31:45 +0200 Date: Thu, 15 Jun 2006 16:31:44 +0200 (CEST) From: Tim Janik X-X-Sender: timj@master.birnet.private To: Matthias Clasen Subject: GTK+ meeting at GUADEC (Re: GTK+ 2.10, the endgame) In-Reply-To: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> Message-ID: References: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at holken.mikan.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.381 tagged_above=-999 required=2 tests=[AWL=0.083, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.381 X-Spam-Level: Cc: Gtk+ Developers X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 15:31:19 -0000 On Thu, 15 Jun 2006, Matthias Clasen wrote: > I want to have GTK+ 2.10 ready at or immediately after GUADEC. > Another thing I have slacked off about is organizing a GTK+ > team meeting at GUADEC. So, who of the GTK+ team is there > and at what times ? Should we try to find a free hour during > the core days, or does everybody stay for the after hours ? > If so, it may be easier to do a team meeting on Thursday... i think i volounteered to take on arrangement of that to some extend. at least, we intended to have a meeting on GTK+ linking issues, and could probably merge that with the GTK+ team meeting during guadec. the plan for that was to send out en email next friday/saturday (i.e right at the guadec start) to figure/suggest dates suitable for everyone to attend. > Matthias --- ciaoTJ From hfiguiere@teaser.fr Thu Jun 15 11:52:14 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C00CA3B0261 for ; Thu, 15 Jun 2006 11:52:14 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20706-05 for ; Thu, 15 Jun 2006 11:52:13 -0400 (EDT) Received: from xandros.com (smtp1.xandros.com [209.87.238.70]) by menubar.gnome.org (Postfix) with ESMTP id 6D7663B053A for ; Thu, 15 Jun 2006 11:52:13 -0400 (EDT) Received: from [172.16.1.95] (unknown [209.87.238.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by xandros.com (Postfix) with ESMTP id 4B02239025; Thu, 15 Jun 2006 11:51:30 -0400 (EDT) Message-ID: <44918201.6010605@teaser.fr> Date: Thu, 15 Jun 2006 11:51:29 -0400 From: Hubert Figuiere User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: Matthias Clasen Subject: Re: GTK+ 2.10, the endgame References: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> In-Reply-To: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.54 tagged_above=-999 required=2 tests=[AWL=0.059, BAYES_00=-2.599] X-Spam-Score: -2.54 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 15:52:14 -0000 Matthias Clasen wrote: > I want to have GTK+ 2.10 ready at or immediately after GUADEC. Can somebody summarize the Mac port status? Hub From tristan.van.berkom@gmail.com Thu Jun 15 12:44:57 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 0A0273B05DC for ; Thu, 15 Jun 2006 12:44:57 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23203-02 for ; Thu, 15 Jun 2006 12:44:56 -0400 (EDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.200]) by menubar.gnome.org (Postfix) with ESMTP id 0AD9C3B007F for ; Thu, 15 Jun 2006 12:44:55 -0400 (EDT) Received: by wx-out-0102.google.com with SMTP id i30so312681wxd for ; Thu, 15 Jun 2006 09:44:14 -0700 (PDT) Received: by 10.70.100.8 with SMTP id x8mr2494520wxb; Thu, 15 Jun 2006 09:44:14 -0700 (PDT) Received: from ?66.48.170.37? ( [66.48.170.37]) by mx.gmail.com with ESMTP id i39sm1649326wxd.2006.06.15.09.44.12; Thu, 15 Jun 2006 09:44:14 -0700 (PDT) Message-ID: <44919246.8060301@gnome.org> Date: Thu, 15 Jun 2006 13:00:54 -0400 User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Janik Subject: Re: GObject extension propose (GContainer) References: <200606151101.12868.ntd@users.sourceforge.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit From: Tristan Van Berkom X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.481 tagged_above=-999 required=2 tests=[AWL=-0.414, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=1.456, SPF_PASS=-0.001, TW_GT=0.077] X-Spam-Score: -1.481 X-Spam-Level: Cc: Gtk+ Developers X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 16:44:57 -0000 Tim Janik wrote: >On Thu, 15 Jun 2006, Fontana Nicola wrote: > > > >>Hi all, >> >>I'm a GObject based libraries (for UI purpose and not) user and I often need >>a generic container to derive my own types. In my opinion, I think this >>generic container must be included inside the GObject library ... it could >>be used by a lot of derived libraries providing a common approach. >> >>I published my solution - that is, what I am currently using - on >>sourceforge. >> >>http://sourceforge.net/projects/gcontainer/ >> >>Is it a good idea? Is something planned in this direction? Am I totally >>wrong? >> >>I need feedbacks ... >> >> As a side note... I've been working on container --> child relationships and honing them down inside the glade builder... objects may for example have object delagates that are "owned" and in turn may "own" other delagates... this is all functional with libglade facilities and the future gtk builder also (from the design as of yet...)... this concept of "types of container relationships" is also usefull for GtkMenuShell --> GtkMenu for example (not just any GtkWidget can be added to a menushell). All of that just to say... I cannot count the times I've thought to myself that GtkContainer should really just be GContainerIface, and implemented by whatever interested objects that want to parent other objects... I think that what we need is not really "yet another container api", but a container api that is a unified front for generic handling of the GTK object hierarchy at runtime. Cheers, -Tristan From federico@ximian.com Thu Jun 15 12:56:13 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 0DAD63B03FF for ; Thu, 15 Jun 2006 12:56:13 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23665-06 for ; Thu, 15 Jun 2006 12:56:06 -0400 (EDT) Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) by menubar.gnome.org (Postfix) with ESMTP id 688823B0613 for ; Thu, 15 Jun 2006 12:56:05 -0400 (EDT) Received: (qmail 25104 invoked from network); 15 Jun 2006 16:54:53 -0000 Received: from localhost (HELO 164-99-120-38.boston.ximian.com) (127.0.0.1) by localhost with SMTP; 15 Jun 2006 16:54:53 -0000 Subject: Re: GTK+ 2.10, the endgame From: Federico Mena Quintero To: Matthias Clasen In-Reply-To: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> References: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> Content-Type: text/plain Date: Thu, 15 Jun 2006 11:50:29 -0500 Message-Id: <1150390229.17566.191.camel@cacharro.xalalinux.org> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.575 tagged_above=-999 required=2 tests=[AWL=0.024, BAYES_00=-2.599] X-Spam-Score: -2.575 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 16:56:13 -0000 On Thu, 2006-06-15 at 09:56 -0400, Matthias Clasen wrote: > Therefore, I want to consider 2.9.3 api frozen, and take a > look at what still needs to happen before 2.10. Here are some > things I personally would like get worked on (not sure > how much time I can free to look into these myself): > > - I think the async filechooser conversion has caused some > regressions, I noticed that .hidden support seems broken > and autocompletion also behaved badly for me recently. Yes, it's quite broken at the moment. I don't think we can do any more productive debugging (fixing something breaks something else) until we have a good set of automated tests for the basic behaviors. > - There is a number of FIXMEs and unimplemented bits in > the print code. > > - The print backends need a careful look wrt to memory leaks > and error reporting. I'm rather worried of declaring the printing API as stable and just unleashing it to the world. Is any software *really* using it? Does it contemplate things like - sites with thousands of printers - sites which want to lock-down certain printers - color management for apps that need it > Another thing I have slacked off about is organizing a GTK+ > team meeting at GUADEC. So, who of the GTK+ team is there > and at what times ? Should we try to find a free hour during > the core days, or does everybody stay for the after hours ? > If so, it may be easier to do a team meeting on Thursday... I'll be there since Sunday morning. Thursday is the Advisory Board meeting, so I'm afraid I won't have that day free for the GTK+ meeeting. Federico From mclasen@redhat.com Thu Jun 15 13:15:33 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id BC2163B0187 for ; Thu, 15 Jun 2006 13:15:33 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24531-03 for ; Thu, 15 Jun 2006 13:15:29 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id DCC933B0227 for ; Thu, 15 Jun 2006 13:15:28 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5FHDjVa014384; Thu, 15 Jun 2006 13:13:45 -0400 Received: from lacrosse.corp.redhat.com (lacrosse.corp.redhat.com [172.16.52.154]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5FHDjmo017834; Thu, 15 Jun 2006 13:13:45 -0400 Received: from [172.16.83.98] (dhcp83-98.boston.redhat.com [172.16.83.98]) by lacrosse.corp.redhat.com (8.12.11.20060308/8.11.6) with ESMTP id k5FHDjGC025752; Thu, 15 Jun 2006 13:13:45 -0400 Subject: Re: GTK+ 2.10, the endgame From: Matthias Clasen To: Federico Mena Quintero In-Reply-To: <1150390229.17566.191.camel@cacharro.xalalinux.org> References: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> <1150390229.17566.191.camel@cacharro.xalalinux.org> Content-Type: text/plain Organization: Red Hat Date: Thu, 15 Jun 2006 13:15:37 -0400 Message-Id: <1150391737.3187.33.camel@dhcp83-98.boston.redhat.com> Mime-Version: 1.0 X-Mailer: Evolution 2.7.3 (2.7.3-2) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.542 tagged_above=-999 required=2 tests=[AWL=0.059, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.542 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 17:15:33 -0000 On Thu, 2006-06-15 at 11:50 -0500, Federico Mena Quintero wrote: > On Thu, 2006-06-15 at 09:56 -0400, Matthias Clasen wrote: > > > Therefore, I want to consider 2.9.3 api frozen, and take a > > look at what still needs to happen before 2.10. Here are some > > things I personally would like get worked on (not sure > > how much time I can free to look into these myself): > > > > - I think the async filechooser conversion has caused some > > regressions, I noticed that .hidden support seems broken > > and autocompletion also behaved badly for me recently. > > Yes, it's quite broken at the moment. I don't think we can do any more > productive debugging (fixing something breaks something else) until we > have a good set of automated tests for the basic behaviors. Quite unfortunate. We spent too much time working on finetuning the filechooser behaviour to leave it broken now... > > - There is a number of FIXMEs and unimplemented bits in > > the print code. > > > > - The print backends need a careful look wrt to memory leaks > > and error reporting. > > I'm rather worried of declaring the printing API as stable and just > unleashing it to the world. Is any software *really* using it? Does it > contemplate things like Typical chicken and egg problem that won't be solved by keeping it unreleased for another year. There is no way to get any software _really_ using it without releasing it first. We got quite a bit of feedback from people looking at porting real apps to it (e.g gedit, OOo and epiphany), so it is not as if we release it straight from the whiteboard. > - sites with thousands of printers > > - sites which want to lock-down certain printers > > - color management for apps that need it No doubt that we may have to add new api in 2.12 to accomodate things like this, but all of these are special cases. From muntyan@tamu.edu Thu Jun 15 15:05:44 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 9364F3B0605 for ; Thu, 15 Jun 2006 15:05:44 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28754-04 for ; Thu, 15 Jun 2006 15:05:41 -0400 (EDT) Received: from smtp103.vzn.mail.mud.yahoo.com (smtp103.vzn.mail.mud.yahoo.com [68.142.203.47]) by menubar.gnome.org (Postfix) with SMTP id 568873B05C3 for ; Thu, 15 Jun 2006 15:05:40 -0400 (EDT) Received: (qmail 34334 invoked from network); 15 Jun 2006 19:05:00 -0000 Received: from unknown (HELO ?192.168.3.9?) (muntyan@verizon.net@71.113.224.59 with plain) by smtp103.vzn.mail.mud.yahoo.com with SMTP; 15 Jun 2006 19:04:59 -0000 Message-ID: <4491AF5A.2050702@tamu.edu> Date: Thu, 15 Jun 2006 14:04:58 -0500 From: Yevgen Muntyan User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20060216 Debian/1.7.12-1.1ubuntu2 X-Accept-Language: en MIME-Version: 1.0 To: GTK Devel List Subject: Printing and blocking ui Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.552 tagged_above=-999 required=2 tests=[AWL=0.047, BAYES_00=-2.599] X-Spam-Score: -2.552 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 19:05:44 -0000 Hi there, I print a text document from GtkTextView here. There is a problem with pagination: pagination is potentially slow, so some sort of progress dialog should be shown during it. From the other hand, the text buffer must not be modified during pagination. How to solve it? Should I show my own modal dialog and make sure user doesn't modify the buffer, or GtkPrintOperation can take care of it? Actually, it would be good to ensure printing blocks the text widget too, since in this case it wouldn't be necessary to calculate and store all the pango layouts in begin-print. Maybe just show a modal dialog between begin-print and end-print. Thanks, Yevgen From richard@imendio.com Thu Jun 15 15:08:15 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C90B13B02BF for ; Thu, 15 Jun 2006 15:08:15 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28754-07 for ; Thu, 15 Jun 2006 15:08:14 -0400 (EDT) Received: from holken.mikan.net (holken.mikan.net [83.145.56.183]) by menubar.gnome.org (Postfix) with ESMTP id 47EFB3B018C for ; Thu, 15 Jun 2006 15:08:14 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by holken.mikan.net (Postfix) with ESMTP id 418C111EB4; Thu, 15 Jun 2006 21:07:02 +0200 (CEST) Received: from holken.mikan.net ([127.0.0.1]) by localhost (holken.mikan.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04160-07; Thu, 15 Jun 2006 21:06:58 +0200 (CEST) Received: from [192.168.100.5] (c83-248-134-21.bredband.comhem.se [83.248.134.21]) by holken.mikan.net (Postfix) with ESMTP id E679E1459D; Thu, 15 Jun 2006 21:06:57 +0200 (CEST) Message-ID: <4491AFD0.5000408@imendio.com> Date: Thu, 15 Jun 2006 21:06:56 +0200 From: Richard Hult Organization: Imendio AB User-Agent: Thunderbird 1.5.0.4 (Macintosh/20060530) MIME-Version: 1.0 To: Hubert Figuiere Subject: Re: GTK+ 2.10, the endgame References: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> <44918201.6010605@teaser.fr> In-Reply-To: <44918201.6010605@teaser.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at holken.mikan.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.543 tagged_above=-999 required=2 tests=[AWL=0.056, BAYES_00=-2.599] X-Spam-Score: -2.543 X-Spam-Level: Cc: gtk-devel-list@gnome.org, Matthias Clasen X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 19:08:16 -0000 Hubert Figuiere skrev: > Matthias Clasen wrote: >> I want to have GTK+ 2.10 ready at or immediately after GUADEC. > > Can somebody summarize the Mac port status? The basic functionality is implemented and what's next in the pipeline is bug fixing, and after that looking into tighter integration with the platform in various areas. /Richard From muntyan@tamu.edu Thu Jun 15 15:12:58 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 9FC7E3B063D for ; Thu, 15 Jun 2006 15:12:58 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29079-06 for ; Thu, 15 Jun 2006 15:12:57 -0400 (EDT) Received: from smtp101.vzn.mail.mud.yahoo.com (smtp101.vzn.mail.mud.yahoo.com [68.142.203.45]) by menubar.gnome.org (Postfix) with SMTP id E72693B0613 for ; Thu, 15 Jun 2006 15:12:56 -0400 (EDT) Received: (qmail 97288 invoked from network); 15 Jun 2006 19:11:44 -0000 Received: from unknown (HELO ?192.168.3.9?) (muntyan@verizon.net@71.113.224.59 with plain) by smtp101.vzn.mail.mud.yahoo.com with SMTP; 15 Jun 2006 19:11:43 -0000 Message-ID: <4491B0EE.3040900@tamu.edu> Date: Thu, 15 Jun 2006 14:11:42 -0500 From: Yevgen Muntyan User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20060216 Debian/1.7.12-1.1ubuntu2 X-Accept-Language: en MIME-Version: 1.0 To: gtk-devel-list@gnome.org Subject: Re: GTK+ 2.10, the endgame References: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> <1150390229.17566.191.camel@cacharro.xalalinux.org> In-Reply-To: <1150390229.17566.191.camel@cacharro.xalalinux.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.514 tagged_above=-999 required=2 tests=[AWL=0.008, BAYES_00=-2.599, TW_GT=0.077] X-Spam-Score: -2.514 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 19:12:58 -0000 Federico Mena Quintero wrote: >On Thu, 2006-06-15 at 09:56 -0400, Matthias Clasen wrote: > > >>- The print backends need a careful look wrt to memory leaks >> and error reporting. >> >> > >I'm rather worried of declaring the printing API as stable and just >unleashing it to the world. Is any software *really* using it? > > Yes, there is software which is going to use gtk printing as soon as gtk-2.10 is released. And there will be much more when gtk has printing. Just think for a moment about gtk-but-not-gnome applications (win32 comes to mind too). > - sites with thousands of printers > > - sites which want to lock-down certain printers > > - color management for apps that need it > > If gtk can print to a single user's printer, it's already worth releasing. Again, there are applications which do not have printing, because they can't use gnomeprint, and developers don't feel like implement their own printing while gtk is going to get it. IMHO, etc., you know. Best regards, Yevgen From gnome-gtk-devel-list@m.gmane.org Thu Jun 15 16:40:15 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 2360D3B00D0 for ; Thu, 15 Jun 2006 16:40:15 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32360-05 for ; Thu, 15 Jun 2006 16:40:13 -0400 (EDT) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by menubar.gnome.org (Postfix) with ESMTP id 3B9113B0237 for ; Thu, 15 Jun 2006 16:40:13 -0400 (EDT) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1FqydG-0004Vk-6i for gtk-devel-list@gnome.org; Thu, 15 Jun 2006 22:40:02 +0200 Received: from cpe0004e2d9f884-cm0013718690da.cpe.net.cable.rogers.com ([70.24.212.140]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 15 Jun 2006 22:40:02 +0200 Received: from jasonspiro4+news by cpe0004e2d9f884-cm0013718690da.cpe.net.cable.rogers.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 15 Jun 2006 22:40:02 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gtk-devel-list@gnome.org From: Jason Spiro Subject: Imagine: what if points in Bugzilla had a significant effect? Date: Thu, 15 Jun 2006 19:15:34 +0000 (UTC) Lines: 15 Message-ID: X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cpe0004e2d9f884-cm0013718690da.cpe.net.cable.rogers.com User-Agent: slrn/0.9.8.1pl1 (Debian) Sender: news X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.601 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.601 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 20:40:15 -0000 Imagine: what if points did something in Bugzilla, like, the more points you have, the more votes you get? I think this would encourage people to file more bug reports, both good bug reports and not-so-good ones. Would that be a net gain or a net loss for GTK+? Regards, Jason Spiro -- Jason Spiro: computer consulting with a smile. Specializing in Linux: Red Hat AS / ES, Debian, and others. Serving homes and companies globally via remote access tools. Fair rates. Just email jasonspiro4@gmail.com or call Skype ID jasonspiro. From murrayc@murrayc.com Fri Jun 16 04:53:13 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id D68413B0007 for ; Fri, 16 Jun 2006 04:53:12 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23115-03 for ; Fri, 16 Jun 2006 04:53:08 -0400 (EDT) Received: from swarthymail-a5.dreamhost.com (sd-green-bigip-176.dreamhost.com [208.97.132.176]) by menubar.gnome.org (Postfix) with ESMTP id 7FA303B006C for ; Fri, 16 Jun 2006 04:53:08 -0400 (EDT) Received: from noname (p5497E1BF.dip.t-dialin.net [84.151.225.191]) by swarthymail-a5.dreamhost.com (Postfix) with ESMTP id 69FE4109E8B; Fri, 16 Jun 2006 01:52:14 -0700 (PDT) Subject: Re: GTK+ 2.10, the endgame From: Murray Cumming To: Matthias Clasen In-Reply-To: <1150391737.3187.33.camel@dhcp83-98.boston.redhat.com> References: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> <1150390229.17566.191.camel@cacharro.xalalinux.org> <1150391737.3187.33.camel@dhcp83-98.boston.redhat.com> Content-Type: text/plain Date: Fri, 16 Jun 2006 10:52:10 +0200 Message-Id: <1150447930.5806.4.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.481 tagged_above=-999 required=2 tests=[AWL=0.118, BAYES_00=-2.599] X-Spam-Score: -2.481 X-Spam-Level: Cc: Federico Mena Quintero , gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2006 08:53:13 -0000 I'm also concerned about the recent files stuff. Do we now have UIManager integration of that? -- Murray Cumming murrayc@murrayc.com www.murrayc.com www.openismus.com From murrayc@murrayc.com Fri Jun 16 05:06:58 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id A76AC3B0076 for ; Fri, 16 Jun 2006 05:06:58 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23550-01 for ; Fri, 16 Jun 2006 05:06:57 -0400 (EDT) Received: from kungfu.dreamhost.com (kungfu.dreamhost.com [66.33.216.126]) by menubar.gnome.org (Postfix) with ESMTP id D099D3B006B for ; Fri, 16 Jun 2006 05:06:57 -0400 (EDT) Received: from swarthymail-a4.dreamhost.com (sd-green-bigip-62.dreamhost.com [208.97.132.62]) by kungfu.dreamhost.com (Postfix) with ESMTP id 708B51F0265 for ; Fri, 16 Jun 2006 01:28:47 -0700 (PDT) Received: from noname (p5497E1BF.dip.t-dialin.net [84.151.225.191]) by swarthymail-a4.dreamhost.com (Postfix) with ESMTP id 0D51A129A83; Fri, 16 Jun 2006 01:28:10 -0700 (PDT) Subject: Re: GTK+ 2.10, the endgame From: Murray Cumming To: Matthias Clasen In-Reply-To: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> References: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> Content-Type: text/plain Date: Thu, 15 Jun 2006 23:20:27 +0200 Message-Id: <1150406427.30234.1.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.068 tagged_above=-999 required=2 tests=[AWL=-0.296, BAYES_00=-2.599, DATE_IN_PAST_06_12=0.827] X-Spam-Score: -2.068 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2006 09:06:58 -0000 On Thu, 2006-06-15 at 09:56 -0400, Matthias Clasen wrote: > I want to have GTK+ 2.10 ready at or immediately after GUADEC. [snip] I'd rather it was after rather than before. That gives us just a little more time to get everything wrapped quickly for gtkmm, which might show some small problems that need fixing. Maybe I haven't been paying attention, but I'm surprised (again) by the freeze announcement. -- Murray Cumming murrayc@murrayc.com www.murrayc.com www.openismus.com From mgiannakidis@gmail.com Thu Jun 15 11:24:35 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id B7BE73B0211 for ; Thu, 15 Jun 2006 11:24:35 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19150-09 for ; Thu, 15 Jun 2006 11:24:34 -0400 (EDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.188]) by menubar.gnome.org (Postfix) with ESMTP id AAD863B04FC for ; Thu, 15 Jun 2006 11:24:33 -0400 (EDT) Received: by nf-out-0910.google.com with SMTP id c2so90382nfe for ; Thu, 15 Jun 2006 08:23:41 -0700 (PDT) Received: by 10.48.47.15 with SMTP id u15mr674329nfu; Thu, 15 Jun 2006 08:23:39 -0700 (PDT) Received: from ?213.140.137.120? ( [213.140.137.120]) by mx.gmail.com with ESMTP id n22sm2029009nfc.2006.06.15.08.23.38; Thu, 15 Jun 2006 08:23:39 -0700 (PDT) From: Michalis Giannakidis To: gtk-devel-list@gnome.org Subject: gslice allocator: general impresions. Date: Thu, 15 Jun 2006 18:27:45 +0300 User-Agent: KMail/1.8.3 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200606151827.45477.mgiannakidis@gmail.com> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.6 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.6 X-Spam-Level: X-Mailman-Approved-At: Fri, 16 Jun 2006 05:29:57 -0400 X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 15:24:35 -0000 Dear Glib team, I have recently used the glib-glice allocator in a very malloc intensive application, and I would like to share a few observations I made, with you. The typical size I send to g_slice_alloc is 20 and 76 bytes (32 bit build). The total memory consumed by my application has decreased - which is great! However it `seems' to me, that this decrease in size is larger for the 64bit build compared to the 32bit build. (I have modified gslice to align a chunk to its own size so that I don't have unused memory between chunks eg: request 20 and get 24...) In my application now I use both g_slice_alloc and malloc.Testing the new allocator in linux I came accross the following: After using g_slice_alloc to alloc a great amount of data (eg 1500mb), each of them being 20 or 76 bytes in size, subsequent calls to malloc(8*1024) or similar sizes take much longer (the allocation does _not_ got to the swap). Also if I chage the min_page_size from 128 to 4096, then the subsequent calls to malloc(8*1024) or similar sizes take even longer. It takes for ever in the 64 bit build! Moreover, even with min_page_size set to 128, the calls to malloc take for ever on a Linux 2.4.20 glibc-2.2.4(glibc up to 2.2.5 has a broken posix_memalign so I fallback to memalign). In all of the cases above, malloc responds much faster when the gslice allocator is turned off. I know I should be providing sample code and test programms here to back up my observations. I also understand that I should provide execution times instead of just stating that the calls to malloc take for ever. I would like to ask you, if there are any known issues in mixing gslice and malloc calls in malloc intensive applications. Any suggested readings would be most welcome. Regards Michalis -- Michalis Giannakidis From timj@gtk.org Fri Jun 16 07:30:05 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id EEDE23B0011 for ; Fri, 16 Jun 2006 07:30:04 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26976-06 for ; Fri, 16 Jun 2006 07:30:04 -0400 (EDT) Received: from holken.mikan.net (holken.mikan.net [83.145.56.183]) by menubar.gnome.org (Postfix) with ESMTP id DA78D3B0007 for ; Fri, 16 Jun 2006 07:30:03 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by holken.mikan.net (Postfix) with ESMTP id BDFA43352B0; Fri, 16 Jun 2006 13:28:54 +0200 (CEST) Received: from holken.mikan.net ([127.0.0.1]) by localhost (holken.mikan.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29662-08; Fri, 16 Jun 2006 13:28:48 +0200 (CEST) Received: from birnet.org (d003098.adsl.hansenet.de [80.171.3.98]) by holken.mikan.net (Postfix) with ESMTP id DFB2633525A; Fri, 16 Jun 2006 13:28:47 +0200 (CEST) Received: from master.birnet.private (localhost.localdomain [127.0.0.1]) by birnet.org (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k5GBSi9S008066 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 16 Jun 2006 13:28:44 +0200 Received: (from timj@localhost) by master.birnet.private (8.13.4/8.13.4/Submit) id k5GBSZMj008064; Fri, 16 Jun 2006 13:28:35 +0200 Date: Fri, 16 Jun 2006 13:28:35 +0200 (CEST) From: Tim Janik X-X-Sender: timj@master.birnet.private To: "Gustavo J. A. M. Carneiro" Subject: Re: GObject extension propose (GContainer) In-Reply-To: <1150456522.5305.12.camel@localhost.localdomain> Message-ID: References: <200606151101.12868.ntd@users.sourceforge.net> <44919246.8060301@gnome.org> <1150456522.5305.12.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="656239-2144330416-1150457315=:7955" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at holken.mikan.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.677 tagged_above=-999 required=2 tests=[AWL=-0.669, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, RCVD_IN_SORBS_WEB=1.456] X-Spam-Score: -1.677 X-Spam-Level: Cc: Gtk+ Developers X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2006 11:30:05 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --656239-2144330416-1150457315=:7955 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Fri, 16 Jun 2006, Gustavo J. A. M. Carneiro wrote: > Qui, 2006-06-15 =E0s 13:00 -0400, Tristan Van Berkom escreveu: >> All of that just to say... I cannot count the times I've thought to >> myself that >> GtkContainer should really just be GContainerIface, and implemented by >> whatever interested objects that want to parent other objects... > > That's interesting, but I wonder what is the runtime penalty of > interface lookup compared to normal class structure lookup? Is it > really OK to use an interface for this, or is it better just to add a > new virtual methods to the GObject class? the lookup penalties are negligible. type node/class lookups and is_a checks are O(1); interface class lookups and conforms_to checks are O(ld(N)), where N is the number of interfaces a type node conforms to. > Gustavo J. A. M. Carneiro --- ciaoTJ --656239-2144330416-1150457315=:7955-- From gjc@inescporto.pt Fri Jun 16 07:34:21 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 74BCC3B000B for ; Fri, 16 Jun 2006 07:34:21 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26977-07 for ; Fri, 16 Jun 2006 07:34:20 -0400 (EDT) Received: from animal.inescn.pt (correio.inescn.pt [194.117.24.9]) by menubar.gnome.org (Postfix) with ESMTP id 5B7183B0011 for ; Fri, 16 Jun 2006 07:34:19 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by animal.inescn.pt (8.13.6/8.13.6/7) with ESMTP id k5GBFdIJ028014; Fri, 16 Jun 2006 12:15:39 +0100 (WEST) Received: from pong.inescporto.pt (pong.inescn.pt [194.117.26.74]) by animal.inescn.pt (8.13.6/8.13.6/5) with ESMTP id k5GBFT0a027999; Fri, 16 Jun 2006 12:15:29 +0100 (WEST) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by pong.inescporto.pt (Postfix) with ESMTP id AE13A39D8; Fri, 16 Jun 2006 12:12:16 +0100 (WEST) Subject: Re: GObject extension propose (GContainer) From: "Gustavo J. A. M. Carneiro" To: Tristan Van Berkom In-Reply-To: <44919246.8060301@gnome.org> References: <200606151101.12868.ntd@users.sourceforge.net> <44919246.8060301@gnome.org> Content-Type: text/plain; charset=UTF-8 Date: Fri, 16 Jun 2006 12:15:21 +0100 Message-Id: <1150456522.5305.12.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at inescporto.pt X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.39 tagged_above=-999 required=2 tests=[AWL=-0.002, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, SPF_PASS=-0.001, TW_GT=0.077] X-Spam-Score: -2.39 X-Spam-Level: Cc: Gtk+ Developers , Tim Janik X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2006 11:34:21 -0000 Qui, 2006-06-15 s 13:00 -0400, Tristan Van Berkom escreveu: > Tim Janik wrote: > > >On Thu, 15 Jun 2006, Fontana Nicola wrote: > > > > > > > >>Hi all, > >> > >>I'm a GObject based libraries (for UI purpose and not) user and I often need > >>a generic container to derive my own types. In my opinion, I think this > >>generic container must be included inside the GObject library ... it could > >>be used by a lot of derived libraries providing a common approach. > >> > >>I published my solution - that is, what I am currently using - on > >>sourceforge. > >> > >>http://sourceforge.net/projects/gcontainer/ > >> > >>Is it a good idea? Is something planned in this direction? Am I totally > >>wrong? > >> > >>I need feedbacks ... > >> > >> > As a side note... I've been working on container --> child relationships and > honing them down inside the glade builder... objects may for example have > object delagates that are "owned" and in turn may "own" other delagates... > this is all functional with libglade facilities and the future gtk > builder also > (from the design as of yet...)... this concept of "types of container > relationships" > is also usefull for GtkMenuShell --> GtkMenu for example (not just any > GtkWidget > can be added to a menushell). > > All of that just to say... I cannot count the times I've thought to > myself that > GtkContainer should really just be GContainerIface, and implemented by > whatever interested objects that want to parent other objects... That's interesting, but I wonder what is the runtime penalty of interface lookup compared to normal class structure lookup? Is it really OK to use an interface for this, or is it better just to add a new virtual methods to the GObject class? > I think > that what we need is not really "yet another container api", but a container > api that is a unified front for generic handling of the GTK object > hierarchy at runtime. Actually, for the python language bindings we could use a generic GObject container interface. See http://bugzilla.gnome.org/show_bug.cgi?id=303266 Regards. -- Gustavo J. A. M. Carneiro The universe is always one step beyond logic From alan@clueserver.org Fri Jun 16 12:57:14 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 502C63B0336 for ; Fri, 16 Jun 2006 12:57:14 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06317-07 for ; Fri, 16 Jun 2006 12:57:08 -0400 (EDT) Received: from clueserver.org (216-99-213-120.dsl.aracnet.com [216.99.213.120]) by menubar.gnome.org (Postfix) with ESMTP id 7529F3B041B for ; Fri, 16 Jun 2006 12:54:18 -0400 (EDT) Received: by clueserver.org (Postfix, from userid 500) id 2985BF50BE2; Fri, 16 Jun 2006 09:53:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by clueserver.org (Postfix) with ESMTP id 26461F50BE1; Fri, 16 Jun 2006 09:53:44 -0700 (PDT) Date: Fri, 16 Jun 2006 09:53:44 -0700 (PDT) From: alan X-X-Sender: alan@blackbox.fnordora.org To: Jason Spiro Subject: Re: Imagine: what if points in Bugzilla had a significant effect? In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.45 tagged_above=-999 required=2 tests=[AWL=0.014, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.45 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2006 16:57:14 -0000 On Thu, 15 Jun 2006, Jason Spiro wrote: > Imagine: what if points did something in Bugzilla, like, the more points > you have, the more votes you get? Slashzilla? -- "Waiter! This lambchop tastes like an old sock!" - Sheri Lewis From ntd@users.sourceforge.net Fri Jun 16 14:08:36 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 39BE13B03E1 for ; Fri, 16 Jun 2006 14:08:36 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11017-04 for ; Fri, 16 Jun 2006 14:08:34 -0400 (EDT) Received: from mailout02.albacom.net (mailout02.albacom.net [217.220.34.14]) by menubar.gnome.org (Postfix) with SMTP id E2E913B00E4 for ; Fri, 16 Jun 2006 14:08:33 -0400 (EDT) Received: (qmail 21669 invoked by uid 507); 16 Jun 2006 18:08:08 -0000 Received: from ntd@users.sourceforge.net by mailout02.albacom.net with qmail-scanner (spamassassin: ???. Clear:RC:1(217.221.76.9):SA:0(0.0/15.0):. Processed in 0.841774 secs); 16 Jun 2006 18:08:08 -0000 Received: from unknown (HELO sviluppo.internet.local) (postmaster@effe-gi.it@217.221.76.9) by mailout02.albacom.net with SMTP; 16 Jun 2006 18:08:07 -0000 From: Fontana Nicola Organization: Elettronica EFFE-GI s.n.c. To: Tim Janik Subject: Re: GObject extension propose (GContainer) Date: Fri, 16 Jun 2006 20:44:11 +0000 User-Agent: KMail/1.9.1 References: <200606151101.12868.ntd@users.sourceforge.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200606162044.11716.ntd@users.sourceforge.net> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.526 tagged_above=-999 required=2 tests=[AWL=-0.004, BAYES_00=-2.599, TW_GT=0.077] X-Spam-Score: -2.526 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2006 18:08:36 -0000 > On Thu, 15 Jun 2006, Fontana Nicola wrote: > > Hi all, > > > > I'm a GObject based libraries (for UI purpose and not) user and I often > > need a generic container to derive my own types. In my opinion, I think > > this generic container must be included inside the GObject library ... it > > could be used by a lot of derived libraries providing a common approach. > > > > I published my solution - that is, what I am currently using - on > > sourceforge. > > > > http://sourceforge.net/projects/gcontainer/ > > > > Is it a good idea? Is something planned in this direction? Am I totally > > wrong? > > > > I need feedbacks ... > > hi. your gcontainer-1.0.0 looks like an interesting approach to me, but > i'm not sure it's generally good to put that into stock libgobject. > the main reason is that container needs are probably pretty variable > out there (i've come across at least 4 different gobject container > implementations in free software projects i'm woorking on) and that > both, making too little assumptions in the child/container interface > isn't going to be very helpful, albeit making too many has the > same problem. Some time ago I've started a communication library based on libgobject and I feeled the need of two things: a base object with floating reference and a container. After some time, I started an experimental cairo canvas and I had the same needs. In both cases, no gtk dependency was requested. Briefly, I'm not talking about a container that cover all needs and tastes but instead about "moving the GtkContainer logic and complexity" from gtk to gobject, something similar to what was done for GtkObject and its floating reference. I wrote gcontainer with this in mind (the GContainerable interface is "compatible" with GtkContainer and GChildable with GtkWidget). Anyway, my solution presents some serious problems: I'm misusing the interface to hide as much technical details as possible to the implementing objects. I know it is a huge task but consider this as an idea or a looooong term project: I don't think to be the only one with these needs. > > i guess we could add a link to your project from the libgobject docs > (it should probably have a Contrib section), for people possibly looking > for a GObject container implementation. that way, gcontainer-1.0.0 gets > a chance of being reused and maybe extended to something generally > usefull for GObject applications out there. > > > Nicola > > --- > ciaoTJ Of course I'll be glad to have a link in the gobject documentation. Thank you for your availability. Nicola From tristan.van.berkom@gmail.com Fri Jun 16 14:26:50 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id E38F43B0139 for ; Fri, 16 Jun 2006 14:26:49 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12245-08 for ; Fri, 16 Jun 2006 14:26:49 -0400 (EDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.197]) by menubar.gnome.org (Postfix) with ESMTP id DB55F3B0179 for ; Fri, 16 Jun 2006 14:26:48 -0400 (EDT) Received: by wx-out-0102.google.com with SMTP id i30so517779wxd for ; Fri, 16 Jun 2006 11:26:15 -0700 (PDT) Received: by 10.70.83.9 with SMTP id g9mr4369121wxb; Fri, 16 Jun 2006 11:20:03 -0700 (PDT) Received: from ?66.48.170.68? ( [66.48.170.68]) by mx.gmail.com with ESMTP id h39sm2692858wxd.2006.06.16.11.20.01; Fri, 16 Jun 2006 11:20:03 -0700 (PDT) Message-ID: <4492FA3C.5060106@gmail.com> Date: Fri, 16 Jun 2006 14:36:44 -0400 From: Tristan Van Berkom User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Fontana Nicola Subject: Re: GObject extension propose (GContainer) References: <200606151101.12868.ntd@users.sourceforge.net> <200606162044.11716.ntd@users.sourceforge.net> In-Reply-To: <200606162044.11716.ntd@users.sourceforge.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.497 tagged_above=-999 required=2 tests=[AWL=-0.353, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=1.456, SPF_PASS=-0.001] X-Spam-Score: -1.497 X-Spam-Level: Cc: gtk-devel-list@gnome.org, Tim Janik X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2006 18:26:50 -0000 Fontana Nicola wrote: [...] >I wrote gcontainer with this in mind (the GContainerable interface is >"compatible" with GtkContainer and GChildable with GtkWidget). Anyway, my >solution presents some serious problems: I'm misusing the interface to hide >as much technical details as possible to the implementing objects. > >I know it is a huge task but consider this as an idea or a looooong term >project: I don't think to be the only one with these needs. > > I think you may be overcomplicating things, if for example; the GContainerable or GContainerIface were implemented by GtkContainer; then nothing in GtkContainer derivatives would really have to change (unless the api was drasticly different... but I doubt that). Then this could be extended to other object sets and other needs without having to rewrite large pieces of code. Cheers, -Tristan From behdad.esfahbod@gmail.com Fri Jun 16 15:04:20 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 611EA3B00F8 for ; Fri, 16 Jun 2006 15:04:20 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15384-03 for ; Fri, 16 Jun 2006 15:04:18 -0400 (EDT) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.228]) by menubar.gnome.org (Postfix) with ESMTP id 566D33B007C for ; Fri, 16 Jun 2006 15:04:18 -0400 (EDT) Received: by wr-out-0506.google.com with SMTP id i4so618991wra for ; Fri, 16 Jun 2006 12:03:42 -0700 (PDT) Received: by 10.54.142.9 with SMTP id p9mr3126451wrd; Fri, 16 Jun 2006 11:57:25 -0700 (PDT) Received: from ?192.168.190.5? ( [72.136.156.47]) by mx.gmail.com with ESMTP id 10sm2200187wrl.2006.06.16.11.57.23; Fri, 16 Jun 2006 11:57:24 -0700 (PDT) Subject: Re: Imagine: what if points in Bugzilla had a significant effect? From: Behdad Esfahbod To: gtk-devel-list@gnome.org In-Reply-To: References: Content-Type: text/plain Date: Fri, 16 Jun 2006 14:57:22 -0400 Message-Id: <1150484242.15469.17.camel@home> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 (2.6.1-1.fc5.2) Content-Transfer-Encoding: 7bit Sender: Behdad Esfahbod X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.561 tagged_above=-999 required=2 tests=[AWL=-0.038, BAYES_00=-2.599, SPF_PASS=-0.001, TW_GT=0.077] X-Spam-Score: -2.561 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2006 19:04:20 -0000 On Thu, 2006-06-15 at 15:15 -0400, Jason Spiro wrote: > Imagine: what if points did something in Bugzilla, like, the more points > you have, the more votes you get? > > I think this would encourage people to file more bug reports, both good > bug reports and not-so-good ones. Would that be a net gain or a net loss > for GTK+? It has evolved to be like that already. The more points one has, the more he (or she, in the near future) respects bugs/comments from high-point others. Or at least that's been my experience. behdad > Regards, > Jason Spiro > > -- > Jason Spiro: computer consulting with a smile. > Specializing in Linux: Red Hat AS / ES, Debian, and others. > Serving homes and companies globally via remote access tools. Fair rates. > Just email jasonspiro4@gmail.com or call Skype ID jasonspiro. > > _______________________________________________ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-devel-list -- behdad http://behdad.org/ "Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill" -- Dan Bern, "New American Language" From grakic@devbase.net Fri Jun 16 16:12:39 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 7B9EC3B025A for ; Fri, 16 Jun 2006 16:12:39 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19416-03 for ; Fri, 16 Jun 2006 16:12:38 -0400 (EDT) Received: from mxout-04.mxes.net (mxout-04.mxes.net [205.237.194.35]) by menubar.gnome.org (Postfix) with ESMTP id 07A823B02B4 for ; Fri, 16 Jun 2006 16:12:37 -0400 (EDT) Received: from limun.local (unknown [87.116.163.93]) by smtp.mxes.net (Postfix) with ESMTP id C5307A3292; Fri, 16 Jun 2006 16:11:35 -0400 (EDT) Subject: Re: Imagine: what if points in Bugzilla had a significant effect? From: Goran Rakic To: Jason Spiro In-Reply-To: References: Content-Type: text/plain; charset=utf-8 Date: Fri, 16 Jun 2006 22:11:33 +0200 Message-Id: <1150488693.2273.3.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.6 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, SPF_HELO_PASS=-0.001] X-Spam-Score: -2.6 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2006 20:12:39 -0000 Lary Osterman has a nice writing on this topic titled "Measuring testers by test metrics doesn't." У čet, 15. 06 2006. у 19:15 +0000, Jason Spiro пише: > Imagine: what if points did something in Bugzilla, like, the more points > you have, the more votes you get? > > I think this would encourage people to file more bug reports, both good > bug reports and not-so-good ones. Would that be a net gain or a net loss > for GTK+? > > Regards, > Jason Spiro From ame1@extratech.com Fri Jun 16 17:02:33 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 2F9013B018C for ; Fri, 16 Jun 2006 17:02:33 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21327-05 for ; Fri, 16 Jun 2006 17:02:32 -0400 (EDT) Received: from portal2.extratech.com (portal.extratech.com [67.105.201.210]) by menubar.gnome.org (Postfix) with ESMTP id BB3BD3B01C8 for ; Fri, 16 Jun 2006 17:02:31 -0400 (EDT) Received: from zosma.extratech.com (zosma.extratech.com [192.168.0.41]) by portal2.extratech.com (8.12.11/8.12.11) with ESMTP id k5GL1Quq030485 for ; Fri, 16 Jun 2006 14:01:26 -0700 Subject: Re: GObject extension propose (GContainer) From: "Alan M. Evans" To: Gtk+ Developers In-Reply-To: References: <200606151101.12868.ntd@users.sourceforge.net> <44919246.8060301@gnome.org> <1150456522.5305.12.camel@localhost.localdomain> Content-Type: text/plain; charset=UTF-8 Message-Id: <1150491686.19405.355.camel@zosma.extratech.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 16 Jun 2006 14:01:26 -0700 Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV 0.86.1/1544/Fri Jun 16 02:19:15 2006 on portal2.extratech.com X-Virus-Status: Clean X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.556 tagged_above=-999 required=2 tests=[AWL=0.044, BAYES_00=-2.599] X-Spam-Score: -2.556 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2006 21:02:33 -0000 On Fri, 2006-06-16 at 04:28, Tim Janik wrote: > On Fri, 16 Jun 2006, Gustavo J. A. M. Carneiro wrote: > > > Qui, 2006-06-15 s 13:00 -0400, Tristan Van Berkom escreveu: > > >> All of that just to say... I cannot count the times I've thought to > >> myself that > >> GtkContainer should really just be GContainerIface, and implemented by > >> whatever interested objects that want to parent other objects... > > > > That's interesting, but I wonder what is the runtime penalty of > > interface lookup compared to normal class structure lookup? Is it > > really OK to use an interface for this, or is it better just to add a > > new virtual methods to the GObject class? > > the lookup penalties are negligible. > type node/class lookups and is_a checks are O(1); > interface class lookups and conforms_to checks are O(ld(N)), where > N is the number of interfaces a type node conforms to. Your assertion that the penalties are negligable is not really supported by your response, unless the constant is also known for both orders. From ebassi@gmail.com Fri Jun 16 20:14:03 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 3E95D3B069B for ; Fri, 16 Jun 2006 20:14:03 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28883-03 for ; Fri, 16 Jun 2006 20:14:00 -0400 (EDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.185]) by menubar.gnome.org (Postfix) with ESMTP id 969133B015A for ; Fri, 16 Jun 2006 20:13:59 -0400 (EDT) Received: by nf-out-0910.google.com with SMTP id c2so667512nfe for ; Fri, 16 Jun 2006 17:13:07 -0700 (PDT) Received: by 10.49.72.13 with SMTP id z13mr2277195nfk; Fri, 16 Jun 2006 17:05:51 -0700 (PDT) Received: from ?192.168.1.74? ( [86.136.65.180]) by mx.gmail.com with ESMTP id y23sm3836170nfb.2006.06.16.17.05.51; Fri, 16 Jun 2006 17:05:51 -0700 (PDT) Subject: Re: GTK+ 2.10, the endgame From: Emmanuele Bassi To: gtk-devel-list@gnome.org In-Reply-To: <1150447930.5806.4.camel@localhost.localdomain> References: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> <1150390229.17566.191.camel@cacharro.xalalinux.org> <1150391737.3187.33.camel@dhcp83-98.boston.redhat.com> <1150447930.5806.4.camel@localhost.localdomain> Content-Type: text/plain Date: Sat, 17 Jun 2006 01:05:50 +0100 Message-Id: <1150502750.2668.12.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.34 tagged_above=-999 required=2 tests=[AWL=0.260, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.34 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2006 00:14:03 -0000 Hi Murray, On Fri, 2006-06-16 at 10:52 +0200, Murray Cumming wrote: > I'm also concerned about the recent files stuff. Do we now have > UIManager integration of that? No, and I am to blame because I had less time to spend on fixing this issue. Mostly, I've been stuck on how to implement an action for both the menu and toolbars using the same tag. In the meantime, a nice and clean way to integrate the GtkRecentChooserMenu inside a GtkUIManager is to subclass GtkAction into a custom action that automatically adds a recent chooser menu to the menu item it creates, and use a placeholder in the UI definition (most applications using EggRecentViewUIManager already have that placeholder present). A working example is available here: http://www.gnome.org/~ebassi/test-uimanager.c The action code itself is one hundred lines long and can easily be hidden inside an helper file; it's approximately how GtkRecentAction would be implemented, anyway. I hereby give permission to do whatever you want to do with it. I understand that it's sub-optimal, and hopefully this should really go away once there's an action inside GTK. Ciao, Emmanuele. -- Emmanuele Bassi, E: ebassi@gmail.com W: http://www.emmanuelebassi.net B: http://log.emmanuelebassi.net From behdad.esfahbod@gmail.com Mon Jun 12 17:52:45 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 162C73B02CD for ; Mon, 12 Jun 2006 17:52:45 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00303-05 for ; Mon, 12 Jun 2006 17:52:43 -0400 (EDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.206]) by menubar.gnome.org (Postfix) with ESMTP id 643023B0010 for ; Mon, 12 Jun 2006 17:52:43 -0400 (EDT) Received: by wx-out-0102.google.com with SMTP id h26so956965wxd for ; Mon, 12 Jun 2006 14:51:27 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:subject:from:to:content-type:date:message-id:mime-version:x-mailer:sender; b=HkVpdki0/g3XkGcHUm613LiH99RNWp83QpOiB04twtI9/oyY5QJs7xgUW9ugXUYWTW0FQESua3SiFes9GpwcHFnulMB+jmu6Frg1gjSTz94Z0WNKazKYJCx/0yCrKVvi+sIhO9793kd+R7hBbKFWLBqlIyo5yetvED1gx6HIjnc= Received: by 10.70.36.1 with SMTP id j1mr6891335wxj; Mon, 12 Jun 2006 14:44:52 -0700 (PDT) Received: from to-dhcp26.toronto.redhat.com ( [63.250.163.171]) by mx.gmail.com with ESMTP id h18sm3879342wxd.2006.06.12.14.44.50; Mon, 12 Jun 2006 14:44:51 -0700 (PDT) Subject: Pango-1.13.2 released [unstable] From: Behdad Esfahbod To: Pango Release Lists , gtk-app-devel-list@gnome.org, gtk-devel-list@gnome.org, gtk-i18n-list@gnome.org, gtk-list@gnome.org Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-HZBsNn3KdPR3jVVwB9gO" Date: Mon, 12 Jun 2006 17:44:37 -0400 Message-Id: <1150148678.10765.8.camel@home> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 (2.6.1-1.fc5.2) Sender: Behdad Esfahbod X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.6 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.6 X-Spam-Level: X-Mailman-Approved-At: Fri, 16 Jun 2006 05:27:53 -0400 X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2006 21:52:45 -0000 --=-HZBsNn3KdPR3jVVwB9gO Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Pango-1.13.2 is now available for download at: ftp://ftp.gtk.org/pub/gtk/v2.11/ or http://download.gnome.org/sources/pango/1.13/ 28a6ea9d43c4cd398e7352032f775401 pango-1.13.2.tar.bz2 17d78473c05fece044c6a3b44519b61f pango-1.13.2.tar.gz This is a development release leading up to Pango-1.14.0, which will be released just in time for GNOME-2.16. Notes: * This is unstable development release. While it has had fairly extensive testing, there are likely bugs remaining to be found. This release should not be used in production. * Installing this version will overwrite your existing copy of Pango-1.12. If you have problems, you'll need to reinstall Pango-1.12.x * Bugs should be reported to http://bugzilla.gnome.org. About Pango =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Pango is a library for layout and rendering of text, with an emphasis on internationalization. Pango can be used anywhere that text layout is needed, though most of the work on Pango so far has been done in the context of the GTK+ widget toolkit. Pango forms the core of text and font handling for GTK+-2.x. Pango is designed to be modular; the core Pango layout engine can be used with different font backends. There are three basic backends, with multiple options for rendering with each. - Client side fonts using the FreeType and fontconfig libraries. Rendering can be with with Cairo or Xft libraries, or directly to an in-memory buffer with no additional libraries. - Native fonts on Microsoft Windows. (Optionally using Uniscribe for complex-text handling). Rendering can be done via Cairo or directly using the native Win32 API. - Native fonts on MacOS X, rendering via Cairo. The integration of Pango with Cairo (http://cairographics.org) provides a complete solution with high quality text handling and graphics rendering. Dynamically loaded modules then handle text layout for particular combinations of script and font backend. Pango ships with a wide selection of modules, including modules for Hebrew, Arabic, Hangul, Thai, and a number of Indic scripts. Virtually all of the world's major scripts are supported. As well as the low level layout rendering routines, Pango includes PangoLayout, a high level driver for laying out entire blocks of text, and routines to assist in editing internationalized text. More information about Pango is available from http://www.pango.org/. Pango 1.13.2 depends on version 2.10.0 or newer of the GLib library and version 1.1.2 or newer of the cairo library (if the cairo backend is desired); more information about GLib and cairo can be found at http://www.gtk.org/ and http://cairographics.org/ respectively. Overview of changes between 1.13.1 and 1.13.2 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D * Improved hexbox drawing, and font metrics calculations. * Synthesize italic variants on win32 [Hans Breuer] * New public API: - pango_cairo_show_error_underline - pango_cairo_error_underline_path - pango_font_describe_with_absolute_size * Misc fixes. * Bugs fixed in this release: Bug 326960 =E2=80=93 hex box drawing for win32 and atsui backends of cairo Bug 343717 =E2=80=93 License information in unclear. Bug 343355 =E2=80=93 Add pango_cairo_show_error_underline & pango_cairo_error_underline_path Bug 343966 =E2=80=93 pango Cygwin build fixes Patch from Cygwin Ports maintainer. Bug 343796 =E2=80=93 Italic Chinese character can't be show correctly in Win32. Bug 314114 =E2=80=93 max_x_advance not appropriate for approximate_(char|digit)_width Bug 341138 =E2=80=93 Using TTC font, Gtk2 programs begin to eating big mem= ory and have many cpu usage. Patch from Yong Li. Bug 336153 =E2=80=93 Mark to mark positioning (Lookup Type 6) isn't correc= t when using MarkAttchmentType Patch from Tin Myo Htet. Bug 333984 =E2=80=93 pango_language_from_string improvements Bug 125378 =E2=80=93 Better underline thickness handling Bug 339730 =E2=80=93 Pango needlessly falls back away from a Type 1 font i= nto a TTF font Bug 342562 =E2=80=93 Support absolute sizes in pango_font_description_to/from_string Bug 341922 =E2=80=93 pango should handle more characters as zero width Patch from Roozbeh Pournader Bug 342525 =E2=80=93 With PangoFc and PangoWin32, approximate digit width = is not what it says Bug 342079 =E2=80=93 pangoatsui-private.h missing from release Behdad Esfahbod 12 June 2006 --=-HZBsNn3KdPR3jVVwB9gO Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQBEjeBFn+4E5dNTERURApTwAJ9OvqbaG1xnQYzGPC9u0WPi30b6ggCfXNvZ oFfMwctzkAaKRETc/0aDRj0= =Wl7j -----END PGP SIGNATURE----- --=-HZBsNn3KdPR3jVVwB9gO-- From Klaus.Stengel@asamnet.de Tue Jun 13 06:57:05 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 1BD1E3B008F for ; Tue, 13 Jun 2006 06:57:05 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20572-03 for ; Tue, 13 Jun 2006 06:57:03 -0400 (EDT) Received: from mail.asamnet.de (mail.asamnet.de [194.25.81.18]) by menubar.gnome.org (Postfix) with ESMTP id A52473B000C for ; Tue, 13 Jun 2006 06:57:03 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.asamnet.de (Asamnet e.V. Mailserver) with ESMTP id D01E8A7076 for ; Tue, 13 Jun 2006 12:56:24 +0200 (CEST) Received: from mail.asamnet.de ([127.0.0.1]) by localhost (mail.asamnet.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00951-06 for ; Tue, 13 Jun 2006 12:56:24 +0200 (CEST) Received: from aquarian.nathanet.lan (p5492D6A6.dip.t-dialin.net [84.146.214.166]) by mail.asamnet.de (Asamnet e.V. Mailserver) with ESMTP id 6350FA7066 for ; Tue, 13 Jun 2006 12:56:24 +0200 (CEST) Subject: Pango memory leak in get_ruleset() in modules/basic/basic-fc.c From: Klaus Stengel To: gtk-devel-list@gnome.org Content-Type: text/plain Date: Tue, 13 Jun 2006 12:56:34 +0200 Message-Id: <1150196194.9594.16.camel@aquarian.nathanet.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at asamnet.de X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.464 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.464 X-Spam-Level: X-Mailman-Approved-At: Fri, 16 Jun 2006 05:27:53 -0400 X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2006 10:57:05 -0000 Hi, while working with the diagram editor "dia" I noticed a major memory leak when editing text objects. I tracked this down to a problem in the above function. From what I understand the function looks for an ruleset associated with the given font face and in case there is none, the ruleset is created with pango_ot_ruleset_new() and finally attached to the font face. The g_object_unref() is given as "notification callback" so that the ruleset is destroyed when the font face is finalized. In theory this should work, but unfortunately it doesn't in practice, because pango_ot_ruleset_new() internally references "info" itself, thus creating a circular dependency that keeps the objects alive indefinitely. Unfortunately I don't see an simple solution, except to drop that kind of caching again... Bye, Klaus. P.S.: Please reply to my email address as well, as I'm not subscribed to the list. From newren@gmail.com Sat Jun 17 01:54:29 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 7F2843B066E for ; Sat, 17 Jun 2006 01:54:29 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08609-05 for ; Sat, 17 Jun 2006 01:54:28 -0400 (EDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.198]) by menubar.gnome.org (Postfix) with ESMTP id 354E43B050E for ; Sat, 17 Jun 2006 01:54:28 -0400 (EDT) Received: by wx-out-0102.google.com with SMTP id h26so603851wxd for ; Fri, 16 Jun 2006 22:53:32 -0700 (PDT) Received: by 10.70.24.3 with SMTP id 3mr5192323wxx; Fri, 16 Jun 2006 22:53:32 -0700 (PDT) Received: by 10.70.102.9 with HTTP; Fri, 16 Jun 2006 22:53:32 -0700 (PDT) Message-ID: <51419b2c0606162253pfe0e7edsba8af3f8a1573477@mail.gmail.com> Date: Fri, 16 Jun 2006 23:53:32 -0600 From: "Elijah Newren" To: "Jason Spiro" Subject: Re: Imagine: what if points in Bugzilla had a significant effect? In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.572 tagged_above=-999 required=2 tests=[AWL=0.028, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.572 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2006 05:54:29 -0000 On 6/15/06, Jason Spiro wrote: > Imagine: what if points did something in Bugzilla, like, the more points > you have, the more votes you get? > > I think this would encourage people to file more bug reports, both good > bug reports and not-so-good ones. Would that be a net gain or a net loss > for GTK+? This isn't the right list for this email; bugzilla-devel or filed in bugzilla (against the bugzilla.gnome.org module) would be much better. Thanks, Elijah From timj@gtk.org Sat Jun 17 10:12:11 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id CD5003B00A6 for ; Sat, 17 Jun 2006 10:12:11 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23968-01 for ; Sat, 17 Jun 2006 10:12:08 -0400 (EDT) Received: from holken.mikan.net (holken.mikan.net [83.145.56.183]) by menubar.gnome.org (Postfix) with ESMTP id 34EA13B00D5 for ; Sat, 17 Jun 2006 10:12:07 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by holken.mikan.net (Postfix) with ESMTP id AC6413352A5; Sat, 17 Jun 2006 13:44:21 +0200 (CEST) Received: from holken.mikan.net ([127.0.0.1]) by localhost (holken.mikan.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07456-06; Sat, 17 Jun 2006 13:44:16 +0200 (CEST) Received: from birnet.org (d003096.adsl.hansenet.de [80.171.3.96]) by holken.mikan.net (Postfix) with ESMTP id 7CD8233524F; Sat, 17 Jun 2006 13:44:16 +0200 (CEST) Received: from master.birnet.private (localhost.localdomain [127.0.0.1]) by birnet.org (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k5HBiART015834 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 17 Jun 2006 13:44:11 +0200 Received: (from timj@localhost) by master.birnet.private (8.13.4/8.13.4/Submit) id k5HBhvjK015833; Sat, 17 Jun 2006 13:43:57 +0200 Date: Sat, 17 Jun 2006 13:43:57 +0200 (CEST) From: Tim Janik X-X-Sender: timj@master.birnet.private To: Michalis Giannakidis Subject: Re: gslice allocator: general impresions. In-Reply-To: <200606151827.45477.mgiannakidis@gmail.com> Message-ID: References: <200606151827.45477.mgiannakidis@gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at holken.mikan.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.339 tagged_above=-999 required=2 tests=[AWL=0.048, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, TW_TX=0.077] X-Spam-Score: -2.339 X-Spam-Level: Cc: Gtk+ Developers X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2006 14:12:12 -0000 On Thu, 15 Jun 2006, Michalis Giannakidis wrote: > Dear Glib team, > > I have recently used the glib-glice allocator in a very malloc intensive > application, and I would like to share a few observations I made, with you. > > The typical size I send to g_slice_alloc is 20 and 76 bytes (32 bit build). > The total memory consumed by my application has decreased - which is great! > However it `seems' to me, that this decrease in size is larger for the 64bit > build compared to the 32bit build. (I have modified gslice to align a chunk > to its own size so that I don't have unused memory between chunks eg: request > 20 and get 24...) you mean you've set P2ALIGNMENT to 1 * sizeof(void*) to get better granularity of the slices? have you left NATIVE_MALLOC_PADDING at 2*sizeof(void*) at least? (if not, memory fragmentation on some glibc systems and on all 64bit systems can become etxremely bad). > In my application now I use both g_slice_alloc and malloc.Testing the new > allocator in linux I came accross the following: > After using g_slice_alloc to alloc a great amount of data (eg 1500mb), each of > them being 20 or 76 bytes in size, subsequent calls to malloc(8*1024) or > similar sizes take much longer (the allocation does _not_ got to the swap). this is a magnitude of memory allocations where gslice hasn't been well tested. (my machine only has 1GB of memory for instance). while gslice should perform well even much beyond 1GB, i'd suspect that malloc()/memalign() don't, and thus could result in *some* GSlice slowdown as well. > Also if I chage the min_page_size from 128 to 4096, then the subsequent calls > to malloc(8*1024) or similar sizes take even longer. It takes for ever in the > 64 bit build! maybe due to your alignment tweaks. but maybe also because some malloc() buckets will have even longer lists that way. > Moreover, even with min_page_size set to 128, the calls to malloc take for > ever on a Linux 2.4.20 glibc-2.2.4(glibc up to 2.2.5 has a broken > posix_memalign so I fallback to memalign). broken in what way? > In all of the cases above, malloc responds much faster when the gslice > allocator is turned off. aparently some malloc implementations aren't too good at handling large numbers of page allocations. if modifying GSlice is an option for you, you could try to work around this at the expense of read-only allocation of the memory used by GSlice. to do that, you need to disable the HAVE_COMPLIANT_POSIX_MEMALIGN, HAVE_MEMALIGN and HAVE_VALLOC branches in allocator_memalign() and allocator_memfree() so the read-only malloc()-based fallback allocator is enabled. on 32bit systems, that'll by default allocate 16*4096=64k areas to allocate pages from. by doing: - const guint n_pages = 16; + const guint n_pages = 2560; you'll instead allocate 10MB areas, which should put far less stress on the system malloc() (that way, to fill 1GB, a maximum of 100 allocations are required). > I know I should be providing sample code and test programms here to back up > my observations. I also understand that I should provide execution times > instead of just stating that the calls to malloc take for ever. test programs would be great. allthough this kind of stress test can only be run and examined on a limited set of machines. e.g. the development machines i use have just 1GB and normally have only 30%-40% of free memory to spare for tests during runs like make check -C glib/test ;) > I would like to ask you, if there are any known issues in mixing gslice and > malloc calls in malloc intensive applications. > Any suggested readings would be most welcome. you've already seen the two papers cited in the big comment block at the start of gslice.c? it links to: http://citeseer.ist.psu.edu/bonwick94slab.html http://citeseer.ist.psu.edu/bonwick01magazines.html the first of which describes a kernel page allocator which isn't implemented by GSlice. we use memalign() instead, on the assumption that this is good enough for the vast majority of applications out there. if malloc is too stressed out by the aligned allocations gslice makes in your scenario, implementing this page allocator on top of mmap() and using that as a base allocator for gslice may be another option. > Regards > Michalis --- ciaoTJ From tristan.van.berkom@gmail.com Sat Jun 17 12:09:06 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 2E2D13B013A for ; Sat, 17 Jun 2006 12:09:06 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26133-07 for ; Sat, 17 Jun 2006 12:09:03 -0400 (EDT) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.239]) by menubar.gnome.org (Postfix) with ESMTP id DEE4F3B0061 for ; Sat, 17 Jun 2006 12:09:02 -0400 (EDT) Received: by wr-out-0506.google.com with SMTP id 57so940143wri for ; Sat, 17 Jun 2006 09:07:30 -0700 (PDT) Received: by 10.54.116.7 with SMTP id o7mr3977729wrc; Sat, 17 Jun 2006 09:00:41 -0700 (PDT) Received: from ?66.48.170.156? ( [66.48.170.156]) by mx.gmail.com with ESMTP id 44sm2844499wri.2006.06.17.09.02.05; Sat, 17 Jun 2006 09:02:06 -0700 (PDT) Message-ID: <44942B5F.2090903@gnome.org> Date: Sat, 17 Jun 2006 12:18:39 -0400 User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Alan M. Evans" Subject: Re: GObject extension propose (GContainer) References: <200606151101.12868.ntd@users.sourceforge.net> <44919246.8060301@gnome.org> <1150456522.5305.12.camel@localhost.localdomain> <1150491686.19405.355.camel@zosma.extratech.com> In-Reply-To: <1150491686.19405.355.camel@zosma.extratech.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit From: Tristan Van Berkom X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.208 tagged_above=-999 required=2 tests=[AWL=0.392, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.208 X-Spam-Level: Cc: Gtk+ Developers X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2006 16:09:06 -0000 Alan M. Evans wrote: [...] >>the lookup penalties are negligible. >>type node/class lookups and is_a checks are O(1); >>interface class lookups and conforms_to checks are O(ld(N)), where >>N is the number of interfaces a type node conforms to. >> >> > >Your assertion that the penalties are negligable is not really supported >by your response, unless the constant is also known for both orders. > > From my swift glance at gtype.c, it seems that in the case of an interface, the implementing interface is searched on that class's list of implementing interfaces... so when classes implement hundreds of interfaces it might be a performance hit. I dont think we've yet reached the day that we have to ditch good design and avoid using interfaces because of performance woes, that would be sorry day indeed... (I also dont think GTK+ code will be the only OO code needing major refactoring in those areas too... if these interface lookups weren't negligable) Cheers, -Tristan From chris@gnome-de.org Sat Jun 17 12:59:38 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 89E3F3B00A7 for ; Sat, 17 Jun 2006 12:59:38 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27929-06 for ; Sat, 17 Jun 2006 12:59:35 -0400 (EDT) Received: from mail.bytecamp.net (mail.bytecamp.net [212.204.60.9]) by menubar.gnome.org (Postfix) with SMTP id DF0E93B000D for ; Sat, 17 Jun 2006 12:59:34 -0400 (EDT) Received: (qmail 40076 invoked by uid 85); 17 Jun 2006 16:58:00 -0000 Received: from chris@gnome-de.org by mail.bytecamp.net by uid 88 with qmail-scanner-1.20 (clamscan: 0.88.1 Clear:RC:0(84.150.174.158):. Processed in 0.431315 secs); 17 Jun 2006 16:58:00 -0000 Received: from p5496ae9e.dip0.t-ipconnect.de (HELO ?192.168.123.112?) (chris@gnome-de.org@84.150.174.158) by mail.bytecamp.net with RC4-MD5 encrypted SMTP; 17 Jun 2006 16:57:59 -0000 Subject: GtkFileChooser/GnomeVFS backend still messing up authentication manager? (was: GTK+ 2.10, the endgame) From: Christian Neumair To: Matthias Clasen In-Reply-To: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> References: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> Content-Type: text/plain Date: Sat, 17 Jun 2006 18:57:54 +0200 Message-Id: <1150563475.24534.12.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.586 tagged_above=-999 required=2 tests=[AWL=0.013, BAYES_00=-2.599] X-Spam-Score: -2.586 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2006 16:59:38 -0000 Am Donnerstag, den 15.06.2006, 09:56 -0400 schrieb Matthias Clasen: > I want to have GTK+ 2.10 ready at or immediately after GUADEC. > > I did not declare 2.9.3 api frozen in the release announcement, > because we were still holding the door open for Kris' work on > the new tooltips api. But he has run into some difficulties > with the implementation which will take some time to overcome, > so we have decided to punt this feature and try to get it > into 2.12 early. > > Therefore, I want to consider 2.9.3 api frozen, and take a > look at what still needs to happen before 2.10. Here are some > things I personally would like get worked on (not sure > how much time I can free to look into these myself): > > - I think the async filechooser conversion has caused some > regressions, I noticed that .hidden support seems broken > and autocompletion also behaved badly for me recently. > > - There is a number of FIXMEs and unimplemented bits in > the print code. > > - The print backends need a careful look wrt to memory leaks > and error reporting. > > Are there other important bugs or regressions that need > attention before 2.10 ? Some months ago I investigated an issue where the GtkFileChooser requested file info for all shortcuts and caused mass login requests for all bookmarked remote locations on startup that require login with the GnomeVFS backend. I think the issue was that the file chooser has no way of requesting file info, but signalling at the same time that failure due to unavailability of resources or access constraints isn't fatal, allowing the GnomeVFS backend to not request login data when it is invoked through gtkfilechooserdefault.c:shortcuts_reload_icons. In that case, we may want to fall back to a folder icon. >From reading the GTK+ HEAD source code, the shortcut code still doesn't seem to pass any special flags, so it still seems to be relevant. -- Christian Neumair From gcottenc@gmail.com Sat Jun 17 13:23:55 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 81FC83B000D for ; Sat, 17 Jun 2006 13:23:55 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30389-08 for ; Sat, 17 Jun 2006 13:23:54 -0400 (EDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.197]) by menubar.gnome.org (Postfix) with ESMTP id 01A153B010F for ; Sat, 17 Jun 2006 13:23:53 -0400 (EDT) Received: by wx-out-0102.google.com with SMTP id h26so659270wxd for ; Sat, 17 Jun 2006 10:22:54 -0700 (PDT) Received: by 10.70.116.8 with SMTP id o8mr5867050wxc; Sat, 17 Jun 2006 10:22:54 -0700 (PDT) Received: by 10.70.19.4 with HTTP; Sat, 17 Jun 2006 10:22:54 -0700 (PDT) Message-ID: Date: Sat, 17 Jun 2006 19:22:54 +0200 From: "Guillaume Cottenceau" To: "Matthias Clasen" Subject: Re: GTK+ 2.10, the endgame In-Reply-To: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.6 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.6 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2006 17:23:55 -0000 On 6/15/06, Matthias Clasen wrote: > Therefore, I want to consider 2.9.3 api frozen, and take a Does this mean that http://developer.gnome.org/doc/API/2.0/gtk/ix07.html (and equivalents for gdk, pango, atk) is now a fully stable source for bindings which want to support new features of 2.10? -- Guillaume Cottenceau - http://zarb.org/~gc/ From timj@gtk.org Sun Jun 18 07:31:59 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id D384A3B0316 for ; Sun, 18 Jun 2006 07:31:59 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21403-07 for ; Sun, 18 Jun 2006 07:31:57 -0400 (EDT) Received: from holken.mikan.net (holken.mikan.net [83.145.56.183]) by menubar.gnome.org (Postfix) with ESMTP id 5988B3B09AB for ; Sun, 18 Jun 2006 07:31:57 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by holken.mikan.net (Postfix) with ESMTP id D1B0818461; Sun, 18 Jun 2006 13:31:12 +0200 (CEST) Received: from holken.mikan.net ([127.0.0.1]) by localhost (holken.mikan.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16166-04; Sun, 18 Jun 2006 13:31:09 +0200 (CEST) Received: from birnet.org (d003096.adsl.hansenet.de [80.171.3.96]) by holken.mikan.net (Postfix) with ESMTP id DE31E14571; Sun, 18 Jun 2006 13:31:08 +0200 (CEST) Received: from master.birnet.private (localhost.localdomain [127.0.0.1]) by birnet.org (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k5IBV5n9025330 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 18 Jun 2006 13:31:05 +0200 Received: (from timj@localhost) by master.birnet.private (8.13.4/8.13.4/Submit) id k5IBUuX0025320; Sun, 18 Jun 2006 13:30:56 +0200 Date: Sun, 18 Jun 2006 13:30:56 +0200 (CEST) From: Tim Janik X-X-Sender: timj@master.birnet.private To: Tristan Van Berkom Subject: Re: GObject extension propose (GContainer) In-Reply-To: <44942B5F.2090903@gnome.org> Message-ID: References: <200606151101.12868.ntd@users.sourceforge.net> <44919246.8060301@gnome.org> <1150456522.5305.12.camel@localhost.localdomain> <1150491686.19405.355.camel@zosma.extratech.com> <44942B5F.2090903@gnome.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at holken.mikan.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.378 tagged_above=-999 required=2 tests=[AWL=0.086, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.378 X-Spam-Level: Cc: Gtk+ Developers X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jun 2006 11:32:00 -0000 On Sat, 17 Jun 2006, Tristan Van Berkom wrote: > Alan M. Evans wrote: > [...] > >>> the lookup penalties are negligible. >>> type node/class lookups and is_a checks are O(1); >>> interface class lookups and conforms_to checks are O(ld(N)), where >>> N is the number of interfaces a type node conforms to. >>> >>> >> >> Your assertion that the penalties are negligable is not really supported >> by your response, unless the constant is also known for both orders. >> >> > From my swift glance at gtype.c, it seems that in the case of > an interface, the implementing interface is searched on that class's > list of implementing interfaces... so when classes implement > hundreds of interfaces it might be a performance hit. no there won't be a performance hit. that's because gtype.c uses a binary search for the lookups (as indicated in my last email by the O(ld(N)) complexity). the function used for frequent interface lookups is: gpointer g_type_interface_peek (gpointer instance_class, GType iface_type); and in a nutshell, it does: { TypeNode *node = lookup_type_node_I (class->g_type); // O(1) TypeNode *iface = lookup_type_node_I (iface_type); // O(1) IFaceEntry *entry = type_lookup_iface_entry_L (node, iface); // O(ld(N)) return entry->vtable; } take a look at gtype.c and type_lookup_iface_entry_L() to confirm. using a binary lookup in type_lookup_iface_entry_L() means, lookups in terms of number of interfaces and node visits during the search relate like this: interfaces-per-node | visits-per-lookup 1 | 1.0 2 | 2.0 3 | 2.6 4 | 3.0 5 | 3.3 6 | 3.6 8 | 4.0 16 | 5.0 32 | 6.0 64 | 7.0 128 | 8.0 256 | 9.0 512 | 10.0 1024 | 11.0 65536 | 17.0 262144 | 19.0 1048576 | 21.0 67108864 | 27.0 268435456 | 29.0 2147483648 | 32.0 that is, for all practical purposes, interface lookups are negligible even for many thausands of interfaces implemented per node. and now, please show me the OO system that gets into the hundreds at least... > Cheers, > -Tristan --- ciaoTJ From nicola@effe-gi.it Wed Jun 14 13:42:30 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id D182C3B0003 for ; Wed, 14 Jun 2006 13:42:30 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20727-04 for ; Wed, 14 Jun 2006 13:42:29 -0400 (EDT) Received: from mailout01.albacom.net (mailout01.albacom.net [217.220.34.13]) by menubar.gnome.org (Postfix) with SMTP id 968DC3B0081 for ; Wed, 14 Jun 2006 13:42:28 -0400 (EDT) Received: (qmail 15057 invoked by uid 508); 14 Jun 2006 17:41:43 -0000 Received: from nicola@effe-gi.it by mailout01.albacom.net with qmail-scanner (spamassassin: ???. Clear:RC:1(217.221.76.9):SA:0(0.0/15.0):. Processed in 2.56365 secs); 14 Jun 2006 17:41:43 -0000 Received: from unknown (HELO sviluppo.internet.local) (postmaster@effe-gi.it@217.221.76.9) by mailout01.albacom.net with SMTP; 14 Jun 2006 17:41:40 -0000 From: Fontana Nicola Organization: Elettronica EFFE-GI s.n.c. To: gtk-devel-list@gnome.org Subject: GObject extension propose (GContainer) Date: Wed, 14 Jun 2006 20:17:53 +0000 User-Agent: KMail/1.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200606142017.53525.nicola@effe-gi.it> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.599 tagged_above=-999 required=2 tests=[BAYES_00=-2.599] X-Spam-Score: -2.599 X-Spam-Level: X-Mailman-Approved-At: Sun, 18 Jun 2006 10:56:05 -0400 X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2006 17:42:31 -0000 Hi all, I'm a GObject based libraries (for UI purpose and not) user and I often need a generic container to derive my own types. In my opinion, I think this generic container must be included inside the GObject library ... it could be used by a lot of derived libraries providing a common approach. I published my solution - that is, what I am currently using - on sourceforge. http://sourceforge.net/projects/gcontainer/ Is it a good idea? Is something planned in this direction? Am I totally wrong? I need feedbacks ... Nicola From tristan.van.berkom@gmail.com Sun Jun 18 12:43:27 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 15A9A3B0BF9 for ; Sun, 18 Jun 2006 12:43:27 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03626-01 for ; Sun, 18 Jun 2006 12:43:26 -0400 (EDT) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.225]) by menubar.gnome.org (Postfix) with ESMTP id 1D9F83B0C2D for ; Sun, 18 Jun 2006 12:43:26 -0400 (EDT) Received: by wr-out-0506.google.com with SMTP id 37so824607wra for ; Sun, 18 Jun 2006 09:42:28 -0700 (PDT) Received: by 10.54.153.8 with SMTP id a8mr5030935wre; Sun, 18 Jun 2006 09:42:28 -0700 (PDT) Received: from ?66.48.170.160? ( [66.48.170.160]) by mx.gmail.com with ESMTP id 25sm98918wra.2006.06.18.09.42.26; Sun, 18 Jun 2006 09:42:27 -0700 (PDT) Message-ID: <44958664.4050704@gmail.com> Date: Sun, 18 Jun 2006 12:59:16 -0400 From: Tristan Van Berkom User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Janik Subject: Re: GObject extension propose (GContainer) References: <200606151101.12868.ntd@users.sourceforge.net> <44919246.8060301@gnome.org> <1150456522.5305.12.camel@localhost.localdomain> <1150491686.19405.355.camel@zosma.extratech.com> <44942B5F.2090903@gnome.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.495 tagged_above=-999 required=2 tests=[AWL=-0.351, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=1.456, SPF_PASS=-0.001] X-Spam-Score: -1.495 X-Spam-Level: Cc: Gtk+ Developers X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jun 2006 16:43:27 -0000 Tim Janik wrote: [...] > no there won't be a performance hit. [...] > 268435456 | 29.0 > 2147483648 | 32.0 > > that is, for all practical purposes, interface lookups are negligible > even > for many thausands of interfaces implemented per node. > Those stats look great Tim, sorry for any confusion I may have unwillingly caused in this thread, I think its of great importance that people not fear the GInterface. Cheers, -Tristan From jnoreiko@yahoo.com Sun Jun 18 15:19:51 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id E64063B0114 for ; Sun, 18 Jun 2006 15:19:50 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08166-08 for ; Sun, 18 Jun 2006 15:19:48 -0400 (EDT) Received: from web32405.mail.mud.yahoo.com (web32405.mail.mud.yahoo.com [68.142.207.198]) by menubar.gnome.org (Postfix) with SMTP id 24E153B00E5 for ; Sun, 18 Jun 2006 15:19:47 -0400 (EDT) Received: (qmail 1542 invoked by uid 60001); 18 Jun 2006 19:19:02 -0000 Message-ID: <20060618191902.1540.qmail@web32405.mail.mud.yahoo.com> Received: from [172.213.179.4] by web32405.mail.mud.yahoo.com via HTTP; Sun, 18 Jun 2006 20:19:02 BST Date: Sun, 18 Jun 2006 20:19:02 +0100 (BST) From: Joachim Noreiko Subject: Re: GtkFileChooser/GnomeVFS backend still messing up authentication manager? (was: GTK+ 2.10, the endgame) To: gtk-devel-list@gnome.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.64 tagged_above=-999 required=2 tests=[AWL=-0.688, BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2, DNS_FROM_RFC_WHOIS=1.447] X-Spam-Score: -1.64 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jun 2006 19:19:51 -0000 > Date: Sat, 17 Jun 2006 18:57:54 +0200 > From: Christian Neumair > Subject: GtkFileChooser/GnomeVFS backend still > > Are there other important bugs or regressions that > need > > attention before 2.10 ? Yes! Please could you implement a help button in the filechooser. The documentation is already written and is ready to be linked to. ___________________________________________________________ All new Yahoo! Mail "The new Interface is stunning in its simplicity and ease of use." - PC Magazine http://uk.docs.yahoo.com/nowyoucan.html From alexl@redhat.com Mon Jun 19 05:47:41 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id AB66D3B00A4 for ; Mon, 19 Jun 2006 05:47:41 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02513-02 for ; Mon, 19 Jun 2006 05:47:40 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id 4A6763B0014 for ; Mon, 19 Jun 2006 05:47:40 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5J9Aqqj029011; Mon, 19 Jun 2006 05:10:52 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5J9AqpA029834; Mon, 19 Jun 2006 05:10:52 -0400 Received: from [127.0.0.1] (sebastian-int.corp.redhat.com [172.16.52.221]) by devserv.devel.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5J9Ap4k026344; Mon, 19 Jun 2006 05:10:51 -0400 Subject: Re: Printing and blocking ui From: Alexander Larsson To: Yevgen Muntyan In-Reply-To: <4491AF5A.2050702@tamu.edu> References: <4491AF5A.2050702@tamu.edu> Content-Type: text/plain Date: Mon, 19 Jun 2006 11:10:51 +0200 Message-Id: <1150708251.1962.23.camel@greebo> Mime-Version: 1.0 X-Mailer: Evolution 2.7.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.588 tagged_above=-999 required=2 tests=[AWL=0.013, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.588 X-Spam-Level: Cc: GTK Devel List X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2006 09:47:41 -0000 On Thu, 2006-06-15 at 14:04 -0500, Yevgen Muntyan wrote: > Hi there, > > I print a text document from GtkTextView here. There is a problem > with pagination: pagination is potentially slow, so some sort of progress > dialog should be shown during it. From the other hand, the text buffer > must not be modified during pagination. > How to solve it? Should I show my own modal dialog and make sure user > doesn't modify the buffer, or GtkPrintOperation can take care of it? This is supported now with the Gtkprintoperation::paginate signal and gtk_print_operation_set_show_progress(). > Actually, it would be good to ensure printing blocks the text widget too, > since in this case it wouldn't be necessary to calculate and store all > the pango > layouts in begin-print. Maybe just show a modal dialog between begin-print > and end-print. Locking the editing widget is probably something you have to do yourself. You could also do a snapshot of the data at print time. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl@redhat.com alla@lysator.liu.se He's an otherworldly guerilla ex-con with a secret. She's a scantily clad belly-dancing widow who can talk to animals. They fight crime! From muntyan@tamu.edu Mon Jun 19 06:17:07 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 591293B00FB for ; Mon, 19 Jun 2006 06:17:07 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04050-03 for ; Mon, 19 Jun 2006 06:17:05 -0400 (EDT) Received: from smtp101.vzn.mail.mud.yahoo.com (smtp101.vzn.mail.mud.yahoo.com [68.142.203.45]) by menubar.gnome.org (Postfix) with SMTP id 64EE03B00C8 for ; Mon, 19 Jun 2006 06:17:05 -0400 (EDT) Received: (qmail 1322 invoked from network); 19 Jun 2006 10:16:02 -0000 Received: from unknown (HELO ?192.168.3.9?) (muntyan@verizon.net@71.113.224.59 with plain) by smtp101.vzn.mail.mud.yahoo.com with SMTP; 19 Jun 2006 10:16:01 -0000 Message-ID: <44967960.3060609@tamu.edu> Date: Mon, 19 Jun 2006 05:16:00 -0500 From: Yevgen Muntyan User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20060216 Debian/1.7.12-1.1ubuntu2 X-Accept-Language: en MIME-Version: 1.0 To: Alexander Larsson Subject: Re: Printing and blocking ui References: <4491AF5A.2050702@tamu.edu> <1150708251.1962.23.camel@greebo> In-Reply-To: <1150708251.1962.23.camel@greebo> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.553 tagged_above=-999 required=2 tests=[AWL=0.046, BAYES_00=-2.599] X-Spam-Score: -2.553 X-Spam-Level: Cc: GTK Devel List X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2006 10:17:07 -0000 Alexander Larsson wrote: >On Thu, 2006-06-15 at 14:04 -0500, Yevgen Muntyan wrote: > > >>Hi there, >> >>I print a text document from GtkTextView here. There is a problem >>with pagination: pagination is potentially slow, so some sort of progress >>dialog should be shown during it. From the other hand, the text buffer >>must not be modified during pagination. >>How to solve it? Should I show my own modal dialog and make sure user >>doesn't modify the buffer, or GtkPrintOperation can take care of it? >> >> > >This is supported now with the Gtkprintoperation::paginate signal and >gtk_print_operation_set_show_progress(). > > I don't know how paginate works, but the dialog which shows up during printing is not modal, and it appears only after some delay. I can erase text in the buffer between clicking Print button and the time when progress dialog appears. >>Actually, it would be good to ensure printing blocks the text widget too, >>since in this case it wouldn't be necessary to calculate and store all >>the pango >>layouts in begin-print. Maybe just show a modal dialog between begin-print >>and end-print. >> >> > >Locking the editing widget is probably something you have to do >yourself. You could also do a snapshot of the data at print time. > > Well, locking is easy, but I have to tell user about what's happening. So I guess the solution is to have my own modal progress dialog. Regards, Yevgen From mardy@users.sourceforge.net Mon Jun 19 10:20:09 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id B4CCC3B018E for ; Mon, 19 Jun 2006 10:20:09 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14994-07 for ; Mon, 19 Jun 2006 10:20:06 -0400 (EDT) Received: from smtp008.mail.ukl.yahoo.com (smtp008.mail.ukl.yahoo.com [217.12.11.62]) by menubar.gnome.org (Postfix) with SMTP id 190673B0076 for ; Mon, 19 Jun 2006 10:20:05 -0400 (EDT) Received: (qmail 79361 invoked from network); 19 Jun 2006 14:12:00 -0000 Received: from unknown (HELO pupilla) (mardy78@151.38.48.109 with login) by smtp008.mail.ukl.yahoo.com with SMTP; 19 Jun 2006 14:12:00 -0000 Received: by pupilla (Postfix, from userid 1000) id D59DB6B883; Mon, 19 Jun 2006 16:10:17 +0200 (CEST) Date: Mon, 19 Jun 2006 16:10:17 +0200 From: Alberto Mardegan To: gtk-devel-list@gnome.org Subject: GtkLabel as a child of a windowless widget Message-ID: <20060619141017.GA31744@pupilla> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Accept-Language: it,ia,en,bg,es,fr User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.599 tagged_above=-999 required=2 tests=[BAYES_00=-2.599] X-Spam-Score: -2.599 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2006 14:20:09 -0000 Hi all! I'm creating a Widget based on GtkFrame, with little differences: 1) It's not a container 2) It has the GTK_NO_WINDOW flag set. I'm going to use this widget inside a GtkFixed container, with the only goal of having it paint its frame (and draw its label) on the screen. I want it windowless, so that I can insert other widgets which will appear to be inside it, but which will be actually be owned by the GtkFixed. I know this is not really senseful, but I need such a widget for porting lots of applications from Prolific's Panther GUI to Gtk+. The problem I have, is that the frame label isn't drawn. I'm not sure if there are any operation I should do on it... I just create it, and call gtk_widget_set_parent(). On size_allocate, I'm not sure whether the child's x and y members of the size_allocation struct should be relative to (0,0) or to the parent widget's x and y allocation (since the parent is windowless, too). But this won't work in any case... Any hints? I have no clue. -- Saluti, Mardy http://interlingua.altervista.org Chiacchiera con i tuoi amici in tempo reale! http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com From ame1@extratech.com Mon Jun 19 11:13:35 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 1E8293B03A9 for ; Mon, 19 Jun 2006 11:13:35 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16850-05 for ; Mon, 19 Jun 2006 11:13:32 -0400 (EDT) Received: from portal2.extratech.com (portal.extratech.com [67.105.201.210]) by menubar.gnome.org (Postfix) with ESMTP id BF3D93B0076 for ; Mon, 19 Jun 2006 11:13:30 -0400 (EDT) Received: from zosma.extratech.com (zosma.extratech.com [192.168.0.41]) by portal2.extratech.com (8.12.11/8.12.11) with ESMTP id k5JFBMdd004376; Mon, 19 Jun 2006 08:11:22 -0700 Subject: Re: GObject extension propose (GContainer) From: "Alan M. Evans" To: Tristan Van Berkom In-Reply-To: <44942B5F.2090903@gnome.org> References: <200606151101.12868.ntd@users.sourceforge.net> <44919246.8060301@gnome.org> <1150456522.5305.12.camel@localhost.localdomain> <1150491686.19405.355.camel@zosma.extratech.com> <44942B5F.2090903@gnome.org> Content-Type: text/plain Message-Id: <1150729881.19405.420.camel@zosma.extratech.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 19 Jun 2006 08:11:21 -0700 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.86.1/1549/Sat Jun 17 15:20:39 2006 on portal2.extratech.com X-Virus-Status: Clean X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.551 tagged_above=-999 required=2 tests=[AWL=0.048, BAYES_00=-2.599] X-Spam-Score: -2.551 X-Spam-Level: Cc: Gtk+ Developers X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2006 15:13:35 -0000 On Sat, 2006-06-17 at 09:18, Tristan Van Berkom wrote: > Alan M. Evans wrote: > >>the lookup penalties are negligible. > >>type node/class lookups and is_a checks are O(1); > >>interface class lookups and conforms_to checks are O(ld(N)), where > >>N is the number of interfaces a type node conforms to. > > > >Your assertion that the penalties are negligable is not really supported > >by your response, unless the constant is also known for both orders.> > > > From my swift glance at gtype.c, it seems that in the case of > an interface, the implementing interface is searched on that class's > list of implementing interfaces... so when classes implement > hundreds of interfaces it might be a performance hit. My impression from the original question, which I didn't ask, was not so much about access to a large number of members. If a single variable needs to be examined many times then the performance penalty of a generic interface lookup can add up. In any case, I merely observed an assertion, "the lookup penalties are negligible," and the what appeared to be supporting data, the order of the lookups. This doesn't tell us what the penalty is, only that there is a penalty that gets worse as the number of members increases. Maybe the penalty is negligible, but the data presented didn't say so. That's all I was saying. > I dont think we've yet reached the day that we have to ditch good design > and avoid using interfaces because of performance woes, that would > be sorry day indeed... (I also dont think GTK+ code will be the only OO code > needing major refactoring in those areas too... if these interface > lookups weren't negligable) Indeed. I would certainly not advocate dispensing with good design. In fact, I usually advocate the purist design in my own software, and let Moore's Law fix the performance issues. But some cases still call for direct access for essential performance. I, too, would like to know the performance penalty of the generic interface. Being lazy, I suppose I will set up some experiment to discover it pragmatically. From federico@ximian.com Mon Jun 19 13:28:06 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id B62B13B05EF for ; Mon, 19 Jun 2006 13:28:06 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23010-05 for ; Mon, 19 Jun 2006 13:28:05 -0400 (EDT) Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) by menubar.gnome.org (Postfix) with ESMTP id 163BA3B0809 for ; Mon, 19 Jun 2006 13:28:04 -0400 (EDT) Received: (qmail 29558 invoked from network); 19 Jun 2006 17:27:00 -0000 Received: from localhost (HELO 164-99-120-63.boston.ximian.com) (127.0.0.1) by localhost with SMTP; 19 Jun 2006 17:27:00 -0000 Subject: Re: GtkFileChooser/GnomeVFS backend still messing up authentication manager? (was: GTK+ 2.10, the endgame) From: Federico Mena Quintero To: Joachim Noreiko In-Reply-To: <20060618191902.1540.qmail@web32405.mail.mud.yahoo.com> References: <20060618191902.1540.qmail@web32405.mail.mud.yahoo.com> Content-Type: text/plain Date: Mon, 19 Jun 2006 12:22:31 -0500 Message-Id: <1150737751.8452.77.camel@cacharro.xalalinux.org> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.575 tagged_above=-999 required=2 tests=[AWL=0.024, BAYES_00=-2.599] X-Spam-Score: -2.575 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2006 17:28:06 -0000 On Sun, 2006-06-18 at 20:19 +0100, Joachim Noreiko wrote: > Yes! > Please could you implement a help button in the > filechooser. The documentation is already written and > is ready to be linked to. Do we have a mechanism for this? I see that GtkColorSelectionDialog creates a Help button but hides it by default, and it gives GTK_RESPONSE_HELP when pressed. Does that get captured anywhere so that it can take you to the right help page? Federico From tvb@gnome.org Mon Jun 19 14:23:28 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 8657F3B04AC for ; Mon, 19 Jun 2006 14:23:28 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25353-05 for ; Mon, 19 Jun 2006 14:23:26 -0400 (EDT) Received: from mail.touchtunes.com (mail.touchtunes.com [207.96.182.162]) by menubar.gnome.org (Postfix) with ESMTP id 74D063B03C7 for ; Mon, 19 Jun 2006 14:23:26 -0400 (EDT) Received: from [192.168.0.138] (unknown [192.168.0.138]) by mail.touchtunes.com (Postfix) with ESMTP id 1C61615AAA; Mon, 19 Jun 2006 14:22:06 -0400 (EDT) Message-ID: <4496ED9C.3090009@gnome.org> Date: Mon, 19 Jun 2006 14:31:56 -0400 From: Tristan Van Berkom User-Agent: Mozilla Thunderbird 0.8 (X11/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alberto Mardegan Subject: Re: GtkLabel as a child of a windowless widget References: <20060619141017.GA31744@pupilla> In-Reply-To: <20060619141017.GA31744@pupilla> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.517 tagged_above=-999 required=2 tests=[AWL=0.006, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, TW_GT=0.077] X-Spam-Score: -2.517 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2006 18:23:28 -0000 Alberto Mardegan wrote: [...] > > Any hints? I have no clue. This mailing list is for the discussion of GTK+ development itself, for questions related to writing applications in gtk+ please write to gtk-app-devel-list@gnome.org or gtk-list@gnome.org. FYI: Widgets do not overlap in any containers in gtk+ (I've heard that there is z-ordering in gnomecanvas... you might want to check that out). You can: - Draw the frame yourself in the GtkFixed and place a child label where the frames label would be - Add a fixed as the child widget of the frame (probably what you want anyway). Cheers, -Tristan From federico@ximian.com Mon Jun 19 22:53:07 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 955513B044F for ; Mon, 19 Jun 2006 22:53:07 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18923-10 for ; Mon, 19 Jun 2006 22:53:06 -0400 (EDT) Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) by menubar.gnome.org (Postfix) with ESMTP id E23A03B0301 for ; Mon, 19 Jun 2006 22:53:05 -0400 (EDT) Received: (qmail 30485 invoked from network); 20 Jun 2006 02:52:00 -0000 Received: from localhost (HELO 164-99-120-63.boston.ximian.com) (127.0.0.1) by localhost with SMTP; 20 Jun 2006 02:52:00 -0000 Subject: Re: GtkLabel as a child of a windowless widget From: Federico Mena Quintero To: Alberto Mardegan In-Reply-To: <20060619141017.GA31744@pupilla> References: <20060619141017.GA31744@pupilla> Content-Type: text/plain Date: Mon, 19 Jun 2006 21:47:24 -0500 Message-Id: <1150771645.8452.94.camel@cacharro.xalalinux.org> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.575 tagged_above=-999 required=2 tests=[AWL=0.024, BAYES_00=-2.599] X-Spam-Score: -2.575 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2006 02:53:07 -0000 On Mon, 2006-06-19 at 16:10 +0200, Alberto Mardegan wrote: > Hi all! > I'm creating a Widget based on GtkFrame, with little differences: > 1) It's not a container > 2) It has the GTK_NO_WINDOW flag set. > > I'm going to use this widget inside a GtkFixed container, with the only > goal of having it paint its frame (and draw its label) on the screen. > I want it windowless, so that I can insert other widgets which will > appear to be inside it, but which will be actually be owned by the > GtkFixed. First, can you simply use a GtkFrame inside a GtkFixed, and just not put a child inside the frame? > The problem I have, is that the frame label isn't drawn. I'm not sure if > there are any operation I should do on it... I just create it, and call > gtk_widget_set_parent(). > On size_allocate, I'm not sure whether the child's x and y members of > the size_allocation struct should be relative to (0,0) or to the parent > widget's x and y allocation (since the parent is windowless, too). But > this won't work in any case... Allocations are always with respect to the parent window. So if you have a windowed parent, then inside it a no-window container at (10, 20), and a child of that container which is supposed to be offset (3, 4) pixels from the container's top-left corner, then the child's allocation will be at (13, 24). Federico From mclasen@redhat.com Tue Jun 20 09:27:18 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 4C2873B02C2 for ; Tue, 20 Jun 2006 09:27:18 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17744-01 for ; Tue, 20 Jun 2006 09:27:17 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id D5CE13B0184 for ; Tue, 20 Jun 2006 09:27:16 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5KDQgQV017831 for ; Tue, 20 Jun 2006 09:26:42 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5KDQbkk003106 for ; Tue, 20 Jun 2006 09:26:37 -0400 Received: from golem.boston.redhat.com (golem.boston.redhat.com [172.16.80.24]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id k5KDQbdH021200 for ; Tue, 20 Jun 2006 09:26:37 -0400 Subject: GTK+ team meeting From: Matthias Clasen To: gtk-devel-list@gnome.org Content-Type: text/plain Date: Tue, 20 Jun 2006 09:26:36 -0400 Message-Id: <1150809996.15532.50.camel@golem.boston.redhat.com> Mime-Version: 1.0 X-Mailer: Evolution 2.7.1 (2.7.1-1) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.543 tagged_above=-999 required=2 tests=[AWL=0.058, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.543 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2006 13:27:18 -0000 After a few weeks, we should probably have a team meeting today. The meeting is intended for the GTK+ team, but everybody is welcome to come and listen. The meeting logs will be posted on the GTK+ website (http://www.gtk.org/plan/meetings). Place: irc.gnome.org:#gtk-devel Time: 19:30 UTC (15:30 EDT), Tue, Jun 20 Possible agenda items: - GUADEC meeting - 2.10 + when to release + what needs to be on the 2.10 milestone but isn't ? Matthias From mclasen@redhat.com Tue Jun 20 11:22:11 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 3B32C3B043F; Tue, 20 Jun 2006 11:22:11 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22457-09; Tue, 20 Jun 2006 11:22:09 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id 71CF13B00E7; Tue, 20 Jun 2006 11:22:09 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5KFLLnL004523; Tue, 20 Jun 2006 11:21:21 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5KFLLNA016479; Tue, 20 Jun 2006 11:21:21 -0400 Received: from golem.boston.redhat.com (golem.boston.redhat.com [172.16.80.24]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id k5KFLKdH032719; Tue, 20 Jun 2006 11:21:20 -0400 Subject: GLib 2.11.4 released From: Matthias Clasen To: gnome-announce-list@gnome.org, gtk-devel-list@gnome.org, gtk-list@gnome.org, gtk-app-devel-list@gnome.org Content-Type: text/plain Date: Tue, 20 Jun 2006 11:21:20 -0400 Message-Id: <1150816880.15532.58.camel@golem.boston.redhat.com> Mime-Version: 1.0 X-Mailer: Evolution 2.7.1 (2.7.1-1) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.543 tagged_above=-999 required=2 tests=[AWL=0.058, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.543 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: gnome-hackers@gnome.org List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2006 15:22:11 -0000 GLib 2.11.4 is now available for download at: ftp://ftp.gtk.org/pub/gtk/v2.11/ http://ftp.gnome.org/pub/GNOME/sources/glib/2.11/ glib-2.11.4.tar.bz2 md5sum: 9d3a94baa4bfcd9a579b45eea6de3a8c glib-2.11.4.tar.gz md5sum: f7768bc7ed524c6b40cb87daccb6c2b2 This is a development release leading up to GLib 2.12. Notes: * This is unstable development release. While it has had a bit of testing, there are certainly plenty of bugs remaining to be found. This release should not be used in production. * Installing this version will overwrite your existing copy of GLib 2.10. If you have problems, you'll need to reinstall GLib 2.10. * GLib 2.12 will be source and binary compatible with the GLib 2.10.x series (for some caveats, see the README). At this point, the API additions in the 2.11.x series are finished. * Bugs should be reported to http://bugzilla.gnome.org. About GLib ========== GLib is the low-level core library that forms the basis for projects such as GTK+ and GNOME. It provides data structure handling for C, portability wrappers, and interfaces for such runtime functionality as an event loop, threads, dynamic loading, and an object system. More information about GLib is available at: http://www.gtk.org/ An installation guide for the GTK+ libraries, including GLib, can be found at: http://developer.gnome.org/doc/API/2.0/gtk/gtk-building.html Overview of Changes from GLib 2.11.3 to GLib 2.11.4 =================================================== * GBookmarkFile: - g_bookmark_file_remove_item returns a boolean * g_mkstemp accepts the XXXXXX in the middle of the template * Bugs fixed: 344868 g_key_file_to_data should separate groups * Updated translations (de,es,fr,gu,hi,ko,th) A list of all bugs fixed in this release can be found at: http://bugzilla.gnome.org/buglist.cgi?bug_id=344868 Thanks to everybody who has contributed to this release, in the form of bug reports or patches: Emmanuele Bassi, Christian Persch, Federico Mena Quintero Matthias Clasen June 20, 2006 From mgiannakidis@gmail.com Mon Jun 19 08:23:48 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id E62893B0AAF for ; Mon, 19 Jun 2006 08:23:47 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10711-01 for ; Mon, 19 Jun 2006 08:23:44 -0400 (EDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.191]) by menubar.gnome.org (Postfix) with ESMTP id E721A3B089A for ; Mon, 19 Jun 2006 08:23:43 -0400 (EDT) Received: by nf-out-0910.google.com with SMTP id x30so1070652nfb for ; Mon, 19 Jun 2006 05:22:35 -0700 (PDT) Received: by 10.48.14.1 with SMTP id 1mr1206423nfn; Mon, 19 Jun 2006 05:16:27 -0700 (PDT) Received: from ?213.140.137.120? ( [213.140.137.120]) by mx.gmail.com with ESMTP id d2sm4750763nfe.2006.06.19.05.16.26; Mon, 19 Jun 2006 05:16:26 -0700 (PDT) From: Michalis Giannakidis To: gtk-devel-list@gnome.org Subject: Re: gslice allocator: general impresions. Date: Mon, 19 Jun 2006 15:20:48 +0300 User-Agent: KMail/1.8.3 References: <200606151827.45477.mgiannakidis@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200606191520.48220.mgiannakidis@gmail.com> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.526 tagged_above=-999 required=2 tests=[AWL=-0.002, BAYES_00=-2.599, SPF_PASS=-0.001, TW_TX=0.077] X-Spam-Score: -2.526 X-Spam-Level: X-Mailman-Approved-At: Tue, 20 Jun 2006 12:30:13 -0400 X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2006 12:23:48 -0000 Dear Tim > > (I have modified gslice > > to align a chunk to its own size so that I don't have unused memory > > between chunks eg: request 20 and get 24...) > > you mean you've set P2ALIGNMENT to 1 * sizeof(void*) to get better > granularity of the slices? have you left NATIVE_MALLOC_PADDING at > 2*sizeof(void*) at least? (if not, memory fragmentation on some glibc > systems and on all 64bit systems can become etxremely bad). > I didn't change P2ALIGNMENT . I modified SLAB_INDEX to (asize - 1), SLAB_CHUNK_SIZE to (ix + 1) I also modified P2ALIGN to (size) for all occurances of P2ALIGN except for SLAB_INFO_SIZE. I understand that this will create different memory pools for each size I alloc for, but this is accpeted since I only call g_slice_alloc for two sizes. The tweak seem to be OK since I don't get any segfaults. > maybe due to your alignment tweaks. but maybe also because some malloc() > buckets will have even longer lists that way. > The slowdown also occurred without the alignment tweaks. My understanding is that it is a general malloc slowdown that occurres of the many small mallocs done in the application plus the many larger mallocs done by the gslice allocator. I have read the references available in the gslice allocator comments and were very helpful. What I am looking for know is some sort of comparisons in memory usage and speed in applications changing from malloc to gslice. Also, any tweaks in the gslice allocation sizes providing a more responsive malloc would be great! Any suggestions would be very welcome. Thank you very much. Michalis -- Michalis Giannakidis From mclasen@redhat.com Wed Jun 21 09:13:22 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C2BA53B1007 for ; Wed, 21 Jun 2006 09:13:22 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07614-06 for ; Wed, 21 Jun 2006 09:13:21 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id E02C63B0FE5 for ; Wed, 21 Jun 2006 09:13:20 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5LDDKUh027657; Wed, 21 Jun 2006 09:13:20 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5LDDJnE017553; Wed, 21 Jun 2006 09:13:19 -0400 Received: from golem.boston.redhat.com (golem.boston.redhat.com [172.16.80.24]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id k5LDDJdH018065; Wed, 21 Jun 2006 09:13:19 -0400 Subject: Re: Fwd: GTK+ 2.10, the endgame From: Matthias Clasen To: Guillaume Cottenceau In-Reply-To: References: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> Content-Type: text/plain Date: Wed, 21 Jun 2006 09:13:19 -0400 Message-Id: <1150895599.15532.80.camel@golem.boston.redhat.com> Mime-Version: 1.0 X-Mailer: Evolution 2.7.1 (2.7.1-1) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.506 tagged_above=-999 required=2 tests=[AWL=0.018, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, TW_GT=0.077] X-Spam-Score: -2.506 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2006 13:13:23 -0000 On Wed, 2006-06-21 at 08:38 +0200, Guillaume Cottenceau wrote: > Hi Matthias, > > Could you just drop a line on the list about this question? > > Thanks in advance. > > ---------- Forwarded message ---------- > From: Guillaume Cottenceau > Date: Jun 17, 2006 7:22 PM > Subject: Re: GTK+ 2.10, the endgame > To: Matthias Clasen > Cc: gtk-devel-list@gnome.org > > > On 6/15/06, Matthias Clasen wrote: > > Therefore, I want to consider 2.9.3 api frozen, and take a > > Does this mean that > http://developer.gnome.org/doc/API/2.0/gtk/ix07.html (and equivalents > for gdk, pango, atk) is now a fully stable source for bindings which > want to support new features of 2.10? > > -- > Guillaume Cottenceau - http://zarb.org/~gc/ > The online documentation is still at 2.9.2. I hope to find time to update it to 2.9.4 before leaving for GUADEC tomorrow. A small number of API additions turned out to be necessary in the lowlevel printing apis after 2.9.3: gtk_enumerate_printers GTK_PRINT_CAPABILITY_CAN_GENERATE_PS GTK_PRINT_SETTINGS_OUTPUT_FILE_FORMAT GTK_PRINT_SETTINGS_OUTPUT_URI Furthermore, GTK_PRINT_SETTINGS_PRINT_TO_FILE was found to be unused and removed, together with its setter and getter. Matthias From mclasen@redhat.com Wed Jun 21 13:35:58 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id EE5983B046D for ; Wed, 21 Jun 2006 13:35:57 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25325-06 for ; Wed, 21 Jun 2006 13:35:56 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id 7ACFF3B02CE for ; Wed, 21 Jun 2006 13:35:56 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5LHZtpq012200 for ; Wed, 21 Jun 2006 13:35:55 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5LHZthC009595 for ; Wed, 21 Jun 2006 13:35:55 -0400 Received: from golem.boston.redhat.com (golem.boston.redhat.com [172.16.80.24]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id k5LHZtdH019718 for ; Wed, 21 Jun 2006 13:35:55 -0400 Subject: Looking beyond 2.10 From: Matthias Clasen To: gtk-devel-list@gnome.org Content-Type: text/plain Date: Wed, 21 Jun 2006 13:35:55 -0400 Message-Id: <1150911355.15532.100.camel@golem.boston.redhat.com> Mime-Version: 1.0 X-Mailer: Evolution 2.7.1 (2.7.1-1) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.545 tagged_above=-999 required=2 tests=[AWL=0.056, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.545 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2006 17:35:58 -0000 So, with GTK+ 2.10 on the finish line, I tried to make a quick list of things we may want to look at for 2.12, as input to GUADEC discussions. Patches almost ready to go in - libglade integration - new tooltips api Stuff that needs more work - introspection - international calendar support Stuff that we need to figure out - canvas - libsexy cherrypicking ? (Of course, bugzilla has an endless supply of feature requests and bugs that one can work on, these are just the things that came to my mind first) Matthias From hfiguiere@teaser.fr Wed Jun 21 15:04:27 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C0B713B00F6 for ; Wed, 21 Jun 2006 15:04:27 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31064-02 for ; Wed, 21 Jun 2006 15:04:19 -0400 (EDT) Received: from xandros.com (smtp1.xandros.com [209.87.238.70]) by menubar.gnome.org (Postfix) with ESMTP id 873C83B02DA for ; Wed, 21 Jun 2006 15:04:14 -0400 (EDT) Received: from [172.16.1.95] (unknown [209.87.238.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by xandros.com (Postfix) with ESMTP id 09337A030 for ; Wed, 21 Jun 2006 15:04:13 -0400 (EDT) Message-ID: <4499982C.1010004@teaser.fr> Date: Wed, 21 Jun 2006 15:04:12 -0400 From: Hubert Figuiere User-Agent: Thunderbird 1.5.0.4 (X11/20060615) MIME-Version: 1.0 To: gtk-devel-list@gnome.org Subject: Re: Looking beyond 2.10 References: <1150911355.15532.100.camel@golem.boston.redhat.com> In-Reply-To: <1150911355.15532.100.camel@golem.boston.redhat.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.542 tagged_above=-999 required=2 tests=[AWL=0.057, BAYES_00=-2.599] X-Spam-Score: -2.542 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2006 19:04:27 -0000 Matthias Clasen wrote: > Stuff that needs more work > > - introspection > - international calendar support Complete MacOS X support? I'm about to pick Qt as a toolkit for a personal project just because of that. Hub From matthias.clasen@gmail.com Wed Jun 21 18:26:02 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id A5B4E3B006C for ; Wed, 21 Jun 2006 18:26:02 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09882-05 for ; Wed, 21 Jun 2006 18:26:01 -0400 (EDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.177]) by menubar.gnome.org (Postfix) with ESMTP id 477AE3B00F8 for ; Wed, 21 Jun 2006 18:26:01 -0400 (EDT) Received: by py-out-1112.google.com with SMTP id e30so107107pya for ; Wed, 21 Jun 2006 15:26:00 -0700 (PDT) Received: by 10.35.111.14 with SMTP id o14mr363031pym; Wed, 21 Jun 2006 15:26:00 -0700 (PDT) Received: by 10.35.39.16 with HTTP; Wed, 21 Jun 2006 15:26:00 -0700 (PDT) Message-ID: Date: Wed, 21 Jun 2006 18:26:00 -0400 From: "Matthias Clasen" To: "Hubert Figuiere" Subject: Re: Looking beyond 2.10 In-Reply-To: <4499982C.1010004@teaser.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1150911355.15532.100.camel@golem.boston.redhat.com> <4499982C.1010004@teaser.fr> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.51 tagged_above=-999 required=2 tests=[AWL=0.090, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.51 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2006 22:26:02 -0000 On 6/21/06, Hubert Figuiere wrote: > Matthias Clasen wrote: > > > Stuff that needs more work > > > > - introspection > > - international calendar support > > Complete MacOS X support? Sure, if someone with access to a Mac works on it. I don't have a Mac... > I'm about to pick Qt as a toolkit for a personal project just because of > that. Good luck. Matthias From trowbrds@gmail.com Wed Jun 21 18:29:52 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 103073B0011 for ; Wed, 21 Jun 2006 18:29:52 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10124-04 for ; Wed, 21 Jun 2006 18:29:49 -0400 (EDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.185]) by menubar.gnome.org (Postfix) with ESMTP id B842D3B00E4 for ; Wed, 21 Jun 2006 18:29:48 -0400 (EDT) Received: by nf-out-0910.google.com with SMTP id h2so177759nfe for ; Wed, 21 Jun 2006 15:29:47 -0700 (PDT) Received: by 10.49.81.12 with SMTP id i12mr1011269nfl; Wed, 21 Jun 2006 15:29:47 -0700 (PDT) Received: by 10.49.36.8 with HTTP; Wed, 21 Jun 2006 15:29:47 -0700 (PDT) Message-ID: Date: Wed, 21 Jun 2006 16:29:47 -0600 From: "David Trowbridge" To: gtk-devel-list@gnome.org Subject: Re: Looking beyond 2.10 In-Reply-To: <1150911355.15532.100.camel@golem.boston.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1150911355.15532.100.camel@golem.boston.redhat.com> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.538 tagged_above=-999 required=2 tests=[AWL=0.062, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.538 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2006 22:29:52 -0000 On 6/21/06, Matthias Clasen wrote: > - libsexy cherrypicking ? The icon entry and url labels are probably robust enough (and widely useful enough) to go in. For anything else, it will require some work. -David From mclasen@redhat.com Wed Jun 21 23:10:41 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id AA4213B0172; Wed, 21 Jun 2006 23:10:41 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23030-07; Wed, 21 Jun 2006 23:10:39 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id 63BA23B0008; Wed, 21 Jun 2006 23:10:39 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5M3AclX021506; Wed, 21 Jun 2006 23:10:38 -0400 Received: from lacrosse.corp.redhat.com (lacrosse.corp.redhat.com [172.16.52.154]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5M3AcnM019751; Wed, 21 Jun 2006 23:10:38 -0400 Received: from [172.16.83.158] (vpn83-158.boston.redhat.com [172.16.83.158]) by lacrosse.corp.redhat.com (8.12.11.20060308/8.11.6) with ESMTP id k5M3AciB004961; Wed, 21 Jun 2006 23:10:38 -0400 Subject: GTK+ 2.9.4 released From: Matthias Clasen To: gnome-announce-list@gnome.org, gtk-devel-list@gnome.org, gtk-app-devel-list@gnome.org, gtk-list@gnome.org Content-Type: text/plain Organization: Red Hat Date: Wed, 21 Jun 2006 23:12:41 -0400 Message-Id: <1150945961.4457.2.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.7.3 (2.7.3-2) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.507 tagged_above=-999 required=2 tests=[AWL=0.017, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, TW_GT=0.077] X-Spam-Score: -2.507 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: gnome-hackers@gnome.org List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 03:10:42 -0000 GTK+ 2.9.4 is now available for download at: http://ftp.gnome.org/pub/gnome/sources/gtk+/2.9/ gtk+-2.9.4.tar.bz2 md5sum: c06cf2cfa66485600d90789c9e58f27c gtk+-2.9.4.tar.gz md5sum: e3fefedc7f1a89b66c71c9967168a857 This is a development release leading up to GTK+ 2.10. Notes: * This is unstable development release. There are certainly plenty of bugs remaining to be found. This release should not be used in production. * Installing this version will overwrite your existing copy of GTK+ 2.8. If you have problems, you'll need to reinstall GTK+ 2.8. * GTK+ 2.10 will be source compatible with the GTK+ 2.8 series; the new API additions in GTK+ 2.9.0 are finalized by now. * The ABI version has been bumped from 2.4.0 to 2.10.0, since the filechooser backend interface has been changed. Third-party filechooser backends need to be ported to the new interface. Other third-party modules (input methods, image loaders, etc) just need to be reinstalled in the proper location for GTK+ to find them. * Remaining issues for GTK+ 2.10 can be found with following bugzilla query: http://bugzilla.gnome.org/buglist.cgi?product=gtk%2b&target_milestone=2.10+API+Freeze&target_milestone=2.10+Freeze&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED * Bugs should be reported to http://bugzilla.gnome.org. What is GTK+ ============ GTK+ is a multi-platform toolkit for creating graphical user interfaces. Offering a complete set of widgets, GTK+ is suitable for projects ranging from small one-off tools to complete application suites. GTK+ has been designed from the ground up to support a range of languages, not only C/C++. Using GTK+ from languages such as Perl and Python (especially in combination with the Glade GUI builder) provides an effective method of rapid application development. GTK+ is free software and part of the GNU Project. However, the licensing terms for GTK+, the GNU LGPL, allow it to be used by all developers, including those developing proprietary software, without any license fees or royalties. Where to get more information about GTK+ ======================================== Information about GTK+ including links to documentation can be found at: http://www.gtk.org/ An installation guide for GTK+ 2.x is found at: http://developer.gnome.org/doc/API/2.4/gtk/gtk-building.html Common questions: http://developer.gnome.org/doc/API/2.4/gtk/gtk-question-index.html http://www.gtk.org/faq/ Overview of Changes from GTK+ 2.9.3 to 2.9.4 ============================================ * GtkPrintOperation: - UI improvements in the print dialog - Make printing work without a display connection - Replace "Print to PDF" by "Print to file" that can generate PDF or PostScript - Add a function to the low-level API to enumerate all printers * GtkNotebook tab DND has been improved * GtkProgressbar supports text in activity mode * GtkLabel allows to set the wrap mode * GtkStatusIcon supports transparency * Bugs fixed: 344850 Dragging a GtkTreeViewColumn segfaults when using certain GtkTreeViewColumnDropFunc 342458 Stock menu items without icons are broken in recent GTK+ releases. 335873 notebook DND + popup windows 337882 gtk_progress_bar_set_text() does nothing in activity mode 339456 unix print dialogue help button bug 339702 Make sure printing works without a display 341571 tabs too easily reordered 344074 New Feature: get printer list, and get default print 344743 gtk_targets_include_text() should initialize atoms 344838 Allow func to be NULL in gtk_tree_view_set_search_position_func 344891 GtkPrintOperationPreview signal defs correction 345008 Need updated cairo req 345093 print preview temp file issues 345107 Memory leak in gtk_entry_completion_finalize: User data not freed 345194 gdk_window_set_functions() docs need to be updated 345456 grid-lines property is wrongly registered and get/set. 314278 strings in gtk-update-icon-cache are not marked for translation 344707 size group with widgets in hidden container 344897 Entry completion model NULL handling should be documented 345038 gtk_print_job_set_status' status 345106 dialog button box spacings 345176 GtkIconView doc about drag and drop 345275 doc imporovements for gtk_window_move 345320 Two very similiar strings should be made equal 345321 Add meaning of "shortcut" as translator comment 320034 transparency gtkstatusicon 339592 Add print-to-postscript 344867 custom paper file could use keyfile * Updated translations (cs,de,es,fr,gl,gu,hi,ko,ta,th) A list of all bugs fixed in this release can be found at http://bugzilla.gnome.org/buglist.cgi?bug_id=344838,344743,344867,344891,345008,341571,345038,337882,345093,344707,339456,345107,345275,339702,344074,345320,345321,344897,314278,320034,344850,345194,345176,345106,335873,342458,339592,345456 Thanks to everybody who has contributed to this release, in the form of bug reports or patches: Christian Persch, John Finlay, Federico Mena Quintero, Michael Emmel, Marko Anastasov, Bastien Nocera, Carlos Garnacho, Yevgen Muntyan, Tommi Komulainen, Tim Janik, Christian Weiske, Behdad Esfahbod, Alexander Larsson, Felipe Heidrich, Hendrik Richter, Claudio Saavedra, Dan Winship, Callum McKenzie, John Palmieri, Murray Cumming, Kristian Rietveld June 21, 2006 Matthias Clasen From alexl@redhat.com Thu Jun 22 03:30:13 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id F02D73B04C8 for ; Thu, 22 Jun 2006 03:30:12 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04379-10 for ; Thu, 22 Jun 2006 03:30:11 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id 3177C3B021B for ; Thu, 22 Jun 2006 03:30:11 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5M7UAw1025719 for ; Thu, 22 Jun 2006 03:30:10 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5M7UAI5026706; Thu, 22 Jun 2006 03:30:10 -0400 Received: from [127.0.0.1] (sebastian-int.corp.redhat.com [172.16.52.221]) by devserv.devel.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5M7U90l029917; Thu, 22 Jun 2006 03:30:09 -0400 Subject: Re: Looking beyond 2.10 From: Alexander Larsson To: Matthias Clasen In-Reply-To: <1150911355.15532.100.camel@golem.boston.redhat.com> References: <1150911355.15532.100.camel@golem.boston.redhat.com> Content-Type: text/plain Date: Thu, 22 Jun 2006 09:30:09 +0200 Message-Id: <1150961409.16397.101.camel@greebo> Mime-Version: 1.0 X-Mailer: Evolution 2.7.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.588 tagged_above=-999 required=2 tests=[AWL=0.013, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.588 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 07:30:13 -0000 On Wed, 2006-06-21 at 13:35 -0400, Matthias Clasen wrote: > So, with GTK+ 2.10 on the finish line, I tried to make a quick > list of things we may want to look at for 2.12, as input to > GUADEC discussions. The EditableLable stuff would be nice to have in gtk+: http://live.gnome.org/ProjectRidley/EelEditableLabel This would mean i could drop EelEditableLabel, and i'm sure others need something like this too. For instance, GtkIconView would need it to support renaming. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl@redhat.com alla@lysator.liu.se He's a lonely hunchbacked matador on the edge. She's a radical impetuous single mother who don't take no shit from nobody. They fight crime! From mclasen@redhat.com Thu Jun 22 09:23:37 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 8880D3B0667 for ; Thu, 22 Jun 2006 09:23:37 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30015-09 for ; Thu, 22 Jun 2006 09:23:23 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id 58F4B3B03E5 for ; Thu, 22 Jun 2006 09:23:04 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5MDN3ca016505 for ; Thu, 22 Jun 2006 09:23:03 -0400 Received: from lacrosse.corp.redhat.com (lacrosse.corp.redhat.com [172.16.52.154]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5MDN3dV000789; Thu, 22 Jun 2006 09:23:03 -0400 Received: from [172.16.83.176] (vpn83-176.boston.redhat.com [172.16.83.176]) by lacrosse.corp.redhat.com (8.12.11.20060308/8.11.6) with ESMTP id k5MDN2MM012188; Thu, 22 Jun 2006 09:23:03 -0400 Subject: Re: Looking beyond 2.10 From: Matthias Clasen To: Alexander Larsson In-Reply-To: <1150961409.16397.101.camel@greebo> References: <1150911355.15532.100.camel@golem.boston.redhat.com> <1150961409.16397.101.camel@greebo> Content-Type: text/plain Organization: Red Hat Date: Thu, 22 Jun 2006 09:25:07 -0400 Message-Id: <1150982707.2966.6.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.7.3 (2.7.3-2) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.546 tagged_above=-999 required=2 tests=[AWL=0.055, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.546 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 13:23:37 -0000 On Thu, 2006-06-22 at 09:30 +0200, Alexander Larsson wrote: > On Wed, 2006-06-21 at 13:35 -0400, Matthias Clasen wrote: > > So, with GTK+ 2.10 on the finish line, I tried to make a quick > > list of things we may want to look at for 2.12, as input to > > GUADEC discussions. > > The EditableLable stuff would be nice to have in gtk+: > http://live.gnome.org/ProjectRidley/EelEditableLabel > > This would mean i could drop EelEditableLabel, and i'm sure others need > something like this too. For instance, GtkIconView would need it to > support renaming. > Not that it would not be useful, but GtkIconView uses cell renderers, and already supports editing... From alexl@redhat.com Thu Jun 22 09:33:59 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 9529C3B0748 for ; Thu, 22 Jun 2006 09:33:59 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30708-06 for ; Thu, 22 Jun 2006 09:33:54 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id B4FBD3B0559 for ; Thu, 22 Jun 2006 09:33:54 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5MDXsaJ021314 for ; Thu, 22 Jun 2006 09:33:54 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5MDXrtU004254; Thu, 22 Jun 2006 09:33:53 -0400 Received: from [127.0.0.1] (sebastian-int.corp.redhat.com [172.16.52.221]) by devserv.devel.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5MDXqt9025805; Thu, 22 Jun 2006 09:33:53 -0400 Subject: Re: Looking beyond 2.10 From: Alexander Larsson To: Matthias Clasen In-Reply-To: <1150982707.2966.6.camel@localhost.localdomain> References: <1150911355.15532.100.camel@golem.boston.redhat.com> <1150961409.16397.101.camel@greebo> <1150982707.2966.6.camel@localhost.localdomain> Content-Type: text/plain Date: Thu, 22 Jun 2006 15:33:52 +0200 Message-Id: <1150983232.16397.107.camel@greebo> Mime-Version: 1.0 X-Mailer: Evolution 2.7.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.588 tagged_above=-999 required=2 tests=[AWL=0.013, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.588 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 13:33:59 -0000 On Thu, 2006-06-22 at 09:25 -0400, Matthias Clasen wrote: > On Thu, 2006-06-22 at 09:30 +0200, Alexander Larsson wrote: > > On Wed, 2006-06-21 at 13:35 -0400, Matthias Clasen wrote: > > > So, with GTK+ 2.10 on the finish line, I tried to make a quick > > > list of things we may want to look at for 2.12, as input to > > > GUADEC discussions. > > > > The EditableLable stuff would be nice to have in gtk+: > > http://live.gnome.org/ProjectRidley/EelEditableLabel > > > > This would mean i could drop EelEditableLabel, and i'm sure others need > > something like this too. For instance, GtkIconView would need it to > > support renaming. > > > > Not that it would not be useful, but GtkIconView uses cell renderers, > and already supports editing... How does that handle labels that are several lines long? =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl@redhat.com alla@lysator.liu.se He's a war-weary moralistic waffle chef with nothing left to lose. She's an orphaned red-headed barmaid looking for love in all the wrong places. They fight crime! From mclasen@redhat.com Thu Jun 22 09:48:21 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 98DD03B04F0 for ; Thu, 22 Jun 2006 09:48:21 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31802-05 for ; Thu, 22 Jun 2006 09:48:20 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id DD2613B00DE for ; Thu, 22 Jun 2006 09:48:19 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5MDmJQS027439 for ; Thu, 22 Jun 2006 09:48:19 -0400 Received: from lacrosse.corp.redhat.com (lacrosse.corp.redhat.com [172.16.52.154]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5MDmJB6008537; Thu, 22 Jun 2006 09:48:19 -0400 Received: from [172.16.83.176] (vpn83-176.boston.redhat.com [172.16.83.176]) by lacrosse.corp.redhat.com (8.12.11.20060308/8.11.6) with ESMTP id k5MDmIjF015592; Thu, 22 Jun 2006 09:48:18 -0400 Subject: Re: Looking beyond 2.10 From: Matthias Clasen To: Alexander Larsson In-Reply-To: <1150983232.16397.107.camel@greebo> References: <1150911355.15532.100.camel@golem.boston.redhat.com> <1150961409.16397.101.camel@greebo> <1150982707.2966.6.camel@localhost.localdomain> <1150983232.16397.107.camel@greebo> Content-Type: text/plain Organization: Red Hat Date: Thu, 22 Jun 2006 09:50:23 -0400 Message-Id: <1150984223.2966.10.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.7.3 (2.7.3-2) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.546 tagged_above=-999 required=2 tests=[AWL=0.055, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.546 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 13:48:21 -0000 On Thu, 2006-06-22 at 15:33 +0200, Alexander Larsson wrote: > On Thu, 2006-06-22 at 09:25 -0400, Matthias Clasen wrote: > > On Thu, 2006-06-22 at 09:30 +0200, Alexander Larsson wrote: > > > On Wed, 2006-06-21 at 13:35 -0400, Matthias Clasen wrote: > > > > So, with GTK+ 2.10 on the finish line, I tried to make a quick > > > > list of things we may want to look at for 2.12, as input to > > > > GUADEC discussions. > > > > > > The EditableLable stuff would be nice to have in gtk+: > > > http://live.gnome.org/ProjectRidley/EelEditableLabel > > > > > > This would mean i could drop EelEditableLabel, and i'm sure others need > > > something like this too. For instance, GtkIconView would need it to > > > support renaming. > > > > > > > Not that it would not be useful, but GtkIconView uses cell renderers, > > and already supports editing... > > How does that handle labels that are several lines long? > As well as the treeview does... eventually we'll have to sit down and add multline to GtkEntry... From alexl@redhat.com Thu Jun 22 09:52:23 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 292473B081B for ; Thu, 22 Jun 2006 09:52:23 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32031-08 for ; Thu, 22 Jun 2006 09:52:21 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id 83E8E3B0811 for ; Thu, 22 Jun 2006 09:52:21 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5MDqKud029180 for ; Thu, 22 Jun 2006 09:52:21 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5MDqFg0009757; Thu, 22 Jun 2006 09:52:15 -0400 Received: from [127.0.0.1] (sebastian-int.corp.redhat.com [172.16.52.221]) by devserv.devel.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5MDqE6x027583; Thu, 22 Jun 2006 09:52:14 -0400 Subject: Re: Looking beyond 2.10 From: Alexander Larsson To: Matthias Clasen In-Reply-To: <1150984223.2966.10.camel@localhost.localdomain> References: <1150911355.15532.100.camel@golem.boston.redhat.com> <1150961409.16397.101.camel@greebo> <1150982707.2966.6.camel@localhost.localdomain> <1150983232.16397.107.camel@greebo> <1150984223.2966.10.camel@localhost.localdomain> Content-Type: text/plain Date: Thu, 22 Jun 2006 15:52:14 +0200 Message-Id: <1150984334.16397.110.camel@greebo> Mime-Version: 1.0 X-Mailer: Evolution 2.7.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.588 tagged_above=-999 required=2 tests=[AWL=0.013, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.588 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 13:52:23 -0000 On Thu, 2006-06-22 at 09:50 -0400, Matthias Clasen wrote: > On Thu, 2006-06-22 at 15:33 +0200, Alexander Larsson wrote: > > > How does that handle labels that are several lines long? > > As well as the treeview does... eventually we'll have to sit down > and add multline to GtkEntry... Thats basically what EelEditableLabel is. I'm not sure its better to combine the two into one than having a separate widget for it. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl@redhat.com alla@lysator.liu.se He's a sword-wielding Catholic gangster fleeing from a secret government programme. She's a beautiful mute snake charmer with the power to bend men's minds. They fight crime! From Bill.Haneman@Sun.COM Thu Jun 22 09:59:01 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id A04A33B06B5 for ; Thu, 22 Jun 2006 09:59:01 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32611-04 for ; Thu, 22 Jun 2006 09:58:59 -0400 (EDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by menubar.gnome.org (Postfix) with ESMTP id EC16D3B0487 for ; Thu, 22 Jun 2006 09:58:52 -0400 (EDT) Received: from phys-gadget-1 ([129.156.85.171]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k5MDwpH2016279 for ; Thu, 22 Jun 2006 07:58:52 -0600 (MDT) Received: from conversion-daemon.gadget-mail1.uk.sun.com by gadget-mail1.uk.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0J1900F01LG3TK@gadget-mail1.uk.sun.com> (original mail from Bill.Haneman@Sun.COM) for gtk-devel-list@gnome.org; Thu, 22 Jun 2006 14:58:51 +0100 (BST) Received: from [192.168.1.120] (vpn-129-150-116-130.UK.Sun.COM [129.150.116.130]) by gadget-mail1.uk.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0J1900AYWLI2KV@gadget-mail1.uk.sun.com> for gtk-devel-list@gnome.org; Thu, 22 Jun 2006 14:58:51 +0100 (BST) Date: Thu, 22 Jun 2006 15:00:03 +0100 From: Bill Haneman Subject: GtkTextBuffer serialization formats: why no "text/plain" ? To: gtk-devel-list@gnome.org Message-id: <1150984802.7100.4.camel@linux.site> MIME-version: 1.0 X-Mailer: Ximian Evolution 1.4.6.338 Content-type: text/plain Content-transfer-encoding: 7BIT X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.538 tagged_above=-999 required=2 tests=[AWL=-0.017, BAYES_00=-2.599, TW_GT=0.077, UNPARSEABLE_RELAY=0.001] X-Spam-Score: -2.538 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 13:59:01 -0000 Hi; The new serialize/deserialize API for GtkTextBuffer looks to be very useful to accessibility among other things. I am currently using it to implement AtkStreamableContent, an interface which allows objects with streamable backing data (for instance images, HTML widgets, text containers...) to advertise that fact and stream the data to remote clients such as assistive technologies. However I am somewhat surprised to see in gtk-demo's Hypertext widget that, although there's a serialization format called "application/x-gtk-rich-text", there's no "text/plain". Of course serialization via plain text would not be lossless, but why isn't there a plain text serialization available for all GtkTextBuffer instances? We certainly need it for the accessibility case - otherwise we'll have to fake one in gail, necessitating multiple code paths or at least some odd concatenation of "text/plain" if it is not among those returned by gtk_text_buffer_get_serialize_formats... regards, Bill From ebassi@gmail.com Thu Jun 22 10:02:56 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id D0CCE3B074F for ; Thu, 22 Jun 2006 10:02:56 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00339-10 for ; Thu, 22 Jun 2006 10:02:55 -0400 (EDT) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.171]) by menubar.gnome.org (Postfix) with ESMTP id CC4073B0634 for ; Thu, 22 Jun 2006 10:02:54 -0400 (EDT) Received: by ug-out-1314.google.com with SMTP id o2so482915uge for ; Thu, 22 Jun 2006 07:02:53 -0700 (PDT) Received: by 10.78.151.3 with SMTP id y3mr507751hud; Thu, 22 Jun 2006 07:02:53 -0700 (PDT) Received: from ?192.168.1.70? ( [86.136.65.180]) by mx.gmail.com with ESMTP id 8sm364730hug.2006.06.22.07.02.53; Thu, 22 Jun 2006 07:02:53 -0700 (PDT) Subject: Re: Looking beyond 2.10 From: Emmanuele Bassi To: gtk-devel-list@gnome.org In-Reply-To: <1150911355.15532.100.camel@golem.boston.redhat.com> References: <1150911355.15532.100.camel@golem.boston.redhat.com> Content-Type: text/plain Date: Thu, 22 Jun 2006 15:02:51 +0100 Message-Id: <1150984971.5346.12.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.362 tagged_above=-999 required=2 tests=[AWL=0.238, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.362 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 14:02:57 -0000 Hi; On Wed, 2006-06-21 at 13:35 -0400, Matthias Clasen wrote: > So, with GTK+ 2.10 on the finish line, I tried to make a quick > list of things we may want to look at for 2.12, as input to > GUADEC discussions. > Stuff that needs more work > > - introspection > - international calendar support - use GBookmarkFile inside GtkFileSystem and add recent files inside GtkFileChooser. > Stuff that we need to figure out > > - canvas > - libsexy cherrypicking ? - EggIconChooser. AFAIR there were issues but I can't find any pointer to those. Also, I'd like to see the thumbnailing code added to GTK, and the thumbnail helpers changed from using GConf to a lower level position in the stack. Ciao, Emmanuele. -- Emmanuele Bassi, E: ebassi@gmail.com W: http://www.emmanuelebassi.net B: http://log.emmanuelebassi.net From kris@babi-pangang.org Thu Jun 22 10:07:12 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 9474E3B07EB for ; Thu, 22 Jun 2006 10:07:12 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00887-04 for ; Thu, 22 Jun 2006 10:07:09 -0400 (EDT) Received: from nasi-goreng.babi-pangang.org (nasi-goreng.babi-pangang.org [83.166.137.20]) by menubar.gnome.org (Postfix) with ESMTP id ECDDC3B07F0 for ; Thu, 22 Jun 2006 10:07:08 -0400 (EDT) Received: by nasi-goreng.babi-pangang.org (Postfix, from userid 1000) id 5DB383DCA0; Thu, 22 Jun 2006 16:07:04 +0200 (CEST) Date: Thu, 22 Jun 2006 16:07:04 +0200 From: Kristian Rietveld To: Matthias Clasen Subject: Re: Looking beyond 2.10 Message-ID: <20060622140703.GA15275@babi-pangang.org> References: <1150911355.15532.100.camel@golem.boston.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1150911355.15532.100.camel@golem.boston.redhat.com> User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.565 tagged_above=-999 required=2 tests=[AWL=0.034, BAYES_00=-2.599] X-Spam-Score: -2.565 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 14:07:12 -0000 On Wed, Jun 21, 2006 at 01:35:55PM -0400, Matthias Clasen wrote: > Stuff that needs more work > > - introspection > - international calendar support (I want to try to do multiple row DnD in GtkTreeView for real now. But I won't promise anything :) -kris. From jnoreiko@yahoo.com Thu Jun 22 10:28:15 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id CEBD43B0110 for ; Thu, 22 Jun 2006 10:28:15 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01906-05 for ; Thu, 22 Jun 2006 10:28:15 -0400 (EDT) Received: from web32406.mail.mud.yahoo.com (web32406.mail.mud.yahoo.com [68.142.207.199]) by menubar.gnome.org (Postfix) with SMTP id DCE8B3B0251 for ; Thu, 22 Jun 2006 10:28:14 -0400 (EDT) Received: (qmail 59923 invoked by uid 60001); 22 Jun 2006 14:28:14 -0000 Message-ID: <20060622142814.59921.qmail@web32406.mail.mud.yahoo.com> Received: from [172.203.129.193] by web32406.mail.mud.yahoo.com via HTTP; Thu, 22 Jun 2006 15:28:14 BST Date: Thu, 22 Jun 2006 15:28:14 +0100 (BST) From: Joachim Noreiko Subject: Re: Looking beyond 2.10 To: gtk-devel-list@gnome.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-0.405 tagged_above=-999 required=2 tests=[AWL=-1.612, BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2, DNS_FROM_RFC_WHOIS=1.447, RCVD_IN_SORBS_SOCKS=2.159] X-Spam-Score: -0.405 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 14:28:16 -0000 > Date: Wed, 21 Jun 2006 13:35:55 -0400 > From: Matthias Clasen > Subject: Looking beyond 2.10 > So, with GTK+ 2.10 on the finish line, I tried to > make a quick > list of things we may want to look at for 2.12, as > input to > GUADEC discussions. > > (Of course, bugzilla has an endless supply of > feature requests > and bugs that one can work on, these are just the > things that > came to my mind first) > I feel like I'm talking to myself here, but please could someone look at adding a help button to the fileselector. ___________________________________________________________ Inbox full of spam? Get leading spam protection and 1GB storage with All New Yahoo! Mail. http://uk.docs.yahoo.com/nowyoucan.html From tristan.van.berkom@gmail.com Thu Jun 22 13:10:30 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id A0DBC3B0690 for ; Thu, 22 Jun 2006 13:10:30 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12156-06 for ; Thu, 22 Jun 2006 13:10:28 -0400 (EDT) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.225]) by menubar.gnome.org (Postfix) with ESMTP id 215163B0137 for ; Thu, 22 Jun 2006 13:10:28 -0400 (EDT) Received: by wr-out-0506.google.com with SMTP id i12so437125wra for ; Thu, 22 Jun 2006 10:10:27 -0700 (PDT) Received: by 10.54.153.18 with SMTP id a18mr2404093wre; Thu, 22 Jun 2006 10:10:27 -0700 (PDT) Received: from ?66.48.170.242? ( [66.48.170.242]) by mx.gmail.com with ESMTP id 7sm1704382wrl.2006.06.22.10.10.22; Thu, 22 Jun 2006 10:10:27 -0700 (PDT) Message-ID: <449AD300.3030809@gnome.org> Date: Thu, 22 Jun 2006 13:27:28 -0400 User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mclasen@redhat.com Subject: Re: Looking beyond 2.10 References: <1150911355.15532.100.camel@golem.boston.redhat.com> <1150984971.5346.12.camel@localhost> In-Reply-To: <1150984971.5346.12.camel@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit From: Tristan Van Berkom X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.216 tagged_above=-999 required=2 tests=[AWL=0.384, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.216 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 17:10:30 -0000 Emmanuele Bassi wrote: >Hi; > >On Wed, 2006-06-21 at 13:35 -0400, Matthias Clasen wrote: > > >>So, with GTK+ 2.10 on the finish line, I tried to make a quick >>list of things we may want to look at for 2.12, as input to >>GUADEC discussions. >> >> Heh, unfortunately I wont be at GAUDEC to discuss any of this (which I am sure would be a great experience), so I'll do my best from the mailing lists and irc to tag along :) In light of the new Gtk Builder code getting in, I would like to propose that we depricate UIManager completely in favour of the Gtk Builder and provide a unified front for the creation of GObjects parsed from ui descriptions (or whatever the new "glade file" is to be called). My proposals to address issues of UI merging and handling of GtkActions are described in detail in these to emails: http://mail.gnome.org/archives/gtk-devel-list/2006-May/msg00157.html http://mail.gnome.org/archives/gtk-devel-list/2006-May/msg00166.html Please let me know your thoughts on the proposition and design, if accepted; I am sure I can get all this "ui merging/action subscription" stuff working properly inside of one month... hopefully leaving time enough for it to mature before 2.12. Cheers, -Tristan From sven@gimp.org Thu Jun 22 14:23:14 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C09883B062A for ; Thu, 22 Jun 2006 14:23:14 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16777-05 for ; Thu, 22 Jun 2006 14:23:11 -0400 (EDT) Received: from buzzloop.caiaq.de (buzzloop.caiaq.de [212.112.241.133]) by menubar.gnome.org (Postfix) with ESMTP id 26D1A3B05BF for ; Thu, 22 Jun 2006 14:23:08 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by buzzloop.caiaq.de (Postfix) with ESMTP id 194427F402E; Thu, 22 Jun 2006 20:23:10 +0200 (CEST) Received: from buzzloop.caiaq.de ([127.0.0.1]) by localhost (buzzloop [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11007-03; Thu, 22 Jun 2006 20:23:09 +0200 (CEST) Received: from [192.168.3.158] (i577B6734.versanet.de [87.123.103.52]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by buzzloop.caiaq.de (Postfix) with ESMTP id A11AD7F4024; Thu, 22 Jun 2006 20:23:09 +0200 (CEST) Subject: Re: Looking beyond 2.10 From: Sven Neumann To: Joachim Noreiko In-Reply-To: <20060622142814.59921.qmail@web32406.mail.mud.yahoo.com> References: <20060622142814.59921.qmail@web32406.mail.mud.yahoo.com> Content-Type: text/plain Date: Thu, 22 Jun 2006 20:22:49 +0200 Message-Id: <1151000569.12681.22.camel@bender> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.692 tagged_above=-999 required=2 tests=[AWL=0.907, BAYES_00=-2.599] X-Spam-Score: -1.692 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 18:23:15 -0000 Hi, On Thu, 2006-06-22 at 15:28 +0100, Joachim Noreiko wrote: > I feel like I'm talking to myself here, but please > could someone look at adding a help button to the fileselector. GIMP has done that for quite a while already, so there's nothing that would keep an application from adding a Help button to the file-chooser. What's the point of adding one by default? By default it won't be connected to anything useful and what good is a help button that does nothing when the user clicks it? Sven From murrayc@murrayc.com Thu Jun 22 14:45:17 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 2C2CB3B0649 for ; Thu, 22 Jun 2006 14:45:17 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18110-06 for ; Thu, 22 Jun 2006 14:45:13 -0400 (EDT) Received: from swarthymail-a1.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by menubar.gnome.org (Postfix) with ESMTP id A79253B083A for ; Thu, 22 Jun 2006 14:45:12 -0400 (EDT) Received: from noname (p5497EA12.dip.t-dialin.net [84.151.234.18]) by swarthymail-a1.dreamhost.com (Postfix) with ESMTP id 71BF690FA6; Thu, 22 Jun 2006 11:45:00 -0700 (PDT) Subject: Re: GTK+ 2.10, the endgame From: Murray Cumming To: Emmanuele Bassi In-Reply-To: <1150502750.2668.12.camel@localhost> References: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> <1150390229.17566.191.camel@cacharro.xalalinux.org> <1150391737.3187.33.camel@dhcp83-98.boston.redhat.com> <1150447930.5806.4.camel@localhost.localdomain> <1150502750.2668.12.camel@localhost> Content-Type: text/plain Date: Thu, 22 Jun 2006 20:44:54 +0200 Message-Id: <1151001894.5804.33.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.477 tagged_above=-999 required=2 tests=[AWL=0.122, BAYES_00=-2.599] X-Spam-Score: -2.477 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 18:45:17 -0000 On Sat, 2006-06-17 at 01:05 +0100, Emmanuele Bassi wrote: > Hi Murray, > > On Fri, 2006-06-16 at 10:52 +0200, Murray Cumming wrote: > > I'm also concerned about the recent files stuff. Do we now have > > UIManager integration of that? > > No, and I am to blame because I had less time to spend on fixing this > issue. > > Mostly, I've been stuck on how to implement an action for both the menu > and toolbars using the same tag. In the meantime, a nice and clean way > to integrate the GtkRecentChooserMenu inside a GtkUIManager is to > subclass GtkAction into a custom action that automatically adds a recent > chooser menu to the menu item it creates, and use a placeholder in the > UI definition (most applications using EggRecentViewUIManager already > have that placeholder present). > > A working example is available here: > > http://www.gnome.org/~ebassi/test-uimanager.c > > The action code itself is one hundred lines long and can easily be > hidden inside an helper file; it's approximately how GtkRecentAction > would be implemented, anyway. I hereby give permission to do whatever > you want to do with it. > > I understand that it's sub-optimal, and hopefully this should really go > away once there's an action inside GTK. Do you feel that the existing API might need to be changed to add this to a future version of GTK+? For instance, would it need need existing classes to implement new interfaces, or add new signals? -- Murray Cumming murrayc@murrayc.com www.murrayc.com www.openismus.com From ebassi@gmail.com Thu Jun 22 15:19:39 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id F26233B077F for ; Thu, 22 Jun 2006 15:19:38 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20426-04 for ; Thu, 22 Jun 2006 15:19:35 -0400 (EDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.186]) by menubar.gnome.org (Postfix) with ESMTP id 2A7653B062A for ; Thu, 22 Jun 2006 15:19:35 -0400 (EDT) Received: by nf-out-0910.google.com with SMTP id h2so304101nfe for ; Thu, 22 Jun 2006 12:19:34 -0700 (PDT) Received: by 10.48.242.3 with SMTP id p3mr1697803nfh; Thu, 22 Jun 2006 12:19:34 -0700 (PDT) Received: from ?192.168.1.70? ( [86.136.65.180]) by mx.gmail.com with ESMTP id z73sm2097413nfb.2006.06.22.12.19.33; Thu, 22 Jun 2006 12:19:33 -0700 (PDT) Subject: Re: GTK+ 2.10, the endgame From: Emmanuele Bassi To: Murray Cumming In-Reply-To: <1151001894.5804.33.camel@localhost.localdomain> References: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> <1150390229.17566.191.camel@cacharro.xalalinux.org> <1150391737.3187.33.camel@dhcp83-98.boston.redhat.com> <1150447930.5806.4.camel@localhost.localdomain> <1150502750.2668.12.camel@localhost> <1151001894.5804.33.camel@localhost.localdomain> Content-Type: text/plain Date: Thu, 22 Jun 2006 20:19:32 +0100 Message-Id: <1151003972.5346.29.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.371 tagged_above=-999 required=2 tests=[AWL=0.229, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.371 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 19:19:39 -0000 Hi Murray; On Thu, 2006-06-22 at 20:44 +0200, Murray Cumming wrote: > > The action code itself is one hundred lines long and can easily be > > hidden inside an helper file; it's approximately how GtkRecentAction > > would be implemented, anyway. I hereby give permission to do whatever > > you want to do with it. > > > > I understand that it's sub-optimal, and hopefully this should really go > > away once there's an action inside GTK. > > Do you feel that the existing API might need to be changed to add this > to a future version of GTK+? For instance, would it need need existing > classes to implement new interfaces, or add new signals? The point is: I don't know. :-) The currently unresolved issue is that I can't find a way to use this UI definition:

which is the "right" way to offer a submenu and a menu inside a toolbar item. The only case where I know for sure would require adding API is the case where you want an inlined recent files list - as it would require the ability to create a list of menu items instead of a single widget with the same GtkAction. At this point, I'd like a UIManager author/guru to step in and see if I'm doing something wrong. The bug is #338843 [1]. +++ http://bugzilla.gnome.org/show_bug.cgi?id=338843 -- Emmanuele Bassi, E: ebassi@gmail.com W: http://www.emmanuelebassi.net B: http://log.emmanuelebassi.net From jnoreiko@yahoo.com Thu Jun 22 17:19:57 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 48DC33B07DC for ; Thu, 22 Jun 2006 17:19:57 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27254-05 for ; Thu, 22 Jun 2006 17:19:56 -0400 (EDT) Received: from web32404.mail.mud.yahoo.com (web32404.mail.mud.yahoo.com [68.142.207.197]) by menubar.gnome.org (Postfix) with SMTP id 6C40C3B0601 for ; Thu, 22 Jun 2006 17:19:56 -0400 (EDT) Received: (qmail 9697 invoked by uid 60001); 22 Jun 2006 21:19:55 -0000 Message-ID: <20060622211955.9695.qmail@web32404.mail.mud.yahoo.com> Received: from [172.216.98.138] by web32404.mail.mud.yahoo.com via HTTP; Thu, 22 Jun 2006 22:19:55 BST Date: Thu, 22 Jun 2006 22:19:55 +0100 (BST) From: Joachim Noreiko Subject: Re: Looking beyond 2.10 To: Sven Neumann In-Reply-To: <1151000569.12681.22.camel@bender> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.693 tagged_above=-999 required=2 tests=[AWL=-0.741, BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2, DNS_FROM_RFC_WHOIS=1.447] X-Spam-Score: -1.693 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 21:19:57 -0000 --- Sven Neumann wrote: > Hi, > > On Thu, 2006-06-22 at 15:28 +0100, Joachim Noreiko > wrote: > > > I feel like I'm talking to myself here, but please > > could someone look at adding a help button to the > fileselector. > > GIMP has done that for quite a while already, so > there's nothing that > would keep an application from adding a Help button > to the file-chooser. > What's the point of adding one by default? By > default it won't be > connected to anything useful and what good is a help > button that does > nothing when the user clicks it? The documentation for the fileselector has been in the GNOME Desktop User Guide since 2.14. I'm sure I posted on this list when I wrote it. ___________________________________________________________ All new Yahoo! Mail "The new Interface is stunning in its simplicity and ease of use." - PC Magazine http://uk.docs.yahoo.com/nowyoucan.html From scott@asofyet.org Thu Jun 22 22:52:08 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 046A73B05F9 for ; Thu, 22 Jun 2006 22:52:08 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09189-02 for ; Thu, 22 Jun 2006 22:52:06 -0400 (EDT) Received: from looneymail-a2.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by menubar.gnome.org (Postfix) with ESMTP id 39B703B071C for ; Thu, 22 Jun 2006 22:52:06 -0400 (EDT) Received: from [192.168.0.100] (unknown [74.131.115.107]) by looneymail-a2.dreamhost.com (Postfix) with ESMTP id 2C0F016E8CD for ; Thu, 22 Jun 2006 19:52:05 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v750) In-Reply-To: <20060622211955.9695.qmail@web32404.mail.mud.yahoo.com> References: <20060622211955.9695.qmail@web32404.mail.mud.yahoo.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: muppet Subject: Re: Looking beyond 2.10 Date: Thu, 22 Jun 2006 22:51:48 -0400 To: GTK+ development mailing list X-Mailer: Apple Mail (2.750) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.558 tagged_above=-999 required=2 tests=[AWL=0.041, BAYES_00=-2.599] X-Spam-Score: -2.558 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2006 02:52:08 -0000 On Jun 22, 2006, at 5:19 PM, Joachim Noreiko wrote: > > --- Sven Neumann wrote: > >> GIMP has done that for quite a while already, so there's nothing >> that would keep an application from adding a Help button to the >> file-chooser. What's the point of adding one by default? By >> default it won't be connected to anything useful and what good is >> a help button that does nothing when the user clicks it? > > The documentation for the fileselector has been in the GNOME > Desktop User Guide since 2.14. I'm sure I posted on this list when > I wrote it. That doesn't do much good for gtk+ environments that don't involve GNOME. -- Jolt is my co-pilot. -- Slogan on a giant paper airplane hung in Lobby 7 at MIT. http://hacks.mit.edu/ From magnusbe@algonet.se Fri Jun 23 05:33:19 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 0D0353B0591 for ; Fri, 23 Jun 2006 05:33:19 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31880-05 for ; Fri, 23 Jun 2006 05:33:17 -0400 (EDT) Received: from pne-smtpout2-sn2.hy.skanova.net (pne-smtpout2-sn2.hy.skanova.net [81.228.8.164]) by menubar.gnome.org (Postfix) with ESMTP id 294473B041F for ; Fri, 23 Jun 2006 05:33:16 -0400 (EDT) Received: from feathers (83.252.145.175) by pne-smtpout2-sn2.hy.skanova.net (7.2.072.1) (authenticated as u73906364) id 449A811D0002C366 for gtk-devel-list@gnome.org; Fri, 23 Jun 2006 11:33:15 +0200 Date: Fri, 23 Jun 2006 12:31:05 +0200 From: Magnus Bergman To: GTK+ devel list Subject: Problems making loaders for header-less images Message-ID: <20060623123105.1589fed8@feathers> X-Mailer: Sylpheed-Claws 2.3.0 (GTK+ 2.8.16; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.522 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, TW_GD=0.077] X-Spam-Score: -2.522 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2006 09:33:19 -0000 I've made a couple of gdk-pixbuf loaders for formats that cannot be finger printed using a pattern, because they totaly lack some kind of header or that information is located at the end of the file. This has causes me the following problems: * If one loader handles several (similar) formats that cannot be distinguished from each other by looking at the first bytes. Then gdk-pixbuf uses other means to distinguish between them (extension or mime-type) but the information about what the match was based on is unavailable to loader (or am I missing something). Can this be solved is some way (except by making a different loader for each variant)? Example: There is an image format called pi1 (the most common format on the Atari ST). It consists of one word telling about the resolution, the palette and a copy of the screen memory. A variant of the format is called pc1 and has the only difference that the screen memory image is compressed. It is easy to distinguish between them using the extension or by looking at the file size (pi1 has a fixed size of 32066 bytes while pc1 is always smaller). * If a loader doesn't provide any fingerprinting pattern gdk-pixbuf causes a segfault at runtime then trying to load a picture in any format. Is the loader required to provide at least one pattern or is this a bug? * If the only thing that is known about the format is that it starts with one or more zeros, then gdk-pixbuf-query-loaders will refuse to register the loader because it considers the pattern to be empty. This could be avoided to checking the length of the mask field instead to the prefix field. A bug? From gcottenc@gmail.com Fri Jun 23 07:57:54 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id DA1E43B0678 for ; Fri, 23 Jun 2006 07:57:54 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08025-10 for ; Fri, 23 Jun 2006 07:57:53 -0400 (EDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.192]) by menubar.gnome.org (Postfix) with ESMTP id 7D8543B01A4 for ; Fri, 23 Jun 2006 07:57:53 -0400 (EDT) Received: by wx-out-0102.google.com with SMTP id s6so466104wxc for ; Fri, 23 Jun 2006 04:57:53 -0700 (PDT) Received: by 10.70.103.17 with SMTP id a17mr4494204wxc; Fri, 23 Jun 2006 04:57:52 -0700 (PDT) Received: by 10.70.46.6 with HTTP; Fri, 23 Jun 2006 04:57:52 -0700 (PDT) Message-ID: Date: Fri, 23 Jun 2006 13:57:52 +0200 From: "Guillaume Cottenceau" To: "Matthias Clasen" Subject: Re: Fwd: GTK+ 2.10, the endgame In-Reply-To: <1150895599.15532.80.camel@golem.boston.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> <1150895599.15532.80.camel@golem.boston.redhat.com> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.564 tagged_above=-999 required=2 tests=[AWL=0.036, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.564 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2006 11:57:55 -0000 Hi Matthias, > The online documentation is still at 2.9.2. I hope to find time > to update it to 2.9.4 before leaving for GUADEC tomorrow. Please warn us when the online API documentation regarding new symbols is fully freezed for 2.10 so that we can start working on adding the new symbols in bindings. Thanks! -- Guillaume Cottenceau - http://zarb.org/~gc/ From hfiguiere@teaser.fr Fri Jun 23 11:50:42 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 100083B04A7 for ; Fri, 23 Jun 2006 11:50:42 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21632-05 for ; Fri, 23 Jun 2006 11:50:39 -0400 (EDT) Received: from xandros.com (smtp1.xandros.com [209.87.238.70]) by menubar.gnome.org (Postfix) with ESMTP id 83AC63B0907 for ; Fri, 23 Jun 2006 11:50:33 -0400 (EDT) Received: from [172.16.1.95] (unknown [209.87.238.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by xandros.com (Postfix) with ESMTP id 6A6F223033 for ; Fri, 23 Jun 2006 11:50:32 -0400 (EDT) Message-ID: <449C0DC7.60502@teaser.fr> Date: Fri, 23 Jun 2006 11:50:31 -0400 From: Hubert Figuiere User-Agent: Thunderbird 1.5.0.4 (X11/20060615) MIME-Version: 1.0 To: gtk-devel-list@gnome.org Subject: Re: Looking beyond 2.10 References: <20060622142814.59921.qmail@web32406.mail.mud.yahoo.com> <1151000569.12681.22.camel@bender> In-Reply-To: <1151000569.12681.22.camel@bender> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.544 tagged_above=-999 required=2 tests=[AWL=0.055, BAYES_00=-2.599] X-Spam-Score: -2.544 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2006 15:50:42 -0000 Sven Neumann wrote: > GIMP has done that for quite a while already, so there's nothing that > would keep an application from adding a Help button to the file-chooser. > What's the point of adding one by default? By default it won't be > connected to anything useful and what good is a help button that does > nothing when the user clicks it? Why not putting it in only if the signal is connected ? (a signal like "help_requested"). Hub From gjc@inescporto.pt Fri Jun 23 18:23:20 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 9B8D83B0847 for ; Fri, 23 Jun 2006 18:23:20 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08741-04 for ; Fri, 23 Jun 2006 18:23:19 -0400 (EDT) Received: from animal.inescn.pt (animal.inescn.pt [194.117.24.9]) by menubar.gnome.org (Postfix) with ESMTP id AC38C3B0971 for ; Fri, 23 Jun 2006 18:23:18 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by animal.inescn.pt (8.13.6/8.13.6/7) with ESMTP id k5NMNG4Z018417; Fri, 23 Jun 2006 23:23:17 +0100 (WEST) Received: from pong.inescporto.pt (pong.inescn.pt [194.117.26.74]) by animal.inescn.pt (8.13.6/8.13.6/5) with ESMTP id k5NMN5ql018402; Fri, 23 Jun 2006 23:23:05 +0100 (WEST) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by pong.inescporto.pt (Postfix) with ESMTP id 31501155721; Fri, 23 Jun 2006 23:19:37 +0100 (WEST) Subject: Re: Looking beyond 2.10 From: "Gustavo J. A. M. Carneiro" To: Matthias Clasen In-Reply-To: <1150911355.15532.100.camel@golem.boston.redhat.com> References: <1150911355.15532.100.camel@golem.boston.redhat.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-2prtuoBhNnmmz3lcPkNU" Date: Fri, 23 Jun 2006 23:22:59 +0100 Message-Id: <1151101379.5189.5.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 X-Virus-Scanned: by amavisd-new at inescporto.pt X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.428 tagged_above=-999 required=2 tests=[AWL=0.038, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.428 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2006 22:23:20 -0000 --=-2prtuoBhNnmmz3lcPkNU Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Qua, 2006-06-21 =C3=A0s 13:35 -0400, Matthias Clasen escreveu: > So, with GTK+ 2.10 on the finish line, I tried to make a quick > list of things we may want to look at for 2.12, as input to > GUADEC discussions. >=20 > Patches almost ready to go in >=20 > - libglade integration > - new tooltips api >=20 >=20 > Stuff that needs more work >=20 > - introspection I'm willing to do some work in introspection. However, if you say it needs more work then I think you should identify precisely what work needs to be done. I could try guessing, but that usually leads to patches sitting in bugzilla for whole release cycles (e.g. #313268). Regards. --=20 Gustavo J. A. M. Carneiro The universe is always one step beyond logic --=-2prtuoBhNnmmz3lcPkNU Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta =?ISO-8859-1?Q?=E9?= uma parte de mensagem assinada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQBEnGnD2XoHyMdS6TARAk0JAJ95rFWntIs1xJ0hPTYMBwXdg26PgACeJo0x DrkoftT0jbf/hSym/poi0Uo= =WVRK -----END PGP SIGNATURE----- --=-2prtuoBhNnmmz3lcPkNU-- From jnoreiko@yahoo.com Sat Jun 24 03:40:19 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id EBA9B3B00F5 for ; Sat, 24 Jun 2006 03:40:18 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30651-07 for ; Sat, 24 Jun 2006 03:40:17 -0400 (EDT) Received: from web32401.mail.mud.yahoo.com (web32401.mail.mud.yahoo.com [68.142.207.194]) by menubar.gnome.org (Postfix) with SMTP id BD1E03B0194 for ; Sat, 24 Jun 2006 03:40:16 -0400 (EDT) Received: (qmail 229 invoked by uid 60001); 24 Jun 2006 07:40:15 -0000 Message-ID: <20060624074015.227.qmail@web32401.mail.mud.yahoo.com> Received: from [172.212.40.3] by web32401.mail.mud.yahoo.com via HTTP; Sat, 24 Jun 2006 08:40:15 BST Date: Sat, 24 Jun 2006 08:40:15 +0100 (BST) From: Joachim Noreiko Subject: Re: Looking beyond 2.10 To: gtk-devel-list@gnome.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.681 tagged_above=-999 required=2 tests=[AWL=-0.729, BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2, DNS_FROM_RFC_WHOIS=1.447] X-Spam-Score: -1.681 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2006 07:40:19 -0000 Message: 6 Date: Thu, 22 Jun 2006 22:51:48 -0400 From: muppet Subject: Re: Looking beyond 2.10 > The documentation for the fileselector has been in the GNOME > Desktop User Guide since 2.14. I'm sure I posted on this list when > I wrote it. That doesn't do much good for gtk+ environments that don't involve GNOME. -------------- Then figure out some way for it to detect whether it's on GNOME or not, maybe? Dialog boxes used in GNOME required help buttons, especially ones with as many features as the fileselector. Please could somebody look into this? I put a lot of work into writing the docs, and that's not a huge amount of use until it's linked to. ___________________________________________________________ Inbox full of spam? Get leading spam protection and 1GB storage with All New Yahoo! Mail. http://uk.docs.yahoo.com/nowyoucan.html From macfreesoft@free.fr Sat Jun 24 05:56:35 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C31133B02D5 for ; Sat, 24 Jun 2006 05:56:35 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05338-06 for ; Sat, 24 Jun 2006 05:56:33 -0400 (EDT) Received: from smtp010.mail.ukl.yahoo.com (smtp010.mail.ukl.yahoo.com [217.12.11.79]) by menubar.gnome.org (Postfix) with SMTP id 3D48E3B02B2 for ; Sat, 24 Jun 2006 05:56:33 -0400 (EDT) Received: (qmail 6982 invoked from network); 24 Jun 2006 09:56:32 -0000 Received: from unknown (HELO ?192.168.1.10?) (a?gillaizeau@217.66.126.141 with plain) by smtp010.mail.ukl.yahoo.com with SMTP; 24 Jun 2006 09:56:32 -0000 Message-ID: <449D0C4E.504@free.fr> Date: Sat, 24 Jun 2006 11:56:30 +0200 From: Aymeric GILLAIZEAU User-Agent: Thunderbird 1.5 (Macintosh/20051201) MIME-Version: 1.0 To: Easy B Subject: Gtk+.framework snapshot Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.033 tagged_above=-999 required=2 tests=[BAYES_05=-1.11, TW_GT=0.077] X-Spam-Score: -1.033 X-Spam-Level: X-Mailman-Approved-At: Sat, 24 Jun 2006 06:24:14 -0400 Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2006 09:56:36 -0000 > Hi guys > > Well I wasn't that happy with the result I got from the mono scripts > so I pretty much rewrote them. I now install everything into one > framework. I still don't have libtiff and jpeg support though. How is > the best way to make the gtk configure look for libtiff 3.8.2? I saw > that it looks for 3.4. Do I have to patch configure? > > Anyway, who's interested can give my installer a try. It installs the > framework into /Library/Frameworks and Gtk-Demo into /Applications. I > managed to compile one of my small apps by setting PKG_CONFIG_PATH to > /Library/Frameworks/Gtk+.framework/Libraries/pkgconfig/ and > ./configure, make. > > To make an application bundles I use this script: > http://www.easyb.ch/files/bundleApp.sh > > The Installer you can download here: > http://www.easyb.ch/files/Gtk%2B-2.9.1%20Framework%20snapshot.pkg.zip > > Cheers, > Ezra. Why to not use the already built Frameworks used by Scribus ? Instead of having many times the same things, it is present once and used by anyone. The problem with OpenSource is that everyone makes his cooking in his place without never taking consideration in the work others has already done. It could save time, also use less space on the drive, and so save room. http://www.scribus.net/index.php?name=Sections&req=viewarticle&artid=3&page=1 > ome support libraries, which should be moved to /Library/Frameworks : > Qt.framework > Freetype.framework > Fontconfig2.framework > libart.framework > libexpat.framework > libjpeg.framework > liblcms.framework > libpng.framework > libtiff.framework ___________________________________________________________________________ Yahoo! Mail rinvente le mail ! Dcouvrez le nouveau Yahoo! Mail et son interface rvolutionnaire. http://fr.mail.yahoo.com From alex@halogen-dg.com Sat Jun 24 08:41:32 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 92B9B3B013A for ; Sat, 24 Jun 2006 08:41:32 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13862-09 for ; Sat, 24 Jun 2006 08:41:31 -0400 (EDT) Received: from appserver.halogen.kharkov.ua (appserver.halogen.kharkov.ua [217.144.70.65]) by menubar.gnome.org (Postfix) with ESMTP id 256C33B00FB for ; Sat, 24 Jun 2006 08:41:31 -0400 (EDT) Received: (qmail 29949 invoked from network); 24 Jun 2006 15:41:32 +0300 Received: from dom.koval.kharkov.ua (217.144.70.182) by alex.halogen.kharkov.ua with AES256-SHA encrypted SMTP; 24 Jun 2006 15:41:32 +0300 Date: Sat, 24 Jun 2006 15:45:30 +0300 (EEST) From: alex@halogen-dg.com X-X-Sender: alex@dom.koval.kharkov.ua To: gtk-devel-list@gnome.org Subject: gtk file open dialog usability. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-0.858 tagged_above=-999 required=2 tests=[AWL=-0.709, BAYES_05=-1.11, NO_REAL_NAME=0.961] X-Spam-Score: -0.858 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2006 12:41:32 -0000 Anyone except me also disappointed by it? Any way how we can have old file open dialog back? I really find it very frustating and explained why, with some images here: http://www.halogen-dg.com/alex/file_selection_dialog/GtkFileOpenBadUsability -- Alex V. Koval http://www.halogen-dg.com/ http://www.zwarehouse.org/ From gnome-gtk-devel-list@m.gmane.org Sat Jun 24 08:49:58 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id F15263B00A8 for ; Sat, 24 Jun 2006 08:49:57 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14302-05 for ; Sat, 24 Jun 2006 08:49:55 -0400 (EDT) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by menubar.gnome.org (Postfix) with ESMTP id 402703B00FB for ; Sat, 24 Jun 2006 08:49:55 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Fu7a8-0004yS-Mc for gtk-devel-list@gnome.org; Sat, 24 Jun 2006 14:49:48 +0200 Received: from 84.52.165.220 ([84.52.165.220]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 24 Jun 2006 14:49:48 +0200 Received: from jernej.listsonly by 84.52.165.220 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 24 Jun 2006 14:49:48 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gtk-devel-list@gnome.org From: Jernej =?utf-7?Q?Simon+AQ0-i+AQ0-?= Subject: Re: gtk file open dialog usability. Date: Sat, 24 Jun 2006 14:49:37 +0200 Lines: 9 Message-ID: <10umqokepyu8y.10vhe4alqj04.dlg@40tude.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset="utf-7" Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 84.52.165.220 User-Agent: 40tude_Dialog/2.0.15.84 (cfc06cd9.460.419) X-Face: BOCQpf4)pfW>6Ya?'@oBT]=LBF; <6`_r[6pwqLggP!RG:*D)^Fz; O(I'n(FwJ{]5lo>g.H. _,Z:_`nLsfz]]8V'&9OmX)o-bXd?(P|CO=@5}[y\0rH9!AN&Qt:GXC(r!1}$q@@C]x`](7+#C]WRzw L|0W}vdFR/b@AFWIw~ X-Ultimate-Answer: 42 Sender: news X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.008 tagged_above=-999 required=2 tests=[AWL=0.016, BAYES_00=-2.599, FROM_EXCESS_QP=0, RCVD_NUMERIC_HELO=1.5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, TW_GT=0.077] X-Spam-Score: -1.008 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2006 12:49:58 -0000 On Sat, 24 Jun 2006 15:45:30 +-0300 (EEST), alex@halogen-dg.com wrote: > Anyone except me also disappointed by it? Search the archives, you're far from being the only one. -- < Jernej Simon+AQ0-i+AQ0- >< http://deepthought.ena.si/ > < Contact address: >< jernej simoncic at isg si > From alex@halogen-dg.com Sat Jun 24 09:01:55 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id F3A283B00A8 for ; Sat, 24 Jun 2006 09:01:54 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15013-06 for ; Sat, 24 Jun 2006 09:01:54 -0400 (EDT) Received: from appserver.halogen.kharkov.ua (appserver.halogen.kharkov.ua [217.144.70.65]) by menubar.gnome.org (Postfix) with ESMTP id 388713B0490 for ; Sat, 24 Jun 2006 09:01:53 -0400 (EDT) Received: (qmail 32296 invoked from network); 24 Jun 2006 16:01:54 +0300 Received: from dom.koval.kharkov.ua (217.144.70.182) by alex.halogen.kharkov.ua with AES256-SHA encrypted SMTP; 24 Jun 2006 16:01:54 +0300 Date: Sat, 24 Jun 2006 16:05:52 +0300 (EEST) From: alex@halogen-dg.com X-X-Sender: alex@dom.koval.kharkov.ua To: gtk-devel-list@gnome.org Subject: Re: gtk file open dialog usability. In-Reply-To: <10umqokepyu8y.10vhe4alqj04.dlg@40tude.net> Message-ID: References: <10umqokepyu8y.10vhe4alqj04.dlg@40tude.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.533 tagged_above=-999 required=2 tests=[AWL=0.028, BAYES_00=-2.599, NO_REAL_NAME=0.961, TW_GT=0.077] X-Spam-Score: -1.533 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2006 13:01:55 -0000 Hi Jernej On Sat, 24 Jun 2006, Jernej Simon+AQ0-i+AQ0- wrote: > On Sat, 24 Jun 2006 15:45:30 +-0300 (EEST), alex@halogen-dg.com wrote: > >> Anyone except me also disappointed by it? I am happy that people noticed that, too. The question is what can we do to fix this? My feeling is that at least 2 things could be done: 1. Make automatic selection of file optional (like its being done in KDE, in grey) 2. Do not display additional file open dialog when I *already* typed file name. > > Search the archives, you're far from being the only one. > BTW, before doing this post I've tried to search for "file dialog usability GTK". To my regret mail.gnome.org mailman search is not working ("The requested URL /mailman/search was not found on this server."),so I searched google a little, did not found any good results and posted here... Althrough this search returns more results: http://www.google.com.ua/search?q=gtk+file+open+usability&start=0&ie=utf-8&oe=utf-8&client=firefox-a&rls=org.mozilla:en-US:official Alex From g.tagliaretti@gmail.com Sat Jun 24 09:53:34 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 2C1C83B02E0 for ; Sat, 24 Jun 2006 09:53:34 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17447-04 for ; Sat, 24 Jun 2006 09:53:33 -0400 (EDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.178]) by menubar.gnome.org (Postfix) with ESMTP id 054D13B0228 for ; Sat, 24 Jun 2006 09:53:32 -0400 (EDT) Received: by py-out-1112.google.com with SMTP id i49so1099450pyi for ; Sat, 24 Jun 2006 06:52:59 -0700 (PDT) Received: by 10.35.99.14 with SMTP id b14mr3541165pym; Sat, 24 Jun 2006 06:52:56 -0700 (PDT) Received: by 10.35.132.18 with HTTP; Sat, 24 Jun 2006 06:52:56 -0700 (PDT) Message-ID: <35bf41160606240652s3da0fe6brd3915cd84c601114@mail.gmail.com> Date: Sat, 24 Jun 2006 15:52:56 +0200 From: "Gian Mario Tagliaretti" To: "alex@halogen-dg.com" Subject: Re: gtk file open dialog usability. In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.257 tagged_above=-999 required=2 tests=[AWL=0.066, BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2, SPF_PASS=-0.001, TW_GT=0.077] X-Spam-Score: -2.257 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2006 13:53:34 -0000 2006/6/24, alex@halogen-dg.com : > > Anyone except me also disappointed by it? > Any way how we can have old file open dialog back? code not complain :) > I really find it very frustating and explained > why, with some images here: > http://www.halogen-dg.com/alex/file_selection_dialog/GtkFileOpenBadUsability are you using gtk+ 2.9.x ? ciao -- Gian Mario Tagliaretti http://www.parafernalia.org/pygtk/ http://pygstdocs.berlios.de From timj@gtk.org Sat Jun 24 13:36:49 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 6B4403B006E; Sat, 24 Jun 2006 13:36:49 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27591-06; Sat, 24 Jun 2006 13:36:45 -0400 (EDT) Received: from holken.mikan.net (holken.mikan.net [83.145.56.183]) by menubar.gnome.org (Postfix) with ESMTP id C28AD3B06ED; Sat, 24 Jun 2006 13:36:44 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by holken.mikan.net (Postfix) with ESMTP id 59BF93352A5; Sat, 24 Jun 2006 19:36:26 +0200 (CEST) Received: from holken.mikan.net ([127.0.0.1]) by localhost (holken.mikan.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27952-05; Sat, 24 Jun 2006 19:36:22 +0200 (CEST) Received: from birnet.org (c135173.adsl.hansenet.de [213.39.135.173]) by holken.mikan.net (Postfix) with ESMTP id E12711844A; Sat, 24 Jun 2006 19:36:21 +0200 (CEST) Received: from master.birnet.private (localhost.localdomain [127.0.0.1]) by birnet.org (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k5OHaLjt023300 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 24 Jun 2006 19:36:21 +0200 Received: (from timj@localhost) by master.birnet.private (8.13.4/8.13.4/Submit) id k5OHZcXs023295; Sat, 24 Jun 2006 19:35:38 +0200 Date: Sat, 24 Jun 2006 19:35:38 +0200 (CEST) From: Tim Janik X-X-Sender: timj@master.birnet.private To: Gtk+ Developers Subject: Re: GTK+ meeting at GUADEC (Re: GTK+ 2.10, the endgame) In-Reply-To: Message-ID: References: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at holken.mikan.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.637 tagged_above=-999 required=2 tests=[AWL=-0.662, BAYES_05=-1.11, FORGED_RCVD_HELO=0.135] X-Spam-Score: -1.637 X-Spam-Level: X-Mailman-Approved-At: Sat, 24 Jun 2006 13:47:30 -0400 Cc: Federico Mena Quintero , Jonathan Blandford , Tim Janik , sandmann@daimi.au.dk, cworth@cworth.org, Komulainen Tommi , Alex Larsson , Michael Natterer , Kristian Rietveld , Matthias Clasen , Richard Hult , johan@gnome.org, michael meeks X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2006 17:36:49 -0000 On Thu, 15 Jun 2006, Tim Janik wrote: > the plan for that was to send out en email next friday/saturday (i.e > right at the guadec start) to figure/suggest dates suitable for > everyone to attend. we have gotten a room for the Gtk+ meeting now. it's on Sunday the 25th from 16:00-18:00 in the blue room (at the conference facility, second floor). --- ciaoTJ From torriem@chem.byu.edu Sun Jun 25 01:08:26 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id EA0E73B0079 for ; Sun, 25 Jun 2006 01:08:25 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17289-04 for ; Sun, 25 Jun 2006 01:08:22 -0400 (EDT) Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [63.240.77.83]) by menubar.gnome.org (Postfix) with ESMTP id ACB1F3B00A6 for ; Sun, 25 Jun 2006 01:08:22 -0400 (EDT) Received: from enterprise.local.lan (c-24-2-75-5.hsd1.ut.comcast.net[24.2.75.5]) by comcast.net (sccrmhc13) with ESMTP id <2006062505073001300me7qte>; Sun, 25 Jun 2006 05:07:31 +0000 Received: from enterprise.local.lan (enterprise.local.lan [127.0.0.1]) by enterprise.local.lan (8.13.1/8.12.8) with ESMTP id k5P57TFs002388 for ; Sat, 24 Jun 2006 23:07:29 -0600 Received: (from torriem@localhost) by enterprise.local.lan (8.13.1/8.13.1/Submit) id k5P57T1Z002387 for gtk-devel-list@gnome.org; Sat, 24 Jun 2006 23:07:29 -0600 X-Authentication-Warning: enterprise.local.lan: torriem set sender to torriem@chem.byu.edu using -f Subject: Re: Looking beyond 2.10 From: Michael Torrie To: gtk-devel-list@gnome.org In-Reply-To: References: <1150911355.15532.100.camel@golem.boston.redhat.com> <4499982C.1010004@teaser.fr> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Sat, 24 Jun 2006 23:07:29 -0600 Message-Id: <1151212049.32440.11.camel@enterprise.local.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-7) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.377 tagged_above=-999 required=2 tests=[AWL=0.010, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, TW_GT=0.077] X-Spam-Score: -2.377 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jun 2006 05:08:26 -0000 On Wed, 2006-06-21 at 18:26 -0400, Matthias Clasen wrote: > > I'm about to pick Qt as a toolkit for a personal project just because of > > that. > > Good luck. I was in the same boat as Hubert. I also ended up picking Qt. Although I like GTK much better, Qt was the best choice given the circumstances. I have not regretted it. But, as soon as GTK is fully supported on OS X, I will abandon Qt entirely, as GTK is cleaner, a little easier to work with, and, ironically, has better C++ bindings than Qt. > > Matthias > _______________________________________________ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-devel-list > From torriem@chem.byu.edu Sun Jun 25 01:21:50 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 36FD43B01F4 for ; Sun, 25 Jun 2006 01:21:50 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18141-02 for ; Sun, 25 Jun 2006 01:21:47 -0400 (EDT) Received: from sccrmhc14.comcast.net (sccrmhc14.comcast.net [204.127.200.84]) by menubar.gnome.org (Postfix) with ESMTP id DD6353B02BD for ; Sun, 25 Jun 2006 01:21:46 -0400 (EDT) Received: from enterprise.local.lan (c-24-2-75-5.hsd1.ut.comcast.net[24.2.75.5]) by comcast.net (sccrmhc14) with ESMTP id <2006062505211801400apa3je>; Sun, 25 Jun 2006 05:21:19 +0000 Received: from enterprise.local.lan (enterprise.local.lan [127.0.0.1]) by enterprise.local.lan (8.13.1/8.12.8) with ESMTP id k5P5LHWa002930; Sat, 24 Jun 2006 23:21:17 -0600 Received: (from torriem@localhost) by enterprise.local.lan (8.13.1/8.13.1/Submit) id k5P5LH4T002929; Sat, 24 Jun 2006 23:21:17 -0600 X-Authentication-Warning: enterprise.local.lan: torriem set sender to torriem@chem.byu.edu using -f Subject: Re: gtk file open dialog usability. From: Michael Torrie To: Gian Mario Tagliaretti In-Reply-To: <35bf41160606240652s3da0fe6brd3915cd84c601114@mail.gmail.com> References: <35bf41160606240652s3da0fe6brd3915cd84c601114@mail.gmail.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Sat, 24 Jun 2006 23:21:16 -0600 Message-Id: <1151212877.32440.24.camel@enterprise.local.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-7) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.378 tagged_above=-999 required=2 tests=[AWL=0.009, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, TW_GT=0.077] X-Spam-Score: -2.378 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jun 2006 05:21:50 -0000 On Sat, 2006-06-24 at 15:52 +0200, Gian Mario Tagliaretti wrote: > 2006/6/24, alex@halogen-dg.com : > > > > Anyone except me also disappointed by it? > > Any way how we can have old file open dialog back? > > code not complain :) BS. Before anyone can code anything, especially in the framework of GTK, the design has to be worked out. You can't just willy-nilly code up some pseudo-compatible widget. The problem is that every time this is discussed there is never any consensus on what the problems are, why they are problems, and how to fix them. And without this, we cannot convince developers to do anything about the problem. Now having said that, if someone wants to prototype a better widget (one that is API compatible with the current one), maybe that would jump- start the process. Myself, I fear that inertia guarantees we're stuck with this bad design for the duration. > > > I really find it very frustating and explained > > why, with some images here: > > http://www.halogen-dg.com/alex/file_selection_dialog/GtkFileOpenBadUsability > > are you using gtk+ 2.9.x ? > > ciao From the introduction of 2396: This document updates and merges "Uniform Resource Locators" [RFC1738] and "Relative Uniform Resource Locators" [RFC1808] in order to define a single, generic syntax for all URI. It excludes those portions of RFC 1738 that defined the specific syntax of individual URL schemes ... Seems you missed the second sentence. That's why 2396 is not obsoleting 1738 in a formal sense, it only update a part of 1738 and this part doesn't include the definition of the FILE scheme. > from a usability standpoint, i really enjoy not having to type 3 /s in a row > (even though konqi does let you do that too) It's a completely different problem, you should even be able to enter /usr/local and have the software expand/remap to a valid URL. I don't use Konqueror but I'm pretty sure Netscape does this, the goal is that once entered the user is exposed to a valid URL. This should also include escaping of reserved or forbiden characters, the goal is to provide something correct for selection or drag and drop as well as teaching the user. Daniel -- Daniel Veillard | Red Hat Network http://redhat.com/products/network/ veillard@redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From my quick look at the RFC (1459), IRC should be able to support SJIS, UTF-8 and most of the Latin encodings -- the control stream is ASCII. But there is no indication of the encoding in use, making it necessary to use some OOB information to set the right encoding. Nor is there any indication of the language, making selection of an appropriate Han glyph set rather difficult. Pretty primitive protocol. I guess there are sufficient per-channel conventions to resolves these issues. > You may well be well right that we should have worked on making > GdkFont still work; it's certainly a bit of a API hole that there > isn't a conventional character-by-character text drawing API > available. If this is a reasonable course, then perhaps the right idea is to create a new function that returns an Xft font for use by the rendering routines; that way legacy applications would continue to see only GDK_FONT_FONT and GDK_FONT_FONTSET but minor source modifications could switch applications to Xft fonts instead. That would make porting existing Gtk+ apps to use Xft would require few changes rather than a wholesale conversion to Pango. > But considering that we are releasing this weekend, it's not something > we can go back and revisit at this point. > > (While adding a 3rd type of font may seem like a small API compatible, > change, it's actually something that can easily crash applications > that aren't expecting it.) Adding new APIs after the release that preserve source and binary compatibility for existing applications would probably be a better way than whacking gdk_font_load to return a new kind of object; the key is to require applications call a new function to get the new kind of gdk_font object. Keith Packard XFree86 Core Team Compaq Cambridge Research Lab From mardy@users.sourceforge.net Thu Jun 1 07:04:29 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 633423B0C7E for ; Thu, 1 Jun 2006 07:04:29 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28962-04 for ; Thu, 1 Jun 2006 07:04:28 -0400 (EDT) Received: from smtp010.mail.ukl.yahoo.com (smtp010.mail.ukl.yahoo.com [217.12.11.79]) by menubar.gnome.org (Postfix) with SMTP id 690073B013F for ; Thu, 1 Jun 2006 07:04:27 -0400 (EDT) Received: (qmail 61490 invoked from network); 1 Jun 2006 11:04:26 -0000 Received: from unknown (HELO pupilla) (mardy78@151.42.226.237 with login) by smtp010.mail.ukl.yahoo.com with SMTP; 1 Jun 2006 11:04:26 -0000 Received: by pupilla (Postfix, from userid 1000) id 038336B7FF; Thu, 1 Jun 2006 13:03:17 +0200 (CEST) Date: Thu, 1 Jun 2006 13:03:17 +0200 From: Alberto Mardegan To: gtk-devel-list@gnome.org Message-ID: <20060601110317.GA23802@pupilla> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Accept-Language: it,ia,en,bg,es,fr User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.599 tagged_above=-999 required=2 tests=[BAYES_00=-2.599] X-Spam-Score: -2.599 X-Spam-Level: Subject: Histogram widget X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2006 11:04:29 -0000 Hi all! I'm going to write a widget for displaying histograms. Would it be elegant/smart/useful if it were to fetch the data from a GtkTreeModel, or would it be an unneeded complexity and just some GArrays are better? I'm thinking of a GtkTreeModel, in which every row is a histogram bar; hence we would/could have a double field for the value, a string field for the label in the X axis, maybe a GdkColor for the color and whatever can come to mind. Many thanks in advance to all those who will share their thoughts on the matter. -- Saluti, Mardy http://www.interlingua.com ___________________________________ Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB http://mail.yahoo.it From matthias.clasen@gmail.com Thu Jun 1 09:35:39 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 44D6D3B0213 for ; Thu, 1 Jun 2006 09:35:39 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06492-04 for ; Thu, 1 Jun 2006 09:35:37 -0400 (EDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.190]) by menubar.gnome.org (Postfix) with ESMTP id 2B1463B019C for ; Thu, 1 Jun 2006 09:35:37 -0400 (EDT) Received: by nf-out-0910.google.com with SMTP id l37so564726nfc for ; Thu, 01 Jun 2006 06:35:36 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=AXg4pkieJhFwK/fsPTG5BVq6Sv29H8f6t8wbUeiehWS8QFuJL4sEqqu5dTplyA7vdRrz50uICadI8ZT1y2rp+BasRLmOBacUSSXY1blUEAIWfvb1udC+bqhsXFVhdU6V4+2wZCjIuaczx07TxLq1x+v9zHm4YPkA8kydW+5SycA= Received: by 10.48.31.10 with SMTP id e10mr779574nfe; Thu, 01 Jun 2006 06:33:48 -0700 (PDT) Received: by 10.48.215.7 with HTTP; Thu, 1 Jun 2006 06:33:48 -0700 (PDT) Message-ID: Date: Thu, 1 Jun 2006 09:33:48 -0400 From: "Matthias Clasen" To: "Kristian Rietveld" In-Reply-To: <20060531200823.GA7846@babi-pangang.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20060531200823.GA7846@babi-pangang.org> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.742 tagged_above=-999 required=2 tests=[AWL=-0.700, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.558, SPF_PASS=-0.001] X-Spam-Score: -1.742 X-Spam-Level: Cc: gtk-devel-list@gnome.org, timj@imendio.com Subject: Re: Tooltips progress X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2006 13:35:39 -0000 > Attached is some sample code using the new API. Opinions, comments, > suggestions are appreciated. > I don't remember too much of the original proposal, so I'll just go by what I see in the examples... What is the relation between the tooltip-markup and has-tooltip properties ? Is has-tooltip automatically set when setting tooltip-markup ? Or do you only need to set has-tooltip if you want to connect to query-tooltip ? Is the tooltip window available as a property too ? (The example uses a dedicated setter for it). The example doesn't show tooltips constructed using the old tooltips api, but I assume those will continue to work as before, right ? Using x == -1 to indicate a keyboard-triggered tooltip looks a bit odd to me; how about adding a boolean parameter for this ? Regarding dedicated treeview api, I think we can do without it (at least initially), if we have a good example in the docs. Though lots of people will forget the selection_changed thing for keyboard tooltips... Could you enhance your demo with an example of text view tooltips on a tag ? Matthias From jean.brefort@normalesup.org Thu Jun 1 09:58:21 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 479CD3B0171 for ; Thu, 1 Jun 2006 09:58:03 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08512-08 for ; Thu, 1 Jun 2006 09:58:01 -0400 (EDT) Received: from smtp4-g19.free.fr (smtp4-g19.free.fr [212.27.42.30]) by menubar.gnome.org (Postfix) with ESMTP id 84A533B0CBB for ; Thu, 1 Jun 2006 09:57:52 -0400 (EDT) Received: from che21-1-82-239-125-56.fbx.proxad.net (che21-1-82-239-125-56.fbx.proxad.net [82.239.125.56]) by smtp4-g19.free.fr (Postfix) with ESMTP id DE3EA54C0D; Thu, 1 Jun 2006 15:57:50 +0200 (CEST) From: Jean =?ISO-8859-1?Q?Br=E9fort?= To: Alberto Mardegan In-Reply-To: <20060601110317.GA23802@pupilla> References: <20060601110317.GA23802@pupilla> Content-Type: text/plain; charset=utf-8 Date: Thu, 01 Jun 2006 16:00:49 +0200 Message-Id: <1149170449.11316.1.camel@athlon.brefort.fr> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.884 tagged_above=-999 required=2 tests=[AWL=-0.354, BAYES_00=-2.599, SPF_NEUTRAL=1.069] X-Spam-Score: -1.884 X-Spam-Level: Cc: gtk-devel-list@gnome.org Subject: Re: Histogram widget X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2006 13:58:21 -0000 Le jeudi 01 juin 2006 13:03 +0200, Alberto Mardegan a crit : > Hi all! > I'm going to write a widget for displaying histograms. Would it be > elegant/smart/useful if it were to fetch the data from a GtkTreeModel, > or would it be an unneeded complexity and just some GArrays are better? > > I'm thinking of a GtkTreeModel, in which every row is a histogram bar; > hence we would/could have a double field for the value, a string field > for the label in the X axis, maybe a GdkColor for the color and whatever > can come to mind. > > Many thanks in advance to all those who will share their thoughts on the > matter. Do you want histograms or column charts? Anyway both already exist in goffice and we have the GOGraphWidget widget to display a large variety of 2D charts. Regards, Jean Brfort From mitch@gimp.org Thu Jun 1 10:37:41 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 9C8673B0253 for ; Thu, 1 Jun 2006 10:37:41 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12026-06 for ; Thu, 1 Jun 2006 10:37:40 -0400 (EDT) Received: from mitch.gimp.org (p549C9506.dip0.t-ipconnect.de [84.156.149.6]) by menubar.gnome.org (Postfix) with ESMTP id 630D53B0171 for ; Thu, 1 Jun 2006 10:37:40 -0400 (EDT) Received: from mitch by mitch.gimp.org with local (Exim 3.36 #1 (Debian)) id 1FloKa-0005tI-00; Thu, 01 Jun 2006 16:39:24 +0200 From: Michael Natterer To: Kristian Rietveld In-Reply-To: <20060531200823.GA7846@babi-pangang.org> References: <20060531200823.GA7846@babi-pangang.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Thu, 01 Jun 2006 16:39:24 +0200 Message-Id: <1149172764.5721.13.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-0.468 tagged_above=-999 required=2 tests=[AWL=-1.996, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, RCVD_IN_NJABL_DUL=1.946, RCVD_IN_SORBS_DUL=2.046] X-Spam-Score: -0.468 X-Spam-Level: Cc: gtk-devel-list@gnome.org, timj@imendio.com Subject: Re: Tooltips progress X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2006 14:37:41 -0000 On Wed, 2006-05-31 at 22:08 +0200, Kristian Rietveld wrote: > Currently, we are using the following query-tooltips signal: > > gboolean (*query_tooltip) (GtkWidget *widget, > gint x, > gint y, > GtkTooltip *tooltip); > > But if a user sets a custom using gtk_widget_set_custom_window(), we don't > have to pass a GtkTooltip around. So currently I just set the tooltip > field to NULL, so the user knows he has to use his own custom tooltip > window (and we assume he has a reference to that). Is this okay or do > we want to change this? We could also move the _set_custom_window() > functions into GtkTooltip for example. I would very much appreciate if the GtkTooltip object also kept track of the custom window. IMHO it makes no sense to handle this differently. gtk_tooltip_set_markup() vs. gtk_tooltip_set_window() simply feels much better than the asymmetry in gtk_tooltip_set_markup() vs. gtk_widget_set_tooltip_window() The current approach even limits the new tooltip system's use cases, since you have to set the custom window *outside* the callback. There is no way to decide *in* the callback if a standard tooltip is sufficient, or if a custom window is needed. Another problem is the assymetry in getting the relevant data to the callback. With markup, the GtkTooltip can be queried for the markup, if it's a custom window, you have to get it to the callback somehow. In your example code it's passed as user_data, but user_data is often not available since it's needed for other things, so you have to add a "GtkWidget *tooltip_window" to the "other thing". If "other thing" is e.g. the application toplevel window, which of the sub-widget's tooltips should it keep? All of them? People will in many cases end up attaching the tooltip window to the widget. I also fail to see why the "has-tooltip" property has to be set to TRUE, even tho a tooltip window was set on the widget. ciao, --mitch From islewind@gmail.com Thu Jun 1 11:16:53 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id CCF0F3B027D for ; Thu, 1 Jun 2006 11:16:53 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15167-10 for ; Thu, 1 Jun 2006 11:16:52 -0400 (EDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.181]) by menubar.gnome.org (Postfix) with ESMTP id EBDF73B02A2 for ; Thu, 1 Jun 2006 11:16:51 -0400 (EDT) Received: by py-out-1112.google.com with SMTP id x31so492875pye for ; Thu, 01 Jun 2006 08:16:51 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=TJcxirCpCUc11Q5e90yGryvZPvt6/4y9oixknOJbU9D0ul2vMJTRqtCSsnJU4SxRLn9lAKaOyN+GZ5nbxOOcf0T99ZPfjnqzOA3KseyOVQ4Ap+A8c67skU0CG6t40az7MwaWe4KCKIFXgrpOCN10KzuNVCisW4dtldpMgxlx5bQ= Received: by 10.35.36.13 with SMTP id o13mr1010511pyj; Thu, 01 Jun 2006 08:16:51 -0700 (PDT) Received: by 10.35.10.17 with HTTP; Thu, 1 Jun 2006 08:16:50 -0700 (PDT) Message-ID: <7bf6f2dc0606010816q15d512aejc30a6c93bc165e6@mail.gmail.com> Date: Thu, 1 Jun 2006 17:16:50 +0200 From: "=?ISO-8859-1?Q?=D8yvind_Kol=E5s?=" Sender: islewind@gmail.com To: "=?ISO-8859-1?Q?Carlos_Eduardo_Rodrigues_Di=F3genes?=" In-Reply-To: <1149104973.27709.4.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <1149104973.27709.4.camel@localhost.localdomain> X-Google-Sender-Auth: aee248fb7aae0f83 X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.571 tagged_above=-999 required=2 tests=[AWL=0.029, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.571 X-Spam-Level: Cc: gtk-devel-list@gnome.org Subject: Re: Color space transformations in GTK X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2006 15:16:54 -0000 On 5/31/06, Carlos Eduardo Rodrigues Di=F3genes = wrote: > Hi, > > There is any plan to add color spaces conversions in GTK+ (GDK or > Gdk-Pixbuf)? If the answear is no, why not? Pixel format conversions is not a small piece of code and the needed pixel formats varies from scenario to scenario. Most programs will not need such a large general infrastructure and the ones that really need it would probably not be satisfied with a simpler solution. What functionality is it you miss that you think fits into a GUI toolkit? (color management is a seperate issue to color space(pixel format) conversions according to my interpretation of your question). /=D8yvind K. --=20 =ABThe future is already here. It's just not very evenly distributed=BB -- William Gibson http://pippin.gimp.org/ http://ffii.org/ From timj@gtk.org Thu Jun 1 11:17:09 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 565CF3B0DC9 for ; Thu, 1 Jun 2006 11:17:09 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15377-03 for ; Thu, 1 Jun 2006 11:17:02 -0400 (EDT) Received: from webmail.hansenet.de (mail01.hansenet.de [213.191.73.61]) by menubar.gnome.org (Postfix) with ESMTP id 8AFEE3B0DB5 for ; Thu, 1 Jun 2006 11:17:00 -0400 (EDT) Received: from birnet.org (213.39.195.111) by webmail.hansenet.de (7.2.059) id 447D3FB2000502B1; Thu, 1 Jun 2006 17:16:59 +0200 Received: from master.birnet.private (localhost [127.0.0.1]) by birnet.org (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k51FGvIU003186 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 1 Jun 2006 17:16:57 +0200 Received: (from timj@localhost) by master.birnet.private (8.13.4/8.13.4/Submit) id k51FGpl3003183; Thu, 1 Jun 2006 17:16:51 +0200 Date: Thu, 1 Jun 2006 17:16:51 +0200 (CEST) From: Tim Janik X-X-Sender: timj@master.birnet.private To: Kristian Rietveld In-Reply-To: <20060531183045.GA7564@babi-pangang.org> Message-ID: References: <20060314132538.GA3526@babi-pangang.org> <443B4A8A.8000302@imendio.com> <20060425103017.GA15762@babi-pangang.org> <20060531183045.GA7564@babi-pangang.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.431 tagged_above=-999 required=2 tests=[AWL=0.168, BAYES_00=-2.599] X-Spam-Score: -2.431 X-Spam-Level: Cc: Gtk+ Developers , Soeren Sandmann Subject: Re: Callback based tooltips (Re: New tooltips API, continued) X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2006 15:17:10 -0000 On Wed, 31 May 2006, Kristian Rietveld wrote: > On Tue, Apr 25, 2006 at 03:08:12PM +0200, Soeren Sandmann wrote: >> I once wrote down how tooltips should behave: > > I mostly like the behaviour you described below. > >> - Tooltips are too intrusive. The text should be smaller, and not sure if this has been raised already... the font size of the tooltips should be exactly as large as the default font size (module tooltip markup of course) to avoid reducing usability of the tooltips in contrast to normal text (labels). >> they should to the right of the cursor, and a little below >> the cursor's center. --- ciaoTJ From timj@gtk.org Thu Jun 1 12:12:43 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id E5C0F3B0171 for ; Thu, 1 Jun 2006 12:12:42 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19272-05 for ; Thu, 1 Jun 2006 12:12:40 -0400 (EDT) Received: from webmail.hansenet.de (mail03.hansenet.de [213.191.73.10]) by menubar.gnome.org (Postfix) with ESMTP id 9C9433B015C for ; Thu, 1 Jun 2006 12:12:39 -0400 (EDT) Received: from birnet.org (213.39.195.111) by webmail.hansenet.de (7.2.059) id 447C08450012767E; Thu, 1 Jun 2006 18:12:37 +0200 Received: from master.birnet.private (localhost [127.0.0.1]) by birnet.org (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k51GCZTL005312 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 1 Jun 2006 18:12:35 +0200 Received: (from timj@localhost) by master.birnet.private (8.13.4/8.13.4/Submit) id k51GCY4h005311; Thu, 1 Jun 2006 18:12:34 +0200 Date: Thu, 1 Jun 2006 18:12:34 +0200 (CEST) From: Tim Janik X-X-Sender: timj@master.birnet.private To: Kristian Rietveld In-Reply-To: <20060531200823.GA7846@babi-pangang.org> Message-ID: References: <20060531200823.GA7846@babi-pangang.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.434 tagged_above=-999 required=2 tests=[AWL=0.165, BAYES_00=-2.599] X-Spam-Score: -2.434 X-Spam-Level: Cc: Gtk+ Developers , Matthias Clasen Subject: Re: Tooltips progress X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2006 16:12:43 -0000 On Wed, 31 May 2006, Kristian Rietveld wrote: > Last week I've been working on the tooltips implementation, using the > callback-based approach/interface discussed earlier on this mailing list. > The basics are working already including keyboard support and custom > windows. Before I can finalize a patch for reviewal, I have some comments > and questions. > > > In a follow up to his original mail, Tim is talking about adding the > following function: > > gdk_display_force_query_display (GdkDisplay *); > > I am not sure if this really belongs in GdkDisplay. Currently I have a: > > gtk_widget_force_query_tooltip (GtkWidget *widget); > > which works just fine for forcably updating a tooltip, in both keyboard > and mouse mode. I guess most people will usually know which widget's > tooltip to update. Opinions? yes, in most cases the widget will be known, but not in all. the trivial example is changing per-display settings like ::display-tooltips = off or the timeout. also, since we support nesting/overlaying of widgets. even the display might not be clear, which is why i actually proposed: void gtk_display_force_tooltip_query (GdkDisplay*); /* display may be NULL */ /* because of nesting/overlapping tooltips, widget is not always known * http://mail.gnome.org/archives/gtk-devel-list/2006-April/msg00030.html */ but you have a point here, since in most cases the widget will indeed be known, it'll be most convenient to also provide: void gtk_widget_force_query_tooltip (GtkWidget *widget) { gtk_display_force_tooltip_query (gtk_widget_get_display (widget)); } > Currently, we are using the following query-tooltips signal: > > gboolean (*query_tooltip) (GtkWidget *widget, > gint x, > gint y, > GtkTooltip *tooltip); > > But if a user sets a custom using gtk_widget_set_custom_window(), we don't > have to pass a GtkTooltip around. So currently I just set the tooltip > field to NULL, so the user knows he has to use his own custom tooltip > window (and we assume he has a reference to that). my original proposal http://mail.gnome.org/archives/gtk-devel-list/2006-April/msg00010.html included: GtkWindow* gtk_widget_get_tooltip_window (GtkWidget *widget); so the user doesn't need to duplicate tracking of this window. > Is this okay or do > we want to change this? We could also move the _set_custom_window() > functions into GtkTooltip for example. no, i intentionally didn't put it there. the reasoning for this was: - the setter should go along with a getter - the user should get at the custom window but *not* the tooltips window used by gtk. the latter is violated with a getter on GtkTooltip. > Implementing GtkTreeView tooltips in your application is now pretty easy, > just set up a query_tooltip callback and call gtk_tree_view_get_path_at_pos() > with the coordinates which are provided to you (but if x == -1, the keyboard > mode is enabled and then you should really call gtk_tree_view_get_cursor()). using x==-1&&y==-1 for keyboard mode was a bit of an aftermath patchup to my original proposal. Matthias Clasen now pointed out: > Using x == -1 to indicate a keyboard-triggered tooltip looks a bit > odd to me; how about adding a boolean parameter for this ? and i thnk he is right. another indication that we'd not want (-1,-1) is that you already talk about querying the cursor yourself. so it's probably better to adapt the signal to: gboolean (*query_tooltip) (GtkWidget *widget, gint x, gint y, gboolean keyboard_tip, GtkTooltip *tooltip); and preserve the x,y position. > Would this be sufficient, or do we want to add some special API for supporting > tooltips in the tree view, like having GtkTreeView implement the query > tooltip callback and have tooltip-markup properties on cell renderers. > Personally I think implementing the query-tooltip yourself is easy enough > for people to do and also really flexible, so there's no need for more API. i'd say let's first nail the basic tooltip API. GtkWidget already comes with a default handler. we can still add treeview convenience API later on if that is required. (and for that, i think it'd be easiest to forward the query_tooltip() signal to signals on the columns and cell renderers). > Since we re-query for a tooltip on mouse motion, I was wondering what we > should do in keyboard mode if a key is pressed in, for example, GtkTreeView. > A key press there might change the cursor and we might want to update the > tooltip contents. Do we want stock GTK+ to take care of this, or should the > user do this himself? (For example by calling gtk_widget_force_tooltip_query > from the GtkTreeSelection::changed callback). i think i'd handle key press events like mouse motion and scroll events, i.e. re-query. that eases things on the user side and is consistent with movement. (the basic idea behind my proposal was that gtk+ takes care of the required granularity whenever possible, so gtk_display_force_tooltip_query() needs to allmost never be used). > thanks, > > -kris. > --- ciaoTJ From timj@gtk.org Thu Jun 1 12:21:35 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 96AD53B0E27 for ; Thu, 1 Jun 2006 12:21:35 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19725-05 for ; Thu, 1 Jun 2006 12:21:33 -0400 (EDT) Received: from webmail.hansenet.de (mail02.hansenet.de [213.191.73.62]) by menubar.gnome.org (Postfix) with ESMTP id AE4893B0115 for ; Thu, 1 Jun 2006 12:21:33 -0400 (EDT) Received: from birnet.org (213.39.195.111) by webmail.hansenet.de (7.2.059) id 447C276B001342DD; Thu, 1 Jun 2006 18:21:31 +0200 Received: from master.birnet.private (localhost [127.0.0.1]) by birnet.org (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k51GLTmR005587 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 1 Jun 2006 18:21:29 +0200 Received: (from timj@localhost) by master.birnet.private (8.13.4/8.13.4/Submit) id k51GLTBN005586; Thu, 1 Jun 2006 18:21:29 +0200 Date: Thu, 1 Jun 2006 18:21:29 +0200 (CEST) From: Tim Janik X-X-Sender: timj@master.birnet.private To: Matthias Clasen In-Reply-To: Message-ID: References: <20060531200823.GA7846@babi-pangang.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.436 tagged_above=-999 required=2 tests=[AWL=0.163, BAYES_00=-2.599] X-Spam-Score: -2.436 X-Spam-Level: Cc: Gtk+ Developers , Kristian Rietveld Subject: Re: Tooltips progress X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2006 16:21:35 -0000 On Thu, 1 Jun 2006, Matthias Clasen wrote: >> Attached is some sample code using the new API. Opinions, comments, >> suggestions are appreciated. >> > > I don't remember too much of the original proposal, so I'll just go > by what I see in the examples... > > What is the relation between the tooltip-markup and has-tooltip > properties ? setting ::tooltip-markup should automatically set ::has-tooltip=TRUE; as mentioned in the original proposal: http://mail.gnome.org/archives/gtk-devel-list/2006-April/msg00010.html > Is has-tooltip automatically set when setting tooltip-markup ? > Or do you only need to set has-tooltip if you want to connect to > query-tooltip ? the idea behind ::has-tooltip is to reduce the number of required signal emissions to figure a tooltip. e.g. by adding a PRIVATE_GTK_* flag that indicates if the ::query-tooltips() emission is neccessary. maybe it'd helpt to rename that property to ::can-tooltip? > Is the tooltip window available as a property too ? (The example uses > a dedicated setter for it). i don't quite see a need for that. the custom window is only useful if you implement your own ::query-tooltip() handler anyway and there you could simply use the getter. (if you want to argue consistency with other things settable/gettable on widgets though, then yes, you have a point for also exporting it as a property) > The example doesn't show tooltips constructed using the old tooltips > api, but I assume those will continue to work as before, right ? that was the plan, i.e. you'd basically just do: void gtk_tooltips_set_tip (GtkTooltips *tooltips, GtkWidget *widget, const gchar *tip_text, const gchar *tip_private) { g_object_set (widget, "tooltip-markup", tip_text, NULL); } > Matthias --- ciaoTJ From timj@gtk.org Thu Jun 1 12:37:26 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 777F13B0DE5 for ; Thu, 1 Jun 2006 12:37:26 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20777-08 for ; Thu, 1 Jun 2006 12:37:17 -0400 (EDT) Received: from webmail.hansenet.de (mail03.hansenet.de [213.191.73.10]) by menubar.gnome.org (Postfix) with ESMTP id DD7453B0E15 for ; Thu, 1 Jun 2006 12:37:16 -0400 (EDT) Received: from birnet.org (213.39.195.111) by webmail.hansenet.de (7.2.059) id 447C084500128D01; Thu, 1 Jun 2006 18:36:53 +0200 Received: from master.birnet.private (localhost [127.0.0.1]) by birnet.org (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k51Gaj8T006024 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 1 Jun 2006 18:36:45 +0200 Received: (from timj@localhost) by master.birnet.private (8.13.4/8.13.4/Submit) id k51Gaj0d006023; Thu, 1 Jun 2006 18:36:45 +0200 Date: Thu, 1 Jun 2006 18:36:45 +0200 (CEST) From: Tim Janik X-X-Sender: timj@master.birnet.private To: Michael Natterer In-Reply-To: <1149172764.5721.13.camel@localhost> Message-ID: References: <20060531200823.GA7846@babi-pangang.org> <1149172764.5721.13.camel@localhost> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.439 tagged_above=-999 required=2 tests=[AWL=0.160, BAYES_00=-2.599] X-Spam-Score: -2.439 X-Spam-Level: Cc: Gtk+ Developers , Kristian Rietveld Subject: Re: Tooltips progress X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2006 16:37:26 -0000 On Thu, 1 Jun 2006, Michael Natterer wrote: > On Wed, 2006-05-31 at 22:08 +0200, Kristian Rietveld wrote: > >> Currently, we are using the following query-tooltips signal: >> >> gboolean (*query_tooltip) (GtkWidget *widget, >> gint x, >> gint y, >> GtkTooltip *tooltip); >> >> But if a user sets a custom using gtk_widget_set_custom_window(), we don't >> have to pass a GtkTooltip around. So currently I just set the tooltip >> field to NULL, so the user knows he has to use his own custom tooltip >> window (and we assume he has a reference to that). Is this okay or do >> we want to change this? We could also move the _set_custom_window() >> functions into GtkTooltip for example. > > I would very much appreciate if the GtkTooltip object also kept track > of the custom window. IMHO it makes no sense to handle this differently. the widget is meant to do that: void gtk_widget_set_tooltip_window (GtkWidget *widget, GtkWindow *custom_window); GtkWindow* gtk_widget_get_tooltip_window (GtkWidget *widget); for reasons outlined in a previous reply from me to kris. > gtk_tooltip_set_markup() vs. gtk_tooltip_set_window() > > simply feels much better than the asymmetry in > > gtk_tooltip_set_markup() vs. gtk_widget_set_tooltip_window() well, you'd not use GtkTooltip at all if you used gtk_widget_set_tooltip_window() before. in that way, the "asymmetry" simply reflects your usage. > The current approach even limits the new tooltip system's use cases, > since you have to set the custom window *outside* the callback. There > is no way to decide *in* the callback if a standard tooltip is > sufficient, or if a custom window is needed. i don't think it'd be clear that/if the custom window will be available in the GtkTooltip object again upon the next ::query-tooltip() emission. especially since users are not supposed to access GtkTooltip objects/structures in anyway *outside* of ::query-tooltip(), as outlined originally: http://mail.gnome.org/archives/gtk-devel-list/2006-April/msg00010.html also, passing GtkTooltip as NULL is meant to be as a clear indication that the user has to tinker with gtk_widget_get_tooltip_window() instead of the tooltip object. this avoids ambiguities like: static gboolean query_tooltip (GtkWidget *widget, gint x, gint y, GtkTooltip *tooltip) { gtk_tooltip_set_markup (tooltip, "See Me?"); g_object_new (GTK_TYPE_BUTTON, "parent", gtk_widget_get_tooltip_window(), "label", "Can You Click Me?", NULL); gtk_tooltip_set_icon (tooltip, messup_pixbuf); } what's the tooltip code supposed to do here? and yes, the API basically enforces that you decide per widget if an own tooltip window is needed or not. but i don't think that is a strong limitation, we have been discussing usage cases quite some in thise thread and nothing required to defer this decision into the callback (and no existing tooltip code i know of requires this either). so giving the benefits in API (and implementation) this provides, i think it is a reasonable limitation to make. > Another problem is the assymetry in getting the relevant data to the > callback. With markup, the GtkTooltip can be queried for the markup, > if it's a custom window, you have to get it to the callback somehow. Kris just forgot the getter for the custom window on the widget, so signal handler user_data is left alone. > In your example code it's passed as user_data, but user_data is > often not available since it's needed for other things, so you > have to add a "GtkWidget *tooltip_window" to the "other thing". > If "other thing" is e.g. the application toplevel window, which > of the sub-widget's tooltips should it keep? All of them? People > will in many cases end up attaching the tooltip window to the > widget. > > I also fail to see why the "has-tooltip" property has to be > set to TRUE, even tho a tooltip window was set on the widget. > i think this can be come by if we implement: - gtk_widget_set_tooltip_window() should automatically set: GtkWidget::has-tooltip = (custom_window != NULL || GtkWidget::tooltip-markup != ""); - setting GtkWidget::tooltip-markup should automatically set: GtkWidget::has-tooltip = (custom_window != NULL || GtkWidget::tooltip-markup != ""); right? > ciao, > --mitch > --- ciaoTJ From tkomulai@gmail.com Thu Jun 1 15:14:41 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 5A7023B0D70 for ; Thu, 1 Jun 2006 15:14:41 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31172-10 for ; Thu, 1 Jun 2006 15:14:40 -0400 (EDT) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.174]) by menubar.gnome.org (Postfix) with ESMTP id D35083B0CA3 for ; Thu, 1 Jun 2006 15:14:39 -0400 (EDT) Received: by ug-out-1314.google.com with SMTP id o2so222332uge for ; Thu, 01 Jun 2006 12:14:38 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=pkJ9GUF7tBRSDYTFZk62hCunrEDWh/ETW5JoJhlQx7UdB4QeOLJv/qztCngXO4Co/DiXf7ruqlpPxLBRYMp1hjNHoS2y4j0YEr7klSoN2TI6/rPnna1ZG+sfsuFqJaUK0lPq+fzd8NFeO3Vaf+6D8oJI9g3JXpXVTm3KfKENqYU= Received: by 10.78.47.15 with SMTP id u15mr181197huu; Thu, 01 Jun 2006 12:14:38 -0700 (PDT) Received: by 10.78.41.17 with HTTP; Thu, 1 Jun 2006 12:14:38 -0700 (PDT) Message-ID: <68bd3e050606011214i6c36109chff11c7242268b84@mail.gmail.com> Date: Thu, 1 Jun 2006 22:14:38 +0300 From: "Tommi Komulainen" Sender: tkomulai@gmail.com To: gtk-devel-list@gnome.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20060314132538.GA3526@babi-pangang.org> <443B4A8A.8000302@imendio.com> <20060425103017.GA15762@babi-pangang.org> <20060531183045.GA7564@babi-pangang.org> X-Google-Sender-Auth: 6188435c8e783fb2 X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.792 tagged_above=-999 required=2 tests=[AWL=-0.750, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.558, SPF_PASS=-0.001] X-Spam-Score: -1.792 X-Spam-Level: Subject: Re: Callback based tooltips (Re: New tooltips API, continued) X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2006 19:14:41 -0000 On 6/1/06, Tim Janik wrote: > On Wed, 31 May 2006, Kristian Rietveld wrote: > > > On Tue, Apr 25, 2006 at 03:08:12PM +0200, Soeren Sandmann wrote: > >> I once wrote down how tooltips should behave: > > > > I mostly like the behaviour you described below. > > > >> - Tooltips are too intrusive. The text should be smaller, and > > not sure if this has been raised already... > the font size of the tooltips should be exactly as large as the default > font size (module tooltip markup of course) to avoid reducing usability > of the tooltips in contrast to normal text (labels). As long as the font (and other things) are easily themable, the default values are not as important. And as gtk+ doesn't currently have any kind of design for using different font sizes in different contexts, I'd say the default font is a good default. Until someone comes up with a plan that looks at the bigger picture. -- Tommi Komulainen tommi.komulainen@iki.fi From mclasen@redhat.com Thu Jun 1 19:12:39 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id B0B143B0135 for ; Thu, 1 Jun 2006 19:12:39 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12736-06 for ; Thu, 1 Jun 2006 19:12:36 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id 567E43B0061 for ; Thu, 1 Jun 2006 19:12:36 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k51NCZWS017685 for ; Thu, 1 Jun 2006 19:12:35 -0400 Received: from lacrosse.corp.redhat.com (lacrosse.corp.redhat.com [172.16.52.154]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k51NCZpf020363 for ; Thu, 1 Jun 2006 19:12:35 -0400 Received: from [172.16.83.142] (vpn83-142.boston.redhat.com [172.16.83.142]) by lacrosse.corp.redhat.com (8.12.11.20060308/8.11.6) with ESMTP id k51NCXoG026214 for ; Thu, 1 Jun 2006 19:12:33 -0400 From: Matthias Clasen To: gtk-devel-list@gnome.org Content-Type: multipart/mixed; boundary="=-xjDvOKJb0tdB52kmWdgp" Organization: Red Hat Date: Thu, 01 Jun 2006 19:13:59 -0400 Message-Id: <1149203639.27455.9.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.7.2.1 (2.7.2.1-4) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.466 tagged_above=-999 required=2 tests=[AWL=-0.019, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, TW_GT=0.077, TW_XD=0.077] X-Spam-Score: -2.466 X-Spam-Level: Subject: Print preview api X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2006 23:12:39 -0000 --=-xjDvOKJb0tdB52kmWdgp Content-Type: text/plain Content-Transfer-Encoding: 7bit Ok, after a lot of work (mostly by John and Alex), we finally have a proposal for a print preview api that will allow us to use an external viewer by default, but also support internal preview. It consists of the following pieces: 1) GtkPrintOperation gets a new signal gboolean (*preview) (GtkPrintOperation *operation, GtkPrintOperationPreview *preview, GtkPrintContext *context, GtkWindow *parent); This signal is emitted when the user clicks the preview button. It the application does not handle it, the default handler will arrange for the external viewer to be spawned. An application that handles the preview internally should return TRUE from the signal handler. The GtkPrintOperationPreview that is passed to the signal handler lets the application control the preview. 2) The GtkPrintOperationPreview interface has a number of signals: void (*ready) (GtkPrintOperationPreview *preview, GtkPrintContext *context); The ready signal is emitted when pagination is done. The GtkPrintOperation::preview handler should connect to this signal to know when it is safe to start displaying pages. void (*got_page_size) (GtkPrintOperationPreview *preview, GtkPrintContext *context, GtkPageSetup *page_setup); The got-page-size signal is emitted for every rendered page, when the page setup for the page is know. This signal can be used to adjust the cairo context used for rendering the page (e.g. for resizing the preview window). And methods: void gtk_print_operation_preview_render_page (GtkPrintOperationPreview *preview, gint page_nr) Renders the requested page to the cairo context currently set on the print context for the preview. void gtk_print_operation_preview_end_preview (GtkPrintOperationPreview *preview) Must be called to clean up when the preview is finished. 3) A new way of handling the cairo context associated with a GtkPrintContext. A print context is no longer directly associated with a cairo surface. Instead, a cairo context is set with void gtk_print_context_set_cairo_context (GtkPrintContext *context, cairo_t *cr, double dpi_x, double dpi_y); And this can be repeated, typically in a got-page-size handler. The attached patch against current cvs has a very basic preview implementation in print-editor.c that demonstrates this api. Comments appreciated, Matthias --=-xjDvOKJb0tdB52kmWdgp Content-Disposition: attachment; filename=gtk-print-preview-7.diff Content-Type: text/x-patch; name=gtk-print-preview-7.diff; charset=UTF-8 Content-Transfer-Encoding: 7bit Index: gtk/Makefile.am =================================================================== RCS file: /cvs/gnome/gtk+/gtk/Makefile.am,v retrieving revision 1.308 diff -u -p -r1.308 Makefile.am --- gtk/Makefile.am 22 May 2006 17:19:09 -0000 1.308 +++ gtk/Makefile.am 1 Jun 2006 20:34:39 -0000 @@ -4,6 +4,7 @@ SUBDIRS=theme-bits if OS_UNIX SUBDIRS += xdgmime +GTK_PRINT_PREVIEW_COMMAND="evince %f" endif DIST_SUBDIRS=theme-bits xdgmime @@ -25,6 +26,7 @@ INCLUDES = \ -DGTK_HOST=\"$(host)\" \ -DGTK_COMPILATION \ -DGTK_PRINT_BACKENDS=\"$(GTK_PRINT_BACKENDS)\" \ + -DGTK_PRINT_PREVIEW_COMMAND=\"$(GTK_PRINT_PREVIEW_COMMAND)\" \ -I$(top_builddir)/gtk \ -I$(top_srcdir) -I../gdk \ -I$(top_srcdir)/gdk \ @@ -231,6 +233,7 @@ gtk_public_h_sources = \ gtkpreview.h \ gtkprintcontext.h \ gtkprintoperation.h \ + gtkprintoperationpreview.h \ gtkprintsettings.h \ gtkprivate.h \ gtkprogress.h \ @@ -487,6 +490,7 @@ gtk_c_sources = \ gtkpreview.c \ gtkprintcontext.c \ gtkprintoperation.c \ + gtkprintoperationpreview.c \ gtkprintsettings.c \ gtkprintutils.c \ gtkprogress.c \ Index: gtk/gtkmarshalers.list =================================================================== RCS file: /cvs/gnome/gtk+/gtk/gtkmarshalers.list,v retrieving revision 1.67 diff -u -p -r1.67 gtkmarshalers.list --- gtk/gtkmarshalers.list 22 May 2006 17:19:09 -0000 1.67 +++ gtk/gtkmarshalers.list 1 Jun 2006 20:34:39 -0000 @@ -32,6 +32,7 @@ BOOLEAN:OBJECT,INT,INT,UINT BOOLEAN:OBJECT,STRING,STRING,BOXED BOOLEAN:OBJECT,BOXED BOOLEAN:OBJECT,BOXED,BOXED +BOOLEAN:OBJECT,OBJECT,OBJECT BOOLEAN:OBJECT,STRING,STRING BOOLEAN:INT BOOLEAN:INT,INT Index: gtk/gtkprintbackend.c =================================================================== RCS file: /cvs/gnome/gtk+/gtk/gtkprintbackend.c,v retrieving revision 1.7 diff -u -p -r1.7 gtkprintbackend.c --- gtk/gtkprintbackend.c 1 Jun 2006 05:02:56 -0000 1.7 +++ gtk/gtkprintbackend.c 1 Jun 2006 20:34:39 -0000 @@ -200,7 +200,6 @@ _gtk_print_backend_create (const char *b GtkPrintBackendModule *pb_module; GtkPrintBackend *pb; - /* TODO: make module loading code work */ for (l = loaded_backends; l != NULL; l = l->next) { pb_module = l->data; @@ -255,6 +254,11 @@ gtk_print_backend_initialize (void) GTK_PRINT_BACKENDS, GTK_PARAM_READWRITE)); + gtk_settings_install_property (g_param_spec_string ("gtk-print-preview-command", + P_("Default command to run when displaying a print preview"), + P_("Command to run when displaying a print preview"), + GTK_PRINT_PREVIEW_COMMAND, + GTK_PARAM_READWRITE)); initialized = TRUE; } } Index: gtk/gtkprintbackend.h =================================================================== RCS file: /cvs/gnome/gtk+/gtk/gtkprintbackend.h,v retrieving revision 1.8 diff -u -p -r1.8 gtkprintbackend.h --- gtk/gtkprintbackend.h 24 May 2006 10:50:56 -0000 1.8 +++ gtk/gtkprintbackend.h 1 Jun 2006 20:34:39 -0000 @@ -140,6 +140,9 @@ void gtk_print_backend_print_stre GList * gtk_print_backend_load_modules (void); void gtk_print_backend_destroy (GtkPrintBackend *print_backend); +/* Methods private to gtk */ +GtkPrintBackend * _gtk_print_backend_create (const char *backend_name); + /* Backend-only functions for GtkPrintBackend */ void gtk_print_backend_add_printer (GtkPrintBackend *print_backend, Index: gtk/gtkprintcontext.c =================================================================== RCS file: /cvs/gnome/gtk+/gtk/gtkprintcontext.c,v retrieving revision 1.4 diff -u -p -r1.4 gtkprintcontext.c --- gtk/gtkprintcontext.c 31 May 2006 13:38:10 -0000 1.4 +++ gtk/gtkprintcontext.c 1 Jun 2006 20:34:39 -0000 @@ -40,6 +40,9 @@ struct _GtkPrintContext GtkPageSetup *page_setup; PangoFontMap *fontmap; + gdouble surface_dpi_x; + gdouble surface_dpi_y; + gdouble pixels_per_unit_x; gdouble pixels_per_unit_y; }; @@ -60,8 +63,8 @@ gtk_print_context_finalize (GObject *obj if (context->page_setup) g_object_unref (context->page_setup); - cairo_destroy (context->cr); - + if (context->cr) + cairo_destroy (context->cr); G_OBJECT_CLASS (gtk_print_context_parent_class)->finalize (object); } @@ -83,15 +86,31 @@ gtk_print_context_class_init (GtkPrintCo GtkPrintContext * _gtk_print_context_new (GtkPrintOperation *op) { - GtkPrintOperationPrivate *priv = op->priv; GtkPrintContext *context; context = g_object_new (GTK_TYPE_PRINT_CONTEXT, NULL); context->op = op; - context->cr = cairo_create (priv->surface); + context->cr = NULL; + context->fontmap = pango_cairo_font_map_new (); + + return context; +} + +void +gtk_print_context_set_cairo_context (GtkPrintContext *context, + cairo_t *cr, + double dpi_x, + double dpi_y) +{ + if (context->cr) + cairo_destroy (context->cr); + + context->cr = cairo_reference (cr); + context->surface_dpi_x = dpi_x; + context->surface_dpi_y = dpi_y; - switch (priv->unit) + switch (context->op->priv->unit) { default: case GTK_UNIT_PIXEL: @@ -100,34 +119,31 @@ _gtk_print_context_new (GtkPrintOperatio context->pixels_per_unit_y = 1.0; break; case GTK_UNIT_POINTS: - context->pixels_per_unit_x = priv->dpi_x / POINTS_PER_INCH; - context->pixels_per_unit_y = priv->dpi_y / POINTS_PER_INCH; + context->pixels_per_unit_x = dpi_x / POINTS_PER_INCH; + context->pixels_per_unit_y = dpi_y / POINTS_PER_INCH; break; case GTK_UNIT_INCH: - context->pixels_per_unit_x = priv->dpi_x; - context->pixels_per_unit_y = priv->dpi_y; + context->pixels_per_unit_x = dpi_x; + context->pixels_per_unit_y = dpi_y; break; case GTK_UNIT_MM: - context->pixels_per_unit_x = priv->dpi_x / MM_PER_INCH; - context->pixels_per_unit_y = priv->dpi_y / MM_PER_INCH; + context->pixels_per_unit_x = dpi_x / MM_PER_INCH; + context->pixels_per_unit_y = dpi_y / MM_PER_INCH; break; } cairo_scale (context->cr, context->pixels_per_unit_x, context->pixels_per_unit_y); - context->fontmap = pango_cairo_font_map_new (); /* We use the unit-scaled resolution, as we still want fonts given in points to work */ pango_cairo_font_map_set_resolution (PANGO_CAIRO_FONT_MAP (context->fontmap), - priv->dpi_y / context->pixels_per_unit_y); - - return context; + dpi_y / context->pixels_per_unit_y); } + void _gtk_print_context_rotate_according_to_orientation (GtkPrintContext *context) { - GtkPrintOperationPrivate *priv = context->op->priv; cairo_t *cr = context->cr; cairo_matrix_t matrix; GtkPaperSize *paper_size; @@ -136,9 +152,9 @@ _gtk_print_context_rotate_according_to_o paper_size = gtk_page_setup_get_paper_size (context->page_setup); width = gtk_paper_size_get_width (paper_size, GTK_UNIT_INCH); - width = width * priv->dpi_x / context->pixels_per_unit_x; + width = width * context->surface_dpi_x / context->pixels_per_unit_x; height = gtk_paper_size_get_height (paper_size, GTK_UNIT_INCH); - height = height * priv->dpi_y / context->pixels_per_unit_y; + height = height * context->surface_dpi_y / context->pixels_per_unit_y; switch (gtk_page_setup_get_orientation (context->page_setup)) { @@ -188,8 +204,8 @@ _gtk_print_context_translate_into_margin top = gtk_page_setup_get_top_margin (context->page_setup, GTK_UNIT_INCH); cairo_translate (context->cr, - left * priv->dpi_x / context->pixels_per_unit_x, - top * priv->dpi_y / context->pixels_per_unit_y); + left * context->surface_dpi_x / context->pixels_per_unit_x, + top * context->surface_dpi_y / context->pixels_per_unit_y); } void @@ -272,7 +288,7 @@ gtk_print_context_get_width (GtkPrintCon width = gtk_page_setup_get_page_width (context->page_setup, GTK_UNIT_INCH); /* Really dpi_x? What about landscape? what does dpi_x mean in that case? */ - return width * priv->dpi_x / context->pixels_per_unit_x; + return width * context->surface_dpi_x / context->pixels_per_unit_x; } /** @@ -300,8 +316,8 @@ gtk_print_context_get_height (GtkPrintCo else height = gtk_page_setup_get_page_height (context->page_setup, GTK_UNIT_INCH); - /* Really dpi_x? What about landscape? what does dpi_x mean in that case? */ - return height * priv->dpi_y / context->pixels_per_unit_y; + /* Really dpi_y? What about landscape? what does dpi_y mean in that case? */ + return height * context->surface_dpi_y / context->pixels_per_unit_y; } /** @@ -320,7 +336,7 @@ gtk_print_context_get_dpi_x (GtkPrintCon { g_return_val_if_fail (GTK_IS_PRINT_CONTEXT (context), 0); - return context->op->priv->dpi_x; + return context->surface_dpi_x; } /** @@ -339,7 +355,7 @@ gtk_print_context_get_dpi_y (GtkPrintCon { g_return_val_if_fail (GTK_IS_PRINT_CONTEXT (context), 0); - return context->op->priv->dpi_y; + return context->surface_dpi_y; } /** @@ -376,10 +392,16 @@ PangoContext * gtk_print_context_create_pango_context (GtkPrintContext *context) { PangoContext *pango_context; + cairo_font_options_t *options; g_return_val_if_fail (GTK_IS_PRINT_CONTEXT (context), NULL); pango_context = pango_cairo_font_map_create_context (PANGO_CAIRO_FONT_MAP (context->fontmap)); + + options = cairo_font_options_create (); + cairo_font_options_set_hint_metrics (options, CAIRO_HINT_METRICS_OFF); + pango_cairo_context_set_font_options (pango_context, options); + cairo_font_options_destroy (options); return pango_context; } Index: gtk/gtkprintcontext.h =================================================================== RCS file: /cvs/gnome/gtk+/gtk/gtkprintcontext.h,v retrieving revision 1.3 diff -u -p -r1.3 gtkprintcontext.h --- gtk/gtkprintcontext.h 31 May 2006 13:38:10 -0000 1.3 +++ gtk/gtkprintcontext.h 1 Jun 2006 20:34:39 -0000 @@ -51,6 +51,11 @@ PangoFontMap *gtk_print_context_get_pang PangoContext *gtk_print_context_create_pango_context (GtkPrintContext *context); PangoLayout *gtk_print_context_create_pango_layout (GtkPrintContext *context); +/* Needed for preview implementations */ +void gtk_print_context_set_cairo_context (GtkPrintContext *context, + cairo_t *cr, + double dpi_x, + double dpi_y); G_END_DECLS Index: gtk/gtkprintjob.c =================================================================== RCS file: /cvs/gnome/gtk+/gtk/gtkprintjob.c,v retrieving revision 1.8 diff -u -p -r1.8 gtkprintjob.c --- gtk/gtkprintjob.c 16 May 2006 16:13:48 -0000 1.8 +++ gtk/gtkprintjob.c 1 Jun 2006 20:34:39 -0000 @@ -212,14 +212,14 @@ gtk_print_job_constructor (GType job = GTK_PRINT_JOB (object); priv = job->priv; - g_assert (priv->printer_set && - priv->settings_set && + g_assert (priv->settings_set && priv->page_setup_set); - - _gtk_printer_prepare_for_print (priv->printer, - job, - priv->settings, - priv->page_setup); + + if (priv->printer) + _gtk_printer_prepare_for_print (priv->printer, + job, + priv->settings, + priv->page_setup); return object; } @@ -545,8 +545,12 @@ gtk_print_job_set_property (GObject case GTK_PRINT_JOB_PROP_PRINTER: priv->printer = GTK_PRINTER (g_value_dup_object (value)); - priv->printer_set = TRUE; - priv->backend = g_object_ref (gtk_printer_get_backend (priv->printer)); + + if (priv->printer != NULL) + { + priv->printer_set = TRUE; + priv->backend = g_object_ref (gtk_printer_get_backend (priv->printer)); + } break; case GTK_PRINT_JOB_PROP_PAGE_SETUP: Index: gtk/gtkprintoperation-private.h =================================================================== RCS file: /cvs/gnome/gtk+/gtk/gtkprintoperation-private.h,v retrieving revision 1.11 diff -u -p -r1.11 gtkprintoperation-private.h --- gtk/gtkprintoperation-private.h 1 Jun 2006 12:38:07 -0000 1.11 +++ gtk/gtkprintoperation-private.h 1 Jun 2006 20:34:39 -0000 @@ -46,9 +46,11 @@ struct _GtkPrintOperationPrivate guint print_pages_idle_id; guint show_progress_timeout_id; + GtkPrintContext *print_context; + /* Data for the print job: */ - cairo_surface_t *surface; - gdouble dpi_x, dpi_y; + /* cairo_surface_t *surface; */ + /* gdouble dpi_x, dpi_y; */ GtkPrintPages print_pages; GtkPageRange *page_ranges; @@ -84,11 +86,23 @@ GtkPrintOperationResult _gtk_print_opera GError **error); typedef void (* GtkPrintOperationPrintFunc) (GtkPrintOperation *op, - GtkWindow *parent); + GtkWindow *parent, + gboolean is_preview); void _gtk_print_operation_platform_backend_run_dialog_async (GtkPrintOperation *op, GtkWindow *parent, GtkPrintOperationPrintFunc print_cb); + +void _gtk_print_operation_platform_backend_launch_preview (GtkPrintOperation *op, + GtkWindow *parent, + const char *filename); + +cairo_surface_t *_gtk_print_operation_platform_backend_create_preview_surface (GtkPrintOperation *operation, + gdouble width, + gdouble heigh, + gdouble *dpi_x, + gdouble *dpi_y, + const gchar *target); void _gtk_print_operation_set_status (GtkPrintOperation *op, GtkPrintStatus status, Index: gtk/gtkprintoperation-unix.c =================================================================== RCS file: /cvs/gnome/gtk+/gtk/gtkprintoperation-unix.c,v retrieving revision 1.19 diff -u -p -r1.19 gtkprintoperation-unix.c --- gtk/gtkprintoperation-unix.c 1 Jun 2006 12:38:07 -0000 1.19 +++ gtk/gtkprintoperation-unix.c 1 Jun 2006 20:34:39 -0000 @@ -25,6 +25,9 @@ #include #include #include +#include +#include +#include #include "gtkprintoperation-private.h" #include "gtkmarshal.h" @@ -41,13 +44,17 @@ #include "gtkalias.h" #include "gtkintl.h" - typedef struct { - GtkPrintJob *job; /* the job we are sending to the printer */ - gulong job_status_changed_tag; GtkWindow *parent; /* just in case we need to throw error dialogs */ GMainLoop *loop; gboolean data_sent; + + /* Real printing (not preview: */ + GtkPrintJob *job; /* the job we are sending to the printer */ + cairo_surface_t *surface; + gulong job_status_changed_tag; + + } GtkPrintOperationUnix; typedef struct _PrinterFinder PrinterFinder; @@ -62,21 +69,24 @@ unix_start_page (GtkPrintOperation *op, GtkPrintContext *print_context, GtkPageSetup *page_setup) { + GtkPrintOperationUnix *op_unix; GtkPaperSize *paper_size; cairo_surface_type_t type; double w, h; + op_unix = op->priv->platform_data; + paper_size = gtk_page_setup_get_paper_size (page_setup); w = gtk_paper_size_get_width (paper_size, GTK_UNIT_POINTS); h = gtk_paper_size_get_height (paper_size, GTK_UNIT_POINTS); - type = cairo_surface_get_type (op->priv->surface); + type = cairo_surface_get_type (op_unix->surface); if (type == CAIRO_SURFACE_TYPE_PS) - cairo_ps_surface_set_size (op->priv->surface, w, h); + cairo_ps_surface_set_size (op_unix->surface, w, h); else if (type == CAIRO_SURFACE_TYPE_PDF) - cairo_pdf_surface_set_size (op->priv->surface, w, h); + cairo_pdf_surface_set_size (op_unix->surface, w, h); } static void @@ -102,6 +112,112 @@ op_unix_free (GtkPrintOperationUnix *op_ g_free (op_unix); } +static char * +shell_command_substitute_file (const gchar *cmd, + const gchar *filename) +{ + const char *inptr, *start; + char *result; + GString *final; + + g_return_val_if_fail (cmd != NULL, NULL); + g_return_val_if_fail (filename != NULL, NULL); + + result = NULL; + final = g_string_new (NULL); + + start = inptr = cmd; + + while ((inptr = strchr (inptr, '%')) != NULL) + { + g_string_append_len (final, start, inptr - start); + inptr++; + switch (*inptr) + { + case 'f': + g_string_append (final, filename ? filename : ""); + break; + + case '%': + g_string_append_c (final, '%'); + break; + + default: + g_string_append_c (final, '%'); + if (*inptr) + g_string_append_c (final, *inptr); + break; + } + if (*inptr) + inptr++; + start = inptr; + } + g_string_append (final, start); + + result = final->str; + + g_string_free (final, FALSE); + + return result; +} + +void +_gtk_print_operation_platform_backend_launch_preview (GtkPrintOperation *op, + GtkWindow *parent, + const char *filename) +{ + int argc; + gchar **argv; + gchar *cmd; + gchar *preview_cmd; + GtkSettings *settings; + gchar *quoted_filename; + GdkScreen *screen; + GError *error = NULL; + + settings = gtk_settings_get_default (); + g_object_get (settings, "gtk-print-preview-command", &preview_cmd, NULL); + + quoted_filename = g_shell_quote (filename); + cmd = shell_command_substitute_file (preview_cmd, quoted_filename); + g_shell_parse_argv (cmd, &argc, &argv, &error); + + if (error !=NULL) + goto out; + + if (parent) + screen = gtk_window_get_screen (parent); + else + screen = gdk_screen_get_default (); + + gdk_spawn_on_screen (screen, NULL, argv, NULL, G_SPAWN_SEARCH_PATH, NULL, NULL, NULL, &error); + + out: + if (error != NULL) + { + GtkWidget *edialog; + edialog = gtk_message_dialog_new (parent, + GTK_DIALOG_DESTROY_WITH_PARENT, + GTK_MESSAGE_ERROR, + GTK_BUTTONS_CLOSE, + _("Error launching preview") /* FIXME better text */); + gtk_message_dialog_format_secondary_text (GTK_MESSAGE_DIALOG (edialog), + "%s", error->message); + gtk_window_set_modal (GTK_WINDOW (edialog), TRUE); + g_signal_connect (edialog, "response", + G_CALLBACK (gtk_widget_destroy), NULL); + + gtk_window_present (GTK_WINDOW (edialog)); + + g_error_free (error); + } + + g_free (cmd); + g_free (quoted_filename); + g_free (preview_cmd); + g_strfreev (argv); +} + static void unix_finish_send (GtkPrintJob *job, void *user_data, @@ -129,6 +245,7 @@ unix_finish_send (GtkPrintJob *job, } op_unix->data_sent = TRUE; + if (op_unix->loop) g_main_loop_quit (op_unix->loop); } @@ -140,6 +257,8 @@ unix_end_run (GtkPrintOperation *op, { GtkPrintOperationUnix *op_unix = op->priv->platform_data; + cairo_surface_finish (op_unix->surface); + if (cancelled) return; @@ -147,10 +266,11 @@ unix_end_run (GtkPrintOperation *op, op_unix->loop = g_main_loop_new (NULL, FALSE); /* TODO: Check for error */ - gtk_print_job_send (op_unix->job, - unix_finish_send, - op_unix, NULL, - NULL); + if (op_unix->job != NULL) + gtk_print_job_send (op_unix->job, + unix_finish_send, + op_unix, NULL, + NULL); if (wait) { @@ -253,64 +373,66 @@ finish_print (PrintResponseData *rdata, { GtkPrintOperation *op = rdata->op; GtkPrintOperationPrivate *priv = op->priv; + gboolean is_preview; - priv->start_page = unix_start_page; - priv->end_page = unix_end_page; - priv->end_run = unix_end_run; + g_print ("finish_print\n"); + + is_preview = rdata->result == GTK_PRINT_OPERATION_RESULT_PREVIEW; if (rdata->do_print) { - GtkPrintOperationUnix *op_unix; - gtk_print_operation_set_print_settings (op, settings); - - op_unix = g_new0 (GtkPrintOperationUnix, 1); - op_unix->job = gtk_print_job_new (priv->job_name, - printer, - settings, - page_setup); + op->priv->print_context = _gtk_print_context_new (op); - gtk_print_job_set_track_print_status (op_unix->job, priv->track_print_status); - - rdata->op->priv->surface = gtk_print_job_get_surface (op_unix->job, rdata->error); - if (op->priv->surface == NULL) + if (!is_preview) { - rdata->do_print = FALSE; - op_unix_free (op_unix); - rdata->result = GTK_PRINT_OPERATION_RESULT_ERROR; - goto out; - } - - _gtk_print_operation_set_status (op, gtk_print_job_get_status (op_unix->job), NULL); - op_unix->job_status_changed_tag = - g_signal_connect (op_unix->job, "status-changed", - G_CALLBACK (job_status_changed_cb), op); - - op_unix->parent = rdata->parent; - - priv->dpi_x = 72; - priv->dpi_y = 72; - - priv->platform_data = op_unix; - priv->free_platform_data = (GDestroyNotify) op_unix_free; - - priv->print_pages = op_unix->job->print_pages; - priv->page_ranges = op_unix->job->page_ranges; - priv->num_page_ranges = op_unix->job->num_page_ranges; - - priv->manual_num_copies = op_unix->job->num_copies; - priv->manual_collation = op_unix->job->collate; - priv->manual_reverse = op_unix->job->reverse; - priv->manual_page_set = op_unix->job->page_set; - priv->manual_scale = op_unix->job->scale; - priv->manual_orientation = op_unix->job->rotate_to_orientation; + GtkPrintOperationUnix *op_unix; + cairo_t *cr; + + op_unix = g_new0 (GtkPrintOperationUnix, 1); + priv->platform_data = op_unix; + priv->free_platform_data = (GDestroyNotify) op_unix_free; + op_unix->parent = rdata->parent; + + priv->start_page = unix_start_page; + priv->end_page = unix_end_page; + priv->end_run = unix_end_run; + + op_unix->job = gtk_print_job_new (priv->job_name, + printer, + settings, + page_setup); + gtk_print_job_set_track_print_status (op_unix->job, priv->track_print_status); + /* TODO: handle error */ + op_unix->surface = gtk_print_job_get_surface (op_unix->job, rdata->error); + cr = cairo_create (op_unix->surface); + gtk_print_context_set_cairo_context (op->priv->print_context, + cr, 72, 72); + cairo_destroy (cr); + + _gtk_print_operation_set_status (op, gtk_print_job_get_status (op_unix->job), NULL); + + op_unix->job_status_changed_tag = + g_signal_connect (op_unix->job, "status-changed", + G_CALLBACK (job_status_changed_cb), op); + + priv->print_pages = op_unix->job->print_pages; + priv->page_ranges = op_unix->job->page_ranges; + priv->num_page_ranges = op_unix->job->num_page_ranges; + + priv->manual_num_copies = op_unix->job->num_copies; + priv->manual_collation = op_unix->job->collate; + priv->manual_reverse = op_unix->job->reverse; + priv->manual_page_set = op_unix->job->page_set; + priv->manual_scale = op_unix->job->scale; + priv->manual_orientation = op_unix->job->rotate_to_orientation; + } } - - out: + if (rdata->print_cb) { if (rdata->do_print) - rdata->print_cb (op, rdata->parent); + rdata->print_cb (op, rdata->parent, is_preview); else _gtk_print_operation_set_status (op, GTK_PRINT_STATUS_FINISHED_ABORTED, NULL); } @@ -319,7 +441,7 @@ finish_print (PrintResponseData *rdata, rdata->destroy (rdata); } -static void +static void handle_print_response (GtkWidget *dialog, gint response, gpointer data) @@ -330,6 +452,8 @@ handle_print_response (GtkWidget *dialog GtkPageSetup *page_setup = NULL; GtkPrinter *printer = NULL; + g_print ("handle_print_response\n"); + if (response == GTK_RESPONSE_OK) { rdata->result = GTK_PRINT_OPERATION_RESULT_APPLY; @@ -345,14 +469,24 @@ handle_print_response (GtkWidget *dialog g_signal_emit_by_name (rdata->op, "custom-widget-apply", rdata->op->priv->custom_widget); } + else if (response == GTK_RESPONSE_APPLY) + { + /* print preview */ + rdata->result = GTK_PRINT_OPERATION_RESULT_PREVIEW; + rdata->do_print = TRUE; + settings = gtk_print_unix_dialog_get_settings (GTK_PRINT_UNIX_DIALOG (pd)); + page_setup = gtk_print_unix_dialog_get_page_setup (GTK_PRINT_UNIX_DIALOG (pd)); + } + out: finish_print (rdata, printer, page_setup, settings); if (settings) g_object_unref (settings); - + gtk_widget_destroy (GTK_WIDGET (pd)); + } @@ -436,6 +570,19 @@ _gtk_print_operation_platform_backend_ru } } +cairo_surface_t * +_gtk_print_operation_platform_backend_create_preview_surface (GtkPrintOperation *op, + gdouble width, + gdouble height, + gdouble *dpi_x, + gdouble *dpi_y, + const gchar *target) +{ + g_print ("pdf surface size: %f x %f\n", width, height); + *dpi_x = *dpi_y = 72; + return cairo_pdf_surface_create (target, width, height); +} + GtkPrintOperationResult _gtk_print_operation_platform_backend_run_dialog (GtkPrintOperation *op, GtkWindow *parent, @@ -459,6 +606,7 @@ _gtk_print_operation_platform_backend_ru if (op->priv->show_dialog) { pd = get_print_dialog (op, parent); + response = gtk_dialog_run (GTK_DIALOG (pd)); handle_print_response (pd, response, &rdata); } Index: gtk/gtkprintoperation-win32.c =================================================================== RCS file: /cvs/gnome/gtk+/gtk/gtkprintoperation-win32.c,v retrieving revision 1.9 diff -u -p -r1.9 gtkprintoperation-win32.c --- gtk/gtkprintoperation-win32.c 23 May 2006 16:30:45 -0000 1.9 +++ gtk/gtkprintoperation-win32.c 1 Jun 2006 20:34:39 -0000 @@ -492,6 +492,7 @@ win32_end_run (GtkPrintOperation *op, GlobalFree(op_win32->devmode); GlobalFree(op_win32->devnames); + cairo_surface_finish (op->priv->surface); cairo_surface_destroy (op->priv->surface); op->priv->surface = NULL; Index: gtk/gtkprintoperation.c =================================================================== RCS file: /cvs/gnome/gtk+/gtk/gtkprintoperation.c,v retrieving revision 1.24 diff -u -p -r1.24 gtkprintoperation.c --- gtk/gtkprintoperation.c 1 Jun 2006 12:38:07 -0000 1.24 +++ gtk/gtkprintoperation.c 1 Jun 2006 20:34:39 -0000 @@ -19,6 +19,10 @@ */ #include "config.h" + +#include +#include + #include #include "gtkprintoperation-private.h" #include "gtkmarshalers.h" @@ -41,6 +45,7 @@ enum { STATUS_CHANGED, CREATE_CUSTOM_WIDGET, CUSTOM_WIDGET_APPLY, + PREVIEW, LAST_SIGNAL }; @@ -65,7 +70,15 @@ enum { static guint signals[LAST_SIGNAL] = { 0 }; static int job_nr = 0; -G_DEFINE_TYPE (GtkPrintOperation, gtk_print_operation, G_TYPE_OBJECT) +static void preview_iface_init (GtkPrintOperationPreviewIface *iface); +static GtkPageSetup *create_page_setup (GtkPrintOperation *op); +static void common_render_page (GtkPrintOperation *op, + gint page_nr); + + +G_DEFINE_TYPE_WITH_CODE (GtkPrintOperation, gtk_print_operation, G_TYPE_OBJECT, + G_IMPLEMENT_INTERFACE (GTK_TYPE_PRINT_OPERATION_PREVIEW, + preview_iface_init)) /** * gtk_print_error_quark: @@ -146,6 +159,60 @@ gtk_print_operation_init (GtkPrintOperat } static void +preview_iface_render_page (GtkPrintOperationPreview *preview, + gint page_nr) +{ + GtkPrintOperation *op; + + op = GTK_PRINT_OPERATION (preview); + common_render_page (op, page_nr); +} + +static void +preview_iface_end_preview (GtkPrintOperationPreview *preview) +{ + GtkPrintOperation *op; + + op = GTK_PRINT_OPERATION (preview); + + g_signal_emit (op, signals[END_PRINT], 0, op->priv->print_context); + + if (op->priv->rloop) + g_main_loop_quit (op->priv->rloop); + + op->priv->end_run (op, op->priv->is_sync, TRUE); +} + +static void +preview_iface_init (GtkPrintOperationPreviewIface *iface) +{ + iface->render_page = preview_iface_render_page; + iface->end_preview = preview_iface_end_preview; +} + +static void +preview_start_page (GtkPrintOperation *op, + GtkPrintContext *print_context, + GtkPageSetup *page_setup) +{ + g_signal_emit_by_name (op, "got-page-size",print_context, page_setup); +} + +static void +preview_end_page (GtkPrintOperation *op, + GtkPrintContext *print_context) +{ +} + +static void +preview_end_run (GtkPrintOperation *op, + gboolean wait, + gboolean cancelled) +{ +} + + +static void gtk_print_operation_set_property (GObject *object, guint prop_id, const GValue *value, @@ -256,6 +323,158 @@ gtk_print_operation_get_property (GObjec } } +typedef struct +{ + GtkPrintOperationPreview *preview; + GtkPrintContext *print_context; + GtkWindow *parent; + cairo_surface_t *surface; + gchar *filename; + guint page_nr; + gboolean wait; +} PreviewOp; + +static void +preview_print_idle_done (gpointer data) +{ + GtkPrintOperation *op; + PreviewOp *pop = (PreviewOp *) data; + + op = GTK_PRINT_OPERATION (pop->preview); + + _gtk_print_operation_platform_backend_launch_preview (op, + pop->parent, + pop->filename); + + g_free (pop->filename); + cairo_surface_finish (pop->surface); + cairo_surface_destroy (pop->surface); + + gtk_print_operation_preview_end_preview (pop->preview); + g_free (pop); +} + +static gboolean +preview_print_idle (gpointer data) +{ + PreviewOp *pop; + GtkPrintOperation *op; + gboolean retval = TRUE; + cairo_t *cr; + + GDK_THREADS_ENTER (); + + pop = (PreviewOp *) data; + op = GTK_PRINT_OPERATION (pop->preview); + + gtk_print_operation_preview_render_page (pop->preview, pop->page_nr); + + cr = gtk_print_context_get_cairo_context (pop->print_context); + cairo_show_page (cr); + + /* TODO: print out sheets not pages and follow ranges */ + pop->page_nr++; + if (op->priv->nr_of_pages <= pop->page_nr) + retval = FALSE; + + GDK_THREADS_LEAVE (); + + return retval; +} + +static void +preview_got_page_size (GtkPrintOperationPreview *preview, + GtkPrintContext *context, + GtkPageSetup *page_setup, + PreviewOp *pop) +{ + GtkPrintOperation *op = GTK_PRINT_OPERATION (preview); + GtkPaperSize *paper_size; + double w, h; + + paper_size = gtk_page_setup_get_paper_size (page_setup); + + w = gtk_paper_size_get_width (paper_size, GTK_UNIT_POINTS); + h = gtk_paper_size_get_height (paper_size, GTK_UNIT_POINTS); + + /* TODO: don't hardcode pdf */ + cairo_pdf_surface_set_size (pop->surface, w, h); +} + +static void +preview_ready (GtkPrintOperationPreview *preview, + GtkPrintContext *context, + PreviewOp *pop) +{ + + pop->page_nr = 0; + pop->print_context = context; + + g_idle_add_full (G_PRIORITY_DEFAULT_IDLE, + preview_print_idle, + pop, + preview_print_idle_done); + +} + +/** + * gtk_print_operation_preview_handler: + * + * Default handler for preview operations + **/ +static gboolean +gtk_print_operation_preview_handler (GtkPrintOperation *op, + GtkPrintOperationPreview *preview, + GtkPrintContext *context, + GtkWindow *parent) +{ + gdouble width, height, dpi_x, dpi_y; + gchar *tmp_dir; + gchar *dir_template; + gchar *preview_filename; + PreviewOp *pop; + GtkPrintSettings *settings; + cairo_t *cr; + + dir_template = g_build_filename (g_get_tmp_dir (), "print-preview-XXXXXX", NULL); + + /* use temp dirs because apps like evince need to have extentions + to determine the mine type */ + tmp_dir = mkdtemp(dir_template); + + preview_filename = g_build_filename (tmp_dir, + "Print Preview.pdf", + NULL); + + g_free (dir_template); + + pop = g_new0 (PreviewOp, 1); + pop->filename = preview_filename; + pop->preview = preview; + pop->parent = parent; + + settings = op->priv->print_settings; + + width = gtk_print_settings_get_paper_width (settings, GTK_UNIT_POINTS); + height = gtk_print_settings_get_paper_height (settings, GTK_UNIT_POINTS); + + pop->surface = + _gtk_print_operation_platform_backend_create_preview_surface (op, + width, height, + &dpi_x, &dpi_y, + pop->filename); + + cr = cairo_create (pop->surface); + gtk_print_context_set_cairo_context (op->priv->print_context, cr, + dpi_x, dpi_y); + cairo_destroy (cr); + + g_signal_connect (preview, "ready", (GCallback) preview_ready, pop); + g_signal_connect (preview, "got-page-size", (GCallback) preview_got_page_size, pop); + + return TRUE; +} + static GtkWidget * gtk_print_operation_create_custom_widget (GtkPrintOperation *operation) { @@ -287,7 +506,8 @@ gtk_print_operation_class_init (GtkPrint gobject_class->set_property = gtk_print_operation_set_property; gobject_class->get_property = gtk_print_operation_get_property; gobject_class->finalize = gtk_print_operation_finalize; - + + class->preview = gtk_print_operation_preview_handler; class->create_custom_widget = gtk_print_operation_create_custom_widget; g_type_class_add_private (gobject_class, sizeof (GtkPrintOperationPrivate)); @@ -530,6 +750,33 @@ gtk_print_operation_class_init (GtkPrint g_cclosure_marshal_VOID__OBJECT, G_TYPE_NONE, 1, GTK_TYPE_WIDGET); + /** + * GtkPrintOperation::preview: + * @operation: the #GtkPrintOperation on which the signal was emitted + * @preview: the #GtkPrintPreviewOperation for the current operation + * @context: the #GtkPrintContext that will be used + * @parent: the #GtkWindow to use as window parent, or NULL + * + * Gets emitted when a preview is requested from the native dialog. + * If you handle this you must set the cairo_context on the printing context. + * + * Returns: #TRUE if the listener wants to take over control of the preview + * + * Since: 2.10 + */ + signals[PREVIEW] = + g_signal_new (I_("preview"), + G_TYPE_FROM_CLASS (gobject_class), + G_SIGNAL_RUN_LAST, + G_STRUCT_OFFSET (GtkPrintOperationClass, preview), + _gtk_boolean_handled_accumulator, NULL, + _gtk_marshal_BOOLEAN__OBJECT_OBJECT_OBJECT, + G_TYPE_BOOLEAN, 3, + GTK_TYPE_PRINT_OPERATION_PREVIEW, + GTK_TYPE_PRINT_CONTEXT, + GTK_TYPE_WINDOW); + + /** * GtkPrintOperation:default-page-setup: * @@ -1436,6 +1683,7 @@ pdf_start_page (GtkPrintOperation *op, GtkPageSetup *page_setup) { GtkPaperSize *paper_size; + cairo_surface_t *surface = op->priv->platform_data; double w, h; paper_size = gtk_page_setup_get_paper_size (page_setup); @@ -1443,7 +1691,7 @@ pdf_start_page (GtkPrintOperation *op, w = gtk_paper_size_get_width (paper_size, GTK_UNIT_POINTS); h = gtk_paper_size_get_height (paper_size, GTK_UNIT_POINTS); - cairo_pdf_surface_set_size (op->priv->surface, w, h); + cairo_pdf_surface_set_size (surface, w, h); } static void @@ -1462,9 +1710,10 @@ pdf_end_run (GtkPrintOperation *op, gboolean cancelled) { GtkPrintOperationPrivate *priv = op->priv; + cairo_surface_t *surface = priv->platform_data; - cairo_surface_destroy (priv->surface); - priv->surface = NULL; + cairo_surface_finish (surface); + cairo_surface_destroy (surface); } static GtkPrintOperationResult @@ -1475,6 +1724,8 @@ run_pdf (GtkPrintOperation *op, { GtkPrintOperationPrivate *priv = op->priv; GtkPageSetup *page_setup; + cairo_surface_t *surface; + cairo_t *cr; double width, height; /* This will be overwritten later by the non-default size, but we need to pass some size: */ @@ -1484,13 +1735,19 @@ run_pdf (GtkPrintOperation *op, height = gtk_page_setup_get_paper_height (page_setup, GTK_UNIT_POINTS); g_object_unref (page_setup); - priv->surface = cairo_pdf_surface_create (priv->pdf_target, + surface = cairo_pdf_surface_create (priv->pdf_target, width, height); - cairo_pdf_surface_set_dpi (priv->surface, 300, 300); - - priv->dpi_x = 72; - priv->dpi_y = 72; + cairo_pdf_surface_set_dpi (surface, 300, 300); + + priv->platform_data = surface; + priv->free_platform_data = (GDestroyNotify) cairo_surface_destroy; + cr = cairo_create (surface); + gtk_print_context_set_cairo_context (op->priv->print_context, + cr, 72, 72); + cairo_destroy (cr); + + priv->print_pages = GTK_PRINT_PAGES_ALL; priv->page_ranges = NULL; priv->num_page_ranges = 0; @@ -1524,10 +1781,11 @@ typedef struct gint page, start, end, inc; - GtkPageSetup *initial_page_setup; - GtkPrintContext *print_context; + gboolean initialized; GtkWidget *progress; + + gboolean is_preview; } PrintPagesData; static void @@ -1599,12 +1857,9 @@ print_pages_idle_done (gpointer user_dat if (data->progress) gtk_widget_destroy (data->progress); - g_object_unref (data->print_context); - g_object_unref (data->initial_page_setup); - g_object_unref (data->op); - if (priv->rloop) + if (priv->rloop && !data->is_preview) g_main_loop_quit (priv->rloop); g_free (data); @@ -1640,15 +1895,62 @@ update_progress (PrintPagesData *data) } } +static void +common_render_page (GtkPrintOperation *op, + gint page_nr) +{ + GtkPrintOperationPrivate *priv = op->priv; + GtkPageSetup *page_setup; + GtkPrintContext *print_context; + cairo_t *cr; + + print_context = priv->print_context; + + page_setup = create_page_setup (op); + + g_signal_emit (op, signals[REQUEST_PAGE_SETUP], 0, + print_context, page_nr, page_setup); + + _gtk_print_context_set_page_setup (print_context, page_setup); + + /* TODO: override for preview */ + priv->start_page (op, print_context, page_setup); + + cr = gtk_print_context_get_cairo_context (print_context); + + cairo_save (cr); + if (priv->manual_scale != 1.0) + cairo_scale (cr, + priv->manual_scale, + priv->manual_scale); + + if (priv->manual_orientation) + _gtk_print_context_rotate_according_to_orientation (print_context); + + if (!priv->use_full_page) + _gtk_print_context_translate_into_margin (print_context); + + g_signal_emit (op, signals[DRAW_PAGE], 0, + print_context, page_nr); + + /* TODO: override for preview */ + priv->end_page (op, print_context); + + cairo_restore (cr); + + g_object_unref (page_setup); +} + static gboolean print_pages_idle (gpointer user_data) { PrintPagesData *data; GtkPrintOperationPrivate *priv; GtkPageSetup *page_setup; - cairo_t *cr; gboolean done = FALSE; + g_print ("print_pages_idle\n"); + GDK_THREADS_ENTER (); data = (PrintPagesData*)user_data; @@ -1656,15 +1958,15 @@ print_pages_idle (gpointer user_data) if (priv->status == GTK_PRINT_STATUS_PREPARING) { - if (!data->print_context) + if (!data->initialized) { - data->print_context = _gtk_print_context_new (data->op); - data->initial_page_setup = create_page_setup (data->op); - - _gtk_print_context_set_page_setup (data->print_context, - data->initial_page_setup); + data->initialized = TRUE; + page_setup = create_page_setup (data->op); + _gtk_print_context_set_page_setup (priv->print_context, + page_setup); + g_object_unref (page_setup); - g_signal_emit (data->op, signals[BEGIN_PRINT], 0, data->print_context); + g_signal_emit (data->op, signals[BEGIN_PRINT], 0, priv->print_context); if (priv->manual_collation) { @@ -1684,7 +1986,7 @@ print_pages_idle (gpointer user_data) { gboolean paginated = FALSE; - g_signal_emit (data->op, signals[PAGINATE], 0, data->print_context, &paginated); + g_signal_emit (data->op, signals[PAGINATE], 0, priv->print_context, &paginated); if (!paginated) goto out; } @@ -1751,36 +2053,18 @@ print_pages_idle (gpointer user_data) goto out; } } + + if (data->is_preview) + { + done = TRUE; - page_setup = gtk_page_setup_copy (data->initial_page_setup); - g_signal_emit (data->op, signals[REQUEST_PAGE_SETUP], 0, - data->print_context, data->page, page_setup); - - _gtk_print_context_set_page_setup (data->print_context, page_setup); - priv->start_page (data->op, data->print_context, page_setup); - - cr = gtk_print_context_get_cairo_context (data->print_context); - - cairo_save (cr); - if (priv->manual_scale != 1.0) - cairo_scale (cr, - priv->manual_scale, - priv->manual_scale); - - if (priv->manual_orientation) - _gtk_print_context_rotate_according_to_orientation (data->print_context); - - if (!priv->use_full_page) - _gtk_print_context_translate_into_margin (data->print_context); - - g_signal_emit (data->op, signals[DRAW_PAGE], 0, - data->print_context, data->page); - - priv->end_page (data->op, data->print_context); - - cairo_restore (cr); - - g_object_unref (page_setup); + g_object_ref (data->op); + + g_signal_emit_by_name (data->op, "ready", priv->print_context); + goto out; + } + + common_render_page (data->op, data->page); out: @@ -1791,11 +2075,9 @@ print_pages_idle (gpointer user_data) done = TRUE; } - if (done) + if (done && !data->is_preview) { - g_signal_emit (data->op, signals[END_PRINT], 0, data->print_context); - - cairo_surface_finish (priv->surface); + g_signal_emit (data->op, signals[END_PRINT], 0, priv->print_context); priv->end_run (data->op, priv->is_sync, priv->cancelled); } @@ -1833,15 +2115,19 @@ show_progress_timeout (PrintPagesData *d static void print_pages (GtkPrintOperation *op, - GtkWindow *parent) + GtkWindow *parent, + gboolean is_preview) { GtkPrintOperationPrivate *priv = op->priv; PrintPagesData *data; - + + g_print ("print_pages\n"); + _gtk_print_operation_set_status (op, GTK_PRINT_STATUS_PREPARING, NULL); data = g_new0 (PrintPagesData, 1); data->op = g_object_ref (op); + data->is_preview = is_preview; if (priv->show_progress) { @@ -1862,6 +2148,37 @@ print_pages (GtkPrintOperation *op, data->progress = progress; } + if (is_preview) + { + gboolean handled; + + g_signal_emit_by_name (op, "preview", + GTK_PRINT_OPERATION_PREVIEW (op), + op->priv->print_context, + parent, + &handled); + + if (!handled || + gtk_print_context_get_cairo_context (priv->print_context) == NULL) { + /* TODO: handle error */ + } + + priv->start_page = preview_start_page; + priv->end_page = preview_end_page; + priv->end_run = preview_end_run; + + /* TODO: Do we really need to set these? */ + priv->print_pages = GTK_PRINT_PAGES_ALL; + priv->page_ranges = NULL; + priv->num_page_ranges = 0; + priv->manual_num_copies = 1; + priv->manual_collation = FALSE; + priv->manual_reverse = FALSE; + priv->manual_page_set = GTK_PAGE_SET_ALL; + priv->manual_scale = 1.0; + priv->manual_orientation = TRUE; + } + priv->print_pages_idle_id = g_idle_add_full (G_PRIORITY_DEFAULT_IDLE, print_pages_idle, data, @@ -1877,9 +2194,10 @@ print_pages (GtkPrintOperation *op, GDK_THREADS_LEAVE (); g_main_loop_run (priv->rloop); GDK_THREADS_ENTER (); + + g_main_loop_unref (priv->rloop); + priv->rloop = NULL; } - g_main_loop_unref (priv->rloop); - priv->rloop = NULL; } /** @@ -1964,7 +2282,7 @@ gtk_print_operation_run (GtkPrintOperati &do_print, error); if (do_print) - print_pages (op, parent); + print_pages (op, parent, result == GTK_PRINT_OPERATION_RESULT_PREVIEW); else _gtk_print_operation_set_status (op, GTK_PRINT_STATUS_FINISHED_ABORTED, NULL); @@ -2006,7 +2324,7 @@ gtk_print_operation_run_async (GtkPrintO { run_pdf (op, parent, &do_print, NULL); if (do_print) - print_pages (op, parent); + print_pages (op, parent, FALSE); else _gtk_print_operation_set_status (op, GTK_PRINT_STATUS_FINISHED_ABORTED, NULL); } Index: gtk/gtkprintoperation.h =================================================================== RCS file: /cvs/gnome/gtk+/gtk/gtkprintoperation.h,v retrieving revision 1.10 diff -u -p -r1.10 gtkprintoperation.h --- gtk/gtkprintoperation.h 24 May 2006 16:15:14 -0000 1.10 +++ gtk/gtkprintoperation.h 1 Jun 2006 20:34:39 -0000 @@ -29,6 +29,7 @@ #include "gtkpagesetup.h" #include "gtkprintsettings.h" #include "gtkprintcontext.h" +#include "gtkprintoperationpreview.h" G_BEGIN_DECLS @@ -84,7 +85,13 @@ struct _GtkPrintOperationClass GtkWidget *(*create_custom_widget) (GtkPrintOperation *operation); void (*custom_widget_apply) (GtkPrintOperation *operation, GtkWidget *widget); + + gboolean (*preview) (GtkPrintOperation *operation, + GtkPrintOperationPreview *preview, + GtkPrintContext *context, + GtkWindow *parent); + /* Padding for future expansion */ void (*_gtk_reserved1) (void); void (*_gtk_reserved2) (void); @@ -98,7 +105,8 @@ struct _GtkPrintOperationClass typedef enum { GTK_PRINT_OPERATION_RESULT_ERROR, GTK_PRINT_OPERATION_RESULT_APPLY, - GTK_PRINT_OPERATION_RESULT_CANCEL + GTK_PRINT_OPERATION_RESULT_CANCEL, + GTK_PRINT_OPERATION_RESULT_PREVIEW } GtkPrintOperationResult; #define GTK_PRINT_ERROR gtk_print_error_quark () Index: gtk/gtkprintoperationpreview.c =================================================================== RCS file: gtk/gtkprintoperationpreview.c diff -N gtk/gtkprintoperationpreview.c --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ gtk/gtkprintoperationpreview.c 1 Jun 2006 20:34:39 -0000 @@ -0,0 +1,107 @@ +/* GTK - The GIMP Toolkit + * gtkprintoperationpreview.c: Abstract print preview interface + * Copyright (C) 2006, Red Hat, Inc. + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2 of the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library; if not, write to the + * Free Software Foundation, Inc., 59 Temple Place - Suite 330, + * Boston, MA 02111-1307, USA. + */ + +#include "config.h" + +#include "gtkprintoperationpreview.h" +#include "gtkmarshalers.h" +#include "gtkintl.h" + +static void gtk_print_operation_preview_base_init (gpointer g_iface); + +GType +gtk_print_operation_preview_get_type (void) +{ + static GType print_operation_preview_type = 0; + + if (!print_operation_preview_type) + { + static const GTypeInfo print_operation_preview_info = + { + sizeof (GtkPrintOperationPreviewIface), /* class_size */ + gtk_print_operation_preview_base_init, /* base_init */ + NULL, /* base_finalize */ + NULL, + NULL, /* class_finalize */ + NULL, /* class_data */ + 0, + 0, /* n_preallocs */ + NULL + }; + + print_operation_preview_type = + g_type_register_static (G_TYPE_INTERFACE, I_("GtkPrintOperationPreview"), + &print_operation_preview_info, 0); + + g_type_interface_add_prerequisite (print_operation_preview_type, G_TYPE_OBJECT); + } + + return print_operation_preview_type; +} + +static void +gtk_print_operation_preview_base_init (gpointer g_iface) +{ + static gboolean initialized = FALSE; + + if (!initialized) + { + g_signal_new (I_("ready"), + GTK_TYPE_PRINT_OPERATION_PREVIEW, + G_SIGNAL_RUN_LAST, + G_STRUCT_OFFSET (GtkPrintOperationPreviewIface, ready), + NULL, NULL, + g_cclosure_marshal_VOID__OBJECT, + G_TYPE_NONE, 1, + G_TYPE_OBJECT); + + g_signal_new (I_("got-page-size"), + GTK_TYPE_PRINT_OPERATION_PREVIEW, + G_SIGNAL_RUN_LAST, + G_STRUCT_OFFSET (GtkPrintOperationPreviewIface, ready), + NULL, NULL, + _gtk_marshal_VOID__OBJECT_OBJECT, + G_TYPE_NONE, 2, + GTK_TYPE_PRINT_CONTEXT, + GTK_TYPE_PAGE_SETUP); + + initialized = TRUE; + } +} + + +void +gtk_print_operation_preview_render_page (GtkPrintOperationPreview *preview, + gint page_nr) +{ + g_return_if_fail (GTK_IS_PRINT_OPERATION_PREVIEW (preview)); + + GTK_PRINT_OPERATION_PREVIEW_GET_IFACE (preview)->render_page (preview, + page_nr); +} + +void +gtk_print_operation_preview_end_preview (GtkPrintOperationPreview *preview) +{ + g_return_if_fail (GTK_IS_PRINT_OPERATION_PREVIEW (preview)); + + GTK_PRINT_OPERATION_PREVIEW_GET_IFACE (preview)->end_preview (preview); +} + Index: gtk/gtkprintoperationpreview.h =================================================================== RCS file: gtk/gtkprintoperationpreview.h diff -N gtk/gtkprintoperationpreview.h --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ gtk/gtkprintoperationpreview.h 1 Jun 2006 20:34:39 -0000 @@ -0,0 +1,75 @@ +/* GTK - The GIMP Toolkit + * gtkprintoperationpreview.h: Abstract print preview interface + * Copyright (C) 2006, Red Hat, Inc. + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2 of the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library; if not, write to the + * Free Software Foundation, Inc., 59 Temple Place - Suite 330, + * Boston, MA 02111-1307, USA. + */ + +#ifndef __GTK_PRINT_OPERATION_PREVIEW_H__ +#define __GTK_PRINT_OPERATION_PREVIEW_H__ + +#include +#include + +#include "gtkprintcontext.h" + +G_BEGIN_DECLS + +#define GTK_TYPE_PRINT_OPERATION_PREVIEW (gtk_print_operation_preview_get_type ()) +#define GTK_PRINT_OPERATION_PREVIEW(obj) (G_TYPE_CHECK_INSTANCE_CAST ((obj), GTK_TYPE_PRINT_OPERATION_PREVIEW, GtkPrintOperationPreview)) +#define GTK_IS_PRINT_OPERATION_PREVIEW(obj) (G_TYPE_CHECK_INSTANCE_TYPE ((obj), GTK_TYPE_PRINT_OPERATION_PREVIEW)) +#define GTK_PRINT_OPERATION_PREVIEW_GET_IFACE(obj) (G_TYPE_INSTANCE_GET_INTERFACE ((obj), GTK_TYPE_PRINT_OPERATION_PREVIEW, GtkPrintOperationPreviewIface)) + +typedef struct _GtkPrintOperationPreview GtkPrintOperationPreview; /*dummy typedef */ +typedef struct _GtkPrintOperationPreviewIface GtkPrintOperationPreviewIface; + + +struct _GtkPrintOperationPreviewIface +{ + GTypeInterface g_iface; + + /* signals */ + void (*ready) (GtkPrintOperationPreview *preview, + GtkPrintContext *context); + void (*got_page_size) (GtkPrintOperationPreview *preview, + GtkPrintContext *context, + GtkPageSetup *page_setup); + + /* methods */ + void (*render_page) (GtkPrintOperationPreview *preview, + gint page_nr); + void (*end_preview) (GtkPrintOperationPreview *preview); + + /* Padding for future expansion */ + void (*_gtk_reserved1) (void); + void (*_gtk_reserved2) (void); + void (*_gtk_reserved3) (void); + void (*_gtk_reserved4) (void); + void (*_gtk_reserved5) (void); + void (*_gtk_reserved6) (void); + void (*_gtk_reserved7) (void); +}; + +GType gtk_print_operation_preview_get_type (void) G_GNUC_CONST; + +void gtk_print_operation_preview_render_page (GtkPrintOperationPreview *preview, + gint page_nr); +void gtk_print_operation_preview_render_sheet (GtkPrintOperationPreview *preview, + gint page_nr); +void gtk_print_operation_preview_end_preview (GtkPrintOperationPreview *preview); + + +#endif /* __GTK_PRINT_OPERATION_PREVIEW_H__ */ Index: gtk/gtkprintunixdialog.c =================================================================== RCS file: /cvs/gnome/gtk+/gtk/gtkprintunixdialog.c,v retrieving revision 1.22 diff -u -p -r1.22 gtkprintunixdialog.c --- gtk/gtkprintunixdialog.c 1 Jun 2006 04:58:18 -0000 1.22 +++ gtk/gtkprintunixdialog.c 1 Jun 2006 20:34:39 -0000 @@ -275,7 +275,8 @@ gtk_print_unix_dialog_init (GtkPrintUnix (GCallback) gtk_print_unix_dialog_destroy, NULL); - gtk_dialog_add_buttons (GTK_DIALOG (dialog), + gtk_dialog_add_buttons (GTK_DIALOG (dialog), + GTK_STOCK_PRINT_PREVIEW, GTK_RESPONSE_APPLY, GTK_STOCK_CANCEL, GTK_RESPONSE_CANCEL, GTK_STOCK_PRINT, GTK_RESPONSE_OK, NULL); Index: tests/print-editor.c =================================================================== RCS file: /cvs/gnome/gtk+/tests/print-editor.c,v retrieving revision 1.7 diff -u -p -r1.7 print-editor.c --- tests/print-editor.c 31 May 2006 14:06:02 -0000 1.7 +++ tests/print-editor.c 1 Jun 2006 20:34:39 -0000 @@ -262,6 +262,7 @@ begin_print (GtkPrintOperation *operatio int num_lines; int line; + g_print ("begin-print\n"); width = gtk_print_context_get_width (context); height = gtk_print_context_get_height (context); @@ -304,6 +305,7 @@ begin_print (GtkPrintOperation *operatio print_data->page_breaks = page_breaks; + g_print ("found %d pages\n", g_list_length (page_breaks)); } static void @@ -317,6 +319,9 @@ draw_page (GtkPrintOperation *operation, int start, end, i; PangoLayoutIter *iter; double start_pos; + + g_print ("draw-page %d\n", page_nr); + if (page_nr == 0) start = 0; else @@ -430,17 +435,205 @@ custom_widget_apply (GtkPrintOperation * data->font = g_strdup (selected_font); } +typedef struct +{ + GtkPrintOperation *op; + GtkPrintOperationPreview *preview; + GtkWidget *spin; + GtkWidget *area; + gint page; + PrintData *data; + gdouble dpi_x, dpi_y; +} PreviewOp; + +static gboolean +preview_expose (GtkWidget *widget, + GdkEventExpose *event, + gpointer data) +{ + PreviewOp *pop = data; + + gdk_window_clear (pop->area->window); + gtk_print_operation_preview_render_page (pop->preview, + pop->page - 1); + + return TRUE; +} + +static void +preview_ready (GtkPrintOperationPreview *preview, + GtkPrintContext *context, + gpointer data) +{ + PreviewOp *pop = data; + gint n_pages; + + g_object_get (pop->op, "n-pages", &n_pages, NULL); + g_print ("ready to preview %d pages\n", n_pages); + + gtk_spin_button_set_range (GTK_SPIN_BUTTON (pop->spin), + 1.0, n_pages); + + g_signal_connect (pop->area, "expose_event", + G_CALLBACK (preview_expose), + pop); + + gtk_widget_queue_draw (pop->area); +} + +static void +preview_got_page_size (GtkPrintOperationPreview *preview, + GtkPrintContext *context, + GtkPageSetup *page_setup, + gpointer data) +{ + PreviewOp *pop = data; + GtkPaperSize *paper_size; + double w, h; + cairo_t *cr; + gdouble dpi_x, dpi_y; + + paper_size = gtk_page_setup_get_paper_size (page_setup); + + w = gtk_paper_size_get_width (paper_size, GTK_UNIT_INCH); + h = gtk_paper_size_get_height (paper_size, GTK_UNIT_INCH); + + cr = gdk_cairo_create (pop->area->window); + + dpi_x = pop->area->allocation.width/w; + dpi_y = pop->area->allocation.height/h; + + g_print ("new dpi: %f, %f\n", dpi_x, dpi_y); + if (fabs (dpi_x - pop->dpi_x) > 0.001 || + fabs (dpi_y - pop->dpi_y) > 0.001) + { + gtk_print_context_set_cairo_context (context, cr, dpi_x, dpi_y); + pop->dpi_x = dpi_x; + pop->dpi_y = dpi_y; + } + + pango_cairo_update_layout (cr, pop->data->layout); + cairo_destroy (cr); +} + +static void +update_page (GtkSpinButton *widget, + gpointer data) +{ + PreviewOp *pop = data; + + pop->page = gtk_spin_button_get_value_as_int (widget); + g_print ("go to page %d\n", pop->page); + gtk_widget_queue_draw (pop->area); +} + +static void +preview_destroy (GtkWindow *window, + PreviewOp *pop) +{ + gtk_print_operation_preview_end_preview (pop->preview); + g_object_unref (pop->op); + + g_free (pop); +} + +static gboolean +do_preview (GtkPrintOperation *op, + GtkPrintOperationPreview *preview, + GtkPrintContext *context, + GtkWindow *parent, + gpointer data) +{ + GtkPrintSettings *settings; + GtkWidget *window, *close, *page, *hbox, *vbox, *da; + gdouble width, height; + cairo_t *cr; + PreviewOp *pop; + PrintData *print_data = data; + + pop = g_new0 (PreviewOp, 1); + + pop->data = print_data; + settings = gtk_print_operation_get_print_settings (op); + +#if 0 + /* FIXME need to figure out the size */ + width = gtk_print_settings_get_paper_width (settings, GTK_UNIT_PIXEL); + height = gtk_print_settings_get_paper_height (settings, GTK_UNIT_PIXEL); + + g_print ("%f x %f\n", width, height); +#endif + width = 200; + height = 300; + window = gtk_window_new (GTK_WINDOW_TOPLEVEL); + gtk_window_set_transient_for (GTK_WINDOW (window), + GTK_WINDOW (main_window)); + vbox = gtk_vbox_new (FALSE, 0); + gtk_container_add (GTK_CONTAINER (window), vbox); + hbox = gtk_hbox_new (FALSE, 0); + gtk_box_pack_start (GTK_BOX (vbox), hbox, + FALSE, FALSE, 0); + page = gtk_spin_button_new_with_range (1, 100, 1); + gtk_box_pack_start (GTK_BOX (hbox), page, FALSE, FALSE, 0); + + close = gtk_button_new_from_stock (GTK_STOCK_CLOSE); + gtk_box_pack_start (GTK_BOX (hbox), close, FALSE, FALSE, 0); + + da = gtk_drawing_area_new (); + gtk_widget_set_size_request (GTK_WIDGET (da), width, height); + gtk_box_pack_start (GTK_BOX (vbox), da, TRUE, TRUE, 0); + + gtk_widget_set_double_buffered (da, FALSE); + + gtk_widget_realize (da); + + cr = gdk_cairo_create (da->window); + + /* TODO: What dpi to use here? This will be used for pagination.. */ + gtk_print_context_set_cairo_context (context, cr, 72, 72); + cairo_destroy (cr); + + pop->op = op; + pop->preview = preview; + pop->spin = page; + pop->area = da; + pop->page = 1; + + g_signal_connect (page, "value-changed", + G_CALLBACK (update_page), pop); + g_signal_connect_swapped (close, "clicked", + G_CALLBACK (gtk_widget_destroy), window); + + g_signal_connect (preview, "ready", + G_CALLBACK (preview_ready), pop); + g_signal_connect (preview, "got-page-size", + G_CALLBACK (preview_got_page_size), pop); + + g_signal_connect (window, "destroy", + G_CALLBACK (preview_destroy), pop); + + gtk_widget_show_all (window); + + return TRUE; +} + +/* FIXME had to move this to the heap, since previewing + * returns too early from the sync api + */ +PrintData *print_data; + static void do_print (GtkAction *action) { GtkWidget *error_dialog; GtkPrintOperation *print; - PrintData print_data; GtkPrintOperationResult res; GError *error; - print_data.text = get_text (); - print_data.font = g_strdup ("Sans 12"); + print_data = g_new0 (PrintData, 1); + + print_data->text = get_text (); + print_data->font = g_strdup ("Sans 12"); print = gtk_print_operation_new (); @@ -452,12 +645,15 @@ do_print (GtkAction *action) if (page_setup != NULL) gtk_print_operation_set_default_page_setup (print, page_setup); - g_signal_connect (print, "begin_print", G_CALLBACK (begin_print), &print_data); - g_signal_connect (print, "draw_page", G_CALLBACK (draw_page), &print_data); - g_signal_connect (print, "create_custom_widget", G_CALLBACK (create_custom_widget), &print_data); - g_signal_connect (print, "custom_widget_apply", G_CALLBACK (custom_widget_apply), &print_data); - + g_signal_connect (print, "begin_print", G_CALLBACK (begin_print), print_data); + g_signal_connect (print, "draw_page", G_CALLBACK (draw_page), print_data); + g_signal_connect (print, "create_custom_widget", G_CALLBACK (create_custom_widget), print_data); + g_signal_connect (print, "custom_widget_apply", G_CALLBACK (custom_widget_apply), print_data); + g_signal_connect (print, "preview", G_CALLBACK (do_preview), print_data); + error = NULL; + +#if 1 res = gtk_print_operation_run (print, GTK_WINDOW (main_window), &error); if (res == GTK_PRINT_OPERATION_RESULT_ERROR) @@ -467,7 +663,7 @@ do_print (GtkAction *action) GTK_MESSAGE_ERROR, GTK_BUTTONS_CLOSE, "Error printing file:\n%s", - error->message); + error ? error->message : "no details"); g_signal_connect (error_dialog, "response", G_CALLBACK (gtk_widget_destroy), NULL); gtk_widget_show (error_dialog); g_error_free (error); @@ -489,10 +685,15 @@ do_print (GtkAction *action) g_signal_connect (print, "status_changed", G_CALLBACK (status_changed_cb), NULL); } +#else + gtk_print_operation_run_async (print, GTK_WINDOW (main_window)); +#endif g_object_unref (print); +#if 0 g_free (print_data.text); g_free (print_data.font); +#endif } static void --=-xjDvOKJb0tdB52kmWdgp-- From tomasek@ebed.etf.cuni.cz Fri Jun 2 03:11:55 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 2F96F3B01C7 for ; Fri, 2 Jun 2006 03:11:55 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05061-05 for ; Fri, 2 Jun 2006 03:11:53 -0400 (EDT) Received: from ebed.etf.cuni.cz (ebed.etf.cuni.cz [195.113.5.3]) by menubar.gnome.org (Postfix) with ESMTP id 3EDBD3B011A for ; Fri, 2 Jun 2006 03:11:53 -0400 (EDT) Received: from ebed.etf.cuni.cz (localhost.localdomain [127.0.0.1]) by ebed.etf.cuni.cz (8.12.11.20060308/8.12.11) with ESMTP id k5270gLE004827 for ; Fri, 2 Jun 2006 09:00:42 +0200 Received: (from tomasek@localhost) by ebed.etf.cuni.cz (8.12.11.20060308/8.12.11/Submit) id k5270gdU004825 for gtk-devel-list@gnome.org; Fri, 2 Jun 2006 09:00:42 +0200 Date: Fri, 2 Jun 2006 09:00:42 +0200 From: Petr Tomasek To: gtk-devel-list@gnome.org Message-ID: <20060602070042.GA3470@ebed.etf.cuni.cz> References: <1149203639.27455.9.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1149203639.27455.9.camel@localhost.localdomain> User-Agent: Mutt/1.4.1i X-Homepage: http://www.etf.cuni.cz/~tomasek/ X-Echelon: bomb Arafat Intifada bus kach drugs mafia boss heroin spy Semtex Saddam Al-Qaida Usama bin Ladin Bush Sharon X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.534 tagged_above=-999 required=2 tests=[AWL=0.065, BAYES_00=-2.599] X-Spam-Score: -2.534 X-Spam-Level: Subject: Re: Print preview api X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 07:11:55 -0000 On Thu, Jun 01, 2006 at 07:13:59PM -0400, Matthias Clasen wrote: > Ok, after a lot of work (mostly by John and Alex), > we finally have a proposal for a print preview > api that will allow us to use an external viewer > by default, but also support internal preview. Hi! I think, this is very unfortunate. Many people will not want to use the external viewer (for reasons discused earlier), so everyone will write his own preview widget? Why not just have official internal preview widget like gnome-print has and support it by deafult? P.T. -- Petr Tomasek From shree_poroly@yahoo.com Fri Jun 2 06:49:17 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id DD9063B03E7 for ; Fri, 2 Jun 2006 06:49:10 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19278-08 for ; Fri, 2 Jun 2006 06:49:06 -0400 (EDT) Received: from web53308.mail.yahoo.com (web53308.mail.yahoo.com [206.190.49.98]) by menubar.gnome.org (Postfix) with SMTP id 574673B110A for ; Fri, 2 Jun 2006 06:48:56 -0400 (EDT) Received: (qmail 1625 invoked by uid 60001); 2 Jun 2006 10:48:55 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=opsX4ZJJjJ3RSp61u8057G5DaMkib9ROhHy+AzeYX+l7J8HSwJa+UppJPxFDKOjVDg5ivFj+xumB8simRH1oUSf2tMk9h8YEuyY6OEPoTApYincgsxe7YmLfJe3+jDCaLeD7TV1kXmnpIstEupgel4fQt9kXW1CGDMkwXy+xReA= ; Message-ID: <20060602104855.1623.qmail@web53308.mail.yahoo.com> Received: from [61.246.61.209] by web53308.mail.yahoo.com via HTTP; Fri, 02 Jun 2006 03:48:55 PDT Date: Fri, 2 Jun 2006 03:48:55 -0700 (PDT) From: shree nidhi To: gtk dev MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-596188450-1149245335=:1049" Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=1.399 tagged_above=-999 required=2 tests=[AWL=-3.076, BAYES_50=0.001, DNS_FROM_RFC_ABUSE=0.2, DNS_FROM_RFC_WHOIS=1.447, HTML_40_50=0.496, HTML_IMAGE_ONLY_12=1.867, HTML_IMAGE_RATIO_02=0.463, HTML_MESSAGE=0.001] X-Spam-Score: 1.399 X-Spam-Level: * Subject: Fwd: test X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 10:49:17 -0000 --0-596188450-1149245335=:1049 Content-Type: multipart/alternative; boundary="0-601274911-1149245335=:1049" --0-601274911-1149245335=:1049 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Note: forwarded message attached. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --0-601274911-1149245335=:1049 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit

Note: forwarded message attached.

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com --0-601274911-1149245335=:1049-- --0-596188450-1149245335=:1049 Content-Type: message/rfc822 X-Apparently-To: shree_poroly@yahoo.com via 206.190.49.100; Thu, 01 Jun 2006 21:38:26 -0700 X-Originating-IP: [202.71.129.68] Authentication-Results: mta129.mail.mud.yahoo.com from=galieosoft.com; domainkeys=neutral (no sig) Received: from 202.71.129.68 (EHLO smx1.net4india.com) (202.71.129.68) by mta129.mail.mud.yahoo.com with SMTP; Thu, 01 Jun 2006 21:38:26 -0700 Received: from [125.22.33.12] by smx1.net4india.com with smtp (Exim 4.51) id 1Fm1a8-00025h-AB; Fri, 02 Jun 2006 10:18:21 +0530 OM-Header: origin=omniqube Received: from unknown (192.168.0.89) by SMTP-Receiver; Fri, 2 Jun 2006 10:07:06 +0530 Subject: test From: Nidhi To: nidhi@galieosoft.com, shree_poroly@yahoo.com Content-Type: multipart/mixed; boundary="=-k0bJJnk7Qaq1V0+G97NB" Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-1) Date: Fri, 02 Jun 2006 10:12:00 +0530 Content-Length: 21206 --=-k0bJJnk7Qaq1V0+G97NB Content-Type: multipart/alternative; boundary="=-rVG5rqf50PHPN/AXL0Ln" --=-rVG5rqf50PHPN/AXL0Ln Content-Type: text/plain Content-Transfer-Encoding: 7bit I have developed an application for an handheld device, the initial window will look like this : But the device is having rectangular display if i place the window as it is my drawing area will look compressed, so i dont want to compress my drawing area. If i can tilt the window and display i hope my drawing area will look like enlarged. Is there any way to tilt an application window as shown please help me out. --=-rVG5rqf50PHPN/AXL0Ln Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
I have developed an application for an handheld device, the initial window will look like this :









But the device is having rectangular display if i place the window as it is my drawing area will look compressed, so i dont want to compress my drawing area. If i can tilt the window and display i hope my drawing area will look like enlarged.







Is there any way to tilt an application window as shown please help me out.


--=-rVG5rqf50PHPN/AXL0Ln-- --=-k0bJJnk7Qaq1V0+G97NB Content-Disposition: attachment; filename=test1.map Content-Type: application/octet-stream; name=test1.map Content-Transfer-Encoding: 7bit --=-k0bJJnk7Qaq1V0+G97NB Content-Disposition: attachment; filename=test2.map Content-Type: application/octet-stream; name=test2.map Content-Transfer-Encoding: 7bit --=-k0bJJnk7Qaq1V0+G97NB Content-Disposition: attachment; filename=wintilt.sxw Content-Type: application/vnd.sun.xml.writer; name=wintilt.sxw Content-Transfer-Encoding: base64 UEsDBBQAAAAAAJZQwTSAkGt+mxsAAJsbAAAtAAAAUGljdHVyZXMvMTAwMDAyMDEwMDAwMDEzNzAw MDAwMTM0REUzMjdBMTMucG5niVBORw0KGgoAAAANSUhEUgAAATcAAAE0CAYAAABJtnScAAAABHNC SVQICAgIfAhkiAAAABV0RVh0U29mdHdhcmUARXllIG9mIEdub21lCx+PrwAAGzFJREFUeJzt3X1w XOVh7/Hfvmglr23ZMS/BAWNbmBcrYPOSmCQ0kUMgwYQyIS+9uDdphyZtYzFzk6bJVWZaT5JbXXqH zjT3TlM70Et7XQ+95OIggkOhxAnrtBjiYBAGS7Zky/KLkLEl68162Zdzzv1jdY53VytZu9rVrh5/ PzMaafe8PUe757fPeZ7nnPVJcoQ5o2phtQLBoIb7zqY97/f7S1QioPzYtq2gJLUeP65jp8+oZ2BA I9FYqcuFHLR3dWn3rl165I+/qurqas2bN08VFRWEHS5Kw8PDuu222yQpGW7HTp/RL99sLmmhkJ+9 e/cqeu6cBgcHFQ6HFQwGVVlZqWAwmHX+eDw+5fp8Pp/3t9/v9x47jiPbtuU4U1f0Z7p8IaSWYap5 UuebbBm3vJP9Lib2Y6LJyu++1/r6+7zHQUk609+ffPM5jvzTKAjKh+M4io+NanR0VJZlye/3q7Ky UhUVFZLST1dt21ZVVZUcx5HjOGlvKPfNMZ03IlBuotGogsGgomNR77mgJA2NjimWSMhxHAXGD4Zd zzbJTiRkJRJy3E9cx5HcN3/G3z6/Xz6/Xxse3Di7e3URsx1HtmUpOjysnp4eLViwQBUVFXIcR6FQ SBUVFV7ISclaWzwel2VZXrgFAgFvvmAwmFbbAqbrBz/4gWKxmOLxuBKJxJS1dJ/Pl6xZBYN69NFH C7L82NiYqqqqNDY25s0XlKR4IqGEZcm2HVl+W5KUiMX01P/+Bx1+t1vv9fVraHR0yp07fvq0Xvjn bYolEjn+WzAjjqPoyIh+9PQOVS2sVmU4rGBlpQIVFfrhw5tUVVWlYDCoh//u72UnEkrEYrIty/tw 8gcC+uHDmzR//nxvXtrrkKvh4WE9/vjj055/3759euSRR3Tu3LmCLH/69GktXLhQI8PD3jxBSUpY luIJS5ZtezU3Kx7XoZNdemnfmxNOVbOdvr75H/+u6MiI4glr2gXMxcZP1mk0GtWze14ryvoLvb3N //lBLZo/X99+/IkClyzd6rU364H77kt77uCJk3o98rK6urq0ePFiVVRUKDYyoi3f26yO7lN6r69f w2Njajl+Qm/sjqirq0uXXHKJFi5cqKqqKgUCgaKWGeYZHa/8dHZ2Tmv+nTt3qr+/31tupsufPXtW Pp9PwyMj3jxBSYolEorG40pYloLjb2w7kdDx02cUz1ITc09pUtmWpUR0TNGMButt3/mWJKntZJf+ +//9iff81++7Vx9dfYOOnz6jzdu2X3BnPrl2jfrOndNPdv/7tHY+1Z9/8QGtWblS3/mHf9Tp/n5J 0lc+dafuuvVm/d3Pdur1tnZJ0t233qIvfvwOPfyjrTPaniQtmDdP1eHwhP9HMbzVcTTtcfv+tzQ6 OKCenh75fD5VVVUpEY2q7WSXdr62N+t8qaems9HIDLO4HVUX6rBKNTIyosR4vmQuf91116mtrS1t /sznUpcfGRnRggULstfcYu6p6fgb27Ys9Z87p2g8ntbj5fP50t787jTbtmUnEpOell575QdUWVGh odFRBQMBra1ZmVynnGmdym7860cvOM9k9nd0as3Klbph2VU62dMjSfrgiqu9cu1paZUk3bRyhfYf 7dRINDqj7UnJsz5Js3Kanvl6OLat2MiIBgYGFA6HZdu2ErGYTvb0euVxxtvr3Pmqq6sVDofT2unc Dgba4HAhlpU8Y0vk8H6PxWKybXvC8rW1tZKSYdbS0iJJWZ9LXd5tSx5JaT7zam5j420xCbfmZlmK xuNT1jz8Pt/5MEwkZFuWxmITx8n1DA7q0upq3bhiuV5+a7/W1tQoFo8rXFkpx3E0Fovp0upq/ZcH 7tc1S5dqXiikd3vP6p9e+oX2tR+WJDV97y/VOzSkr/3t/0p7/I8vvqSv3vNphSsr9c+7fqUXfvv6 hO2/3tauL3/qk/rg8qv189/s1WWLFmnpkiWSpBuWXaWxWEyVFRWqXX61Hnv+BY3FYjlvryIQ0B/d 82l94qYbFa6s9LY9FovJJ+l3P3K77l33IV26aJF6Bgb0r3tf187f7JXjOPq9uo9r4/o6ffvxJ3Sk u1t/9vnP6RM33aiGJ/5JbSe79J0vfUFDIyP68fMvTPo6uNxOhkQ06oVbNBpVIhrV2aGhtNfHGQ+9 oaEhDQ4OKhQKeZ0RwWDQq8kRcLgQ9wM2l3CzbdsLp9Tl9+/frzVr1kg6H2qu/fv3e9tIXd6yLNm2 PbFDQUq2sdmWJcfdmG0rlkjImiLcUlvXbCvZ25pt/n2H2nT3bbfqtmtXadfr+7TuulV6rfWg7vnw h7xlApLeaGvXthdfUlUopL/88u/r4fvv0x/+j785v6KM9S8Kh7VxfZ1+vf9tfe6Oj2nj+k/o53te nbD9o+++q75z53TTyhWSZemm5VdraGRER0+9p5tWrtC8YFA3LLtKFYGAXm89eH4bOWxvY90ndM+H btPOV1/TL99o1l899AdaGA7Lisd1/8c+qoc+c7d+03pQf/OTHfpi3cf10GfulmPbevaVPXrnSIe0 vk6rr7pS7SdO6IPLx2uVS5fqYOcx3bhiubb+bGfW/21qE4H7t21ZSsRievKlXygUDisQDMq2LDW3 tav70MHMFejJX+xSKBxWRdU8BUMhBSoq9N8e+kOFw2FvzBydDJiKG065nJZK52tsmcvv27fPG4zr 2rdv34T1u8vbti3LsjQWzRgK4krEYvK7NTfbTvaiZqmJZWOPDy/INv/g8LDeOdqpW69dJb9t6/Yb btD/3PFTL9wSsZiOd3frxKlTWrpkiRYtWKC+oSEtveSS9PU5SnscTyT07S0/1uDwsNavXaPFCxZM Wt4329p15623aOXll+vmmpV6s/2wjp16T2tqVuq6DyzVrauu0ZGud3W6tzev7a1fm/yk+ZeXdmlg eFixeML7n957+4clSY/9bKdOnT2rH/ed1UdW36B7b1+nHS9HdKDjqBKWpdrlV+vVt9/RwnBYPQMD uu7KD2jZkiWqDof1Zlv7tF+Ly1bWaP2nP5323IH2w3r7317wPsAc25bP79fTTz2lA8eOqaunV4Mj IzrQflhdB95RT0+PlozXbiXRyYAp5VNzcxxnQrhNtXzmtNTl3RpcIiX80sLNisckhdwllbDs5LAB yTsYvBVneazxU6IJO2E7eu1Ai9ZcU6MHPv47CldVqnm8EV9OMhhXXXWl/uIPvqIlCxfqxOnTuqS6 OlnotPWlr39kbEz9g4PJsrs7mWX7kvTGoTbdeestuvXaVVq7apWeeP5f1XXmjL7ymbt148oV+vD1 1+tX+97Ie3uXLkqWt39oaPyFOt92edmiRZKkU729sm1b7/Umrwu9bPGi5Km8ZantxEl9cMUKralZ qdbOY+o/d06rl1+tNdfUqOPdbm+7U3Fr3ZK0f7wd0XW644jsREIbbl+nyspK+f1+Pffqa3qr46ie +eWvzs935LDGhgbV29vrnZYGAgE6GTAlL1zGA+iOO+7IOt8rr7zi/e04Ttop5oWWv/322ydd3v2d 2nySHm7jA3ndjcUSCSViUU3H+ZrbxPltK6FXmpv1J/ffp4133ak9b7+j0ZHh8QLaSsSiemjDPVp6 yRJ9+Xs/0KmzZ/XYd/+rrrnyyrT1OY4mfewee5OV97cHDkiS7vvYR1Q9P6zfvvOO+oaGFIvH9anb btX7Fi7Uq2/vz3t7o9Go5s+bp4WVIQ2PjqoqFPKmn+7r15WXXapLFoTV3dOrK8ZrRGf6+rzl97e3 q3bFcn32ox/RK2+/reHRUdXdvFbrb1mrNw4enPbrMBnHtmUlEgoGg1qwYEGyXS0UUkd3d9q63UHB fX193nWqktI6Gc7/P85fApN5xQOdEReX1Ib9qaROdxxHsfGzkdTl169f780TiUQkyXvujjvu8J5L XT5bjS8t3Bzblp3yd8KyZMXjaTW0bNzTnElrbo6jE6dO6fip93T1Fe/XfzQ3n59vvObmNorX3XKz zo2O6qrLL5ckfej667V3vHcksyaV/vh8TSmbM2fPqrO7WyuWLtWJ997TqfFe05ajnbr5ums1NDyi lo6j3j851+292dau31m7Rn/24O8pVBFS5Xi42ZalZyMRPfylL+rrD3xOT774b/r98VPGZ3f/2lu+ ua1ND959l6656kr9/Y6fKuZ2iS9bpv+z8/lJasTJsrqvj1ubzvwtSXYinrzixLK8Ed7y+dQzOOSd qvr8fq+9bnBwUPPnz5ff71c8HlcoFFIgEPA6GNxPTbch1w03v9/vXfUQCAQIuItEZm/prl27ss6X GkK2bXvhlLr8rl27dNddd2nXrl1p68t8LnX5bDJOS+Nem5scR/HxS6/s8QMis/FaShkK4p6mZRsX Nz5M5IdP/ouWXfF+7Wl+K2U+R3YiocefadJffPUh/dH9v6vd+97QE8/+TH/8wOf0n+7+lF7bv//8 PyRj/Rd6nOr1Ay1asXSpXm9p9eZrPnRIN193rX5z4J2sbVrT3d6Pn96hZZdfrjXXXqutT+/Q8ive r0sXL5adSGjHrl/KL58+f+cn9aNv/7neO3tWW3f8VE//YpfX2/x2W3uyp9O21XL4sKzxNs+A36+3 Dh70tpM5xtBxHCkl+Hxu0GT8dod+PP/qawrNmyd/ICDbttXeckC9x48ll3VfW9vWT3f/WqGqKgUr KxUMheQPVuhbX/qCd0r76P/b4V2el7ziwZZ8fvkDAX3rS1/QvHnzvF5Xws18maeV0xUd7wDIXP7F F1+csK5sz7nLZ7tRhE+Ss3nbdjW3tevsyRPeJ/3hPa9o1cfuUHdry4SFJtNzrFM33XPvtOdHAbjn xz5f+vW+Wea7+vob0p463nZIR3+793wnw3hwPvnUU3rj8BEdPXVK/eeGdbztkM50HNHX7vusFixY oGAwqB89+5z+tvGv0uc7dFBnjnboa/d9VosWLVI4HPZqfDDbY489pkceeUQ7d+6c9jLPPPOMvv/9 7xdk+Wg0qiuuuEKRSESNjY2SspyWpjYcH9r9cvJaxPELWeVM0qg8fjriHx9ygPLUmfFB1XfyhKx4 XB9fc5NCoZD8fr9ebn5L+9oP69mf/zxtvrGhIfX29sqyLIVCIcWjY1POJ52/zRHhZj7HcfTNb35T IyMjyXGVKe33mXw+n3drLndc2kyXr15UPWG4Ulq42Zbl1dxWfnhdfjuZ1maFcpZsckh2MsyfPz/Z ThYK6dDJrrTX0bFtxUZHNTAwoIqKiuSdG2KxKeerqqryApNwM9/GjfndDcg9rZzp8u9bvESZNxWf UHPD3DDV0Ixs7aKpl865v5N/+71PwVAoJH8goJ6BgbQauHepVizmvZkcy7rgfGNjY4QbZsWSJe/T 0NBQ2nMTWuHOnjwxawVC6dl2MoxGR0eT99FKJNR9sFX93e+mz2clNDw87PWExsbGppyvv79fiUTC 64AAimlRdbV3hxDXhHBr+/XuWSsQysNPjhxJe3zsjX1Z53sqc759E6/jzTYfUGzf+MY3JvTKp4Vb YHygZilHo7e2tl54JgAYV1tbm/UO0tm/RUSlCZna2lrvdiYAMBNl0xjiXlIBAIVQNuEGAIVEuAEw 0qRtbuUq8/Q19Q4Cc5WJ+wSU2pwJNzcA6uvrJ0zbsmXLnAwEE/cJKBc5hVvm/cxdqV/ikO3vmYpE Il4AZBum4vP58gqDfMpYqP0q5D5dqEyl7IWmBxylknObW0tLy4Sf1GnFNNn4u3zG5bkH3WSBPVsK tU+T7Uep9w8olYJ2KEx1INXW1no/uXBrOBc62Ddt2qRIJKLVq1fntP5sMsvoPs787f6d636VYp9S TVbm1P2bbNpUj/N5fYFimZXeUreW5P6U+gBIPVXKpTypy6Supxz2K9v2s50SXqjMqdOnuz/l9H8A XDl3KGS+cWlPmVsu9Hrl83ryHkA5yjnc8n0jl9unebmVpxDcWlPq72yKse8m/j8xt83aUJB8Q3G6 PaBbt27Vpk2bLnhN7GQH/Wz26hV6n3KRuZ+FCKVirBOYqZJcoZDrm3/Lli0l+5KRYh2oxdqnC9Xa CoHwwlwwKzW3zEbmXA+89evXa8uWLV5NJtXWrVslqaA1nNTy5tLonst+zfY+pZYxs8zTCcOp/if5 rhMoprRvv+o9fkx7tm+T4zizfssjd3jEhQ6IzEuV3GCYy/eBM3GfgNlSW1urvr4+dXZ2qqmpKfu3 X80FmbUcEwLAxH0CSm3OhZuJB76J+wSUGrc8AmAkwg2AkQg3AEaass2N7zUAMFdNGm4M1AQwl2UN t9bW1oIMwCz0rXoAmKdYowWKPhSEYQ4AJlPMK1noUABQEsVu0y9quJXqYneUL9pyMVvm3BUKMMtM bqgATIVwQ8lkuw8cAYdCoc0NgJEINwBGItwAGIlwA2Akwg2AkegtRdFMNqaNXlHMBsINRTPZt8+7 wTbTLw4CpkK4oagmC7jU6UAx0OaGokutqQGzhXDDrCDYMNtm5bSUi6WRivcDZkNRw81xHO4MAqAk soZb6h108w0nx3G0fv161dXV5VcyABeF5557rijrnbTm5t5BN9+2Ep/PR7ABmJaGhoa8lrNtW9/9 7nezTivKaSltKgByletXEtTW1sqyrEmn01sKYM6Zzi3KCTcARiLcAJStmTRxEW4AypIbbPkGHOEG oOxkBlo+AUe4ASgrU90qKxfcFQRAWSnUdcjU3AAYiXADYCTCDYCRaHMDUDamc+XBdBFuAMpCoa9J J9wAlAXHcXJexrbtSacRbgDKAncFAXDR464gAC5ahBsAIxFuAIxEuAEwEuEGwEiEGwAjEW4AjES4 ATAS4QbASIQbACMRbgCMRLgBMBLhBsBIhBsAIxFuAIxEuAEwEuEGwEiEGwAjFfU7FGrW1aQ97tjb wXSmM53pWacXmk+Ss3nbdjW3tav3+DHt2b5NjuPk/GUNqdyv6KqrqytQMQGYasOGDWpoaMgpcyKR iOrr62VZlgKBgPr6+tTZ2ammpiY1NjZK4rQUgKEINwBGItwAGIlwA2Akwg2AkQg3AEYi3AAYiXAD YCTCDYCRCDcARiLcABiJcANgJMINgJEINwBGItwAGIlwA2Akwg2AkQg3AEYi3AAYiXADYCTCDYCR CDcARiLcABiJcANgJMINgJEINwBGItwAGIlwA2Akwg2AkQg3AEYi3AAYiXADYCTCDYCRCDcARiLc ABgpWMyV16yrSXvcsbeD6UxnOtOzTi80nyRn87btam5rV+/xY9qzfZscx1Fra2veK62trZUk1dXV FaiYAEy1YcMGNTQ05JQ5kUhE9fX1sixLgUBAfX196uzsVFNTkxobGyVxWgrAUIQbACMRbgCMRLgB MBLhBsBIhBsAIxFuAIxEuAEwEuEGwEiEGwAjEW4AjES4ATAS4QbASIQbACMRbgCMRLgBMBLhBsBI hBsAIxFuAIxEuAEwEuEGwEiEGwAjEW4AjES4ATAS4QbASIQbACMRbgCMRLgBMBLhBsBIhBsAIxFu AIxEuAEwEuEGwEiEGwAjBUtdAFw8Irt3e3+vr6srYUlwMbhguNXW1ua98pp1NWmPO/Z2MP0inq6U cCvH8jG9xO+PAvNJcjZv267mtnb1Hj+mPdu3yXEctba25r1SNxDr+HRGCmpuyGbDhg1qaGjIKXMi kYjq6+tlWZYCgYD6+vrU2dmppqYmNTY2SsrhtDS1BtfS0pJD0YEkAg2zaVrhVltbmxZomY8BoNzQ WwrASIQbACMRbgCMRLgBMBLhBsBIhBsAI01rKEhLSwvj3ADMKdMexEugAZhLOC0FYCTCDYCRCDcA RiLcABiJcANgpBmH20xuZgkAxVKQmhsBB6DcFOy0lIADUE4K2uZGwAEoFwUNN65iAFAuChZuBBuA clKQcCPYAJSbGYcbwQagHDGIF4CRCDcARiLcABiJcANgJMINgJEINwBGItwAGIlwA2Akwg2AkQg3 AEYi3AAYadpfypyPmnU1aY879nYwnelMZ3rW6YXmk+Rs3rZdzW3t6j1+THu2b5PjOGptbc17pe5N K+vq6gpUTACm2rBhgxoaGnLKnEgkovr6elmWpUAgoL6+PnV2dqqpqUmNjY2SOC0FYCjCDYCRCDcA RiLcABiJcANgJMINgJEINwBGItwAGIlwA2Akwg2AkQg3AEYi3AAYiXADYCTCDYCRCDcARiLcABiJ cANgJMINgJEINwBGItwAGIlwA2Akwg2AkQg3AEYi3AAYiXADYCTCDYCRCDcARiLcABiJcANgJMIN gJEINwBGItwAGIlwA2Akwg2AkQg3AEYKFnPlNetq0h537O1gOtOZzvSs0wvNJ8nZvG27mtva1Xv8 mPZs3ybHcdTa2pr3SmtrayVJdXV1BSomAFNt2LBBDQ0NOWVOJBJRfX29LMtSIBBQX1+fOjs71dTU pMbGRkmclgIwFOEGwEiEGwAjEW4AjES4ATAS4QbASIQbACMRbgCMRLgBMBLhBsBIhBsAIxFuAIxE uAEwEuEGwEiEGwAjEW4AjES4ATAS4QbASEX9DgUAyEUkEinYugg3AGXB/e6VQiHcAJQFx3FyXsa2 7UmnEW4AykKu37hXW1sry7ImnU6HAoA5Zzptc4QbACMRbgCMRJsbgLIyVa9pS0vLtNdDzQ1AWZks wHIJNolwA1CGMoMs12CTCDcAZcoNtHyCTSLcAJSxfINNItwAGIpwA2AkhoIAKBuzdleQQm4IAKYy a3cFKfSGAGAytm1PeRF8PrKGW2tr64x6KVzPPffcjNcBwGz333+/Dh06VPD1Fr3NraGhodibADBH 2bZdlGCTZqlDIZ/7NDmOk/NyAGZfvsfrhe7HNlNlNxSETgxg7sj3eJ2N47yk4UanBWCuUh/fJQu3 Uu84gOIr5XFeknAj2ICLR6mO91kPN4INuPiU4rif9XArxPg5AHNLKY77kpyWEnDAxaNUx3vJOhQI OMB8pTzOSzoUhIADzFXq47vsBvECQCHM2v3cynkkM4DCKKfjdVbCLd9uYIaNAHNHuR2vRQ+3fO/T VIz7OwEojnI8XrOGW6GqltXV1XrssccKsi4AyEXWcNu0adNslwMA8lJfX5/1+bRws+JxSZLP5yt+ iQCgCGzblpQRbpdfs0qbt20vSYEAFEZzW7sORn6lTV/4vFavXq1ly5bpgT/9uh78kz/Ne/rixYtV WVmpQCAwZyo/E05Lm9vaS1EOAAVy+shhxcbG1Nvbq+7ubklSbGxMUvL4zmf6wMCAKisr5ff751a4 uTsEwAznes6oublZXV1dWrx4cfJxynGe6/SqqioFg0H5/XNn3L9PklPqQgBAoc2dGAaAHPx/YMnV s9b8aj0AAAAASUVORK5CYIJQSwMEFAAAAAAAllDBNLasV216HwAAeh8AAC0AAABQaWN0dXJlcy8x MDAwMDIwMTAwMDAwMTM0MDAwMDAxMzdBQjUxQTdGMS5wbmeJUE5HDQoaCgAAAA1JSERSAAABNAAA ATcIBgAAACQVvTEAAAAEc0JJVAgICAh8CGSIAAAAFXRFWHRTb2Z0d2FyZQBFeWUgb2YgR25vbWUL H4+vAAAfEElEQVR4nO3de3hc5WEm8PecGd1tSb6C8QUsbNcShRAMsg2bWoBJIFwCXdJC+zRZIKGR S7fbbGG7adNsku4fLm36bLtIlDalSdjCEggEtgmlEMZJHYIxxBgs2QZ8wYCNbUmj0Whmzn3/kM7x jOZyzpyZo/nm6P09jx+kkWbmNbZef+c73/mOBMACAFmWQURUD0zTLPh4lEVGRGERBYDXXnsNqqZC ySjIZDJITU5iMpVCanISqXQamUwGGUWBrmmQJKnWmYmIcnzjG98AMF1obW1tWNS8CK2trdB1HWNj Y0gmk1AUBYZhwDRNGIZR8IVkWYYsy4hGo2hoaEA0GoUkSSw+IpoVTz31lPNx1P7Asizouo5MJoOJ iQmMjo4ilUpB0zSn1EzThK7r0HV96snRKJqbmzG/fT4WdC7E/Pnz0dHejuaWFs7JEVHgjhw5kvO5 U2imaaKpqQlNTU2IRCLo7OyErutOkRmGAcMwoOs6VFWFqqpQlKlD1MR4AqdOnkImk8GJEyec4R8R UVDGxsbyHosW+L6qGBoaCuqlq+qZZ57BvffeW+sYRHPCgQMHKnp+LBZDf39/0Sktp9Dsb7jvvvsw MjKCeDyOVCoFVVWdU6SWZTm/7MdkWUZDQwPuueeeioLWkizLvub8LMviXCHNOX7/3hebh6+mvBGa ruv4yle+gmeffdbzizzxxBNVDVULQ0NDiMVinr9/27Ztvp5HVM/8/r23nxe0vBGaaZrYsGEDFi1a BE3TnJMAxT5++eWXnZME9a6vr8/T9838g/T6PKJ65vfv/Wz+g593KtKyrJzPe3p68p408zcy8zlE RLXgFFqhY+J169YBAC666CLnsSuuuAIAsHXr1qCzCaFQoRNRLlF+TkouFjt48KDz8YYNG7Bx40bn 8xdeeCG4VIIQ5Q+JqB6I8PPiuvq10PKLuTAJLsIfDlG9qfXPDZfzF1DrPxSielbLnx/XQvNyUiBs 6mVRMJGIavnzk1do2ScH7JMCwNSOHK+88orzefZJgTAuLmWpEZWv1j83TqHZSy+yLyq3Twrs3bvX eWznzp0Ack8KRKOBXUFVU7X+wyGqJyL8vOSN0GaWk5eTAk1NTdVNJRAR/pCIRCfKz0ne0KqhoQEA cN5553l6gcWLF+PFF1+saijRhX0OkagQv3/vZ/PnJWc/NABobGzE3XffjXQ67eyFNvOidHs7Ifvj lpaWWQsclO7u7rK+3/7/Ve7ziOqZ37/32RtaBCmv0L72ta8hmUwinU573g8tk8lAUZTAwwZl+/bt tY5ANCfcdNNNgb5+3c7md3d3V+Xs6pYtW6qQpnq6ertwaNehWsfIwUzuRMsDiJkJQEX7D7ot6s8r tHraD62SrXtmazsTIsrld/9BL/up1f1+aGGboBfxX1RmcidaHkDMTLag9lPLK7S5vB8aEc2eIPZT c90PzQvuh0ZEIij74vQrrrgidId5RBQO3G1DMF29XbWOkIeZ3ImWBxAzUynV2KWDhUZENWeXWaWl lndxOhHRbJpZYpWUGkdoRFQzxcrLb6nlLdvws+AtjPuh1YqIa4eYyZ1oeQAxM81U7V068gotez+0 Qnbu3OmsQ3NeJKT7oRFRfXHdD82LMO+HRkT1g/uhEZHQyln3mldoc3U/NFGIuEMCM7kTLQ8gZiZb UPup5RXaXNwPjYhm16zttkFEFLRZ222DiGg2zMpuG1RbIs55MJM70fIAYmYKGguNiEKDhUZEdcle eZGNhUZEdSl76ZiNhSYYEfewYiZ3ouUBxMxUTYqiQFGUnMswWWhEVJfi8TgSiQQymYzzGAuNiOrS sWPHcPz4ccTjcecxrkMjoro0PDyMkZERnDp1ynmMhSYYEdcOMZM70fIAYmaqpsEnfwA1k0HyNAuN iOrc+r6rcPLdd4C16zBy9CgAzqERUZ26eN1aLD1/Tc5jHKERUd26eN1a7Mn6nCM0wYi4doiZ3ImW BxAzUzU99tDf4bt/87/w80e+4zzGQiOiuvTU3z2IB//8m/idW25xHmOhEVFdKrkOjbeiI6J6wnVo dUDEtUPM5E60PICYmaqp5Do0jtCIqJ5wHRoRhUbJdWgcoRFRveE6NMGJuHaImdyJlgcQM1M1lVyH xhEaEdUTrkMjotDgfmhEFBpch1YHRFw7xEzuRMsDiJmpmrgfGhGFBtehEVFoFFqH5hTazBt2EhHV G47QBCPi2iFmcidaHkDMTEFjoRFRaPCQk4hCg4VGRKHBQ07BiLh2iJnciZYHEDNT0FhoRBQaLDQi Cg0WGhGFBgtNMCKuHWImd6LlAcTMFDQWGhGFBguNiEKDhUZEocGFtYIRce0QM7kTLQ8gZqagcYRG RKHBQiOi0GChEVFosNAEI+LaIWZyJ1oeQMxMQWOhEVFosNCIKDRYaEQUGiw0wYi4doiZ3ImWBxAz U9BYaEQUGiw0IgoNFhoRhQYLTTAirh1iJnei5QHEzBQ0FhoRhQYLjYhCg4VGRKHBQhOMiGuHmMmd aHkAMTMFjYVGRKHBQiOi0GChEVFosNAEI+LaIWZyJ1oeQMxMQWOhEVFosNCIKDRYaEQUGiw0wYi4 doiZ3ImWBxAzU9CcQpMkqZY5iIgqxhEaEYUGR2hEFBocoQlGxLVDzOROtDyAmJmCxhEaEYUGR2hE FBocoRFRaHCEJhgR1w4xkzvR8gBiZgoaC42IQoOFRkShwUIjotBgoQlGxLVDzOROtDyAmJmC5hSa ZVm1zEFEVDGO0IgoNFhoRBQaPOQUjIhrh5jJnWh5ADEzBY2FRkShwUNOIgoNFhoRhQYLTTAirh1i Jnei5QHEzBQ0FhoRhQYLjYhCg4VGRKHBQhOMiGuHmMmdaHkAMTMFjYVGRKHBhbVEFBocoRFRaLDQ BCPi2iFmcidaHkDMTEFjoRFRaLDQiCg0WGhEFBosNMGIuHaImdyJlgcQM1PQWGhEFBosNCIKDRYa EYUGC00wIq4dYiZ3ouUBxMwUNBYaEYUGC42IQoOFRkShwUITjIhrh5jJnWh5ADEzBY2FRkShwUIj otCI1jpANfX09BT92tDQ0CwmIaJaCE2h9fT0lCwtt6+Loqu3S7i5D2ZyJ1oeQMxMQeMhJxGFBguN iEIjNIecQ0NDnEMjmuNCU2hAOEpLxDkPZnInWh5AzExBC1WhFVMvJwTIm9iOHc7HfVu21DAJiSYU hVbqULOc7yGi+uYUmiRJtcxREbfRV3aZ2d/LgiMKH+cspyzPjROeoheZiHtYiZapb8sW3HnvHUId bor2/wgQM1PQnBar5xFaOTiXRhRevufQLMuCZVkwDCPnl2mars/1MkoKonhYZkTh5hSaZVmen2SX ma7rUFUV6XQamUwGmUwGiqK4Pr8WxcIyIwo/55DTy8jKZo/MVFVFKpVCIpHA2NgY4vE4kslkxaGq Pc9VT2Um4tohZnInWh5AzExB83XIaVkWNE1DOp3G+Pg4RkZGMD4+DlVVMTk5WdZrFSqveiogIhKH 7zk0wzDwre8/icxEApmJCajpNEzDgGnonl8je8FrsY+JiLzyPYdmmiZMw8CS1V0Yee8oWtrbnbm1 U+++G0hYIqJSfC0+s4sLlolVv7IeC1asxIIVK9F5zvJq55tzRFw7xEzuRMsDiJkpaL4KTZKkqXVr kozOeW2+3zx7hwz7Yx5uEpFfvubQJEmCLMuQIxGsPvts7KkgQHZ5sciIqBK+TwpEIhFEolFcsuZ8 WDfcgAPvf4DT4+Owylj+QURUTb5HaNFoFHI0ii//6VehKRnoqgrLMKBmMp5fhxsy5hNx7RAzuRMt DyBmpqD5HqFJkoT7fuNWjI+PY2JiApOTk1BVFaOjo3jgtd2eXqNQaXEOjYj88r3Fhr10w778SVVV KIoCTdMqCuS2lTYRUTG+9kOzr+NUFAXJZBLxeNz3lQJERNXiFFq5+6FV60qBQubyIaeI91JkJnei 5QHEzBQ0TyM0+/DS3iJI0zSoqgpT17Ck63yMHD3i60qBuVxcRFR9ricFsrcKUhQFmUwGyWQSExMT 0FUVq9b9CkzDgDV9KdTYB+/PRm4iojyu13LOnC+bmJjA+Pg4xsfHoStKRVcKADzsJKLqcQqt2H5o 9lZBqVQKo6OjGBkZwdjYGBKJBNRMpqIrBbhEI5+Icx7M5E60PICYmYLmaR2aruv4s4e/g8zEBDIT CSiTk1MLaU2TVwoQkTDyCq3YCQBD07D8gl/FiYMH0NLROT1vZuC3b7sN0cZGRBobIUciMHXvZznt NWccpRFRNeTMoWUvlrXvEZBOp5FIJKCrKi5YuwamYUBXFZiGgVOH3oVlWbjy4o+hvb0dzc3NSKVS GHz9NU9vbs+fcddaIqqGnBGafQIgk8lgYmICiUQCk5OTSCQS0DJptLe2nvle04RlWZAkCaZpQtM0 yLJc1pUCLK18Iq4dYiZ3ouUBxMwUtJxCs4tpcnISIyMjOH36tHOtpppKYfniRc73StMLcSVZnlqT ZppIp9NQVbXiUDwMJSI/8ubQNE3DHz4wiFQ8jnRiHGoqBV1VAcvCBeeei1+/+iocOn4cpxMTMDQN 8Q8/xM/2vgnT0CFJMkzTKCsADzeJqFryDjkNw4BpGLhkSx+GXn8tZ9HsZ2+7DQ3NzYg2NgKSBEPT sPqyXowcPeIcgpZzpQBvkkJE1ZRXaFP3CrDQs2olNF2HomlQNA3vv/UmLNPETZs3obOzE7Is43v/ +jyvFKgyEec8mMmdaHkAMTMFLafQztwrQEJbc7PzmPN1WYZpmlBVdepkgJF7eFnOjh1ERNWWV2iR SARyJIKzFnTmfbMky1AUxVmjpqbTOV8v51Z4QO46tJk3TCEiKpdTaA0NDc5/o42N6Fp2Nm7c1Iv3 T49gdGLqBMDpI4fx41d2wdB1mLpelREab5JCRNWSM0KTZRkNDQ2Qo1Fs+/o3oSsKdFWFrihQ0yl0 X3k1jh/YPzVfpmuwLAvvHdjvPL/cERrlE3HtEDO5Ey0PIGamoBW8lvOB3/89jI6OIplMIpVKIR6P 468efQwXrF0DQ9Ng6BpMw4ChaTmjNK8jNC9bbHO0RkTlKlhouq5D0zTn0qdMJgOjwDWaMwvM6wiN 82VEFISCVwpkMhnE43HnSoHx8akFttnsdWd+Za85y/6ciMgvb1cKTM+lZZNkGdKMrYIqOSnAYpsi 4pwHM7kTLQ8gZqagRQE4O2xkbxV0ad+VeOu13c6CWdMwsO/td5wnVjpCm4nFRkSVigJTozLLsqCq KuLxOHRFwfqVK6BoGlRdR2a65LJHaYVGaJUUHIuMiCoVBYB0Og1d12EYBkZHR6FkzZdZlgVZkqDP KCtnhFbhKI1FRkTVIgNAIpHAiRMn8N577+HIkSPITCTyvtGeH8veNmj6C77euKenJ+cqAZrS1dtV 6wh5mMmdaHkAMTMFLWqaJr7y99+GkkxCy6ShTE7mjNBc+RihZa9D412fiKhaogCwZetW7Nq1a2oL bsMALAv7j03tmiFJEkx7F44sldwMhWVFREGIAsDa5cuB3t6pEwO6Dt0woOnu12naO3MQEYlAznvA Y0E5c2hUVSKuHWImd6LlAcTMFDS5bcHCqr0Y90MjolqSC12j6RV31yAikciFlmh4xREZEYnE00TY l66/Dldc0IP2trag88x5Iq4dYiZ3ouUBxMwUtILbB800v7UV/Z+5Ee2trTj04XG8vn8/Xt9/AG/s 349EMun7zbu7u3M+Hx4e9v1aRESeCu3+7z8JU9excuFCXHR+F/o+/jHcetWVME0TW75wt+83Hxwc zPm8v78fAIuNiPzxVGjrVizH2mXLsG75OVi/aiWWLlgAADB8Lq6NxWIAzhSYzS64/v5+lhoRlc1T oW2/6w4AwOnxcew7fARPvhTDvncP4cDhw2W/YSwWw7Zt2wqeIbULbnBwcM6Wmohrh5jJnWh5ADEz Bc3TSYGfvvkWRhIJtLe1oXPePLS1tKCxoQERH4tri5UZEVGlPI3Q/voHT8PUdSyZNw8Xda3G9Zs3 4XPXXQvdMHDlF3/X85vZh5pu+vv75/QojYj88VRo5y9bhu4Vy9Fz7ipccN55aG9rBTB12zsiIlF4 KrS/vPsuAIBuGDh47H3s/fnb2HPwIN48+Hag4eYiEe+lyEzuRMsDiJkpaJ4K7dHYDrz17iHsO3QY mUwGuqpM3WeggsumiIiqzVOhPb7jZ1P3FNC0it6sr68PAwMDkCSp5ImBwcFB9PX1cf6MiMriqdAk ScLNV1yOT2/sxZLODpwaG8PTO36Kx//1eRjuTy/6moVKTZIkDAwM+HxVIprLPBXajRt7ccenrnE+ P3vRInzp12+BZZr45x/9uKw3tEdpQOGL2wcGBtDX11fWa4aJiHMezOROtDyAmJmC5qnQPt17KX4x vB8PPv1DfDQyikVtrfjSLTfj5r4tZRcaAKewZo7E5nKREVHlPBXa4o4O3P9/n8DJsTgsy8KJ0VH8 8/PP43//0X+t6M1ZYERUTZ4Wkp0eH8dnt3wCZy9cCFmWsWzxIvz2tZ/CqbF40PmIiDzzNEL70a7d uONT12Bj9/qcxwe//2QgoeYyEdcOMZM70fIAYmYKmqdCe/YXr8AwDHx642VY0tGBk2NxPB2L4YkX Xgw6HxGRZ54KzQLwzM9fxg9iO2AahrOwlheZE5FIihbaX959F9pbW11f4BN3fqGqgYiI/CpaaOOT kzBME5YFLJw/DxOpFFRNB2ChubERTY2NiE9MzGLUuUHEOQ9mcidaHkDMTEErWmjf/D+PQdE0qLqO R//7ffjqw9/FwaNHYRoGIpaJb9z9Rbz06quzmZWIqCRPyzZSioKrL7kYHW1tkCQJbS0tUDUV/Z+9 Neh8RESeeTop8NM338KNmzfhxs2bch4/evxExQF6enryHhsaGqr4dYlo7vE0QvvH557H47Gf4uRY HKZpYjKdxr+/sRd/8kBlF5H39PRgaGgo71ehkpsrRLyXIjO5Ey0PIGamoHkaoWmGgUdeeBH/9KMf 5yzb4H5oRCQS7qFNRKHhaYR23WWX4va+X8P8AuvSKlmHVuzwknNoROSHp0L73Nar0NzYiHgyCcMw MHWBQHWuEmB55RJx7RAzuRMtDyBmpqB5KrSUouC5V3fjoR8+W9U5NPukgNfHiYhK8VRo337uedze twWPtbUhnkhU/KbZh5lz+YwmEVWXp0K789pPoqO1FQ//8b1IZTI5h5y3fPmPyn5Te/TFkRgRVZOn s5yL5s9HNBJBS1MTFnV0YHFnBxZ3dmJxZ2dFb84yyyfi2iFmcidaHkDMTEHzNEK75et/PnUbO1Wt +hxaMSw7IiqXp0ILCk8IEFE1FS20my/fhM093dj2twP4hy//AWBZ09NmVsVzaKXYa9NYakRUrqKF 1tLUhAXz5gGYmkOj2SHi2iFmcidaHkDMTEErWmiPvrQDj7z4EoDZn0Pj6IyI/Cg5h/bAPf3Ye/gI dh04iN3D+3FyZKSqb87iIqJqKlloT/xsJy5cfR5+9/rrcM9NN+DdDz7ErqFhvPzmXgwdOgxzlkIS EXlRstD+7fVf4l92vQrLstCzcgUuWXM+rtpwCW6/5mpMTKbwyr638PUHH6pamOxD0Lk6ehPxXorM 5E60PICYmYLmadmGomnY/94xmLqOjKLg6g2XYMH8+dja21txobHEiKhaShbapevWYu3yc7B+5Qqc u3QpJEkCAKiahj0H38aeAwd8v7FdZNmXQRERVaJkof3+Z250Pt576DDeePsdvPHOO9j3zjtQFMX3 WU6uMyOiIJS8lvOF1/fg+OgoAGD12Wfh3LPPwvIlS7CgwnVp9uJZjsryiTjnwUzuRMsDiJkpaCVH aN978SdQdR3zW1pw4bmrcHHXatx1/afxh79xK4599BF2Dw3jW997xNcb81CTiKrN00mBU+Pj+Mkv 9+DwBx/i6ImPcMPlm7DyrLOw8qyzfBeaLfvQkycIiKgSJQttaWcn1q9cgQvOXYULV5+HtuZm52tH jh/H7n3VLR2WGBFVomSh3f/FO52Px5JJvPL6L/H6gYN4dd8+nBod5W3sAiDi2iFmcidaHkDMTEEr WWh7Dx/G3kNHsPvg2zj84YfQFMW5lpOISDQlC+2vnngKqq4jo6qwrOrc5YmIKCi80TARhQYLTTAi znkwkzvR8gBiZgoaC42IQqOm9xTo7u7O+Xx4eLhGSYgoDDwV2nWXXYrb+34N81tb8772iTu/4PvN BwcHcz7v7+8HwGIjIn88Fdrntl6F5sZGxJNJGIaRc5MUP2KxGIAzBWazC66/v3/OlpqIa4eYyZ1o eQAxMwXNU6GlFAXPvbobD/3w2YrvKRCLxbBt27aCy0DsghscHJzTpUZE/ng6KfDt557HpevWob2t reI3LFZmRESV8jRCu/PaT6KjtRUP//G9SGUyvu/LaR9quunv7+cojYjK5qnQ7PtyRiMRtDQ1BRpo rhNxzoOZ3ImWBxAzU9A8FVpQ9+UkIqomLqwlotAoOkK7+fJN2NzTjW1/O4B/+PIfAJY1PW1m+Z5D 6+vrw8DAACRJKnliYHBwEH19fZw/I6KyFB2htTQ1YcG8eQCm5tAWtbdjUUc7FnV0YHFnBxZ3dmJx Z6fvN7bvIOX18bmiq7er1hHyMJM70fIAYmYKWtER2qMv7cA/Pf8CgOrOodmjNKBweQ0MDKCvr6/s 1yUi8n0tZ29PD37zmqvxn7ffX/Zz7cKyi23m40REfngqtA1r1+D3brrBOQS1aRWe5WSBEZGbcnrC U6Hd8clr0NLYiOMjI1jU3o5jJ09ixdKl+PbTP/SbkYoQce0QM7kTLQ8gZibbzJ123FiWBdM0Xb/P U6Gds2ghvvrwd5BOZ9D/mRvxpe1/gesv34yPrVlTVigiIsDfyT/DMFy/x1OhpVUVGVXFeDKJlUuX 4uyFCzGvpQVbNlxSdigioqGhIc+XQgJT14B74anQ3j1+HBd2rcbjL76E0YkJPPL1rwEA3j95suhz uru7A12CwQvcieqb17mxcorPU6H9zVPPIIKpEvmf3/0e7rjuWsiShId+8FTJ55Xbwl55bet6JOIe VszkTrQ8gJiZguap0E4nEjA0DQDwzvsf4L89MOB5HVq1z2QGUZBEFA4lC+2bn/8dWLBgWWd+wQIs y3Qug/pPf/Y/ZiUoEZGbkoW2aumS2cpBRHNQT09P0a8NDQ2V/XolC+3l4f34WNdqqJqGXwzvx869 b2LPwbeRTk1y+6CAiDjnwUzuRMsDiJlppqGhoYKl5qfMAJdCe/D//QimZeH8ZcvQu24N/sut/xGt zU14Zd8Q/n3PHvx8zxuYSCZ9vbEt+zdj/+b8/maIqP7MLLVKfv5d90PTDQNvHDqEB5/9F9y1/X48 /pMYLr/wV/Gnd96BrRt7fb8xAKe8sn8DxRqbiMLL7oBKBzOuZznnt7Rgc/d6bFi7BpesXYOWxkYA wHsnPsKxEx9V9OZERLZqHJmVLLQ/uf03sXb5OZAkCaZp4q3DR/CLfUPYuWcPjp04wTm0AIi4doiZ 3ImWBxAzU9BKFtq6FcsBTK1De+3AQSQmJ9E5bx6u27xpahmHaWLw8e/7fvOZh5f2x5xDIyJb1Xfb WNzejk9ddmnBr1VSaEDtyotzdUS1U5PdNj5//7eg6joyqirkXZ/s/yl+rxm1LIt7shHNsu3bt/t+ bnt7e8mv+96xthJeRkZuI7fsG6j4HeUNDw8jFosJdR+DHTt21DpCHmZyJ1oeQMxMg4ODFT3f7dLH mhSaSHNkkiTx8JMoJGpSaCISqWTJHRdg15dYLDYru+TkFdqPH3sUaioFJZWCrmRg6jpMw8i6OP3M fwEAkgQ5EsH6vqs8v6n9l7Ha13ER+cWCDIe8QrNME9d97vPYFYtNTfyb5nSpTRebaeb99/SRw2W9 abVWBRNVg/0PK0ut/hUstFVLl0L7D5+AomlFz3IamgbLNPH+m3s9nU4lEtHMowSWWn3Lv5bT4xk/ Sc56apnbYXMCnkRQ7O8h/37WL9eTApZlQZYkFLrfSrX29ee/ilQL/DsXPvkjtAIlZWY9ZvHwkogE lT9Cmz7kNO2zmTO/nHWoKdKCVJq7eLacbEUPOWVJgjT9i0hUbtMVnM6YW/ILbcaorNQ8WSVzaIXO LmXjX0IiKlfRQ84zn+Z+nj2H5nytzFEcy4qIgpBXaJIkYX5LS9EnZM+h2SM0WXbdyZsoELzihLLl F5os46wFnc6ZzWKHlZZpOiM0OcpLQql2WFpky2uiSDSKNecswyc3fBzvnTyFeDLpXDGg6Tp0w4Sq 69ANA5quw9B1JE7W770FLMvK2YqI6gNLjArJKzQ5GsVtX/giDE1zLkx3rt00TWB650hr+mPLshBp aJy1wNyQkaj+zNbPbV6hbb35lunRmFHyWk57x1pDP3PR+kzlbrPrVbVHVUHlJKIzZuNoKLDJL65f I6IglNpXLQoArU1Th4ymZcEwTZjm1H91w4A+fchp/zI0NW/7IEzfAcoyTSw4Zzk23vZbiDQ0zM7v jojmHEPTsOfg23mPRwFgcUcHgDNXB8iyhIgsIxqJwLQs6JEILNNEY0sLUGJJBxFRLUUB4NylS3D1 xy/GqXgcE+nM9NlMwzmbqfKGwkQkqD1ZH0sAqrMHEBFRjf1/WwoQUouhLCMAAAAASUVORK5CYIJQ SwMEFAAIAAgAllDBNAAAAAAAAAAAAAAAAAsAAABjb250ZW50LnhtbMVXbVPjNhD+3l+xdaedduYc JwSGIyW5gQtc6YSXKTDTflQkxdYgS64kJ+R+fVfySxIg4a50rh+wo9WzL9p9di2OPzzmEubcWKHV MOp1uhFwRTUTKh1G93fn8fvow+i74+/H1x/v/ro5Az2bCcoHTNMy58rFVCuHb7i5P51cfIQoTpLr gqvrAOtokybJ+G4M1XpcawH6SZKzqwiiyl6HORaNjrcZxxiVHVS7wyhzrhgkiUY3euVmr9vtJtU6 qhWsW8rd+IBo4I4/up1oD2jBZPqK7YBo4MyQxU60B2DOG/xMt+jFYtFZ9AOyd3R0lPx5O0nOtclJ G8ujFOphKz7sNlBV5lNudkdCHNnIi52nLxmvEjhvQ6YZMbvzFxCrjPTZKxnpswaMh822HPB9comb 4XE5WaXP5DuNe0B7PmpEsTvyChI17KeSWDuMKj7Uso0eaqlcKSbteoaMjhmn0o6OQ5JXEqjWiuTI qxMjiIR7JbAVOVzeRjDTFXRGciGXw+gnUmj761NcJY1gzXYhHMXkzQlCPSOT3Z5/+wSXQtFMw0Sk mYPft7l+Bny77yuRT0sLf+icKLjSRzDZ5vw58gXvlUqccsWNoMPIePRr8SUvVKoWkdKhBSdoHEy0 JQzPjYPc9Vo3ddiBK41CYZBkxglu2+MtuE/iMJpqyUIYa6a3+5mZZ45SQ4pMUNvIC2L8KA2LuNL6 1EBeiKcSZNqIzxgWkTFmdRhRNMFN9HzXcDmM0AUJbhtALozROGWUVjxUkEpRYP45dT93aQ5rf79E 4EffQJa5UET5+d79sZb58W9wFq2JDGdrq9RwrtbWU1mu66ckzwk2ZGtOahML1XbqjEjL6010pGzI FcUkxr3uWhReLcf+GkbWEcWIeaFCyVaO1BtTzZajY0+DgeV/l+iHN/R6LoQgYsIWkixjXTqc4TyW fO7TjZ/osF0V80LK0mL0Do/kw3qTsbumC95mxXP9rUbG9QfRZ3p71opKZZ3dt02NRheQkTkH5s0j wRngrCBFIQUN2UJiGi/KEJ9xyTwQK/UOXMahDj4ZCSWcn7EYDNMLfEkJUusHkOKBI1RYGNQRFl8Q VPINMaPjQGCRk5RXXF6HhdkRpBtToVdXgfjRbmK3LPhmh8/TwUIw/z0+7Bzs9WleybJ6gB129g96 XhhMf8Z+Y/wxFDdcRAaZ4bNh9MONoK403CbYad3uXje8ur3+Yf3eH5/19w5Pev1OEW5FQbcKxoq8 CLeTILOZxpsVx2sNa0QETROHSK0mmrAVhf6rAo1OSxdYUjEGkAPINGQr+BFHVFpKYqCmOYgZCMBf lAedmkjEgnBeM19CffkDHD9kjWFU5wWmyHL2DqxGIwwHIiwIPpxud58a6MCFd0iR2U5It+FTsVVU kGFP7PAe+M0VniTlrAP/A8f/FX/3voa/NVU3+VuTepO/vS/k737D45PTg97J4XnvW/O3GbuFr/9T FN5LRhfWU8JwZMMSybT0XApEeTIdVzz1ISpkMCeWA07KAnIOOLw7zWRGX1/ZYsnGVzHZ8o/f6B9Q SwcIVrL7yYQEAACfDgAAUEsDBBQACAAIAJZQwTQAAAAAAAAAAAAAAAAKAAAAc3R5bGVzLnhtbO1Y S2/jNhC+91eoLNqbLNmJmziNsmg3+2iRx6JJgPZIS5TFViIFkrKT/fUdkqJk2ZSTwkBPzSGION88 9XFmlMt3z1UZrImQlLMETScxCghLeUbZKkFPjx/Dc/Tu6pvLb6/v3z/++eVDwPOcpuQi42lTEaZC qV5KIoMvT7/c/Po+QGEU3deE3RvUhItVFF0/Xgf2+bpVCsBNFH24QwGy5iaZytDV5YhtiJDJCytM UKFUfRFFHLzw3sssjuPIPqNWwWgfxBuEgyvyrA6iNaAD4+Urtg3CwTOBNwfRGgAVd/icd+jNZjPZ nBjkdLFYRH883EQfuahwF8tzSdnfo3gjdVDWVEsiDkeCFR7URa5XPuO2gOsu5LTA4nD9DKKvyEn2 SkVOMgeGZIuRBM+jWxCaX7c3fflEddC4BnT5pYLWhyO3EOS4P7gtHWtzDozNSFrKq0tTwP4ksM8M V8CZnwXFZfDEKFwyEtw+oCDnFprjipYvCfoB11z+tIuzpyjYsl1TlUJh1higmm3RYc+fPwW3lKUF D27oqlDBb2Ou94DH+76j1bKRwe+8wiy444vgZsz5PtLj3aqEK8KIoGmChEa/Fl/keVPtke00LoWM 5Lgp2/7jjLZBrgSuC5pK5MC1AMoIRaFR6VsMpoDmIdw6Esoap3Crw4IL+hWc4jJB8WR2fpIC+8bA a20s3YcSlr3V6h7UYxOKn/KSQzP4LjY/g+q9/tIk/QqI6UzfCzgrMVs1eAVHhLXGG6YEFOzpYc9y iCXFzEvILaT24JDWjxU6V07GOCNO1nr1iXrvKa/qkjz7ruKu+w7qDaCT+kLwCvUMCXGjuH4zUCya EW4YFeKyLrCD1Q1LVYMVdJlwA+IESaqtdRHol7sUBEPflwpugOroCHMHeMtrqQm/y9DuaMDwt9C+ xgKbQH28/59L/y2XoCTFS10QhhUUKcelHB5q2ghSYcpCPXRDYyZBsz1Q3cjiFUiJs4x0csahsVRU Hc3nAvI2C88ooYMhn8OMQrNk2slsMovnuodZxEZQpZtcBYVPUClCtUTRYaZvM9zS8wFsZ1hkaJT3 7pWUWMoEmWUwGrf3yY2JfzE+tM0LrDkMObzUZOh9vboAAsQmb/j7xf3d1kAXdZs6ruWHMDshXF7v CQQpPfn1U8VqprCIE+GR7qj3FW8rbbLhjbKDyHNWkjUp22ZjBOYArodzBttqmJtVN0Ha/pu0Z0dp nxylfXqU9vwo7R+P0j47Svv8KO3FUdrTeEw9GmVgzrliXBEJbY3ldNUI05o8doCLRsPuaWtcNnAr 4/awNwM3hSrzSVBDLx/o2E8u3Z+0Pfdp26UHq9rbIqH+SJwdnWPvamjMAKzQrIWymxm2QnkuidKr 4eli0bcUXxlaI326JclVK4PhCzOH6Ckx39623WrdPuphATZpGg53bl24sIJPTyIGjbSupiMrh9HY 0Ex/G86mk/miXWvNeUH0FgCCs8nidDQpZ5bCjIbOBsHj9jVyoQSmdh+psIBZFUIP1bNnftr6aY+X XEFGPokuDrSUyfRsPhQIG1sncZuCpRNU4bmLX/f4/suqBUhSu75v048n8fS8t+RGZbgkkKzBa8w0 nnowOIeSeyE4+6uRyr5S+6LtOXT+ru7z7/tdZbAB+tfPdooQrHcK8xBtZ7d1GO3RoqfUPodagQXu MKs91JYOjvwtV2HPvS0m71iP/P+uuvoHUEsHCFT8PRwABQAAUxMAAFBLAwQUAAAAAACWUME0gbtD aWIEAABiBAAACAAAAG1ldGEueG1sPD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgi Pz4KPCFET0NUWVBFIG9mZmljZTpkb2N1bWVudC1tZXRhIFBVQkxJQyAiLS8vT3Blbk9mZmljZS5v cmcvL0RURCBPZmZpY2VEb2N1bWVudCAxLjAvL0VOIiAib2ZmaWNlLmR0ZCI+PG9mZmljZTpkb2N1 bWVudC1tZXRhIHhtbG5zOm9mZmljZT0iaHR0cDovL29wZW5vZmZpY2Uub3JnLzIwMDAvb2ZmaWNl IiB4bWxuczp4bGluaz0iaHR0cDovL3d3dy53My5vcmcvMTk5OS94bGluayIgeG1sbnM6ZGM9Imh0 dHA6Ly9wdXJsLm9yZy9kYy9lbGVtZW50cy8xLjEvIiB4bWxuczptZXRhPSJodHRwOi8vb3Blbm9m ZmljZS5vcmcvMjAwMC9tZXRhIiBvZmZpY2U6dmVyc2lvbj0iMS4wIj48b2ZmaWNlOm1ldGE+PG1l dGE6Z2VuZXJhdG9yPk9wZW5PZmZpY2Uub3JnIDEuMC4yIChMaW51eCk8L21ldGE6Z2VuZXJhdG9y PjwhLS1TUkM2NDFfWzc2NjNdX0xJTlVYX0lOVEVMX19zeWx2ZXN0ZXIuZGV2ZWwucmVkaGF0LmNv bV9hdF8yLzIwLzAzXzEyOjMzOjQ1LS0+PG1ldGE6Y3JlYXRpb24tZGF0ZT4yMDA2LTA2LTAxVDEw OjQ1OjU1PC9tZXRhOmNyZWF0aW9uLWRhdGU+PGRjOmRhdGU+MjAwNi0wNi0wMVQxMTowNDo0NDwv ZGM6ZGF0ZT48ZGM6bGFuZ3VhZ2U+ZW4tVVM8L2RjOmxhbmd1YWdlPjxtZXRhOmVkaXRpbmctY3lj bGVzPjI8L21ldGE6ZWRpdGluZy1jeWNsZXM+PG1ldGE6ZWRpdGluZy1kdXJhdGlvbj5QVDE4TTQ5 UzwvbWV0YTplZGl0aW5nLWR1cmF0aW9uPjxtZXRhOnVzZXItZGVmaW5lZCBtZXRhOm5hbWU9Iklu Zm8gMSIvPjxtZXRhOnVzZXItZGVmaW5lZCBtZXRhOm5hbWU9IkluZm8gMiIvPjxtZXRhOnVzZXIt ZGVmaW5lZCBtZXRhOm5hbWU9IkluZm8gMyIvPjxtZXRhOnVzZXItZGVmaW5lZCBtZXRhOm5hbWU9 IkluZm8gNCIvPjxtZXRhOmRvY3VtZW50LXN0YXRpc3RpYyBtZXRhOnRhYmxlLWNvdW50PSIwIiBt ZXRhOmltYWdlLWNvdW50PSIyIiBtZXRhOm9iamVjdC1jb3VudD0iMCIgbWV0YTpwYWdlLWNvdW50 PSIxIiBtZXRhOnBhcmFncmFwaC1jb3VudD0iMTIiIG1ldGE6d29yZC1jb3VudD0iNzkiIG1ldGE6 Y2hhcmFjdGVyLWNvdW50PSI0MTUiLz48L29mZmljZTptZXRhPjwvb2ZmaWNlOmRvY3VtZW50LW1l dGE+UEsDBBQACAAIAJZQwTQAAAAAAAAAAAAAAAAMAAAAc2V0dGluZ3MueG1s7Vjdd6I4FH/fv8Ll dY8F7Uxbe1rngAq1H9YKYutbJLdKJyRsCKLz129AbacVZrsqe/ZhOceDITe/e3NzP3PxbRGQyhx4 5DN6qdSONKUC1GPYp9NLZeiY1TPlW/O3i9/b9y3nqd+psOdn34NzzLw4ACqqEQghaaNKf2jcdlsV paqq9yHQ+4zuiPGpqraddmU1bq+XVSQjVe30lIqyAjzCAivNi0J0KSWNzlfTl8pMiPBcVZnkw974 1DVNU1djZb1gQXz6/ZU+SZKj5DijrTUaDTWb3ZB6jD77019g19QVibLRwTutvcq+Ebl5sSJfA1d9 AUG6n8r6M0WB3Mnch+R1l0remvf0rqTXOSCHhcpmRixDOeNToTTrF+o2wudRb+FZ5MFq+8GOfCxm ueIe1xun+2FfgT+d5QpdO67VjncDt2csGQCW5gGtGaJTiD4wmDBGAFGlKXgMu/O4AoSBj2Y+AYOz JJJGUMToGZFoD04mY6J8Tl2agcMdw3AQ+GqAwqpPMSwAb59/vsNka2Tw4MvPWVEXfxA1EjxVTzP1 zT0cqsiZvtRO97D5Isf/enK6s5dG/oTAwX0/Qz10nMpAB0Uun8aTk72gDSYECw4cTsaMBY5E+mhn M8Z3V3AKaiJPMJ4PW9N2BO5GNhDwBGCTyw87+HHOx5+dsmh67ef5BDJHfi6jrgYxR0Lm5n+SWnWM +4gjB0kzsEPklRMi+zK2iAGktQN8DDyHwL+VJc0wxEjkBeGNaewGLVMhlwYHvMWCkEOUFj8HN+tM P7bUPYFrNinMu/ueQB+FwE3OAhtE/DFEHYxLGlP7qJTyIcPPbLUE8PSkhR4LtrKkkqRvMRkPGClL OcBzzxZFcPLF8CniS6UZT2//UDVMJoG7RKO76fDqOpzQAfGm+n/yGWrYdIhhu39POtL1O/nqZgNV PTN1yxjqevtsIsd20PAHlqk92fqiRQ2596/a+LHbGNTdePx4HT4tjQcvIDG23GUraMh5V/43NTRq xH3XmHt0sHwaEa0V9OaeRYj3Q5M4vZen0YL0nc7NZGQux3USjy3zT/zY0ybp+rYm7uzk7fcQvkzq i7kXSH1fDVjf6WpSlh8Ty62PR0njTn+bxwF5GTta0iLGw6DTm6dnBJ3BDFudm6Fl0rHbCyEYnjiW q6Uyl3oI/z//5nO5RwjQKWUiKwSKk+GOeUoPQ7IcRsDbSKDDRzDTB4LLjMA2moO7usC4py3CosM0 bNtMLMImiGwuftLypIyk3o1ugFM98hHtx9QTcXbqJTDSiT+lMu/agoV9FvklsWnFnEt1pcaVZqz0 bbOYe1tGvOpV1U/nxN52Sb/pdy2gwH2vsqbcw+9MtCjm81lZsy6vpOopp9bXhS1k1VNawclZFMqu qix8i6Nw5ntlFIPvTVEW/wGiOKfw3+e6YF2UT8FA3vcpZzEtbI4OvZP9rLTNUZI1mOUUsQaR+jBl obxL0Czso9Wtu2q16Oa9+RdQSwcIYIjI8FgEAAAiGAAAUEsDBBQACAAIAJZQwTQAAAAAAAAAAAAA AAAVAAAATUVUQS1JTkYvbWFuaWZlc3QueG1svZNRa8IwEMff9ymyvDfXqMMhVlGrMNimD/qwx9Be a6BNQ3M6/faLY1VBYThkeblcuPv9/+G4/nBXFmyLtdOVibgUIWdokirVJo/4ajkLnvlw8NB/jOeT 5cdiykpldIaOes2FLVbj15cJ4wHA3KKZZ5lOUFR1DhAvY/bW1Hk2wPSdM948iZRS7uGXTG/KuGMa 8TWR7QFUnl+d+K0wlNAUeRA7kTJdYICG6v2ZY0y1CmhvMeLK2kInivyvYWtS4TZGeFHxWWvCmp+a sk1RBFbROuLA4SYNXaocwZr8Om6hE9rU6ECG/rTC7xDKdvcnduJpu9UdybY4IP5FutNYGI2f5Kg7 k3+Q/kXxRhrhjsAP5jo1qQz55sPk7sp1tC/Q3R1bIqn7e0Uiv6xHt324WKfBF1BLBwhaFbNOMAEA AOYDAABQSwECFAAUAAAAAACWUME0gJBrfpsbAACbGwAALQAAAAAAAAAAAAAAAAAAAAAAUGljdHVy ZXMvMTAwMDAyMDEwMDAwMDEzNzAwMDAwMTM0REUzMjdBMTMucG5nUEsBAhQAFAAAAAAAllDBNLas V216HwAAeh8AAC0AAAAAAAAAAAAAAAAA5hsAAFBpY3R1cmVzLzEwMDAwMjAxMDAwMDAxMzQwMDAw MDEzN0FCNTFBN0YxLnBuZ1BLAQIUABQACAAIAJZQwTRWsvvJhAQAAJ8OAAALAAAAAAAAAAAAAAAA AKs7AABjb250ZW50LnhtbFBLAQIUABQACAAIAJZQwTRU/D0cAAUAAFMTAAAKAAAAAAAAAAAAAAAA AGhAAABzdHlsZXMueG1sUEsBAhQAFAAAAAAAllDBNIG7Q2liBAAAYgQAAAgAAAAAAAAAAAAAAAAA oEUAAG1ldGEueG1sUEsBAhQAFAAIAAgAllDBNGCIyPBYBAAAIhgAAAwAAAAAAAAAAAAAAAAAKEoA AHNldHRpbmdzLnhtbFBLAQIUABQACAAIAJZQwTRaFbNOMAEAAOYDAAAVAAAAAAAAAAAAAAAAALpO AABNRVRBLUlORi9tYW5pZmVzdC54bWxQSwUGAAAAAAcABwDaAQAALVAAAAAA --=-k0bJJnk7Qaq1V0+G97NB-- --0-596188450-1149245335=:1049-- From kris@babi-pangang.org Fri Jun 2 07:03:22 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 7783B3B03DE for ; Fri, 2 Jun 2006 07:03:22 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20299-05 for ; Fri, 2 Jun 2006 07:03:21 -0400 (EDT) Received: from nasi-goreng.babi-pangang.org (nasi-goreng.babi-pangang.org [83.166.137.20]) by menubar.gnome.org (Postfix) with ESMTP id 0CC793B0196 for ; Fri, 2 Jun 2006 07:03:20 -0400 (EDT) Received: by nasi-goreng.babi-pangang.org (Postfix, from userid 1000) id 417E73DCA0; Fri, 2 Jun 2006 13:03:18 +0200 (CEST) Date: Fri, 2 Jun 2006 13:03:17 +0200 From: Kristian Rietveld To: Tim Janik Message-ID: <20060602110317.GA10757@babi-pangang.org> References: <20060314132538.GA3526@babi-pangang.org> <443B4A8A.8000302@imendio.com> <20060425103017.GA15762@babi-pangang.org> <20060531183045.GA7564@babi-pangang.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.563 tagged_above=-999 required=2 tests=[AWL=0.036, BAYES_00=-2.599] X-Spam-Score: -2.563 X-Spam-Level: Cc: Gtk+ Developers , Soeren Sandmann Subject: Re: Callback based tooltips (Re: New tooltips API, continued) X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 11:03:22 -0000 On Thu, Jun 01, 2006 at 05:16:51PM +0200, Tim Janik wrote: > On Wed, 31 May 2006, Kristian Rietveld wrote: > > >On Tue, Apr 25, 2006 at 03:08:12PM +0200, Soeren Sandmann wrote: > >>I once wrote down how tooltips should behave: > > > >I mostly like the behaviour you described below. > > > >> - Tooltips are too intrusive. The text should be smaller, and > > not sure if this has been raised already... > the font size of the tooltips should be exactly as large as the default > font size (module tooltip markup of course) to avoid reducing usability > of the tooltips in contrast to normal text (labels). The text for default/simple tooltips using toolip-markup are drawn using the default GTK+ font at this point. FireFox does this too, it seems. -kris. From lists@nabble.com Fri Jun 2 07:11:06 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 15ADC3B10CE for ; Fri, 2 Jun 2006 07:11:06 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20935-09 for ; Fri, 2 Jun 2006 07:11:04 -0400 (EDT) Received: from talk.nabble.com (www.nabble.com [72.21.53.35]) by menubar.gnome.org (Postfix) with ESMTP id 7B8A53B0E85 for ; Fri, 2 Jun 2006 07:11:04 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=talk.nabble.com) by talk.nabble.com with esmtp (Exim 4.50) id 1Fm7YV-00067i-S9 for gtk-devel-list@gnome.org; Fri, 02 Jun 2006 04:11:03 -0700 Message-ID: <4677819.post@talk.nabble.com> Date: Fri, 2 Jun 2006 04:11:03 -0700 (PDT) From: heavenscape To: gtk-devel-list@gnome.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-Sender: masonduan1@sina.com X-Nabble-From: heavenscape X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.564 tagged_above=-999 required=2 tests=[AWL=0.037, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.564 X-Spam-Level: Subject: strange trouble in displaying a 8bit monochromy grey scale image X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 11:11:06 -0000 I need to display a 8 bit monochromy image with size of 2048x2048 pixels, all the image data are already loaded into memory, and out of which I created a 24 bit RGB buffer for the GdkPixbuf (please see code below) Well, the result is: The GtkImage widget was expanded to size of 2048x2048 pixels, THREE exactly same images tile in a row in the top of the GtkImage widget, each with size shrinked to 684x684 pixels, and all the lower 2/3 space is left blank.(see the attached image below) Can anyone please look at my code and give me some suggestion on this problem? I have been debugging is problem for almost one week time! Or I wonder if there is any other alternative mean to display a grey scale monochromy image. Any help is highly appriciated! following is my code: ...... char* pDisplayBuf = malloc(sizeX*sizeY*3); for(i=0;i X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 129D43B0401 for ; Fri, 2 Jun 2006 07:42:43 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22729-02 for ; Fri, 2 Jun 2006 07:42:41 -0400 (EDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.204]) by menubar.gnome.org (Postfix) with ESMTP id AACEB3B03DC for ; Fri, 2 Jun 2006 07:42:41 -0400 (EDT) Received: by wx-out-0102.google.com with SMTP id i30so488730wxd for ; Fri, 02 Jun 2006 04:42:41 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=gT1j5ejSD/b/CcxQn0QQsSvUHhFufm/g+0pbZR2i/XzGfNpGoCbQpb21JCQ8031mkn0Ki6u8pLPOMj7RR8l3DAglKtDDYSYHma6DaM5dCPwAcVKD9bRfW3lU8+yvbKvGFEapsCpgbG/Y1Pe5Z3GQWmSp7m88CvcAjjuc1aYqX10= Received: by 10.70.62.1 with SMTP id k1mr2290069wxa; Fri, 02 Jun 2006 04:42:41 -0700 (PDT) Received: by 10.70.96.6 with HTTP; Fri, 2 Jun 2006 04:42:40 -0700 (PDT) Message-ID: <522c6460606020442q5704285jefadb260aa5ceda1@mail.gmail.com> Date: Fri, 2 Jun 2006 12:42:40 +0100 From: "John Cupitt" To: heavenscape In-Reply-To: <4677819.post@talk.nabble.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4677819.post@talk.nabble.com> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.554 tagged_above=-999 required=2 tests=[AWL=0.046, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.554 X-Spam-Level: Cc: gtk-devel-list@gnome.org Subject: Re: strange trouble in displaying a 8bit monochromy grey scale image X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 11:42:43 -0000 On 6/2/06, heavenscape wrote: > char* pDisplayBuf = malloc(sizeX*sizeY*3); > for(i=0;i { > //create a gray scale img in the display buffer > pDisplayBuf[i+1]=pDisplayBuf[i+1]=pDisplayBuf[i+2] = pixel_value; > } This isn't going to work. You're only filling the first third of the memory area. How about (untested): // malloc() can return NULL: you need to test the result // g_malloc() cannot fail char *p = g_malloc(sizeX * sizeY * 3); char *q; int i; // i loops for number of pixels // q loops pointing at each RGB triplet in turn for (q = p, i = 0; i < sizeX * sizeY; i++, q += 3) q[0] = q[1] = q[2] = pixel_value; // or alternatively in this special case memset( p, sizeX * sizeY * 3, pixel_value ) From jcupitt@gmail.com Fri Jun 2 07:44:31 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C18CD3B0402 for ; Fri, 2 Jun 2006 07:44:31 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22729-06 for ; Fri, 2 Jun 2006 07:44:30 -0400 (EDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.202]) by menubar.gnome.org (Postfix) with ESMTP id 8F0073B0413 for ; Fri, 2 Jun 2006 07:44:30 -0400 (EDT) Received: by wx-out-0102.google.com with SMTP id i30so489124wxd for ; Fri, 02 Jun 2006 04:44:29 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=EMOfucJIundQbGeCrVxW4fD6Iz3tUALWFaW8hgWFjuzmGzy3HlOTtgzn8QGVrywRA62j6kzikELTcAJL+GvTNGqGag3vtyJIcBhy5nQKUdv8v5Gm6dzT8SPDVoRKsWY874GU5fTfTuEc6cSK5TYAaWH6Ezj7csUQ73y/uo1NF/8= Received: by 10.70.128.5 with SMTP id a5mr2255574wxd; Fri, 02 Jun 2006 04:44:29 -0700 (PDT) Received: by 10.70.96.6 with HTTP; Fri, 2 Jun 2006 04:44:29 -0700 (PDT) Message-ID: <522c6460606020444q6963f934g8d7b671fb87905b0@mail.gmail.com> Date: Fri, 2 Jun 2006 12:44:29 +0100 From: "John Cupitt" To: heavenscape In-Reply-To: <522c6460606020442q5704285jefadb260aa5ceda1@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4677819.post@talk.nabble.com> <522c6460606020442q5704285jefadb260aa5ceda1@mail.gmail.com> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.555 tagged_above=-999 required=2 tests=[AWL=0.045, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.555 X-Spam-Level: Cc: gtk-devel-list@gnome.org Subject: Re: strange trouble in displaying a 8bit monochromy grey scale image X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 11:44:31 -0000 On 6/2/06, John Cupitt wrote: > memset( p, sizeX * sizeY * 3, pixel_value ) Ahem, of course that should be memset (p, pixel_value, sizeX * sizeY * 3); From cerdiogenes@yahoo.com.br Fri Jun 2 09:09:23 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id BD1CF3B03D8 for ; Fri, 2 Jun 2006 09:09:23 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27976-05 for ; Fri, 2 Jun 2006 09:09:21 -0400 (EDT) Received: from cac-bdc03.unioeste.br (pop3.unioeste.br [200.201.8.21]) by menubar.gnome.org (Postfix) with ESMTP id 8FFCD3B0351 for ; Fri, 2 Jun 2006 09:09:20 -0400 (EDT) Received: from [200.201.81.39] (200.201.81.39 [200.201.81.39]) by cac-bdc03.unioeste.br with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id L71GDA45; Fri, 2 Jun 2006 10:07:46 -0300 From: Carlos Eduardo Rodrigues =?ISO-8859-1?Q?Di=F3genes?= To: =?ISO-8859-1?Q?=D8yvind_Kol=E5s?= In-Reply-To: <7bf6f2dc0606010816q15d512aejc30a6c93bc165e6@mail.gmail.com> References: <1149104973.27709.4.camel@localhost.localdomain> <7bf6f2dc0606010816q15d512aejc30a6c93bc165e6@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Date: Fri, 02 Jun 2006 10:01:52 -0300 Message-Id: <1149253312.4847.21.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.221 tagged_above=-999 required=2 tests=[AWL=0.043, BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.221 X-Spam-Level: Cc: gtk-devel-list@gnome.org Subject: Re: Color space transformations in GTK X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 13:09:23 -0000 On Thu, 2006-06-01 at 17:16 +0200, =D8yvind Kol=E5s wrote: > On 5/31/06, Carlos Eduardo Rodrigues Di=F3genes wrote: > > Hi, > > > > There is any plan to add color spaces conversions in GTK+ (GDK or > > Gdk-Pixbuf)? If the answear is no, why not? >=20 > Pixel format conversions is not a small piece of code and the needed > pixel formats varies from scenario to scenario. Most programs will not > need such a large general infrastructure and the ones that really need > it would probably not be satisfied with a simpler solution. I think that I understand your last argument. And what I really have in mind is a simple solution, more below... >=20 > What functionality is it you miss that you think fits into a GUI > toolkit? (color management is a seperate issue to color space(pixel > format) conversions according to my interpretation of your question). I had to make RGB <-> HSL conversions, because it's more intuitive change some color properties in the HSL color space. I thinked that we could have something like GdkColor for other color spaces and functions to convert between GdkColor and the other color spaces. I think that it will help who want to play with colors in a quick way. I don't find this in any other library, and I thinked that GTK+ could be a good place for this, because it will become easiest to work with other colors representations in GTK+ applications. >=20 > /=D8yvind K. --=20 Carlos Eduardo Rodrigues Di=F3genes Projeto xLupa - http://www.unioeste.br/projetos/xlupa From murrayc@murrayc.com Fri Jun 2 09:28:59 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id A768B3B112B for ; Fri, 2 Jun 2006 09:28:59 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28843-09 for ; Fri, 2 Jun 2006 09:28:58 -0400 (EDT) Received: from webmail1.sd.dreamhost.com (webmail1.sd.dreamhost.com [66.33.201.159]) by menubar.gnome.org (Postfix) with ESMTP id 953E83B111A for ; Fri, 2 Jun 2006 09:28:58 -0400 (EDT) Received: from webmail.murrayc.com (localhost [127.0.0.1]) by webmail1.sd.dreamhost.com (Postfix) with ESMTP id 9A66F2CAF2; Fri, 2 Jun 2006 06:23:41 -0700 (PDT) Received: from 194.138.18.132 (proxying for unknown) (SquirrelMail authenticated user murrayc@murrayc.com) by webmail.murrayc.com with HTTP; Fri, 2 Jun 2006 15:23:41 +0200 (CEST) Message-ID: <1464.194.138.18.132.1149254621.squirrel@webmail.murrayc.com> In-Reply-To: <1149253312.4847.21.camel@localhost.localdomain> References: <1149104973.27709.4.camel@localhost.localdomain> <7bf6f2dc0606010816q15d512aejc30a6c93bc165e6@mail.gmail.com> <1149253312.4847.21.camel@localhost.localdomain> Date: Fri, 2 Jun 2006 15:23:41 +0200 (CEST) From: "Murray Cumming" To: Carlos Eduardo Rodrigues =?iso-8859-1?Q?Di=F3genes?= User-Agent: SquirrelMail/1.4.6 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.481 tagged_above=-999 required=2 tests=[AWL=-0.036, BAYES_00=-2.599, TW_GT=0.077, TW_TK=0.077] X-Spam-Score: -2.481 X-Spam-Level: Cc: gtk-devel-list@gnome.org, =?iso-8859-1?Q?=D8yvind_Kol=E5s?= Subject: Re: Color space transformations in GTK X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 13:28:59 -0000 > On Thu, 2006-06-01 at 17:16 +0200, yvind Kols wrote: >> On 5/31/06, Carlos Eduardo Rodrigues Digenes >> wrote: >> > Hi, >> > >> > There is any plan to add color spaces conversions in GTK+ (GDK or >> > Gdk-Pixbuf)? If the answear is no, why not? >> >> Pixel format conversions is not a small piece of code and the needed >> pixel formats varies from scenario to scenario. Most programs will not >> need such a large general infrastructure and the ones that really need >> it would probably not be satisfied with a simpler solution. > > I think that I understand your last argument. And what I really have in > mind is a simple solution, more below... > >> >> What functionality is it you miss that you think fits into a GUI >> toolkit? (color management is a seperate issue to color space(pixel >> format) conversions according to my interpretation of your question). > > I had to make RGB <-> HSL conversions, because it's more intuitive > change some color properties in the HSL color space. I thinked that we > could have something like GdkColor for other color spaces and functions > to convert between GdkColor and the other color spaces. > > I think that it will help who want to play with colors in a quick way. I > don't find this in any other library, and I thinked that GTK+ could be a > good place for this, because it will become easiest to work with other > colors representations in GTK+ applications. In case it's useful, we have some old undocumented RGB <-> HSL color value conversion code in gtkmm here: http://cvs.gnome.org/viewcvs/gtkmm/gdk/src/color.ccg?view=markup (See set_hsl(), for instance) Murray Cumming murrayc@murrayc.com www.murrayc.com www.openismus.com From timj@gtk.org Fri Jun 2 10:28:42 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 270163B043C for ; Fri, 2 Jun 2006 10:28:42 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32586-01 for ; Fri, 2 Jun 2006 10:28:40 -0400 (EDT) Received: from webmail.hansenet.de (mail04.hansenet.de [213.191.73.12]) by menubar.gnome.org (Postfix) with ESMTP id 4C4283B0272 for ; Fri, 2 Jun 2006 10:28:40 -0400 (EDT) Received: from birnet.org (213.39.189.161) by webmail.hansenet.de (7.2.059) id 447C34F100154F1E; Fri, 2 Jun 2006 16:28:37 +0200 Received: from master.birnet.private (localhost [127.0.0.1]) by birnet.org (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k52ESaZY028846 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 2 Jun 2006 16:28:36 +0200 Received: (from timj@localhost) by master.birnet.private (8.13.4/8.13.4/Submit) id k52ESPMh028844; Fri, 2 Jun 2006 16:28:25 +0200 Date: Fri, 2 Jun 2006 16:28:25 +0200 (CEST) From: Tim Janik X-X-Sender: timj@master.birnet.private To: Stefan Kost In-Reply-To: <1148567274.9054.4.camel@fluffy.local> Message-ID: References: <1148567274.9054.4.camel@fluffy.local> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.442 tagged_above=-999 required=2 tests=[AWL=0.157, BAYES_00=-2.599] X-Spam-Score: -2.442 X-Spam-Level: Cc: Gtk+ Developers Subject: Re: Serialization in libgobject X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 14:28:42 -0000 On Thu, 25 May 2006, Stefan Kost wrote: > Hi Tim, > > thanks for the extensive comments and detailed concerns. Don't you think > it would be good to keep the buzzgilla issue open. Its an enhancement > request after all and there seems to be several people wanting to have > it. well, my concern is that most of them want/think different things about serialization which was the main point of my last email. i.e. if you want to cover beast's serialization need, you already need 2 different serializers. if you then also want to cover GStreamer needs, and maybe properly human digestible config files, you can easily end up with 3 or 4 sets of mutually exclusive requirements. so without precise definition of the usage cases: - the exact required behaviour of a GLib serializer isn't clear; - we'll end up with lots of projects still rolling their own serializer because the glib one doesn't cover their needs; - the serializer will be used in scenarios that it's unplanned and suboptimal for. i'm not saying the technical issues i raised are unsolvable, in fact each one has been adressed in one way or the other in beast's serializers. rather, i'm asking: 1) what exactly do we want in glib? (i.e. which use cases should be covered) 2) which use cases should be rejected by the glib implementation(s)? 3) do the answers to (1) and (2) really cover a broad range of serialization applications out there? and i think one of the best way to be sure and positively answer (3) could be the independent development of a serialization lib outside of glib. such a library could be included into glib at a later point, once its mature enough and has an adequate track record of applications. > The bugzilla issue could serve as a tracker item. And now maybe some > more people know about thsi and add their thoughts and ideas. if you still think this should be tracked in glib bugzilla as an enhancement, you can always reopen the report. > @Andrew: is you implementation public? If so where can I find the > sources, if not can you make the serialisation part public? > > Maybe we can find a SoC student for the next summer to look at the > solutions used in our application as come up with a good proposal that > suites most apps. > > Stefan > --- ciaoTJ From timj@gtk.org Fri Jun 2 12:59:30 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id AFEC23B0140 for ; Fri, 2 Jun 2006 12:59:30 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09573-08 for ; Fri, 2 Jun 2006 12:59:29 -0400 (EDT) Received: from webmail.hansenet.de (mail01.hansenet.de [213.191.73.61]) by menubar.gnome.org (Postfix) with ESMTP id 53B8C3B00A5 for ; Fri, 2 Jun 2006 12:59:29 -0400 (EDT) Received: from birnet.org (213.39.189.161) by webmail.hansenet.de (7.2.059) id 447D3FB2000A3052; Fri, 2 Jun 2006 18:59:16 +0200 Received: from master.birnet.private (localhost [127.0.0.1]) by birnet.org (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k52GxEAY001423 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 2 Jun 2006 18:59:14 +0200 Received: (from timj@localhost) by master.birnet.private (8.13.4/8.13.4/Submit) id k52GxETr001415; Fri, 2 Jun 2006 18:59:14 +0200 Date: Fri, 2 Jun 2006 18:59:13 +0200 (CEST) From: Tim Janik X-X-Sender: timj@master.birnet.private To: Owen Taylor Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.445 tagged_above=-999 required=2 tests=[AWL=0.154, BAYES_00=-2.599] X-Spam-Score: -2.445 X-Spam-Level: Cc: Gtk+ Developers Subject: locking around source_funcs->finalize X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 16:59:30 -0000 hi Owen. reading up on g_source_unref() again, i notice that the GMainContext lock is removed and re-acquired around callback_funcs->unref(), but not around source_funcs->finalize(); supposing you're unlocking around unref() so that the handler may do things like adding a new idle handler to the context, shouldnt the same semantics be provided for source_funcs->finalize() as well? > static void > g_source_unref_internal (GSource *source, > GMainContext *context, > gboolean have_lock) > { > gpointer old_cb_data = NULL; > GSourceCallbackFuncs *old_cb_funcs = NULL; > > g_return_if_fail (source != NULL); > > if (!have_lock && context) > LOCK_CONTEXT (context); > > source->ref_count--; > if (source->ref_count == 0) > { > old_cb_data = source->callback_data; > old_cb_funcs = source->callback_funcs; > > source->callback_data = NULL; > source->callback_funcs = NULL; > > if (context && !SOURCE_DESTROYED (source)) > { > g_warning (G_STRLOC ": ref_count == 0, but source is still attached to a context!"); > source->ref_count++; > } > else if (context) > g_source_list_remove (source, context); > > if (source->source_funcs->finalize) > source->source_funcs->finalize (source); lock is being held if have_lock || context. > > g_slist_free (source->poll_fds); > source->poll_fds = NULL; > g_free (source); > } > > if (!have_lock && context) > UNLOCK_CONTEXT (context); > > if (old_cb_funcs) > { > if (have_lock) > UNLOCK_CONTEXT (context); > > old_cb_funcs->unref (old_cb_data); no lock is being held. > > if (have_lock) > LOCK_CONTEXT (context); > } > } --- ciaoTJ From matthias.clasen@gmail.com Fri Jun 2 13:14:22 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 181063B0178 for ; Fri, 2 Jun 2006 13:14:22 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10341-10 for ; Fri, 2 Jun 2006 13:14:21 -0400 (EDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.188]) by menubar.gnome.org (Postfix) with ESMTP id A84F33B0115 for ; Fri, 2 Jun 2006 13:14:20 -0400 (EDT) Received: by nf-out-0910.google.com with SMTP id l37so1131753nfc for ; Fri, 02 Jun 2006 10:14:19 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=IIiw0EjBJce9nDArNbjwYFffpCUCNPuYeqI8uOIN+ycf/KtiNjAY9VtWweGXWApORefDRcNkzdsGRROn1FJvCDC494mL9vZcz0WpDA5tNFO1IZSXHXsfZPz+YqQUJ6orpi6MA7hmCcT7pTYK8vEfd8Pic7cApyoegcqYqJXL1U8= Received: by 10.49.1.9 with SMTP id d9mr941927nfi; Fri, 02 Jun 2006 10:14:19 -0700 (PDT) Received: by 10.48.215.7 with HTTP; Fri, 2 Jun 2006 10:14:19 -0700 (PDT) Message-ID: Date: Fri, 2 Jun 2006 13:14:19 -0400 From: "Matthias Clasen" To: "Tim Janik" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.699 tagged_above=-999 required=2 tests=[AWL=-0.734, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.558, SPF_PASS=-0.001, TW_GT=0.077] X-Spam-Score: -1.699 X-Spam-Level: Cc: Owen Taylor , Gtk+ Developers Subject: Re: locking around source_funcs->finalize X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 17:14:22 -0000 On 6/2/06, Tim Janik wrote: > hi Owen. > > reading up on g_source_unref() again, i notice that the > GMainContext lock is removed and re-acquired around > callback_funcs->unref(), but not around source_funcs->finalize(); > supposing you're unlocking around unref() so that the > handler may do things like adding a new idle handler > to the context, shouldnt the same semantics be provided > for source_funcs->finalize() as well? > Interesting observation Tim. We actually ran into a deadlock in the gtk print module code where a source finalize function was trying to add another idle... So fixing this would help GTK+; it would allow us to unload the print backends. Matthias From matthias.clasen@gmail.com Fri Jun 2 13:22:11 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id B05EA3B01BA for ; Fri, 2 Jun 2006 13:22:11 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10854-10 for ; Fri, 2 Jun 2006 13:22:10 -0400 (EDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.186]) by menubar.gnome.org (Postfix) with ESMTP id 691F63B007B for ; Fri, 2 Jun 2006 13:22:10 -0400 (EDT) Received: by nf-out-0910.google.com with SMTP id l37so1137364nfc for ; Fri, 02 Jun 2006 10:22:09 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=WQtzpP4N8ZyKSiiDfpj/VtLI/AxhPsWp029H1Nvd+SG7mq6Rf64PWWm4vH8TCDmIyieOgUdMr0+Y64igzWX+Liq5FKe/p14IvHTVc7Jf8A3g/lkQrbeGGqzHTAEGhQsu+lwlvRhqNYJVH8XXuOcmjrJxkEXrBrcqWzQyQ9CuNTg= Received: by 10.48.14.19 with SMTP id 19mr950281nfn; Fri, 02 Jun 2006 10:22:09 -0700 (PDT) Received: by 10.48.215.7 with HTTP; Fri, 2 Jun 2006 10:22:09 -0700 (PDT) Message-ID: Date: Fri, 2 Jun 2006 13:22:09 -0400 From: "Matthias Clasen" To: "Petr Tomasek" In-Reply-To: <20060602070042.GA3470@ebed.etf.cuni.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1149203639.27455.9.camel@localhost.localdomain> <20060602070042.GA3470@ebed.etf.cuni.cz> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.733 tagged_above=-999 required=2 tests=[AWL=-0.691, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.558, SPF_PASS=-0.001] X-Spam-Score: -1.733 X-Spam-Level: Cc: gtk-devel-list@gnome.org Subject: Re: Print preview api X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 17:22:11 -0000 On 6/2/06, Petr Tomasek wrote: > On Thu, Jun 01, 2006 at 07:13:59PM -0400, Matthias Clasen wrote: > > Ok, after a lot of work (mostly by John and Alex), > > we finally have a proposal for a print preview > > api that will allow us to use an external viewer > > by default, but also support internal preview. > > Hi! > > I think, this is very unfortunate. Many people will > not want to use the external viewer (for reasons discused > earlier), so everyone will write his own preview > widget? Why not just have official internal > preview widget like gnome-print has and support > it by deafult? You are more than welcome to on a high-quality print preview widget and propse it for inclusion; it is a considerable amount of work though (duplicating things that are already in evince), and we are not going to hold the 2.10 release for it. Defaulting to external preview allows us to release 2.10 with preview support, which seems better than no preview support at all. In other news, Alex has just committed the preview patch with some fixes. Matthias From kris@babi-pangang.org Fri Jun 2 19:04:03 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 6F8D73B051E for ; Fri, 2 Jun 2006 19:04:03 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29568-08 for ; Fri, 2 Jun 2006 19:04:02 -0400 (EDT) Received: from nasi-goreng.babi-pangang.org (nasi-goreng.babi-pangang.org [83.166.137.20]) by menubar.gnome.org (Postfix) with ESMTP id 2B5243B04C8 for ; Fri, 2 Jun 2006 19:04:01 -0400 (EDT) Received: by nasi-goreng.babi-pangang.org (Postfix, from userid 1000) id BC1643DCA0; Sat, 3 Jun 2006 01:03:59 +0200 (CEST) Date: Sat, 3 Jun 2006 01:03:59 +0200 From: Kristian Rietveld To: Matthias Clasen Message-ID: <20060602230359.GB10757@babi-pangang.org> References: <20060531200823.GA7846@babi-pangang.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.525 tagged_above=-999 required=2 tests=[AWL=-0.003, BAYES_00=-2.599, TW_GT=0.077] X-Spam-Score: -2.525 X-Spam-Level: Cc: gtk-devel-list@gnome.org, timj@imendio.com Subject: Re: Tooltips progress X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 23:04:03 -0000 On Thu, Jun 01, 2006 at 09:33:48AM -0400, Matthias Clasen wrote: > Using x == -1 to indicate a keyboard-triggered tooltip looks a bit > odd to me; how about adding a boolean parameter for this ? Good idea, fixed this. > Regarding dedicated treeview api, I think we can do without it > (at least initially), if we have a good example in the docs. Though > lots of people will forget the selection_changed thing for keyboard > tooltips... I'll make sure some nice example code will appear in gtk-demo, where we can point people at. > Could you enhance your demo with an example of text view > tooltips on a tag ? Will do. -kris. From kris@babi-pangang.org Fri Jun 2 19:08:42 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 1CF883B11C6 for ; Fri, 2 Jun 2006 19:08:42 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29930-06 for ; Fri, 2 Jun 2006 19:08:40 -0400 (EDT) Received: from nasi-goreng.babi-pangang.org (nasi-goreng.babi-pangang.org [83.166.137.20]) by menubar.gnome.org (Postfix) with ESMTP id 89C933B11CD for ; Fri, 2 Jun 2006 19:08:40 -0400 (EDT) Received: by nasi-goreng.babi-pangang.org (Postfix, from userid 1000) id 411F73DCA0; Sat, 3 Jun 2006 01:08:37 +0200 (CEST) Date: Sat, 3 Jun 2006 01:08:37 +0200 From: Kristian Rietveld To: Tim Janik Message-ID: <20060602230837.GC10757@babi-pangang.org> References: <20060531200823.GA7846@babi-pangang.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.563 tagged_above=-999 required=2 tests=[AWL=0.036, BAYES_00=-2.599] X-Spam-Score: -2.563 X-Spam-Level: Cc: Gtk+ Developers Subject: Re: Tooltips progress X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 23:08:42 -0000 On Thu, Jun 01, 2006 at 06:21:29PM +0200, Tim Janik wrote: > On Thu, 1 Jun 2006, Matthias Clasen wrote: > the idea behind ::has-tooltip is to reduce the number of required signal > emissions to figure a tooltip. e.g. by adding a PRIVATE_GTK_* flag that > indicates if the ::query-tooltips() emission is neccessary. > maybe it'd helpt to rename that property to ::can-tooltip? Or maybe ::enable-query-tooltip? > (if you want to argue consistency with other things settable/gettable > on widgets though, then yes, you have a point for also exporting it > as a property) I would tend to add the property just for consistency. > >The example doesn't show tooltips constructed using the old tooltips > >api, but I assume those will continue to work as before, right ? > > that was the plan, i.e. you'd basically just do: I am not 100% if we can implement the complete old API using the new one, for example the public fields in the old structures and GtkTipsQuery come to mind ... I'll investigate once I get a first patch out. -kris. From exe522@hotmail.com Mon Jun 5 10:30:49 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id E7BDF3B0420 for ; Mon, 5 Jun 2006 10:30:48 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06214-09 for ; Mon, 5 Jun 2006 10:30:45 -0400 (EDT) Received: from hotmail.com (bay104-f19.bay104.hotmail.com [65.54.175.29]) by menubar.gnome.org (Postfix) with ESMTP id 81AC13B030D for ; Mon, 5 Jun 2006 10:30:44 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 5 Jun 2006 07:30:43 -0700 Message-ID: Received: from 65.54.175.200 by by104fd.bay104.hotmail.msn.com with HTTP; Mon, 05 Jun 2006 14:30:41 GMT X-Originating-IP: [83.202.13.252] X-Originating-Email: [exe522@hotmail.com] X-Sender: exe522@hotmail.com In-Reply-To: <44747D3E.8020902@imendio.com> From: "Malik NakaMura" To: richard@imendio.com Date: Mon, 05 Jun 2006 14:30:41 +0000 Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed X-OriginalArrivalTime: 05 Jun 2006 14:30:43.0753 (UTC) FILETIME=[A0A49190:01C688AC] X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-0.739 tagged_above=-999 required=2 tests=[AWL=-1.535, BAYES_05=-1.11, DNS_FROM_RFC_ABUSE=0.2, DNS_FROM_RFC_POST=1.708, MSGID_FROM_MTA_HEADER=0, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -0.739 X-Spam-Level: Cc: otaylor@redhat.com, ben2004uk@googlemail.com, scott@asofyet.org, gtk-devel-list@gnome.org Subject: Re: GTK+ >> Cocoa Native Port X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2006 14:30:49 -0000 Hi, I'm trying to implement this function : _gdk_quartz_copy_to_image (gdkimage-quartz.c) I would like to know if it is possible to get the pixels table from a GdkPixmap structure ? this is the code : GdkImage * _gdk_quartz_copy_to_image (GdkDrawable *drawable, GdkImage *image, gint src_x, gint src_y, gint dest_x, gint dest_y, gint width, gint height) { /* FIXME: Implement */ // Image Creation image = g_object_new (gdk_image_get_type (), NULL); image->width = width; image->height = height; image->byte_order = (G_BYTE_ORDER == G_LITTLE_ENDIAN) ? GDK_LSB_FIRST : GDK_MSB_FIRST; image->bpp = 4; image->bpl = image->width * image->bpp; image->bits_per_pixel = image->bpp * 8; // Get the Visual GdkColormap *colormap = gdk_drawable_get_colormap (drawable); if(colormap != NULL) { image->visual = gdk_colormap_get_visual (colormap); } // Get the depth image->depth = GDK_PIXMAP_OBJECT (drawable)->depth; // Get the pixels ??? image->mem = g_malloc (image->bpl * image->height); memset (image->mem, 0x00, image->bpl * image->height); image->mem = gdk_pixbuf_get_pixels (GDK_PIXBUF (drawable)); return image; } I think that drawable is a GdkPixmap structure, so I cant do GDK_PIXBUF (drawable), but is there a function to get the pixbuf from a pixmap ? From domlachowicz@gmail.com Mon Jun 5 10:52:51 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id B05E13B0543 for ; Mon, 5 Jun 2006 10:52:51 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08008-05 for ; Mon, 5 Jun 2006 10:52:48 -0400 (EDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.205]) by menubar.gnome.org (Postfix) with ESMTP id 0DD8B3B03E7 for ; Mon, 5 Jun 2006 10:52:47 -0400 (EDT) Received: by wx-out-0102.google.com with SMTP id i30so1182797wxd for ; Mon, 05 Jun 2006 07:52:47 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=mBHtGZClxJk0twUjUBnjIyhM/WAD6Uo9my7i+D5hoC4J+tCoUbUHFxNQxrI4rHUN+ozS7wnRgFO+uMkkEg6Pg2xZje4D8Xja5Bt7lmKFvCh6pSZMS6uV+5TpBquvMmVoaoFkNDoZEDJjdLqt3Wj9IaLQ/ggRMyfDTkEaz5x0TcU= Received: by 10.70.49.6 with SMTP id w6mr6127550wxw; Mon, 05 Jun 2006 07:52:44 -0700 (PDT) Received: by 10.70.116.12 with HTTP; Mon, 5 Jun 2006 07:52:44 -0700 (PDT) Message-ID: <2672cf4d0606050752o12a6d0d2gcb4c355cc0f35d79@mail.gmail.com> Date: Mon, 5 Jun 2006 10:52:44 -0400 From: "Dominic Lachowicz" To: "Malik NakaMura" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <44747D3E.8020902@imendio.com> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.457 tagged_above=-999 required=2 tests=[AWL=0.143, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.457 X-Spam-Level: Cc: gtk-devel-list@gnome.org Subject: Re: GTK+ >> Cocoa Native Port X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2006 14:52:51 -0000 > I think that drawable is a GdkPixmap structure, so I cant do GDK_PIXBUF > (drawable), but is there a function to get the pixbuf from a pixmap ? You might want to look at gdk_pixbuf_get_from_drawable(). Best, Dom -- Counting bodies like sheep to the rhythm of the war drums. From mclasen@redhat.com Mon Jun 5 14:15:03 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 744343B09D3; Mon, 5 Jun 2006 14:15:03 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20278-06; Mon, 5 Jun 2006 14:15:01 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id D637E3B0988; Mon, 5 Jun 2006 14:15:00 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k55IF08I024331; Mon, 5 Jun 2006 14:15:00 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k55IF0I9021827; Mon, 5 Jun 2006 14:15:00 -0400 Received: from golem.boston.redhat.com (golem.boston.redhat.com [172.16.80.24]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id k55IExAV012588; Mon, 5 Jun 2006 14:14:59 -0400 From: Matthias Clasen To: gnome-announce-list@gnome.org, gtk-devel-list@gnome.org, gtk-app-devel-list@gnome.org, gtk-list@gnome.org Content-Type: text/plain; charset=UTF-8 Date: Mon, 05 Jun 2006 14:14:59 -0400 Message-Id: <1149531299.4071.35.camel@golem.boston.redhat.com> Mime-Version: 1.0 X-Mailer: Evolution 2.7.1 (2.7.1-1) Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.543 tagged_above=-999 required=2 tests=[AWL=0.058, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.543 X-Spam-Level: Cc: Subject: GLib 2.11.2 released X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gnome-hackers@gnome.org List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2006 18:15:03 -0000 GLib 2.11.2 is now available for download at: ftp://ftp.gtk.org/pub/gtk/v2.11/ http://ftp.gnome.org/pub/GNOME/sources/glib/2.11/ glib-2.11.2.tar.bz2 md5sum: 18464b85bfd589f83897623c637a1553 glib-2.11.2.tar.gz md5sum: f728cd295ac98d4b95d850fe91c05fd5 This is a development release leading up to GLib 2.12. Notes: * This is unstable development release. While it has had a bit of testing, there are certainly plenty of bugs remaining to be found. This release should not be used in production. * Installing this version will overwrite your existing copy of GLib 2.10. If you have problems, you'll need to reinstall GLib 2.10. * GLib 2.12 will be source and binary compatible with the GLib 2.10.x series (for some caveats, see the README). At this point, the API additions in the 2.11.x series are almost finished. * Bugs should be reported to http://bugzilla.gnome.org. About GLib ========== GLib is the low-level core library that forms the basis for projects such as GTK+ and GNOME. It provides data structure handling for C, portability wrappers, and interfaces for such runtime functionality as an event loop, threads, dynamic loading, and an object system. More information about GLib is available at: http://www.gtk.org/ An installation guide for the GTK+ libraries, including GLib, can be found at: http://developer.gnome.org/doc/API/2.0/gtk/gtk-building.html Overview of Changes from GLib 2.11.1 to GLib 2.11.2 =================================================== * Add g_ascii_stroll to parse signed 64bit integers * GMarkup: add a flag to treat CDATA as text * GHashTable: add functions to remove all entries * GMainLoop: add functions to find the currently running source, and determine if it is destroyed * Bug fixes: 342563 g_atomic_thread_init() needs to be called before other _g_*_thread_init() functions 343548 Potential use after free in callers of g_string_free() 168538 Wish: Clearing contents of GHashTables 321886 GTK+ cannot be reliably used in multi-threaded applications 341826 goption.c: 'strtoll' is C99's function 343899 g_ascii_formatd dosn't work as expected for all format strings 317793 Make GEnumValue strings const 337129 Compile warnings in G_IMPLEMENT_INTERFACE 303622 What is G_TYPE_CHAR? * Updated translations (bg,dz,eu,gl,ja,nl,th,vi) A list of all bugs fixed in this release can be found at: http://bugzilla.gnome.org/buglist.cgi?bug_id=341826,342563,343548,168538,168538,321886,343899,321886,317793,337129,303622 Thanks to everybody who has contributed to this release, in the form of bug reports or patches: Peter Kjellerstedt, Kazuki Iwamoto Leonard den Ottolander, Chris Wilson, Behdad Esfahbod, Matt Barnes, ystein Johansen, Tim Janik Morten Welinder Matthias Clasen June 5, 2006 From mclasen@redhat.com Mon Jun 5 16:21:34 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 09B113B0543; Mon, 5 Jun 2006 16:21:34 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28553-01; Mon, 5 Jun 2006 16:21:32 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id 0F8903B0012; Mon, 5 Jun 2006 16:21:31 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k55KLVn7006951; Mon, 5 Jun 2006 16:21:31 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k55KLUBq020469; Mon, 5 Jun 2006 16:21:31 -0400 Received: from golem.boston.redhat.com (golem.boston.redhat.com [172.16.80.24]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id k55KLUAV025318; Mon, 5 Jun 2006 16:21:30 -0400 From: Matthias Clasen To: gnome-announce-list@gnome.org, gtk-devel-list@gnome.org, gtk-app-devel-list@gnome.org, gtk-list@gnome.org Content-Type: text/plain Date: Mon, 05 Jun 2006 16:21:30 -0400 Message-Id: <1149538890.4071.40.camel@golem.boston.redhat.com> Mime-Version: 1.0 X-Mailer: Evolution 2.7.1 (2.7.1-1) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.429 tagged_above=-999 required=2 tests=[AWL=-0.059, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, TW_GD=0.077, TW_GT=0.077, TW_XI=0.077] X-Spam-Score: -2.429 X-Spam-Level: Cc: Subject: GTK+ 2.9.2 released X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gnome-hackers@gnome.org List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2006 20:21:34 -0000 GTK+ 2.9.2 is now available for download at: http://ftp.gnome.org/pub/gnome/sources/gtk+/2.9/ gtk+-2.9.2.tar.gz md5sum: c63e7d0cf7c4e983206c3088a0fb8862 gtk+-2.9.2.tar.bz2 md5sum: 17629437af44fce03485101371c8f041 This is a development release leading up to GTK+ 2.10. Notes: * This is unstable development release. There are certainly plenty of bugs remaining to be found. This release should not be used in production. * Installing this version will overwrite your existing copy of GTK+ 2.8. If you have problems, you'll need to reinstall GTK+ 2.8. * GTK+ 2.10 will be source compatible with the GTK+ 2.8 series; the new API additions in GTK+ 2.9.0 are not yet completely finalized, so there are likely incompatibilies between this release and the final 2.10 release. * The ABI version has been bumped from 2.4.0 to 2.10.0, since the filechooser backend interface has been changed. Third-party filechooser backends need to be ported to the new interface. Other third-party modules (input methods, image loaders, etc) just need to be reinstalled in the proper location for GTK+ to find them. * Remaining issues for GTK+ 2.10 can be found with following bugzilla query: http://bugzilla.gnome.org/buglist.cgi?product=gtk%2b&target_milestone=2.10+API+Freeze&target_milestone=2.10+Freeze&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED * Bugs should be reported to http://bugzilla.gnome.org. What is GTK+ ============ GTK+ is a multi-platform toolkit for creating graphical user interfaces. Offering a complete set of widgets, GTK+ is suitable for projects ranging from small one-off tools to complete application suites. GTK+ has been designed from the ground up to support a range of languages, not only C/C++. Using GTK+ from languages such as Perl and Python (especially in combination with the Glade GUI builder) provides an effective method of rapid application development. GTK+ is free software and part of the GNU Project. However, the licensing terms for GTK+, the GNU LGPL, allow it to be used by all developers, including those developing proprietary software, without any license fees or royalties. Where to get more information about GTK+ ======================================== Information about GTK+ including links to documentation can be found at: http://www.gtk.org/ An installation guide for GTK+ 2.x is found at: http://developer.gnome.org/doc/API/2.4/gtk/gtk-building.html Common questions: http://developer.gnome.org/doc/API/2.4/gtk/gtk-question-index.html http://www.gtk.org/faq/ Overview of Changes from GTK+ 2.9.1 to 2.9.2 ============================================ * GtkPrintOperation - Support asynchronous pagination with the ::paginate signal - Add gtk_print_operation_cancel - Support application-specific widgets - Allow disabling features based on application capabilities - Optionally show progress - Change some function names in GtkPrintContext to be longer and better - Support preview, the default implementation spawns evince, but the api allows for an internal preview implementation * GtkCellView - Add a model property * GtkStatusIcon - Allow to obtain screen geometry * GtkTreeView - Many bug fixes, in particular for RTL handling - Separate sensitive and selectable properties of rows - Optionally allow rubberband selection * GtkButton - Add image-spacing style property - Add image-position property * GtkToolButton - Add icon-spacing style property * Make GTK+ work as an untrused X client * Bugs fixed: 343838 gtkprintoperationpreview.h guards 305530 Crashes while creating source code w/GtkFontSelection 341327 Memory corruption inside glib 341734 cursor blocked to dnd mode after using shift and dnd on a GtkCalendar 343453 G_DEFINE_TYPE messes up internal typenames of GdkWindow and GdkPixmap 136571 Problems running as untrusted client 168105 the right edge tab does not appear when switching tab 172535 Add support for UI builders in gtk+ 302556 GtkTreeView widget signals are badly documented 324480 Selecting first item with keyboard is difficult 340428 small cleanup 340444 don't run the custom page size dialogue 340839 Critical warnings in GtkTreeModelFilter 341898 gtk_tree_view_insert_column_with_attributes doesn't work with fixed_height_mode 342003 DnD: Conditional jump or move depends on uninitialised value 342072 Wrong drop location in GtkEntry 342096 GtkImage animation CRITICALS on switching themes 342513 widget class style property with type module 342529 gdk should set resolution on PangoCairoFontmap, not PangoCairoContext 342535 Add documentation for new GtkWidget style properties (including Since tags) 342543 can't compile gtk+ on opensolaris using sun cc 342569 Typo in decl of gdk_color_parse 342752 Need a way to specify custom tab label for custom page in Print dialog 342754 print-editor: font button dialog doesn't get focus if main window has a window group 342781 GtkPrintUnixDialog: Collate should be insensitive unless Copies is > 1 342783 GtkPrintUnixDialog: Range textinput area should be insensitive unless range radiobutton is selected 342894 Use after free inside gtk_text_view_set_buffer 342930 GtkButton should offer a way to position the image relative to the text 343088 Some typos in the PO file 343425 "grab-notify"-signal is not correctly propagated for internal children 343438 gtk_color_button_set_color() doesn't emit "color-set" signal 343475 page setup unix dialog confusion 343625 allow to get only some info from gtk_status_icon_get_geometry 343677 GtkWindow chains key-release to key-press 320431 Text too close when using East/West in a GtkToolButton 321523 GtkTreeView's test_expand_row signal emitting impractical on row expand all 342007 Warning in gtk_paned_compute_position 343233 gdk_rectangle_intersect doc 333284 expander animation not working in RTL mode 343444 change color of gtk-demo source-buffer comment color from red to DodgerBlue 343630 Small inconsistence in migration documentation 80127 Rubberbanding for GtkTreeView 341450 status icon + libnotify 341679 Allow absolute filenames in the options entries * Updated translations (bg,cy,de,el,es,et,eu,gl,gu,it,ja, nb,nl,pt_BR,th,vi) Thanks to everybody who has contributed to this release, in the form of bug reports or patches: Alexander Larsson, Behdad Esfahbod, Benjamin Berg, Caolan McNamara, Carlos Garnacho Parro, Carol Spears, Christian Persch, Chris Wilson, Claudio Saavedra, Clytie Siddall, Damon Chaplin, Daniel Lindenaar, Dan Winship, Diana Fong, Ed Catmur, Emmanuele Bassi, Havoc Pennington, Henrique Romano, Hiroyuki Ikezoe, James Moger, Johan Dahlin, Kouhei Sutou, Kristian Rietveld, Markku Vire, Mart Raudsepp, Masatake Yamato, Michael Emmel, Michael Natterer, Murray Cumming, Olexiy Avramchenko, Paolo Borelli, Patrick Monnerat, Richard Hult, Sampo Savolainen, Sebastien Bacher, Srirama Sharma, Stefan Kost, Tim Janik, Tommi Komulainen, Tor Lillqvist, Yevgen Muntyan A list of all bugs fixed in this release can be found at: http://bugzilla.gnome.org/buglist.cgi?bug_id=342072,342096,342003,341734,305530,168105,342007,342529,342535,342543,342569,341679,342752,172535,342513,342781,342783,342754,136571,341450,333284,340428,340839,341898,321523,343088,343233,324480,342894,320431,342930,343453,343425,343438,343444,340444,343475,302556,343677,343625,80127,343838,341327,168105,343630 Matthias Clasen June 5, 2006 From otaylor@redhat.com Mon Jun 5 18:10:18 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 606843B039F for ; Mon, 5 Jun 2006 18:10:18 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03967-08 for ; Mon, 5 Jun 2006 18:10:17 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id CAF5C3B0389 for ; Mon, 5 Jun 2006 18:10:16 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k55MAGwn013331; Mon, 5 Jun 2006 18:10:16 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k55MAGNr013297; Mon, 5 Jun 2006 18:10:16 -0400 Received: from localhost.localdomain (sebastian-int.corp.redhat.com [172.16.52.221]) by devserv.devel.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k55MAFJC021457; Mon, 5 Jun 2006 18:10:15 -0400 From: Owen Taylor In-Reply-To: <2672cf4d0606050752o12a6d0d2gcb4c355cc0f35d79@mail.gmail.com> References: <44747D3E.8020902@imendio.com> <2672cf4d0606050752o12a6d0d2gcb4c355cc0f35d79@mail.gmail.com> Content-Type: text/plain Date: Mon, 05 Jun 2006 15:10:09 -0400 Message-Id: <1149534609.2441.107.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 (2.6.1-1.fc5.2) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.187 tagged_above=-999 required=2 tests=[AWL=-0.199, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.478, FORGED_RCVD_HELO=0.135, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.187 X-Spam-Level: Cc: gtk-devel-list@gnome.org Subject: Re: GTK+ >> Cocoa Native Port X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2006 22:10:18 -0000 On Mon, 2006-06-05 at 10:52 -0400, Dominic Lachowicz wrote: > > I think that drawable is a GdkPixmap structure, so I cant do GDK_PIXBUF > > (drawable), but is there a function to get the pixbuf from a pixmap ? > > You might want to look at gdk_pixbuf_get_from_drawable(). Not going to help here, I think .. copy_to_image() is the backend function used to implement gdk_pixbuf_get_from_drawable(). :-) This is the point in the code where you need to figure out how to copy pixels from a native drawable into an image buffer, which is going to involve native graphics system calls. If you can find docs on how to take a screenshot of a window in OS X, that will be similar code to what is needed here. Owen From rpmcruz@clix.pt Mon Jun 5 21:41:34 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id B9E363B03FB for ; Mon, 5 Jun 2006 21:41:34 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15260-05 for ; Mon, 5 Jun 2006 21:41:33 -0400 (EDT) Received: from mailrly02.isp.novis.pt (mailrly02.isp.novis.pt [195.23.133.212]) by menubar.gnome.org (Postfix) with ESMTP id 84DA33B0076 for ; Mon, 5 Jun 2006 21:41:32 -0400 (EDT) Received: (qmail 21302 invoked from network); 6 Jun 2006 01:41:30 -0000 Received: from unknown (HELO mailfrt04.isp.novis.pt) ([195.23.133.196]) (envelope-sender ) by mailrly02.isp.novis.pt with compressed SMTP; 6 Jun 2006 01:41:30 -0000 Received: (qmail 17342 invoked from network); 6 Jun 2006 01:41:29 -0000 Received: from unknown (HELO [10.0.0.2]) (Sent_by_authenticated_user_x2476431@[87.196.74.232]) (envelope-sender ) by mailfrt04.isp.novis.pt with SMTP; 6 Jun 2006 01:41:29 -0000 From: Ricardo Cruz To: gtk-devel-list@gnome.org Date: Tue, 6 Jun 2006 02:48:21 +0100 User-Agent: KMail/1.9.1 X-Face: $29d{(U~(^/X.rR|7i6syM3jeJ}N+*%U-#Bzl5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200606060248.21205.rpmcruz@clix.pt> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.657 tagged_above=-999 required=2 tests=[AWL=-0.917, BAYES_20=-0.74] X-Spam-Score: -1.657 X-Spam-Level: Subject: GtkComboBoxEntry -- changing entry line value X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2006 01:41:34 -0000 Hi there, Is there a way to set a value for a GtkComboBoxEntry line entry? I am currently just adding an entry, set it as selected and remove it, which is a pretty nasty work-around. By the way, is it planned to add a GtkEditable interface for it? That would be really sweet and, if affirmitive, I could work on making a patch. Cheers, Ricardo -- Fourth Law of Thermodynamics: If the probability of success is not almost one, it is damn near zero. -- David Ellis From markku.vire@kolumbus.fi Tue Jun 6 04:39:15 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 5E3DD3B0C57 for ; Tue, 6 Jun 2006 04:39:15 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23318-01 for ; Tue, 6 Jun 2006 04:39:13 -0400 (EDT) Received: from fep02-app.kolumbus.fi (fep02-0.kolumbus.fi [193.229.0.44]) by menubar.gnome.org (Postfix) with ESMTP id C21BF3B0A19 for ; Tue, 6 Jun 2006 04:37:26 -0400 (EDT) Received: from smtp.kolumbus.fi ([193.229.55.124]) by fep02-app.kolumbus.fi with ESMTP id <20060606083725.NGAZ5174.fep02-app.kolumbus.fi@smtp.kolumbus.fi>; Tue, 6 Jun 2006 11:37:25 +0300 X-Mailer: Openwave WebEngine, version 2.8.12 (webedge20-101-197-20030912) X-Originating-IP: [62.236.91.3] From: To: Ricardo Cruz , Date: Tue, 6 Jun 2006 11:37:24 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <20060606083725.NGAZ5174.fep02-app.kolumbus.fi@smtp.kolumbus.fi> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.504 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, NO_REAL_NAME=0.961, SPF_PASS=-0.001] X-Spam-Score: -1.504 X-Spam-Level: X-Mailman-Approved-At: Tue, 06 Jun 2006 07:05:18 -0400 Cc: Subject: Re: GtkComboBoxEntry -- changing entry line value X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2006 08:39:15 -0000 Hi, You can get the entry by calling gtk_bin_get_child(box); and then using any methods of GtkEntry to manipulate the text. > Is there a way to set a value for a GtkComboBoxEntry line entry? I am > currently just adding an entry, set it as selected and remove it, which is a > pretty nasty work-around. -Markku- From markku.vire@kolumbus.fi Tue Jun 6 04:39:55 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 544743B0B78 for ; Tue, 6 Jun 2006 04:39:55 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23288-09 for ; Tue, 6 Jun 2006 04:39:52 -0400 (EDT) Received: from fep02-app.kolumbus.fi (fep02-0.kolumbus.fi [193.229.0.44]) by menubar.gnome.org (Postfix) with ESMTP id BD56C3B0A19 for ; Tue, 6 Jun 2006 04:39:51 -0400 (EDT) Received: from smtp.kolumbus.fi ([193.229.55.124]) by fep02-app.kolumbus.fi with ESMTP id <20060606083950.NHYK5174.fep02-app.kolumbus.fi@smtp.kolumbus.fi>; Tue, 6 Jun 2006 11:39:50 +0300 X-Mailer: Openwave WebEngine, version 2.8.12 (webedge20-101-197-20030912) X-Originating-IP: [62.236.91.3] From: To: Ricardo Cruz , Date: Tue, 6 Jun 2006 11:39:50 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <20060606083950.NHYK5174.fep02-app.kolumbus.fi@smtp.kolumbus.fi> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.504 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, NO_REAL_NAME=0.961, SPF_PASS=-0.001] X-Spam-Score: -1.504 X-Spam-Level: X-Mailman-Approved-At: Tue, 06 Jun 2006 07:05:18 -0400 Cc: Subject: Re: GtkComboBoxEntry -- changing entry line value X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2006 08:39:55 -0000 Hi, You can get the entry by calling gtk_bin_get_child(box); and then using any methods of GtkEntry to manipulate the text. > Is there a way to set a value for a GtkComboBoxEntry line entry? I am > currently just adding an entry, set it as selected and remove it, which is a > pretty nasty work-around. -Markku- From federico@ximian.com Tue Jun 6 11:45:51 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id A23E83B00FF for ; Tue, 6 Jun 2006 11:45:51 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01904-10 for ; Tue, 6 Jun 2006 11:45:35 -0400 (EDT) Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) by menubar.gnome.org (Postfix) with ESMTP id 6D4083B0ADD for ; Tue, 6 Jun 2006 11:45:33 -0400 (EDT) Received: (qmail 15590 invoked from network); 6 Jun 2006 15:45:31 -0000 Received: from localhost (HELO ?164.99.120.162?) (127.0.0.1) by localhost with SMTP; 6 Jun 2006 15:45:31 -0000 From: Federico Mena Quintero To: GTK+ development mailing list Content-Type: text/plain Date: Tue, 06 Jun 2006 10:41:22 -0500 Message-Id: <1149608483.14088.54.camel@cacharro.xalalinux.org> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.574 tagged_above=-999 required=2 tests=[AWL=0.025, BAYES_00=-2.599] X-Spam-Score: -2.574 X-Spam-Level: Cc: Michael.meeks@novell.com Subject: Default timeouts X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2006 15:45:51 -0000 In gtksettings.c we have #define DEFAULT_TIMEOUT_INITIAL 200 #define DEFAULT_TIMEOUT_REPEAT 20 for the "gtk-timeout-initial" and "gtk-timeout-repeat" settings, respectively. This means we wait for a fifth of a second before we start repeating, but then we try to repeat 50 times per second. Isn't the repeat timeout way too short? This is why clicking on a calendar arrow takes you back tens of months in no time, and also makes it hard to use spin buttons. Also, Michael Meeks has the following words of wisdom in a Novell bug about the calendar in gnome-panel's clock: > In essence the timeout is way too short for switching days; also - > in the panel applet the timeout has a higher priority than the > queued resize of the display (and hence the redraw) - so in > essence we skip days even faster since we never have to render > them. > > Lowering the priority there, and lengthening the timeouts gives > a far more reasonable, usable experience without getting rid > of the whole auto-repeat principle [...] I.e. instead of using g_timeout_add() in gtkcalendar, we would use g_timeout_add_full (G_PRIORITY_DEFAULT_IDLE, ...), or perhaps (GDK_PRIORITY_REDRAW + positive_constant): both are lower priority than GTK_PRIORITY_RESIZE. Federico From michael.meeks@novell.com Tue Jun 6 12:33:58 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 74B9F3B0197 for ; Tue, 6 Jun 2006 12:33:58 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05177-09 for ; Tue, 6 Jun 2006 12:33:57 -0400 (EDT) Received: from gwia-smtp.id2.novell.com (public.id2-vpn.continvity.gns.novell.com [195.33.99.129]) by menubar.gnome.org (Postfix) with ESMTP id 3714E3B014F for ; Tue, 6 Jun 2006 12:33:57 -0400 (EDT) Received: from [192.168.0.8] (l4-client.id2.novell.com [::ffff:149.44.117.251]) by gwia-smtp.id2.novell.com with ESMTP (TLS encrypted); Tue, 06 Jun 2006 17:33:30 +0100 From: Michael Meeks To: Federico Mena Quintero In-Reply-To: <1149608483.14088.54.camel@cacharro.xalalinux.org> References: <1149608483.14088.54.camel@cacharro.xalalinux.org> Content-Type: text/plain Organization: Novell, Inc. Date: Tue, 06 Jun 2006 17:37:54 +0100 Message-Id: <1149611874.2202.2.camel@t60p.site> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.427 tagged_above=-999 required=2 tests=[AWL=-0.028, BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2] X-Spam-Score: -2.427 X-Spam-Level: Cc: GTK+ development mailing list Subject: Re: Default timeouts X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: michael.meeks@novell.com List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2006 16:33:58 -0000 On Tue, 2006-06-06 at 10:41 -0500, Federico Mena Quintero wrote: > > In essence the timeout is way too short for switching days; also - > > in the panel applet the timeout has a higher priority than the > > queued resize of the display (and hence the redraw) - so in > > essence we skip days even faster since we never have to render > > them. Of course - this is particularly applicable for the calendar where it really makes sense to actually see the month rendered each time you switch to a different month or year. Of course with a spin-button I guess throttling the spin rate to that of the refresh rate would (perhaps) be problematic. Then again re-rendering a spin-button is presumably an extremely fast operation. HTH, Michael. -- michael.meeks@novell.com <><, Pseudo Engineer, itinerant idiot From carlosgc@gnome.org Wed Jun 7 07:48:25 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id BACA33B0C6A for ; Wed, 7 Jun 2006 07:48:25 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08136-01 for ; Wed, 7 Jun 2006 07:48:23 -0400 (EDT) Received: from localhost.localdomain (gsyc090.dat.escet.urjc.es [193.147.71.90]) by menubar.gnome.org (Postfix) with ESMTP id D0D083B01EA for ; Wed, 7 Jun 2006 07:48:22 -0400 (EDT) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 945E110F28E for ; Wed, 7 Jun 2006 13:48:19 +0200 (CEST) From: Carlos Garcia Campos To: GTK+ development mailing list Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-hBJf7M2jws0KBkd4rYip" Date: Wed, 07 Jun 2006 13:48:17 +0200 Message-Id: <1149680898.3302.9.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.285 tagged_above=-999 required=2 tests=[AWL=0.179, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.285 X-Spam-Level: Subject: Evince preview mode X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 11:48:25 -0000 --=-hBJf7M2jws0KBkd4rYip Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi,=20 since gtk+ is using evince as an external printing previewer, I'm implementing a preview mode in evince, available through the command line (--preview). It's based on the ephy printing previewer where the menubar is hidden and the toolbar contains navigation items and a close button. Here is an screenshot: http://carlosgc.linups.org/files/evince-preview-mode.png Any other thing expected by a previewer? --=20 Carlos Garcia Campos (KaL) elkalmail@yahoo.es carlosgc@gnome.org http://carlosgc.linups.org PGP key: http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0x523E6462 --=-hBJf7M2jws0KBkd4rYip Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQBEhr0BjxBOalI+ZGIRAmSgAJ9Ksy9L8QqVxpvNQCtbejp/0HRZXACeNcmq O8LT0nzkGzw+qcPFuVqZ3y8= =xZYn -----END PGP SIGNATURE----- --=-hBJf7M2jws0KBkd4rYip-- From hfiguiere@teaser.fr Wed Jun 7 08:28:18 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id AC8923B0CE2; Wed, 7 Jun 2006 08:28:18 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11220-01; Wed, 7 Jun 2006 08:28:15 -0400 (EDT) Received: from xandros.com (smtp1.xandros.com [209.87.238.70]) by menubar.gnome.org (Postfix) with ESMTP id EC3713B0CD7; Wed, 7 Jun 2006 08:28:14 -0400 (EDT) Received: from [172.18.1.132] (toronto-hs-216-138-231-194.s-ip.magma.ca [216.138.231.194]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by xandros.com (Postfix) with ESMTP id E7D80C028; Wed, 7 Jun 2006 08:28:12 -0400 (EDT) Message-ID: <4486C65A.5060800@teaser.fr> Date: Wed, 07 Jun 2006 08:28:10 -0400 From: Hubert Figuiere User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: Carlos Garcia Campos References: <1149680898.3302.9.camel@localhost.localdomain> In-Reply-To: <1149680898.3302.9.camel@localhost.localdomain> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.499 tagged_above=-999 required=2 tests=[AWL=0.100, BAYES_00=-2.599] X-Spam-Score: -2.499 X-Spam-Level: Cc: GTK+ development mailing list Subject: Re: Evince preview mode X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 12:28:19 -0000 Carlos Garcia Campos wrote: > Hi, > > since gtk+ is using evince as an external printing previewer, I'm > implementing a preview mode in evince, available through the command > line (--preview). It's based on the ephy printing previewer where the > menubar is hidden and the toolbar contains navigation items and a close > button. Here is an screenshot: > > http://carlosgc.linups.org/files/evince-preview-mode.png > > Any other thing expected by a previewer? It think it should have a menu bar, even if it is way simplier than Evince, and the button to close in the toolbar should be removed because it is "uncommon" and in fact confuse the user on what to do. Closing the window should be all that needed, or doing a file->close in the menu, Also, zoom in and zoom out are very useful. Hub From paolo.maggi@gmail.com Wed Jun 7 08:15:10 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 9C3E63B08CC for ; Wed, 7 Jun 2006 08:15:10 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10407-05 for ; Wed, 7 Jun 2006 08:15:09 -0400 (EDT) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.172]) by menubar.gnome.org (Postfix) with ESMTP id 8B7343B0303 for ; Wed, 7 Jun 2006 08:15:08 -0400 (EDT) Received: by ug-out-1314.google.com with SMTP id c2so258875ugf for ; Wed, 07 Jun 2006 05:15:07 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:subject:from:to:cc:content-type:date:message-id:mime-version:x-mailer:content-transfer-encoding; b=K90OlbUivfHjc3p7Mf7NxXYQ7dM8ZBxC+0BsgOJcKZJuB7jHCl0ZAGBW4g8105rAzePSP5EyfdcA7LlHJh+VEWxuXvCS7dbrv6RMBVJzQ/vwIPq71eGzz8nn2EwMpB2LP+LFhmJsovQOwZfLUn1MKDz4iRRATWR1zOQleW/WqEg= Received: by 10.67.105.19 with SMTP id h19mr435594ugm; Wed, 07 Jun 2006 05:15:06 -0700 (PDT) Received: from elilix.polito.it ( [130.192.16.224]) by mx.gmail.com with ESMTP id q1sm888781uge.2006.06.07.05.15.05; Wed, 07 Jun 2006 05:15:06 -0700 (PDT) From: Paolo Maggi To: carlosgc@gnome.org Content-Type: text/plain Date: Wed, 07 Jun 2006 14:15:04 +0200 Message-Id: <1149682504.5804.33.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.6 tagged_above=-999 required=2 tests=[AWL=0.000, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.6 X-Spam-Level: X-Mailman-Approved-At: Wed, 07 Jun 2006 09:03:01 -0400 Cc: gtk-devel-list@gnome.org Subject: Re: Evince preview mode X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 12:15:10 -0000 Hi, cia > since gtk+ is using evince as an external printing previewer, I'm > implementing a preview mode in evince, available through the command > line (--preview). It's based on the ephy printing previewer where the > menubar is hidden and the toolbar contains navigation items and a close > button. Here is an screenshot: > > http://carlosgc.linups.org/files/evince-preview-mode.png > > Any other thing expected by a previewer? - Zoom - Direct jump to a given page Please, look also at the gedit 2.14.x print previewer. Probably we also need a way to specify paper orientation on the command line (or is orientation already specified in the PDF file?) Ciao, Paolo From matthias.clasen@gmail.com Wed Jun 7 09:13:05 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id E24273B0D07 for ; Wed, 7 Jun 2006 09:13:04 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14781-07 for ; Wed, 7 Jun 2006 09:13:02 -0400 (EDT) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.202]) by menubar.gnome.org (Postfix) with ESMTP id 00C823B0B41 for ; Wed, 7 Jun 2006 09:13:01 -0400 (EDT) Received: by nz-out-0102.google.com with SMTP id 9so196545nzo for ; Wed, 07 Jun 2006 06:13:01 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=saqMihVje8FYa9UdpyLa1+dlefvQoIGQxKH7/1Zo60aYxymeM8Pd6GyFWAgY0o+p1vKDz7amMyAC6pjntEQBEcP8uj0rJL3yYZX1hequAVkJsd5sQslhyn8T44EZjEA/hsuQz0+1EdqmPuNMRK0Lseu0seEU88n8Ei5Ii1IMFBQ= Received: by 10.37.13.40 with SMTP id q40mr711105nzi; Wed, 07 Jun 2006 06:13:00 -0700 (PDT) Received: by 10.37.21.14 with HTTP; Wed, 7 Jun 2006 06:13:00 -0700 (PDT) Message-ID: Date: Wed, 7 Jun 2006 09:13:00 -0400 From: "Matthias Clasen" To: "Carlos Garcia Campos" In-Reply-To: <1149680898.3302.9.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1149680898.3302.9.camel@localhost.localdomain> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.508 tagged_above=-999 required=2 tests=[AWL=0.092, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.508 X-Spam-Level: Cc: GTK+ development mailing list Subject: Re: Evince preview mode X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 13:13:05 -0000 On 6/7/06, Carlos Garcia Campos wrote: > Hi, > > since gtk+ is using evince as an external printing previewer, I'm > implementing a preview mode in evince, available through the command > line (--preview). It's based on the ephy printing previewer where the > menubar is hidden and the toolbar contains navigation items and a close > button. Here is an screenshot: > > http://carlosgc.linups.org/files/evince-preview-mode.png > > Any other thing expected by a previewer? A print button. From n1huq@hotmail.com Wed Jun 7 13:11:51 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 04F873B04FC for ; Wed, 7 Jun 2006 13:11:51 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32024-05 for ; Wed, 7 Jun 2006 13:11:49 -0400 (EDT) Received: from hotmail.com (bay114-dav5.bay114.hotmail.com [65.54.169.77]) by menubar.gnome.org (Postfix) with ESMTP id 192433B00F5 for ; Wed, 7 Jun 2006 13:11:49 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 7 Jun 2006 10:11:48 -0700 Message-ID: Received: from 68.0.250.43 by BAY114-DAV5.phx.gbl with DAV; Wed, 07 Jun 2006 17:11:46 +0000 X-Originating-IP: [68.0.250.43] X-Originating-Email: [n1huq@hotmail.com] X-Sender: n1huq@hotmail.com From: "Sydney Faria" To: Date: Wed, 7 Jun 2006 13:15:56 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-OriginalArrivalTime: 07 Jun 2006 17:11:48.0135 (UTC) FILETIME=[75E3BB70:01C68A55] X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=1.984 tagged_above=-999 required=2 tests=[BAYES_50=0.001, DNS_FROM_RFC_ABUSE=0.2, DNS_FROM_RFC_POST=1.708, MSGID_FROM_MTA_HEADER=0, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, TW_GT=0.077] X-Spam-Score: 1.984 X-Spam-Level: * Subject: combo box problem X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 17:11:51 -0000 The following simple example of a gtk_combo_box compiles and works OK it the select_cb() is empty. The line marked gives a compiler error: undefined reference to gtk_combo_box_get_active_text. I am befuddled! sydney #include #include GtkWidget *window, *combo; static gboolean delete_event(GtkWidget *widget, GdkEvent *event, gpointer data) { return FALSE; } static void destroy(GtkWidget *widget, gpointer data) { gtk_main_quit(); } static void select_cb(GtkWidget *widget, gpointer data) { /* comment out following 2 lines and program compiles and works OK */ gchar *str = gtk_combo_box_get_active_text(GTK_COMBO_BOX(combo)); /* compile error */ g_print("active text: %s\n", str); } int main( int argc, char *argv[] ) { GtkWidget *button, *hbox; gtk_init (&argc, &argv); /* init gtk */ window = gtk_window_new (GTK_WINDOW_TOPLEVEL); gtk_container_set_border_width(GTK_CONTAINER(window), 10); g_signal_connect(G_OBJECT(window), "delete_event", G_CALLBACK(delete_event), NULL); g_signal_connect(G_OBJECT(window), "destroy", G_CALLBACK(destroy), NULL); hbox = gtk_hbox_new(TRUE, 20); gtk_container_add(GTK_CONTAINER(window), hbox); button = gtk_button_new_with_label("Select text"); g_signal_connect(G_OBJECT(button), "clicked", G_CALLBACK(select_cb), NULL); gtk_box_pack_start(GTK_BOX(hbox), button, FALSE, FALSE, 0); combo = gtk_combo_box_new_text(); gtk_box_pack_start(GTK_BOX(hbox), combo, FALSE, FALSE, 0); gtk_combo_box_insert_text(GTK_COMBO_BOX(combo), 0, "Astring"); gtk_combo_box_append_text(GTK_COMBO_BOX(combo), "Bstring"); gtk_combo_box_append_text(GTK_COMBO_BOX(combo), "Cstring"); gtk_combo_box_append_text(GTK_COMBO_BOX(combo), "Dstring"); gtk_combo_box_append_text(GTK_COMBO_BOX(combo), "Estring"); gtk_combo_box_insert_text(GTK_COMBO_BOX(combo), 3, "xxxxx"); gtk_widget_show_all(window); gtk_main(); return 0; } From ali@avrc.city.ac.uk Wed Jun 7 13:20:43 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id B9C6A3B0D3D for ; Wed, 7 Jun 2006 13:20:43 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32493-04 for ; Wed, 7 Jun 2006 13:20:42 -0400 (EDT) Received: from firewall.avrc.city.ac.uk (optosun2.city.ac.uk [138.40.167.2]) by menubar.gnome.org (Postfix) with ESMTP id ACA3B3B0BDC for ; Wed, 7 Jun 2006 13:20:40 -0400 (EDT) Received: from tom.avrc.city.ac.uk (IDENT:U2FsdGVkX1/zwWSA4Vc+XKbUWVXUavCLm3rPqXMMlDg@tom [192.168.137.104]) by firewall.avrc.city.ac.uk (8.9.3/8.9.3) with ESMTP id SAA27971; Wed, 7 Jun 2006 18:10:27 +0100 Received: from tom.avrc.city.ac.uk (localhost.localdomain [127.0.0.1]) by tom.avrc.city.ac.uk (8.13.1/8.13.1) with ESMTP id k57HTT2Y031243; Wed, 7 Jun 2006 18:29:29 +0100 Date: Wed, 07 Jun 2006 17:29:28 +0000 From: "J. Ali Harlow" To: Sydney Faria References: In-Reply-To: (from n1huq@hotmail.com on Wed Jun 7 18:15:56 2006) X-Mailer: Balsa 2.2.6 Message-Id: <1149701368l.5713l.3l@tom.avrc.city.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; DelSp=Yes; Format=Flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.525 tagged_above=-999 required=2 tests=[AWL=-0.003, BAYES_00=-2.599, TW_GT=0.077] X-Spam-Score: -2.525 X-Spam-Level: Cc: gtk-devel-list@gnome.org Subject: Re: combo box problem X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 17:20:43 -0000 On 07/06/06 18:15:56, Sydney Faria wrote: > The following simple example of a gtk_combo_box compiles and works OK > it the select_cb() is empty. The line marked gives a compiler error: =20 > undefined reference to gtk_combo_box_get_active_text. gtk_combo_box_get_active_text was added in Gtk+ v2.6 Ali. From carlosgc@gnome.org Wed Jun 7 14:37:47 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id D45D43B0546 for ; Wed, 7 Jun 2006 14:37:47 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05339-08 for ; Wed, 7 Jun 2006 14:37:46 -0400 (EDT) Received: from localhost.localdomain (gsyc090.dat.escet.urjc.es [193.147.71.90]) by menubar.gnome.org (Postfix) with ESMTP id 3EC7D3B03F7 for ; Wed, 7 Jun 2006 14:37:46 -0400 (EDT) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 0ABE610F28E for ; Wed, 7 Jun 2006 20:37:40 +0200 (CEST) From: Carlos Garcia Campos To: gtk-devel-list@gnome.org In-Reply-To: References: <1149680898.3302.9.camel@localhost.localdomain> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-WdU94ldj/PvL1mhYRti9" Date: Wed, 07 Jun 2006 20:37:39 +0200 Message-Id: <1149705460.3302.25.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.354 tagged_above=-999 required=2 tests=[AWL=0.110, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.354 X-Spam-Level: Subject: Re: Evince preview mode X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 18:37:48 -0000 --=-WdU94ldj/PvL1mhYRti9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable El mi=C3=A9, 07-06-2006 a las 09:13 -0400, Matthias Clasen escribi=C3=B3: > On 6/7/06, Carlos Garcia Campos wrote: > > Hi, > > > > since gtk+ is using evince as an external printing previewer, I'm > > implementing a preview mode in evince, available through the command > > line (--preview). It's based on the ephy printing previewer where the > > menubar is hidden and the toolbar contains navigation items and a close > > button. Here is an screenshot: > > > > http://carlosgc.linups.org/files/evince-preview-mode.png > > > > Any other thing expected by a previewer? >=20 > A print button. >=20 hmm, when the user selects preview from the print dialog, the dialog disappears and evince is launched, so that if evince has a print button we should print the document directly without showing the print dialog again. I see several problems in this approach. First of all we can't know the print settings selected by the user from evince. And, should we close evince or keep it opened after clicking on print? Is it possible to print a pdf file with the new gtk+ api without showing any dialog?=20 I think it's very confused. The best solution would be not to hide the dialog when the previewer is launched, so that once the user is happy with the results showed in evince, he simply clicks on print button.=20 --=20 Carlos Garcia Campos (KaL) elkalmail@yahoo.es carlosgc@gnome.org http://carlosgc.linups.org PGP key: http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0x523E6462 --=-WdU94ldj/PvL1mhYRti9 Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQBEhxzzjxBOalI+ZGIRAsatAJ4+rfTQPQwp9+YtbRKpPmVlDuEG9ACfclx7 9c9NhlEvkjGZjMS42o6vmHM= =TbYL -----END PGP SIGNATURE----- --=-WdU94ldj/PvL1mhYRti9-- From matthias.clasen@gmail.com Wed Jun 7 19:34:00 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 62A323B036A for ; Wed, 7 Jun 2006 19:34:00 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23001-06 for ; Wed, 7 Jun 2006 19:33:56 -0400 (EDT) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.203]) by menubar.gnome.org (Postfix) with ESMTP id A86BE3B0E6E for ; Wed, 7 Jun 2006 19:33:56 -0400 (EDT) Received: by nz-out-0102.google.com with SMTP id o37so261498nzf for ; Wed, 07 Jun 2006 16:33:55 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=LpgZtLrjc9Sc3giRUzuWDX2naMTMsbgrizT1aggkQjCN27Pm9kFPU1c5Bra0LikmJaw1sDQO0paAD7N3OQwY1+3Y9JTdMwkT9YBnlgCbMohSYLzhRt6yPFasRtdkLK24rM8sI5l8EdJ/+dpxDSU/+GFlNbztpO8kky973RVbTmY= Received: by 10.36.103.6 with SMTP id a6mr1426226nzc; Wed, 07 Jun 2006 16:33:53 -0700 (PDT) Received: by 10.37.21.14 with HTTP; Wed, 7 Jun 2006 16:33:52 -0700 (PDT) Message-ID: Date: Wed, 7 Jun 2006 19:33:52 -0400 From: "Matthias Clasen" To: "Carlos Garcia Campos" In-Reply-To: <1149705460.3302.25.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1149680898.3302.9.camel@localhost.localdomain> <1149705460.3302.25.camel@localhost.localdomain> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.509 tagged_above=-999 required=2 tests=[AWL=0.091, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.509 X-Spam-Level: Cc: gtk-devel-list@gnome.org Subject: Re: Evince preview mode X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 23:34:00 -0000 On 6/7/06, Carlos Garcia Campos wrote: > hmm, when the user selects preview from the print dialog, the dialog > disappears and evince is launched, so that if evince has a print button > we should print the document directly without showing the print dialog > again. I see several problems in this approach. First of all we can't > know the print settings selected by the user from evince. And, should we > close evince or keep it opened after clicking on print? Is it possible > to print a pdf file with the new gtk+ api without showing any dialog? Sure, figuring out the best way to transfer the print settings to evince is part of this. And yes, printing preformatted pdf is supported. > > I think it's very confused. The best solution would be not to hide the > dialog when the previewer is launched, so that once the user is happy > with the results showed in evince, he simply clicks on print button. > Apple does it too, so it can't be all bad... Matthias From hfiguiere@teaser.fr Wed Jun 7 21:05:56 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 3CAD23B051D for ; Wed, 7 Jun 2006 21:05:56 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27783-02 for ; Wed, 7 Jun 2006 21:05:53 -0400 (EDT) Received: from xandros.com (smtp1.xandros.com [209.87.238.70]) by menubar.gnome.org (Postfix) with ESMTP id 31DC43B0414 for ; Wed, 7 Jun 2006 21:05:53 -0400 (EDT) Received: from [172.18.1.132] (toronto-hs-216-138-231-194.s-ip.magma.ca [216.138.231.194]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by xandros.com (Postfix) with ESMTP id A37413E02E; Wed, 7 Jun 2006 21:05:51 -0400 (EDT) Message-ID: <448777ED.1020804@teaser.fr> Date: Wed, 07 Jun 2006 21:05:49 -0400 From: Hubert Figuiere User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: Matthias Clasen References: <1149680898.3302.9.camel@localhost.localdomain> <1149705460.3302.25.camel@localhost.localdomain> In-Reply-To: X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.506 tagged_above=-999 required=2 tests=[AWL=0.093, BAYES_00=-2.599] X-Spam-Score: -2.506 X-Spam-Level: Cc: gtk-devel-list@gnome.org Subject: Re: Evince preview mode X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 01:05:56 -0000 >> I think it's very confused. The best solution would be not to hide the >> dialog when the previewer is launched, so that once the user is happy >> with the results showed in evince, he simply clicks on print button. >> > > Apple does it too, so it can't be all bad... That is the kind of blind thinking that lead to nowhere. Remember just one thing: if it does not please Steve Jobs, it does not goes. That how it works at Apple. Bottom line: wrong argument. Hub From alexl@redhat.com Thu Jun 8 08:09:59 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 5B8C83B0EF5; Thu, 8 Jun 2006 08:09:59 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32659-09; Thu, 8 Jun 2006 08:09:58 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id B35BC3B075A; Thu, 8 Jun 2006 08:09:57 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k58C9u9M020757; Thu, 8 Jun 2006 08:09:56 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k58C9u0T021240; Thu, 8 Jun 2006 08:09:56 -0400 Received: from [127.0.0.1] (sebastian-int.corp.redhat.com [172.16.52.221]) by devserv.devel.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k58C9tGO011054; Thu, 8 Jun 2006 08:09:56 -0400 From: Alexander Larsson To: Matthias Clasen In-Reply-To: References: <1149680898.3302.9.camel@localhost.localdomain> <1149705460.3302.25.camel@localhost.localdomain> Content-Type: text/plain Date: Thu, 08 Jun 2006 14:09:55 +0200 Message-Id: <1149768596.3023.11.camel@greebo> Mime-Version: 1.0 X-Mailer: Evolution 2.7.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.587 tagged_above=-999 required=2 tests=[AWL=0.014, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.587 X-Spam-Level: Cc: gtk-devel-list@gnome.org Subject: Re: Evince preview mode X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 12:09:59 -0000 On Wed, 2006-06-07 at 19:33 -0400, Matthias Clasen wrote: > On 6/7/06, Carlos Garcia Campos wrote: > > > hmm, when the user selects preview from the print dialog, the dialog > > disappears and evince is launched, so that if evince has a print button > > we should print the document directly without showing the print dialog > > again. I see several problems in this approach. First of all we can't > > know the print settings selected by the user from evince. And, should we > > close evince or keep it opened after clicking on print? Is it possible > > to print a pdf file with the new gtk+ api without showing any dialog? > > Sure, figuring out the best way to transfer the print settings to evince > is part of this. And yes, printing preformatted pdf is supported. This is tricky. What if the preview was launched without even showing the dialog, or if the user hadn't picked the right printer yet when clicking on preview. Also, it will print differently by generating pdf and then converting that to postscript, instead of generating postscript directly. Ideally this should produce as-good output, but thats not really guaranteed. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl@redhat.com alla@lysator.liu.se He's an immortal umbrella-wielding cyborg with no name. She's a tortured green-skinned Hell's Angel from a different time and place. They fight crime! From lists@nabble.com Thu Jun 8 21:35:27 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id BFE263B0E9B for ; Thu, 8 Jun 2006 21:35:27 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18339-04 for ; Thu, 8 Jun 2006 21:35:26 -0400 (EDT) Received: from talk.nabble.com (www.nabble.com [72.21.53.35]) by menubar.gnome.org (Postfix) with ESMTP id 602DC3B05AC for ; Thu, 8 Jun 2006 21:35:26 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=talk.nabble.com) by talk.nabble.com with esmtp (Exim 4.50) id 1FoVuE-0000rb-3p for gtk-devel-list@gnome.org; Thu, 08 Jun 2006 18:35:24 -0700 Message-ID: <4785900.post@talk.nabble.com> Date: Thu, 8 Jun 2006 18:35:22 -0700 (PDT) From: darknecro To: gtk-devel-list@gnome.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-Sender: darknecromancer@dodgeit.com X-Nabble-From: darknecro X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-0.316 tagged_above=-999 required=2 tests=[AWL=2.285, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -0.316 X-Spam-Level: Subject: GTK Masks X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2006 01:35:27 -0000 I am attempting to create a single mask that would cover several items with in the GUI. There will by 16 circles created with gdk_pixmap_create_from_xpm_d, and I can currently do this, but only one item would be 'created' in the mask, so when i apply the mask to the window, only one of the items will be visible. I have done a lot of searching, and I have only been able to come up with that you can xor 2 masks together somehow and create one that contains both. Any help that anyone could shed on this would be greatly appreciated. -- View this message in context: http://www.nabble.com/GTK-Masks-t1759366.html#a4785900 Sent from the Gtk+ - Dev - General forum at Nabble.com. From mitch@gimp.org Fri Jun 9 06:31:35 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id D2D0C3B0216 for ; Fri, 9 Jun 2006 06:31:34 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14877-07 for ; Fri, 9 Jun 2006 06:31:33 -0400 (EDT) Received: from mitch.gimp.org (p549C9439.dip0.t-ipconnect.de [84.156.148.57]) by menubar.gnome.org (Postfix) with ESMTP id EB4033B01DA for ; Fri, 9 Jun 2006 06:31:30 -0400 (EDT) Received: from mitch by mitch.gimp.org with local (Exim 3.36 #1 (Debian)) id 1FoeIj-0003cx-00; Fri, 09 Jun 2006 12:33:13 +0200 From: Michael Natterer To: Federico Mena Quintero In-Reply-To: <1149608483.14088.54.camel@cacharro.xalalinux.org> References: <1149608483.14088.54.camel@cacharro.xalalinux.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Fri, 09 Jun 2006 12:33:12 +0200 Message-Id: <1149849193.3010.23.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=1.06 tagged_above=-999 required=2 tests=[AWL=-0.545, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, RCVD_IN_NJABL_DUL=1.946, RCVD_IN_SORBS_DUL=2.046, TW_GT=0.077] X-Spam-Score: 1.06 X-Spam-Level: * Cc: GTK+ development mailing list , Michael.meeks@novell.com Subject: Re: Default timeouts X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2006 10:31:35 -0000 On Tue, 2006-06-06 at 10:41 -0500, Federico Mena Quintero wrote: > In gtksettings.c we have > > #define DEFAULT_TIMEOUT_INITIAL 200 > #define DEFAULT_TIMEOUT_REPEAT 20 > > for the "gtk-timeout-initial" and "gtk-timeout-repeat" settings, > respectively. This means we wait for a fifth of a second before we > start repeating, but then we try to repeat 50 times per second. > > Isn't the repeat timeout way too short? This is why clicking on a > calendar arrow takes you back tens of months in no time, and also makes > it hard to use spin buttons. Yes, that's way too short. When doing the settings patch, I unified timeouts without actually changing them (the 20 ms was there before). However in some places I introduced a factor of 5 so all existing timeouts could be done with the two values from GtkSettings. See comment #10 of http://bugzilla.gnome.org/show_bug.cgi?id=142582 Actually, it may make sense to simply use the user's configured key repeat and delay for these two setting values. What do you think? ciao, --mitch > Also, Michael Meeks has the following words of wisdom in a Novell bug > about the calendar in gnome-panel's clock: > > > In essence the timeout is way too short for switching days; also - > > in the panel applet the timeout has a higher priority than the > > queued resize of the display (and hence the redraw) - so in > > essence we skip days even faster since we never have to render > > them. > > > > Lowering the priority there, and lengthening the timeouts gives > > a far more reasonable, usable experience without getting rid > > of the whole auto-repeat principle [...] > > I.e. instead of using g_timeout_add() in gtkcalendar, we would use > g_timeout_add_full (G_PRIORITY_DEFAULT_IDLE, ...), or perhaps > (GDK_PRIORITY_REDRAW + positive_constant): both are lower priority than > GTK_PRIORITY_RESIZE. > > Federico > > _______________________________________________ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-devel-list From ross@burtonini.com Fri Jun 9 07:15:10 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 1192B3B0099 for ; Fri, 9 Jun 2006 07:15:10 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18418-03 for ; Fri, 9 Jun 2006 07:15:08 -0400 (EDT) Received: from smtp.nildram.co.uk (smtp.nildram.co.uk [195.112.4.54]) by menubar.gnome.org (Postfix) with ESMTP id 279213B0081 for ; Fri, 9 Jun 2006 07:15:07 -0400 (EDT) Received: from burtonini.com (althur.gotadsl.co.uk [84.12.135.175]) by smtp.nildram.co.uk (Postfix) with ESMTP id 1DDA833C3F2; Fri, 9 Jun 2006 12:11:26 +0100 (BST) Received: from 127.0.0.1 (ident=unknown) by burtonini.com with esmtp (masqmail 0.2.21) id 1Foetj-17d-00; Fri, 09 Jun 2006 12:11:27 +0100 From: Ross Burton To: Michael Natterer In-Reply-To: <1149849193.3010.23.camel@localhost> References: <1149608483.14088.54.camel@cacharro.xalalinux.org> <1149849193.3010.23.camel@localhost> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-DKvhrUfzvCjsapgkUotZ" Date: Fri, 09 Jun 2006 12:11:27 +0100 Message-Id: <1149851487.2333.2.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.456 tagged_above=-999 required=2 tests=[AWL=0.008, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.456 X-Spam-Level: Cc: Federico Mena Quintero , GTK+ development mailing list , Michael.meeks@novell.com Subject: Re: Default timeouts X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2006 11:15:10 -0000 --=-DKvhrUfzvCjsapgkUotZ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2006-06-09 at 12:33 +0200, Michael Natterer wrote: > Actually, it may make sense to simply use the user's configured > key repeat and delay for these two setting values. What do you > think? That's probably a very good idea, on the grounds that people set the keyboard delay/repeat to values they can handle (i.e. my Dad has slowed them down as he isn't as fast as he used to be). What are the system defaults for the keyboard delay/repeat? Ross --=20 Ross Burton mail: ross@burtonini.com jabber: ross@burtonini.com www: http://www.burtonini.com./ PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF --=-DKvhrUfzvCjsapgkUotZ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQBEiVdeLQnkR9C0M98RAp+DAJ9s9H2qD2A4AQ6kXwgB+B6ka0ve8QCfZcQL IPi9sLP/fY2zOVLCX+eSrvo= =LNZu -----END PGP SIGNATURE----- --=-DKvhrUfzvCjsapgkUotZ-- From timj@gtk.org Fri Jun 9 13:30:55 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 1CAD23B00E9 for ; Fri, 9 Jun 2006 13:30:55 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10186-10 for ; Fri, 9 Jun 2006 13:30:52 -0400 (EDT) Received: from webmail.hansenet.de (mail03.hansenet.de [213.191.73.10]) by menubar.gnome.org (Postfix) with ESMTP id E3A183B011B for ; Fri, 9 Jun 2006 13:30:51 -0400 (EDT) Received: from birnet.org (80.171.4.161) by webmail.hansenet.de (7.2.059) id 4487A06D0006D98F; Fri, 9 Jun 2006 19:30:40 +0200 Received: from master.birnet.private (localhost [127.0.0.1]) by birnet.org (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k59HUdVg010604 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 9 Jun 2006 19:30:39 +0200 Received: (from timj@localhost) by master.birnet.private (8.13.4/8.13.4/Submit) id k59HUPEO010599; Fri, 9 Jun 2006 19:30:25 +0200 Date: Fri, 9 Jun 2006 19:30:25 +0200 (CEST) From: Tim Janik X-X-Sender: timj@master.birnet.private To: "Kaveh R. Ghazi" In-Reply-To: <200606091630.k59GUaES013244@caipclassic.rutgers.edu> Message-ID: References: <20060609152646.GE20719@space.twc.de> <200606091630.k59GUaES013244@caipclassic.rutgers.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.469 tagged_above=-999 required=2 tests=[AWL=0.130, BAYES_00=-2.599] X-Spam-Score: -2.469 X-Spam-Level: Cc: gcc@gcc.gnu.org, Gtk+ Developers Subject: Re: Problem with type safety and the "sentinel" attribute X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2006 17:30:55 -0000 thanks for the quick response Kaveh. On Fri, 9 Jun 2006, Kaveh R. Ghazi wrote: > > > void print_string_array (const char *array_name, > > const char *string, ...) __attribute__ > > ((__sentinel__)); > > > > print_string_array ("empty_array", NULL); /* gcc warns, but shouldn't */ > > > > The only way out for keeping the sentinel attribute and avoiding the > > warning is using > > > > static void print_string_array (const char *array_name, ...) > > __attribute__ ((__sentinel__)); > > I think you could maintain typesafety and silence the warning by > keeping the more specific prototype and adding an extra NULL, e.g.: > > print_string_array ("empty_array", NULL, NULL); > > Doesn't seem elegant, but it does the job. this is an option for a limited set of callers, yes. > > By the way, there is already an existing gcc bug, which is about the > > same thing (NULL passed within named args), but wants to have it the > > way it works now: > > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21911 > > Correct, the feature as I envisioned it expected the sentinel to > appear in the variable arguments only. This PR reflects when I found > out it didn't do that and got around to fixing it. Note the "buggy" > behavior wasn't exactly what you wanted either because GCC got fooled > by a sentinel in *any* of the named arguments, not just the last one. > > > > so if it gets changed, then gcc might need to support both > > - NULL termination within the last named parameter allowed > > - NULL termination only allowed within varargs parameters (like it is > > now) > > I'm not against this enhancement, but you need to specify a syntax > that allows the old behavior but also allows doing it your way. > > Hmm, perhaps we could check for attribute "nonnull" on the last named > argument, if it exists then that can't be the sentinel, if it's not > there then it does what you want. This is not completely backwards > compatible because anyone wanting the existing behavior has to add the > attribute nonnull. But there's precedent for this when attribute > printf split out whether the format specifier could be null... > > We could also create a new attribute name for the new behavior. This > would preserve backwards compatibility. I like this idea better. i agree here. as far as the majority of the GLib and Gtk+ APIs are concerned, we don't really need the flexibility of the sentinel attribute but rather a compiler check on whether the last argument used in a function call is NULL or 0 (regardless of whether it's the last named arg or already part of the varargs list). that's also why the actual sentinel wrapper in GLib looks like this: #define G_GNUC_NULL_TERMINATED __attribute__((__sentinel__)) so, if i was to make a call on this issue, i'd either introduce __attribute__((__null_terminated__)) with the described semantics, or have __attribute__((__sentinel__(-1))) work essentially like __attribute__((__sentinel__(0))) while also accepting 0 in the position of the last named argument. > Next you need to recruit someone to implement this enhancement, or > submit a patch. :-) Although given that you can silence the warning by > adding an extra NULL at the call site, I'm not sure it's worth it. i would say this is definitely worth it, because the issue also shows up in other code that is widely used: gpointer g_object_new (GType object_type, const gchar *first_property_name, ...); that's for instance a function which is called in many projects. putting the burden on the caller is clearly the wrong trade off here. so please take this as a vote for the worthiness of a fix ;) > --Kaveh > -- > Kaveh R. Ghazi ghazi@caip.rutgers.edu --- ciaoTJ From nshmyrev@yandex.ru Sat Jun 10 02:06:32 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 347973B00D0 for ; Sat, 10 Jun 2006 02:06:32 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12492-03 for ; Sat, 10 Jun 2006 02:06:28 -0400 (EDT) Received: from chen.mtu.ru (chen.mtu.ru [195.34.34.232]) by menubar.gnome.org (Postfix) with ESMTP id 78AC43B0126 for ; Sat, 10 Jun 2006 02:06:28 -0400 (EDT) Received: from gnome.local (ppp83-237-50-138.pppoe.mtu-net.ru [83.237.50.138]) by smtp.MTU.RU (Postfix) with ESMTP id D51B453DA7E; Sat, 10 Jun 2006 10:06:25 +0400 (MSD) (envelope-from nshmyrev@yandex.ru) From: "Nickolay V. Shmyrev" To: gtk-devel-list@gnome.org, gnome-i18n@gnome.org Content-Type: text/plain Date: Sat, 10 Jun 2006 10:06:30 +0400 Message-Id: <1149919590.2305.18.camel@gnome.local> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 (2.6.2-1.fc5.3) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.758 tagged_above=-999 required=2 tests=[AWL=-0.440, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, SPF_NEUTRAL=1.069, TW_GT=0.077] X-Spam-Score: -1.758 X-Spam-Level: Cc: Subject: Translation of gtk tuturial X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2006 06:06:32 -0000 Hello all. I now there was done quite amazing work about translation of gtk tutorial and I know there were some other translations http://linfoline.homedns.org/gtk/book1.html http://kldp.org/KoreanDoc/html/GtkTutorial/GtkTutorial.html What about making gtk tutorial translatable with docutils like all user documentation and merging those translations upstream? I don't ask about reference manual translation but it's also interesting, although not realistic. Probably it's not sensible to distribute tutorial with gtk package itself but use something like a web-based Rosetta. From matthias.clasen@gmail.com Sat Jun 10 10:02:35 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id A74883B0280 for ; Sat, 10 Jun 2006 10:02:35 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06778-09 for ; Sat, 10 Jun 2006 10:02:33 -0400 (EDT) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.200]) by menubar.gnome.org (Postfix) with ESMTP id 1C56D3B01C3 for ; Sat, 10 Jun 2006 10:02:33 -0400 (EDT) Received: by nz-out-0102.google.com with SMTP id z3so947001nzf for ; Sat, 10 Jun 2006 07:02:32 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=jUGG9w5BYrTkFmK4uobvwaXzJ1w3H4k8DuZIFGIHoBjFn1kgtf//lWo+engDAz0ImbOYOsKrWjvA9YAXvpwCcamcXXpE51E09vtpA8lmZKxAt+RA6AWeMX4blO5srWeestsf+E6dRd0OwZUmD3OCksEXAdLAjQcGBJBiKLVKPnQ= Received: by 10.37.15.76 with SMTP id s76mr5772218nzi; Sat, 10 Jun 2006 07:02:32 -0700 (PDT) Received: by 10.37.21.6 with HTTP; Sat, 10 Jun 2006 07:02:32 -0700 (PDT) Message-ID: Date: Sat, 10 Jun 2006 10:02:32 -0400 From: "Matthias Clasen" To: "Nickolay V. Shmyrev" In-Reply-To: <1149919590.2305.18.camel@gnome.local> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1149919590.2305.18.camel@gnome.local> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.471 tagged_above=-999 required=2 tests=[AWL=0.052, BAYES_00=-2.599, SPF_PASS=-0.001, TW_GT=0.077] X-Spam-Score: -2.471 X-Spam-Level: Cc: gnome-i18n@gnome.org, gtk-devel-list@gnome.org Subject: Re: Translation of gtk tuturial X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2006 14:02:35 -0000 On 6/10/06, Nickolay V. Shmyrev wrote: > Hello all. > > I now there was done quite amazing work about translation of gtk > tutorial and I know there were some other translations > > http://linfoline.homedns.org/gtk/book1.html > > http://kldp.org/KoreanDoc/html/GtkTutorial/GtkTutorial.html > > What about making gtk tutorial translatable with docutils like all > user documentation and merging those translations upstream? > > I don't ask about reference manual translation but it's also interesting, > although not realistic. Probably it's not sensible to distribute tutorial > with gtk package itself but use something like a web-based Rosetta. > The first step towards making the tutorial more useful would be updating its 2.0 era content, remove deprecated apis, and cover at least some of the important new apis. From lists@nabble.com Sat Jun 10 13:20:05 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id BB53E3B01B8 for ; Sat, 10 Jun 2006 13:20:05 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16672-08 for ; Sat, 10 Jun 2006 13:20:04 -0400 (EDT) Received: from talk.nabble.com (www.nabble.com [72.21.53.35]) by menubar.gnome.org (Postfix) with ESMTP id 2730A3B01D7 for ; Sat, 10 Jun 2006 13:20:04 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=talk.nabble.com) by talk.nabble.com with esmtp (Exim 4.50) id 1Fp77z-0000O0-FG for gtk-devel-list@gnome.org; Sat, 10 Jun 2006 10:20:03 -0700 Message-ID: <4809607.post@talk.nabble.com> Date: Sat, 10 Jun 2006 10:20:03 -0700 (PDT) From: mikecorn To: gtk-devel-list@gnome.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-Sender: mikecorn@t-online.de X-Nabble-From: mikecorn X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.565 tagged_above=-999 required=2 tests=[AWL=0.036, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.565 X-Spam-Level: Subject: GTK window edge detection sensitivity X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2006 17:20:05 -0000 To: GTK developers The resizable windows in Gnome are slick, but I often have a minor problem: After the mouse cursor changes form, indicating that the window edge is in-range for dragging, I often find myself dragging across the window behind, because the edge range was lost shortly after it was found. I ask you to consider possible improvements to make this work more reliably and with less precision required (which also means faster for the user). 1. increase the edge-detection threshold by 2x or more, or make it user-adjustable. 2. once the edge is detected, increase the threshold for losing it (time or distance). regards Mike C. -- View this message in context: http://www.nabble.com/GTK-window-edge-detection-sensitivity-t1767067.html#a4809607 Sent from the Gtk+ - Dev - General forum at Nabble.com. From marcel@telka.sk Sat Jun 10 23:05:18 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 2D8C03B05D2 for ; Sat, 10 Jun 2006 23:05:18 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06780-08 for ; Sat, 10 Jun 2006 23:05:16 -0400 (EDT) Received: from tortuga.telka.sk (unknown [193.86.173.20]) by menubar.gnome.org (Postfix) with SMTP id 7D8283B0543 for ; Sat, 10 Jun 2006 23:05:15 -0400 (EDT) Received: (qmail 14272 invoked by uid 0); 11 Jun 2006 02:57:43 -0000 Date: 11 Jun 2006 02:57:43 -0000 Message-ID: <20060611025743.14269.qmail@tortuga.telka.sk> To: From: Marcel Telka X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.443 tagged_above=-999 required=2 tests=[AWL=0.156, BAYES_00=-2.599] X-Spam-Score: -2.443 X-Spam-Level: Subject: gtk+: Missing translatable files X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jun 2006 03:05:18 -0000 Hi. I have tested module gtk+ (CVS branch HEAD) which lives in GNOME CVS for missing translatable files with `intltool-update -m` command. Here is a content of the 'missing' file: gtk/gtkfilechoosersettings.c gtk/gtkprintoperationpreview.c Please put these files into POTFILES.in or POTFILES.skip files. Thanks. Note: This report is generated automatically and you are not required to reply to this mail. If you are not maintainer of the 'gtk+' module or this CVS branch is obsolete or you don't want similar report in future, tell me and I will stop this report generation. Regards. -- +-------------------------------------------+ | Marcel Telka e-mail: marcel@telka.sk | | homepage: http://telka.sk/ | | jabber: marcel@jabber.sk | +-------------------------------------------+ From easy-b@freesurf.ch Sun Jun 11 16:22:48 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id ABE753B0159 for ; Sun, 11 Jun 2006 16:22:48 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32516-10 for ; Sun, 11 Jun 2006 16:22:46 -0400 (EDT) Received: from mail-fs.sunrise.ch (mta-fs-be-04.sunrise.ch [194.158.229.33]) by menubar.gnome.org (Postfix) with ESMTP id A306E3B00CA for ; Sun, 11 Jun 2006 16:22:45 -0400 (EDT) Received: from [10.0.1.2] (84.227.173.50) by mail-fs.sunrise.ch (7.2.073) id 44858C490024803A; Sun, 11 Jun 2006 22:21:55 +0200 In-Reply-To: References: <20060522160033.F1A8E3B1CE4@menubar.gnome.org> <772588ED-500A-4A11-8829-DA80B9A35D1F@freesurf.ch> <44720B8C.3080903@imendio.com> <0A34FCC9-6650-4737-B86D-1B503D8A9072@freesurf.ch> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7D6367DC-8689-453B-8FD7-217632BC1DAE@freesurf.ch> Content-Transfer-Encoding: 7bit From: Easy B Date: Sun, 11 Jun 2006 22:21:54 +0200 To: Gregor Riepl X-Mailer: Apple Mail (2.749.3) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.312 tagged_above=-999 required=2 tests=[AWL=-0.787, BAYES_00=-2.599, DNS_FROM_RFC_POST=1.708, FORGED_RCVD_HELO=0.135, TW_BG=0.077, TW_GD=0.077, TW_GT=0.077] X-Spam-Score: -1.312 X-Spam-Level: Cc: gtk-devel-list@gnome.org Subject: Mac OS X Framework X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jun 2006 20:22:48 -0000 Hoi Gregor Thanx for the Tips. This would make the Framework more like one. The ability to include it into the application bundle would be very handy. If I look at other Frameworks I always find a single library in the top directory, for example: /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ Frameworks/ImageIO.framework/ImageIO If I do "otool -L /System/Library/Frameworks/ ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/ ImageIO", I get references to many other libraries that are located inside the framework bundle: /System/Library/Frameworks/ApplicationServices.framework/ Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/ libJPEG.dylib (compatibility version 1.0.0, current version 1.0.0) /System/Library/Frameworks/ApplicationServices.framework/ Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/ libJP2.dylib (compatibility version 1.0.0, current version 1.0.0) /System/Library/Frameworks/ApplicationServices.framework/ Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/ libGIF.dylib (compatibility version 1.0.0, current version 1.0.0) /System/Library/Frameworks/ApplicationServices.framework/ Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/ libRaw.dylib (compatibility version 1.0.0, current version 1.0.0) /System/Library/Frameworks/ApplicationServices.framework/ Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/ libTIFF.dylib (compatibility version 1.0.0, current version 1.0.0) /System/Library/Frameworks/ApplicationServices.framework/ Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/ libPng.dylib (compatibility version 1.0.0, current version 1.0.0) /System/Library/Frameworks/ApplicationServices.framework/ Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/ libRadiance.dylib (compatibility version 1.0.0, current version 1.0.0) In my Gtk+.framework I have tons of libraries. Would it be possible to create something like the above for gtk? Would it make sense? Right now I just use pkg-config to find the libraries and the result looks like this: /Applications/Shity Apps/Gtk-Demo.app/Contents/MacOS/gtk-demo: /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libgdk_pixbuf-2.0.0.dylib (compatibility version 902.0.0, current version 902.0.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libgdk-quartz-2.0.0.dylib (compatibility version 902.0.0, current version 902.0.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libgtk-quartz-2.0.0.dylib (compatibility version 902.0.0, current version 902.0.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libpangocairo-1.0.0.dylib (compatibility version 1301.0.0, current version 1301.1.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libpangoft2-1.0.0.dylib (compatibility version 1301.0.0, current version 1301.1.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libpango-1.0.0.dylib (compatibility version 1301.0.0, current version 1301.1.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libatk-1.0.0.dylib (compatibility version 1115.0.0, current version 1115.0.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libgobject-2.0.0.dylib (compatibility version 1102.0.0, current version 1102.0.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libgmodule-2.0.0.dylib (compatibility version 1102.0.0, current version 1102.0.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libglib-2.0.0.dylib (compatibility version 1102.0.0, current version 1102.0.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libcairo.2.dylib (compatibility version 9.0.0, current version 9.0.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libpng12.0.dylib (compatibility version 11.0.0, current version 11.0.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libfontconfig.1.dylib (compatibility version 2.0.0, current version 2.4.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libfreetype.6.dylib (compatibility version 10.0.0, current version 10.8.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libxml2.2.dylib (compatibility version 9.0.0, current version 9.24.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libintl.3.dylib (compatibility version 8.0.0, current version 8.3.0) What do you think? Cheers, Ezra. On 11.06.2006, at 10:22, Gregor Riepl wrote: > Hi Ezra > >> Well it's looking better now. I even ended up with ready to use >> Installers. I still got my pkg-config/headers problem though so >> the script still has some ugly hard links in it., besides all the >> other debugging ugliness. I'm also not sure if the framework is >> usable the way it's now. I will first have to try to compile some >> apps against it. I'll definitely come with more problems soon. > > To make a framework fully usable, it's dynamic library paths need > to be adapted with install_name_tool. > For example, its the self-reference should be > @executable_path/../Frameworks/.framework/ > Versions/A/ > This makes the library includable in application bundles, instead > of having to install it. > But you may of course also use /Library/Frameworks/ framework>.framework/Versions/A/ > Have a look at the output of otool -L for some system and user- > installed libraries, i.e. > > $ otool -L /System/Library/Frameworks/Cocoa.framework/Cocoa > /System/Library/Frameworks/Cocoa.framework/Cocoa: > /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa > (compatibility version 1.0.0, current version 11.0.0) > /System/Library/Frameworks/AppKit.framework/Versions/C/ > AppKit (compatibility version 45.0.0, current version 822.0.0) > /System/Library/Frameworks/CoreData.framework/Versions/A/ > CoreData (compatibility version 1.0.0, current version 46.0.0) > /System/Library/Frameworks/Foundation.framework/Versions/C/ > Foundation (compatibility version 300.0.0, current version 566.0.0) > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, > current version 88.0.0) > > or > > $ otool -L /Library/Frameworks/SDL_image.framework/SDL_image > /Library/Frameworks/SDL_image.framework/SDL_image: > @executable_path/../Frameworks/SDL_image.framework/Versions/ > A/SDL_image (compatibility version 1.0.0, current version 1.0.0) > @executable_path/../Frameworks/SDL.framework/Versions/A/SDL > (compatibility version 1.0.0, current version 1.0.0) > /usr/lib/libz.1.dylib (compatibility version 1.0.0, current > version 1.0.0) > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, > current version 71.1.1) > > If a library has a lot of dependencies, you may run into a problem > here: The Mach-O header's area for library references isn't of > variable size, and install_name_tool may refuse to change all > paths. There's afaik no other way then to relink the binary with > the option -headerpad_max_install_names (see man ld). > From mclasen@redhat.com Mon Jun 12 12:04:32 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 41C3B3B000C; Mon, 12 Jun 2006 12:04:32 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09149-04; Mon, 12 Jun 2006 12:04:29 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id 7270D3B009D; Mon, 12 Jun 2006 12:04:29 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5CG3bc9030255; Mon, 12 Jun 2006 12:03:37 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5CG3bc3007778; Mon, 12 Jun 2006 12:03:37 -0400 Received: from golem.boston.redhat.com (golem.boston.redhat.com [172.16.80.24]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id k5CG3blQ018463; Mon, 12 Jun 2006 12:03:37 -0400 From: Matthias Clasen To: gnome-announce-list@gnome.org, gtk-devel-list@gnome.org, gtk-app-devel-list@gnome.org, gtk-list@gnome.org Content-Type: text/plain Date: Mon, 12 Jun 2006 12:03:36 -0400 Message-Id: <1150128216.15532.14.camel@golem.boston.redhat.com> Mime-Version: 1.0 X-Mailer: Evolution 2.7.1 (2.7.1-1) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.426 tagged_above=-999 required=2 tests=[AWL=-0.056, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, TW_LQ=0.077, TW_RX=0.077, TW_TR=0.077] X-Spam-Score: -2.426 X-Spam-Level: Cc: Subject: GLib 2.11.3 released X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gome-hackers@gnome.org List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2006 16:04:32 -0000 GLib 2.11.3 is now available for download at: ftp://ftp.gtk.org/pub/gtk/v2.11/ http://ftp.gnome.org/pub/GNOME/sources/glib/2.11/ glib-2.11.3.tar.bz2 md5sum: 41931c4965f7e1848f81b800914905cd glib-2.11.3.tar.gz md5sum: cd78ebc535e29cdef0fed9487aa21dac This is a development release leading up to GLib 2.12. Notes: * This is unstable development release. While it has had a bit of testing, there are certainly plenty of bugs remaining to be found. This release should not be used in production. * Installing this version will overwrite your existing copy of GLib 2.10. If you have problems, you'll need to reinstall GLib 2.10. * GLib 2.12 will be source and binary compatible with the GLib 2.10.x series (for some caveats, see the README). At this point, the API additions in the 2.11.x series are almost finished. * Bugs should be reported to http://bugzilla.gnome.org. About GLib ========== GLib is the low-level core library that forms the basis for projects such as GTK+ and GNOME. It provides data structure handling for C, portability wrappers, and interfaces for such runtime functionality as an event loop, threads, dynamic loading, and an object system. More information about GLib is available at: http://www.gtk.org/ An installation guide for the GTK+ libraries, including GLib, can be found at: http://developer.gnome.org/doc/API/2.0/gtk/gtk-building.html Overview of Changes from GLib 2.11.2 to GLib 2.11.3 =================================================== * GBookmarkFile: - g_bookmark_file_move_item: Return TRUE in case of an empty target * Bugs fixed: 343919 gunicollate.c: strxfrm bug on VC8 * Updated translations (fi) A list of all bugs fixed in this release can be found at: http://bugzilla.gnome.org/buglist.cgi?bug_id=343919 Thanks to everybody who has contributed to this release, in the form of bug reports or patches: Emmanuele Bassi, Kazuki Iwamoto, Tor Lillqvist Matthias Clasen June 12, 2006 From mclasen@redhat.com Mon Jun 12 15:43:04 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 851123B00E5; Mon, 12 Jun 2006 15:43:04 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27729-06; Mon, 12 Jun 2006 15:43:02 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id 5B16F3B0010; Mon, 12 Jun 2006 15:43:02 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5CJZWav007572; Mon, 12 Jun 2006 15:35:32 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5CJZWUd001833; Mon, 12 Jun 2006 15:35:32 -0400 Received: from golem.boston.redhat.com (golem.boston.redhat.com [172.16.80.24]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id k5CJZWlQ009694; Mon, 12 Jun 2006 15:35:32 -0400 From: Matthias Clasen To: gnome-announce-list@gnome.org, gtk-devel-list@gnome.org, gtk-app-devel-list@gnome.org, gtk-list@gnome.org Content-Type: text/plain Date: Mon, 12 Jun 2006 15:35:31 -0400 Message-Id: <1150140931.15532.18.camel@golem.boston.redhat.com> Mime-Version: 1.0 X-Mailer: Evolution 2.7.1 (2.7.1-1) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.541 tagged_above=-999 required=2 tests=[AWL=0.060, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.541 X-Spam-Level: Cc: Subject: GTK+ 2.8.19 released X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gnome-hackers@gnome.org List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2006 19:43:04 -0000 GTK+ 2.8.19 is now available for download at: ftp://ftp.gtk.org/pub/gtk/v2.8/ http://ftp.gnome.org/pub/GNOME/sources/gtk+/2.8/ gtk+-2.8.19.tar.bz2 md5sum: 1a03dbed4b794194a610e9d7eb175b06 gtk+-2.8.19.tar.gz md5sum: 604d3263498994c58af378f0ec076e6f This is a bugfix release in the 2.8.x series. It fixes a rare memory corruption issue when using the deprecated GdkFont API. What is GTK+ ============ GTK+ is a multi-platform toolkit for creating graphical user interfaces. Offering a complete set of widgets, GTK+ is suitable for projects ranging from small one-off tools to complete application suites. GTK+ has been designed from the ground up to support a range of languages, not only C/C++. Using GTK+ from languages such as Perl and Python (especially in combination with the Glade GUI builder) provides an effective method of rapid application development. GTK+ is free software and part of the GNU Project. However, the licensing terms for GTK+, the GNU LGPL, allow it to be used by all developers, including those developing proprietary software, without any license fees or royalties. Where to get more information about GTK+ ======================================== Information about GTK+ including links to documentation can be found at: http://www.gtk.org/ An installation guide for GTK+ 2.8 is found at: http://developer.gnome.org/doc/API/2.0/gtk/gtk-building.html Common questions: http://developer.gnome.org/doc/API/2.0/gtk/gtk-question-index.html http://www.gtk.org/faq/ Overview of Changes from GTK+ 2.8.18 to GTK+ 2.8.19 =================================================== Bugs fixed: 341327 Memory corruption inside glib 337491 _gdk_win32_drawable_release_dc: DeleteDC() called on a GetDC() handle 343425 "grab-notify"-signal is not correctly propagated for internal children 344244 Window resizing not working when keeping the aspect fixed 344496 CRLF converting via Clipboard Updated translations (ne) A list of all bugs fixed in this release can be found at: http://bugzilla.gnome.org/buglist.cgi?bug_id=343425,341327,344244,337491,344496 Thanks to everybody who has contributed to this release, in the form of bug reports or patches: Markku Vire, Sampo Savolainen, Tim Janik, Tor Lillqvist, Chris Wilson June 12, 2006 Matthias Clasen From mclasen@redhat.com Tue Jun 13 02:09:16 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 72FE93B00AF; Tue, 13 Jun 2006 02:09:16 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12183-04; Tue, 13 Jun 2006 02:09:13 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id B2F773B000C; Tue, 13 Jun 2006 02:09:13 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5D681s3022181; Tue, 13 Jun 2006 02:08:01 -0400 Received: from lacrosse.corp.redhat.com (lacrosse.corp.redhat.com [172.16.52.154]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5D67uRP017686; Tue, 13 Jun 2006 02:07:56 -0400 Received: from [172.16.83.145] (vpn83-145.boston.redhat.com [172.16.83.145]) by lacrosse.corp.redhat.com (8.12.11.20060308/8.11.6) with ESMTP id k5D67tQC015619; Tue, 13 Jun 2006 02:07:56 -0400 From: Matthias Clasen To: gnome-announce-list@gnome.org, gtk-devel-list@gnome.org, gtk-app-devel-list@gnome.org, gtk-list@gnome.org Content-Type: text/plain; charset=UTF-8 Organization: Red Hat Date: Tue, 13 Jun 2006 02:09:42 -0400 Message-Id: <1150178982.4081.13.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.7.2.1 (2.7.2.1-4) Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.426 tagged_above=-999 required=2 tests=[AWL=-0.056, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, TW_GD=0.077, TW_GT=0.077, TW_KB=0.077] X-Spam-Score: -2.426 X-Spam-Level: Cc: Subject: GTK+ 2.9.3 released X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gnome-hackers@gnome.org List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2006 06:09:16 -0000 GTK+ 2.9.3 is now available for download at: ftp://ftp.gtk.org/pub/gtk/v2.9/ http://ftp.gnome.org/pub/gnome/sources/gtk+/2.9/ gtk+-2.9.3.tar.bz2 md5sum: d73039a3b5847c352f5740ac908be7d2 gtk+-2.9.3.tar.gz md5sum: 0156eef91d2bbb23f1b6ccb49335fae5 This is a development release leading up to GTK+ 2.10. Notes: * This is unstable development release. There are certainly plenty of bugs remaining to be found. This release should not be used in production. * Installing this version will overwrite your existing copy of GTK+ 2.8. If you have problems, you'll need to reinstall GTK+ 2.8. * GTK+ 2.10 will be source compatible with the GTK+ 2.8 series; the new API additions in GTK+ 2.9.0 are not yet completely finalized, so there are likely incompatibilies between this release and the final 2.10 release. * The ABI version has been bumped from 2.4.0 to 2.10.0, since the filechooser backend interface has been changed. Third-party filechooser backends need to be ported to the new interface. Other third-party modules (input methods, image loaders, etc) just need to be reinstalled in the proper location for GTK+ to find them. * Remaining issues for GTK+ 2.10 can be found with following bugzilla query: http://bugzilla.gnome.org/buglist.cgi?product=gtk%2b&target_milestone=2.10+API+Freeze&target_milestone=2.10+Freeze&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED * Bugs should be reported to http://bugzilla.gnome.org. What is GTK+ ============ GTK+ is a multi-platform toolkit for creating graphical user interfaces. Offering a complete set of widgets, GTK+ is suitable for projects ranging from small one-off tools to complete application suites. GTK+ has been designed from the ground up to support a range of languages, not only C/C++. Using GTK+ from languages such as Perl and Python (especially in combination with the Glade GUI builder) provides an effective method of rapid application development. GTK+ is free software and part of the GNU Project. However, the licensing terms for GTK+, the GNU LGPL, allow it to be used by all developers, including those developing proprietary software, without any license fees or royalties. Where to get more information about GTK+ ======================================== Information about GTK+ including links to documentation can be found at: http://www.gtk.org/ An installation guide for GTK+ 2.x is found at: http://developer.gnome.org/doc/API/2.4/gtk/gtk-building.html Common questions: http://developer.gnome.org/doc/API/2.4/gtk/gtk-question-index.html http://www.gtk.org/faq/ Overview of Changes from GTK+ 2.9.2 to 2.9.3 ============================================ * GtkPrintOperation: - Introduce an allow-async property - Introduce a GtkPrintOperationAction enumeration - Rename pdf_target to export_filename - Allow to hide "Print to PDF" in the low-level API * GtkNotebook: - Add a destroy notify to gtk_notebook_set_window_creation_hook. * GtkTreeView: - Support grid lines * GtkRange: - Add a number of new stle properties which allow more fexible stepper theming * Bugs fixed: 153212 Have the Paste kbd shortcut jump to the location in the buffer 337491 _gdk_win32_drawable_release_dc: DeleteDC() called on a GetDC() handle 339739 gtk/gtkprintoperation-win32.c: 3 compile error 342339 GtkRange::stepper-spacing style property not implemented correctly 343945 Buttons of a GtkAssistant are not accessible 344148 Wrong reqs for ATK 344209 gtk_notebook_set_window_creation_hook() has no destroy func. 344232 GtkEntry's "Delete" context menu item is sensitive on a non-editable GtkEntry 344244 Window resizing not working when keeping the aspect fixed 344288 gtk_print_operation_preview_is_selected must return a value 344386 gdk-2.0-uninstalled.pc.in and gdkconfig.h 344496 CRLF converting via Clipboard 344504 GtkPrintCapabilities not in gtktypebuiltins.h 344505 Wrong signal registration for create_custom_widget 344512 cvs build issue 344513 pdf print module's print_stream not calling destroy notify 344518 NULL unref in page setup dialogue 344543 gtk_progress_bar_pulse calls gtk_progress_bar_paint directly 344560 gtk_print_settings_[sg]et_scale shouldn't be in percent 344607 memory leaks in gtkrecentchooserdefault.c and gtkrecentchoosermenu.c 344624 Memory leak in gtk_tree_model_filter_finalize: User data not freed 337603 Possible off-by-one in gdk_pango_layout_line_get_clip_region 344239 Wrong filename for gtk-find stock item. 344528 comma at end of GtkPrintOperationAction enum causes mozilla compilation error 344290 horizontal-padding not take into account when placing submenus 344558 document print dialogue response codes 339592 Add print-to-postscript 342249 Allow to draw upper and lower sides of GtkRange's trough differently 344530 gtk_recent_chooser_widget_new_for_manager and gtk_recent_chooser_menu_new_for_manager should allow NULL manager arg * Updated translations (es,fi,gu,ko,th,wa) A list of all bugs fixed in this release can be found at: http://bugzilla.gnome.org/buglist.cgi?bug_id=153212,337491,339739,342339,343945,344148,344209,344232,344244,344288,344386,344496,344504,344505,344512,344513,344518,344543,344560,344607,344624,337603,344239,344528,344290,344558,339592,342249,344530 Thanks to everybody who has contributed to this release, in the form of bug reports or patches: Behdad Esfahbod, Bastian Nocera, Alexander Larsson, Jrg Billeter, Murray Cumming, Milosz Derezynski, Tor Lillqvist, Kazuki Iwamoto, Chris Wilson, Michael Natterer, Benjamin Berg, Marko Anastasov, Christian Persch, Masatake Yamamoto, Elijah Newren, John Finlay, Emmanuele Bassi, David Malcolm, John Darrington, Christian Weiske, Yvgen Muntyan, Martyn Russell, Kristian Rietveld June 13, 2006 Matthias Clasen From exe522@hotmail.com Tue Jun 13 09:17:01 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 1FF7B3B000A for ; Tue, 13 Jun 2006 09:17:01 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24109-07 for ; Tue, 13 Jun 2006 09:17:00 -0400 (EDT) Received: from hotmail.com (bay104-f2.bay104.hotmail.com [65.54.175.12]) by menubar.gnome.org (Postfix) with ESMTP id 4C4843B00AF for ; Tue, 13 Jun 2006 09:17:00 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 13 Jun 2006 06:16:02 -0700 Message-ID: Received: from 65.54.175.200 by by104fd.bay104.hotmail.msn.com with HTTP; Tue, 13 Jun 2006 13:15:57 GMT X-Originating-IP: [86.212.127.235] X-Originating-Email: [exe522@hotmail.com] X-Sender: exe522@hotmail.com In-Reply-To: <2672cf4d0606050752o12a6d0d2gcb4c355cc0f35d79@mail.gmail.com> From: "Malik NakaMura" To: domlachowicz@gmail.com Date: Tue, 13 Jun 2006 13:15:57 +0000 Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed X-OriginalArrivalTime: 13 Jun 2006 13:16:02.0831 (UTC) FILETIME=[851C21F0:01C68EEB] X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-0.736 tagged_above=-999 required=2 tests=[AWL=-1.532, BAYES_05=-1.11, DNS_FROM_RFC_ABUSE=0.2, DNS_FROM_RFC_POST=1.708, MSGID_FROM_MTA_HEADER=0, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -0.736 X-Spam-Level: Cc: gtk-devel-list@gnome.org Subject: Re: GTK+ >> Cocoa Native Port X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2006 13:17:01 -0000 This is my first version of _gdk_quartz_copy_to_image. The only problem is that I didnt succeed in getting the color map from "drawable"... so the image is displayed without its original colors GdkImage * _gdk_quartz_copy_to_image (GdkDrawable *drawable, GdkImage *image, gint src_x, gint src_y, gint dest_x, gint dest_y, gint width, gint height) { GdkPixbuf *pixbuf; //printf("_gdk_quartz_copy_to_image : To Implement\n"); pixbuf = NULL; image = g_object_new (gdk_image_get_type (), NULL); image->type = GDK_TYPE_IMAGE; image->width = width; image->height = height; image->byte_order = (G_BYTE_ORDER == G_LITTLE_ENDIAN) ? GDK_LSB_FIRST : GDK_MSB_FIRST; image->bpp = 4; image->bpl = image->width * image->bpp; image->bits_per_pixel = image->bpp * 8; image->colormap = (GdkColormap *)g_malloc(sizeof(GdkColormap)); memcpy(image->colormap, GDK_DRAWABLE_IMPL_QUARTZ (&(GDK_PIXMAP_IMPL_QUARTZ (drawable)->parent_instance))->colormap, sizeof(GdkColormap)); if(image->colormap != NULL) { image->visual = (GdkVisual *)g_malloc(sizeof(GdkVisual)); memcpy(image->visual, gdk_colormap_get_visual (image->colormap), sizeof(GdkVisual)); if (image->visual) { void *data; int x, y; guint32 *pix, *pixels; image->depth = image->visual->depth; image->mem = g_malloc (image->bpl * image->height); memset (image->mem, 0x00, image->bpl * image->height); data = GDK_PIXMAP_IMPL_QUARTZ (drawable)->data; pixels = (guint32 *)data; for (y = 0; y < image->height; y++) { pix = pixels+((image->height - 1 - y)*width); for (x = 0; xwidth; x++) { gdk_image_put_pixel (image, x, y, *pix); pix++; } } return image; } } g_free(image); image = NULL; return NULL; } From kloczek@rudy.mif.pg.gda.pl Tue Jun 13 09:41:41 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 2C9B33B008F for ; Tue, 13 Jun 2006 09:41:41 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24974-03 for ; Tue, 13 Jun 2006 09:41:37 -0400 (EDT) Received: from rudy.mif.pg.gda.pl (rudy.mif.pg.gda.pl [153.19.42.16]) by menubar.gnome.org (Postfix) with ESMTP id 59FF13B000C for ; Tue, 13 Jun 2006 09:41:37 -0400 (EDT) X-Virus-Scanned: at rudy.mif.pg.gda.pl Received: by rudy.mif.pg.gda.pl (plum, from userid 2732) id 39ED2233B7; Tue, 13 Jun 2006 15:40:54 +0200 (CEST) Date: Tue, 13 Jun 2006 15:40:53 +0200 (CEST) From: =?ISO-8859-2?Q?Tomasz_K=B3oczko?= To: gtk-devel-list@gnome.org Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1270146782-1150206053=:31655" X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.579 tagged_above=-999 required=2 tests=[AWL=0.022, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.579 X-Spam-Level: Subject: gtk+ 2.9.3 compilation fail X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2006 13:41:41 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1270146782-1150206053=:31655 Content-Type: TEXT/PLAIN; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 8BIT gcc -DG_DISABLE_DEPRECATED -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -o .libs/gtk-query-immodules-2.0 queryimmodules.o ./.libs/libgtk-x11-2.0.so -L/lib64 /home/users/prac/nd/kloczek/rpm/BUILD/gtk+-2.9.3/gdk/.libs/libgdk-x11-2.0.so -latk-1.0 ../gdk-pixbuf/.libs/libgdk_pixbuf-2.0.so ../gdk/.libs/libgdk-x11-2.0.so -lpangocairo-1.0 -lpango-1.0 -lcairo -lfontconfig -lXext -lXrender -lX11 -lXinerama -lXi -lXrandr -lXcursor -lXfixes /home/users/prac/nd/kloczek/rpm/BUILD/gtk+-2.9.3/gdk-pixbuf/.libs/libgdk_pixbuf-2.0.so -lgmodule-2.0 -ldl -lgobject-2.0 -lglib-2.0 -lm ./.libs/libgtk-x11-2.0.so: undefined reference to `cairo_surface_set_fallback_resolution' collect2: ld returned 1 exit status make[4]: *** [gtk-query-immodules-2.0] Error 1 make[4]: Leaving directory `/home/users/prac/nd/kloczek/rpm/BUILD/gtk+-2.9.3/gtk' $ rpm -q cairo cairo-1.1.6-6 kloczek -- ----------------------------------------------------------- *Ludzie nie maj problemw, tylko sobie sami je stwarzaj* ----------------------------------------------------------- Tomasz Koczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek@rudy.mif.pg.gda.pl* --0-1270146782-1150206053=:31655-- From federico@ximian.com Tue Jun 13 12:13:42 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 31B0B3B0071 for ; Tue, 13 Jun 2006 12:13:42 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29632-05 for ; Tue, 13 Jun 2006 12:13:41 -0400 (EDT) Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) by menubar.gnome.org (Postfix) with ESMTP id 9C36B3B000A for ; Tue, 13 Jun 2006 12:13:40 -0400 (EDT) Received: (qmail 22968 invoked from network); 13 Jun 2006 16:11:48 -0000 Received: from localhost (HELO 164-99-120-90.boston.ximian.com) (127.0.0.1) by localhost with SMTP; 13 Jun 2006 16:11:48 -0000 From: Federico Mena Quintero To: Michael Natterer In-Reply-To: <1149849193.3010.23.camel@localhost> References: <1149608483.14088.54.camel@cacharro.xalalinux.org> <1149849193.3010.23.camel@localhost> Content-Type: text/plain Date: Tue, 13 Jun 2006 11:07:30 -0500 Message-Id: <1150214850.17566.118.camel@cacharro.xalalinux.org> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.574 tagged_above=-999 required=2 tests=[AWL=0.025, BAYES_00=-2.599] X-Spam-Score: -2.574 X-Spam-Level: Cc: GTK+ development mailing list , Michael.meeks@novell.com Subject: Re: Default timeouts X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2006 16:13:42 -0000 On Fri, 2006-06-09 at 12:33 +0200, Michael Natterer wrote: > However in some places I introduced a factor of 5 so all existing > timeouts could be done with the two values from GtkSettings. > > See comment #10 of http://bugzilla.gnome.org/show_bug.cgi?id=142582 > > Actually, it may make sense to simply use the user's configured > key repeat and delay for these two setting values. What do you > think? Yeah, it makes perfect sense to make it the same as the key repeat rate. You'll then get the same rate of change whether you use the mouse or the keyboard. Federico From stefan@space.twc.de Tue Jun 13 14:33:13 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id A37933B02D9 for ; Tue, 13 Jun 2006 14:33:13 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01854-06 for ; Tue, 13 Jun 2006 14:33:08 -0400 (EDT) Received: from space.twc.de (port-83-236-178-131.static.qsc.de [83.236.178.131]) by menubar.gnome.org (Postfix) with ESMTP id 1C3EE3B00C9 for ; Tue, 13 Jun 2006 14:33:07 -0400 (EDT) Received: from stefan by space.twc.de with local (Exim 4.50) id 1FqEOs-0007KV-NR; Tue, 13 Jun 2006 21:18:06 +0200 Date: Tue, 13 Jun 2006 21:18:06 +0200 To: Tim Janik Message-ID: <20060613191806.GA28032@space.twc.de> References: <20060609152646.GE20719@space.twc.de> <200606091630.k59GUaES013244@caipclassic.rutgers.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i From: Stefan Westerfeld X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.305 tagged_above=-999 required=2 tests=[AWL=0.159, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.305 X-Spam-Level: Cc: "Kaveh R. Ghazi" , Gtk+ Developers , gcc@gcc.gnu.org Subject: Re: Problem with type safety and the "sentinel" attribute X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2006 18:33:13 -0000 Hi! On Fri, Jun 09, 2006 at 07:30:25PM +0200, Tim Janik wrote: > On Fri, 9 Jun 2006, Kaveh R. Ghazi wrote: > >> void print_string_array (const char *array_name, > >> const char *string, ...) __attribute__ > >> ((__sentinel__)); > >> > >> print_string_array ("empty_array", NULL); /* gcc warns, but shouldn't > >*/ > >> > >> The only way out for keeping the sentinel attribute and avoiding the > >> warning is using > >> > >> static void print_string_array (const char *array_name, ...) > >> __attribute__ ((__sentinel__)); > > > >I think you could maintain typesafety and silence the warning by > >keeping the more specific prototype and adding an extra NULL, e.g.: > > > >print_string_array ("empty_array", NULL, NULL); > > > >Doesn't seem elegant, but it does the job. > > this is an option for a limited set of callers, yes. For the statistics, by adding the __sentinel__ attribute to the beast codebase, I have about 50 of those sentinel warnings that I don't need. So the double NULL termination would make quite some code more messy than it should be. > >> By the way, there is already an existing gcc bug, which is about the > >> same thing (NULL passed within named args), but wants to have it the > >> way it works now: > >> > >> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21911 > > > >Correct, the feature as I envisioned it expected the sentinel to > >appear in the variable arguments only. This PR reflects when I found > >out it didn't do that and got around to fixing it. Note the "buggy" > >behavior wasn't exactly what you wanted either because GCC got fooled > >by a sentinel in *any* of the named arguments, not just the last one. Ah, I see. > >> so if it gets changed, then gcc might need to support both > >> - NULL termination within the last named parameter allowed > >> - NULL termination only allowed within varargs parameters (like it is > >> now) > > > >I'm not against this enhancement, but you need to specify a syntax > >that allows the old behavior but also allows doing it your way. > > > >Hmm, perhaps we could check for attribute "nonnull" on the last named > >argument, if it exists then that can't be the sentinel, if it's not > >there then it does what you want. This is not completely backwards > >compatible because anyone wanting the existing behavior has to add the > >attribute nonnull. But there's precedent for this when attribute > >printf split out whether the format specifier could be null... > > > >We could also create a new attribute name for the new behavior. This > >would preserve backwards compatibility. I like this idea better. > > i agree here. as far as the majority of the GLib and Gtk+ APIs are > concerned, > we don't really need the flexibility of the sentinel attribute but rather > a compiler check on whether the last argument used in a function call > is NULL or 0 (regardless of whether it's the last named arg or already part > of the varargs list). > that's also why the actual sentinel wrapper in GLib looks like this: > > #define G_GNUC_NULL_TERMINATED __attribute__((__sentinel__)) > > so, if i was to make a call on this issue, i'd either introduce > __attribute__((__null_terminated__)) with the described semantics, > or have __attribute__((__sentinel__(-1))) work essentially like > __attribute__((__sentinel__(0))) while also accepting 0 in the position > of the last named argument. I also like the backwards compatible way better than trying to somehow modifying the attribute; it may break something now, or - which would also be bad - it may make something that somebody will want to check with the sentinel attribute in some future program impossible. The only case that I ever needed was NULL termination, so I think implementing one of the two proposals Tim made would be sufficient. Personally I like __attribute__((__null_terminated__)) better, because a -1 sentinel may be less intuitive to read in the source code. So this would be my suggestion for a "syntax specification". > >Next you need to recruit someone to implement this enhancement, or > >submit a patch. :-) Although given that you can silence the warning by > >adding an extra NULL at the call site, I'm not sure it's worth it. > > i would say this is definitely worth it, because the issue also shows up in > other code that is widely used: > gpointer g_object_new (GType object_type, > const gchar *first_property_name, > ...); > that's for instance a function which is called in many projects. > putting the burden on the caller is clearly the wrong trade off here. > > so please take this as a vote for the worthiness of a fix ;) Good. Of course I would be happy if somebody with knowledge of the compiler source could implement it. I never hacked gcc code before. But since you suggested sending a patch, I'll at least try to implement a new __null_terminated__ attribute, and ask for help if I can't figure out what to do. Cu... Stefan -- Stefan Westerfeld, Hamburg/Germany, http://space.twc.de/~stefan From easy-b@freesurf.ch Tue Jun 13 16:37:46 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 1FEC53B03CF for ; Tue, 13 Jun 2006 16:37:46 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05861-06 for ; Tue, 13 Jun 2006 16:37:45 -0400 (EDT) Received: from mail-fs.sunrise.ch (mta-fs-be-01.sunrise.ch [194.158.229.16]) by menubar.gnome.org (Postfix) with ESMTP id B948D3B00C8 for ; Tue, 13 Jun 2006 16:37:44 -0400 (EDT) Received: from [10.0.1.2] (84.226.131.17) by mail-fs.sunrise.ch (7.2.073) id 44795C850064786C; Tue, 13 Jun 2006 22:36:45 +0200 In-Reply-To: <89C1D6F0-EDC8-495C-B76B-9909E6388E62@freesurf.ch> References: <20060522160033.F1A8E3B1CE4@menubar.gnome.org> <772588ED-500A-4A11-8829-DA80B9A35D1F@freesurf.ch> <44720B8C.3080903@imendio.com> <0A34FCC9-6650-4737-B86D-1B503D8A9072@freesurf.ch> <7D6367DC-8689-453B-8FD7-217632BC1DAE@freesurf.ch> <89C1D6F0-EDC8-495C-B76B-9909E6388E62@freesurf.ch> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2B5653F8-341D-440C-9D5C-F166B296F94E@freesurf.ch> Content-Transfer-Encoding: 7bit From: Easy B Date: Tue, 13 Jun 2006 22:36:44 +0200 To: Gregor Riepl X-Mailer: Apple Mail (2.749.3) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-0.997 tagged_above=-999 required=2 tests=[AWL=-0.549, BAYES_00=-2.599, DNS_FROM_RFC_POST=1.708, FORGED_RCVD_HELO=0.135, TW_BG=0.077, TW_GD=0.077, TW_GT=0.077, TW_PK=0.077] X-Spam-Score: -0.997 X-Spam-Level: Cc: gtk-devel-list@gnome.org Subject: Re: Mac OS X Framework X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2006 20:37:46 -0000 Hi So i understand that we only need to link against one library that is linked to all the other ones, right? If I look at libgtk-quartz-2.0.dylib I see following: libgtk-quartz-2.0.dylib: /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libgtk-quartz-2.0.0.dylib (compatibility version 902.0.0, current version 902.0.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libgdk_pixbuf-2.0.0.dylib (compatibility version 902.0.0, current version 902.0.0) /usr/lib/libiconv.2.dylib (compatibility version 5.0.0, current version 5.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.1.5) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libgdk-quartz-2.0.0.dylib (compatibility version 902.0.0, current version 902.0.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libpangoft2-1.0.0.dylib (compatibility version 1301.0.0, current version 1301.1.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libpng12.0.dylib (compatibility version 11.0.0, current version 11.0.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libfontconfig.1.dylib (compatibility version 2.0.0, current version 2.4.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libfreetype.6.dylib (compatibility version 10.0.0, current version 10.8.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libxml2.2.dylib (compatibility version 9.0.0, current version 9.24.0) /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.3) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libpangocairo-1.0.0.dylib (compatibility version 1301.0.0, current version 1301.1.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libpango-1.0.0.dylib (compatibility version 1301.0.0, current version 1301.1.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libatk-1.0.0.dylib (compatibility version 1115.0.0, current version 1115.0.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libgobject-2.0.0.dylib (compatibility version 1102.0.0, current version 1102.0.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libgmodule-2.0.0.dylib (compatibility version 1102.0.0, current version 1102.0.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libglib-2.0.0.dylib (compatibility version 1102.0.0, current version 1102.0.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libcairo.2.dylib (compatibility version 9.0.0, current version 9.0.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libintl.3.dylib (compatibility version 8.0.0, current version 8.3.0) So I guess everything what we need is there. But I don't really get how to satisfy configure of a gtk app so that it only uses "- framework Gtk+". Sorry for my ignorance I'm pretty much a newbe on these things. Cheers, Ezra. On 12.06.2006, at 08:47, Gregor Riepl wrote: >> Thanx for the Tips. This would make the Framework more like one. >> The ability to include it into the application bundle would be >> very handy. >> >> If I look at other Frameworks I always find a single library in >> the top directory, for example: >> >> /System/Library/Frameworks/ApplicationServices.framework/Versions/ >> A/Frameworks/ImageIO.framework/ImageIO > that's right, this is the dynamic library itself. it doesn't have > the dylib suffix, but you may specify one if you like. > executables need to be linked against that, then, just -framework X > doesn't work. on the other hand, it's a good idea to either make > the "main" library (like libgtk-2.0.0.dylib) the framework (and > include all dependent libraries as either frameworks on their own > or dylibs) or just create an empty stub library that links against > those libraries or frameworks. to do that, make an empty .c source, > compile and link it against all the dylibs/frameworks you need. but > i can't tell if that's a good idea. > >> If I do "otool -L /System/Library/Frameworks/ >> ApplicationServices.framework/Versions/A/Frameworks/ >> ImageIO.framework/ImageIO", I get references to many other >> libraries that are located inside the framework bundle: > i guess that would be such a stub library, but maybe there's other > functionality contained? > otool can help you getting the symbols from mach-o binaries, much > like objdump. > >> In my Gtk+.framework I have tons of libraries. Would it be >> possible to create something like the above for gtk? Would it make >> sense? Right now I just use pkg-config to find the libraries and >> the result looks like this: >> >> /Applications/Shity Apps/Gtk-Demo.app/Contents/MacOS/gtk-demo: >> /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ >> libgdk_pixbuf-2.0.0.dylib (compatibility version 902.0.0, current >> version 902.0.0) >> ....... >> /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ >> libintl.3.dylib (compatibility version 8.0.0, current version 8.3.0) >> >> What do you think? > you should use /Library/Frameworks/Gtk+.framework/Versions/2.9.1/Gtk > + as the main library. it doesn't matter if that's just a stub or > the last library in the build chain (yes, i don't see > libgtk-2.0.0.dylib anywhere?). binaries then wouldn't require to be > linked against all those libs mentioned above. > this way you can also link gtk software with -framework Gtk+ and > nothing else, which you could even move into the pkconfig file and > thus facilitate porting. > i did something similar with the readily-available SDL framework > fpr mac os x, but it doesn't work very well because of the missing > startup code. with gtk it's easier i guess. > > have a nice day > gregor > > p.s.: on second thought, there could be a problem. afaik if a > binary loads a dylib, only that dylib's symbols become available > for it. the dependent symbols from libs that dylib's linked against > stay local for that dylib... maybe there's a workaround for this or > you come up with a better idea? From ntd@users.sourceforge.net Thu Jun 15 04:25:32 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 382C53B0324 for ; Thu, 15 Jun 2006 04:25:32 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22415-07 for ; Thu, 15 Jun 2006 04:25:29 -0400 (EDT) Received: from mailout01.albacom.net (mailout01.albacom.net [217.220.34.13]) by menubar.gnome.org (Postfix) with SMTP id 0694D3B0311 for ; Thu, 15 Jun 2006 04:25:28 -0400 (EDT) Received: (qmail 13668 invoked by uid 508); 15 Jun 2006 08:25:00 -0000 Received: from ntd@users.sourceforge.net by mailout01.albacom.net with qmail-scanner (spamassassin: ???. Clear:RC:1(217.221.76.9):SA:0(0.0/15.0):. Processed in 0.697195 secs); 15 Jun 2006 08:25:00 -0000 Received: from unknown (HELO sviluppo.internet.local) (postmaster@effe-gi.it@217.221.76.9) by mailout01.albacom.net with SMTP; 15 Jun 2006 08:24:59 -0000 Content-Disposition: inline From: Fontana Nicola Organization: Elettronica EFFE-GI s.n.c. To: gtk-devel-list@gnome.org Subject: GObject extension propose (GContainer) Date: Thu, 15 Jun 2006 11:01:12 +0000 User-Agent: KMail/1.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200606151101.12868.ntd@users.sourceforge.net> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.599 tagged_above=-999 required=2 tests=[BAYES_00=-2.599] X-Spam-Score: -2.599 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 08:25:32 -0000 Hi all, I'm a GObject based libraries (for UI purpose and not) user and I often need a generic container to derive my own types. In my opinion, I think this generic container must be included inside the GObject library ... it could be used by a lot of derived libraries providing a common approach. I published my solution - that is, what I am currently using - on sourceforge. http://sourceforge.net/projects/gcontainer/ Is it a good idea? Is something planned in this direction? Am I totally wrong? I need feedbacks ... Nicola From mclasen@redhat.com Thu Jun 15 09:54:37 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 88F2B3B00F3 for ; Thu, 15 Jun 2006 09:54:37 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14500-10 for ; Thu, 15 Jun 2006 09:54:36 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id 12BF23B0261 for ; Thu, 15 Jun 2006 09:54:36 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5FDsZ1W022208 for ; Thu, 15 Jun 2006 09:54:35 -0400 Received: from lacrosse.corp.redhat.com (lacrosse.corp.redhat.com [172.16.52.154]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5FDsZa4019641 for ; Thu, 15 Jun 2006 09:54:35 -0400 Received: from [172.16.83.98] (dhcp83-98.boston.redhat.com [172.16.83.98]) by lacrosse.corp.redhat.com (8.12.11.20060308/8.11.6) with ESMTP id k5FDsZL7008811 for ; Thu, 15 Jun 2006 09:54:35 -0400 Subject: GTK+ 2.10, the endgame From: Matthias Clasen To: gtk-devel-list@gnome.org Content-Type: text/plain Organization: Red Hat Date: Thu, 15 Jun 2006 09:56:26 -0400 Message-Id: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> Mime-Version: 1.0 X-Mailer: Evolution 2.7.3 (2.7.3-2) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.542 tagged_above=-999 required=2 tests=[AWL=0.059, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.542 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 13:54:37 -0000 I want to have GTK+ 2.10 ready at or immediately after GUADEC. I did not declare 2.9.3 api frozen in the release announcement, because we were still holding the door open for Kris' work on the new tooltips api. But he has run into some difficulties with the implementation which will take some time to overcome, so we have decided to punt this feature and try to get it into 2.12 early. Therefore, I want to consider 2.9.3 api frozen, and take a look at what still needs to happen before 2.10. Here are some things I personally would like get worked on (not sure how much time I can free to look into these myself): - I think the async filechooser conversion has caused some regressions, I noticed that .hidden support seems broken and autocompletion also behaved badly for me recently. - There is a number of FIXMEs and unimplemented bits in the print code. - The print backends need a careful look wrt to memory leaks and error reporting. Are there other important bugs or regressions that need attention before 2.10 ? Another thing I have slacked off about is organizing a GTK+ team meeting at GUADEC. So, who of the GTK+ team is there and at what times ? Should we try to find a free hour during the core days, or does everybody stay for the after hours ? If so, it may be easier to do a team meeting on Thursday... Matthias From timj@gtk.org Thu Jun 15 10:53:17 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id BBF963B04EA for ; Thu, 15 Jun 2006 10:53:17 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17592-10 for ; Thu, 15 Jun 2006 10:53:16 -0400 (EDT) Received: from holken.mikan.net (holken.mikan.net [83.145.56.183]) by menubar.gnome.org (Postfix) with ESMTP id 035EF3B04E7 for ; Thu, 15 Jun 2006 10:53:15 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by holken.mikan.net (Postfix) with ESMTP id C0DB83352B4; Thu, 15 Jun 2006 16:52:21 +0200 (CEST) Received: from holken.mikan.net ([127.0.0.1]) by localhost (holken.mikan.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16765-03; Thu, 15 Jun 2006 16:52:18 +0200 (CEST) Received: from birnet.org (c152167.adsl.hansenet.de [213.39.152.167]) by holken.mikan.net (Postfix) with ESMTP id E3B0433529D; Thu, 15 Jun 2006 16:52:17 +0200 (CEST) Received: from master.birnet.private (localhost.localdomain [127.0.0.1]) by birnet.org (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k5FEqH2d008152 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 15 Jun 2006 16:52:18 +0200 Received: (from timj@localhost) by master.birnet.private (8.13.4/8.13.4/Submit) id k5FEqHpN008151; Thu, 15 Jun 2006 16:52:17 +0200 Date: Thu, 15 Jun 2006 16:52:17 +0200 (CEST) From: Tim Janik X-X-Sender: timj@master.birnet.private To: Fontana Nicola Subject: Re: GObject extension propose (GContainer) In-Reply-To: <200606151101.12868.ntd@users.sourceforge.net> Message-ID: References: <200606151101.12868.ntd@users.sourceforge.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at holken.mikan.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.38 tagged_above=-999 required=2 tests=[AWL=0.084, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.38 X-Spam-Level: Cc: Gtk+ Developers X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 14:53:17 -0000 On Thu, 15 Jun 2006, Fontana Nicola wrote: > Hi all, > > I'm a GObject based libraries (for UI purpose and not) user and I often need > a generic container to derive my own types. In my opinion, I think this > generic container must be included inside the GObject library ... it could > be used by a lot of derived libraries providing a common approach. > > I published my solution - that is, what I am currently using - on > sourceforge. > > http://sourceforge.net/projects/gcontainer/ > > Is it a good idea? Is something planned in this direction? Am I totally > wrong? > > I need feedbacks ... hi. your gcontainer-1.0.0 looks like an interesting approach to me, but i'm not sure it's generally good to put that into stock libgobject. the main reason is that container needs are probably pretty variable out there (i've come across at least 4 different gobject container implementations in free software projects i'm woorking on) and that both, making too little assumptions in the child/container interface isn't going to be very helpful, albeit making too many has the same problem. i guess we could add a link to your project from the libgobject docs (it should probably have a Contrib section), for people possibly looking for a GObject container implementation. that way, gcontainer-1.0.0 gets a chance of being reused and maybe extended to something generally usefull for GObject applications out there. > Nicola --- ciaoTJ From timj@gtk.org Thu Jun 15 11:31:19 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 642E33B02ED for ; Thu, 15 Jun 2006 11:31:19 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19431-03 for ; Thu, 15 Jun 2006 11:31:18 -0400 (EDT) Received: from holken.mikan.net (holken.mikan.net [83.145.56.183]) by menubar.gnome.org (Postfix) with ESMTP id 2E9543B0155 for ; Thu, 15 Jun 2006 11:31:18 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by holken.mikan.net (Postfix) with ESMTP id B5DB533524B; Thu, 15 Jun 2006 16:32:01 +0200 (CEST) Received: from holken.mikan.net ([127.0.0.1]) by localhost (holken.mikan.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16412-10; Thu, 15 Jun 2006 16:31:58 +0200 (CEST) Received: from birnet.org (c152167.adsl.hansenet.de [213.39.152.167]) by holken.mikan.net (Postfix) with ESMTP id D5D7E335256; Thu, 15 Jun 2006 16:31:57 +0200 (CEST) Received: from master.birnet.private (localhost.localdomain [127.0.0.1]) by birnet.org (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k5FEVrL1007682 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 15 Jun 2006 16:31:53 +0200 Received: (from timj@localhost) by master.birnet.private (8.13.4/8.13.4/Submit) id k5FEVis7007681; Thu, 15 Jun 2006 16:31:45 +0200 Date: Thu, 15 Jun 2006 16:31:44 +0200 (CEST) From: Tim Janik X-X-Sender: timj@master.birnet.private To: Matthias Clasen Subject: GTK+ meeting at GUADEC (Re: GTK+ 2.10, the endgame) In-Reply-To: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> Message-ID: References: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at holken.mikan.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.381 tagged_above=-999 required=2 tests=[AWL=0.083, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.381 X-Spam-Level: Cc: Gtk+ Developers X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 15:31:19 -0000 On Thu, 15 Jun 2006, Matthias Clasen wrote: > I want to have GTK+ 2.10 ready at or immediately after GUADEC. > Another thing I have slacked off about is organizing a GTK+ > team meeting at GUADEC. So, who of the GTK+ team is there > and at what times ? Should we try to find a free hour during > the core days, or does everybody stay for the after hours ? > If so, it may be easier to do a team meeting on Thursday... i think i volounteered to take on arrangement of that to some extend. at least, we intended to have a meeting on GTK+ linking issues, and could probably merge that with the GTK+ team meeting during guadec. the plan for that was to send out en email next friday/saturday (i.e right at the guadec start) to figure/suggest dates suitable for everyone to attend. > Matthias --- ciaoTJ From hfiguiere@teaser.fr Thu Jun 15 11:52:14 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C00CA3B0261 for ; Thu, 15 Jun 2006 11:52:14 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20706-05 for ; Thu, 15 Jun 2006 11:52:13 -0400 (EDT) Received: from xandros.com (smtp1.xandros.com [209.87.238.70]) by menubar.gnome.org (Postfix) with ESMTP id 6D7663B053A for ; Thu, 15 Jun 2006 11:52:13 -0400 (EDT) Received: from [172.16.1.95] (unknown [209.87.238.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by xandros.com (Postfix) with ESMTP id 4B02239025; Thu, 15 Jun 2006 11:51:30 -0400 (EDT) Message-ID: <44918201.6010605@teaser.fr> Date: Thu, 15 Jun 2006 11:51:29 -0400 From: Hubert Figuiere User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: Matthias Clasen Subject: Re: GTK+ 2.10, the endgame References: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> In-Reply-To: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.54 tagged_above=-999 required=2 tests=[AWL=0.059, BAYES_00=-2.599] X-Spam-Score: -2.54 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 15:52:14 -0000 Matthias Clasen wrote: > I want to have GTK+ 2.10 ready at or immediately after GUADEC. Can somebody summarize the Mac port status? Hub From tristan.van.berkom@gmail.com Thu Jun 15 12:44:57 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 0A0273B05DC for ; Thu, 15 Jun 2006 12:44:57 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23203-02 for ; Thu, 15 Jun 2006 12:44:56 -0400 (EDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.200]) by menubar.gnome.org (Postfix) with ESMTP id 0AD9C3B007F for ; Thu, 15 Jun 2006 12:44:55 -0400 (EDT) Received: by wx-out-0102.google.com with SMTP id i30so312681wxd for ; Thu, 15 Jun 2006 09:44:14 -0700 (PDT) Received: by 10.70.100.8 with SMTP id x8mr2494520wxb; Thu, 15 Jun 2006 09:44:14 -0700 (PDT) Received: from ?66.48.170.37? ( [66.48.170.37]) by mx.gmail.com with ESMTP id i39sm1649326wxd.2006.06.15.09.44.12; Thu, 15 Jun 2006 09:44:14 -0700 (PDT) Message-ID: <44919246.8060301@gnome.org> Date: Thu, 15 Jun 2006 13:00:54 -0400 User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Janik Subject: Re: GObject extension propose (GContainer) References: <200606151101.12868.ntd@users.sourceforge.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit From: Tristan Van Berkom X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.481 tagged_above=-999 required=2 tests=[AWL=-0.414, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=1.456, SPF_PASS=-0.001, TW_GT=0.077] X-Spam-Score: -1.481 X-Spam-Level: Cc: Gtk+ Developers X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 16:44:57 -0000 Tim Janik wrote: >On Thu, 15 Jun 2006, Fontana Nicola wrote: > > > >>Hi all, >> >>I'm a GObject based libraries (for UI purpose and not) user and I often need >>a generic container to derive my own types. In my opinion, I think this >>generic container must be included inside the GObject library ... it could >>be used by a lot of derived libraries providing a common approach. >> >>I published my solution - that is, what I am currently using - on >>sourceforge. >> >>http://sourceforge.net/projects/gcontainer/ >> >>Is it a good idea? Is something planned in this direction? Am I totally >>wrong? >> >>I need feedbacks ... >> >> As a side note... I've been working on container --> child relationships and honing them down inside the glade builder... objects may for example have object delagates that are "owned" and in turn may "own" other delagates... this is all functional with libglade facilities and the future gtk builder also (from the design as of yet...)... this concept of "types of container relationships" is also usefull for GtkMenuShell --> GtkMenu for example (not just any GtkWidget can be added to a menushell). All of that just to say... I cannot count the times I've thought to myself that GtkContainer should really just be GContainerIface, and implemented by whatever interested objects that want to parent other objects... I think that what we need is not really "yet another container api", but a container api that is a unified front for generic handling of the GTK object hierarchy at runtime. Cheers, -Tristan From federico@ximian.com Thu Jun 15 12:56:13 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 0DAD63B03FF for ; Thu, 15 Jun 2006 12:56:13 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23665-06 for ; Thu, 15 Jun 2006 12:56:06 -0400 (EDT) Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) by menubar.gnome.org (Postfix) with ESMTP id 688823B0613 for ; Thu, 15 Jun 2006 12:56:05 -0400 (EDT) Received: (qmail 25104 invoked from network); 15 Jun 2006 16:54:53 -0000 Received: from localhost (HELO 164-99-120-38.boston.ximian.com) (127.0.0.1) by localhost with SMTP; 15 Jun 2006 16:54:53 -0000 Subject: Re: GTK+ 2.10, the endgame From: Federico Mena Quintero To: Matthias Clasen In-Reply-To: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> References: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> Content-Type: text/plain Date: Thu, 15 Jun 2006 11:50:29 -0500 Message-Id: <1150390229.17566.191.camel@cacharro.xalalinux.org> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.575 tagged_above=-999 required=2 tests=[AWL=0.024, BAYES_00=-2.599] X-Spam-Score: -2.575 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 16:56:13 -0000 On Thu, 2006-06-15 at 09:56 -0400, Matthias Clasen wrote: > Therefore, I want to consider 2.9.3 api frozen, and take a > look at what still needs to happen before 2.10. Here are some > things I personally would like get worked on (not sure > how much time I can free to look into these myself): > > - I think the async filechooser conversion has caused some > regressions, I noticed that .hidden support seems broken > and autocompletion also behaved badly for me recently. Yes, it's quite broken at the moment. I don't think we can do any more productive debugging (fixing something breaks something else) until we have a good set of automated tests for the basic behaviors. > - There is a number of FIXMEs and unimplemented bits in > the print code. > > - The print backends need a careful look wrt to memory leaks > and error reporting. I'm rather worried of declaring the printing API as stable and just unleashing it to the world. Is any software *really* using it? Does it contemplate things like - sites with thousands of printers - sites which want to lock-down certain printers - color management for apps that need it > Another thing I have slacked off about is organizing a GTK+ > team meeting at GUADEC. So, who of the GTK+ team is there > and at what times ? Should we try to find a free hour during > the core days, or does everybody stay for the after hours ? > If so, it may be easier to do a team meeting on Thursday... I'll be there since Sunday morning. Thursday is the Advisory Board meeting, so I'm afraid I won't have that day free for the GTK+ meeeting. Federico From mclasen@redhat.com Thu Jun 15 13:15:33 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id BC2163B0187 for ; Thu, 15 Jun 2006 13:15:33 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24531-03 for ; Thu, 15 Jun 2006 13:15:29 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id DCC933B0227 for ; Thu, 15 Jun 2006 13:15:28 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5FHDjVa014384; Thu, 15 Jun 2006 13:13:45 -0400 Received: from lacrosse.corp.redhat.com (lacrosse.corp.redhat.com [172.16.52.154]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5FHDjmo017834; Thu, 15 Jun 2006 13:13:45 -0400 Received: from [172.16.83.98] (dhcp83-98.boston.redhat.com [172.16.83.98]) by lacrosse.corp.redhat.com (8.12.11.20060308/8.11.6) with ESMTP id k5FHDjGC025752; Thu, 15 Jun 2006 13:13:45 -0400 Subject: Re: GTK+ 2.10, the endgame From: Matthias Clasen To: Federico Mena Quintero In-Reply-To: <1150390229.17566.191.camel@cacharro.xalalinux.org> References: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> <1150390229.17566.191.camel@cacharro.xalalinux.org> Content-Type: text/plain Organization: Red Hat Date: Thu, 15 Jun 2006 13:15:37 -0400 Message-Id: <1150391737.3187.33.camel@dhcp83-98.boston.redhat.com> Mime-Version: 1.0 X-Mailer: Evolution 2.7.3 (2.7.3-2) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.542 tagged_above=-999 required=2 tests=[AWL=0.059, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.542 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 17:15:33 -0000 On Thu, 2006-06-15 at 11:50 -0500, Federico Mena Quintero wrote: > On Thu, 2006-06-15 at 09:56 -0400, Matthias Clasen wrote: > > > Therefore, I want to consider 2.9.3 api frozen, and take a > > look at what still needs to happen before 2.10. Here are some > > things I personally would like get worked on (not sure > > how much time I can free to look into these myself): > > > > - I think the async filechooser conversion has caused some > > regressions, I noticed that .hidden support seems broken > > and autocompletion also behaved badly for me recently. > > Yes, it's quite broken at the moment. I don't think we can do any more > productive debugging (fixing something breaks something else) until we > have a good set of automated tests for the basic behaviors. Quite unfortunate. We spent too much time working on finetuning the filechooser behaviour to leave it broken now... > > - There is a number of FIXMEs and unimplemented bits in > > the print code. > > > > - The print backends need a careful look wrt to memory leaks > > and error reporting. > > I'm rather worried of declaring the printing API as stable and just > unleashing it to the world. Is any software *really* using it? Does it > contemplate things like Typical chicken and egg problem that won't be solved by keeping it unreleased for another year. There is no way to get any software _really_ using it without releasing it first. We got quite a bit of feedback from people looking at porting real apps to it (e.g gedit, OOo and epiphany), so it is not as if we release it straight from the whiteboard. > - sites with thousands of printers > > - sites which want to lock-down certain printers > > - color management for apps that need it No doubt that we may have to add new api in 2.12 to accomodate things like this, but all of these are special cases. From muntyan@tamu.edu Thu Jun 15 15:05:44 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 9364F3B0605 for ; Thu, 15 Jun 2006 15:05:44 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28754-04 for ; Thu, 15 Jun 2006 15:05:41 -0400 (EDT) Received: from smtp103.vzn.mail.mud.yahoo.com (smtp103.vzn.mail.mud.yahoo.com [68.142.203.47]) by menubar.gnome.org (Postfix) with SMTP id 568873B05C3 for ; Thu, 15 Jun 2006 15:05:40 -0400 (EDT) Received: (qmail 34334 invoked from network); 15 Jun 2006 19:05:00 -0000 Received: from unknown (HELO ?192.168.3.9?) (muntyan@verizon.net@71.113.224.59 with plain) by smtp103.vzn.mail.mud.yahoo.com with SMTP; 15 Jun 2006 19:04:59 -0000 Message-ID: <4491AF5A.2050702@tamu.edu> Date: Thu, 15 Jun 2006 14:04:58 -0500 From: Yevgen Muntyan User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20060216 Debian/1.7.12-1.1ubuntu2 X-Accept-Language: en MIME-Version: 1.0 To: GTK Devel List Subject: Printing and blocking ui Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.552 tagged_above=-999 required=2 tests=[AWL=0.047, BAYES_00=-2.599] X-Spam-Score: -2.552 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 19:05:44 -0000 Hi there, I print a text document from GtkTextView here. There is a problem with pagination: pagination is potentially slow, so some sort of progress dialog should be shown during it. From the other hand, the text buffer must not be modified during pagination. How to solve it? Should I show my own modal dialog and make sure user doesn't modify the buffer, or GtkPrintOperation can take care of it? Actually, it would be good to ensure printing blocks the text widget too, since in this case it wouldn't be necessary to calculate and store all the pango layouts in begin-print. Maybe just show a modal dialog between begin-print and end-print. Thanks, Yevgen From richard@imendio.com Thu Jun 15 15:08:15 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C90B13B02BF for ; Thu, 15 Jun 2006 15:08:15 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28754-07 for ; Thu, 15 Jun 2006 15:08:14 -0400 (EDT) Received: from holken.mikan.net (holken.mikan.net [83.145.56.183]) by menubar.gnome.org (Postfix) with ESMTP id 47EFB3B018C for ; Thu, 15 Jun 2006 15:08:14 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by holken.mikan.net (Postfix) with ESMTP id 418C111EB4; Thu, 15 Jun 2006 21:07:02 +0200 (CEST) Received: from holken.mikan.net ([127.0.0.1]) by localhost (holken.mikan.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04160-07; Thu, 15 Jun 2006 21:06:58 +0200 (CEST) Received: from [192.168.100.5] (c83-248-134-21.bredband.comhem.se [83.248.134.21]) by holken.mikan.net (Postfix) with ESMTP id E679E1459D; Thu, 15 Jun 2006 21:06:57 +0200 (CEST) Message-ID: <4491AFD0.5000408@imendio.com> Date: Thu, 15 Jun 2006 21:06:56 +0200 From: Richard Hult Organization: Imendio AB User-Agent: Thunderbird 1.5.0.4 (Macintosh/20060530) MIME-Version: 1.0 To: Hubert Figuiere Subject: Re: GTK+ 2.10, the endgame References: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> <44918201.6010605@teaser.fr> In-Reply-To: <44918201.6010605@teaser.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at holken.mikan.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.543 tagged_above=-999 required=2 tests=[AWL=0.056, BAYES_00=-2.599] X-Spam-Score: -2.543 X-Spam-Level: Cc: gtk-devel-list@gnome.org, Matthias Clasen X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 19:08:16 -0000 Hubert Figuiere skrev: > Matthias Clasen wrote: >> I want to have GTK+ 2.10 ready at or immediately after GUADEC. > > Can somebody summarize the Mac port status? The basic functionality is implemented and what's next in the pipeline is bug fixing, and after that looking into tighter integration with the platform in various areas. /Richard From muntyan@tamu.edu Thu Jun 15 15:12:58 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 9FC7E3B063D for ; Thu, 15 Jun 2006 15:12:58 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29079-06 for ; Thu, 15 Jun 2006 15:12:57 -0400 (EDT) Received: from smtp101.vzn.mail.mud.yahoo.com (smtp101.vzn.mail.mud.yahoo.com [68.142.203.45]) by menubar.gnome.org (Postfix) with SMTP id E72693B0613 for ; Thu, 15 Jun 2006 15:12:56 -0400 (EDT) Received: (qmail 97288 invoked from network); 15 Jun 2006 19:11:44 -0000 Received: from unknown (HELO ?192.168.3.9?) (muntyan@verizon.net@71.113.224.59 with plain) by smtp101.vzn.mail.mud.yahoo.com with SMTP; 15 Jun 2006 19:11:43 -0000 Message-ID: <4491B0EE.3040900@tamu.edu> Date: Thu, 15 Jun 2006 14:11:42 -0500 From: Yevgen Muntyan User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20060216 Debian/1.7.12-1.1ubuntu2 X-Accept-Language: en MIME-Version: 1.0 To: gtk-devel-list@gnome.org Subject: Re: GTK+ 2.10, the endgame References: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> <1150390229.17566.191.camel@cacharro.xalalinux.org> In-Reply-To: <1150390229.17566.191.camel@cacharro.xalalinux.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.514 tagged_above=-999 required=2 tests=[AWL=0.008, BAYES_00=-2.599, TW_GT=0.077] X-Spam-Score: -2.514 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 19:12:58 -0000 Federico Mena Quintero wrote: >On Thu, 2006-06-15 at 09:56 -0400, Matthias Clasen wrote: > > >>- The print backends need a careful look wrt to memory leaks >> and error reporting. >> >> > >I'm rather worried of declaring the printing API as stable and just >unleashing it to the world. Is any software *really* using it? > > Yes, there is software which is going to use gtk printing as soon as gtk-2.10 is released. And there will be much more when gtk has printing. Just think for a moment about gtk-but-not-gnome applications (win32 comes to mind too). > - sites with thousands of printers > > - sites which want to lock-down certain printers > > - color management for apps that need it > > If gtk can print to a single user's printer, it's already worth releasing. Again, there are applications which do not have printing, because they can't use gnomeprint, and developers don't feel like implement their own printing while gtk is going to get it. IMHO, etc., you know. Best regards, Yevgen From gnome-gtk-devel-list@m.gmane.org Thu Jun 15 16:40:15 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 2360D3B00D0 for ; Thu, 15 Jun 2006 16:40:15 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32360-05 for ; Thu, 15 Jun 2006 16:40:13 -0400 (EDT) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by menubar.gnome.org (Postfix) with ESMTP id 3B9113B0237 for ; Thu, 15 Jun 2006 16:40:13 -0400 (EDT) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1FqydG-0004Vk-6i for gtk-devel-list@gnome.org; Thu, 15 Jun 2006 22:40:02 +0200 Received: from cpe0004e2d9f884-cm0013718690da.cpe.net.cable.rogers.com ([70.24.212.140]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 15 Jun 2006 22:40:02 +0200 Received: from jasonspiro4+news by cpe0004e2d9f884-cm0013718690da.cpe.net.cable.rogers.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 15 Jun 2006 22:40:02 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gtk-devel-list@gnome.org From: Jason Spiro Subject: Imagine: what if points in Bugzilla had a significant effect? Date: Thu, 15 Jun 2006 19:15:34 +0000 (UTC) Lines: 15 Message-ID: X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cpe0004e2d9f884-cm0013718690da.cpe.net.cable.rogers.com User-Agent: slrn/0.9.8.1pl1 (Debian) Sender: news X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.601 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.601 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 20:40:15 -0000 Imagine: what if points did something in Bugzilla, like, the more points you have, the more votes you get? I think this would encourage people to file more bug reports, both good bug reports and not-so-good ones. Would that be a net gain or a net loss for GTK+? Regards, Jason Spiro -- Jason Spiro: computer consulting with a smile. Specializing in Linux: Red Hat AS / ES, Debian, and others. Serving homes and companies globally via remote access tools. Fair rates. Just email jasonspiro4@gmail.com or call Skype ID jasonspiro. From murrayc@murrayc.com Fri Jun 16 04:53:13 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id D68413B0007 for ; Fri, 16 Jun 2006 04:53:12 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23115-03 for ; Fri, 16 Jun 2006 04:53:08 -0400 (EDT) Received: from swarthymail-a5.dreamhost.com (sd-green-bigip-176.dreamhost.com [208.97.132.176]) by menubar.gnome.org (Postfix) with ESMTP id 7FA303B006C for ; Fri, 16 Jun 2006 04:53:08 -0400 (EDT) Received: from noname (p5497E1BF.dip.t-dialin.net [84.151.225.191]) by swarthymail-a5.dreamhost.com (Postfix) with ESMTP id 69FE4109E8B; Fri, 16 Jun 2006 01:52:14 -0700 (PDT) Subject: Re: GTK+ 2.10, the endgame From: Murray Cumming To: Matthias Clasen In-Reply-To: <1150391737.3187.33.camel@dhcp83-98.boston.redhat.com> References: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> <1150390229.17566.191.camel@cacharro.xalalinux.org> <1150391737.3187.33.camel@dhcp83-98.boston.redhat.com> Content-Type: text/plain Date: Fri, 16 Jun 2006 10:52:10 +0200 Message-Id: <1150447930.5806.4.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.481 tagged_above=-999 required=2 tests=[AWL=0.118, BAYES_00=-2.599] X-Spam-Score: -2.481 X-Spam-Level: Cc: Federico Mena Quintero , gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2006 08:53:13 -0000 I'm also concerned about the recent files stuff. Do we now have UIManager integration of that? -- Murray Cumming murrayc@murrayc.com www.murrayc.com www.openismus.com From murrayc@murrayc.com Fri Jun 16 05:06:58 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id A76AC3B0076 for ; Fri, 16 Jun 2006 05:06:58 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23550-01 for ; Fri, 16 Jun 2006 05:06:57 -0400 (EDT) Received: from kungfu.dreamhost.com (kungfu.dreamhost.com [66.33.216.126]) by menubar.gnome.org (Postfix) with ESMTP id D099D3B006B for ; Fri, 16 Jun 2006 05:06:57 -0400 (EDT) Received: from swarthymail-a4.dreamhost.com (sd-green-bigip-62.dreamhost.com [208.97.132.62]) by kungfu.dreamhost.com (Postfix) with ESMTP id 708B51F0265 for ; Fri, 16 Jun 2006 01:28:47 -0700 (PDT) Received: from noname (p5497E1BF.dip.t-dialin.net [84.151.225.191]) by swarthymail-a4.dreamhost.com (Postfix) with ESMTP id 0D51A129A83; Fri, 16 Jun 2006 01:28:10 -0700 (PDT) Subject: Re: GTK+ 2.10, the endgame From: Murray Cumming To: Matthias Clasen In-Reply-To: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> References: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> Content-Type: text/plain Date: Thu, 15 Jun 2006 23:20:27 +0200 Message-Id: <1150406427.30234.1.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.068 tagged_above=-999 required=2 tests=[AWL=-0.296, BAYES_00=-2.599, DATE_IN_PAST_06_12=0.827] X-Spam-Score: -2.068 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2006 09:06:58 -0000 On Thu, 2006-06-15 at 09:56 -0400, Matthias Clasen wrote: > I want to have GTK+ 2.10 ready at or immediately after GUADEC. [snip] I'd rather it was after rather than before. That gives us just a little more time to get everything wrapped quickly for gtkmm, which might show some small problems that need fixing. Maybe I haven't been paying attention, but I'm surprised (again) by the freeze announcement. -- Murray Cumming murrayc@murrayc.com www.murrayc.com www.openismus.com From mgiannakidis@gmail.com Thu Jun 15 11:24:35 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id B7BE73B0211 for ; Thu, 15 Jun 2006 11:24:35 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19150-09 for ; Thu, 15 Jun 2006 11:24:34 -0400 (EDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.188]) by menubar.gnome.org (Postfix) with ESMTP id AAD863B04FC for ; Thu, 15 Jun 2006 11:24:33 -0400 (EDT) Received: by nf-out-0910.google.com with SMTP id c2so90382nfe for ; Thu, 15 Jun 2006 08:23:41 -0700 (PDT) Received: by 10.48.47.15 with SMTP id u15mr674329nfu; Thu, 15 Jun 2006 08:23:39 -0700 (PDT) Received: from ?213.140.137.120? ( [213.140.137.120]) by mx.gmail.com with ESMTP id n22sm2029009nfc.2006.06.15.08.23.38; Thu, 15 Jun 2006 08:23:39 -0700 (PDT) From: Michalis Giannakidis To: gtk-devel-list@gnome.org Subject: gslice allocator: general impresions. Date: Thu, 15 Jun 2006 18:27:45 +0300 User-Agent: KMail/1.8.3 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200606151827.45477.mgiannakidis@gmail.com> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.6 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.6 X-Spam-Level: X-Mailman-Approved-At: Fri, 16 Jun 2006 05:29:57 -0400 X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 15:24:35 -0000 Dear Glib team, I have recently used the glib-glice allocator in a very malloc intensive application, and I would like to share a few observations I made, with you. The typical size I send to g_slice_alloc is 20 and 76 bytes (32 bit build). The total memory consumed by my application has decreased - which is great! However it `seems' to me, that this decrease in size is larger for the 64bit build compared to the 32bit build. (I have modified gslice to align a chunk to its own size so that I don't have unused memory between chunks eg: request 20 and get 24...) In my application now I use both g_slice_alloc and malloc.Testing the new allocator in linux I came accross the following: After using g_slice_alloc to alloc a great amount of data (eg 1500mb), each of them being 20 or 76 bytes in size, subsequent calls to malloc(8*1024) or similar sizes take much longer (the allocation does _not_ got to the swap). Also if I chage the min_page_size from 128 to 4096, then the subsequent calls to malloc(8*1024) or similar sizes take even longer. It takes for ever in the 64 bit build! Moreover, even with min_page_size set to 128, the calls to malloc take for ever on a Linux 2.4.20 glibc-2.2.4(glibc up to 2.2.5 has a broken posix_memalign so I fallback to memalign). In all of the cases above, malloc responds much faster when the gslice allocator is turned off. I know I should be providing sample code and test programms here to back up my observations. I also understand that I should provide execution times instead of just stating that the calls to malloc take for ever. I would like to ask you, if there are any known issues in mixing gslice and malloc calls in malloc intensive applications. Any suggested readings would be most welcome. Regards Michalis -- Michalis Giannakidis From timj@gtk.org Fri Jun 16 07:30:05 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id EEDE23B0011 for ; Fri, 16 Jun 2006 07:30:04 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26976-06 for ; Fri, 16 Jun 2006 07:30:04 -0400 (EDT) Received: from holken.mikan.net (holken.mikan.net [83.145.56.183]) by menubar.gnome.org (Postfix) with ESMTP id DA78D3B0007 for ; Fri, 16 Jun 2006 07:30:03 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by holken.mikan.net (Postfix) with ESMTP id BDFA43352B0; Fri, 16 Jun 2006 13:28:54 +0200 (CEST) Received: from holken.mikan.net ([127.0.0.1]) by localhost (holken.mikan.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29662-08; Fri, 16 Jun 2006 13:28:48 +0200 (CEST) Received: from birnet.org (d003098.adsl.hansenet.de [80.171.3.98]) by holken.mikan.net (Postfix) with ESMTP id DFB2633525A; Fri, 16 Jun 2006 13:28:47 +0200 (CEST) Received: from master.birnet.private (localhost.localdomain [127.0.0.1]) by birnet.org (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k5GBSi9S008066 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 16 Jun 2006 13:28:44 +0200 Received: (from timj@localhost) by master.birnet.private (8.13.4/8.13.4/Submit) id k5GBSZMj008064; Fri, 16 Jun 2006 13:28:35 +0200 Date: Fri, 16 Jun 2006 13:28:35 +0200 (CEST) From: Tim Janik X-X-Sender: timj@master.birnet.private To: "Gustavo J. A. M. Carneiro" Subject: Re: GObject extension propose (GContainer) In-Reply-To: <1150456522.5305.12.camel@localhost.localdomain> Message-ID: References: <200606151101.12868.ntd@users.sourceforge.net> <44919246.8060301@gnome.org> <1150456522.5305.12.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="656239-2144330416-1150457315=:7955" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at holken.mikan.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.677 tagged_above=-999 required=2 tests=[AWL=-0.669, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, RCVD_IN_SORBS_WEB=1.456] X-Spam-Score: -1.677 X-Spam-Level: Cc: Gtk+ Developers X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2006 11:30:05 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --656239-2144330416-1150457315=:7955 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Fri, 16 Jun 2006, Gustavo J. A. M. Carneiro wrote: > Qui, 2006-06-15 =E0s 13:00 -0400, Tristan Van Berkom escreveu: >> All of that just to say... I cannot count the times I've thought to >> myself that >> GtkContainer should really just be GContainerIface, and implemented by >> whatever interested objects that want to parent other objects... > > That's interesting, but I wonder what is the runtime penalty of > interface lookup compared to normal class structure lookup? Is it > really OK to use an interface for this, or is it better just to add a > new virtual methods to the GObject class? the lookup penalties are negligible. type node/class lookups and is_a checks are O(1); interface class lookups and conforms_to checks are O(ld(N)), where N is the number of interfaces a type node conforms to. > Gustavo J. A. M. Carneiro --- ciaoTJ --656239-2144330416-1150457315=:7955-- From gjc@inescporto.pt Fri Jun 16 07:34:21 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 74BCC3B000B for ; Fri, 16 Jun 2006 07:34:21 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26977-07 for ; Fri, 16 Jun 2006 07:34:20 -0400 (EDT) Received: from animal.inescn.pt (correio.inescn.pt [194.117.24.9]) by menubar.gnome.org (Postfix) with ESMTP id 5B7183B0011 for ; Fri, 16 Jun 2006 07:34:19 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by animal.inescn.pt (8.13.6/8.13.6/7) with ESMTP id k5GBFdIJ028014; Fri, 16 Jun 2006 12:15:39 +0100 (WEST) Received: from pong.inescporto.pt (pong.inescn.pt [194.117.26.74]) by animal.inescn.pt (8.13.6/8.13.6/5) with ESMTP id k5GBFT0a027999; Fri, 16 Jun 2006 12:15:29 +0100 (WEST) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by pong.inescporto.pt (Postfix) with ESMTP id AE13A39D8; Fri, 16 Jun 2006 12:12:16 +0100 (WEST) Subject: Re: GObject extension propose (GContainer) From: "Gustavo J. A. M. Carneiro" To: Tristan Van Berkom In-Reply-To: <44919246.8060301@gnome.org> References: <200606151101.12868.ntd@users.sourceforge.net> <44919246.8060301@gnome.org> Content-Type: text/plain; charset=UTF-8 Date: Fri, 16 Jun 2006 12:15:21 +0100 Message-Id: <1150456522.5305.12.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at inescporto.pt X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.39 tagged_above=-999 required=2 tests=[AWL=-0.002, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, SPF_PASS=-0.001, TW_GT=0.077] X-Spam-Score: -2.39 X-Spam-Level: Cc: Gtk+ Developers , Tim Janik X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2006 11:34:21 -0000 Qui, 2006-06-15 s 13:00 -0400, Tristan Van Berkom escreveu: > Tim Janik wrote: > > >On Thu, 15 Jun 2006, Fontana Nicola wrote: > > > > > > > >>Hi all, > >> > >>I'm a GObject based libraries (for UI purpose and not) user and I often need > >>a generic container to derive my own types. In my opinion, I think this > >>generic container must be included inside the GObject library ... it could > >>be used by a lot of derived libraries providing a common approach. > >> > >>I published my solution - that is, what I am currently using - on > >>sourceforge. > >> > >>http://sourceforge.net/projects/gcontainer/ > >> > >>Is it a good idea? Is something planned in this direction? Am I totally > >>wrong? > >> > >>I need feedbacks ... > >> > >> > As a side note... I've been working on container --> child relationships and > honing them down inside the glade builder... objects may for example have > object delagates that are "owned" and in turn may "own" other delagates... > this is all functional with libglade facilities and the future gtk > builder also > (from the design as of yet...)... this concept of "types of container > relationships" > is also usefull for GtkMenuShell --> GtkMenu for example (not just any > GtkWidget > can be added to a menushell). > > All of that just to say... I cannot count the times I've thought to > myself that > GtkContainer should really just be GContainerIface, and implemented by > whatever interested objects that want to parent other objects... That's interesting, but I wonder what is the runtime penalty of interface lookup compared to normal class structure lookup? Is it really OK to use an interface for this, or is it better just to add a new virtual methods to the GObject class? > I think > that what we need is not really "yet another container api", but a container > api that is a unified front for generic handling of the GTK object > hierarchy at runtime. Actually, for the python language bindings we could use a generic GObject container interface. See http://bugzilla.gnome.org/show_bug.cgi?id=303266 Regards. -- Gustavo J. A. M. Carneiro The universe is always one step beyond logic From alan@clueserver.org Fri Jun 16 12:57:14 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 502C63B0336 for ; Fri, 16 Jun 2006 12:57:14 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06317-07 for ; Fri, 16 Jun 2006 12:57:08 -0400 (EDT) Received: from clueserver.org (216-99-213-120.dsl.aracnet.com [216.99.213.120]) by menubar.gnome.org (Postfix) with ESMTP id 7529F3B041B for ; Fri, 16 Jun 2006 12:54:18 -0400 (EDT) Received: by clueserver.org (Postfix, from userid 500) id 2985BF50BE2; Fri, 16 Jun 2006 09:53:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by clueserver.org (Postfix) with ESMTP id 26461F50BE1; Fri, 16 Jun 2006 09:53:44 -0700 (PDT) Date: Fri, 16 Jun 2006 09:53:44 -0700 (PDT) From: alan X-X-Sender: alan@blackbox.fnordora.org To: Jason Spiro Subject: Re: Imagine: what if points in Bugzilla had a significant effect? In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.45 tagged_above=-999 required=2 tests=[AWL=0.014, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.45 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2006 16:57:14 -0000 On Thu, 15 Jun 2006, Jason Spiro wrote: > Imagine: what if points did something in Bugzilla, like, the more points > you have, the more votes you get? Slashzilla? -- "Waiter! This lambchop tastes like an old sock!" - Sheri Lewis From ntd@users.sourceforge.net Fri Jun 16 14:08:36 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 39BE13B03E1 for ; Fri, 16 Jun 2006 14:08:36 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11017-04 for ; Fri, 16 Jun 2006 14:08:34 -0400 (EDT) Received: from mailout02.albacom.net (mailout02.albacom.net [217.220.34.14]) by menubar.gnome.org (Postfix) with SMTP id E2E913B00E4 for ; Fri, 16 Jun 2006 14:08:33 -0400 (EDT) Received: (qmail 21669 invoked by uid 507); 16 Jun 2006 18:08:08 -0000 Received: from ntd@users.sourceforge.net by mailout02.albacom.net with qmail-scanner (spamassassin: ???. Clear:RC:1(217.221.76.9):SA:0(0.0/15.0):. Processed in 0.841774 secs); 16 Jun 2006 18:08:08 -0000 Received: from unknown (HELO sviluppo.internet.local) (postmaster@effe-gi.it@217.221.76.9) by mailout02.albacom.net with SMTP; 16 Jun 2006 18:08:07 -0000 From: Fontana Nicola Organization: Elettronica EFFE-GI s.n.c. To: Tim Janik Subject: Re: GObject extension propose (GContainer) Date: Fri, 16 Jun 2006 20:44:11 +0000 User-Agent: KMail/1.9.1 References: <200606151101.12868.ntd@users.sourceforge.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200606162044.11716.ntd@users.sourceforge.net> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.526 tagged_above=-999 required=2 tests=[AWL=-0.004, BAYES_00=-2.599, TW_GT=0.077] X-Spam-Score: -2.526 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2006 18:08:36 -0000 > On Thu, 15 Jun 2006, Fontana Nicola wrote: > > Hi all, > > > > I'm a GObject based libraries (for UI purpose and not) user and I often > > need a generic container to derive my own types. In my opinion, I think > > this generic container must be included inside the GObject library ... it > > could be used by a lot of derived libraries providing a common approach. > > > > I published my solution - that is, what I am currently using - on > > sourceforge. > > > > http://sourceforge.net/projects/gcontainer/ > > > > Is it a good idea? Is something planned in this direction? Am I totally > > wrong? > > > > I need feedbacks ... > > hi. your gcontainer-1.0.0 looks like an interesting approach to me, but > i'm not sure it's generally good to put that into stock libgobject. > the main reason is that container needs are probably pretty variable > out there (i've come across at least 4 different gobject container > implementations in free software projects i'm woorking on) and that > both, making too little assumptions in the child/container interface > isn't going to be very helpful, albeit making too many has the > same problem. Some time ago I've started a communication library based on libgobject and I feeled the need of two things: a base object with floating reference and a container. After some time, I started an experimental cairo canvas and I had the same needs. In both cases, no gtk dependency was requested. Briefly, I'm not talking about a container that cover all needs and tastes but instead about "moving the GtkContainer logic and complexity" from gtk to gobject, something similar to what was done for GtkObject and its floating reference. I wrote gcontainer with this in mind (the GContainerable interface is "compatible" with GtkContainer and GChildable with GtkWidget). Anyway, my solution presents some serious problems: I'm misusing the interface to hide as much technical details as possible to the implementing objects. I know it is a huge task but consider this as an idea or a looooong term project: I don't think to be the only one with these needs. > > i guess we could add a link to your project from the libgobject docs > (it should probably have a Contrib section), for people possibly looking > for a GObject container implementation. that way, gcontainer-1.0.0 gets > a chance of being reused and maybe extended to something generally > usefull for GObject applications out there. > > > Nicola > > --- > ciaoTJ Of course I'll be glad to have a link in the gobject documentation. Thank you for your availability. Nicola From tristan.van.berkom@gmail.com Fri Jun 16 14:26:50 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id E38F43B0139 for ; Fri, 16 Jun 2006 14:26:49 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12245-08 for ; Fri, 16 Jun 2006 14:26:49 -0400 (EDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.197]) by menubar.gnome.org (Postfix) with ESMTP id DB55F3B0179 for ; Fri, 16 Jun 2006 14:26:48 -0400 (EDT) Received: by wx-out-0102.google.com with SMTP id i30so517779wxd for ; Fri, 16 Jun 2006 11:26:15 -0700 (PDT) Received: by 10.70.83.9 with SMTP id g9mr4369121wxb; Fri, 16 Jun 2006 11:20:03 -0700 (PDT) Received: from ?66.48.170.68? ( [66.48.170.68]) by mx.gmail.com with ESMTP id h39sm2692858wxd.2006.06.16.11.20.01; Fri, 16 Jun 2006 11:20:03 -0700 (PDT) Message-ID: <4492FA3C.5060106@gmail.com> Date: Fri, 16 Jun 2006 14:36:44 -0400 From: Tristan Van Berkom User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Fontana Nicola Subject: Re: GObject extension propose (GContainer) References: <200606151101.12868.ntd@users.sourceforge.net> <200606162044.11716.ntd@users.sourceforge.net> In-Reply-To: <200606162044.11716.ntd@users.sourceforge.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.497 tagged_above=-999 required=2 tests=[AWL=-0.353, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=1.456, SPF_PASS=-0.001] X-Spam-Score: -1.497 X-Spam-Level: Cc: gtk-devel-list@gnome.org, Tim Janik X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2006 18:26:50 -0000 Fontana Nicola wrote: [...] >I wrote gcontainer with this in mind (the GContainerable interface is >"compatible" with GtkContainer and GChildable with GtkWidget). Anyway, my >solution presents some serious problems: I'm misusing the interface to hide >as much technical details as possible to the implementing objects. > >I know it is a huge task but consider this as an idea or a looooong term >project: I don't think to be the only one with these needs. > > I think you may be overcomplicating things, if for example; the GContainerable or GContainerIface were implemented by GtkContainer; then nothing in GtkContainer derivatives would really have to change (unless the api was drasticly different... but I doubt that). Then this could be extended to other object sets and other needs without having to rewrite large pieces of code. Cheers, -Tristan From behdad.esfahbod@gmail.com Fri Jun 16 15:04:20 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 611EA3B00F8 for ; Fri, 16 Jun 2006 15:04:20 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15384-03 for ; Fri, 16 Jun 2006 15:04:18 -0400 (EDT) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.228]) by menubar.gnome.org (Postfix) with ESMTP id 566D33B007C for ; Fri, 16 Jun 2006 15:04:18 -0400 (EDT) Received: by wr-out-0506.google.com with SMTP id i4so618991wra for ; Fri, 16 Jun 2006 12:03:42 -0700 (PDT) Received: by 10.54.142.9 with SMTP id p9mr3126451wrd; Fri, 16 Jun 2006 11:57:25 -0700 (PDT) Received: from ?192.168.190.5? ( [72.136.156.47]) by mx.gmail.com with ESMTP id 10sm2200187wrl.2006.06.16.11.57.23; Fri, 16 Jun 2006 11:57:24 -0700 (PDT) Subject: Re: Imagine: what if points in Bugzilla had a significant effect? From: Behdad Esfahbod To: gtk-devel-list@gnome.org In-Reply-To: References: Content-Type: text/plain Date: Fri, 16 Jun 2006 14:57:22 -0400 Message-Id: <1150484242.15469.17.camel@home> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 (2.6.1-1.fc5.2) Content-Transfer-Encoding: 7bit Sender: Behdad Esfahbod X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.561 tagged_above=-999 required=2 tests=[AWL=-0.038, BAYES_00=-2.599, SPF_PASS=-0.001, TW_GT=0.077] X-Spam-Score: -2.561 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2006 19:04:20 -0000 On Thu, 2006-06-15 at 15:15 -0400, Jason Spiro wrote: > Imagine: what if points did something in Bugzilla, like, the more points > you have, the more votes you get? > > I think this would encourage people to file more bug reports, both good > bug reports and not-so-good ones. Would that be a net gain or a net loss > for GTK+? It has evolved to be like that already. The more points one has, the more he (or she, in the near future) respects bugs/comments from high-point others. Or at least that's been my experience. behdad > Regards, > Jason Spiro > > -- > Jason Spiro: computer consulting with a smile. > Specializing in Linux: Red Hat AS / ES, Debian, and others. > Serving homes and companies globally via remote access tools. Fair rates. > Just email jasonspiro4@gmail.com or call Skype ID jasonspiro. > > _______________________________________________ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-devel-list -- behdad http://behdad.org/ "Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill" -- Dan Bern, "New American Language" From grakic@devbase.net Fri Jun 16 16:12:39 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 7B9EC3B025A for ; Fri, 16 Jun 2006 16:12:39 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19416-03 for ; Fri, 16 Jun 2006 16:12:38 -0400 (EDT) Received: from mxout-04.mxes.net (mxout-04.mxes.net [205.237.194.35]) by menubar.gnome.org (Postfix) with ESMTP id 07A823B02B4 for ; Fri, 16 Jun 2006 16:12:37 -0400 (EDT) Received: from limun.local (unknown [87.116.163.93]) by smtp.mxes.net (Postfix) with ESMTP id C5307A3292; Fri, 16 Jun 2006 16:11:35 -0400 (EDT) Subject: Re: Imagine: what if points in Bugzilla had a significant effect? From: Goran Rakic To: Jason Spiro In-Reply-To: References: Content-Type: text/plain; charset=utf-8 Date: Fri, 16 Jun 2006 22:11:33 +0200 Message-Id: <1150488693.2273.3.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.6 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, SPF_HELO_PASS=-0.001] X-Spam-Score: -2.6 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2006 20:12:39 -0000 Lary Osterman has a nice writing on this topic titled "Measuring testers by test metrics doesn't." У čet, 15. 06 2006. у 19:15 +0000, Jason Spiro пише: > Imagine: what if points did something in Bugzilla, like, the more points > you have, the more votes you get? > > I think this would encourage people to file more bug reports, both good > bug reports and not-so-good ones. Would that be a net gain or a net loss > for GTK+? > > Regards, > Jason Spiro From ame1@extratech.com Fri Jun 16 17:02:33 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 2F9013B018C for ; Fri, 16 Jun 2006 17:02:33 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21327-05 for ; Fri, 16 Jun 2006 17:02:32 -0400 (EDT) Received: from portal2.extratech.com (portal.extratech.com [67.105.201.210]) by menubar.gnome.org (Postfix) with ESMTP id BB3BD3B01C8 for ; Fri, 16 Jun 2006 17:02:31 -0400 (EDT) Received: from zosma.extratech.com (zosma.extratech.com [192.168.0.41]) by portal2.extratech.com (8.12.11/8.12.11) with ESMTP id k5GL1Quq030485 for ; Fri, 16 Jun 2006 14:01:26 -0700 Subject: Re: GObject extension propose (GContainer) From: "Alan M. Evans" To: Gtk+ Developers In-Reply-To: References: <200606151101.12868.ntd@users.sourceforge.net> <44919246.8060301@gnome.org> <1150456522.5305.12.camel@localhost.localdomain> Content-Type: text/plain; charset=UTF-8 Message-Id: <1150491686.19405.355.camel@zosma.extratech.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 16 Jun 2006 14:01:26 -0700 Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV 0.86.1/1544/Fri Jun 16 02:19:15 2006 on portal2.extratech.com X-Virus-Status: Clean X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.556 tagged_above=-999 required=2 tests=[AWL=0.044, BAYES_00=-2.599] X-Spam-Score: -2.556 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2006 21:02:33 -0000 On Fri, 2006-06-16 at 04:28, Tim Janik wrote: > On Fri, 16 Jun 2006, Gustavo J. A. M. Carneiro wrote: > > > Qui, 2006-06-15 s 13:00 -0400, Tristan Van Berkom escreveu: > > >> All of that just to say... I cannot count the times I've thought to > >> myself that > >> GtkContainer should really just be GContainerIface, and implemented by > >> whatever interested objects that want to parent other objects... > > > > That's interesting, but I wonder what is the runtime penalty of > > interface lookup compared to normal class structure lookup? Is it > > really OK to use an interface for this, or is it better just to add a > > new virtual methods to the GObject class? > > the lookup penalties are negligible. > type node/class lookups and is_a checks are O(1); > interface class lookups and conforms_to checks are O(ld(N)), where > N is the number of interfaces a type node conforms to. Your assertion that the penalties are negligable is not really supported by your response, unless the constant is also known for both orders. From ebassi@gmail.com Fri Jun 16 20:14:03 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 3E95D3B069B for ; Fri, 16 Jun 2006 20:14:03 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28883-03 for ; Fri, 16 Jun 2006 20:14:00 -0400 (EDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.185]) by menubar.gnome.org (Postfix) with ESMTP id 969133B015A for ; Fri, 16 Jun 2006 20:13:59 -0400 (EDT) Received: by nf-out-0910.google.com with SMTP id c2so667512nfe for ; Fri, 16 Jun 2006 17:13:07 -0700 (PDT) Received: by 10.49.72.13 with SMTP id z13mr2277195nfk; Fri, 16 Jun 2006 17:05:51 -0700 (PDT) Received: from ?192.168.1.74? ( [86.136.65.180]) by mx.gmail.com with ESMTP id y23sm3836170nfb.2006.06.16.17.05.51; Fri, 16 Jun 2006 17:05:51 -0700 (PDT) Subject: Re: GTK+ 2.10, the endgame From: Emmanuele Bassi To: gtk-devel-list@gnome.org In-Reply-To: <1150447930.5806.4.camel@localhost.localdomain> References: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> <1150390229.17566.191.camel@cacharro.xalalinux.org> <1150391737.3187.33.camel@dhcp83-98.boston.redhat.com> <1150447930.5806.4.camel@localhost.localdomain> Content-Type: text/plain Date: Sat, 17 Jun 2006 01:05:50 +0100 Message-Id: <1150502750.2668.12.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.34 tagged_above=-999 required=2 tests=[AWL=0.260, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.34 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2006 00:14:03 -0000 Hi Murray, On Fri, 2006-06-16 at 10:52 +0200, Murray Cumming wrote: > I'm also concerned about the recent files stuff. Do we now have > UIManager integration of that? No, and I am to blame because I had less time to spend on fixing this issue. Mostly, I've been stuck on how to implement an action for both the menu and toolbars using the same tag. In the meantime, a nice and clean way to integrate the GtkRecentChooserMenu inside a GtkUIManager is to subclass GtkAction into a custom action that automatically adds a recent chooser menu to the menu item it creates, and use a placeholder in the UI definition (most applications using EggRecentViewUIManager already have that placeholder present). A working example is available here: http://www.gnome.org/~ebassi/test-uimanager.c The action code itself is one hundred lines long and can easily be hidden inside an helper file; it's approximately how GtkRecentAction would be implemented, anyway. I hereby give permission to do whatever you want to do with it. I understand that it's sub-optimal, and hopefully this should really go away once there's an action inside GTK. Ciao, Emmanuele. -- Emmanuele Bassi, E: ebassi@gmail.com W: http://www.emmanuelebassi.net B: http://log.emmanuelebassi.net From behdad.esfahbod@gmail.com Mon Jun 12 17:52:45 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 162C73B02CD for ; Mon, 12 Jun 2006 17:52:45 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00303-05 for ; Mon, 12 Jun 2006 17:52:43 -0400 (EDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.206]) by menubar.gnome.org (Postfix) with ESMTP id 643023B0010 for ; Mon, 12 Jun 2006 17:52:43 -0400 (EDT) Received: by wx-out-0102.google.com with SMTP id h26so956965wxd for ; Mon, 12 Jun 2006 14:51:27 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:subject:from:to:content-type:date:message-id:mime-version:x-mailer:sender; b=HkVpdki0/g3XkGcHUm613LiH99RNWp83QpOiB04twtI9/oyY5QJs7xgUW9ugXUYWTW0FQESua3SiFes9GpwcHFnulMB+jmu6Frg1gjSTz94Z0WNKazKYJCx/0yCrKVvi+sIhO9793kd+R7hBbKFWLBqlIyo5yetvED1gx6HIjnc= Received: by 10.70.36.1 with SMTP id j1mr6891335wxj; Mon, 12 Jun 2006 14:44:52 -0700 (PDT) Received: from to-dhcp26.toronto.redhat.com ( [63.250.163.171]) by mx.gmail.com with ESMTP id h18sm3879342wxd.2006.06.12.14.44.50; Mon, 12 Jun 2006 14:44:51 -0700 (PDT) Subject: Pango-1.13.2 released [unstable] From: Behdad Esfahbod To: Pango Release Lists , gtk-app-devel-list@gnome.org, gtk-devel-list@gnome.org, gtk-i18n-list@gnome.org, gtk-list@gnome.org Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-HZBsNn3KdPR3jVVwB9gO" Date: Mon, 12 Jun 2006 17:44:37 -0400 Message-Id: <1150148678.10765.8.camel@home> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 (2.6.1-1.fc5.2) Sender: Behdad Esfahbod X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.6 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.6 X-Spam-Level: X-Mailman-Approved-At: Fri, 16 Jun 2006 05:27:53 -0400 X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2006 21:52:45 -0000 --=-HZBsNn3KdPR3jVVwB9gO Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Pango-1.13.2 is now available for download at: ftp://ftp.gtk.org/pub/gtk/v2.11/ or http://download.gnome.org/sources/pango/1.13/ 28a6ea9d43c4cd398e7352032f775401 pango-1.13.2.tar.bz2 17d78473c05fece044c6a3b44519b61f pango-1.13.2.tar.gz This is a development release leading up to Pango-1.14.0, which will be released just in time for GNOME-2.16. Notes: * This is unstable development release. While it has had fairly extensive testing, there are likely bugs remaining to be found. This release should not be used in production. * Installing this version will overwrite your existing copy of Pango-1.12. If you have problems, you'll need to reinstall Pango-1.12.x * Bugs should be reported to http://bugzilla.gnome.org. About Pango =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Pango is a library for layout and rendering of text, with an emphasis on internationalization. Pango can be used anywhere that text layout is needed, though most of the work on Pango so far has been done in the context of the GTK+ widget toolkit. Pango forms the core of text and font handling for GTK+-2.x. Pango is designed to be modular; the core Pango layout engine can be used with different font backends. There are three basic backends, with multiple options for rendering with each. - Client side fonts using the FreeType and fontconfig libraries. Rendering can be with with Cairo or Xft libraries, or directly to an in-memory buffer with no additional libraries. - Native fonts on Microsoft Windows. (Optionally using Uniscribe for complex-text handling). Rendering can be done via Cairo or directly using the native Win32 API. - Native fonts on MacOS X, rendering via Cairo. The integration of Pango with Cairo (http://cairographics.org) provides a complete solution with high quality text handling and graphics rendering. Dynamically loaded modules then handle text layout for particular combinations of script and font backend. Pango ships with a wide selection of modules, including modules for Hebrew, Arabic, Hangul, Thai, and a number of Indic scripts. Virtually all of the world's major scripts are supported. As well as the low level layout rendering routines, Pango includes PangoLayout, a high level driver for laying out entire blocks of text, and routines to assist in editing internationalized text. More information about Pango is available from http://www.pango.org/. Pango 1.13.2 depends on version 2.10.0 or newer of the GLib library and version 1.1.2 or newer of the cairo library (if the cairo backend is desired); more information about GLib and cairo can be found at http://www.gtk.org/ and http://cairographics.org/ respectively. Overview of changes between 1.13.1 and 1.13.2 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D * Improved hexbox drawing, and font metrics calculations. * Synthesize italic variants on win32 [Hans Breuer] * New public API: - pango_cairo_show_error_underline - pango_cairo_error_underline_path - pango_font_describe_with_absolute_size * Misc fixes. * Bugs fixed in this release: Bug 326960 =E2=80=93 hex box drawing for win32 and atsui backends of cairo Bug 343717 =E2=80=93 License information in unclear. Bug 343355 =E2=80=93 Add pango_cairo_show_error_underline & pango_cairo_error_underline_path Bug 343966 =E2=80=93 pango Cygwin build fixes Patch from Cygwin Ports maintainer. Bug 343796 =E2=80=93 Italic Chinese character can't be show correctly in Win32. Bug 314114 =E2=80=93 max_x_advance not appropriate for approximate_(char|digit)_width Bug 341138 =E2=80=93 Using TTC font, Gtk2 programs begin to eating big mem= ory and have many cpu usage. Patch from Yong Li. Bug 336153 =E2=80=93 Mark to mark positioning (Lookup Type 6) isn't correc= t when using MarkAttchmentType Patch from Tin Myo Htet. Bug 333984 =E2=80=93 pango_language_from_string improvements Bug 125378 =E2=80=93 Better underline thickness handling Bug 339730 =E2=80=93 Pango needlessly falls back away from a Type 1 font i= nto a TTF font Bug 342562 =E2=80=93 Support absolute sizes in pango_font_description_to/from_string Bug 341922 =E2=80=93 pango should handle more characters as zero width Patch from Roozbeh Pournader Bug 342525 =E2=80=93 With PangoFc and PangoWin32, approximate digit width = is not what it says Bug 342079 =E2=80=93 pangoatsui-private.h missing from release Behdad Esfahbod 12 June 2006 --=-HZBsNn3KdPR3jVVwB9gO Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQBEjeBFn+4E5dNTERURApTwAJ9OvqbaG1xnQYzGPC9u0WPi30b6ggCfXNvZ oFfMwctzkAaKRETc/0aDRj0= =Wl7j -----END PGP SIGNATURE----- --=-HZBsNn3KdPR3jVVwB9gO-- From Klaus.Stengel@asamnet.de Tue Jun 13 06:57:05 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 1BD1E3B008F for ; Tue, 13 Jun 2006 06:57:05 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20572-03 for ; Tue, 13 Jun 2006 06:57:03 -0400 (EDT) Received: from mail.asamnet.de (mail.asamnet.de [194.25.81.18]) by menubar.gnome.org (Postfix) with ESMTP id A52473B000C for ; Tue, 13 Jun 2006 06:57:03 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.asamnet.de (Asamnet e.V. Mailserver) with ESMTP id D01E8A7076 for ; Tue, 13 Jun 2006 12:56:24 +0200 (CEST) Received: from mail.asamnet.de ([127.0.0.1]) by localhost (mail.asamnet.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00951-06 for ; Tue, 13 Jun 2006 12:56:24 +0200 (CEST) Received: from aquarian.nathanet.lan (p5492D6A6.dip.t-dialin.net [84.146.214.166]) by mail.asamnet.de (Asamnet e.V. Mailserver) with ESMTP id 6350FA7066 for ; Tue, 13 Jun 2006 12:56:24 +0200 (CEST) Subject: Pango memory leak in get_ruleset() in modules/basic/basic-fc.c From: Klaus Stengel To: gtk-devel-list@gnome.org Content-Type: text/plain Date: Tue, 13 Jun 2006 12:56:34 +0200 Message-Id: <1150196194.9594.16.camel@aquarian.nathanet.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at asamnet.de X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.464 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.464 X-Spam-Level: X-Mailman-Approved-At: Fri, 16 Jun 2006 05:27:53 -0400 X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2006 10:57:05 -0000 Hi, while working with the diagram editor "dia" I noticed a major memory leak when editing text objects. I tracked this down to a problem in the above function. From what I understand the function looks for an ruleset associated with the given font face and in case there is none, the ruleset is created with pango_ot_ruleset_new() and finally attached to the font face. The g_object_unref() is given as "notification callback" so that the ruleset is destroyed when the font face is finalized. In theory this should work, but unfortunately it doesn't in practice, because pango_ot_ruleset_new() internally references "info" itself, thus creating a circular dependency that keeps the objects alive indefinitely. Unfortunately I don't see an simple solution, except to drop that kind of caching again... Bye, Klaus. P.S.: Please reply to my email address as well, as I'm not subscribed to the list. From newren@gmail.com Sat Jun 17 01:54:29 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 7F2843B066E for ; Sat, 17 Jun 2006 01:54:29 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08609-05 for ; Sat, 17 Jun 2006 01:54:28 -0400 (EDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.198]) by menubar.gnome.org (Postfix) with ESMTP id 354E43B050E for ; Sat, 17 Jun 2006 01:54:28 -0400 (EDT) Received: by wx-out-0102.google.com with SMTP id h26so603851wxd for ; Fri, 16 Jun 2006 22:53:32 -0700 (PDT) Received: by 10.70.24.3 with SMTP id 3mr5192323wxx; Fri, 16 Jun 2006 22:53:32 -0700 (PDT) Received: by 10.70.102.9 with HTTP; Fri, 16 Jun 2006 22:53:32 -0700 (PDT) Message-ID: <51419b2c0606162253pfe0e7edsba8af3f8a1573477@mail.gmail.com> Date: Fri, 16 Jun 2006 23:53:32 -0600 From: "Elijah Newren" To: "Jason Spiro" Subject: Re: Imagine: what if points in Bugzilla had a significant effect? In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.572 tagged_above=-999 required=2 tests=[AWL=0.028, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.572 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2006 05:54:29 -0000 On 6/15/06, Jason Spiro wrote: > Imagine: what if points did something in Bugzilla, like, the more points > you have, the more votes you get? > > I think this would encourage people to file more bug reports, both good > bug reports and not-so-good ones. Would that be a net gain or a net loss > for GTK+? This isn't the right list for this email; bugzilla-devel or filed in bugzilla (against the bugzilla.gnome.org module) would be much better. Thanks, Elijah From timj@gtk.org Sat Jun 17 10:12:11 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id CD5003B00A6 for ; Sat, 17 Jun 2006 10:12:11 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23968-01 for ; Sat, 17 Jun 2006 10:12:08 -0400 (EDT) Received: from holken.mikan.net (holken.mikan.net [83.145.56.183]) by menubar.gnome.org (Postfix) with ESMTP id 34EA13B00D5 for ; Sat, 17 Jun 2006 10:12:07 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by holken.mikan.net (Postfix) with ESMTP id AC6413352A5; Sat, 17 Jun 2006 13:44:21 +0200 (CEST) Received: from holken.mikan.net ([127.0.0.1]) by localhost (holken.mikan.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07456-06; Sat, 17 Jun 2006 13:44:16 +0200 (CEST) Received: from birnet.org (d003096.adsl.hansenet.de [80.171.3.96]) by holken.mikan.net (Postfix) with ESMTP id 7CD8233524F; Sat, 17 Jun 2006 13:44:16 +0200 (CEST) Received: from master.birnet.private (localhost.localdomain [127.0.0.1]) by birnet.org (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k5HBiART015834 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 17 Jun 2006 13:44:11 +0200 Received: (from timj@localhost) by master.birnet.private (8.13.4/8.13.4/Submit) id k5HBhvjK015833; Sat, 17 Jun 2006 13:43:57 +0200 Date: Sat, 17 Jun 2006 13:43:57 +0200 (CEST) From: Tim Janik X-X-Sender: timj@master.birnet.private To: Michalis Giannakidis Subject: Re: gslice allocator: general impresions. In-Reply-To: <200606151827.45477.mgiannakidis@gmail.com> Message-ID: References: <200606151827.45477.mgiannakidis@gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at holken.mikan.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.339 tagged_above=-999 required=2 tests=[AWL=0.048, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, TW_TX=0.077] X-Spam-Score: -2.339 X-Spam-Level: Cc: Gtk+ Developers X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2006 14:12:12 -0000 On Thu, 15 Jun 2006, Michalis Giannakidis wrote: > Dear Glib team, > > I have recently used the glib-glice allocator in a very malloc intensive > application, and I would like to share a few observations I made, with you. > > The typical size I send to g_slice_alloc is 20 and 76 bytes (32 bit build). > The total memory consumed by my application has decreased - which is great! > However it `seems' to me, that this decrease in size is larger for the 64bit > build compared to the 32bit build. (I have modified gslice to align a chunk > to its own size so that I don't have unused memory between chunks eg: request > 20 and get 24...) you mean you've set P2ALIGNMENT to 1 * sizeof(void*) to get better granularity of the slices? have you left NATIVE_MALLOC_PADDING at 2*sizeof(void*) at least? (if not, memory fragmentation on some glibc systems and on all 64bit systems can become etxremely bad). > In my application now I use both g_slice_alloc and malloc.Testing the new > allocator in linux I came accross the following: > After using g_slice_alloc to alloc a great amount of data (eg 1500mb), each of > them being 20 or 76 bytes in size, subsequent calls to malloc(8*1024) or > similar sizes take much longer (the allocation does _not_ got to the swap). this is a magnitude of memory allocations where gslice hasn't been well tested. (my machine only has 1GB of memory for instance). while gslice should perform well even much beyond 1GB, i'd suspect that malloc()/memalign() don't, and thus could result in *some* GSlice slowdown as well. > Also if I chage the min_page_size from 128 to 4096, then the subsequent calls > to malloc(8*1024) or similar sizes take even longer. It takes for ever in the > 64 bit build! maybe due to your alignment tweaks. but maybe also because some malloc() buckets will have even longer lists that way. > Moreover, even with min_page_size set to 128, the calls to malloc take for > ever on a Linux 2.4.20 glibc-2.2.4(glibc up to 2.2.5 has a broken > posix_memalign so I fallback to memalign). broken in what way? > In all of the cases above, malloc responds much faster when the gslice > allocator is turned off. aparently some malloc implementations aren't too good at handling large numbers of page allocations. if modifying GSlice is an option for you, you could try to work around this at the expense of read-only allocation of the memory used by GSlice. to do that, you need to disable the HAVE_COMPLIANT_POSIX_MEMALIGN, HAVE_MEMALIGN and HAVE_VALLOC branches in allocator_memalign() and allocator_memfree() so the read-only malloc()-based fallback allocator is enabled. on 32bit systems, that'll by default allocate 16*4096=64k areas to allocate pages from. by doing: - const guint n_pages = 16; + const guint n_pages = 2560; you'll instead allocate 10MB areas, which should put far less stress on the system malloc() (that way, to fill 1GB, a maximum of 100 allocations are required). > I know I should be providing sample code and test programms here to back up > my observations. I also understand that I should provide execution times > instead of just stating that the calls to malloc take for ever. test programs would be great. allthough this kind of stress test can only be run and examined on a limited set of machines. e.g. the development machines i use have just 1GB and normally have only 30%-40% of free memory to spare for tests during runs like make check -C glib/test ;) > I would like to ask you, if there are any known issues in mixing gslice and > malloc calls in malloc intensive applications. > Any suggested readings would be most welcome. you've already seen the two papers cited in the big comment block at the start of gslice.c? it links to: http://citeseer.ist.psu.edu/bonwick94slab.html http://citeseer.ist.psu.edu/bonwick01magazines.html the first of which describes a kernel page allocator which isn't implemented by GSlice. we use memalign() instead, on the assumption that this is good enough for the vast majority of applications out there. if malloc is too stressed out by the aligned allocations gslice makes in your scenario, implementing this page allocator on top of mmap() and using that as a base allocator for gslice may be another option. > Regards > Michalis --- ciaoTJ From tristan.van.berkom@gmail.com Sat Jun 17 12:09:06 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 2E2D13B013A for ; Sat, 17 Jun 2006 12:09:06 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26133-07 for ; Sat, 17 Jun 2006 12:09:03 -0400 (EDT) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.239]) by menubar.gnome.org (Postfix) with ESMTP id DEE4F3B0061 for ; Sat, 17 Jun 2006 12:09:02 -0400 (EDT) Received: by wr-out-0506.google.com with SMTP id 57so940143wri for ; Sat, 17 Jun 2006 09:07:30 -0700 (PDT) Received: by 10.54.116.7 with SMTP id o7mr3977729wrc; Sat, 17 Jun 2006 09:00:41 -0700 (PDT) Received: from ?66.48.170.156? ( [66.48.170.156]) by mx.gmail.com with ESMTP id 44sm2844499wri.2006.06.17.09.02.05; Sat, 17 Jun 2006 09:02:06 -0700 (PDT) Message-ID: <44942B5F.2090903@gnome.org> Date: Sat, 17 Jun 2006 12:18:39 -0400 User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Alan M. Evans" Subject: Re: GObject extension propose (GContainer) References: <200606151101.12868.ntd@users.sourceforge.net> <44919246.8060301@gnome.org> <1150456522.5305.12.camel@localhost.localdomain> <1150491686.19405.355.camel@zosma.extratech.com> In-Reply-To: <1150491686.19405.355.camel@zosma.extratech.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit From: Tristan Van Berkom X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.208 tagged_above=-999 required=2 tests=[AWL=0.392, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.208 X-Spam-Level: Cc: Gtk+ Developers X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2006 16:09:06 -0000 Alan M. Evans wrote: [...] >>the lookup penalties are negligible. >>type node/class lookups and is_a checks are O(1); >>interface class lookups and conforms_to checks are O(ld(N)), where >>N is the number of interfaces a type node conforms to. >> >> > >Your assertion that the penalties are negligable is not really supported >by your response, unless the constant is also known for both orders. > > From my swift glance at gtype.c, it seems that in the case of an interface, the implementing interface is searched on that class's list of implementing interfaces... so when classes implement hundreds of interfaces it might be a performance hit. I dont think we've yet reached the day that we have to ditch good design and avoid using interfaces because of performance woes, that would be sorry day indeed... (I also dont think GTK+ code will be the only OO code needing major refactoring in those areas too... if these interface lookups weren't negligable) Cheers, -Tristan From chris@gnome-de.org Sat Jun 17 12:59:38 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 89E3F3B00A7 for ; Sat, 17 Jun 2006 12:59:38 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27929-06 for ; Sat, 17 Jun 2006 12:59:35 -0400 (EDT) Received: from mail.bytecamp.net (mail.bytecamp.net [212.204.60.9]) by menubar.gnome.org (Postfix) with SMTP id DF0E93B000D for ; Sat, 17 Jun 2006 12:59:34 -0400 (EDT) Received: (qmail 40076 invoked by uid 85); 17 Jun 2006 16:58:00 -0000 Received: from chris@gnome-de.org by mail.bytecamp.net by uid 88 with qmail-scanner-1.20 (clamscan: 0.88.1 Clear:RC:0(84.150.174.158):. Processed in 0.431315 secs); 17 Jun 2006 16:58:00 -0000 Received: from p5496ae9e.dip0.t-ipconnect.de (HELO ?192.168.123.112?) (chris@gnome-de.org@84.150.174.158) by mail.bytecamp.net with RC4-MD5 encrypted SMTP; 17 Jun 2006 16:57:59 -0000 Subject: GtkFileChooser/GnomeVFS backend still messing up authentication manager? (was: GTK+ 2.10, the endgame) From: Christian Neumair To: Matthias Clasen In-Reply-To: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> References: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> Content-Type: text/plain Date: Sat, 17 Jun 2006 18:57:54 +0200 Message-Id: <1150563475.24534.12.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.586 tagged_above=-999 required=2 tests=[AWL=0.013, BAYES_00=-2.599] X-Spam-Score: -2.586 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2006 16:59:38 -0000 Am Donnerstag, den 15.06.2006, 09:56 -0400 schrieb Matthias Clasen: > I want to have GTK+ 2.10 ready at or immediately after GUADEC. > > I did not declare 2.9.3 api frozen in the release announcement, > because we were still holding the door open for Kris' work on > the new tooltips api. But he has run into some difficulties > with the implementation which will take some time to overcome, > so we have decided to punt this feature and try to get it > into 2.12 early. > > Therefore, I want to consider 2.9.3 api frozen, and take a > look at what still needs to happen before 2.10. Here are some > things I personally would like get worked on (not sure > how much time I can free to look into these myself): > > - I think the async filechooser conversion has caused some > regressions, I noticed that .hidden support seems broken > and autocompletion also behaved badly for me recently. > > - There is a number of FIXMEs and unimplemented bits in > the print code. > > - The print backends need a careful look wrt to memory leaks > and error reporting. > > Are there other important bugs or regressions that need > attention before 2.10 ? Some months ago I investigated an issue where the GtkFileChooser requested file info for all shortcuts and caused mass login requests for all bookmarked remote locations on startup that require login with the GnomeVFS backend. I think the issue was that the file chooser has no way of requesting file info, but signalling at the same time that failure due to unavailability of resources or access constraints isn't fatal, allowing the GnomeVFS backend to not request login data when it is invoked through gtkfilechooserdefault.c:shortcuts_reload_icons. In that case, we may want to fall back to a folder icon. >From reading the GTK+ HEAD source code, the shortcut code still doesn't seem to pass any special flags, so it still seems to be relevant. -- Christian Neumair From gcottenc@gmail.com Sat Jun 17 13:23:55 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 81FC83B000D for ; Sat, 17 Jun 2006 13:23:55 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30389-08 for ; Sat, 17 Jun 2006 13:23:54 -0400 (EDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.197]) by menubar.gnome.org (Postfix) with ESMTP id 01A153B010F for ; Sat, 17 Jun 2006 13:23:53 -0400 (EDT) Received: by wx-out-0102.google.com with SMTP id h26so659270wxd for ; Sat, 17 Jun 2006 10:22:54 -0700 (PDT) Received: by 10.70.116.8 with SMTP id o8mr5867050wxc; Sat, 17 Jun 2006 10:22:54 -0700 (PDT) Received: by 10.70.19.4 with HTTP; Sat, 17 Jun 2006 10:22:54 -0700 (PDT) Message-ID: Date: Sat, 17 Jun 2006 19:22:54 +0200 From: "Guillaume Cottenceau" To: "Matthias Clasen" Subject: Re: GTK+ 2.10, the endgame In-Reply-To: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.6 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.6 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2006 17:23:55 -0000 On 6/15/06, Matthias Clasen wrote: > Therefore, I want to consider 2.9.3 api frozen, and take a Does this mean that http://developer.gnome.org/doc/API/2.0/gtk/ix07.html (and equivalents for gdk, pango, atk) is now a fully stable source for bindings which want to support new features of 2.10? -- Guillaume Cottenceau - http://zarb.org/~gc/ From timj@gtk.org Sun Jun 18 07:31:59 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id D384A3B0316 for ; Sun, 18 Jun 2006 07:31:59 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21403-07 for ; Sun, 18 Jun 2006 07:31:57 -0400 (EDT) Received: from holken.mikan.net (holken.mikan.net [83.145.56.183]) by menubar.gnome.org (Postfix) with ESMTP id 5988B3B09AB for ; Sun, 18 Jun 2006 07:31:57 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by holken.mikan.net (Postfix) with ESMTP id D1B0818461; Sun, 18 Jun 2006 13:31:12 +0200 (CEST) Received: from holken.mikan.net ([127.0.0.1]) by localhost (holken.mikan.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16166-04; Sun, 18 Jun 2006 13:31:09 +0200 (CEST) Received: from birnet.org (d003096.adsl.hansenet.de [80.171.3.96]) by holken.mikan.net (Postfix) with ESMTP id DE31E14571; Sun, 18 Jun 2006 13:31:08 +0200 (CEST) Received: from master.birnet.private (localhost.localdomain [127.0.0.1]) by birnet.org (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k5IBV5n9025330 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 18 Jun 2006 13:31:05 +0200 Received: (from timj@localhost) by master.birnet.private (8.13.4/8.13.4/Submit) id k5IBUuX0025320; Sun, 18 Jun 2006 13:30:56 +0200 Date: Sun, 18 Jun 2006 13:30:56 +0200 (CEST) From: Tim Janik X-X-Sender: timj@master.birnet.private To: Tristan Van Berkom Subject: Re: GObject extension propose (GContainer) In-Reply-To: <44942B5F.2090903@gnome.org> Message-ID: References: <200606151101.12868.ntd@users.sourceforge.net> <44919246.8060301@gnome.org> <1150456522.5305.12.camel@localhost.localdomain> <1150491686.19405.355.camel@zosma.extratech.com> <44942B5F.2090903@gnome.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at holken.mikan.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.378 tagged_above=-999 required=2 tests=[AWL=0.086, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.378 X-Spam-Level: Cc: Gtk+ Developers X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jun 2006 11:32:00 -0000 On Sat, 17 Jun 2006, Tristan Van Berkom wrote: > Alan M. Evans wrote: > [...] > >>> the lookup penalties are negligible. >>> type node/class lookups and is_a checks are O(1); >>> interface class lookups and conforms_to checks are O(ld(N)), where >>> N is the number of interfaces a type node conforms to. >>> >>> >> >> Your assertion that the penalties are negligable is not really supported >> by your response, unless the constant is also known for both orders. >> >> > From my swift glance at gtype.c, it seems that in the case of > an interface, the implementing interface is searched on that class's > list of implementing interfaces... so when classes implement > hundreds of interfaces it might be a performance hit. no there won't be a performance hit. that's because gtype.c uses a binary search for the lookups (as indicated in my last email by the O(ld(N)) complexity). the function used for frequent interface lookups is: gpointer g_type_interface_peek (gpointer instance_class, GType iface_type); and in a nutshell, it does: { TypeNode *node = lookup_type_node_I (class->g_type); // O(1) TypeNode *iface = lookup_type_node_I (iface_type); // O(1) IFaceEntry *entry = type_lookup_iface_entry_L (node, iface); // O(ld(N)) return entry->vtable; } take a look at gtype.c and type_lookup_iface_entry_L() to confirm. using a binary lookup in type_lookup_iface_entry_L() means, lookups in terms of number of interfaces and node visits during the search relate like this: interfaces-per-node | visits-per-lookup 1 | 1.0 2 | 2.0 3 | 2.6 4 | 3.0 5 | 3.3 6 | 3.6 8 | 4.0 16 | 5.0 32 | 6.0 64 | 7.0 128 | 8.0 256 | 9.0 512 | 10.0 1024 | 11.0 65536 | 17.0 262144 | 19.0 1048576 | 21.0 67108864 | 27.0 268435456 | 29.0 2147483648 | 32.0 that is, for all practical purposes, interface lookups are negligible even for many thausands of interfaces implemented per node. and now, please show me the OO system that gets into the hundreds at least... > Cheers, > -Tristan --- ciaoTJ From nicola@effe-gi.it Wed Jun 14 13:42:30 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id D182C3B0003 for ; Wed, 14 Jun 2006 13:42:30 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20727-04 for ; Wed, 14 Jun 2006 13:42:29 -0400 (EDT) Received: from mailout01.albacom.net (mailout01.albacom.net [217.220.34.13]) by menubar.gnome.org (Postfix) with SMTP id 968DC3B0081 for ; Wed, 14 Jun 2006 13:42:28 -0400 (EDT) Received: (qmail 15057 invoked by uid 508); 14 Jun 2006 17:41:43 -0000 Received: from nicola@effe-gi.it by mailout01.albacom.net with qmail-scanner (spamassassin: ???. Clear:RC:1(217.221.76.9):SA:0(0.0/15.0):. Processed in 2.56365 secs); 14 Jun 2006 17:41:43 -0000 Received: from unknown (HELO sviluppo.internet.local) (postmaster@effe-gi.it@217.221.76.9) by mailout01.albacom.net with SMTP; 14 Jun 2006 17:41:40 -0000 From: Fontana Nicola Organization: Elettronica EFFE-GI s.n.c. To: gtk-devel-list@gnome.org Subject: GObject extension propose (GContainer) Date: Wed, 14 Jun 2006 20:17:53 +0000 User-Agent: KMail/1.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200606142017.53525.nicola@effe-gi.it> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.599 tagged_above=-999 required=2 tests=[BAYES_00=-2.599] X-Spam-Score: -2.599 X-Spam-Level: X-Mailman-Approved-At: Sun, 18 Jun 2006 10:56:05 -0400 X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2006 17:42:31 -0000 Hi all, I'm a GObject based libraries (for UI purpose and not) user and I often need a generic container to derive my own types. In my opinion, I think this generic container must be included inside the GObject library ... it could be used by a lot of derived libraries providing a common approach. I published my solution - that is, what I am currently using - on sourceforge. http://sourceforge.net/projects/gcontainer/ Is it a good idea? Is something planned in this direction? Am I totally wrong? I need feedbacks ... Nicola From tristan.van.berkom@gmail.com Sun Jun 18 12:43:27 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 15A9A3B0BF9 for ; Sun, 18 Jun 2006 12:43:27 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03626-01 for ; Sun, 18 Jun 2006 12:43:26 -0400 (EDT) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.225]) by menubar.gnome.org (Postfix) with ESMTP id 1D9F83B0C2D for ; Sun, 18 Jun 2006 12:43:26 -0400 (EDT) Received: by wr-out-0506.google.com with SMTP id 37so824607wra for ; Sun, 18 Jun 2006 09:42:28 -0700 (PDT) Received: by 10.54.153.8 with SMTP id a8mr5030935wre; Sun, 18 Jun 2006 09:42:28 -0700 (PDT) Received: from ?66.48.170.160? ( [66.48.170.160]) by mx.gmail.com with ESMTP id 25sm98918wra.2006.06.18.09.42.26; Sun, 18 Jun 2006 09:42:27 -0700 (PDT) Message-ID: <44958664.4050704@gmail.com> Date: Sun, 18 Jun 2006 12:59:16 -0400 From: Tristan Van Berkom User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Janik Subject: Re: GObject extension propose (GContainer) References: <200606151101.12868.ntd@users.sourceforge.net> <44919246.8060301@gnome.org> <1150456522.5305.12.camel@localhost.localdomain> <1150491686.19405.355.camel@zosma.extratech.com> <44942B5F.2090903@gnome.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.495 tagged_above=-999 required=2 tests=[AWL=-0.351, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=1.456, SPF_PASS=-0.001] X-Spam-Score: -1.495 X-Spam-Level: Cc: Gtk+ Developers X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jun 2006 16:43:27 -0000 Tim Janik wrote: [...] > no there won't be a performance hit. [...] > 268435456 | 29.0 > 2147483648 | 32.0 > > that is, for all practical purposes, interface lookups are negligible > even > for many thausands of interfaces implemented per node. > Those stats look great Tim, sorry for any confusion I may have unwillingly caused in this thread, I think its of great importance that people not fear the GInterface. Cheers, -Tristan From jnoreiko@yahoo.com Sun Jun 18 15:19:51 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id E64063B0114 for ; Sun, 18 Jun 2006 15:19:50 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08166-08 for ; Sun, 18 Jun 2006 15:19:48 -0400 (EDT) Received: from web32405.mail.mud.yahoo.com (web32405.mail.mud.yahoo.com [68.142.207.198]) by menubar.gnome.org (Postfix) with SMTP id 24E153B00E5 for ; Sun, 18 Jun 2006 15:19:47 -0400 (EDT) Received: (qmail 1542 invoked by uid 60001); 18 Jun 2006 19:19:02 -0000 Message-ID: <20060618191902.1540.qmail@web32405.mail.mud.yahoo.com> Received: from [172.213.179.4] by web32405.mail.mud.yahoo.com via HTTP; Sun, 18 Jun 2006 20:19:02 BST Date: Sun, 18 Jun 2006 20:19:02 +0100 (BST) From: Joachim Noreiko Subject: Re: GtkFileChooser/GnomeVFS backend still messing up authentication manager? (was: GTK+ 2.10, the endgame) To: gtk-devel-list@gnome.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.64 tagged_above=-999 required=2 tests=[AWL=-0.688, BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2, DNS_FROM_RFC_WHOIS=1.447] X-Spam-Score: -1.64 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jun 2006 19:19:51 -0000 > Date: Sat, 17 Jun 2006 18:57:54 +0200 > From: Christian Neumair > Subject: GtkFileChooser/GnomeVFS backend still > > Are there other important bugs or regressions that > need > > attention before 2.10 ? Yes! Please could you implement a help button in the filechooser. The documentation is already written and is ready to be linked to. ___________________________________________________________ All new Yahoo! Mail "The new Interface is stunning in its simplicity and ease of use." - PC Magazine http://uk.docs.yahoo.com/nowyoucan.html From alexl@redhat.com Mon Jun 19 05:47:41 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id AB66D3B00A4 for ; Mon, 19 Jun 2006 05:47:41 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02513-02 for ; Mon, 19 Jun 2006 05:47:40 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id 4A6763B0014 for ; Mon, 19 Jun 2006 05:47:40 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5J9Aqqj029011; Mon, 19 Jun 2006 05:10:52 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5J9AqpA029834; Mon, 19 Jun 2006 05:10:52 -0400 Received: from [127.0.0.1] (sebastian-int.corp.redhat.com [172.16.52.221]) by devserv.devel.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5J9Ap4k026344; Mon, 19 Jun 2006 05:10:51 -0400 Subject: Re: Printing and blocking ui From: Alexander Larsson To: Yevgen Muntyan In-Reply-To: <4491AF5A.2050702@tamu.edu> References: <4491AF5A.2050702@tamu.edu> Content-Type: text/plain Date: Mon, 19 Jun 2006 11:10:51 +0200 Message-Id: <1150708251.1962.23.camel@greebo> Mime-Version: 1.0 X-Mailer: Evolution 2.7.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.588 tagged_above=-999 required=2 tests=[AWL=0.013, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.588 X-Spam-Level: Cc: GTK Devel List X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2006 09:47:41 -0000 On Thu, 2006-06-15 at 14:04 -0500, Yevgen Muntyan wrote: > Hi there, > > I print a text document from GtkTextView here. There is a problem > with pagination: pagination is potentially slow, so some sort of progress > dialog should be shown during it. From the other hand, the text buffer > must not be modified during pagination. > How to solve it? Should I show my own modal dialog and make sure user > doesn't modify the buffer, or GtkPrintOperation can take care of it? This is supported now with the Gtkprintoperation::paginate signal and gtk_print_operation_set_show_progress(). > Actually, it would be good to ensure printing blocks the text widget too, > since in this case it wouldn't be necessary to calculate and store all > the pango > layouts in begin-print. Maybe just show a modal dialog between begin-print > and end-print. Locking the editing widget is probably something you have to do yourself. You could also do a snapshot of the data at print time. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl@redhat.com alla@lysator.liu.se He's an otherworldly guerilla ex-con with a secret. She's a scantily clad belly-dancing widow who can talk to animals. They fight crime! From muntyan@tamu.edu Mon Jun 19 06:17:07 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 591293B00FB for ; Mon, 19 Jun 2006 06:17:07 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04050-03 for ; Mon, 19 Jun 2006 06:17:05 -0400 (EDT) Received: from smtp101.vzn.mail.mud.yahoo.com (smtp101.vzn.mail.mud.yahoo.com [68.142.203.45]) by menubar.gnome.org (Postfix) with SMTP id 64EE03B00C8 for ; Mon, 19 Jun 2006 06:17:05 -0400 (EDT) Received: (qmail 1322 invoked from network); 19 Jun 2006 10:16:02 -0000 Received: from unknown (HELO ?192.168.3.9?) (muntyan@verizon.net@71.113.224.59 with plain) by smtp101.vzn.mail.mud.yahoo.com with SMTP; 19 Jun 2006 10:16:01 -0000 Message-ID: <44967960.3060609@tamu.edu> Date: Mon, 19 Jun 2006 05:16:00 -0500 From: Yevgen Muntyan User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20060216 Debian/1.7.12-1.1ubuntu2 X-Accept-Language: en MIME-Version: 1.0 To: Alexander Larsson Subject: Re: Printing and blocking ui References: <4491AF5A.2050702@tamu.edu> <1150708251.1962.23.camel@greebo> In-Reply-To: <1150708251.1962.23.camel@greebo> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.553 tagged_above=-999 required=2 tests=[AWL=0.046, BAYES_00=-2.599] X-Spam-Score: -2.553 X-Spam-Level: Cc: GTK Devel List X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2006 10:17:07 -0000 Alexander Larsson wrote: >On Thu, 2006-06-15 at 14:04 -0500, Yevgen Muntyan wrote: > > >>Hi there, >> >>I print a text document from GtkTextView here. There is a problem >>with pagination: pagination is potentially slow, so some sort of progress >>dialog should be shown during it. From the other hand, the text buffer >>must not be modified during pagination. >>How to solve it? Should I show my own modal dialog and make sure user >>doesn't modify the buffer, or GtkPrintOperation can take care of it? >> >> > >This is supported now with the Gtkprintoperation::paginate signal and >gtk_print_operation_set_show_progress(). > > I don't know how paginate works, but the dialog which shows up during printing is not modal, and it appears only after some delay. I can erase text in the buffer between clicking Print button and the time when progress dialog appears. >>Actually, it would be good to ensure printing blocks the text widget too, >>since in this case it wouldn't be necessary to calculate and store all >>the pango >>layouts in begin-print. Maybe just show a modal dialog between begin-print >>and end-print. >> >> > >Locking the editing widget is probably something you have to do >yourself. You could also do a snapshot of the data at print time. > > Well, locking is easy, but I have to tell user about what's happening. So I guess the solution is to have my own modal progress dialog. Regards, Yevgen From mardy@users.sourceforge.net Mon Jun 19 10:20:09 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id B4CCC3B018E for ; Mon, 19 Jun 2006 10:20:09 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14994-07 for ; Mon, 19 Jun 2006 10:20:06 -0400 (EDT) Received: from smtp008.mail.ukl.yahoo.com (smtp008.mail.ukl.yahoo.com [217.12.11.62]) by menubar.gnome.org (Postfix) with SMTP id 190673B0076 for ; Mon, 19 Jun 2006 10:20:05 -0400 (EDT) Received: (qmail 79361 invoked from network); 19 Jun 2006 14:12:00 -0000 Received: from unknown (HELO pupilla) (mardy78@151.38.48.109 with login) by smtp008.mail.ukl.yahoo.com with SMTP; 19 Jun 2006 14:12:00 -0000 Received: by pupilla (Postfix, from userid 1000) id D59DB6B883; Mon, 19 Jun 2006 16:10:17 +0200 (CEST) Date: Mon, 19 Jun 2006 16:10:17 +0200 From: Alberto Mardegan To: gtk-devel-list@gnome.org Subject: GtkLabel as a child of a windowless widget Message-ID: <20060619141017.GA31744@pupilla> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Accept-Language: it,ia,en,bg,es,fr User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.599 tagged_above=-999 required=2 tests=[BAYES_00=-2.599] X-Spam-Score: -2.599 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2006 14:20:09 -0000 Hi all! I'm creating a Widget based on GtkFrame, with little differences: 1) It's not a container 2) It has the GTK_NO_WINDOW flag set. I'm going to use this widget inside a GtkFixed container, with the only goal of having it paint its frame (and draw its label) on the screen. I want it windowless, so that I can insert other widgets which will appear to be inside it, but which will be actually be owned by the GtkFixed. I know this is not really senseful, but I need such a widget for porting lots of applications from Prolific's Panther GUI to Gtk+. The problem I have, is that the frame label isn't drawn. I'm not sure if there are any operation I should do on it... I just create it, and call gtk_widget_set_parent(). On size_allocate, I'm not sure whether the child's x and y members of the size_allocation struct should be relative to (0,0) or to the parent widget's x and y allocation (since the parent is windowless, too). But this won't work in any case... Any hints? I have no clue. -- Saluti, Mardy http://interlingua.altervista.org Chiacchiera con i tuoi amici in tempo reale! http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com From ame1@extratech.com Mon Jun 19 11:13:35 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 1E8293B03A9 for ; Mon, 19 Jun 2006 11:13:35 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16850-05 for ; Mon, 19 Jun 2006 11:13:32 -0400 (EDT) Received: from portal2.extratech.com (portal.extratech.com [67.105.201.210]) by menubar.gnome.org (Postfix) with ESMTP id BF3D93B0076 for ; Mon, 19 Jun 2006 11:13:30 -0400 (EDT) Received: from zosma.extratech.com (zosma.extratech.com [192.168.0.41]) by portal2.extratech.com (8.12.11/8.12.11) with ESMTP id k5JFBMdd004376; Mon, 19 Jun 2006 08:11:22 -0700 Subject: Re: GObject extension propose (GContainer) From: "Alan M. Evans" To: Tristan Van Berkom In-Reply-To: <44942B5F.2090903@gnome.org> References: <200606151101.12868.ntd@users.sourceforge.net> <44919246.8060301@gnome.org> <1150456522.5305.12.camel@localhost.localdomain> <1150491686.19405.355.camel@zosma.extratech.com> <44942B5F.2090903@gnome.org> Content-Type: text/plain Message-Id: <1150729881.19405.420.camel@zosma.extratech.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 19 Jun 2006 08:11:21 -0700 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.86.1/1549/Sat Jun 17 15:20:39 2006 on portal2.extratech.com X-Virus-Status: Clean X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.551 tagged_above=-999 required=2 tests=[AWL=0.048, BAYES_00=-2.599] X-Spam-Score: -2.551 X-Spam-Level: Cc: Gtk+ Developers X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2006 15:13:35 -0000 On Sat, 2006-06-17 at 09:18, Tristan Van Berkom wrote: > Alan M. Evans wrote: > >>the lookup penalties are negligible. > >>type node/class lookups and is_a checks are O(1); > >>interface class lookups and conforms_to checks are O(ld(N)), where > >>N is the number of interfaces a type node conforms to. > > > >Your assertion that the penalties are negligable is not really supported > >by your response, unless the constant is also known for both orders.> > > > From my swift glance at gtype.c, it seems that in the case of > an interface, the implementing interface is searched on that class's > list of implementing interfaces... so when classes implement > hundreds of interfaces it might be a performance hit. My impression from the original question, which I didn't ask, was not so much about access to a large number of members. If a single variable needs to be examined many times then the performance penalty of a generic interface lookup can add up. In any case, I merely observed an assertion, "the lookup penalties are negligible," and the what appeared to be supporting data, the order of the lookups. This doesn't tell us what the penalty is, only that there is a penalty that gets worse as the number of members increases. Maybe the penalty is negligible, but the data presented didn't say so. That's all I was saying. > I dont think we've yet reached the day that we have to ditch good design > and avoid using interfaces because of performance woes, that would > be sorry day indeed... (I also dont think GTK+ code will be the only OO code > needing major refactoring in those areas too... if these interface > lookups weren't negligable) Indeed. I would certainly not advocate dispensing with good design. In fact, I usually advocate the purist design in my own software, and let Moore's Law fix the performance issues. But some cases still call for direct access for essential performance. I, too, would like to know the performance penalty of the generic interface. Being lazy, I suppose I will set up some experiment to discover it pragmatically. From federico@ximian.com Mon Jun 19 13:28:06 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id B62B13B05EF for ; Mon, 19 Jun 2006 13:28:06 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23010-05 for ; Mon, 19 Jun 2006 13:28:05 -0400 (EDT) Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) by menubar.gnome.org (Postfix) with ESMTP id 163BA3B0809 for ; Mon, 19 Jun 2006 13:28:04 -0400 (EDT) Received: (qmail 29558 invoked from network); 19 Jun 2006 17:27:00 -0000 Received: from localhost (HELO 164-99-120-63.boston.ximian.com) (127.0.0.1) by localhost with SMTP; 19 Jun 2006 17:27:00 -0000 Subject: Re: GtkFileChooser/GnomeVFS backend still messing up authentication manager? (was: GTK+ 2.10, the endgame) From: Federico Mena Quintero To: Joachim Noreiko In-Reply-To: <20060618191902.1540.qmail@web32405.mail.mud.yahoo.com> References: <20060618191902.1540.qmail@web32405.mail.mud.yahoo.com> Content-Type: text/plain Date: Mon, 19 Jun 2006 12:22:31 -0500 Message-Id: <1150737751.8452.77.camel@cacharro.xalalinux.org> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.575 tagged_above=-999 required=2 tests=[AWL=0.024, BAYES_00=-2.599] X-Spam-Score: -2.575 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2006 17:28:06 -0000 On Sun, 2006-06-18 at 20:19 +0100, Joachim Noreiko wrote: > Yes! > Please could you implement a help button in the > filechooser. The documentation is already written and > is ready to be linked to. Do we have a mechanism for this? I see that GtkColorSelectionDialog creates a Help button but hides it by default, and it gives GTK_RESPONSE_HELP when pressed. Does that get captured anywhere so that it can take you to the right help page? Federico From tvb@gnome.org Mon Jun 19 14:23:28 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 8657F3B04AC for ; Mon, 19 Jun 2006 14:23:28 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25353-05 for ; Mon, 19 Jun 2006 14:23:26 -0400 (EDT) Received: from mail.touchtunes.com (mail.touchtunes.com [207.96.182.162]) by menubar.gnome.org (Postfix) with ESMTP id 74D063B03C7 for ; Mon, 19 Jun 2006 14:23:26 -0400 (EDT) Received: from [192.168.0.138] (unknown [192.168.0.138]) by mail.touchtunes.com (Postfix) with ESMTP id 1C61615AAA; Mon, 19 Jun 2006 14:22:06 -0400 (EDT) Message-ID: <4496ED9C.3090009@gnome.org> Date: Mon, 19 Jun 2006 14:31:56 -0400 From: Tristan Van Berkom User-Agent: Mozilla Thunderbird 0.8 (X11/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alberto Mardegan Subject: Re: GtkLabel as a child of a windowless widget References: <20060619141017.GA31744@pupilla> In-Reply-To: <20060619141017.GA31744@pupilla> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.517 tagged_above=-999 required=2 tests=[AWL=0.006, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, TW_GT=0.077] X-Spam-Score: -2.517 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2006 18:23:28 -0000 Alberto Mardegan wrote: [...] > > Any hints? I have no clue. This mailing list is for the discussion of GTK+ development itself, for questions related to writing applications in gtk+ please write to gtk-app-devel-list@gnome.org or gtk-list@gnome.org. FYI: Widgets do not overlap in any containers in gtk+ (I've heard that there is z-ordering in gnomecanvas... you might want to check that out). You can: - Draw the frame yourself in the GtkFixed and place a child label where the frames label would be - Add a fixed as the child widget of the frame (probably what you want anyway). Cheers, -Tristan From federico@ximian.com Mon Jun 19 22:53:07 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 955513B044F for ; Mon, 19 Jun 2006 22:53:07 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18923-10 for ; Mon, 19 Jun 2006 22:53:06 -0400 (EDT) Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) by menubar.gnome.org (Postfix) with ESMTP id E23A03B0301 for ; Mon, 19 Jun 2006 22:53:05 -0400 (EDT) Received: (qmail 30485 invoked from network); 20 Jun 2006 02:52:00 -0000 Received: from localhost (HELO 164-99-120-63.boston.ximian.com) (127.0.0.1) by localhost with SMTP; 20 Jun 2006 02:52:00 -0000 Subject: Re: GtkLabel as a child of a windowless widget From: Federico Mena Quintero To: Alberto Mardegan In-Reply-To: <20060619141017.GA31744@pupilla> References: <20060619141017.GA31744@pupilla> Content-Type: text/plain Date: Mon, 19 Jun 2006 21:47:24 -0500 Message-Id: <1150771645.8452.94.camel@cacharro.xalalinux.org> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.575 tagged_above=-999 required=2 tests=[AWL=0.024, BAYES_00=-2.599] X-Spam-Score: -2.575 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2006 02:53:07 -0000 On Mon, 2006-06-19 at 16:10 +0200, Alberto Mardegan wrote: > Hi all! > I'm creating a Widget based on GtkFrame, with little differences: > 1) It's not a container > 2) It has the GTK_NO_WINDOW flag set. > > I'm going to use this widget inside a GtkFixed container, with the only > goal of having it paint its frame (and draw its label) on the screen. > I want it windowless, so that I can insert other widgets which will > appear to be inside it, but which will be actually be owned by the > GtkFixed. First, can you simply use a GtkFrame inside a GtkFixed, and just not put a child inside the frame? > The problem I have, is that the frame label isn't drawn. I'm not sure if > there are any operation I should do on it... I just create it, and call > gtk_widget_set_parent(). > On size_allocate, I'm not sure whether the child's x and y members of > the size_allocation struct should be relative to (0,0) or to the parent > widget's x and y allocation (since the parent is windowless, too). But > this won't work in any case... Allocations are always with respect to the parent window. So if you have a windowed parent, then inside it a no-window container at (10, 20), and a child of that container which is supposed to be offset (3, 4) pixels from the container's top-left corner, then the child's allocation will be at (13, 24). Federico From mclasen@redhat.com Tue Jun 20 09:27:18 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 4C2873B02C2 for ; Tue, 20 Jun 2006 09:27:18 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17744-01 for ; Tue, 20 Jun 2006 09:27:17 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id D5CE13B0184 for ; Tue, 20 Jun 2006 09:27:16 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5KDQgQV017831 for ; Tue, 20 Jun 2006 09:26:42 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5KDQbkk003106 for ; Tue, 20 Jun 2006 09:26:37 -0400 Received: from golem.boston.redhat.com (golem.boston.redhat.com [172.16.80.24]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id k5KDQbdH021200 for ; Tue, 20 Jun 2006 09:26:37 -0400 Subject: GTK+ team meeting From: Matthias Clasen To: gtk-devel-list@gnome.org Content-Type: text/plain Date: Tue, 20 Jun 2006 09:26:36 -0400 Message-Id: <1150809996.15532.50.camel@golem.boston.redhat.com> Mime-Version: 1.0 X-Mailer: Evolution 2.7.1 (2.7.1-1) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.543 tagged_above=-999 required=2 tests=[AWL=0.058, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.543 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2006 13:27:18 -0000 After a few weeks, we should probably have a team meeting today. The meeting is intended for the GTK+ team, but everybody is welcome to come and listen. The meeting logs will be posted on the GTK+ website (http://www.gtk.org/plan/meetings). Place: irc.gnome.org:#gtk-devel Time: 19:30 UTC (15:30 EDT), Tue, Jun 20 Possible agenda items: - GUADEC meeting - 2.10 + when to release + what needs to be on the 2.10 milestone but isn't ? Matthias From mclasen@redhat.com Tue Jun 20 11:22:11 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 3B32C3B043F; Tue, 20 Jun 2006 11:22:11 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22457-09; Tue, 20 Jun 2006 11:22:09 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id 71CF13B00E7; Tue, 20 Jun 2006 11:22:09 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5KFLLnL004523; Tue, 20 Jun 2006 11:21:21 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5KFLLNA016479; Tue, 20 Jun 2006 11:21:21 -0400 Received: from golem.boston.redhat.com (golem.boston.redhat.com [172.16.80.24]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id k5KFLKdH032719; Tue, 20 Jun 2006 11:21:20 -0400 Subject: GLib 2.11.4 released From: Matthias Clasen To: gnome-announce-list@gnome.org, gtk-devel-list@gnome.org, gtk-list@gnome.org, gtk-app-devel-list@gnome.org Content-Type: text/plain Date: Tue, 20 Jun 2006 11:21:20 -0400 Message-Id: <1150816880.15532.58.camel@golem.boston.redhat.com> Mime-Version: 1.0 X-Mailer: Evolution 2.7.1 (2.7.1-1) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.543 tagged_above=-999 required=2 tests=[AWL=0.058, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.543 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: gnome-hackers@gnome.org List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2006 15:22:11 -0000 GLib 2.11.4 is now available for download at: ftp://ftp.gtk.org/pub/gtk/v2.11/ http://ftp.gnome.org/pub/GNOME/sources/glib/2.11/ glib-2.11.4.tar.bz2 md5sum: 9d3a94baa4bfcd9a579b45eea6de3a8c glib-2.11.4.tar.gz md5sum: f7768bc7ed524c6b40cb87daccb6c2b2 This is a development release leading up to GLib 2.12. Notes: * This is unstable development release. While it has had a bit of testing, there are certainly plenty of bugs remaining to be found. This release should not be used in production. * Installing this version will overwrite your existing copy of GLib 2.10. If you have problems, you'll need to reinstall GLib 2.10. * GLib 2.12 will be source and binary compatible with the GLib 2.10.x series (for some caveats, see the README). At this point, the API additions in the 2.11.x series are finished. * Bugs should be reported to http://bugzilla.gnome.org. About GLib ========== GLib is the low-level core library that forms the basis for projects such as GTK+ and GNOME. It provides data structure handling for C, portability wrappers, and interfaces for such runtime functionality as an event loop, threads, dynamic loading, and an object system. More information about GLib is available at: http://www.gtk.org/ An installation guide for the GTK+ libraries, including GLib, can be found at: http://developer.gnome.org/doc/API/2.0/gtk/gtk-building.html Overview of Changes from GLib 2.11.3 to GLib 2.11.4 =================================================== * GBookmarkFile: - g_bookmark_file_remove_item returns a boolean * g_mkstemp accepts the XXXXXX in the middle of the template * Bugs fixed: 344868 g_key_file_to_data should separate groups * Updated translations (de,es,fr,gu,hi,ko,th) A list of all bugs fixed in this release can be found at: http://bugzilla.gnome.org/buglist.cgi?bug_id=344868 Thanks to everybody who has contributed to this release, in the form of bug reports or patches: Emmanuele Bassi, Christian Persch, Federico Mena Quintero Matthias Clasen June 20, 2006 From mgiannakidis@gmail.com Mon Jun 19 08:23:48 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id E62893B0AAF for ; Mon, 19 Jun 2006 08:23:47 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10711-01 for ; Mon, 19 Jun 2006 08:23:44 -0400 (EDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.191]) by menubar.gnome.org (Postfix) with ESMTP id E721A3B089A for ; Mon, 19 Jun 2006 08:23:43 -0400 (EDT) Received: by nf-out-0910.google.com with SMTP id x30so1070652nfb for ; Mon, 19 Jun 2006 05:22:35 -0700 (PDT) Received: by 10.48.14.1 with SMTP id 1mr1206423nfn; Mon, 19 Jun 2006 05:16:27 -0700 (PDT) Received: from ?213.140.137.120? ( [213.140.137.120]) by mx.gmail.com with ESMTP id d2sm4750763nfe.2006.06.19.05.16.26; Mon, 19 Jun 2006 05:16:26 -0700 (PDT) From: Michalis Giannakidis To: gtk-devel-list@gnome.org Subject: Re: gslice allocator: general impresions. Date: Mon, 19 Jun 2006 15:20:48 +0300 User-Agent: KMail/1.8.3 References: <200606151827.45477.mgiannakidis@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200606191520.48220.mgiannakidis@gmail.com> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.526 tagged_above=-999 required=2 tests=[AWL=-0.002, BAYES_00=-2.599, SPF_PASS=-0.001, TW_TX=0.077] X-Spam-Score: -2.526 X-Spam-Level: X-Mailman-Approved-At: Tue, 20 Jun 2006 12:30:13 -0400 X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2006 12:23:48 -0000 Dear Tim > > (I have modified gslice > > to align a chunk to its own size so that I don't have unused memory > > between chunks eg: request 20 and get 24...) > > you mean you've set P2ALIGNMENT to 1 * sizeof(void*) to get better > granularity of the slices? have you left NATIVE_MALLOC_PADDING at > 2*sizeof(void*) at least? (if not, memory fragmentation on some glibc > systems and on all 64bit systems can become etxremely bad). > I didn't change P2ALIGNMENT . I modified SLAB_INDEX to (asize - 1), SLAB_CHUNK_SIZE to (ix + 1) I also modified P2ALIGN to (size) for all occurances of P2ALIGN except for SLAB_INFO_SIZE. I understand that this will create different memory pools for each size I alloc for, but this is accpeted since I only call g_slice_alloc for two sizes. The tweak seem to be OK since I don't get any segfaults. > maybe due to your alignment tweaks. but maybe also because some malloc() > buckets will have even longer lists that way. > The slowdown also occurred without the alignment tweaks. My understanding is that it is a general malloc slowdown that occurres of the many small mallocs done in the application plus the many larger mallocs done by the gslice allocator. I have read the references available in the gslice allocator comments and were very helpful. What I am looking for know is some sort of comparisons in memory usage and speed in applications changing from malloc to gslice. Also, any tweaks in the gslice allocation sizes providing a more responsive malloc would be great! Any suggestions would be very welcome. Thank you very much. Michalis -- Michalis Giannakidis From mclasen@redhat.com Wed Jun 21 09:13:22 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C2BA53B1007 for ; Wed, 21 Jun 2006 09:13:22 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07614-06 for ; Wed, 21 Jun 2006 09:13:21 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id E02C63B0FE5 for ; Wed, 21 Jun 2006 09:13:20 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5LDDKUh027657; Wed, 21 Jun 2006 09:13:20 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5LDDJnE017553; Wed, 21 Jun 2006 09:13:19 -0400 Received: from golem.boston.redhat.com (golem.boston.redhat.com [172.16.80.24]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id k5LDDJdH018065; Wed, 21 Jun 2006 09:13:19 -0400 Subject: Re: Fwd: GTK+ 2.10, the endgame From: Matthias Clasen To: Guillaume Cottenceau In-Reply-To: References: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> Content-Type: text/plain Date: Wed, 21 Jun 2006 09:13:19 -0400 Message-Id: <1150895599.15532.80.camel@golem.boston.redhat.com> Mime-Version: 1.0 X-Mailer: Evolution 2.7.1 (2.7.1-1) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.506 tagged_above=-999 required=2 tests=[AWL=0.018, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, TW_GT=0.077] X-Spam-Score: -2.506 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2006 13:13:23 -0000 On Wed, 2006-06-21 at 08:38 +0200, Guillaume Cottenceau wrote: > Hi Matthias, > > Could you just drop a line on the list about this question? > > Thanks in advance. > > ---------- Forwarded message ---------- > From: Guillaume Cottenceau > Date: Jun 17, 2006 7:22 PM > Subject: Re: GTK+ 2.10, the endgame > To: Matthias Clasen > Cc: gtk-devel-list@gnome.org > > > On 6/15/06, Matthias Clasen wrote: > > Therefore, I want to consider 2.9.3 api frozen, and take a > > Does this mean that > http://developer.gnome.org/doc/API/2.0/gtk/ix07.html (and equivalents > for gdk, pango, atk) is now a fully stable source for bindings which > want to support new features of 2.10? > > -- > Guillaume Cottenceau - http://zarb.org/~gc/ > The online documentation is still at 2.9.2. I hope to find time to update it to 2.9.4 before leaving for GUADEC tomorrow. A small number of API additions turned out to be necessary in the lowlevel printing apis after 2.9.3: gtk_enumerate_printers GTK_PRINT_CAPABILITY_CAN_GENERATE_PS GTK_PRINT_SETTINGS_OUTPUT_FILE_FORMAT GTK_PRINT_SETTINGS_OUTPUT_URI Furthermore, GTK_PRINT_SETTINGS_PRINT_TO_FILE was found to be unused and removed, together with its setter and getter. Matthias From mclasen@redhat.com Wed Jun 21 13:35:58 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id EE5983B046D for ; Wed, 21 Jun 2006 13:35:57 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25325-06 for ; Wed, 21 Jun 2006 13:35:56 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id 7ACFF3B02CE for ; Wed, 21 Jun 2006 13:35:56 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5LHZtpq012200 for ; Wed, 21 Jun 2006 13:35:55 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5LHZthC009595 for ; Wed, 21 Jun 2006 13:35:55 -0400 Received: from golem.boston.redhat.com (golem.boston.redhat.com [172.16.80.24]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id k5LHZtdH019718 for ; Wed, 21 Jun 2006 13:35:55 -0400 Subject: Looking beyond 2.10 From: Matthias Clasen To: gtk-devel-list@gnome.org Content-Type: text/plain Date: Wed, 21 Jun 2006 13:35:55 -0400 Message-Id: <1150911355.15532.100.camel@golem.boston.redhat.com> Mime-Version: 1.0 X-Mailer: Evolution 2.7.1 (2.7.1-1) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.545 tagged_above=-999 required=2 tests=[AWL=0.056, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.545 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2006 17:35:58 -0000 So, with GTK+ 2.10 on the finish line, I tried to make a quick list of things we may want to look at for 2.12, as input to GUADEC discussions. Patches almost ready to go in - libglade integration - new tooltips api Stuff that needs more work - introspection - international calendar support Stuff that we need to figure out - canvas - libsexy cherrypicking ? (Of course, bugzilla has an endless supply of feature requests and bugs that one can work on, these are just the things that came to my mind first) Matthias From hfiguiere@teaser.fr Wed Jun 21 15:04:27 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C0B713B00F6 for ; Wed, 21 Jun 2006 15:04:27 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31064-02 for ; Wed, 21 Jun 2006 15:04:19 -0400 (EDT) Received: from xandros.com (smtp1.xandros.com [209.87.238.70]) by menubar.gnome.org (Postfix) with ESMTP id 873C83B02DA for ; Wed, 21 Jun 2006 15:04:14 -0400 (EDT) Received: from [172.16.1.95] (unknown [209.87.238.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by xandros.com (Postfix) with ESMTP id 09337A030 for ; Wed, 21 Jun 2006 15:04:13 -0400 (EDT) Message-ID: <4499982C.1010004@teaser.fr> Date: Wed, 21 Jun 2006 15:04:12 -0400 From: Hubert Figuiere User-Agent: Thunderbird 1.5.0.4 (X11/20060615) MIME-Version: 1.0 To: gtk-devel-list@gnome.org Subject: Re: Looking beyond 2.10 References: <1150911355.15532.100.camel@golem.boston.redhat.com> In-Reply-To: <1150911355.15532.100.camel@golem.boston.redhat.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.542 tagged_above=-999 required=2 tests=[AWL=0.057, BAYES_00=-2.599] X-Spam-Score: -2.542 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2006 19:04:27 -0000 Matthias Clasen wrote: > Stuff that needs more work > > - introspection > - international calendar support Complete MacOS X support? I'm about to pick Qt as a toolkit for a personal project just because of that. Hub From matthias.clasen@gmail.com Wed Jun 21 18:26:02 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id A5B4E3B006C for ; Wed, 21 Jun 2006 18:26:02 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09882-05 for ; Wed, 21 Jun 2006 18:26:01 -0400 (EDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.177]) by menubar.gnome.org (Postfix) with ESMTP id 477AE3B00F8 for ; Wed, 21 Jun 2006 18:26:01 -0400 (EDT) Received: by py-out-1112.google.com with SMTP id e30so107107pya for ; Wed, 21 Jun 2006 15:26:00 -0700 (PDT) Received: by 10.35.111.14 with SMTP id o14mr363031pym; Wed, 21 Jun 2006 15:26:00 -0700 (PDT) Received: by 10.35.39.16 with HTTP; Wed, 21 Jun 2006 15:26:00 -0700 (PDT) Message-ID: Date: Wed, 21 Jun 2006 18:26:00 -0400 From: "Matthias Clasen" To: "Hubert Figuiere" Subject: Re: Looking beyond 2.10 In-Reply-To: <4499982C.1010004@teaser.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1150911355.15532.100.camel@golem.boston.redhat.com> <4499982C.1010004@teaser.fr> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.51 tagged_above=-999 required=2 tests=[AWL=0.090, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.51 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2006 22:26:02 -0000 On 6/21/06, Hubert Figuiere wrote: > Matthias Clasen wrote: > > > Stuff that needs more work > > > > - introspection > > - international calendar support > > Complete MacOS X support? Sure, if someone with access to a Mac works on it. I don't have a Mac... > I'm about to pick Qt as a toolkit for a personal project just because of > that. Good luck. Matthias From trowbrds@gmail.com Wed Jun 21 18:29:52 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 103073B0011 for ; Wed, 21 Jun 2006 18:29:52 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10124-04 for ; Wed, 21 Jun 2006 18:29:49 -0400 (EDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.185]) by menubar.gnome.org (Postfix) with ESMTP id B842D3B00E4 for ; Wed, 21 Jun 2006 18:29:48 -0400 (EDT) Received: by nf-out-0910.google.com with SMTP id h2so177759nfe for ; Wed, 21 Jun 2006 15:29:47 -0700 (PDT) Received: by 10.49.81.12 with SMTP id i12mr1011269nfl; Wed, 21 Jun 2006 15:29:47 -0700 (PDT) Received: by 10.49.36.8 with HTTP; Wed, 21 Jun 2006 15:29:47 -0700 (PDT) Message-ID: Date: Wed, 21 Jun 2006 16:29:47 -0600 From: "David Trowbridge" To: gtk-devel-list@gnome.org Subject: Re: Looking beyond 2.10 In-Reply-To: <1150911355.15532.100.camel@golem.boston.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1150911355.15532.100.camel@golem.boston.redhat.com> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.538 tagged_above=-999 required=2 tests=[AWL=0.062, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.538 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2006 22:29:52 -0000 On 6/21/06, Matthias Clasen wrote: > - libsexy cherrypicking ? The icon entry and url labels are probably robust enough (and widely useful enough) to go in. For anything else, it will require some work. -David From mclasen@redhat.com Wed Jun 21 23:10:41 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id AA4213B0172; Wed, 21 Jun 2006 23:10:41 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23030-07; Wed, 21 Jun 2006 23:10:39 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id 63BA23B0008; Wed, 21 Jun 2006 23:10:39 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5M3AclX021506; Wed, 21 Jun 2006 23:10:38 -0400 Received: from lacrosse.corp.redhat.com (lacrosse.corp.redhat.com [172.16.52.154]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5M3AcnM019751; Wed, 21 Jun 2006 23:10:38 -0400 Received: from [172.16.83.158] (vpn83-158.boston.redhat.com [172.16.83.158]) by lacrosse.corp.redhat.com (8.12.11.20060308/8.11.6) with ESMTP id k5M3AciB004961; Wed, 21 Jun 2006 23:10:38 -0400 Subject: GTK+ 2.9.4 released From: Matthias Clasen To: gnome-announce-list@gnome.org, gtk-devel-list@gnome.org, gtk-app-devel-list@gnome.org, gtk-list@gnome.org Content-Type: text/plain Organization: Red Hat Date: Wed, 21 Jun 2006 23:12:41 -0400 Message-Id: <1150945961.4457.2.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.7.3 (2.7.3-2) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.507 tagged_above=-999 required=2 tests=[AWL=0.017, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, TW_GT=0.077] X-Spam-Score: -2.507 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: gnome-hackers@gnome.org List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 03:10:42 -0000 GTK+ 2.9.4 is now available for download at: http://ftp.gnome.org/pub/gnome/sources/gtk+/2.9/ gtk+-2.9.4.tar.bz2 md5sum: c06cf2cfa66485600d90789c9e58f27c gtk+-2.9.4.tar.gz md5sum: e3fefedc7f1a89b66c71c9967168a857 This is a development release leading up to GTK+ 2.10. Notes: * This is unstable development release. There are certainly plenty of bugs remaining to be found. This release should not be used in production. * Installing this version will overwrite your existing copy of GTK+ 2.8. If you have problems, you'll need to reinstall GTK+ 2.8. * GTK+ 2.10 will be source compatible with the GTK+ 2.8 series; the new API additions in GTK+ 2.9.0 are finalized by now. * The ABI version has been bumped from 2.4.0 to 2.10.0, since the filechooser backend interface has been changed. Third-party filechooser backends need to be ported to the new interface. Other third-party modules (input methods, image loaders, etc) just need to be reinstalled in the proper location for GTK+ to find them. * Remaining issues for GTK+ 2.10 can be found with following bugzilla query: http://bugzilla.gnome.org/buglist.cgi?product=gtk%2b&target_milestone=2.10+API+Freeze&target_milestone=2.10+Freeze&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED * Bugs should be reported to http://bugzilla.gnome.org. What is GTK+ ============ GTK+ is a multi-platform toolkit for creating graphical user interfaces. Offering a complete set of widgets, GTK+ is suitable for projects ranging from small one-off tools to complete application suites. GTK+ has been designed from the ground up to support a range of languages, not only C/C++. Using GTK+ from languages such as Perl and Python (especially in combination with the Glade GUI builder) provides an effective method of rapid application development. GTK+ is free software and part of the GNU Project. However, the licensing terms for GTK+, the GNU LGPL, allow it to be used by all developers, including those developing proprietary software, without any license fees or royalties. Where to get more information about GTK+ ======================================== Information about GTK+ including links to documentation can be found at: http://www.gtk.org/ An installation guide for GTK+ 2.x is found at: http://developer.gnome.org/doc/API/2.4/gtk/gtk-building.html Common questions: http://developer.gnome.org/doc/API/2.4/gtk/gtk-question-index.html http://www.gtk.org/faq/ Overview of Changes from GTK+ 2.9.3 to 2.9.4 ============================================ * GtkPrintOperation: - UI improvements in the print dialog - Make printing work without a display connection - Replace "Print to PDF" by "Print to file" that can generate PDF or PostScript - Add a function to the low-level API to enumerate all printers * GtkNotebook tab DND has been improved * GtkProgressbar supports text in activity mode * GtkLabel allows to set the wrap mode * GtkStatusIcon supports transparency * Bugs fixed: 344850 Dragging a GtkTreeViewColumn segfaults when using certain GtkTreeViewColumnDropFunc 342458 Stock menu items without icons are broken in recent GTK+ releases. 335873 notebook DND + popup windows 337882 gtk_progress_bar_set_text() does nothing in activity mode 339456 unix print dialogue help button bug 339702 Make sure printing works without a display 341571 tabs too easily reordered 344074 New Feature: get printer list, and get default print 344743 gtk_targets_include_text() should initialize atoms 344838 Allow func to be NULL in gtk_tree_view_set_search_position_func 344891 GtkPrintOperationPreview signal defs correction 345008 Need updated cairo req 345093 print preview temp file issues 345107 Memory leak in gtk_entry_completion_finalize: User data not freed 345194 gdk_window_set_functions() docs need to be updated 345456 grid-lines property is wrongly registered and get/set. 314278 strings in gtk-update-icon-cache are not marked for translation 344707 size group with widgets in hidden container 344897 Entry completion model NULL handling should be documented 345038 gtk_print_job_set_status' status 345106 dialog button box spacings 345176 GtkIconView doc about drag and drop 345275 doc imporovements for gtk_window_move 345320 Two very similiar strings should be made equal 345321 Add meaning of "shortcut" as translator comment 320034 transparency gtkstatusicon 339592 Add print-to-postscript 344867 custom paper file could use keyfile * Updated translations (cs,de,es,fr,gl,gu,hi,ko,ta,th) A list of all bugs fixed in this release can be found at http://bugzilla.gnome.org/buglist.cgi?bug_id=344838,344743,344867,344891,345008,341571,345038,337882,345093,344707,339456,345107,345275,339702,344074,345320,345321,344897,314278,320034,344850,345194,345176,345106,335873,342458,339592,345456 Thanks to everybody who has contributed to this release, in the form of bug reports or patches: Christian Persch, John Finlay, Federico Mena Quintero, Michael Emmel, Marko Anastasov, Bastien Nocera, Carlos Garnacho, Yevgen Muntyan, Tommi Komulainen, Tim Janik, Christian Weiske, Behdad Esfahbod, Alexander Larsson, Felipe Heidrich, Hendrik Richter, Claudio Saavedra, Dan Winship, Callum McKenzie, John Palmieri, Murray Cumming, Kristian Rietveld June 21, 2006 Matthias Clasen From alexl@redhat.com Thu Jun 22 03:30:13 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id F02D73B04C8 for ; Thu, 22 Jun 2006 03:30:12 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04379-10 for ; Thu, 22 Jun 2006 03:30:11 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id 3177C3B021B for ; Thu, 22 Jun 2006 03:30:11 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5M7UAw1025719 for ; Thu, 22 Jun 2006 03:30:10 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5M7UAI5026706; Thu, 22 Jun 2006 03:30:10 -0400 Received: from [127.0.0.1] (sebastian-int.corp.redhat.com [172.16.52.221]) by devserv.devel.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5M7U90l029917; Thu, 22 Jun 2006 03:30:09 -0400 Subject: Re: Looking beyond 2.10 From: Alexander Larsson To: Matthias Clasen In-Reply-To: <1150911355.15532.100.camel@golem.boston.redhat.com> References: <1150911355.15532.100.camel@golem.boston.redhat.com> Content-Type: text/plain Date: Thu, 22 Jun 2006 09:30:09 +0200 Message-Id: <1150961409.16397.101.camel@greebo> Mime-Version: 1.0 X-Mailer: Evolution 2.7.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.588 tagged_above=-999 required=2 tests=[AWL=0.013, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.588 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 07:30:13 -0000 On Wed, 2006-06-21 at 13:35 -0400, Matthias Clasen wrote: > So, with GTK+ 2.10 on the finish line, I tried to make a quick > list of things we may want to look at for 2.12, as input to > GUADEC discussions. The EditableLable stuff would be nice to have in gtk+: http://live.gnome.org/ProjectRidley/EelEditableLabel This would mean i could drop EelEditableLabel, and i'm sure others need something like this too. For instance, GtkIconView would need it to support renaming. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl@redhat.com alla@lysator.liu.se He's a lonely hunchbacked matador on the edge. She's a radical impetuous single mother who don't take no shit from nobody. They fight crime! From mclasen@redhat.com Thu Jun 22 09:23:37 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 8880D3B0667 for ; Thu, 22 Jun 2006 09:23:37 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30015-09 for ; Thu, 22 Jun 2006 09:23:23 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id 58F4B3B03E5 for ; Thu, 22 Jun 2006 09:23:04 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5MDN3ca016505 for ; Thu, 22 Jun 2006 09:23:03 -0400 Received: from lacrosse.corp.redhat.com (lacrosse.corp.redhat.com [172.16.52.154]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5MDN3dV000789; Thu, 22 Jun 2006 09:23:03 -0400 Received: from [172.16.83.176] (vpn83-176.boston.redhat.com [172.16.83.176]) by lacrosse.corp.redhat.com (8.12.11.20060308/8.11.6) with ESMTP id k5MDN2MM012188; Thu, 22 Jun 2006 09:23:03 -0400 Subject: Re: Looking beyond 2.10 From: Matthias Clasen To: Alexander Larsson In-Reply-To: <1150961409.16397.101.camel@greebo> References: <1150911355.15532.100.camel@golem.boston.redhat.com> <1150961409.16397.101.camel@greebo> Content-Type: text/plain Organization: Red Hat Date: Thu, 22 Jun 2006 09:25:07 -0400 Message-Id: <1150982707.2966.6.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.7.3 (2.7.3-2) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.546 tagged_above=-999 required=2 tests=[AWL=0.055, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.546 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 13:23:37 -0000 On Thu, 2006-06-22 at 09:30 +0200, Alexander Larsson wrote: > On Wed, 2006-06-21 at 13:35 -0400, Matthias Clasen wrote: > > So, with GTK+ 2.10 on the finish line, I tried to make a quick > > list of things we may want to look at for 2.12, as input to > > GUADEC discussions. > > The EditableLable stuff would be nice to have in gtk+: > http://live.gnome.org/ProjectRidley/EelEditableLabel > > This would mean i could drop EelEditableLabel, and i'm sure others need > something like this too. For instance, GtkIconView would need it to > support renaming. > Not that it would not be useful, but GtkIconView uses cell renderers, and already supports editing... From alexl@redhat.com Thu Jun 22 09:33:59 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 9529C3B0748 for ; Thu, 22 Jun 2006 09:33:59 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30708-06 for ; Thu, 22 Jun 2006 09:33:54 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id B4FBD3B0559 for ; Thu, 22 Jun 2006 09:33:54 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5MDXsaJ021314 for ; Thu, 22 Jun 2006 09:33:54 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5MDXrtU004254; Thu, 22 Jun 2006 09:33:53 -0400 Received: from [127.0.0.1] (sebastian-int.corp.redhat.com [172.16.52.221]) by devserv.devel.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5MDXqt9025805; Thu, 22 Jun 2006 09:33:53 -0400 Subject: Re: Looking beyond 2.10 From: Alexander Larsson To: Matthias Clasen In-Reply-To: <1150982707.2966.6.camel@localhost.localdomain> References: <1150911355.15532.100.camel@golem.boston.redhat.com> <1150961409.16397.101.camel@greebo> <1150982707.2966.6.camel@localhost.localdomain> Content-Type: text/plain Date: Thu, 22 Jun 2006 15:33:52 +0200 Message-Id: <1150983232.16397.107.camel@greebo> Mime-Version: 1.0 X-Mailer: Evolution 2.7.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.588 tagged_above=-999 required=2 tests=[AWL=0.013, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.588 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 13:33:59 -0000 On Thu, 2006-06-22 at 09:25 -0400, Matthias Clasen wrote: > On Thu, 2006-06-22 at 09:30 +0200, Alexander Larsson wrote: > > On Wed, 2006-06-21 at 13:35 -0400, Matthias Clasen wrote: > > > So, with GTK+ 2.10 on the finish line, I tried to make a quick > > > list of things we may want to look at for 2.12, as input to > > > GUADEC discussions. > > > > The EditableLable stuff would be nice to have in gtk+: > > http://live.gnome.org/ProjectRidley/EelEditableLabel > > > > This would mean i could drop EelEditableLabel, and i'm sure others need > > something like this too. For instance, GtkIconView would need it to > > support renaming. > > > > Not that it would not be useful, but GtkIconView uses cell renderers, > and already supports editing... How does that handle labels that are several lines long? =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl@redhat.com alla@lysator.liu.se He's a war-weary moralistic waffle chef with nothing left to lose. She's an orphaned red-headed barmaid looking for love in all the wrong places. They fight crime! From mclasen@redhat.com Thu Jun 22 09:48:21 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 98DD03B04F0 for ; Thu, 22 Jun 2006 09:48:21 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31802-05 for ; Thu, 22 Jun 2006 09:48:20 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id DD2613B00DE for ; Thu, 22 Jun 2006 09:48:19 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5MDmJQS027439 for ; Thu, 22 Jun 2006 09:48:19 -0400 Received: from lacrosse.corp.redhat.com (lacrosse.corp.redhat.com [172.16.52.154]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5MDmJB6008537; Thu, 22 Jun 2006 09:48:19 -0400 Received: from [172.16.83.176] (vpn83-176.boston.redhat.com [172.16.83.176]) by lacrosse.corp.redhat.com (8.12.11.20060308/8.11.6) with ESMTP id k5MDmIjF015592; Thu, 22 Jun 2006 09:48:18 -0400 Subject: Re: Looking beyond 2.10 From: Matthias Clasen To: Alexander Larsson In-Reply-To: <1150983232.16397.107.camel@greebo> References: <1150911355.15532.100.camel@golem.boston.redhat.com> <1150961409.16397.101.camel@greebo> <1150982707.2966.6.camel@localhost.localdomain> <1150983232.16397.107.camel@greebo> Content-Type: text/plain Organization: Red Hat Date: Thu, 22 Jun 2006 09:50:23 -0400 Message-Id: <1150984223.2966.10.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.7.3 (2.7.3-2) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.546 tagged_above=-999 required=2 tests=[AWL=0.055, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.546 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 13:48:21 -0000 On Thu, 2006-06-22 at 15:33 +0200, Alexander Larsson wrote: > On Thu, 2006-06-22 at 09:25 -0400, Matthias Clasen wrote: > > On Thu, 2006-06-22 at 09:30 +0200, Alexander Larsson wrote: > > > On Wed, 2006-06-21 at 13:35 -0400, Matthias Clasen wrote: > > > > So, with GTK+ 2.10 on the finish line, I tried to make a quick > > > > list of things we may want to look at for 2.12, as input to > > > > GUADEC discussions. > > > > > > The EditableLable stuff would be nice to have in gtk+: > > > http://live.gnome.org/ProjectRidley/EelEditableLabel > > > > > > This would mean i could drop EelEditableLabel, and i'm sure others need > > > something like this too. For instance, GtkIconView would need it to > > > support renaming. > > > > > > > Not that it would not be useful, but GtkIconView uses cell renderers, > > and already supports editing... > > How does that handle labels that are several lines long? > As well as the treeview does... eventually we'll have to sit down and add multline to GtkEntry... From alexl@redhat.com Thu Jun 22 09:52:23 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 292473B081B for ; Thu, 22 Jun 2006 09:52:23 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32031-08 for ; Thu, 22 Jun 2006 09:52:21 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id 83E8E3B0811 for ; Thu, 22 Jun 2006 09:52:21 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5MDqKud029180 for ; Thu, 22 Jun 2006 09:52:21 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5MDqFg0009757; Thu, 22 Jun 2006 09:52:15 -0400 Received: from [127.0.0.1] (sebastian-int.corp.redhat.com [172.16.52.221]) by devserv.devel.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5MDqE6x027583; Thu, 22 Jun 2006 09:52:14 -0400 Subject: Re: Looking beyond 2.10 From: Alexander Larsson To: Matthias Clasen In-Reply-To: <1150984223.2966.10.camel@localhost.localdomain> References: <1150911355.15532.100.camel@golem.boston.redhat.com> <1150961409.16397.101.camel@greebo> <1150982707.2966.6.camel@localhost.localdomain> <1150983232.16397.107.camel@greebo> <1150984223.2966.10.camel@localhost.localdomain> Content-Type: text/plain Date: Thu, 22 Jun 2006 15:52:14 +0200 Message-Id: <1150984334.16397.110.camel@greebo> Mime-Version: 1.0 X-Mailer: Evolution 2.7.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.588 tagged_above=-999 required=2 tests=[AWL=0.013, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.588 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 13:52:23 -0000 On Thu, 2006-06-22 at 09:50 -0400, Matthias Clasen wrote: > On Thu, 2006-06-22 at 15:33 +0200, Alexander Larsson wrote: > > > How does that handle labels that are several lines long? > > As well as the treeview does... eventually we'll have to sit down > and add multline to GtkEntry... Thats basically what EelEditableLabel is. I'm not sure its better to combine the two into one than having a separate widget for it. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl@redhat.com alla@lysator.liu.se He's a sword-wielding Catholic gangster fleeing from a secret government programme. She's a beautiful mute snake charmer with the power to bend men's minds. They fight crime! From Bill.Haneman@Sun.COM Thu Jun 22 09:59:01 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id A04A33B06B5 for ; Thu, 22 Jun 2006 09:59:01 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32611-04 for ; Thu, 22 Jun 2006 09:58:59 -0400 (EDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by menubar.gnome.org (Postfix) with ESMTP id EC16D3B0487 for ; Thu, 22 Jun 2006 09:58:52 -0400 (EDT) Received: from phys-gadget-1 ([129.156.85.171]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k5MDwpH2016279 for ; Thu, 22 Jun 2006 07:58:52 -0600 (MDT) Received: from conversion-daemon.gadget-mail1.uk.sun.com by gadget-mail1.uk.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0J1900F01LG3TK@gadget-mail1.uk.sun.com> (original mail from Bill.Haneman@Sun.COM) for gtk-devel-list@gnome.org; Thu, 22 Jun 2006 14:58:51 +0100 (BST) Received: from [192.168.1.120] (vpn-129-150-116-130.UK.Sun.COM [129.150.116.130]) by gadget-mail1.uk.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0J1900AYWLI2KV@gadget-mail1.uk.sun.com> for gtk-devel-list@gnome.org; Thu, 22 Jun 2006 14:58:51 +0100 (BST) Date: Thu, 22 Jun 2006 15:00:03 +0100 From: Bill Haneman Subject: GtkTextBuffer serialization formats: why no "text/plain" ? To: gtk-devel-list@gnome.org Message-id: <1150984802.7100.4.camel@linux.site> MIME-version: 1.0 X-Mailer: Ximian Evolution 1.4.6.338 Content-type: text/plain Content-transfer-encoding: 7BIT X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.538 tagged_above=-999 required=2 tests=[AWL=-0.017, BAYES_00=-2.599, TW_GT=0.077, UNPARSEABLE_RELAY=0.001] X-Spam-Score: -2.538 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 13:59:01 -0000 Hi; The new serialize/deserialize API for GtkTextBuffer looks to be very useful to accessibility among other things. I am currently using it to implement AtkStreamableContent, an interface which allows objects with streamable backing data (for instance images, HTML widgets, text containers...) to advertise that fact and stream the data to remote clients such as assistive technologies. However I am somewhat surprised to see in gtk-demo's Hypertext widget that, although there's a serialization format called "application/x-gtk-rich-text", there's no "text/plain". Of course serialization via plain text would not be lossless, but why isn't there a plain text serialization available for all GtkTextBuffer instances? We certainly need it for the accessibility case - otherwise we'll have to fake one in gail, necessitating multiple code paths or at least some odd concatenation of "text/plain" if it is not among those returned by gtk_text_buffer_get_serialize_formats... regards, Bill From ebassi@gmail.com Thu Jun 22 10:02:56 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id D0CCE3B074F for ; Thu, 22 Jun 2006 10:02:56 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00339-10 for ; Thu, 22 Jun 2006 10:02:55 -0400 (EDT) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.171]) by menubar.gnome.org (Postfix) with ESMTP id CC4073B0634 for ; Thu, 22 Jun 2006 10:02:54 -0400 (EDT) Received: by ug-out-1314.google.com with SMTP id o2so482915uge for ; Thu, 22 Jun 2006 07:02:53 -0700 (PDT) Received: by 10.78.151.3 with SMTP id y3mr507751hud; Thu, 22 Jun 2006 07:02:53 -0700 (PDT) Received: from ?192.168.1.70? ( [86.136.65.180]) by mx.gmail.com with ESMTP id 8sm364730hug.2006.06.22.07.02.53; Thu, 22 Jun 2006 07:02:53 -0700 (PDT) Subject: Re: Looking beyond 2.10 From: Emmanuele Bassi To: gtk-devel-list@gnome.org In-Reply-To: <1150911355.15532.100.camel@golem.boston.redhat.com> References: <1150911355.15532.100.camel@golem.boston.redhat.com> Content-Type: text/plain Date: Thu, 22 Jun 2006 15:02:51 +0100 Message-Id: <1150984971.5346.12.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.362 tagged_above=-999 required=2 tests=[AWL=0.238, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.362 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 14:02:57 -0000 Hi; On Wed, 2006-06-21 at 13:35 -0400, Matthias Clasen wrote: > So, with GTK+ 2.10 on the finish line, I tried to make a quick > list of things we may want to look at for 2.12, as input to > GUADEC discussions. > Stuff that needs more work > > - introspection > - international calendar support - use GBookmarkFile inside GtkFileSystem and add recent files inside GtkFileChooser. > Stuff that we need to figure out > > - canvas > - libsexy cherrypicking ? - EggIconChooser. AFAIR there were issues but I can't find any pointer to those. Also, I'd like to see the thumbnailing code added to GTK, and the thumbnail helpers changed from using GConf to a lower level position in the stack. Ciao, Emmanuele. -- Emmanuele Bassi, E: ebassi@gmail.com W: http://www.emmanuelebassi.net B: http://log.emmanuelebassi.net From kris@babi-pangang.org Thu Jun 22 10:07:12 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 9474E3B07EB for ; Thu, 22 Jun 2006 10:07:12 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00887-04 for ; Thu, 22 Jun 2006 10:07:09 -0400 (EDT) Received: from nasi-goreng.babi-pangang.org (nasi-goreng.babi-pangang.org [83.166.137.20]) by menubar.gnome.org (Postfix) with ESMTP id ECDDC3B07F0 for ; Thu, 22 Jun 2006 10:07:08 -0400 (EDT) Received: by nasi-goreng.babi-pangang.org (Postfix, from userid 1000) id 5DB383DCA0; Thu, 22 Jun 2006 16:07:04 +0200 (CEST) Date: Thu, 22 Jun 2006 16:07:04 +0200 From: Kristian Rietveld To: Matthias Clasen Subject: Re: Looking beyond 2.10 Message-ID: <20060622140703.GA15275@babi-pangang.org> References: <1150911355.15532.100.camel@golem.boston.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1150911355.15532.100.camel@golem.boston.redhat.com> User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.565 tagged_above=-999 required=2 tests=[AWL=0.034, BAYES_00=-2.599] X-Spam-Score: -2.565 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 14:07:12 -0000 On Wed, Jun 21, 2006 at 01:35:55PM -0400, Matthias Clasen wrote: > Stuff that needs more work > > - introspection > - international calendar support (I want to try to do multiple row DnD in GtkTreeView for real now. But I won't promise anything :) -kris. From jnoreiko@yahoo.com Thu Jun 22 10:28:15 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id CEBD43B0110 for ; Thu, 22 Jun 2006 10:28:15 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01906-05 for ; Thu, 22 Jun 2006 10:28:15 -0400 (EDT) Received: from web32406.mail.mud.yahoo.com (web32406.mail.mud.yahoo.com [68.142.207.199]) by menubar.gnome.org (Postfix) with SMTP id DCE8B3B0251 for ; Thu, 22 Jun 2006 10:28:14 -0400 (EDT) Received: (qmail 59923 invoked by uid 60001); 22 Jun 2006 14:28:14 -0000 Message-ID: <20060622142814.59921.qmail@web32406.mail.mud.yahoo.com> Received: from [172.203.129.193] by web32406.mail.mud.yahoo.com via HTTP; Thu, 22 Jun 2006 15:28:14 BST Date: Thu, 22 Jun 2006 15:28:14 +0100 (BST) From: Joachim Noreiko Subject: Re: Looking beyond 2.10 To: gtk-devel-list@gnome.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-0.405 tagged_above=-999 required=2 tests=[AWL=-1.612, BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2, DNS_FROM_RFC_WHOIS=1.447, RCVD_IN_SORBS_SOCKS=2.159] X-Spam-Score: -0.405 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 14:28:16 -0000 > Date: Wed, 21 Jun 2006 13:35:55 -0400 > From: Matthias Clasen > Subject: Looking beyond 2.10 > So, with GTK+ 2.10 on the finish line, I tried to > make a quick > list of things we may want to look at for 2.12, as > input to > GUADEC discussions. > > (Of course, bugzilla has an endless supply of > feature requests > and bugs that one can work on, these are just the > things that > came to my mind first) > I feel like I'm talking to myself here, but please could someone look at adding a help button to the fileselector. ___________________________________________________________ Inbox full of spam? Get leading spam protection and 1GB storage with All New Yahoo! Mail. http://uk.docs.yahoo.com/nowyoucan.html From tristan.van.berkom@gmail.com Thu Jun 22 13:10:30 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id A0DBC3B0690 for ; Thu, 22 Jun 2006 13:10:30 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12156-06 for ; Thu, 22 Jun 2006 13:10:28 -0400 (EDT) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.225]) by menubar.gnome.org (Postfix) with ESMTP id 215163B0137 for ; Thu, 22 Jun 2006 13:10:28 -0400 (EDT) Received: by wr-out-0506.google.com with SMTP id i12so437125wra for ; Thu, 22 Jun 2006 10:10:27 -0700 (PDT) Received: by 10.54.153.18 with SMTP id a18mr2404093wre; Thu, 22 Jun 2006 10:10:27 -0700 (PDT) Received: from ?66.48.170.242? ( [66.48.170.242]) by mx.gmail.com with ESMTP id 7sm1704382wrl.2006.06.22.10.10.22; Thu, 22 Jun 2006 10:10:27 -0700 (PDT) Message-ID: <449AD300.3030809@gnome.org> Date: Thu, 22 Jun 2006 13:27:28 -0400 User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mclasen@redhat.com Subject: Re: Looking beyond 2.10 References: <1150911355.15532.100.camel@golem.boston.redhat.com> <1150984971.5346.12.camel@localhost> In-Reply-To: <1150984971.5346.12.camel@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit From: Tristan Van Berkom X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.216 tagged_above=-999 required=2 tests=[AWL=0.384, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.216 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 17:10:30 -0000 Emmanuele Bassi wrote: >Hi; > >On Wed, 2006-06-21 at 13:35 -0400, Matthias Clasen wrote: > > >>So, with GTK+ 2.10 on the finish line, I tried to make a quick >>list of things we may want to look at for 2.12, as input to >>GUADEC discussions. >> >> Heh, unfortunately I wont be at GAUDEC to discuss any of this (which I am sure would be a great experience), so I'll do my best from the mailing lists and irc to tag along :) In light of the new Gtk Builder code getting in, I would like to propose that we depricate UIManager completely in favour of the Gtk Builder and provide a unified front for the creation of GObjects parsed from ui descriptions (or whatever the new "glade file" is to be called). My proposals to address issues of UI merging and handling of GtkActions are described in detail in these to emails: http://mail.gnome.org/archives/gtk-devel-list/2006-May/msg00157.html http://mail.gnome.org/archives/gtk-devel-list/2006-May/msg00166.html Please let me know your thoughts on the proposition and design, if accepted; I am sure I can get all this "ui merging/action subscription" stuff working properly inside of one month... hopefully leaving time enough for it to mature before 2.12. Cheers, -Tristan From sven@gimp.org Thu Jun 22 14:23:14 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C09883B062A for ; Thu, 22 Jun 2006 14:23:14 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16777-05 for ; Thu, 22 Jun 2006 14:23:11 -0400 (EDT) Received: from buzzloop.caiaq.de (buzzloop.caiaq.de [212.112.241.133]) by menubar.gnome.org (Postfix) with ESMTP id 26D1A3B05BF for ; Thu, 22 Jun 2006 14:23:08 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by buzzloop.caiaq.de (Postfix) with ESMTP id 194427F402E; Thu, 22 Jun 2006 20:23:10 +0200 (CEST) Received: from buzzloop.caiaq.de ([127.0.0.1]) by localhost (buzzloop [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11007-03; Thu, 22 Jun 2006 20:23:09 +0200 (CEST) Received: from [192.168.3.158] (i577B6734.versanet.de [87.123.103.52]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by buzzloop.caiaq.de (Postfix) with ESMTP id A11AD7F4024; Thu, 22 Jun 2006 20:23:09 +0200 (CEST) Subject: Re: Looking beyond 2.10 From: Sven Neumann To: Joachim Noreiko In-Reply-To: <20060622142814.59921.qmail@web32406.mail.mud.yahoo.com> References: <20060622142814.59921.qmail@web32406.mail.mud.yahoo.com> Content-Type: text/plain Date: Thu, 22 Jun 2006 20:22:49 +0200 Message-Id: <1151000569.12681.22.camel@bender> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.692 tagged_above=-999 required=2 tests=[AWL=0.907, BAYES_00=-2.599] X-Spam-Score: -1.692 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 18:23:15 -0000 Hi, On Thu, 2006-06-22 at 15:28 +0100, Joachim Noreiko wrote: > I feel like I'm talking to myself here, but please > could someone look at adding a help button to the fileselector. GIMP has done that for quite a while already, so there's nothing that would keep an application from adding a Help button to the file-chooser. What's the point of adding one by default? By default it won't be connected to anything useful and what good is a help button that does nothing when the user clicks it? Sven From murrayc@murrayc.com Thu Jun 22 14:45:17 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 2C2CB3B0649 for ; Thu, 22 Jun 2006 14:45:17 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18110-06 for ; Thu, 22 Jun 2006 14:45:13 -0400 (EDT) Received: from swarthymail-a1.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by menubar.gnome.org (Postfix) with ESMTP id A79253B083A for ; Thu, 22 Jun 2006 14:45:12 -0400 (EDT) Received: from noname (p5497EA12.dip.t-dialin.net [84.151.234.18]) by swarthymail-a1.dreamhost.com (Postfix) with ESMTP id 71BF690FA6; Thu, 22 Jun 2006 11:45:00 -0700 (PDT) Subject: Re: GTK+ 2.10, the endgame From: Murray Cumming To: Emmanuele Bassi In-Reply-To: <1150502750.2668.12.camel@localhost> References: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> <1150390229.17566.191.camel@cacharro.xalalinux.org> <1150391737.3187.33.camel@dhcp83-98.boston.redhat.com> <1150447930.5806.4.camel@localhost.localdomain> <1150502750.2668.12.camel@localhost> Content-Type: text/plain Date: Thu, 22 Jun 2006 20:44:54 +0200 Message-Id: <1151001894.5804.33.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.477 tagged_above=-999 required=2 tests=[AWL=0.122, BAYES_00=-2.599] X-Spam-Score: -2.477 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 18:45:17 -0000 On Sat, 2006-06-17 at 01:05 +0100, Emmanuele Bassi wrote: > Hi Murray, > > On Fri, 2006-06-16 at 10:52 +0200, Murray Cumming wrote: > > I'm also concerned about the recent files stuff. Do we now have > > UIManager integration of that? > > No, and I am to blame because I had less time to spend on fixing this > issue. > > Mostly, I've been stuck on how to implement an action for both the menu > and toolbars using the same tag. In the meantime, a nice and clean way > to integrate the GtkRecentChooserMenu inside a GtkUIManager is to > subclass GtkAction into a custom action that automatically adds a recent > chooser menu to the menu item it creates, and use a placeholder in the > UI definition (most applications using EggRecentViewUIManager already > have that placeholder present). > > A working example is available here: > > http://www.gnome.org/~ebassi/test-uimanager.c > > The action code itself is one hundred lines long and can easily be > hidden inside an helper file; it's approximately how GtkRecentAction > would be implemented, anyway. I hereby give permission to do whatever > you want to do with it. > > I understand that it's sub-optimal, and hopefully this should really go > away once there's an action inside GTK. Do you feel that the existing API might need to be changed to add this to a future version of GTK+? For instance, would it need need existing classes to implement new interfaces, or add new signals? -- Murray Cumming murrayc@murrayc.com www.murrayc.com www.openismus.com From ebassi@gmail.com Thu Jun 22 15:19:39 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id F26233B077F for ; Thu, 22 Jun 2006 15:19:38 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20426-04 for ; Thu, 22 Jun 2006 15:19:35 -0400 (EDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.186]) by menubar.gnome.org (Postfix) with ESMTP id 2A7653B062A for ; Thu, 22 Jun 2006 15:19:35 -0400 (EDT) Received: by nf-out-0910.google.com with SMTP id h2so304101nfe for ; Thu, 22 Jun 2006 12:19:34 -0700 (PDT) Received: by 10.48.242.3 with SMTP id p3mr1697803nfh; Thu, 22 Jun 2006 12:19:34 -0700 (PDT) Received: from ?192.168.1.70? ( [86.136.65.180]) by mx.gmail.com with ESMTP id z73sm2097413nfb.2006.06.22.12.19.33; Thu, 22 Jun 2006 12:19:33 -0700 (PDT) Subject: Re: GTK+ 2.10, the endgame From: Emmanuele Bassi To: Murray Cumming In-Reply-To: <1151001894.5804.33.camel@localhost.localdomain> References: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> <1150390229.17566.191.camel@cacharro.xalalinux.org> <1150391737.3187.33.camel@dhcp83-98.boston.redhat.com> <1150447930.5806.4.camel@localhost.localdomain> <1150502750.2668.12.camel@localhost> <1151001894.5804.33.camel@localhost.localdomain> Content-Type: text/plain Date: Thu, 22 Jun 2006 20:19:32 +0100 Message-Id: <1151003972.5346.29.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.371 tagged_above=-999 required=2 tests=[AWL=0.229, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.371 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 19:19:39 -0000 Hi Murray; On Thu, 2006-06-22 at 20:44 +0200, Murray Cumming wrote: > > The action code itself is one hundred lines long and can easily be > > hidden inside an helper file; it's approximately how GtkRecentAction > > would be implemented, anyway. I hereby give permission to do whatever > > you want to do with it. > > > > I understand that it's sub-optimal, and hopefully this should really go > > away once there's an action inside GTK. > > Do you feel that the existing API might need to be changed to add this > to a future version of GTK+? For instance, would it need need existing > classes to implement new interfaces, or add new signals? The point is: I don't know. :-) The currently unresolved issue is that I can't find a way to use this UI definition:

which is the "right" way to offer a submenu and a menu inside a toolbar item. The only case where I know for sure would require adding API is the case where you want an inlined recent files list - as it would require the ability to create a list of menu items instead of a single widget with the same GtkAction. At this point, I'd like a UIManager author/guru to step in and see if I'm doing something wrong. The bug is #338843 [1]. +++ http://bugzilla.gnome.org/show_bug.cgi?id=338843 -- Emmanuele Bassi, E: ebassi@gmail.com W: http://www.emmanuelebassi.net B: http://log.emmanuelebassi.net From jnoreiko@yahoo.com Thu Jun 22 17:19:57 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 48DC33B07DC for ; Thu, 22 Jun 2006 17:19:57 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27254-05 for ; Thu, 22 Jun 2006 17:19:56 -0400 (EDT) Received: from web32404.mail.mud.yahoo.com (web32404.mail.mud.yahoo.com [68.142.207.197]) by menubar.gnome.org (Postfix) with SMTP id 6C40C3B0601 for ; Thu, 22 Jun 2006 17:19:56 -0400 (EDT) Received: (qmail 9697 invoked by uid 60001); 22 Jun 2006 21:19:55 -0000 Message-ID: <20060622211955.9695.qmail@web32404.mail.mud.yahoo.com> Received: from [172.216.98.138] by web32404.mail.mud.yahoo.com via HTTP; Thu, 22 Jun 2006 22:19:55 BST Date: Thu, 22 Jun 2006 22:19:55 +0100 (BST) From: Joachim Noreiko Subject: Re: Looking beyond 2.10 To: Sven Neumann In-Reply-To: <1151000569.12681.22.camel@bender> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.693 tagged_above=-999 required=2 tests=[AWL=-0.741, BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2, DNS_FROM_RFC_WHOIS=1.447] X-Spam-Score: -1.693 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 21:19:57 -0000 --- Sven Neumann wrote: > Hi, > > On Thu, 2006-06-22 at 15:28 +0100, Joachim Noreiko > wrote: > > > I feel like I'm talking to myself here, but please > > could someone look at adding a help button to the > fileselector. > > GIMP has done that for quite a while already, so > there's nothing that > would keep an application from adding a Help button > to the file-chooser. > What's the point of adding one by default? By > default it won't be > connected to anything useful and what good is a help > button that does > nothing when the user clicks it? The documentation for the fileselector has been in the GNOME Desktop User Guide since 2.14. I'm sure I posted on this list when I wrote it. ___________________________________________________________ All new Yahoo! Mail "The new Interface is stunning in its simplicity and ease of use." - PC Magazine http://uk.docs.yahoo.com/nowyoucan.html From scott@asofyet.org Thu Jun 22 22:52:08 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 046A73B05F9 for ; Thu, 22 Jun 2006 22:52:08 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09189-02 for ; Thu, 22 Jun 2006 22:52:06 -0400 (EDT) Received: from looneymail-a2.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by menubar.gnome.org (Postfix) with ESMTP id 39B703B071C for ; Thu, 22 Jun 2006 22:52:06 -0400 (EDT) Received: from [192.168.0.100] (unknown [74.131.115.107]) by looneymail-a2.dreamhost.com (Postfix) with ESMTP id 2C0F016E8CD for ; Thu, 22 Jun 2006 19:52:05 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v750) In-Reply-To: <20060622211955.9695.qmail@web32404.mail.mud.yahoo.com> References: <20060622211955.9695.qmail@web32404.mail.mud.yahoo.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: muppet Subject: Re: Looking beyond 2.10 Date: Thu, 22 Jun 2006 22:51:48 -0400 To: GTK+ development mailing list X-Mailer: Apple Mail (2.750) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.558 tagged_above=-999 required=2 tests=[AWL=0.041, BAYES_00=-2.599] X-Spam-Score: -2.558 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2006 02:52:08 -0000 On Jun 22, 2006, at 5:19 PM, Joachim Noreiko wrote: > > --- Sven Neumann wrote: > >> GIMP has done that for quite a while already, so there's nothing >> that would keep an application from adding a Help button to the >> file-chooser. What's the point of adding one by default? By >> default it won't be connected to anything useful and what good is >> a help button that does nothing when the user clicks it? > > The documentation for the fileselector has been in the GNOME > Desktop User Guide since 2.14. I'm sure I posted on this list when > I wrote it. That doesn't do much good for gtk+ environments that don't involve GNOME. -- Jolt is my co-pilot. -- Slogan on a giant paper airplane hung in Lobby 7 at MIT. http://hacks.mit.edu/ From magnusbe@algonet.se Fri Jun 23 05:33:19 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 0D0353B0591 for ; Fri, 23 Jun 2006 05:33:19 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31880-05 for ; Fri, 23 Jun 2006 05:33:17 -0400 (EDT) Received: from pne-smtpout2-sn2.hy.skanova.net (pne-smtpout2-sn2.hy.skanova.net [81.228.8.164]) by menubar.gnome.org (Postfix) with ESMTP id 294473B041F for ; Fri, 23 Jun 2006 05:33:16 -0400 (EDT) Received: from feathers (83.252.145.175) by pne-smtpout2-sn2.hy.skanova.net (7.2.072.1) (authenticated as u73906364) id 449A811D0002C366 for gtk-devel-list@gnome.org; Fri, 23 Jun 2006 11:33:15 +0200 Date: Fri, 23 Jun 2006 12:31:05 +0200 From: Magnus Bergman To: GTK+ devel list Subject: Problems making loaders for header-less images Message-ID: <20060623123105.1589fed8@feathers> X-Mailer: Sylpheed-Claws 2.3.0 (GTK+ 2.8.16; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.522 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, TW_GD=0.077] X-Spam-Score: -2.522 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2006 09:33:19 -0000 I've made a couple of gdk-pixbuf loaders for formats that cannot be finger printed using a pattern, because they totaly lack some kind of header or that information is located at the end of the file. This has causes me the following problems: * If one loader handles several (similar) formats that cannot be distinguished from each other by looking at the first bytes. Then gdk-pixbuf uses other means to distinguish between them (extension or mime-type) but the information about what the match was based on is unavailable to loader (or am I missing something). Can this be solved is some way (except by making a different loader for each variant)? Example: There is an image format called pi1 (the most common format on the Atari ST). It consists of one word telling about the resolution, the palette and a copy of the screen memory. A variant of the format is called pc1 and has the only difference that the screen memory image is compressed. It is easy to distinguish between them using the extension or by looking at the file size (pi1 has a fixed size of 32066 bytes while pc1 is always smaller). * If a loader doesn't provide any fingerprinting pattern gdk-pixbuf causes a segfault at runtime then trying to load a picture in any format. Is the loader required to provide at least one pattern or is this a bug? * If the only thing that is known about the format is that it starts with one or more zeros, then gdk-pixbuf-query-loaders will refuse to register the loader because it considers the pattern to be empty. This could be avoided to checking the length of the mask field instead to the prefix field. A bug? From gcottenc@gmail.com Fri Jun 23 07:57:54 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id DA1E43B0678 for ; Fri, 23 Jun 2006 07:57:54 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08025-10 for ; Fri, 23 Jun 2006 07:57:53 -0400 (EDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.192]) by menubar.gnome.org (Postfix) with ESMTP id 7D8543B01A4 for ; Fri, 23 Jun 2006 07:57:53 -0400 (EDT) Received: by wx-out-0102.google.com with SMTP id s6so466104wxc for ; Fri, 23 Jun 2006 04:57:53 -0700 (PDT) Received: by 10.70.103.17 with SMTP id a17mr4494204wxc; Fri, 23 Jun 2006 04:57:52 -0700 (PDT) Received: by 10.70.46.6 with HTTP; Fri, 23 Jun 2006 04:57:52 -0700 (PDT) Message-ID: Date: Fri, 23 Jun 2006 13:57:52 +0200 From: "Guillaume Cottenceau" To: "Matthias Clasen" Subject: Re: Fwd: GTK+ 2.10, the endgame In-Reply-To: <1150895599.15532.80.camel@golem.boston.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> <1150895599.15532.80.camel@golem.boston.redhat.com> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.564 tagged_above=-999 required=2 tests=[AWL=0.036, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.564 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2006 11:57:55 -0000 Hi Matthias, > The online documentation is still at 2.9.2. I hope to find time > to update it to 2.9.4 before leaving for GUADEC tomorrow. Please warn us when the online API documentation regarding new symbols is fully freezed for 2.10 so that we can start working on adding the new symbols in bindings. Thanks! -- Guillaume Cottenceau - http://zarb.org/~gc/ From hfiguiere@teaser.fr Fri Jun 23 11:50:42 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 100083B04A7 for ; Fri, 23 Jun 2006 11:50:42 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21632-05 for ; Fri, 23 Jun 2006 11:50:39 -0400 (EDT) Received: from xandros.com (smtp1.xandros.com [209.87.238.70]) by menubar.gnome.org (Postfix) with ESMTP id 83AC63B0907 for ; Fri, 23 Jun 2006 11:50:33 -0400 (EDT) Received: from [172.16.1.95] (unknown [209.87.238.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by xandros.com (Postfix) with ESMTP id 6A6F223033 for ; Fri, 23 Jun 2006 11:50:32 -0400 (EDT) Message-ID: <449C0DC7.60502@teaser.fr> Date: Fri, 23 Jun 2006 11:50:31 -0400 From: Hubert Figuiere User-Agent: Thunderbird 1.5.0.4 (X11/20060615) MIME-Version: 1.0 To: gtk-devel-list@gnome.org Subject: Re: Looking beyond 2.10 References: <20060622142814.59921.qmail@web32406.mail.mud.yahoo.com> <1151000569.12681.22.camel@bender> In-Reply-To: <1151000569.12681.22.camel@bender> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.544 tagged_above=-999 required=2 tests=[AWL=0.055, BAYES_00=-2.599] X-Spam-Score: -2.544 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2006 15:50:42 -0000 Sven Neumann wrote: > GIMP has done that for quite a while already, so there's nothing that > would keep an application from adding a Help button to the file-chooser. > What's the point of adding one by default? By default it won't be > connected to anything useful and what good is a help button that does > nothing when the user clicks it? Why not putting it in only if the signal is connected ? (a signal like "help_requested"). Hub From gjc@inescporto.pt Fri Jun 23 18:23:20 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 9B8D83B0847 for ; Fri, 23 Jun 2006 18:23:20 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08741-04 for ; Fri, 23 Jun 2006 18:23:19 -0400 (EDT) Received: from animal.inescn.pt (animal.inescn.pt [194.117.24.9]) by menubar.gnome.org (Postfix) with ESMTP id AC38C3B0971 for ; Fri, 23 Jun 2006 18:23:18 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by animal.inescn.pt (8.13.6/8.13.6/7) with ESMTP id k5NMNG4Z018417; Fri, 23 Jun 2006 23:23:17 +0100 (WEST) Received: from pong.inescporto.pt (pong.inescn.pt [194.117.26.74]) by animal.inescn.pt (8.13.6/8.13.6/5) with ESMTP id k5NMN5ql018402; Fri, 23 Jun 2006 23:23:05 +0100 (WEST) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by pong.inescporto.pt (Postfix) with ESMTP id 31501155721; Fri, 23 Jun 2006 23:19:37 +0100 (WEST) Subject: Re: Looking beyond 2.10 From: "Gustavo J. A. M. Carneiro" To: Matthias Clasen In-Reply-To: <1150911355.15532.100.camel@golem.boston.redhat.com> References: <1150911355.15532.100.camel@golem.boston.redhat.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-2prtuoBhNnmmz3lcPkNU" Date: Fri, 23 Jun 2006 23:22:59 +0100 Message-Id: <1151101379.5189.5.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 X-Virus-Scanned: by amavisd-new at inescporto.pt X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.428 tagged_above=-999 required=2 tests=[AWL=0.038, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.428 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2006 22:23:20 -0000 --=-2prtuoBhNnmmz3lcPkNU Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Qua, 2006-06-21 =C3=A0s 13:35 -0400, Matthias Clasen escreveu: > So, with GTK+ 2.10 on the finish line, I tried to make a quick > list of things we may want to look at for 2.12, as input to > GUADEC discussions. >=20 > Patches almost ready to go in >=20 > - libglade integration > - new tooltips api >=20 >=20 > Stuff that needs more work >=20 > - introspection I'm willing to do some work in introspection. However, if you say it needs more work then I think you should identify precisely what work needs to be done. I could try guessing, but that usually leads to patches sitting in bugzilla for whole release cycles (e.g. #313268). Regards. --=20 Gustavo J. A. M. Carneiro The universe is always one step beyond logic --=-2prtuoBhNnmmz3lcPkNU Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta =?ISO-8859-1?Q?=E9?= uma parte de mensagem assinada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQBEnGnD2XoHyMdS6TARAk0JAJ95rFWntIs1xJ0hPTYMBwXdg26PgACeJo0x DrkoftT0jbf/hSym/poi0Uo= =WVRK -----END PGP SIGNATURE----- --=-2prtuoBhNnmmz3lcPkNU-- From jnoreiko@yahoo.com Sat Jun 24 03:40:19 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id EBA9B3B00F5 for ; Sat, 24 Jun 2006 03:40:18 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30651-07 for ; Sat, 24 Jun 2006 03:40:17 -0400 (EDT) Received: from web32401.mail.mud.yahoo.com (web32401.mail.mud.yahoo.com [68.142.207.194]) by menubar.gnome.org (Postfix) with SMTP id BD1E03B0194 for ; Sat, 24 Jun 2006 03:40:16 -0400 (EDT) Received: (qmail 229 invoked by uid 60001); 24 Jun 2006 07:40:15 -0000 Message-ID: <20060624074015.227.qmail@web32401.mail.mud.yahoo.com> Received: from [172.212.40.3] by web32401.mail.mud.yahoo.com via HTTP; Sat, 24 Jun 2006 08:40:15 BST Date: Sat, 24 Jun 2006 08:40:15 +0100 (BST) From: Joachim Noreiko Subject: Re: Looking beyond 2.10 To: gtk-devel-list@gnome.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.681 tagged_above=-999 required=2 tests=[AWL=-0.729, BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2, DNS_FROM_RFC_WHOIS=1.447] X-Spam-Score: -1.681 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2006 07:40:19 -0000 Message: 6 Date: Thu, 22 Jun 2006 22:51:48 -0400 From: muppet Subject: Re: Looking beyond 2.10 > The documentation for the fileselector has been in the GNOME > Desktop User Guide since 2.14. I'm sure I posted on this list when > I wrote it. That doesn't do much good for gtk+ environments that don't involve GNOME. -------------- Then figure out some way for it to detect whether it's on GNOME or not, maybe? Dialog boxes used in GNOME required help buttons, especially ones with as many features as the fileselector. Please could somebody look into this? I put a lot of work into writing the docs, and that's not a huge amount of use until it's linked to. ___________________________________________________________ Inbox full of spam? Get leading spam protection and 1GB storage with All New Yahoo! Mail. http://uk.docs.yahoo.com/nowyoucan.html From macfreesoft@free.fr Sat Jun 24 05:56:35 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C31133B02D5 for ; Sat, 24 Jun 2006 05:56:35 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05338-06 for ; Sat, 24 Jun 2006 05:56:33 -0400 (EDT) Received: from smtp010.mail.ukl.yahoo.com (smtp010.mail.ukl.yahoo.com [217.12.11.79]) by menubar.gnome.org (Postfix) with SMTP id 3D48E3B02B2 for ; Sat, 24 Jun 2006 05:56:33 -0400 (EDT) Received: (qmail 6982 invoked from network); 24 Jun 2006 09:56:32 -0000 Received: from unknown (HELO ?192.168.1.10?) (a?gillaizeau@217.66.126.141 with plain) by smtp010.mail.ukl.yahoo.com with SMTP; 24 Jun 2006 09:56:32 -0000 Message-ID: <449D0C4E.504@free.fr> Date: Sat, 24 Jun 2006 11:56:30 +0200 From: Aymeric GILLAIZEAU User-Agent: Thunderbird 1.5 (Macintosh/20051201) MIME-Version: 1.0 To: Easy B Subject: Gtk+.framework snapshot Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.033 tagged_above=-999 required=2 tests=[BAYES_05=-1.11, TW_GT=0.077] X-Spam-Score: -1.033 X-Spam-Level: X-Mailman-Approved-At: Sat, 24 Jun 2006 06:24:14 -0400 Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2006 09:56:36 -0000 > Hi guys > > Well I wasn't that happy with the result I got from the mono scripts > so I pretty much rewrote them. I now install everything into one > framework. I still don't have libtiff and jpeg support though. How is > the best way to make the gtk configure look for libtiff 3.8.2? I saw > that it looks for 3.4. Do I have to patch configure? > > Anyway, who's interested can give my installer a try. It installs the > framework into /Library/Frameworks and Gtk-Demo into /Applications. I > managed to compile one of my small apps by setting PKG_CONFIG_PATH to > /Library/Frameworks/Gtk+.framework/Libraries/pkgconfig/ and > ./configure, make. > > To make an application bundles I use this script: > http://www.easyb.ch/files/bundleApp.sh > > The Installer you can download here: > http://www.easyb.ch/files/Gtk%2B-2.9.1%20Framework%20snapshot.pkg.zip > > Cheers, > Ezra. Why to not use the already built Frameworks used by Scribus ? Instead of having many times the same things, it is present once and used by anyone. The problem with OpenSource is that everyone makes his cooking in his place without never taking consideration in the work others has already done. It could save time, also use less space on the drive, and so save room. http://www.scribus.net/index.php?name=Sections&req=viewarticle&artid=3&page=1 > ome support libraries, which should be moved to /Library/Frameworks : > Qt.framework > Freetype.framework > Fontconfig2.framework > libart.framework > libexpat.framework > libjpeg.framework > liblcms.framework > libpng.framework > libtiff.framework ___________________________________________________________________________ Yahoo! Mail rinvente le mail ! Dcouvrez le nouveau Yahoo! Mail et son interface rvolutionnaire. http://fr.mail.yahoo.com From alex@halogen-dg.com Sat Jun 24 08:41:32 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 92B9B3B013A for ; Sat, 24 Jun 2006 08:41:32 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13862-09 for ; Sat, 24 Jun 2006 08:41:31 -0400 (EDT) Received: from appserver.halogen.kharkov.ua (appserver.halogen.kharkov.ua [217.144.70.65]) by menubar.gnome.org (Postfix) with ESMTP id 256C33B00FB for ; Sat, 24 Jun 2006 08:41:31 -0400 (EDT) Received: (qmail 29949 invoked from network); 24 Jun 2006 15:41:32 +0300 Received: from dom.koval.kharkov.ua (217.144.70.182) by alex.halogen.kharkov.ua with AES256-SHA encrypted SMTP; 24 Jun 2006 15:41:32 +0300 Date: Sat, 24 Jun 2006 15:45:30 +0300 (EEST) From: alex@halogen-dg.com X-X-Sender: alex@dom.koval.kharkov.ua To: gtk-devel-list@gnome.org Subject: gtk file open dialog usability. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-0.858 tagged_above=-999 required=2 tests=[AWL=-0.709, BAYES_05=-1.11, NO_REAL_NAME=0.961] X-Spam-Score: -0.858 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2006 12:41:32 -0000 Anyone except me also disappointed by it? Any way how we can have old file open dialog back? I really find it very frustating and explained why, with some images here: http://www.halogen-dg.com/alex/file_selection_dialog/GtkFileOpenBadUsability -- Alex V. Koval http://www.halogen-dg.com/ http://www.zwarehouse.org/ From gnome-gtk-devel-list@m.gmane.org Sat Jun 24 08:49:58 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id F15263B00A8 for ; Sat, 24 Jun 2006 08:49:57 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14302-05 for ; Sat, 24 Jun 2006 08:49:55 -0400 (EDT) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by menubar.gnome.org (Postfix) with ESMTP id 402703B00FB for ; Sat, 24 Jun 2006 08:49:55 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Fu7a8-0004yS-Mc for gtk-devel-list@gnome.org; Sat, 24 Jun 2006 14:49:48 +0200 Received: from 84.52.165.220 ([84.52.165.220]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 24 Jun 2006 14:49:48 +0200 Received: from jernej.listsonly by 84.52.165.220 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 24 Jun 2006 14:49:48 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gtk-devel-list@gnome.org From: Jernej =?utf-7?Q?Simon+AQ0-i+AQ0-?= Subject: Re: gtk file open dialog usability. Date: Sat, 24 Jun 2006 14:49:37 +0200 Lines: 9 Message-ID: <10umqokepyu8y.10vhe4alqj04.dlg@40tude.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset="utf-7" Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 84.52.165.220 User-Agent: 40tude_Dialog/2.0.15.84 (cfc06cd9.460.419) X-Face: BOCQpf4)pfW>6Ya?'@oBT]=LBF; <6`_r[6pwqLggP!RG:*D)^Fz; O(I'n(FwJ{]5lo>g.H. _,Z:_`nLsfz]]8V'&9OmX)o-bXd?(P|CO=@5}[y\0rH9!AN&Qt:GXC(r!1}$q@@C]x`](7+#C]WRzw L|0W}vdFR/b@AFWIw~ X-Ultimate-Answer: 42 Sender: news X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.008 tagged_above=-999 required=2 tests=[AWL=0.016, BAYES_00=-2.599, FROM_EXCESS_QP=0, RCVD_NUMERIC_HELO=1.5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, TW_GT=0.077] X-Spam-Score: -1.008 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2006 12:49:58 -0000 On Sat, 24 Jun 2006 15:45:30 +-0300 (EEST), alex@halogen-dg.com wrote: > Anyone except me also disappointed by it? Search the archives, you're far from being the only one. -- < Jernej Simon+AQ0-i+AQ0- >< http://deepthought.ena.si/ > < Contact address: >< jernej simoncic at isg si > From alex@halogen-dg.com Sat Jun 24 09:01:55 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id F3A283B00A8 for ; Sat, 24 Jun 2006 09:01:54 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15013-06 for ; Sat, 24 Jun 2006 09:01:54 -0400 (EDT) Received: from appserver.halogen.kharkov.ua (appserver.halogen.kharkov.ua [217.144.70.65]) by menubar.gnome.org (Postfix) with ESMTP id 388713B0490 for ; Sat, 24 Jun 2006 09:01:53 -0400 (EDT) Received: (qmail 32296 invoked from network); 24 Jun 2006 16:01:54 +0300 Received: from dom.koval.kharkov.ua (217.144.70.182) by alex.halogen.kharkov.ua with AES256-SHA encrypted SMTP; 24 Jun 2006 16:01:54 +0300 Date: Sat, 24 Jun 2006 16:05:52 +0300 (EEST) From: alex@halogen-dg.com X-X-Sender: alex@dom.koval.kharkov.ua To: gtk-devel-list@gnome.org Subject: Re: gtk file open dialog usability. In-Reply-To: <10umqokepyu8y.10vhe4alqj04.dlg@40tude.net> Message-ID: References: <10umqokepyu8y.10vhe4alqj04.dlg@40tude.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.533 tagged_above=-999 required=2 tests=[AWL=0.028, BAYES_00=-2.599, NO_REAL_NAME=0.961, TW_GT=0.077] X-Spam-Score: -1.533 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2006 13:01:55 -0000 Hi Jernej On Sat, 24 Jun 2006, Jernej Simon+AQ0-i+AQ0- wrote: > On Sat, 24 Jun 2006 15:45:30 +-0300 (EEST), alex@halogen-dg.com wrote: > >> Anyone except me also disappointed by it? I am happy that people noticed that, too. The question is what can we do to fix this? My feeling is that at least 2 things could be done: 1. Make automatic selection of file optional (like its being done in KDE, in grey) 2. Do not display additional file open dialog when I *already* typed file name. > > Search the archives, you're far from being the only one. > BTW, before doing this post I've tried to search for "file dialog usability GTK". To my regret mail.gnome.org mailman search is not working ("The requested URL /mailman/search was not found on this server."),so I searched google a little, did not found any good results and posted here... Althrough this search returns more results: http://www.google.com.ua/search?q=gtk+file+open+usability&start=0&ie=utf-8&oe=utf-8&client=firefox-a&rls=org.mozilla:en-US:official Alex From g.tagliaretti@gmail.com Sat Jun 24 09:53:34 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 2C1C83B02E0 for ; Sat, 24 Jun 2006 09:53:34 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17447-04 for ; Sat, 24 Jun 2006 09:53:33 -0400 (EDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.178]) by menubar.gnome.org (Postfix) with ESMTP id 054D13B0228 for ; Sat, 24 Jun 2006 09:53:32 -0400 (EDT) Received: by py-out-1112.google.com with SMTP id i49so1099450pyi for ; Sat, 24 Jun 2006 06:52:59 -0700 (PDT) Received: by 10.35.99.14 with SMTP id b14mr3541165pym; Sat, 24 Jun 2006 06:52:56 -0700 (PDT) Received: by 10.35.132.18 with HTTP; Sat, 24 Jun 2006 06:52:56 -0700 (PDT) Message-ID: <35bf41160606240652s3da0fe6brd3915cd84c601114@mail.gmail.com> Date: Sat, 24 Jun 2006 15:52:56 +0200 From: "Gian Mario Tagliaretti" To: "alex@halogen-dg.com" Subject: Re: gtk file open dialog usability. In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.257 tagged_above=-999 required=2 tests=[AWL=0.066, BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2, SPF_PASS=-0.001, TW_GT=0.077] X-Spam-Score: -2.257 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2006 13:53:34 -0000 2006/6/24, alex@halogen-dg.com : > > Anyone except me also disappointed by it? > Any way how we can have old file open dialog back? code not complain :) > I really find it very frustating and explained > why, with some images here: > http://www.halogen-dg.com/alex/file_selection_dialog/GtkFileOpenBadUsability are you using gtk+ 2.9.x ? ciao -- Gian Mario Tagliaretti http://www.parafernalia.org/pygtk/ http://pygstdocs.berlios.de From timj@gtk.org Sat Jun 24 13:36:49 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 6B4403B006E; Sat, 24 Jun 2006 13:36:49 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27591-06; Sat, 24 Jun 2006 13:36:45 -0400 (EDT) Received: from holken.mikan.net (holken.mikan.net [83.145.56.183]) by menubar.gnome.org (Postfix) with ESMTP id C28AD3B06ED; Sat, 24 Jun 2006 13:36:44 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by holken.mikan.net (Postfix) with ESMTP id 59BF93352A5; Sat, 24 Jun 2006 19:36:26 +0200 (CEST) Received: from holken.mikan.net ([127.0.0.1]) by localhost (holken.mikan.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27952-05; Sat, 24 Jun 2006 19:36:22 +0200 (CEST) Received: from birnet.org (c135173.adsl.hansenet.de [213.39.135.173]) by holken.mikan.net (Postfix) with ESMTP id E12711844A; Sat, 24 Jun 2006 19:36:21 +0200 (CEST) Received: from master.birnet.private (localhost.localdomain [127.0.0.1]) by birnet.org (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k5OHaLjt023300 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 24 Jun 2006 19:36:21 +0200 Received: (from timj@localhost) by master.birnet.private (8.13.4/8.13.4/Submit) id k5OHZcXs023295; Sat, 24 Jun 2006 19:35:38 +0200 Date: Sat, 24 Jun 2006 19:35:38 +0200 (CEST) From: Tim Janik X-X-Sender: timj@master.birnet.private To: Gtk+ Developers Subject: Re: GTK+ meeting at GUADEC (Re: GTK+ 2.10, the endgame) In-Reply-To: Message-ID: References: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at holken.mikan.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.637 tagged_above=-999 required=2 tests=[AWL=-0.662, BAYES_05=-1.11, FORGED_RCVD_HELO=0.135] X-Spam-Score: -1.637 X-Spam-Level: X-Mailman-Approved-At: Sat, 24 Jun 2006 13:47:30 -0400 Cc: Federico Mena Quintero , Jonathan Blandford , Tim Janik , sandmann@daimi.au.dk, cworth@cworth.org, Komulainen Tommi , Alex Larsson , Michael Natterer , Kristian Rietveld , Matthias Clasen , Richard Hult , johan@gnome.org, michael meeks X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2006 17:36:49 -0000 On Thu, 15 Jun 2006, Tim Janik wrote: > the plan for that was to send out en email next friday/saturday (i.e > right at the guadec start) to figure/suggest dates suitable for > everyone to attend. we have gotten a room for the Gtk+ meeting now. it's on Sunday the 25th from 16:00-18:00 in the blue room (at the conference facility, second floor). --- ciaoTJ From torriem@chem.byu.edu Sun Jun 25 01:08:26 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id EA0E73B0079 for ; Sun, 25 Jun 2006 01:08:25 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17289-04 for ; Sun, 25 Jun 2006 01:08:22 -0400 (EDT) Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [63.240.77.83]) by menubar.gnome.org (Postfix) with ESMTP id ACB1F3B00A6 for ; Sun, 25 Jun 2006 01:08:22 -0400 (EDT) Received: from enterprise.local.lan (c-24-2-75-5.hsd1.ut.comcast.net[24.2.75.5]) by comcast.net (sccrmhc13) with ESMTP id <2006062505073001300me7qte>; Sun, 25 Jun 2006 05:07:31 +0000 Received: from enterprise.local.lan (enterprise.local.lan [127.0.0.1]) by enterprise.local.lan (8.13.1/8.12.8) with ESMTP id k5P57TFs002388 for ; Sat, 24 Jun 2006 23:07:29 -0600 Received: (from torriem@localhost) by enterprise.local.lan (8.13.1/8.13.1/Submit) id k5P57T1Z002387 for gtk-devel-list@gnome.org; Sat, 24 Jun 2006 23:07:29 -0600 X-Authentication-Warning: enterprise.local.lan: torriem set sender to torriem@chem.byu.edu using -f Subject: Re: Looking beyond 2.10 From: Michael Torrie To: gtk-devel-list@gnome.org In-Reply-To: References: <1150911355.15532.100.camel@golem.boston.redhat.com> <4499982C.1010004@teaser.fr> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Sat, 24 Jun 2006 23:07:29 -0600 Message-Id: <1151212049.32440.11.camel@enterprise.local.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-7) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.377 tagged_above=-999 required=2 tests=[AWL=0.010, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, TW_GT=0.077] X-Spam-Score: -2.377 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jun 2006 05:08:26 -0000 On Wed, 2006-06-21 at 18:26 -0400, Matthias Clasen wrote: > > I'm about to pick Qt as a toolkit for a personal project just because of > > that. > > Good luck. I was in the same boat as Hubert. I also ended up picking Qt. Although I like GTK much better, Qt was the best choice given the circumstances. I have not regretted it. But, as soon as GTK is fully supported on OS X, I will abandon Qt entirely, as GTK is cleaner, a little easier to work with, and, ironically, has better C++ bindings than Qt. > > Matthias > _______________________________________________ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-devel-list > From torriem@chem.byu.edu Sun Jun 25 01:21:50 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 36FD43B01F4 for ; Sun, 25 Jun 2006 01:21:50 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18141-02 for ; Sun, 25 Jun 2006 01:21:47 -0400 (EDT) Received: from sccrmhc14.comcast.net (sccrmhc14.comcast.net [204.127.200.84]) by menubar.gnome.org (Postfix) with ESMTP id DD6353B02BD for ; Sun, 25 Jun 2006 01:21:46 -0400 (EDT) Received: from enterprise.local.lan (c-24-2-75-5.hsd1.ut.comcast.net[24.2.75.5]) by comcast.net (sccrmhc14) with ESMTP id <2006062505211801400apa3je>; Sun, 25 Jun 2006 05:21:19 +0000 Received: from enterprise.local.lan (enterprise.local.lan [127.0.0.1]) by enterprise.local.lan (8.13.1/8.12.8) with ESMTP id k5P5LHWa002930; Sat, 24 Jun 2006 23:21:17 -0600 Received: (from torriem@localhost) by enterprise.local.lan (8.13.1/8.13.1/Submit) id k5P5LH4T002929; Sat, 24 Jun 2006 23:21:17 -0600 X-Authentication-Warning: enterprise.local.lan: torriem set sender to torriem@chem.byu.edu using -f Subject: Re: gtk file open dialog usability. From: Michael Torrie To: Gian Mario Tagliaretti In-Reply-To: <35bf41160606240652s3da0fe6brd3915cd84c601114@mail.gmail.com> References: <35bf41160606240652s3da0fe6brd3915cd84c601114@mail.gmail.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Sat, 24 Jun 2006 23:21:16 -0600 Message-Id: <1151212877.32440.24.camel@enterprise.local.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-7) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.378 tagged_above=-999 required=2 tests=[AWL=0.009, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, TW_GT=0.077] X-Spam-Score: -2.378 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jun 2006 05:21:50 -0000 On Sat, 2006-06-24 at 15:52 +0200, Gian Mario Tagliaretti wrote: > 2006/6/24, alex@halogen-dg.com : > > > > Anyone except me also disappointed by it? > > Any way how we can have old file open dialog back? > > code not complain :) BS. Before anyone can code anything, especially in the framework of GTK, the design has to be worked out. You can't just willy-nilly code up some pseudo-compatible widget. The problem is that every time this is discussed there is never any consensus on what the problems are, why they are problems, and how to fix them. And without this, we cannot convince developers to do anything about the problem. Now having said that, if someone wants to prototype a better widget (one that is API compatible with the current one), maybe that would jump- start the process. Myself, I fear that inertia guarantees we're stuck with this bad design for the duration. > > > I really find it very frustating and explained > > why, with some images here: > > http://www.halogen-dg.com/alex/file_selection_dialog/GtkFileOpenBadUsability > > are you using gtk+ 2.9.x ? > > ciao From dan@entropy.homelinux.org Mon Jun 26 21:13:46 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id D7F733B029A for ; Mon, 26 Jun 2006 21:13:46 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27746-05 for ; Mon, 26 Jun 2006 21:13:44 -0400 (EDT) Received: from screamer.nusconsulting.com.au (mail.nusconsulting.com.au [203.191.186.114]) by menubar.gnome.org (Postfix) with ESMTP id 5E0173B00FE for ; Mon, 26 Jun 2006 21:13:43 -0400 (EDT) Received: from [10.146.1.25] (dkasak.nusconsulting.com.au [10.146.1.25]) by screamer.nusconsulting.com.au (8.13.6/8.13.6) with ESMTP id k5R1FSwU022408 for ; Tue, 27 Jun 2006 11:15:28 +1000 Message-ID: <44A08654.1090208@entropy.homelinux.org> Date: Tue, 27 Jun 2006 11:13:56 +1000 From: Daniel Kasak User-Agent: Thunderbird 1.5.0.2 (X11/20060531) MIME-Version: 1.0 To: gtk-devel-list@gnome.org Subject: Custom Cell Renderers in a TreeView that requires scrolling broken in gtk+-2.8.18 and 2.8.19 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Canit-Stats-ID: 464197 - 7afdf0e072d5 X-Antispam-Training: Train as spam: http://screamer.nusconsulting.com.au/internal/canit/b.php?c=s&i=464197&m=7afdf0e072d5 X-Antispam-Training: Train as non-spam: http://screamer.nusconsulting.com.au/internal/canit/b.php?c=n&i=464197&m=7afdf0e072d5 X-Antispam-Training: Cancel training: http://screamer.nusconsulting.com.au/internal/canit/b.php?c=f&i=464197&m=7afdf0e072d5 X-Scanned-By: CanIt (www . roaringpenguin . com) on 10.146.0.254 X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.564 tagged_above=-999 required=2 tests=[AWL=0.035, BAYES_00=-2.599] X-Spam-Score: -2.564 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2006 01:13:47 -0000 Hi all. I've just noticed a very strange bug in my TreeViews since updating gtk. I have some apps that use a custom cell renderer to provide a pop-up GtkCalender. When I insert a row in the model, the custom cell renderer pops up ( begins editing ) as it's the 1st column. After I select a date and accept changes AND IF THERE ARE MORE ROWS THAN WILL FIT IN THE TREEVIEW WITHOUT SCROLLING, the new row DISAPPEARS from the TreeView. I scroll right from top to bottom - the new row certainly *looks* like it's gone. However if I insert *another* row, my previous missing row appears ( momentarily ) at the bottom again ... until I accept changes from the custom cell renderer on the newest row, and then they both ( or ALL, if I've inserted a number of rows ) disappear. For completeness ( partial anyway - it's a pretty complicated beast, but I can post an entire working example if required - please reply and request this if necessary, but note that it will be in Perl ), I'm pasting the entire CellRendererDate.pm module that provides the custom cell renderer at the bottom, however I note again that everything has worked properly for every version of gtk+ prior to 2.8.18. I initially updated from 2.8.17 to 2.8.19, and then when I found the bug, reverted to 2.8.17 ... tested some more ( no such bug here ), and then updated to 2.8.18 and did some more testing. It definitely arrived in 2.8.18. Has anyone noticed this behaviour with custom cell renderers? I have tested many other TreeViews that *don't* have a custom cell renderer, and have also tried moving the custom cell renderer to another position ( column ). I am almost positive that something is broken with displaying rows with a custom cell renderer when scrolling is required. I would greatly appreciate some help / suggests / confirmations / etc. Dan --- use strict; use Gtk2 -init; package Gtk2::Ex::Datasheet::DBI::CellRendererDate; use Glib::Object::Subclass "Gtk2::CellRenderer", signals => { edited => { flags => [qw(run-last)], param_types => [qw(Glib::String Glib::Scalar)], }, }, properties => [ Glib::ParamSpec -> boolean("editable", "Editable", "Can I change that?", 0, [qw(readable writable)]), Glib::ParamSpec -> string("date", "Date", "What's the date again?", "", [qw(readable writable)]), ] ; use constant x_padding => 2; use constant y_padding => 3; use constant arrow_width => 15; use constant arrow_height => 15; sub hide_popup { my ($cell) = @_; Gtk2 -> grab_remove($cell -> { _popup }); $cell -> { _popup } -> hide(); } sub get_today { my ($cell) = @_; my ($day, $month, $year) = (localtime())[3, 4, 5]; $year += 1900; $month += 1; return ($year, $month, $day); } sub get_date { my ($cell) = @_; my $text = $cell -> get("date"); my ($year, $month, $day) = $text ? split(/[\/-]/, $text) : $cell -> get_today(); return ($year, $month, $day); } sub add_padding { my ($cell, $year, $month, $day) = @_; return ($year, sprintf("%02d", $month), sprintf("%02d", $day)); } sub INIT_INSTANCE { my ($cell) = @_; my $popup = Gtk2::Window -> new ('popup'); my $vbox = Gtk2::VBox -> new(0, 0); my $calendar = Gtk2::Calendar -> new(); my $hbox = Gtk2::HBox -> new(0, 0); my $today = Gtk2::Button -> new('Today'); my $none = Gtk2::Button -> new('None'); $cell -> {_arrow} = Gtk2::Arrow -> new("down", "none"); # We can't just provide the callbacks now because they might need access to # cell-specific variables. And we can't just connect the signals in # START_EDITING because we'd be connecting many signal handlers to the same # widgets. $today -> signal_connect(clicked => sub { $cell -> { _today_clicked_callback } -> (@_) if (exists($cell -> { _today_clicked_callback })); }); $none -> signal_connect(clicked => sub { $cell -> { _none_clicked_callback } -> (@_) if (exists($cell -> { _none_clicked_callback })); }); $calendar -> signal_connect(day_selected_double_click => sub { $cell -> { _day_selected_double_click_callback } -> (@_) if (exists($cell -> { _day_selected_double_click_callback })); }); $calendar -> signal_connect(month_changed => sub { $cell -> { _month_changed } -> (@_) if (exists($cell -> { _month_changed })); }); $hbox -> pack_start($today, 1, 1, 0); $hbox -> pack_start($none, 1, 1, 0); $vbox -> pack_start($calendar, 1, 1, 0); $vbox -> pack_start($hbox, 0, 0, 0); # Find out if the click happended outside of our window. If so, hide it. # Largely copied from Planner (the former MrProject). # Implement via Gtk2::get_event_widget? $popup -> signal_connect(button_press_event => sub { my ($popup, $event) = @_; if ($event -> button() == 1) { my ($x, $y) = ($event -> x_root(), $event -> y_root()); my ($xoffset, $yoffset) = $popup -> window() -> get_root_origin(); my $allocation = $popup -> allocation(); my $x1 = $xoffset + 2 * $allocation -> x(); my $y1 = $yoffset + 2 * $allocation -> y(); my $x2 = $x1 + $allocation -> width(); my $y2 = $y1 + $allocation -> height(); unless ($x > $x1 && $x < $x2 && $y > $y1 && $y < $y2) { $cell -> hide_popup(); return 1; } } return 0; }); $popup -> add($vbox); $cell -> { _popup } = $popup; $cell -> { _calendar } = $calendar; } sub START_EDITING { my ($cell, $event, $view, $path, $background_area, $cell_area, $flags) = @_; my $popup = $cell -> { _popup }; my $calendar = $cell -> { _calendar }; # Specify the callbacks. Will be called by the signal handlers set up in # INIT_INSTANCE. $cell -> { _today_clicked_callback } = sub { my ($button) = @_; my ($year, $month, $day) = $cell -> get_today(); $cell -> signal_emit(edited => $path, join("-", $cell -> add_padding($year, $month, $day))); $cell -> hide_popup(); }; $cell -> { _none_clicked_callback } = sub { my ($button) = @_; $cell -> signal_emit(edited => $path, ""); $cell -> hide_popup(); }; $cell -> { _day_selected_double_click_callback } = sub { my ($calendar) = @_; my ($year, $month, $day) = $calendar -> get_date(); $cell -> signal_emit(edited => $path, join("-", $cell -> add_padding($year, ++$month, $day))); $cell -> hide_popup(); }; $cell -> { _month_changed } = sub { my ($calendar) = @_; my ($selected_year, $selected_month) = $calendar -> get_date(); my ($current_year, $current_month, $current_day) = $cell -> get_today(); if ($selected_year == $current_year && ++$selected_month == $current_month) { $calendar -> mark_day($current_day); } else { $calendar -> unmark_day($current_day); } }; my ($year, $month, $day) = $cell -> get_date(); $calendar -> select_month($month - 1, $year); $calendar -> select_day($day); # Necessary to get the correct allocation of the popup. $popup -> move(-500, -500); $popup -> show_all(); # Figure out where to put the popup - ie don't put it offscreen, # as it's not movable ( by the user ) my $screen_height = $popup->get_screen->get_height; my $requisition = $popup->size_request(); my $popup_width = $requisition->width; my $popup_height = $requisition->height; my ($x_origin, $y_origin) = $view -> get_bin_window() -> get_origin(); my ($popup_x, $popup_y); $popup_x = $x_origin + $cell_area->x() + $cell_area->width() - $popup_width; $popup_x = 0 if $popup_x < 0; $popup_y = $y_origin + $cell_area -> y() + $cell_area -> height(); if ( $popup_y + $popup_height > $screen_height ) { $popup_y = $y_origin + $cell_area -> y() - $popup_height; } $popup -> move( $popup_x, $popup_y ); # Grab the focus and the pointer. Gtk2 -> grab_add($popup); $popup -> grab_focus(); Gtk2::Gdk -> pointer_grab($popup -> window(), 1, [qw(button-press-mask button-release-mask pointer-motion-mask)], undef, undef, 0); return; } sub get_date_string { my $cell = shift; return $cell->get ('date'); } sub calc_size { my ($cell, $layout) = @_; my ($width, $height) = $layout -> get_pixel_size(); return (0, 0, $width + x_padding * 2 + arrow_width, $height + y_padding * 2); } sub GET_SIZE { my ($cell, $widget, $cell_area) = @_; my $layout = $cell -> get_layout($widget); $layout -> set_text( $cell -> get_date_string() || '' ); return $cell -> calc_size($layout); } sub get_layout { my ($cell, $widget) = @_; return $widget -> create_pango_layout(""); } sub RENDER { my ($cell, $window, $widget, $background_area, $cell_area, $expose_area, $flags) = @_; my $state; if ($flags & 'selected') { $state = $widget -> has_focus() ? 'selected' : 'active'; } else { $state = $widget -> state() eq 'insensitive' ? 'insensitive' : 'normal'; } my $layout = $cell -> get_layout($widget); $layout -> set_text( $cell -> get_date_string() || '' ); my ($x_offset, $y_offset, $width, $height) = $cell -> calc_size($layout); $widget -> get_style -> paint_layout($window, $state, 1, $cell_area, $widget, "cellrenderertext", $cell_area -> x() + $x_offset + x_padding, $cell_area -> y() + $y_offset + y_padding, $layout); $widget -> get_style -> paint_arrow ($window, $widget->state, 'none', $cell_area, $cell -> { _arrow }, "", "down", 1, $cell_area -> x + $cell_area -> width - arrow_width, $cell_area -> y + $cell_area -> height - arrow_height - 2, arrow_width - 3, arrow_height); } 1; From mail2karuna@hotmail.com Tue Jun 27 05:53:25 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 0ECA43B00E4 for ; Tue, 27 Jun 2006 05:53:25 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21270-07 for ; Tue, 27 Jun 2006 05:53:11 -0400 (EDT) Received: from hotmail.com (bay123-f24.bay123.hotmail.com [207.46.11.104]) by menubar.gnome.org (Postfix) with ESMTP id 2C7C03B0104 for ; Tue, 27 Jun 2006 05:53:11 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 27 Jun 2006 02:53:10 -0700 Message-ID: Received: from 207.46.11.123 by by123fd.bay123.hotmail.msn.com with HTTP; Tue, 27 Jun 2006 09:53:09 GMT X-Originating-IP: [62.193.236.100] X-Originating-Email: [mail2karuna@hotmail.com] X-Sender: mail2karuna@hotmail.com From: "karuna karan" To: gtk-devel-list@gnome.org Subject: Re: Failed building GTK with the DFB backend Date: Tue, 27 Jun 2006 09:53:09 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 27 Jun 2006 09:53:10.0427 (UTC) FILETIME=[7F932EB0:01C699CF] X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-0.958 tagged_above=-999 required=2 tests=[BAYES_05=-1.11, MSGID_FROM_MTA_HEADER=0, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, TW_BG=0.077, TW_GT=0.077] X-Spam-Score: -0.958 X-Spam-Level: Cc: skar@tataelxsi.co.in X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2006 09:53:25 -0000 Hi all, I tried to build gtk 2.9.1 with directFB backend with following dependencies, glib 2.11.1 atk 1.10.1 cairo 1.1.6 pango 1.13.1 directfb 0.9.25.1 while building gtk with, 1 ./configure --prefix=/opt/gtkdfb/ --without-x --with-gdktarget=directfb --enable-debug=no 2 make the buld fails and throws the error as, queryimmodules.c: In function `query_module': queryimmodules.c:116: warning: dereferencing type-punned pointer will break strict-aliasing rules queryimmodules.c:117: warning: dereferencing type-punned pointer will break strict-aliasing rules queryimmodules.c:118: warning: dereferencing type-punned pointer will break strict-aliasing rules queryimmodules.c:119: warning: dereferencing type-punned pointer will break strict-aliasing rules /bin/sh ../libtool --mode=link gcc -g -O2 -Wall -o gtk-query-immodules-2.0 queryimmodules.o libgtk-directfb-2.0.la .../gdk-pixbuf/libgdk_pixbuf-2.0.la ../gdk/libgdk-directfb-2.0.la gcc -g -O2 -Wall -o .libs/gtk-query-immodules-2.0 queryimmodules.o ../.libs/libgtk-directfb-2.0.so -L/opt/gtkdfb/lib /root/gtk+-2.9.1/gdk/.libs/libgdk-directfb-2.0.so /opt/gtkdfb/lib/libatk-1.0.so ../gdk-pixbuf/.libs/libgdk_pixbuf-2.0.so .../gdk/.libs/libgdk-directfb-2.0.so /opt/gtkdfb/lib/libpangocairo-1.0.so /opt/gtkdfb/lib/libpangoft2-1.0.so /opt/gtkdfb/lib/libpango-1.0.so /opt/gtkdfb/lib/libcairo.so -lpng12 /opt/gtkdfb/lib/libdirectfb.so /opt/gtkdfb/lib/libfusion.so /opt/gtkdfb/lib/libdirect.so -lfontconfig /usr/lib/libfreetype.so /usr/lib/libxml2.so -lpthread -lz /root/gtk+-2.9.1/gdk-pixbuf/.libs/libgdk_pixbuf-2.0.so /opt/gtkdfb/lib/libgmodule-2.0.so -ldl /opt/gtkdfb/lib/libgobject-2.0.so /opt/gtkdfb/lib/libglib-2.0.so -lm -Wl,--rpath -Wl,/opt/gtkdfb/lib ../.libs/libgtk-directfb-2.0.so: undefined reference to `gdk_screen_is_composited' /root/gtk+-2.9.1/gdk/.libs/libgdk-directfb-2.0.so: undefined reference to `IA__gdk_screen_is_composited' collect2: ld returned 1 exit status make[4]: *** [gtk-query-immodules-2.0] Error 1 make[4]: Leaving directory `/root/gtk+-2.9.1/gtk' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/root/gtk+-2.9.1/gtk' make[2]: *** [all] Error 2 make[2]: Leaving directory `/root/gtk+-2.9.1/gtk' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/root/gtk+-2.9.1' make: *** [all] Error 2 help me out in this.. Thanks, Karunakaran A. _________________________________________________________________ Dont just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/ From fiandro@tiscali.it Tue Jun 27 06:05:04 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C52653B0010 for ; Tue, 27 Jun 2006 06:05:04 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22230-02 for ; Tue, 27 Jun 2006 06:05:02 -0400 (EDT) Received: from polito.it (anacreon.polito.it [130.192.3.82]) by menubar.gnome.org (Postfix) with ESMTP id 1B1113B0088 for ; Tue, 27 Jun 2006 06:05:00 -0400 (EDT) X-ExtScanner: Niversoft's FindAttachments (free) Received: from [130.192.31.127] (HELO [130.192.31.127]) by anacreon.polito.it (CommuniGate Pro SMTP 5.0.9) with ESMTP id 39350329; Tue, 27 Jun 2006 12:04:58 +0200 Message-ID: <44A103E0.8000000@tiscali.it> Date: Tue, 27 Jun 2006 12:09:36 +0200 From: Attilio Fiandrotti User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.13) Gecko/20060620 Debian/1.7.13-0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: karuna karan Subject: Re: Failed building GTK with the DFB backend References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.224 tagged_above=-999 required=2 tests=[AWL=-0.337, BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2, FORGED_RCVD_HELO=0.135, SPF_NEUTRAL=1.069, TW_DF=0.077, TW_GT=0.077, TW_KD=0.077, TW_TK=0.077] X-Spam-Score: -1.224 X-Spam-Level: Cc: gtk-devel-list@gnome.org, skar@tataelxsi.co.in X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2006 10:05:05 -0000 karuna karan wrote: > Hi all, > > I tried to build gtk 2.9.1 with directFB backend with following > dependencies, DFB support in was broken: you should try 2.9.4 or follow instructions in the wiki page to build from sratch. If you're a debian user, you can also use precompiled i386 official packages that were built this week http://download.dajobe.org/debian/experimental/ <-cairodfb http://people.debian.org/~joss/packages/ <-gtkdfb Attilio From kris@babi-pangang.org Tue Jun 27 08:43:52 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 623A53B00AE for ; Tue, 27 Jun 2006 08:43:52 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29028-04 for ; Tue, 27 Jun 2006 08:43:48 -0400 (EDT) Received: from nasi-goreng.babi-pangang.org (nasi-goreng.babi-pangang.org [83.166.137.20]) by menubar.gnome.org (Postfix) with ESMTP id 5BA363B008D for ; Tue, 27 Jun 2006 08:43:48 -0400 (EDT) Received: by nasi-goreng.babi-pangang.org (Postfix, from userid 1000) id C52593DCA0; Tue, 27 Jun 2006 14:42:09 +0200 (CEST) Date: Tue, 27 Jun 2006 14:42:09 +0200 From: Kristian Rietveld To: gtk-devel-list@gnome.org Subject: Minutes of the GTK+ meeting at GUADEC Message-ID: <20060627124209.GA23474@babi-pangang.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.564 tagged_above=-999 required=2 tests=[AWL=0.035, BAYES_00=-2.599] X-Spam-Score: -2.564 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2006 12:43:52 -0000 Hey, We had a GTK+ meeting in person at GUADEC last Sunday. Below are the minutes (or really just the notes I took). -kris. ---- GTK+ Meeting, 25 June 2006, GUADEC7 ----------------------------------- * 2.10 is basically done, we are aiming for a release next week. * Tommi asks whether the GTK+ development/maintainer team is big enough. Matthias and Tim both answer that the team has been too small for the last few years, everybody else seems to agree. * Planning 2.12, possible new features: - Canvas, and we need off-screen rendering for that. # At least 3 different candidate canvases around. # Some ideas from Soeren; immediate mode, callbacks. He will write up his ideas and send it to the list for discussion. # Defining the feature set for a canvas is really difficult, though most people agreed that GnomeCanvas does cover most of the features needed by general applications. # Might want to look at the new canvas in Qt 4.1. - Introspection - GtkBuilder, the libglade integration into GTK+. - The new tooltips API. - Maemo.org patches # Menu patches, # Input method, # Tap and hold. - International calendar support # GLib patch is about ready, # After that the GTK+ widget (GtkCalendar) needs some fixing up. - Support for editable multi-line labels, probably by extending GtkEntry. - libsexy cherrypicking # Support having an icon in the entry. # Input masks. - Recent file code updates # GtkRecentAction. # GtkFileChooser integration. * Matthias continues on Tommi's previous question on maintenance, mentioning the OS X backend. Micke and Richard explain that the backend is mostly working, but does need some bug fixing. It's marked as still experimental. * The file chooser API does have some issues. For example the backend API is private, and getting the model from the file chooser dialog is impossible. Also the code for supporting the pluggability of the UI does not work/has not been tested at all. * We decided to target the GTK+ 2.12 release on January '07. This should give us enough time to put all new features in. If we decide to include a canvas with GTK+ 2.12, we might have to depend on a new release of Cairo. According to Carl Worth the next releases of Cairo are pretty much "open". They will probably focus on performance for the next release. Making a new release for supporting some special canvas features should be feasible. * We get interrupted by some guys of the board. Jeff speaks about having the GTK+ project join the GNOME foundation. The foundation can provide help to the GTK+ project with financial and administrative tasks. It has been doing this for the GIMP project already, which has been working fine so far. The foundation does not get any influence on the technical decisions made by the GTK+ team. Also, the plan is to get a press release out on this. * The board leaves and the core team pretty much decides that doing this is not bad at all, and the only thing that needs work is the wording in the press release. Nobody appears to be against. * The topic of GTK+ 3.0 was brought up after this. 3.0 would be an API and ABI breaking release. The team decided that we would like to avoid breaking API since a lot of companies invested into GTK+ 2.x and expect that it'll be supported for some more years. Most of the team seems to agree that we want to get rid of the cruft in the 2.x series, some of which is still sticking around from the 1.x series. Matthias mentions that FC6 will not ship with GTK+ 1.x. (People cheered and Tim complained about he won't be able to run xmms then). The idea of introducing compiling subsets was brought up. We could set up a make system where the full library or only a subset is built, for example omitting all the old stuff and the printing support. The people using GTK+ on embedded devices would be really happy if we implemented something like this. If we want the compiling subsets to work, we need to make sure that none of the internal code is using deprecated widgets. Breaking API is not really something we really want to do soon. If we ever do it, we want to do it right so it can last for at least a couple of years. Also, we would prefer the development on 3.0 to happen in parallel with 2.x development. Alex brought up the idea of creating a bug which we can use to track all issues which require breaking the API, so we get a formalized list of stuff which needs API breakage. According to Tim breaking the ABI is not a real problem, since distributions and also for example the Maemo.org platform can just be recompiled. * Tim also mentioned that Michael Meeks has been working on optimizing shared library loading optimization in OpenOffice.org. We wondered if there's anything we can do to improve GTK+'s performance in this area. As Michael was unable to attend Tim and/or Matthias will try to have a talk with Michael about this. As there was nothing left discuss, we decided to close the meeting. From skar@tataelxsi.co.in Tue Jun 27 07:22:44 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 665AF3B0072 for ; Tue, 27 Jun 2006 07:22:44 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25789-03 for ; Tue, 27 Jun 2006 07:22:43 -0400 (EDT) Received: from mail.tataelxsi.co.in (mail.tataelxsi.co.in [203.200.1.48]) by menubar.gnome.org (Postfix) with ESMTP id 1DFEF3B0011 for ; Tue, 27 Jun 2006 07:22:41 -0400 (EDT) Received: from skar (tataelxsi.co.in [203.197.169.80] (may be forged)) by mail.tataelxsi.co.in (MOS 3.7.4b-GA) with ESMTP id BRG33699 (AUTH skar); Tue, 27 Jun 2006 16:52:16 +0530 (IST) From: Suman Kar To: "'Attilio Fiandrotti'" , "'karuna karan'" Subject: RE: Failed building GTK with the DFB backend Date: Tue, 27 Jun 2006 16:51:13 +0530 Message-ID: <002301c699db$cd352ea0$381b320a@telxsi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal In-Reply-To: <44A103E0.8000000@tiscali.it> X-Junkmail: Blacklisted X-Mirapoint-Sig: mail.tataelxsi.co.in X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=0.386 tagged_above=-999 required=2 tests=[BAYES_50=0.001, TW_DF=0.077, TW_GD=0.077, TW_GT=0.077, TW_KD=0.077, TW_TK=0.077] X-Spam-Score: 0.386 X-Spam-Level: X-Mailman-Approved-At: Tue, 27 Jun 2006 10:07:05 -0400 Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: Suman Kar List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2006 11:22:44 -0000 Hello Attilio, Thanks for the quick update. However, the problem goes away when we added the following: gboolean gdk_screen_is_composited (GdkScreen *screen) { g_return_val_if_fail (GDK_IS_SCREEN (screen), NULL); return FALSE; } is added to gdkscreen-directfb.c (from http://mail.gnome.org/archives/gtk-devel-list/2006-May/msg00210.html ). We will definitely try building gtk+2.9.4 and will get back in case there are any issues. One more thing: we would be really interested in gtk+-2.10. Any idea when this will be out? Regards, Suman. -----Original Message----- From: Attilio Fiandrotti [mailto:fiandro@tiscali.it] Sent: Tuesday, June 27, 2006 3:40 PM To: karuna karan Cc: gtk-devel-list@gnome.org; skar@tataelxsi.co.in Subject: Re: Failed building GTK with the DFB backend karuna karan wrote: > Hi all, > > I tried to build gtk 2.9.1 with directFB backend with following > dependencies, DFB support in was broken: you should try 2.9.4 or follow instructions in the wiki page to build from sratch. If you're a debian user, you can also use precompiled i386 official packages that were built this week http://download.dajobe.org/debian/experimental/ <-cairodfb http://people.debian.org/~joss/packages/ <-gtkdfb Attilio The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s)and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender or administrator@tataelxsi.co.in From mail2karuna@hotmail.com Wed Jun 28 01:21:49 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 761EF3B002A for ; Wed, 28 Jun 2006 01:21:49 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27811-08 for ; Wed, 28 Jun 2006 01:21:48 -0400 (EDT) Received: from hotmail.com (bay123-f28.bay123.hotmail.com [207.46.11.108]) by menubar.gnome.org (Postfix) with ESMTP id 40EF13B000F for ; Wed, 28 Jun 2006 01:21:48 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 27 Jun 2006 22:19:26 -0700 Message-ID: Received: from 207.46.11.123 by by123fd.bay123.hotmail.msn.com with HTTP; Wed, 28 Jun 2006 05:19:23 GMT X-Originating-IP: [62.193.236.96] X-Originating-Email: [mail2karuna@hotmail.com] X-Sender: mail2karuna@hotmail.com In-Reply-To: <002301c699db$cd352ea0$381b320a@telxsi.com> From: "karuna karan" To: fiandro@tiscali.it, skar@tataelxsi.co.in, amirthakaruna@tataelxsi.co.in Subject: RE: Failed building GTK with the DFB backend Date: Wed, 28 Jun 2006 05:19:23 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 28 Jun 2006 05:19:26.0977 (UTC) FILETIME=[6CD95710:01C69A72] X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-0.502 tagged_above=-999 required=2 tests=[AWL=-1.829, BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2, DNS_FROM_RFC_POST=1.708, MSGID_FROM_MTA_HEADER=0, RCVD_IN_BL_SPAMCOP_NET=1.558, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, TW_DF=0.077, TW_DK=0.077, TW_GD=0.077, TW_GT=0.077, TW_KD=0.077, TW_TK=0.077] X-Spam-Score: -0.502 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2006 05:21:49 -0000 Hi, we have tried to build gtk+ 2.9.4 with backend dfb. we got the follwing error while building, gdkwindow-directfb.c: In function `gdk_directfb_create_child_window': gdkwindow-directfb.c:2508: error: structure has no member named `GetPosition' make[4]: *** [gdkwindow-directfb.lo] Error 1 make[4]: Leaving directory `/root/new/gtk+-2.9.4/gdk/directfb' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/root/new/gtk+-2.9.4/gdk' make[2]: *** [all] Error 2 make[2]: Leaving directory `/root/new/gtk+-2.9.4/gdk' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/root/new/gtk+-2.9.4' make: *** [all] Error 2 so kindly give feedback on this issue.. Thanks, Karunakaran A. >From: Suman Kar >Reply-To: Suman Kar >To: "'Attilio Fiandrotti'" , "'karuna karan'" > >CC: >Subject: RE: Failed building GTK with the DFB backend >Date: Tue, 27 Jun 2006 16:51:13 +0530 > >Hello Attilio, > >Thanks for the quick update. However, the problem goes away when we added >the following: > >gboolean >gdk_screen_is_composited (GdkScreen *screen) >{ > g_return_val_if_fail (GDK_IS_SCREEN (screen), NULL); > return FALSE; >} > > >is added to gdkscreen-directfb.c (from >http://mail.gnome.org/archives/gtk-devel-list/2006-May/msg00210.html ). > >We will definitely try building gtk+2.9.4 and will get back in case there >are any issues. > >One more thing: we would be really interested in gtk+-2.10. Any idea when >this will be out? > >Regards, >Suman. > >-----Original Message----- >From: Attilio Fiandrotti [mailto:fiandro@tiscali.it] >Sent: Tuesday, June 27, 2006 3:40 PM >To: karuna karan >Cc: gtk-devel-list@gnome.org; skar@tataelxsi.co.in >Subject: Re: Failed building GTK with the DFB backend > > >karuna karan wrote: > > Hi all, > > > > I tried to build gtk 2.9.1 with directFB backend with following > > dependencies, > >DFB support in was broken: you should try 2.9.4 or follow instructions >in the wiki page to build from sratch. >If you're a debian user, you can also use precompiled i386 official >packages that were built this week > >http://download.dajobe.org/debian/experimental/ <-cairodfb >http://people.debian.org/~joss/packages/ <-gtkdfb > >Attilio > >The information contained in this electronic message and any attachments to >this message are intended for the exclusive use of the addressee(s)and may >contain confidential or privileged information. If you are not the intended >recipient, please notify the sender or administrator@tataelxsi.co.in _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today - it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ From matthias.clasen@gmail.com Wed Jun 28 03:10:14 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 5BEF93B002C for ; Wed, 28 Jun 2006 03:10:14 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30060-02 for ; Wed, 28 Jun 2006 03:10:12 -0400 (EDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.183]) by menubar.gnome.org (Postfix) with ESMTP id 603903B009C for ; Wed, 28 Jun 2006 03:10:12 -0400 (EDT) Received: by py-out-1112.google.com with SMTP id c30so2171621pyc for ; Wed, 28 Jun 2006 00:09:17 -0700 (PDT) Received: by 10.35.83.6 with SMTP id k6mr338054pyl; Wed, 28 Jun 2006 00:09:17 -0700 (PDT) Received: by 10.35.39.16 with HTTP; Wed, 28 Jun 2006 00:09:17 -0700 (PDT) Message-ID: Date: Wed, 28 Jun 2006 03:09:17 -0400 From: "Matthias Clasen" To: "Suman Kar" Subject: Re: Failed building GTK with the DFB backend In-Reply-To: <002301c699db$cd352ea0$381b320a@telxsi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <44A103E0.8000000@tiscali.it> <002301c699db$cd352ea0$381b320a@telxsi.com> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.41 tagged_above=-999 required=2 tests=[AWL=-0.010, BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2, SPF_PASS=-0.001] X-Spam-Score: -2.41 X-Spam-Level: Cc: gtk-devel-list@gnome.org, karuna karan X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2006 07:10:14 -0000 On 6/27/06, Suman Kar wrote: > One more thing: we would be really interested in gtk+-2.10. Any idea when > this will be out? > I'll start working on the release when I'm back from Guadec next week. From fiandro@tiscali.it Wed Jun 28 03:57:13 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 3E6E73B0002 for ; Wed, 28 Jun 2006 03:57:13 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31177-01 for ; Wed, 28 Jun 2006 03:57:10 -0400 (EDT) Received: from aa003msr.fastwebnet.it (aa003msr.fastwebnet.it [85.18.95.66]) by menubar.gnome.org (Postfix) with ESMTP id 4417B3B0005 for ; Wed, 28 Jun 2006 03:57:10 -0400 (EDT) Received: from [192.168.2.2] (41.255.136.50) by aa003msr.fastwebnet.it (7.2.070.1) id 44965DC20058C56D; Wed, 28 Jun 2006 09:55:45 +0200 Message-ID: <44A23718.3020008@tiscali.it> Date: Wed, 28 Jun 2006 10:00:24 +0200 From: Attilio Fiandrotti User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.13) Gecko/20060620 Debian/1.7.13-0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: karuna karan Subject: Re: Failed building GTK with the DFB backend References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=1.347 tagged_above=-999 required=2 tests=[AWL=-0.215, BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2, RCVD_IN_WHOIS_BOGONS=2.43, SPF_NEUTRAL=1.069, TW_DF=0.077, TW_DK=0.077, TW_GD=0.077, TW_GT=0.077, TW_KD=0.077, TW_TK=0.077] X-Spam-Score: 1.347 X-Spam-Level: * Cc: gtk-devel-list@gnome.org, skar@tataelxsi.co.in, amirthakaruna@tataelxsi.co.in X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2006 07:57:13 -0000 A couple of days ago mike checked in the patch that excludes from compilation some extra code that requires DFB 0.9.25 in the case DFN 0.9.24 is used. Use CVS sources or apply to GTK 2.9.4 gdkdirectfb.h and gdkwindow-directfb.c from current SVN. If you're a Debian user and run on i386, simply install cairodfb and gtkdfb packages [1] which were made recently available (other archs will follow soon). Attilio [1] http://mail.directfb.org/pipermail/directfb-dev/2006-June/001973.html karuna karan wrote: > Hi, > > we have tried to build gtk+ 2.9.4 with backend dfb. > we got the follwing error while building, > > gdkwindow-directfb.c: In function `gdk_directfb_create_child_window': > gdkwindow-directfb.c:2508: error: structure has no member named > `GetPosition' > make[4]: *** [gdkwindow-directfb.lo] Error 1 > make[4]: Leaving directory `/root/new/gtk+-2.9.4/gdk/directfb' > make[3]: *** [all-recursive] Error 1 > make[3]: Leaving directory `/root/new/gtk+-2.9.4/gdk' > make[2]: *** [all] Error 2 > make[2]: Leaving directory `/root/new/gtk+-2.9.4/gdk' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/root/new/gtk+-2.9.4' > make: *** [all] Error 2 > > so kindly give feedback on this issue.. > > Thanks, > Karunakaran A. > > > > >> From: Suman Kar >> Reply-To: Suman Kar >> To: "'Attilio Fiandrotti'" , "'karuna >> karan'" >> CC: >> Subject: RE: Failed building GTK with the DFB backend >> Date: Tue, 27 Jun 2006 16:51:13 +0530 >> >> Hello Attilio, >> >> Thanks for the quick update. However, the problem goes away when we added >> the following: >> >> gboolean >> gdk_screen_is_composited (GdkScreen *screen) >> { >> g_return_val_if_fail (GDK_IS_SCREEN (screen), NULL); >> return FALSE; >> } >> >> >> is added to gdkscreen-directfb.c (from >> http://mail.gnome.org/archives/gtk-devel-list/2006-May/msg00210.html ). >> >> We will definitely try building gtk+2.9.4 and will get back in case there >> are any issues. >> >> One more thing: we would be really interested in gtk+-2.10. Any idea when >> this will be out? >> >> Regards, >> Suman. >> >> -----Original Message----- >> From: Attilio Fiandrotti [mailto:fiandro@tiscali.it] >> Sent: Tuesday, June 27, 2006 3:40 PM >> To: karuna karan >> Cc: gtk-devel-list@gnome.org; skar@tataelxsi.co.in >> Subject: Re: Failed building GTK with the DFB backend >> >> >> karuna karan wrote: >> > Hi all, >> > >> > I tried to build gtk 2.9.1 with directFB backend with following >> > dependencies, >> >> DFB support in was broken: you should try 2.9.4 or follow instructions >> in the wiki page to build from sratch. >> If you're a debian user, you can also use precompiled i386 official >> packages that were built this week >> >> http://download.dajobe.org/debian/experimental/ <-cairodfb >> http://people.debian.org/~joss/packages/ <-gtkdfb >> >> Attilio >> >> The information contained in this electronic message and any >> attachments to this message are intended for the exclusive use of the >> addressee(s)and may contain confidential or privileged information. If >> you are not the intended recipient, please notify the sender or >> administrator@tataelxsi.co.in > > > _________________________________________________________________ > Express yourself instantly with MSN Messenger! Download today - it's > FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ > > From mail2karuna@hotmail.com Wed Jun 28 04:51:51 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 8EFB63B0079 for ; Wed, 28 Jun 2006 04:51:51 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00776-08 for ; Wed, 28 Jun 2006 04:51:50 -0400 (EDT) Received: from hotmail.com (bay123-f31.bay123.hotmail.com [207.46.11.111]) by menubar.gnome.org (Postfix) with ESMTP id 2CB433B0005 for ; Wed, 28 Jun 2006 04:51:50 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 28 Jun 2006 01:50:10 -0700 Message-ID: Received: from 207.46.11.123 by by123fd.bay123.hotmail.msn.com with HTTP; Wed, 28 Jun 2006 08:50:07 GMT X-Originating-IP: [62.193.226.74] X-Originating-Email: [mail2karuna@hotmail.com] X-Sender: mail2karuna@hotmail.com In-Reply-To: <44A23718.3020008@tiscali.it> From: "karuna karan" To: fiandro@tiscali.it Subject: Re: Failed building GTK with the DFB backend Date: Wed, 28 Jun 2006 08:50:07 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 28 Jun 2006 08:50:10.0376 (UTC) FILETIME=[DCE6EC80:01C69A8F] X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=1.17 tagged_above=-999 required=2 tests=[AWL=-3.240, BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2, DNS_FROM_RFC_POST=1.708, MSGID_FROM_MTA_HEADER=0, RCVD_IN_BL_SPAMCOP_NET=1.558, RCVD_IN_SBL=3.16, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, TW_DF=0.077, TW_GD=0.077, TW_GT=0.077, TW_KD=0.077, TW_TK=0.077] X-Spam-Score: 1.17 X-Spam-Level: * Cc: gtk-devel-list@gnome.org, skar@tataelxsi.co.in, amirthakaruna@tataelxsi.co.in X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2006 08:51:51 -0000 hi, we are already working with DirectFB 0.9.25.1 and GTK 2.9.4(released) we will start work with GTK 2.9.4 from CVS as suggested by you. we will get back if any issue arises. Thanks, Karunakaran A. >From: Attilio Fiandrotti >A couple of days ago mike checked in the patch that excludes from >compilation some extra code that requires DFB 0.9.25 in the case DFN 0.9.24 >is used. >Use CVS sources or apply to GTK 2.9.4 gdkdirectfb.h and >gdkwindow-directfb.c from current SVN. >If you're a Debian user and run on i386, simply install cairodfb and gtkdfb >packages [1] which were made recently available (other archs will follow >soon). > >Attilio > >[1] http://mail.directfb.org/pipermail/directfb-dev/2006-June/001973.html > >karuna karan wrote: >>Hi, >> >>we have tried to build gtk+ 2.9.4 with backend dfb. >>we got the follwing error while building, >> >>gdkwindow-directfb.c: In function `gdk_directfb_create_child_window': >>gdkwindow-directfb.c:2508: error: structure has no member named >>`GetPosition' >>make[4]: *** [gdkwindow-directfb.lo] Error 1 >>make[4]: Leaving directory `/root/new/gtk+-2.9.4/gdk/directfb' >>make[3]: *** [all-recursive] Error 1 >>make[3]: Leaving directory `/root/new/gtk+-2.9.4/gdk' >>make[2]: *** [all] Error 2 >>make[2]: Leaving directory `/root/new/gtk+-2.9.4/gdk' >>make[1]: *** [all-recursive] Error 1 >>make[1]: Leaving directory `/root/new/gtk+-2.9.4' >>make: *** [all] Error 2 >> >>so kindly give feedback on this issue.. >> >>Thanks, >>Karunakaran A. >> >> >> >> >>>From: Suman Kar >>>Reply-To: Suman Kar >>>To: "'Attilio Fiandrotti'" , "'karuna karan'" >>> >>>CC: >>>Subject: RE: Failed building GTK with the DFB backend >>>Date: Tue, 27 Jun 2006 16:51:13 +0530 >>> >>>Hello Attilio, >>> >>>Thanks for the quick update. However, the problem goes away when we added >>>the following: >>> >>>gboolean >>>gdk_screen_is_composited (GdkScreen *screen) >>>{ >>> g_return_val_if_fail (GDK_IS_SCREEN (screen), NULL); >>> return FALSE; >>>} >>> >>> >>>is added to gdkscreen-directfb.c (from >>>http://mail.gnome.org/archives/gtk-devel-list/2006-May/msg00210.html ). >>> >>>We will definitely try building gtk+2.9.4 and will get back in case there >>>are any issues. >>> >>>One more thing: we would be really interested in gtk+-2.10. Any idea when >>>this will be out? >>> >>>Regards, >>>Suman. >>> >>>-----Original Message----- >>>From: Attilio Fiandrotti [mailto:fiandro@tiscali.it] >>>Sent: Tuesday, June 27, 2006 3:40 PM >>>To: karuna karan >>>Cc: gtk-devel-list@gnome.org; skar@tataelxsi.co.in >>>Subject: Re: Failed building GTK with the DFB backend >>> >>> >>>karuna karan wrote: >>> > Hi all, >>> > >>> > I tried to build gtk 2.9.1 with directFB backend with following >>> > dependencies, >>> >>>DFB support in was broken: you should try 2.9.4 or follow instructions >>>in the wiki page to build from sratch. >>>If you're a debian user, you can also use precompiled i386 official >>>packages that were built this week >>> >>>http://download.dajobe.org/debian/experimental/ <-cairodfb >>>http://people.debian.org/~joss/packages/ <-gtkdfb >>> >>>Attilio >>> >>>The information contained in this electronic message and any attachments >>>to this message are intended for the exclusive use of the addressee(s)and >>>may contain confidential or privileged information. If you are not the >>>intended recipient, please notify the sender or >>>administrator@tataelxsi.co.in >> >> >>_________________________________________________________________ >>Express yourself instantly with MSN Messenger! Download today - it's FREE! >>http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ >> >> > _________________________________________________________________ Dont just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/ From mail2karuna@hotmail.com Wed Jun 28 04:57:44 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id EB6A23B00A2 for ; Wed, 28 Jun 2006 04:57:43 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01098-06 for ; Wed, 28 Jun 2006 04:57:42 -0400 (EDT) Received: from bay0-omc3-s25.bay0.hotmail.com (bay0-omc3-s25.bay0.hotmail.com [65.54.246.225]) by menubar.gnome.org (Postfix) with ESMTP id 8E64F3B0002 for ; Wed, 28 Jun 2006 04:57:42 -0400 (EDT) Received: from hotmail.com ([207.46.11.110]) by bay0-omc3-s25.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Jun 2006 01:57:15 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 28 Jun 2006 01:57:15 -0700 Message-ID: Received: from 207.46.11.123 by by123fd.bay123.hotmail.msn.com with HTTP; Wed, 28 Jun 2006 08:57:12 GMT X-Originating-IP: [62.193.235.46] X-Originating-Email: [mail2karuna@hotmail.com] X-Sender: mail2karuna@hotmail.com In-Reply-To: <006101c69a90$871e5d00$361b320a@telxsi.com> From: "karuna karan" To: gtk-devel-list@gnome.org Subject: RE: Failed building GTK with the DFB backend Date: Wed, 28 Jun 2006 08:57:12 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 28 Jun 2006 08:57:15.0331 (UTC) FILETIME=[DA31E930:01C69A90] X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-0.194 tagged_above=-999 required=2 tests=[AWL=-1.445, BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2, DNS_FROM_RFC_POST=1.708, MSGID_FROM_MTA_HEADER=0, RCVD_IN_BL_SPAMCOP_NET=1.558, SPF_PASS=-0.001, TW_DF=0.077, TW_GD=0.077, TW_GT=0.077, TW_KD=0.077, TW_TK=0.077] X-Spam-Score: -0.194 X-Spam-Level: Cc: amirthakaruna@tataelxsi.co.in, skar@tataelxsi.co.in X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2006 08:57:44 -0000 hi, we are already working with DirectFB 0.9.25.1 and GTK 2.9.4(released) we will start work with GTK 2.9.4 from CVS as suggested by you. we will get back if any issue arises. Thanks, Karunakaran A. >From: Attilio Fiandrotti >A couple of days ago mike checked in the patch that excludes from >compilation some extra code that requires DFB 0.9.25 in the case DFN 0.9.24 >is used. >Use CVS sources or apply to GTK 2.9.4 gdkdirectfb.h and >gdkwindow-directfb.c from current SVN. >If you're a Debian user and run on i386, simply install cairodfb and gtkdfb >packages [1] which were made recently available (other archs will follow >soon). > >Attilio > >[1] http://mail.directfb.org/pipermail/directfb-dev/2006-June/001973.html > >karuna karan wrote: >>Hi, >> >>we have tried to build gtk+ 2.9.4 with backend dfb. >>we got the follwing error while building, >> >>gdkwindow-directfb.c: In function `gdk_directfb_create_child_window': >>gdkwindow-directfb.c:2508: error: structure has no member named >>`GetPosition' >>make[4]: *** [gdkwindow-directfb.lo] Error 1 >>make[4]: Leaving directory `/root/new/gtk+-2.9.4/gdk/directfb' >>make[3]: *** [all-recursive] Error 1 >>make[3]: Leaving directory `/root/new/gtk+-2.9.4/gdk' >>make[2]: *** [all] Error 2 >>make[2]: Leaving directory `/root/new/gtk+-2.9.4/gdk' >>make[1]: *** [all-recursive] Error 1 >>make[1]: Leaving directory `/root/new/gtk+-2.9.4' >>make: *** [all] Error 2 >> >>so kindly give feedback on this issue.. >> >>Thanks, >>Karunakaran A. >> >> >> >> >>>From: Suman Kar >>>Reply-To: Suman Kar >>>To: "'Attilio Fiandrotti'" , "'karuna karan'" >>> >>>CC: >>>Subject: RE: Failed building GTK with the DFB backend >>>Date: Tue, 27 Jun 2006 16:51:13 +0530 >>> >>>Hello Attilio, >>> >>>Thanks for the quick update. However, the problem goes away when we added >>>the following: >>> >>>gboolean >>>gdk_screen_is_composited (GdkScreen *screen) >>>{ >>> g_return_val_if_fail (GDK_IS_SCREEN (screen), NULL); >>> return FALSE; >>>} >>> >>> >>>is added to gdkscreen-directfb.c (from >>>http://mail.gnome.org/archives/gtk-devel-list/2006-May/msg00210.html ). >>> >>>We will definitely try building gtk+2.9.4 and will get back in case there > >>>are any issues. > >>> > >>>One more thing: we would be really interested in gtk+-2.10. Any idea >when > >>>this will be out? > >>> > >>>Regards, > >>>Suman. > >>> > >>>-----Original Message----- > >>>From: Attilio Fiandrotti [mailto:fiandro@tiscali.it] > >>>Sent: Tuesday, June 27, 2006 3:40 PM > >>>To: karuna karan > >>>Cc: gtk-devel-list@gnome.org; skar@tataelxsi.co.in > >>>Subject: Re: Failed building GTK with the DFB backend > >>> > >>> > >>>karuna karan wrote: > >>> > Hi all, > >>> > > >>> > I tried to build gtk 2.9.1 with directFB backend with following > >>> > dependencies, > >>> > >>>DFB support in was broken: you should try 2.9.4 or follow instructions > >>>in the wiki page to build from sratch. > >>>If you're a debian user, you can also use precompiled i386 official > >>>packages that were built this week > >>> > >>>http://download.dajobe.org/debian/experimental/ <-cairodfb > >>>http://people.debian.org/~joss/packages/ <-gtkdfb > >>> > >>>Attilio > >>> > >>>The information contained in this electronic message and any >attachments > >>>to this message are intended for the exclusive use of the >addressee(s)and > >>>may contain confidential or privileged information. If you are not the > >>>intended recipient, please notify the sender or > >>>administrator@tataelxsi.co.in > >> > >> > >>_________________________________________________________________ > >>Express yourself instantly with MSN Messenger! Download today - it's >FREE! > >>http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ > >> > >> > > > >_________________________________________________________________ >Dont just search. Find. Check out the new MSN Search! >http://search.msn.click-url.com/go/onm00200636ave/direct/01/ > >The information contained in this electronic message and any attachments to >this message are intended for the exclusive use of the addressee(s)and may >contain confidential or privileged information. If you are not the intended >recipient, please notify the sender or administrator@tataelxsi.co.in _________________________________________________________________ Dont just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/ From dave.foster@gmail.com Tue Jun 27 23:09:46 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id A42223B0010 for ; Tue, 27 Jun 2006 23:09:46 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25505-01 for ; Tue, 27 Jun 2006 23:09:45 -0400 (EDT) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.225]) by menubar.gnome.org (Postfix) with ESMTP id CEB183B0005 for ; Tue, 27 Jun 2006 23:09:44 -0400 (EDT) Received: by wr-out-0506.google.com with SMTP id i4so303425wra for ; Tue, 27 Jun 2006 20:08:24 -0700 (PDT) Received: by 10.54.80.7 with SMTP id d7mr394957wrb; Tue, 27 Jun 2006 20:08:24 -0700 (PDT) Received: from ?192.168.1.107? ( [68.0.246.8]) by mx.gmail.com with ESMTP id 64sm2194346wra.2006.06.27.20.08.24; Tue, 27 Jun 2006 20:08:24 -0700 (PDT) Subject: gdk_display_close segfault? From: Dave Foster To: gtk-devel-list@gnome.org Content-Type: text/plain Date: Wed, 28 Jun 2006 01:01:55 -0400 Message-Id: <1151470915.4791.3.camel@neptune.minuslab.net> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.6 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.6 X-Spam-Level: X-Mailman-Approved-At: Wed, 28 Jun 2006 07:11:10 -0400 X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2006 03:09:46 -0000 Hi, I've been trying to write a small section of code in my program which makes a second connection to the X display, using gtkmm.. I kept having problems, after rewriting it about 5 or 6 times, I tried writing it in straight gdk, and STILL got the problems. I seem to get a segfault whenever I call gdk_display_close(). Here is a rediculously simple example that gives the problem: Glib::ustring disp = ":0.0"; GdkDisplay* gdisp = gdk_display_open(disp.c_str()); if (!gdisp) ... gdk_display_close(gdisp); /* Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1224202560 (LWP 5689)] 0xb7b413d0 in gdk_display_x11_dispose () from /usr/lib/libgdk-x11-2.0.so.0 (gdb) bt #0 0xb7b413d0 in gdk_display_x11_dispose () from /usr/lib/libgdk-x11-2.0.so.0 #1 0xb7a11f2b in g_object_unref () from /usr/lib/libgobject-2.0.so.0 #2 0xb7b20c04 in gdk_display_close () from /usr/lib/libgdk-x11-2.0.so.0 #3 0x080571d5 in SetBG::set_bg (disp=@0xbfe1b2b0, file=@0xbfe1b2ac, mode=SetBG::SET_SCALE, bgcolor=@0xbfe1b2a8) at SetBG.cc:67 ... */ The display is opening fine. I'm running: gtk: 2.8.17-1 glib: 2.10.2-1 (hmm, didn't notice that before,t he 2.8 vs 2.10 thing, could that be it?) Anyway, I've spent all night trying to debug this and weeks trying to sort this problem out in my program. What is up with this, what can I do? thanks all. dave From fiandro@tiscali.it Wed Jun 28 07:47:12 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id EF7893B0087 for ; Wed, 28 Jun 2006 07:47:11 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08611-03 for ; Wed, 28 Jun 2006 07:47:10 -0400 (EDT) Received: from polito.it (anacreon.polito.it [130.192.3.82]) by menubar.gnome.org (Postfix) with ESMTP id AEB163B00A0 for ; Wed, 28 Jun 2006 07:47:09 -0400 (EDT) X-ExtScanner: Niversoft's FindAttachments (free) Received: from [130.192.31.127] (HELO [130.192.31.127]) by anacreon.polito.it (CommuniGate Pro SMTP 5.0.9) with ESMTP id 39386694; Wed, 28 Jun 2006 13:46:14 +0200 Message-ID: <44A26D1D.9090905@tiscali.it> Date: Wed, 28 Jun 2006 13:50:53 +0200 From: Attilio Fiandrotti User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.13) Gecko/20060620 Debian/1.7.13-0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Suman Kar Subject: Re: Failed building GTK with the DFB backend References: <000101c69aa6$6547c9d0$381b320a@telxsi.com> In-Reply-To: <000101c69aa6$6547c9d0$381b320a@telxsi.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.35 tagged_above=-999 required=2 tests=[AWL=-0.540, BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2, FORGED_RCVD_HELO=0.135, SPF_NEUTRAL=1.069, TW_DF=0.077, TW_GD=0.077, TW_GT=0.077, TW_KD=0.077, TW_TK=0.077] X-Spam-Score: -1.35 X-Spam-Level: Cc: gtk-devel-list@gnome.org, amirthakaruna@tataelxsi.co.in X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2006 11:47:12 -0000 I apologize for my mistake: only now i realize taht getposition() and getsize() were introduced *after* DFB 0.9.25 was released! Yesterday mike checked in a patch ("Added ifdef to compile with 0.9.24 removes creating a child GdkWindow since it u...") that allows GTK+ to be compiled against DFB >= 0.9.24 (so, also 0.9.25 will do) The correct recipe is: DFB >= 0.9.24 GTK+ HEAD from CVS Attilio Suman Kar wrote: > Hello Attilio, > > Let me try to explain Karuna's problem: we are using the > downloadable source tarball from > http://directfb.org/index.php?path=Main%2FDownloads: > DirectFB-0.9.25.1.tar.gz > > Also, this was released on 03-May-2006. Mike's checkin has happened > on 11-June-2006. Moreover, we could not find the GetPosition() > member in either the http://directfb.org/index.php?path=Main%2FNews > page or in the source files Mike has mentioned in the mail to > the directFB list. > > These indicates to me that this is not really an issue with some path > variable as you suggested. Your inputs are awaited. > > Regards, > Suman. > > -----Original Message----- > From: Attilio Fiandrotti [mailto:fiandro@tiscali.it] > Sent: Wednesday, June 28, 2006 3:03 PM > To: karuna karan > Cc: skar@tataelxsi.co.in; amirthakaruna@tataelxsi.co.in > Subject: Re: Failed building GTK with the DFB backend > > > the symbol GetPosition (and getsize, too) were introduced in DFB 0.9.25 > : if you're trying to compile GTKDFB against DFB 0.9.25, then you must > have provided wrong pkg_config_path or ld_library_path > > Attilio > > karuna karan wrote: > >>hi, >> >>we are already working with DirectFB 0.9.25.1 and GTK 2.9.4(released) >> >>we will start work with GTK 2.9.4 from CVS as suggested by you. >> >>we will get back if any issue arises. >> >>Thanks, >>Karunakaran A. >> >> >> >> >From: Attilio Fiandrotti >> >> >A couple of days ago mike checked in the patch that excludes from >> >compilation some extra code that requires DFB 0.9.25 in the case DFN >>0.9.24 >> >is used. >> >Use CVS sources or apply to GTK 2.9.4 gdkdirectfb.h and >> >gdkwindow-directfb.c from current SVN. >> >If you're a Debian user and run on i386, simply install cairodfb and >>gtkdfb >> >packages [1] which were made recently available (other archs will follow >> >soon). >> > >> >Attilio >> > >> >[1] > > http://mail.directfb.org/pipermail/directfb-dev/2006-June/001973.html > >> > >> >karuna karan wrote: >> >>Hi, >> >> >> >>we have tried to build gtk+ 2.9.4 with backend dfb. >> >>we got the follwing error while building, >> >> >> >>gdkwindow-directfb.c: In function `gdk_directfb_create_child_window': >> >>gdkwindow-directfb.c:2508: error: structure has no member named >> >>`GetPosition' >> >>make[4]: *** [gdkwindow-directfb.lo] Error 1 >> >>make[4]: Leaving directory `/root/new/gtk+-2.9.4/gdk/directfb' >> >>make[3]: *** [all-recursive] Error 1 >> >>make[3]: Leaving directory `/root/new/gtk+-2.9.4/gdk' >> >>make[2]: *** [all] Error 2 >> >>make[2]: Leaving directory `/root/new/gtk+-2.9.4/gdk' >> >>make[1]: *** [all-recursive] Error 1 >> >>make[1]: Leaving directory `/root/new/gtk+-2.9.4' >> >>make: *** [all] Error 2 >> >> >> >>so kindly give feedback on this issue.. >> >> >> >>Thanks, >> >>Karunakaran A. >> >> >> >> >> >> >> >> >> >>>From: Suman Kar >> >>>Reply-To: Suman Kar >> >>>To: "'Attilio Fiandrotti'" , "'karuna >>karan'" >> >>> >> >>>CC: >> >>>Subject: RE: Failed building GTK with the DFB backend >> >>>Date: Tue, 27 Jun 2006 16:51:13 +0530 >> >>> >> >>>Hello Attilio, >> >>> >> >>>Thanks for the quick update. However, the problem goes away when we >>added >> >>>the following: >> >>> >> >>>gboolean >> >>>gdk_screen_is_composited (GdkScreen *screen) >> >>>{ >> >>> g_return_val_if_fail (GDK_IS_SCREEN (screen), NULL); >> >>> return FALSE; >> >>>} >> >>> >> >>> >> >>>is added to gdkscreen-directfb.c (from >> >> >>>>>http://mail.gnome.org/archives/gtk-devel-list/2006-May/msg00210.html ). >> >> >>> >> >>>We will definitely try building gtk+2.9.4 and will get back in case >>there >> >> >>>>>>are any issues. >>>>>> >>>>>>One more thing: we would be really interested in gtk+-2.10. Any >>> >>>idea when >>> >>>>>>this will be out? >>>>>> >>>>>>Regards, >>>>>>Suman. >>>>>> >>>>>>-----Original Message----- >>>>>>From: Attilio Fiandrotti [mailto:fiandro@tiscali.it] >>>>>>Sent: Tuesday, June 27, 2006 3:40 PM >>>>>>To: karuna karan >>>>>>Cc: gtk-devel-list@gnome.org; skar@tataelxsi.co.in >>>>>>Subject: Re: Failed building GTK with the DFB backend >>>>>> >>>>>> >>>>>>karuna karan wrote: >>>>>> >>>>>>>Hi all, >>>>>>> >>>>>>>I tried to build gtk 2.9.1 with directFB backend with following >>>>>>>dependencies, >>>>>> >>>>>>DFB support in was broken: you should try 2.9.4 or follow instructions >>>>>>in the wiki page to build from sratch. >>>>>>If you're a debian user, you can also use precompiled i386 official >>>>>>packages that were built this week >>>>>> >>>>>>http://download.dajobe.org/debian/experimental/ <-cairodfb >>>>>>http://people.debian.org/~joss/packages/ <-gtkdfb >>>>>> >>>>>>Attilio >>>>>> >>>>>>The information contained in this electronic message and any >>> >>>attachments >>> >>>>>>to this message are intended for the exclusive use of the >>> >>>addressee(s)and >>> >>>>>>may contain confidential or privileged information. If you are not the >>>>>>intended recipient, please notify the sender or >>>>>>administrator@tataelxsi.co.in >>>>> >>>>> >>>>>_________________________________________________________________ >>>>>Express yourself instantly with MSN Messenger! Download today - it's >>> >>>FREE! >>> >>>>>http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ >>>>> >>>>> >>>> >>>_________________________________________________________________ >>>Dont just search. Find. Check out the new MSN Search! >>>http://search.msn.click-url.com/go/onm00200636ave/direct/01/ >>> >>>The information contained in this electronic message and any >>>attachments to this message are intended for the exclusive use of the >>>addressee(s)and may contain confidential or privileged information. If >>>you are not the intended recipient, please notify the sender or >>>administrator@tataelxsi.co.in >> >> >>_________________________________________________________________ >>Dont just search. Find. Check out the new MSN Search! >>http://search.msn.click-url.com/go/onm00200636ave/direct/01/ >> >> >> >> >>------------------------------------------------------------------------ >> >>The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s)and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender or administrator@tataelxsi.co.in From skar@tataelxsi.co.in Wed Jun 28 07:31:56 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id B3F193B006C for ; Wed, 28 Jun 2006 07:31:56 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07955-07 for ; Wed, 28 Jun 2006 07:31:55 -0400 (EDT) Received: from mail.tataelxsi.co.in (mail.tataelxsi.co.in [203.200.1.48]) by menubar.gnome.org (Postfix) with ESMTP id 0CA9D3B00F3 for ; Wed, 28 Jun 2006 07:31:53 -0400 (EDT) Received: from skar (tataelxsi.co.in [203.197.169.80] (may be forged)) by mail.tataelxsi.co.in (MOS 3.7.4b-GA) with ESMTP id BRJ72122 (AUTH skar); Wed, 28 Jun 2006 17:02:27 +0530 (IST) From: Suman Kar To: "'Attilio Fiandrotti'" , Subject: RE: Failed building GTK with the DFB backend Date: Wed, 28 Jun 2006 17:01:26 +0530 Message-ID: <000101c69aa6$6547c9d0$381b320a@telxsi.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <44A24CDC.4070707@tiscali.it> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Junkmail: Blacklisted Content-Type: multipart/mixed; boundary="MIRAPOINT_PART1_44a268cc" X-Mirapoint-Sig: mail.tataelxsi.co.in X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.291 tagged_above=-999 required=2 tests=[AWL=-0.635, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.558, TW_DF=0.077, TW_GD=0.077, TW_GT=0.077, TW_KD=0.077, TW_TK=0.077] X-Spam-Score: -1.291 X-Spam-Level: X-Mailman-Approved-At: Wed, 28 Jun 2006 08:28:51 -0400 Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: Suman Kar List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2006 11:31:56 -0000 --MIRAPOINT_PART1_44a268cc Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 8bit Hello Attilio, Let me try to explain Karuna's problem: we are using the downloadable source tarball from http://directfb.org/index.php?path=Main%2FDownloads: DirectFB-0.9.25.1.tar.gz Also, this was released on 03-May-2006. Mike's checkin has happened on 11-June-2006. Moreover, we could not find the GetPosition() member in either the http://directfb.org/index.php?path=Main%2FNews page or in the source files Mike has mentioned in the mail to the directFB list. These indicates to me that this is not really an issue with some path variable as you suggested. Your inputs are awaited. Regards, Suman. -----Original Message----- From: Attilio Fiandrotti [mailto:fiandro@tiscali.it] Sent: Wednesday, June 28, 2006 3:03 PM To: karuna karan Cc: skar@tataelxsi.co.in; amirthakaruna@tataelxsi.co.in Subject: Re: Failed building GTK with the DFB backend the symbol GetPosition (and getsize, too) were introduced in DFB 0.9.25 : if you're trying to compile GTKDFB against DFB 0.9.25, then you must have provided wrong pkg_config_path or ld_library_path Attilio karuna karan wrote: > hi, > > we are already working with DirectFB 0.9.25.1 and GTK 2.9.4(released) > > we will start work with GTK 2.9.4 from CVS as suggested by you. > > we will get back if any issue arises. > > Thanks, > Karunakaran A. > > > > >From: Attilio Fiandrotti > > >A couple of days ago mike checked in the patch that excludes from > >compilation some extra code that requires DFB 0.9.25 in the case DFN > 0.9.24 > >is used. > >Use CVS sources or apply to GTK 2.9.4 gdkdirectfb.h and > >gdkwindow-directfb.c from current SVN. > >If you're a Debian user and run on i386, simply install cairodfb and > gtkdfb > >packages [1] which were made recently available (other archs will follow > >soon). > > > >Attilio > > > >[1] http://mail.directfb.org/pipermail/directfb-dev/2006-June/001973.html > > > >karuna karan wrote: > >>Hi, > >> > >>we have tried to build gtk+ 2.9.4 with backend dfb. > >>we got the follwing error while building, > >> > >>gdkwindow-directfb.c: In function `gdk_directfb_create_child_window': > >>gdkwindow-directfb.c:2508: error: structure has no member named > >>`GetPosition' > >>make[4]: *** [gdkwindow-directfb.lo] Error 1 > >>make[4]: Leaving directory `/root/new/gtk+-2.9.4/gdk/directfb' > >>make[3]: *** [all-recursive] Error 1 > >>make[3]: Leaving directory `/root/new/gtk+-2.9.4/gdk' > >>make[2]: *** [all] Error 2 > >>make[2]: Leaving directory `/root/new/gtk+-2.9.4/gdk' > >>make[1]: *** [all-recursive] Error 1 > >>make[1]: Leaving directory `/root/new/gtk+-2.9.4' > >>make: *** [all] Error 2 > >> > >>so kindly give feedback on this issue.. > >> > >>Thanks, > >>Karunakaran A. > >> > >> > >> > >> > >>>From: Suman Kar > >>>Reply-To: Suman Kar > >>>To: "'Attilio Fiandrotti'" , "'karuna > karan'" > >>> > >>>CC: > >>>Subject: RE: Failed building GTK with the DFB backend > >>>Date: Tue, 27 Jun 2006 16:51:13 +0530 > >>> > >>>Hello Attilio, > >>> > >>>Thanks for the quick update. However, the problem goes away when we > added > >>>the following: > >>> > >>>gboolean > >>>gdk_screen_is_composited (GdkScreen *screen) > >>>{ > >>> g_return_val_if_fail (GDK_IS_SCREEN (screen), NULL); > >>> return FALSE; > >>>} > >>> > >>> > >>>is added to gdkscreen-directfb.c (from > >>>> http://mail.gnome.org/archives/gtk-devel-list/2006-May/msg00210.html ). > > >>> > >>>We will definitely try building gtk+2.9.4 and will get back in case > there > >> >>>are any issues. >> >>> >> >>>One more thing: we would be really interested in gtk+-2.10. Any >> idea when >> >>>this will be out? >> >>> >> >>>Regards, >> >>>Suman. >> >>> >> >>>-----Original Message----- >> >>>From: Attilio Fiandrotti [mailto:fiandro@tiscali.it] >> >>>Sent: Tuesday, June 27, 2006 3:40 PM >> >>>To: karuna karan >> >>>Cc: gtk-devel-list@gnome.org; skar@tataelxsi.co.in >> >>>Subject: Re: Failed building GTK with the DFB backend >> >>> >> >>> >> >>>karuna karan wrote: >> >>> > Hi all, >> >>> > >> >>> > I tried to build gtk 2.9.1 with directFB backend with following >> >>> > dependencies, >> >>> >> >>>DFB support in was broken: you should try 2.9.4 or follow instructions >> >>>in the wiki page to build from sratch. >> >>>If you're a debian user, you can also use precompiled i386 official >> >>>packages that were built this week >> >>> >> >>>http://download.dajobe.org/debian/experimental/ <-cairodfb >> >>>http://people.debian.org/~joss/packages/ <-gtkdfb >> >>> >> >>>Attilio >> >>> >> >>>The information contained in this electronic message and any >> attachments >> >>>to this message are intended for the exclusive use of the >> addressee(s)and >> >>>may contain confidential or privileged information. If you are not the >> >>>intended recipient, please notify the sender or >> >>>administrator@tataelxsi.co.in >> >> >> >> >> >>_________________________________________________________________ >> >>Express yourself instantly with MSN Messenger! Download today - it's >> FREE! >> >>http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ >> >> >> >> >> > >> >> _________________________________________________________________ >> Dont just search. Find. Check out the new MSN Search! >> http://search.msn.click-url.com/go/onm00200636ave/direct/01/ >> >> The information contained in this electronic message and any >> attachments to this message are intended for the exclusive use of the >> addressee(s)and may contain confidential or privileged information. If >> you are not the intended recipient, please notify the sender or >> administrator@tataelxsi.co.in > > > _________________________________________________________________ > Dont just search. Find. Check out the new MSN Search! > http://search.msn.click-url.com/go/onm00200636ave/direct/01/ > > --MIRAPOINT_PART1_44a268cc Content-Disposition: inline The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s)and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender or administrator@tataelxsi.co.in --MIRAPOINT_PART1_44a268cc-- From skar@tataelxsi.co.in Wed Jun 28 08:09:32 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id B55753B016E for ; Wed, 28 Jun 2006 08:09:32 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09711-02 for ; Wed, 28 Jun 2006 08:09:31 -0400 (EDT) Received: from mail.tataelxsi.co.in (mail.tataelxsi.co.in [203.200.1.48]) by menubar.gnome.org (Postfix) with ESMTP id B45AB3B01C1 for ; Wed, 28 Jun 2006 08:09:29 -0400 (EDT) Received: from skar (tataelxsi.co.in [203.197.169.80] (may be forged)) by mail.tataelxsi.co.in (MOS 3.7.4b-GA) with ESMTP id BRJ80256 (AUTH skar); Wed, 28 Jun 2006 17:40:28 +0530 (IST) From: Suman Kar To: "'Attilio Fiandrotti'" Subject: RE: Failed building GTK with the DFB backend Date: Wed, 28 Jun 2006 17:39:28 +0530 Message-ID: <000801c69aab$b5138bc0$381b320a@telxsi.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <44A26D1D.9090905@tiscali.it> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Junkmail: Blacklisted Content-Type: multipart/mixed; boundary="MIRAPOINT_PART1_44a271b6" X-Mirapoint-Sig: mail.tataelxsi.co.in X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.227 tagged_above=-999 required=2 tests=[AWL=-0.571, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.558, TW_DF=0.077, TW_GD=0.077, TW_GT=0.077, TW_KD=0.077, TW_TK=0.077] X-Spam-Score: -1.227 X-Spam-Level: X-Mailman-Approved-At: Wed, 28 Jun 2006 08:29:04 -0400 Cc: gtk-devel-list@gnome.org, amirthakaruna@tataelxsi.co.in X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: Suman Kar List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2006 12:09:32 -0000 --MIRAPOINT_PART1_44a271b6 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 8bit Can you please post a link to Mike's change? URL to the CVS will do. I am a little confused as the GNOME cvs did not show any results when searching for entries by memmel and the directFB CVS did not throw up a check-in in the last two days. Regards, Suman. -----Original Message----- From: Attilio Fiandrotti [mailto:fiandro@tiscali.it] Sent: Wednesday, June 28, 2006 5:21 PM To: Suman Kar Cc: amirthakaruna@tataelxsi.co.in; gtk-devel-list@gnome.org Subject: Re: Failed building GTK with the DFB backend I apologize for my mistake: only now i realize taht getposition() and getsize() were introduced *after* DFB 0.9.25 was released! Yesterday mike checked in a patch ("Added ifdef to compile with 0.9.24 removes creating a child GdkWindow since it u...") that allows GTK+ to be compiled against DFB >= 0.9.24 (so, also 0.9.25 will do) The correct recipe is: DFB >= 0.9.24 GTK+ HEAD from CVS Attilio Suman Kar wrote: > Hello Attilio, > > Let me try to explain Karuna's problem: we are using the > downloadable source tarball from > http://directfb.org/index.php?path=Main%2FDownloads: > DirectFB-0.9.25.1.tar.gz > > Also, this was released on 03-May-2006. Mike's checkin has happened > on 11-June-2006. Moreover, we could not find the GetPosition() > member in either the http://directfb.org/index.php?path=Main%2FNews > page or in the source files Mike has mentioned in the mail to > the directFB list. > > These indicates to me that this is not really an issue with some path > variable as you suggested. Your inputs are awaited. > > Regards, > Suman. > > -----Original Message----- > From: Attilio Fiandrotti [mailto:fiandro@tiscali.it] > Sent: Wednesday, June 28, 2006 3:03 PM > To: karuna karan > Cc: skar@tataelxsi.co.in; amirthakaruna@tataelxsi.co.in > Subject: Re: Failed building GTK with the DFB backend > > > the symbol GetPosition (and getsize, too) were introduced in DFB 0.9.25 > : if you're trying to compile GTKDFB against DFB 0.9.25, then you must > have provided wrong pkg_config_path or ld_library_path > > Attilio > > karuna karan wrote: > >>hi, >> >>we are already working with DirectFB 0.9.25.1 and GTK 2.9.4(released) >> >>we will start work with GTK 2.9.4 from CVS as suggested by you. >> >>we will get back if any issue arises. >> >>Thanks, >>Karunakaran A. >> >> >> >> >From: Attilio Fiandrotti >> >> >A couple of days ago mike checked in the patch that excludes from >> >compilation some extra code that requires DFB 0.9.25 in the case DFN >>0.9.24 >> >is used. >> >Use CVS sources or apply to GTK 2.9.4 gdkdirectfb.h and >> >gdkwindow-directfb.c from current SVN. >> >If you're a Debian user and run on i386, simply install cairodfb and >>gtkdfb >> >packages [1] which were made recently available (other archs will follow >> >soon). >> > >> >Attilio >> > >> >[1] > > http://mail.directfb.org/pipermail/directfb-dev/2006-June/001973.html > >> > >> >karuna karan wrote: >> >>Hi, >> >> >> >>we have tried to build gtk+ 2.9.4 with backend dfb. >> >>we got the follwing error while building, >> >> >> >>gdkwindow-directfb.c: In function `gdk_directfb_create_child_window': >> >>gdkwindow-directfb.c:2508: error: structure has no member named >> >>`GetPosition' >> >>make[4]: *** [gdkwindow-directfb.lo] Error 1 >> >>make[4]: Leaving directory `/root/new/gtk+-2.9.4/gdk/directfb' >> >>make[3]: *** [all-recursive] Error 1 >> >>make[3]: Leaving directory `/root/new/gtk+-2.9.4/gdk' >> >>make[2]: *** [all] Error 2 >> >>make[2]: Leaving directory `/root/new/gtk+-2.9.4/gdk' >> >>make[1]: *** [all-recursive] Error 1 >> >>make[1]: Leaving directory `/root/new/gtk+-2.9.4' >> >>make: *** [all] Error 2 >> >> >> >>so kindly give feedback on this issue.. >> >> >> >>Thanks, >> >>Karunakaran A. >> >> >> >> >> >> >> >> >> >>>From: Suman Kar >> >>>Reply-To: Suman Kar >> >>>To: "'Attilio Fiandrotti'" , "'karuna >>karan'" >> >>> >> >>>CC: >> >>>Subject: RE: Failed building GTK with the DFB backend >> >>>Date: Tue, 27 Jun 2006 16:51:13 +0530 >> >>> >> >>>Hello Attilio, >> >>> >> >>>Thanks for the quick update. However, the problem goes away when we >>added >> >>>the following: >> >>> >> >>>gboolean >> >>>gdk_screen_is_composited (GdkScreen *screen) >> >>>{ >> >>> g_return_val_if_fail (GDK_IS_SCREEN (screen), NULL); >> >>> return FALSE; >> >>>} >> >>> >> >>> >> >>>is added to gdkscreen-directfb.c (from >> >> >>>>>http://mail.gnome.org/archives/gtk-devel-list/2006-May/msg00210.html ). >> >> >>> >> >>>We will definitely try building gtk+2.9.4 and will get back in case >>there >> >> >>>>>>are any issues. >>>>>> >>>>>>One more thing: we would be really interested in gtk+-2.10. Any >>> >>>idea when >>> >>>>>>this will be out? >>>>>> >>>>>>Regards, >>>>>>Suman. >>>>>> >>>>>>-----Original Message----- >>>>>>From: Attilio Fiandrotti [mailto:fiandro@tiscali.it] >>>>>>Sent: Tuesday, June 27, 2006 3:40 PM >>>>>>To: karuna karan >>>>>>Cc: gtk-devel-list@gnome.org; skar@tataelxsi.co.in >>>>>>Subject: Re: Failed building GTK with the DFB backend >>>>>> >>>>>> >>>>>>karuna karan wrote: >>>>>> >>>>>>>Hi all, >>>>>>> >>>>>>>I tried to build gtk 2.9.1 with directFB backend with following >>>>>>>dependencies, >>>>>> >>>>>>DFB support in was broken: you should try 2.9.4 or follow instructions >>>>>>in the wiki page to build from sratch. >>>>>>If you're a debian user, you can also use precompiled i386 official >>>>>>packages that were built this week >>>>>> >>>>>>http://download.dajobe.org/debian/experimental/ <-cairodfb >>>>>>http://people.debian.org/~joss/packages/ <-gtkdfb >>>>>> >>>>>>Attilio >>>>>> >>>>>>The information contained in this electronic message and any >>> >>>attachments >>> >>>>>>to this message are intended for the exclusive use of the >>> >>>addressee(s)and >>> >>>>>>may contain confidential or privileged information. If you are not the >>>>>>intended recipient, please notify the sender or >>>>>>administrator@tataelxsi.co.in >>>>> >>>>> >>>>>_________________________________________________________________ >>>>>Express yourself instantly with MSN Messenger! Download today - it's >>> >>>FREE! >>> >>>>>http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ >>>>> >>>>> >>>> >>>_________________________________________________________________ >>>Dont just search. Find. Check out the new MSN Search! >>>http://search.msn.click-url.com/go/onm00200636ave/direct/01/ >>> >>>The information contained in this electronic message and any >>>attachments to this message are intended for the exclusive use of the >>>addressee(s)and may contain confidential or privileged information. If >>>you are not the intended recipient, please notify the sender or >>>administrator@tataelxsi.co.in >> >> >>_________________________________________________________________ >>Dont just search. Find. Check out the new MSN Search! >>http://search.msn.click-url.com/go/onm00200636ave/direct/01/ >> >> >> >> >>------------------------------------------------------------------------ >> >>The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s)and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender or administrator@tataelxsi.co.in --MIRAPOINT_PART1_44a271b6 Content-Disposition: inline The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s)and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender or administrator@tataelxsi.co.in --MIRAPOINT_PART1_44a271b6-- From skar@tataelxsi.co.in Wed Jun 28 08:23:02 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 0B3E43B00B1 for ; Wed, 28 Jun 2006 08:23:02 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10159-01 for ; Wed, 28 Jun 2006 08:23:01 -0400 (EDT) Received: from mail.tataelxsi.co.in (mail.tataelxsi.co.in [203.200.1.48]) by menubar.gnome.org (Postfix) with ESMTP id 8F3FE3B006C for ; Wed, 28 Jun 2006 08:23:00 -0400 (EDT) Received: from skar (tataelxsi.co.in [203.197.169.80] (may be forged)) by mail.tataelxsi.co.in (MOS 3.7.4b-GA) with ESMTP id BRJ83266 (AUTH skar); Wed, 28 Jun 2006 17:53:15 +0530 (IST) From: Suman Kar To: "'Matthias Clasen'" Subject: RE: Failed building GTK with the DFB backend Date: Wed, 28 Jun 2006 17:52:15 +0530 Message-ID: <000a01c69aad$7e2b6270$381b320a@telxsi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Junkmail: Blacklisted X-Mirapoint-Sig: mail.tataelxsi.co.in X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-0.029 tagged_above=-999 required=2 tests=[AWL=-1.665, BAYES_50=0.001, RCVD_IN_BL_SPAMCOP_NET=1.558, TW_GT=0.077] X-Spam-Score: -0.029 X-Spam-Level: X-Mailman-Approved-At: Wed, 28 Jun 2006 08:29:19 -0400 Cc: gtk-devel-list@gnome.org, Karunakaran A X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: Suman Kar List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2006 12:23:02 -0000 Matthias, Thanks for the update! Regards, Suman. -----Original Message----- From: Matthias Clasen [mailto:matthias.clasen@gmail.com] Sent: Wednesday, June 28, 2006 12:39 PM To: Suman Kar Cc: Attilio Fiandrotti; karuna karan; gtk-devel-list@gnome.org Subject: Re: Failed building GTK with the DFB backend On 6/27/06, Suman Kar wrote: > One more thing: we would be really interested in gtk+-2.10. Any idea when > this will be out? > I'll start working on the release when I'm back from Guadec next week. The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s)and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender or administrator@tataelxsi.co.in From matthias.clasen@gmail.com Wed Jun 28 09:56:21 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id A02133B0238 for ; Wed, 28 Jun 2006 09:56:21 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14093-02 for ; Wed, 28 Jun 2006 09:56:20 -0400 (EDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.183]) by menubar.gnome.org (Postfix) with ESMTP id 9B78C3B017A for ; Wed, 28 Jun 2006 09:56:20 -0400 (EDT) Received: by py-out-1112.google.com with SMTP id c30so2229313pyc for ; Wed, 28 Jun 2006 06:55:43 -0700 (PDT) Received: by 10.35.63.2 with SMTP id q2mr140094pyk; Wed, 28 Jun 2006 06:55:43 -0700 (PDT) Received: by 10.35.39.16 with HTTP; Wed, 28 Jun 2006 06:55:43 -0700 (PDT) Message-ID: Date: Wed, 28 Jun 2006 09:55:43 -0400 From: "Matthias Clasen" To: "Dave Foster" Subject: Re: gdk_display_close segfault? In-Reply-To: <1151470915.4791.3.camel@neptune.minuslab.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1151470915.4791.3.camel@neptune.minuslab.net> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.41 tagged_above=-999 required=2 tests=[AWL=-0.010, BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2, SPF_PASS=-0.001] X-Spam-Score: -2.41 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2006 13:56:21 -0000 On 6/28/06, Dave Foster wrote: > Hi, > > I've been trying to write a small section of code in my program which > makes a second connection to the X display, using gtkmm.. I kept having > problems, after rewriting it about 5 or 6 times, I tried writing it in > straight gdk, and STILL got the problems. > > I seem to get a segfault whenever I call gdk_display_close(). Here is a > rediculously simple example that gives the problem: > > Glib::ustring disp = ":0.0"; > GdkDisplay* gdisp = gdk_display_open(disp.c_str()); > if (!gdisp) ... > gdk_display_close(gdisp); > > /* > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread -1224202560 (LWP 5689)] > 0xb7b413d0 in gdk_display_x11_dispose () from /usr/lib/libgdk-x11-2.0.so.0 > (gdb) bt > #0 0xb7b413d0 in gdk_display_x11_dispose () from /usr/lib/libgdk-x11-2.0.so.0 > #1 0xb7a11f2b in g_object_unref () from /usr/lib/libgobject-2.0.so.0 > #2 0xb7b20c04 in gdk_display_close () from /usr/lib/libgdk-x11-2.0.so.0 > #3 0x080571d5 in SetBG::set_bg (disp=@0xbfe1b2b0, file=@0xbfe1b2ac, > mode=SetBG::SET_SCALE, bgcolor=@0xbfe1b2a8) at SetBG.cc:67 > ... > */ > > The display is opening fine. I'm running: > > gtk: 2.8.17-1 > glib: 2.10.2-1 > > (hmm, didn't notice that before,t he 2.8 vs 2.10 thing, could that be it?) > > Anyway, I've spent all night trying to debug this and weeks trying to > sort this problem out in my program. What is up with this, what can I > do? gdk_display_close has been fixed in GTK+ 2.10, which should be available soon. From dave.foster@gmail.com Wed Jun 28 10:19:15 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 006DC3B02CA for ; Wed, 28 Jun 2006 10:19:15 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15554-01 for ; Wed, 28 Jun 2006 10:19:14 -0400 (EDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.193]) by menubar.gnome.org (Postfix) with ESMTP id 907993B02D3 for ; Wed, 28 Jun 2006 10:19:13 -0400 (EDT) Received: by wx-out-0102.google.com with SMTP id s15so69257wxc for ; Wed, 28 Jun 2006 07:18:46 -0700 (PDT) Received: by 10.70.49.13 with SMTP id w13mr1383280wxw; Wed, 28 Jun 2006 07:18:46 -0700 (PDT) Received: by 10.70.6.9 with HTTP; Wed, 28 Jun 2006 07:18:46 -0700 (PDT) Message-ID: Date: Wed, 28 Jun 2006 10:18:46 -0400 From: "Dave Foster" To: "Matthias Clasen" Subject: Re: gdk_display_close segfault? In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_68848_11799959.1151504326383" References: <1151470915.4791.3.camel@neptune.minuslab.net> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.399 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2, HTML_MESSAGE=0.001, SPF_PASS=-0.001] X-Spam-Score: -2.399 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2006 14:19:15 -0000 ------=_Part_68848_11799959.1151504326383 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline ok, thank you Matthias. dave On 6/28/06, Matthias Clasen wrote: > > On 6/28/06, Dave Foster wrote: > > Hi, > > > > I've been trying to write a small section of code in my program which > > makes a second connection to the X display, using gtkmm.. I kept having > > problems, after rewriting it about 5 or 6 times, I tried writing it in > > straight gdk, and STILL got the problems. > > > > I seem to get a segfault whenever I call gdk_display_close(). Here is a > > rediculously simple example that gives the problem: > > > > Glib::ustring disp = ":0.0"; > > GdkDisplay* gdisp = gdk_display_open(disp.c_str()); > > if (!gdisp) ... > > gdk_display_close(gdisp); > > > > /* > > Program received signal SIGSEGV, Segmentation fault. > > [Switching to Thread -1224202560 (LWP 5689)] > > 0xb7b413d0 in gdk_display_x11_dispose () from /usr/lib/libgdk- > x11-2.0.so.0 > > (gdb) bt > > #0 0xb7b413d0 in gdk_display_x11_dispose () from /usr/lib/libgdk- > x11-2.0.so.0 > > #1 0xb7a11f2b in g_object_unref () from /usr/lib/libgobject-2.0.so.0 > > #2 0xb7b20c04 in gdk_display_close () from /usr/lib/libgdk-x11-2.0.so.0 > > #3 0x080571d5 in SetBG::set_bg (disp=@0xbfe1b2b0, file=@0xbfe1b2ac, > > mode=SetBG::SET_SCALE, bgcolor=@0xbfe1b2a8) at SetBG.cc:67 > > ... > > */ > > > > The display is opening fine. I'm running: > > > > gtk: 2.8.17-1 > > glib: 2.10.2-1 > > > > (hmm, didn't notice that before,t he 2.8 vs 2.10 thing, could that be > it?) > > > > Anyway, I've spent all night trying to debug this and weeks trying to > > sort this problem out in my program. What is up with this, what can I > > do? > > gdk_display_close has been fixed in GTK+ 2.10, which should be > available soon. > ------=_Part_68848_11799959.1151504326383 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline ok, thank you Matthias.

dave

On 6/28/06, Matthias Clasen <matthias.clasen@gmail.com> wrote:
On 6/28/06, Dave Foster <dave.foster@gmail.com > wrote:
> Hi,
>
> I've been trying to write a small section of code in my program which
> makes a second connection to the X display, using gtkmm.. I kept having
> problems, after rewriting it about 5 or 6 times, I tried writing it in
> straight gdk, and STILL got the problems.
>
> I seem to get a segfault whenever I call gdk_display_close().  Here is a
> rediculously simple example that gives the problem:
>
> Glib::ustring disp = ": 0.0";
> GdkDisplay* gdisp = gdk_display_open(disp.c_str());
> if (!gdisp) ...
> gdk_display_close(gdisp);
>
> /*
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread -1224202560 (LWP 5689)]
> 0xb7b413d0 in gdk_display_x11_dispose () from /usr/lib/libgdk-x11-2.0.so.0
> (gdb) bt
> #0  0xb7b413d0 in gdk_display_x11_dispose () from /usr/lib/libgdk-x11-2.0.so.0
> #1  0xb7a11f2b in g_object_unref () from /usr/lib/libgobject- 2.0.so.0
> #2  0xb7b20c04 in gdk_display_close () from /usr/lib/libgdk-x11-2.0.so.0
> #3  0x080571d5 in SetBG::set_bg (disp=@0xbfe1b2b0, file=@0xbfe1b2ac,
>     mode=SetBG::SET_SCALE, bgcolor=@0xbfe1b2a8) at SetBG.cc:67
> ...
> */
>
> The display is opening fine.  I'm running:
>
> gtk: 2.8.17-1
> glib: 2.10.2-1
>
> (hmm, didn't notice that before,t he 2.8 vs 2.10 thing, could that be it?)
>
> Anyway, I've spent all night trying to debug this and weeks trying to
> sort this problem out in my program.  What is up with this, what can I
> do?

gdk_display_close has been fixed in GTK+ 2.10, which should  be
available soon.

------=_Part_68848_11799959.1151504326383-- From amirthakaruna@tataelxsi.co.in Wed Jun 28 10:30:48 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 6BE0F3B00A7 for ; Wed, 28 Jun 2006 10:30:48 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15942-08 for ; Wed, 28 Jun 2006 10:30:47 -0400 (EDT) Received: from mail.tataelxsi.co.in (mail.tataelxsi.co.in [203.200.1.48]) by menubar.gnome.org (Postfix) with ESMTP id 2C7823B00B0 for ; Wed, 28 Jun 2006 10:30:46 -0400 (EDT) Received: from amirthakaruna (tataelxsi.co.in [203.197.169.80] (may be forged)) by mail.tataelxsi.co.in (MOS 3.7.4b-GA) with ESMTP id BRK15473 (AUTH amirthakaruna); Wed, 28 Jun 2006 20:00:59 +0530 (IST) From: Karunakaran A To: "'Attilio Fiandrotti'" , "'Suman Kar'" Subject: RE: Failed building GTK with the DFB backend Date: Wed, 28 Jun 2006 20:00:01 +0530 Message-ID: <000601c69abf$5747eb80$361b320a@telxsi.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <44A26D1D.9090905@tiscali.it> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Junkmail: Blacklisted Content-Type: multipart/mixed; boundary="MIRAPOINT_PART1_44a292a6" X-Mirapoint-Sig: mail.tataelxsi.co.in X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-0.656 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.558, TW_DF=0.077, TW_GD=0.077, TW_GT=0.077, TW_KD=0.077, TW_TK=0.077] X-Spam-Score: -0.656 X-Spam-Level: X-Mailman-Approved-At: Thu, 29 Jun 2006 03:02:46 -0400 Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2006 14:30:48 -0000 --MIRAPOINT_PART1_44a292a6 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 8bit Hi all, We also tried to build gtk 2.8.18 with patch( gtk+-directfb.patch downloaded from https://debian.polito.it/downloads/gtk+-directfb.tar.bzip ) with DFB as a backend on a different machine. In that, the patch file alters only configure.in file, not the Makefile.in. so while building,it throws error in the directory `/root/gtkdfb/gtk+-2.8.18/gdk' as, make[4]: *** No rule to make target `libgdk-directfb-2.0.la',needed by `all-am'. help me out in this. Karunakaran A. -----Original Message----- From: Attilio Fiandrotti [mailto:fiandro@tiscali.it] Sent: Wednesday, June 28, 2006 5:21 PM To: Suman Kar Cc: amirthakaruna@tataelxsi.co.in; gtk-devel-list@gnome.org Subject: Re: Failed building GTK with the DFB backend I apologize for my mistake: only now i realize taht getposition() and getsize() were introduced *after* DFB 0.9.25 was released! Yesterday mike checked in a patch ("Added ifdef to compile with 0.9.24 removes creating a child GdkWindow since it u...") that allows GTK+ to be compiled against DFB >= 0.9.24 (so, also 0.9.25 will do) The correct recipe is: DFB >= 0.9.24 GTK+ HEAD from CVS Attilio Suman Kar wrote: > Hello Attilio, > > Let me try to explain Karuna's problem: we are using the > downloadable source tarball from > http://directfb.org/index.php?path=Main%2FDownloads: > DirectFB-0.9.25.1.tar.gz > > Also, this was released on 03-May-2006. Mike's checkin has happened > on 11-June-2006. Moreover, we could not find the GetPosition() > member in either the http://directfb.org/index.php?path=Main%2FNews > page or in the source files Mike has mentioned in the mail to > the directFB list. > > These indicates to me that this is not really an issue with some path > variable as you suggested. Your inputs are awaited. > > Regards, > Suman. > > -----Original Message----- > From: Attilio Fiandrotti [mailto:fiandro@tiscali.it] > Sent: Wednesday, June 28, 2006 3:03 PM > To: karuna karan > Cc: skar@tataelxsi.co.in; amirthakaruna@tataelxsi.co.in > Subject: Re: Failed building GTK with the DFB backend > > > the symbol GetPosition (and getsize, too) were introduced in DFB 0.9.25 > : if you're trying to compile GTKDFB against DFB 0.9.25, then you must > have provided wrong pkg_config_path or ld_library_path > > Attilio > > karuna karan wrote: > >>hi, >> >>we are already working with DirectFB 0.9.25.1 and GTK 2.9.4(released) >> >>we will start work with GTK 2.9.4 from CVS as suggested by you. >> >>we will get back if any issue arises. >> >>Thanks, >>Karunakaran A. >> >> >> >> >From: Attilio Fiandrotti >> >> >A couple of days ago mike checked in the patch that excludes from >> >compilation some extra code that requires DFB 0.9.25 in the case DFN >>0.9.24 >> >is used. >> >Use CVS sources or apply to GTK 2.9.4 gdkdirectfb.h and >> >gdkwindow-directfb.c from current SVN. >> >If you're a Debian user and run on i386, simply install cairodfb and >>gtkdfb >> >packages [1] which were made recently available (other archs will follow >> >soon). >> > >> >Attilio >> > >> >[1] > > http://mail.directfb.org/pipermail/directfb-dev/2006-June/001973.html > >> > >> >karuna karan wrote: >> >>Hi, >> >> >> >>we have tried to build gtk+ 2.9.4 with backend dfb. >> >>we got the follwing error while building, >> >> >> >>gdkwindow-directfb.c: In function `gdk_directfb_create_child_window': >> >>gdkwindow-directfb.c:2508: error: structure has no member named >> >>`GetPosition' >> >>make[4]: *** [gdkwindow-directfb.lo] Error 1 >> >>make[4]: Leaving directory `/root/new/gtk+-2.9.4/gdk/directfb' >> >>make[3]: *** [all-recursive] Error 1 >> >>make[3]: Leaving directory `/root/new/gtk+-2.9.4/gdk' >> >>make[2]: *** [all] Error 2 >> >>make[2]: Leaving directory `/root/new/gtk+-2.9.4/gdk' >> >>make[1]: *** [all-recursive] Error 1 >> >>make[1]: Leaving directory `/root/new/gtk+-2.9.4' >> >>make: *** [all] Error 2 >> >> >> >>so kindly give feedback on this issue.. >> >> >> >>Thanks, >> >>Karunakaran A. >> >> >> >> >> >> >> >> >> >>>From: Suman Kar >> >>>Reply-To: Suman Kar >> >>>To: "'Attilio Fiandrotti'" , "'karuna >>karan'" >> >>> >> >>>CC: >> >>>Subject: RE: Failed building GTK with the DFB backend >> >>>Date: Tue, 27 Jun 2006 16:51:13 +0530 >> >>> >> >>>Hello Attilio, >> >>> >> >>>Thanks for the quick update. However, the problem goes away when we >>added >> >>>the following: >> >>> >> >>>gboolean >> >>>gdk_screen_is_composited (GdkScreen *screen) >> >>>{ >> >>> g_return_val_if_fail (GDK_IS_SCREEN (screen), NULL); >> >>> return FALSE; >> >>>} >> >>> >> >>> >> >>>is added to gdkscreen-directfb.c (from >> >> >>>>>http://mail.gnome.org/archives/gtk-devel-list/2006-May/msg00210.html ). >> >> >>> >> >>>We will definitely try building gtk+2.9.4 and will get back in case >>there >> >> >>>>>>are any issues. >>>>>> >>>>>>One more thing: we would be really interested in gtk+-2.10. Any >>> >>>idea when >>> >>>>>>this will be out? >>>>>> >>>>>>Regards, >>>>>>Suman. >>>>>> >>>>>>-----Original Message----- >>>>>>From: Attilio Fiandrotti [mailto:fiandro@tiscali.it] >>>>>>Sent: Tuesday, June 27, 2006 3:40 PM >>>>>>To: karuna karan >>>>>>Cc: gtk-devel-list@gnome.org; skar@tataelxsi.co.in >>>>>>Subject: Re: Failed building GTK with the DFB backend >>>>>> >>>>>> >>>>>>karuna karan wrote: >>>>>> >>>>>>>Hi all, >>>>>>> >>>>>>>I tried to build gtk 2.9.1 with directFB backend with following >>>>>>>dependencies, >>>>>> >>>>>>DFB support in was broken: you should try 2.9.4 or follow instructions >>>>>>in the wiki page to build from sratch. >>>>>>If you're a debian user, you can also use precompiled i386 official >>>>>>packages that were built this week >>>>>> >>>>>>http://download.dajobe.org/debian/experimental/ <-cairodfb >>>>>>http://people.debian.org/~joss/packages/ <-gtkdfb >>>>>> >>>>>>Attilio >>>>>> >>>>>>The information contained in this electronic message and any >>> >>>attachments >>> >>>>>>to this message are intended for the exclusive use of the >>> >>>addressee(s)and >>> >>>>>>may contain confidential or privileged information. If you are not the >>>>>>intended recipient, please notify the sender or >>>>>>administrator@tataelxsi.co.in >>>>> >>>>> >>>>>_________________________________________________________________ >>>>>Express yourself instantly with MSN Messenger! Download today - it's >>> >>>FREE! >>> >>>>>http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ >>>>> >>>>> >>>> >>>_________________________________________________________________ >>>Dont just search. Find. Check out the new MSN Search! >>>http://search.msn.click-url.com/go/onm00200636ave/direct/01/ >>> >>>The information contained in this electronic message and any >>>attachments to this message are intended for the exclusive use of the >>>addressee(s)and may contain confidential or privileged information. If >>>you are not the intended recipient, please notify the sender or >>>administrator@tataelxsi.co.in >> >> >>_________________________________________________________________ >>Dont just search. Find. Check out the new MSN Search! >>http://search.msn.click-url.com/go/onm00200636ave/direct/01/ >> >> >> >> >>------------------------------------------------------------------------ >> >>The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s)and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender or administrator@tataelxsi.co.in --MIRAPOINT_PART1_44a292a6 Content-Disposition: inline The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s)and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender or administrator@tataelxsi.co.in --MIRAPOINT_PART1_44a292a6-- From jalaganapathy@tataelxsi.co.in Thu Jun 29 03:08:28 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 62B543B03EF for ; Thu, 29 Jun 2006 03:08:28 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24602-01 for ; Thu, 29 Jun 2006 03:08:26 -0400 (EDT) Received: from mail.tataelxsi.co.in (mail.tataelxsi.co.in [203.200.1.48]) by menubar.gnome.org (Postfix) with ESMTP id 1B5DF3B03B2 for ; Thu, 29 Jun 2006 03:08:25 -0400 (EDT) Received: (from mail.tataelxsi.co.in [203.197.169.20]) by mail.tataelxsi.co.in (MOS 3.7.4b-GA) with HTTP/1.1 id BRM16267 (AUTH jalaganapathy); Thu, 29 Jun 2006 12:39:37 +0530 (IST) From: Jalagandeswari G Subject: Installing GTK+2.9.1 in Fedora core2 To: gtk-devel-list@gnome.org X-Mailer: Mirapoint Webmail Direct 3.7.4b-GA MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20060629123937.BRM16267@mail.tataelxsi.co.in> Date: Thu, 29 Jun 2006 12:39:37 +0530 (IST) X-Junkmail: Blacklisted X-Mirapoint-Sig: mail.tataelxsi.co.in X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.599 tagged_above=-999 required=2 tests=[BAYES_00=-2.599] X-Spam-Score: -2.599 X-Spam-Level: X-Mailman-Approved-At: Thu, 29 Jun 2006 07:31:44 -0400 X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2006 07:08:28 -0000 Hello All, Iam trying to install gtk+2.9.1 in fedora core2. i am using glib-1.10.1, cairo-1.1.6,atk-1.0.1 and pango-1.13.1 my configure options are ./configure --prefix=/exp/ffox Confugure works fine. While running make i am getting the following errors. gcc -DHAVE_CONFIG_H -I. -I. -I.. -DG_LOG_DOMAIN=\"Gtk\" -DGTK_LIBDIR=\"/exp/ffox/lib\" -DGTK_DATADIR=\"/exp/ffox/share\" -DGTK_DATA_PREFIX=\"/exp/ffox\" -DGTK_SYSCONFDIR=\"/exp/ffox/etc\" -DGTK_VERSION=\"2.9.1\" -DGTK_BINARY_VERSION=\"2.10.0\" -DGTK_HOST=\"i686-pc-linux-gnu\" -DGTK_COMPILATION -DGTK_PRINT_BACKENDS=\"pdf,cups\" -I../gtk -I.. -I../gdk -I../gdk -I../gdk-pixbuf -I../gdk-pixbuf -DGDK_PIXBUF_DISABLE_DEPRECATED -DGDK_DISABLE_DEPRECATED -DGTK_DISABLE_DEPRECATED -DGTK_FILE_SYSTEM_ENABLE_UNSUPPORTED -DGTK_PRINT_BACKEND_ENABLE_UNSUPPORTED -DG_ENABLE_DEBUG -pthread -I/exp/ffox//include/glib-2.0 -I/exp/ffox//lib/glib-2.0/include -I/exp/ffox//include/pango-1.0 -I/exp/ffox//include/cairo -I/exp/ffox//include/atk-1.0 -I/exp/ffox/include -I/usr/X11R6/include -DG_DISABLE_DEPRECATED -g -O2 -g -Wall -MT gtkrecentmanager.lo -MD -MP -MF .deps/gtkrecentmanager.Tpo -c gtkrecentmanager.c -fPIC -DPIC -o .libs/gtkrecentmanager.o gtkrecentmanager.c:109: error: syntax error before "GBookmarkFile" gtkrecentmanager.c:109: warning: no semicolon at end of struct or union gtkrecentmanager.c:113: error: syntax error before '}' token gtkrecentmanager.c: In function `gtk_recent_manager_class_init': gtkrecentmanager.c:274: error: invalid application of `sizeof' to an incomplete type gtkrecentmanager.c: In function `gtk_recent_manager_init': gtkrecentmanager.c:286: error: dereferencing pointer to incomplete type gtkrecentmanager.c:290: error: dereferencing pointer to incomplete type gtkrecentmanager.c:291: error: dereferencing pointer to incomplete type gtkrecentmanager.c:293: error: dereferencing pointer to incomplete type gtkrecentmanager.c:294: error: dereferencing pointer to incomplete type gtkrecentmanager.c:295: error: dereferencing pointer to incomplete type gtkrecentmanager.c:296: error: dereferencing pointer to incomplete type gtkrecentmanager.c:298: error: dereferencing pointer to incomplete type gtkrecentmanager.c: In function `gtk_recent_manager_get_property': gtkrecentmanager.c:336: error: dereferencing pointer to incomplete type gtkrecentmanager.c:339: error: dereferencing pointer to incomplete type gtkrecentmanager.c:342: error: dereferencing pointer to incomplete type gtkrecentmanager.c: In function `gtk_recent_manager_finalize': gtkrecentmanager.c:357: error: dereferencing pointer to incomplete type gtkrecentmanager.c:358: error: dereferencing pointer to incomplete type gtkrecentmanager.c:360: error: dereferencing pointer to incomplete type gtkrecentmanager.c:361: error: dereferencing pointer to incomplete type gtkrecentmanager.c:363: error: dereferencing pointer to incomplete type gtkrecentmanager.c:364: warning: implicit declaration of function `g_bookmark_file_free' gtkrecentmanager.c:364: error: dereferencing pointer to incomplete type gtkrecentmanager.c: In function `gtk_recent_manager_real_changed': gtkrecentmanager.c:377: error: dereferencing pointer to incomplete type gtkrecentmanager.c:385: error: dereferencing pointer to incomplete type gtkrecentmanager.c:387: error: dereferencing pointer to incomplete type gtkrecentmanager.c:392: error: dereferencing pointer to incomplete type gtkrecentmanager.c:394: error: dereferencing pointer to incomplete type gtkrecentmanager.c:394: warning: implicit declaration of function `g_bookmark_file_new' gtkrecentmanager.c:395: error: dereferencing pointer to incomplete type gtkrecentmanager.c:399: warning: implicit declaration of function `g_bookmark_file_to_file' gtkrecentmanager.c:399: error: dereferencing pointer to incomplete type gtkrecentmanager.c:400: error: dereferencing pointer to incomplete type gtkrecentmanager.c:406: error: dereferencing pointer to incomplete type gtkrecentmanager.c:415: error: dereferencing pointer to incomplete type gtkrecentmanager.c:419: error: dereferencing pointer to incomplete type gtkrecentmanager.c:422: error: dereferencing pointer to incomplete type gtkrecentmanager.c:429: error: dereferencing pointer to incomplete type gtkrecentmanager.c:432: error: dereferencing pointer to incomplete type gtkrecentmanager.c: In function `gtk_recent_manager_poll_timeout': gtkrecentmanager.c:458: error: dereferencing pointer to incomplete type gtkrecentmanager.c:458: error: dereferencing pointer to incomplete type gtkrecentmanager.c:461: error: dereferencing pointer to incomplete type gtkrecentmanager.c:470: error: dereferencing pointer to incomplete type gtkrecentmanager.c:477: error: dereferencing pointer to incomplete type gtkrecentmanager.c: In function `gtk_recent_manager_set_filename': gtkrecentmanager.c:498: error: dereferencing pointer to incomplete type gtkrecentmanager.c:500: error: dereferencing pointer to incomplete type gtkrecentmanager.c:502: error: dereferencing pointer to incomplete type gtkrecentmanager.c:503: error: dereferencing pointer to incomplete type gtkrecentmanager.c:506: error: dereferencing pointer to incomplete type gtkrecentmanager.c:507: error: dereferencing pointer to incomplete type gtkrecentmanager.c:514: error: dereferencing pointer to incomplete type gtkrecentmanager.c: In function `build_recent_items_list': gtkrecentmanager.c:534: error: dereferencing pointer to incomplete type gtkrecentmanager.c:536: error: dereferencing pointer to incomplete type gtkrecentmanager.c:538: error: dereferencing pointer to incomplete type gtkrecentmanager.c:539: error: dereferencing pointer to incomplete type gtkrecentmanager.c:542: error: dereferencing pointer to incomplete type gtkrecentmanager.c:555: error: dereferencing pointer to incomplete type gtkrecentmanager.c:563: error: dereferencing pointer to incomplete type gtkrecentmanager.c:565: error: dereferencing pointer to incomplete type gtkrecentmanager.c:571: warning: implicit declaration of function `g_bookmark_file_load_from_file' gtkrecentmanager.c:571: error: dereferencing pointer to incomplete type gtkrecentmanager.c:572: error: dereferencing pointer to incomplete type gtkrecentmanager.c:578: error: dereferencing pointer to incomplete type gtkrecentmanager.c:581: error: dereferencing pointer to incomplete type gtkrecentmanager.c:582: error: dereferencing pointer to incomplete type gtkrecentmanager.c:587: warning: implicit declaration of function `g_bookmark_file_get_size' gtkrecentmanager.c:587: error: dereferencing pointer to incomplete type gtkrecentmanager.c:588: error: dereferencing pointer to incomplete type gtkrecentmanager.c:590: error: dereferencing pointer to incomplete type gtkrecentmanager.c:595: error: dereferencing pointer to incomplete type gtkrecentmanager.c:596: error: dereferencing pointer to incomplete type gtkrecentmanager.c: In function `IA__gtk_recent_manager_get_for_screen': gtkrecentmanager.c:683: error: dereferencing pointer to incomplete type gtkrecentmanager.c: In function `display_closed': gtkrecentmanager.c:697: error: dereferencing pointer to incomplete type gtkrecentmanager.c:698: error: dereferencing pointer to incomplete type gtkrecentmanager.c:703: error: dereferencing pointer to incomplete type gtkrecentmanager.c: In function `unset_screen': gtkrecentmanager.c:718: error: dereferencing pointer to incomplete type gtkrecentmanager.c:720: error: dereferencing pointer to incomplete type gtkrecentmanager.c:726: error: dereferencing pointer to incomplete type gtkrecentmanager.c: In function `IA__gtk_recent_manager_set_screen': gtkrecentmanager.c:759: error: dereferencing pointer to incomplete type gtkrecentmanager.c: In function `IA__gtk_recent_manager_set_limit': gtkrecentmanager.c:786: error: dereferencing pointer to incomplete type gtkrecentmanager.c: In function `IA__gtk_recent_manager_get_limit': gtkrecentmanager.c:808: error: dereferencing pointer to incomplete type gtkrecentmanager.c: In function `IA__gtk_recent_manager_add_full': gtkrecentmanager.c:977: error: dereferencing pointer to incomplete type gtkrecentmanager.c:979: error: dereferencing pointer to incomplete type gtkrecentmanager.c:980: error: dereferencing pointer to incomplete type gtkrecentmanager.c:984: warning: implicit declaration of function `g_bookmark_file_set_title' gtkrecentmanager.c:984: error: dereferencing pointer to incomplete type gtkrecentmanager.c:987: warning: implicit declaration of function `g_bookmark_file_set_description' gtkrecentmanager.c:987: error: dereferencing pointer to incomplete type gtkrecentmanager.c:989: warning: implicit declaration of function `g_bookmark_file_set_mime_type' gtkrecentmanager.c:989: error: dereferencing pointer to incomplete type gtkrecentmanager.c:996: warning: implicit declaration of function `g_bookmark_file_add_group' gtkrecentmanager.c:996: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1003: warning: implicit declaration of function `g_bookmark_file_add_application' gtkrecentmanager.c:1003: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1007: warning: implicit declaration of function `g_bookmark_file_set_is_private' gtkrecentmanager.c:1007: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1013: error: dereferencing pointer to incomplete type gtkrecentmanager.c: In function `IA__gtk_recent_manager_remove_item': gtkrecentmanager.c:1048: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1050: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1051: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1061: warning: implicit declaration of function `g_bookmark_file_remove_item' gtkrecentmanager.c:1061: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1069: error: dereferencing pointer to incomplete type gtkrecentmanager.c: In function `IA__gtk_recent_manager_has_item': gtkrecentmanager.c:1098: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1100: warning: implicit declaration of function `g_bookmark_file_has_item' gtkrecentmanager.c:1100: error: dereferencing pointer to incomplete type gtkrecentmanager.c: At top level: gtkrecentmanager.c:1104: error: syntax error before '*' token gtkrecentmanager.c: In function `build_recent_info': gtkrecentmanager.c:1110: error: `bookmarks' undeclared (first use in this function) gtkrecentmanager.c:1110: error: (Each undeclared identifier is reported only once gtkrecentmanager.c:1110: error: for each function it appears in.) gtkrecentmanager.c:1111: error: `info' undeclared (first use in this function) gtkrecentmanager.c:1113: warning: implicit declaration of function `g_bookmark_file_get_title' gtkrecentmanager.c:1114: warning: implicit declaration of function `g_bookmark_file_get_description' gtkrecentmanager.c:1115: warning: implicit declaration of function `g_bookmark_file_get_mime_type' gtkrecentmanager.c:1117: warning: implicit declaration of function `g_bookmark_file_get_is_private' gtkrecentmanager.c:1119: warning: implicit declaration of function `g_bookmark_file_get_added' gtkrecentmanager.c:1120: warning: implicit declaration of function `g_bookmark_file_get_modified' gtkrecentmanager.c:1121: warning: implicit declaration of function `g_bookmark_file_get_visited' gtkrecentmanager.c:1123: warning: implicit declaration of function `g_bookmark_file_get_groups' gtkrecentmanager.c:1123: warning: assignment makes pointer from integer without a cast gtkrecentmanager.c:1133: warning: implicit declaration of function `g_bookmark_file_get_applications' gtkrecentmanager.c:1133: warning: assignment makes pointer from integer without a cast gtkrecentmanager.c:1144: warning: implicit declaration of function `g_bookmark_file_get_app_info' gtkrecentmanager.c: In function `IA__gtk_recent_manager_lookup_item': gtkrecentmanager.c:1196: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1198: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1199: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1209: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1224: error: dereferencing pointer to incomplete type gtkrecentmanager.c: In function `IA__gtk_recent_manager_move_item': gtkrecentmanager.c:1268: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1278: warning: implicit declaration of function `g_bookmark_file_move_item' gtkrecentmanager.c:1278: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1287: error: dereferencing pointer to incomplete type gtkrecentmanager.c: In function `IA__gtk_recent_manager_get_items': gtkrecentmanager.c:1317: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1320: warning: implicit declaration of function `g_bookmark_file_get_uris' gtkrecentmanager.c:1320: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1320: warning: assignment makes pointer from integer without a cast gtkrecentmanager.c:1327: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1344: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1345: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1349: error: dereferencing pointer to incomplete type gtkrecentmanager.c: In function `purge_recent_items_list': gtkrecentmanager.c:1370: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1373: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1374: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1376: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1377: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1378: error: dereferencing pointer to incomplete type gtkrecentmanager.c: In function `IA__gtk_recent_manager_purge_items': gtkrecentmanager.c:1406: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1409: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1415: error: dereferencing pointer to incomplete type make[4]: *** [gtkrecentmanager.lo] Error 1 make[4]: Leaving directory `/exp/ffox/gtk+-2.9.1/gtk' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/exp/ffox/gtk+-2.9.1/gtk' make[2]: *** [all] Error 2 make[2]: Leaving directory `/exp/ffox/gtk+-2.9.1/gtk' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/exp/ffox/gtk+-2.9.1' make: *** [all] Error 2 Pls help me out to find a solution. regards, Jala The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s)and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender or administrator@tataelxsi.co.in From the introduction of 2396: This document updates and merges "Uniform Resource Locators" [RFC1738] and "Relative Uniform Resource Locators" [RFC1808] in order to define a single, generic syntax for all URI. It excludes those portions of RFC 1738 that defined the specific syntax of individual URL schemes ... Seems you missed the second sentence. That's why 2396 is not obsoleting 1738 in a formal sense, it only update a part of 1738 and this part doesn't include the definition of the FILE scheme. > from a usability standpoint, i really enjoy not having to type 3 /s in a row > (even though konqi does let you do that too) It's a completely different problem, you should even be able to enter /usr/local and have the software expand/remap to a valid URL. I don't use Konqueror but I'm pretty sure Netscape does this, the goal is that once entered the user is exposed to a valid URL. This should also include escaping of reserved or forbiden characters, the goal is to provide something correct for selection or drag and drop as well as teaching the user. Daniel -- Daniel Veillard | Red Hat Network http://redhat.com/products/network/ veillard@redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From my quick look at the RFC (1459), IRC should be able to support SJIS, UTF-8 and most of the Latin encodings -- the control stream is ASCII. But there is no indication of the encoding in use, making it necessary to use some OOB information to set the right encoding. Nor is there any indication of the language, making selection of an appropriate Han glyph set rather difficult. Pretty primitive protocol. I guess there are sufficient per-channel conventions to resolves these issues. > You may well be well right that we should have worked on making > GdkFont still work; it's certainly a bit of a API hole that there > isn't a conventional character-by-character text drawing API > available. If this is a reasonable course, then perhaps the right idea is to create a new function that returns an Xft font for use by the rendering routines; that way legacy applications would continue to see only GDK_FONT_FONT and GDK_FONT_FONTSET but minor source modifications could switch applications to Xft fonts instead. That would make porting existing Gtk+ apps to use Xft would require few changes rather than a wholesale conversion to Pango. > But considering that we are releasing this weekend, it's not something > we can go back and revisit at this point. > > (While adding a 3rd type of font may seem like a small API compatible, > change, it's actually something that can easily crash applications > that aren't expecting it.) Adding new APIs after the release that preserve source and binary compatibility for existing applications would probably be a better way than whacking gdk_font_load to return a new kind of object; the key is to require applications call a new function to get the new kind of gdk_font object. Keith Packard XFree86 Core Team Compaq Cambridge Research Lab From mardy@users.sourceforge.net Thu Jun 1 07:04:29 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 633423B0C7E for ; Thu, 1 Jun 2006 07:04:29 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28962-04 for ; Thu, 1 Jun 2006 07:04:28 -0400 (EDT) Received: from smtp010.mail.ukl.yahoo.com (smtp010.mail.ukl.yahoo.com [217.12.11.79]) by menubar.gnome.org (Postfix) with SMTP id 690073B013F for ; Thu, 1 Jun 2006 07:04:27 -0400 (EDT) Received: (qmail 61490 invoked from network); 1 Jun 2006 11:04:26 -0000 Received: from unknown (HELO pupilla) (mardy78@151.42.226.237 with login) by smtp010.mail.ukl.yahoo.com with SMTP; 1 Jun 2006 11:04:26 -0000 Received: by pupilla (Postfix, from userid 1000) id 038336B7FF; Thu, 1 Jun 2006 13:03:17 +0200 (CEST) Date: Thu, 1 Jun 2006 13:03:17 +0200 From: Alberto Mardegan To: gtk-devel-list@gnome.org Message-ID: <20060601110317.GA23802@pupilla> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Accept-Language: it,ia,en,bg,es,fr User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.599 tagged_above=-999 required=2 tests=[BAYES_00=-2.599] X-Spam-Score: -2.599 X-Spam-Level: Subject: Histogram widget X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2006 11:04:29 -0000 Hi all! I'm going to write a widget for displaying histograms. Would it be elegant/smart/useful if it were to fetch the data from a GtkTreeModel, or would it be an unneeded complexity and just some GArrays are better? I'm thinking of a GtkTreeModel, in which every row is a histogram bar; hence we would/could have a double field for the value, a string field for the label in the X axis, maybe a GdkColor for the color and whatever can come to mind. Many thanks in advance to all those who will share their thoughts on the matter. -- Saluti, Mardy http://www.interlingua.com ___________________________________ Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB http://mail.yahoo.it From matthias.clasen@gmail.com Thu Jun 1 09:35:39 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 44D6D3B0213 for ; Thu, 1 Jun 2006 09:35:39 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06492-04 for ; Thu, 1 Jun 2006 09:35:37 -0400 (EDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.190]) by menubar.gnome.org (Postfix) with ESMTP id 2B1463B019C for ; Thu, 1 Jun 2006 09:35:37 -0400 (EDT) Received: by nf-out-0910.google.com with SMTP id l37so564726nfc for ; Thu, 01 Jun 2006 06:35:36 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=AXg4pkieJhFwK/fsPTG5BVq6Sv29H8f6t8wbUeiehWS8QFuJL4sEqqu5dTplyA7vdRrz50uICadI8ZT1y2rp+BasRLmOBacUSSXY1blUEAIWfvb1udC+bqhsXFVhdU6V4+2wZCjIuaczx07TxLq1x+v9zHm4YPkA8kydW+5SycA= Received: by 10.48.31.10 with SMTP id e10mr779574nfe; Thu, 01 Jun 2006 06:33:48 -0700 (PDT) Received: by 10.48.215.7 with HTTP; Thu, 1 Jun 2006 06:33:48 -0700 (PDT) Message-ID: Date: Thu, 1 Jun 2006 09:33:48 -0400 From: "Matthias Clasen" To: "Kristian Rietveld" In-Reply-To: <20060531200823.GA7846@babi-pangang.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20060531200823.GA7846@babi-pangang.org> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.742 tagged_above=-999 required=2 tests=[AWL=-0.700, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.558, SPF_PASS=-0.001] X-Spam-Score: -1.742 X-Spam-Level: Cc: gtk-devel-list@gnome.org, timj@imendio.com Subject: Re: Tooltips progress X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2006 13:35:39 -0000 > Attached is some sample code using the new API. Opinions, comments, > suggestions are appreciated. > I don't remember too much of the original proposal, so I'll just go by what I see in the examples... What is the relation between the tooltip-markup and has-tooltip properties ? Is has-tooltip automatically set when setting tooltip-markup ? Or do you only need to set has-tooltip if you want to connect to query-tooltip ? Is the tooltip window available as a property too ? (The example uses a dedicated setter for it). The example doesn't show tooltips constructed using the old tooltips api, but I assume those will continue to work as before, right ? Using x == -1 to indicate a keyboard-triggered tooltip looks a bit odd to me; how about adding a boolean parameter for this ? Regarding dedicated treeview api, I think we can do without it (at least initially), if we have a good example in the docs. Though lots of people will forget the selection_changed thing for keyboard tooltips... Could you enhance your demo with an example of text view tooltips on a tag ? Matthias From jean.brefort@normalesup.org Thu Jun 1 09:58:21 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 479CD3B0171 for ; Thu, 1 Jun 2006 09:58:03 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08512-08 for ; Thu, 1 Jun 2006 09:58:01 -0400 (EDT) Received: from smtp4-g19.free.fr (smtp4-g19.free.fr [212.27.42.30]) by menubar.gnome.org (Postfix) with ESMTP id 84A533B0CBB for ; Thu, 1 Jun 2006 09:57:52 -0400 (EDT) Received: from che21-1-82-239-125-56.fbx.proxad.net (che21-1-82-239-125-56.fbx.proxad.net [82.239.125.56]) by smtp4-g19.free.fr (Postfix) with ESMTP id DE3EA54C0D; Thu, 1 Jun 2006 15:57:50 +0200 (CEST) From: Jean =?ISO-8859-1?Q?Br=E9fort?= To: Alberto Mardegan In-Reply-To: <20060601110317.GA23802@pupilla> References: <20060601110317.GA23802@pupilla> Content-Type: text/plain; charset=utf-8 Date: Thu, 01 Jun 2006 16:00:49 +0200 Message-Id: <1149170449.11316.1.camel@athlon.brefort.fr> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.884 tagged_above=-999 required=2 tests=[AWL=-0.354, BAYES_00=-2.599, SPF_NEUTRAL=1.069] X-Spam-Score: -1.884 X-Spam-Level: Cc: gtk-devel-list@gnome.org Subject: Re: Histogram widget X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2006 13:58:21 -0000 Le jeudi 01 juin 2006 13:03 +0200, Alberto Mardegan a crit : > Hi all! > I'm going to write a widget for displaying histograms. Would it be > elegant/smart/useful if it were to fetch the data from a GtkTreeModel, > or would it be an unneeded complexity and just some GArrays are better? > > I'm thinking of a GtkTreeModel, in which every row is a histogram bar; > hence we would/could have a double field for the value, a string field > for the label in the X axis, maybe a GdkColor for the color and whatever > can come to mind. > > Many thanks in advance to all those who will share their thoughts on the > matter. Do you want histograms or column charts? Anyway both already exist in goffice and we have the GOGraphWidget widget to display a large variety of 2D charts. Regards, Jean Brfort From mitch@gimp.org Thu Jun 1 10:37:41 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 9C8673B0253 for ; Thu, 1 Jun 2006 10:37:41 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12026-06 for ; Thu, 1 Jun 2006 10:37:40 -0400 (EDT) Received: from mitch.gimp.org (p549C9506.dip0.t-ipconnect.de [84.156.149.6]) by menubar.gnome.org (Postfix) with ESMTP id 630D53B0171 for ; Thu, 1 Jun 2006 10:37:40 -0400 (EDT) Received: from mitch by mitch.gimp.org with local (Exim 3.36 #1 (Debian)) id 1FloKa-0005tI-00; Thu, 01 Jun 2006 16:39:24 +0200 From: Michael Natterer To: Kristian Rietveld In-Reply-To: <20060531200823.GA7846@babi-pangang.org> References: <20060531200823.GA7846@babi-pangang.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Thu, 01 Jun 2006 16:39:24 +0200 Message-Id: <1149172764.5721.13.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-0.468 tagged_above=-999 required=2 tests=[AWL=-1.996, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, RCVD_IN_NJABL_DUL=1.946, RCVD_IN_SORBS_DUL=2.046] X-Spam-Score: -0.468 X-Spam-Level: Cc: gtk-devel-list@gnome.org, timj@imendio.com Subject: Re: Tooltips progress X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2006 14:37:41 -0000 On Wed, 2006-05-31 at 22:08 +0200, Kristian Rietveld wrote: > Currently, we are using the following query-tooltips signal: > > gboolean (*query_tooltip) (GtkWidget *widget, > gint x, > gint y, > GtkTooltip *tooltip); > > But if a user sets a custom using gtk_widget_set_custom_window(), we don't > have to pass a GtkTooltip around. So currently I just set the tooltip > field to NULL, so the user knows he has to use his own custom tooltip > window (and we assume he has a reference to that). Is this okay or do > we want to change this? We could also move the _set_custom_window() > functions into GtkTooltip for example. I would very much appreciate if the GtkTooltip object also kept track of the custom window. IMHO it makes no sense to handle this differently. gtk_tooltip_set_markup() vs. gtk_tooltip_set_window() simply feels much better than the asymmetry in gtk_tooltip_set_markup() vs. gtk_widget_set_tooltip_window() The current approach even limits the new tooltip system's use cases, since you have to set the custom window *outside* the callback. There is no way to decide *in* the callback if a standard tooltip is sufficient, or if a custom window is needed. Another problem is the assymetry in getting the relevant data to the callback. With markup, the GtkTooltip can be queried for the markup, if it's a custom window, you have to get it to the callback somehow. In your example code it's passed as user_data, but user_data is often not available since it's needed for other things, so you have to add a "GtkWidget *tooltip_window" to the "other thing". If "other thing" is e.g. the application toplevel window, which of the sub-widget's tooltips should it keep? All of them? People will in many cases end up attaching the tooltip window to the widget. I also fail to see why the "has-tooltip" property has to be set to TRUE, even tho a tooltip window was set on the widget. ciao, --mitch From islewind@gmail.com Thu Jun 1 11:16:53 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id CCF0F3B027D for ; Thu, 1 Jun 2006 11:16:53 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15167-10 for ; Thu, 1 Jun 2006 11:16:52 -0400 (EDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.181]) by menubar.gnome.org (Postfix) with ESMTP id EBDF73B02A2 for ; Thu, 1 Jun 2006 11:16:51 -0400 (EDT) Received: by py-out-1112.google.com with SMTP id x31so492875pye for ; Thu, 01 Jun 2006 08:16:51 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=TJcxirCpCUc11Q5e90yGryvZPvt6/4y9oixknOJbU9D0ul2vMJTRqtCSsnJU4SxRLn9lAKaOyN+GZ5nbxOOcf0T99ZPfjnqzOA3KseyOVQ4Ap+A8c67skU0CG6t40az7MwaWe4KCKIFXgrpOCN10KzuNVCisW4dtldpMgxlx5bQ= Received: by 10.35.36.13 with SMTP id o13mr1010511pyj; Thu, 01 Jun 2006 08:16:51 -0700 (PDT) Received: by 10.35.10.17 with HTTP; Thu, 1 Jun 2006 08:16:50 -0700 (PDT) Message-ID: <7bf6f2dc0606010816q15d512aejc30a6c93bc165e6@mail.gmail.com> Date: Thu, 1 Jun 2006 17:16:50 +0200 From: "=?ISO-8859-1?Q?=D8yvind_Kol=E5s?=" Sender: islewind@gmail.com To: "=?ISO-8859-1?Q?Carlos_Eduardo_Rodrigues_Di=F3genes?=" In-Reply-To: <1149104973.27709.4.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <1149104973.27709.4.camel@localhost.localdomain> X-Google-Sender-Auth: aee248fb7aae0f83 X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.571 tagged_above=-999 required=2 tests=[AWL=0.029, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.571 X-Spam-Level: Cc: gtk-devel-list@gnome.org Subject: Re: Color space transformations in GTK X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2006 15:16:54 -0000 On 5/31/06, Carlos Eduardo Rodrigues Di=F3genes = wrote: > Hi, > > There is any plan to add color spaces conversions in GTK+ (GDK or > Gdk-Pixbuf)? If the answear is no, why not? Pixel format conversions is not a small piece of code and the needed pixel formats varies from scenario to scenario. Most programs will not need such a large general infrastructure and the ones that really need it would probably not be satisfied with a simpler solution. What functionality is it you miss that you think fits into a GUI toolkit? (color management is a seperate issue to color space(pixel format) conversions according to my interpretation of your question). /=D8yvind K. --=20 =ABThe future is already here. It's just not very evenly distributed=BB -- William Gibson http://pippin.gimp.org/ http://ffii.org/ From timj@gtk.org Thu Jun 1 11:17:09 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 565CF3B0DC9 for ; Thu, 1 Jun 2006 11:17:09 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15377-03 for ; Thu, 1 Jun 2006 11:17:02 -0400 (EDT) Received: from webmail.hansenet.de (mail01.hansenet.de [213.191.73.61]) by menubar.gnome.org (Postfix) with ESMTP id 8AFEE3B0DB5 for ; Thu, 1 Jun 2006 11:17:00 -0400 (EDT) Received: from birnet.org (213.39.195.111) by webmail.hansenet.de (7.2.059) id 447D3FB2000502B1; Thu, 1 Jun 2006 17:16:59 +0200 Received: from master.birnet.private (localhost [127.0.0.1]) by birnet.org (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k51FGvIU003186 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 1 Jun 2006 17:16:57 +0200 Received: (from timj@localhost) by master.birnet.private (8.13.4/8.13.4/Submit) id k51FGpl3003183; Thu, 1 Jun 2006 17:16:51 +0200 Date: Thu, 1 Jun 2006 17:16:51 +0200 (CEST) From: Tim Janik X-X-Sender: timj@master.birnet.private To: Kristian Rietveld In-Reply-To: <20060531183045.GA7564@babi-pangang.org> Message-ID: References: <20060314132538.GA3526@babi-pangang.org> <443B4A8A.8000302@imendio.com> <20060425103017.GA15762@babi-pangang.org> <20060531183045.GA7564@babi-pangang.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.431 tagged_above=-999 required=2 tests=[AWL=0.168, BAYES_00=-2.599] X-Spam-Score: -2.431 X-Spam-Level: Cc: Gtk+ Developers , Soeren Sandmann Subject: Re: Callback based tooltips (Re: New tooltips API, continued) X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2006 15:17:10 -0000 On Wed, 31 May 2006, Kristian Rietveld wrote: > On Tue, Apr 25, 2006 at 03:08:12PM +0200, Soeren Sandmann wrote: >> I once wrote down how tooltips should behave: > > I mostly like the behaviour you described below. > >> - Tooltips are too intrusive. The text should be smaller, and not sure if this has been raised already... the font size of the tooltips should be exactly as large as the default font size (module tooltip markup of course) to avoid reducing usability of the tooltips in contrast to normal text (labels). >> they should to the right of the cursor, and a little below >> the cursor's center. --- ciaoTJ From timj@gtk.org Thu Jun 1 12:12:43 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id E5C0F3B0171 for ; Thu, 1 Jun 2006 12:12:42 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19272-05 for ; Thu, 1 Jun 2006 12:12:40 -0400 (EDT) Received: from webmail.hansenet.de (mail03.hansenet.de [213.191.73.10]) by menubar.gnome.org (Postfix) with ESMTP id 9C9433B015C for ; Thu, 1 Jun 2006 12:12:39 -0400 (EDT) Received: from birnet.org (213.39.195.111) by webmail.hansenet.de (7.2.059) id 447C08450012767E; Thu, 1 Jun 2006 18:12:37 +0200 Received: from master.birnet.private (localhost [127.0.0.1]) by birnet.org (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k51GCZTL005312 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 1 Jun 2006 18:12:35 +0200 Received: (from timj@localhost) by master.birnet.private (8.13.4/8.13.4/Submit) id k51GCY4h005311; Thu, 1 Jun 2006 18:12:34 +0200 Date: Thu, 1 Jun 2006 18:12:34 +0200 (CEST) From: Tim Janik X-X-Sender: timj@master.birnet.private To: Kristian Rietveld In-Reply-To: <20060531200823.GA7846@babi-pangang.org> Message-ID: References: <20060531200823.GA7846@babi-pangang.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.434 tagged_above=-999 required=2 tests=[AWL=0.165, BAYES_00=-2.599] X-Spam-Score: -2.434 X-Spam-Level: Cc: Gtk+ Developers , Matthias Clasen Subject: Re: Tooltips progress X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2006 16:12:43 -0000 On Wed, 31 May 2006, Kristian Rietveld wrote: > Last week I've been working on the tooltips implementation, using the > callback-based approach/interface discussed earlier on this mailing list. > The basics are working already including keyboard support and custom > windows. Before I can finalize a patch for reviewal, I have some comments > and questions. > > > In a follow up to his original mail, Tim is talking about adding the > following function: > > gdk_display_force_query_display (GdkDisplay *); > > I am not sure if this really belongs in GdkDisplay. Currently I have a: > > gtk_widget_force_query_tooltip (GtkWidget *widget); > > which works just fine for forcably updating a tooltip, in both keyboard > and mouse mode. I guess most people will usually know which widget's > tooltip to update. Opinions? yes, in most cases the widget will be known, but not in all. the trivial example is changing per-display settings like ::display-tooltips = off or the timeout. also, since we support nesting/overlaying of widgets. even the display might not be clear, which is why i actually proposed: void gtk_display_force_tooltip_query (GdkDisplay*); /* display may be NULL */ /* because of nesting/overlapping tooltips, widget is not always known * http://mail.gnome.org/archives/gtk-devel-list/2006-April/msg00030.html */ but you have a point here, since in most cases the widget will indeed be known, it'll be most convenient to also provide: void gtk_widget_force_query_tooltip (GtkWidget *widget) { gtk_display_force_tooltip_query (gtk_widget_get_display (widget)); } > Currently, we are using the following query-tooltips signal: > > gboolean (*query_tooltip) (GtkWidget *widget, > gint x, > gint y, > GtkTooltip *tooltip); > > But if a user sets a custom using gtk_widget_set_custom_window(), we don't > have to pass a GtkTooltip around. So currently I just set the tooltip > field to NULL, so the user knows he has to use his own custom tooltip > window (and we assume he has a reference to that). my original proposal http://mail.gnome.org/archives/gtk-devel-list/2006-April/msg00010.html included: GtkWindow* gtk_widget_get_tooltip_window (GtkWidget *widget); so the user doesn't need to duplicate tracking of this window. > Is this okay or do > we want to change this? We could also move the _set_custom_window() > functions into GtkTooltip for example. no, i intentionally didn't put it there. the reasoning for this was: - the setter should go along with a getter - the user should get at the custom window but *not* the tooltips window used by gtk. the latter is violated with a getter on GtkTooltip. > Implementing GtkTreeView tooltips in your application is now pretty easy, > just set up a query_tooltip callback and call gtk_tree_view_get_path_at_pos() > with the coordinates which are provided to you (but if x == -1, the keyboard > mode is enabled and then you should really call gtk_tree_view_get_cursor()). using x==-1&&y==-1 for keyboard mode was a bit of an aftermath patchup to my original proposal. Matthias Clasen now pointed out: > Using x == -1 to indicate a keyboard-triggered tooltip looks a bit > odd to me; how about adding a boolean parameter for this ? and i thnk he is right. another indication that we'd not want (-1,-1) is that you already talk about querying the cursor yourself. so it's probably better to adapt the signal to: gboolean (*query_tooltip) (GtkWidget *widget, gint x, gint y, gboolean keyboard_tip, GtkTooltip *tooltip); and preserve the x,y position. > Would this be sufficient, or do we want to add some special API for supporting > tooltips in the tree view, like having GtkTreeView implement the query > tooltip callback and have tooltip-markup properties on cell renderers. > Personally I think implementing the query-tooltip yourself is easy enough > for people to do and also really flexible, so there's no need for more API. i'd say let's first nail the basic tooltip API. GtkWidget already comes with a default handler. we can still add treeview convenience API later on if that is required. (and for that, i think it'd be easiest to forward the query_tooltip() signal to signals on the columns and cell renderers). > Since we re-query for a tooltip on mouse motion, I was wondering what we > should do in keyboard mode if a key is pressed in, for example, GtkTreeView. > A key press there might change the cursor and we might want to update the > tooltip contents. Do we want stock GTK+ to take care of this, or should the > user do this himself? (For example by calling gtk_widget_force_tooltip_query > from the GtkTreeSelection::changed callback). i think i'd handle key press events like mouse motion and scroll events, i.e. re-query. that eases things on the user side and is consistent with movement. (the basic idea behind my proposal was that gtk+ takes care of the required granularity whenever possible, so gtk_display_force_tooltip_query() needs to allmost never be used). > thanks, > > -kris. > --- ciaoTJ From timj@gtk.org Thu Jun 1 12:21:35 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 96AD53B0E27 for ; Thu, 1 Jun 2006 12:21:35 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19725-05 for ; Thu, 1 Jun 2006 12:21:33 -0400 (EDT) Received: from webmail.hansenet.de (mail02.hansenet.de [213.191.73.62]) by menubar.gnome.org (Postfix) with ESMTP id AE4893B0115 for ; Thu, 1 Jun 2006 12:21:33 -0400 (EDT) Received: from birnet.org (213.39.195.111) by webmail.hansenet.de (7.2.059) id 447C276B001342DD; Thu, 1 Jun 2006 18:21:31 +0200 Received: from master.birnet.private (localhost [127.0.0.1]) by birnet.org (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k51GLTmR005587 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 1 Jun 2006 18:21:29 +0200 Received: (from timj@localhost) by master.birnet.private (8.13.4/8.13.4/Submit) id k51GLTBN005586; Thu, 1 Jun 2006 18:21:29 +0200 Date: Thu, 1 Jun 2006 18:21:29 +0200 (CEST) From: Tim Janik X-X-Sender: timj@master.birnet.private To: Matthias Clasen In-Reply-To: Message-ID: References: <20060531200823.GA7846@babi-pangang.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.436 tagged_above=-999 required=2 tests=[AWL=0.163, BAYES_00=-2.599] X-Spam-Score: -2.436 X-Spam-Level: Cc: Gtk+ Developers , Kristian Rietveld Subject: Re: Tooltips progress X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2006 16:21:35 -0000 On Thu, 1 Jun 2006, Matthias Clasen wrote: >> Attached is some sample code using the new API. Opinions, comments, >> suggestions are appreciated. >> > > I don't remember too much of the original proposal, so I'll just go > by what I see in the examples... > > What is the relation between the tooltip-markup and has-tooltip > properties ? setting ::tooltip-markup should automatically set ::has-tooltip=TRUE; as mentioned in the original proposal: http://mail.gnome.org/archives/gtk-devel-list/2006-April/msg00010.html > Is has-tooltip automatically set when setting tooltip-markup ? > Or do you only need to set has-tooltip if you want to connect to > query-tooltip ? the idea behind ::has-tooltip is to reduce the number of required signal emissions to figure a tooltip. e.g. by adding a PRIVATE_GTK_* flag that indicates if the ::query-tooltips() emission is neccessary. maybe it'd helpt to rename that property to ::can-tooltip? > Is the tooltip window available as a property too ? (The example uses > a dedicated setter for it). i don't quite see a need for that. the custom window is only useful if you implement your own ::query-tooltip() handler anyway and there you could simply use the getter. (if you want to argue consistency with other things settable/gettable on widgets though, then yes, you have a point for also exporting it as a property) > The example doesn't show tooltips constructed using the old tooltips > api, but I assume those will continue to work as before, right ? that was the plan, i.e. you'd basically just do: void gtk_tooltips_set_tip (GtkTooltips *tooltips, GtkWidget *widget, const gchar *tip_text, const gchar *tip_private) { g_object_set (widget, "tooltip-markup", tip_text, NULL); } > Matthias --- ciaoTJ From timj@gtk.org Thu Jun 1 12:37:26 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 777F13B0DE5 for ; Thu, 1 Jun 2006 12:37:26 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20777-08 for ; Thu, 1 Jun 2006 12:37:17 -0400 (EDT) Received: from webmail.hansenet.de (mail03.hansenet.de [213.191.73.10]) by menubar.gnome.org (Postfix) with ESMTP id DD7453B0E15 for ; Thu, 1 Jun 2006 12:37:16 -0400 (EDT) Received: from birnet.org (213.39.195.111) by webmail.hansenet.de (7.2.059) id 447C084500128D01; Thu, 1 Jun 2006 18:36:53 +0200 Received: from master.birnet.private (localhost [127.0.0.1]) by birnet.org (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k51Gaj8T006024 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 1 Jun 2006 18:36:45 +0200 Received: (from timj@localhost) by master.birnet.private (8.13.4/8.13.4/Submit) id k51Gaj0d006023; Thu, 1 Jun 2006 18:36:45 +0200 Date: Thu, 1 Jun 2006 18:36:45 +0200 (CEST) From: Tim Janik X-X-Sender: timj@master.birnet.private To: Michael Natterer In-Reply-To: <1149172764.5721.13.camel@localhost> Message-ID: References: <20060531200823.GA7846@babi-pangang.org> <1149172764.5721.13.camel@localhost> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.439 tagged_above=-999 required=2 tests=[AWL=0.160, BAYES_00=-2.599] X-Spam-Score: -2.439 X-Spam-Level: Cc: Gtk+ Developers , Kristian Rietveld Subject: Re: Tooltips progress X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2006 16:37:26 -0000 On Thu, 1 Jun 2006, Michael Natterer wrote: > On Wed, 2006-05-31 at 22:08 +0200, Kristian Rietveld wrote: > >> Currently, we are using the following query-tooltips signal: >> >> gboolean (*query_tooltip) (GtkWidget *widget, >> gint x, >> gint y, >> GtkTooltip *tooltip); >> >> But if a user sets a custom using gtk_widget_set_custom_window(), we don't >> have to pass a GtkTooltip around. So currently I just set the tooltip >> field to NULL, so the user knows he has to use his own custom tooltip >> window (and we assume he has a reference to that). Is this okay or do >> we want to change this? We could also move the _set_custom_window() >> functions into GtkTooltip for example. > > I would very much appreciate if the GtkTooltip object also kept track > of the custom window. IMHO it makes no sense to handle this differently. the widget is meant to do that: void gtk_widget_set_tooltip_window (GtkWidget *widget, GtkWindow *custom_window); GtkWindow* gtk_widget_get_tooltip_window (GtkWidget *widget); for reasons outlined in a previous reply from me to kris. > gtk_tooltip_set_markup() vs. gtk_tooltip_set_window() > > simply feels much better than the asymmetry in > > gtk_tooltip_set_markup() vs. gtk_widget_set_tooltip_window() well, you'd not use GtkTooltip at all if you used gtk_widget_set_tooltip_window() before. in that way, the "asymmetry" simply reflects your usage. > The current approach even limits the new tooltip system's use cases, > since you have to set the custom window *outside* the callback. There > is no way to decide *in* the callback if a standard tooltip is > sufficient, or if a custom window is needed. i don't think it'd be clear that/if the custom window will be available in the GtkTooltip object again upon the next ::query-tooltip() emission. especially since users are not supposed to access GtkTooltip objects/structures in anyway *outside* of ::query-tooltip(), as outlined originally: http://mail.gnome.org/archives/gtk-devel-list/2006-April/msg00010.html also, passing GtkTooltip as NULL is meant to be as a clear indication that the user has to tinker with gtk_widget_get_tooltip_window() instead of the tooltip object. this avoids ambiguities like: static gboolean query_tooltip (GtkWidget *widget, gint x, gint y, GtkTooltip *tooltip) { gtk_tooltip_set_markup (tooltip, "See Me?"); g_object_new (GTK_TYPE_BUTTON, "parent", gtk_widget_get_tooltip_window(), "label", "Can You Click Me?", NULL); gtk_tooltip_set_icon (tooltip, messup_pixbuf); } what's the tooltip code supposed to do here? and yes, the API basically enforces that you decide per widget if an own tooltip window is needed or not. but i don't think that is a strong limitation, we have been discussing usage cases quite some in thise thread and nothing required to defer this decision into the callback (and no existing tooltip code i know of requires this either). so giving the benefits in API (and implementation) this provides, i think it is a reasonable limitation to make. > Another problem is the assymetry in getting the relevant data to the > callback. With markup, the GtkTooltip can be queried for the markup, > if it's a custom window, you have to get it to the callback somehow. Kris just forgot the getter for the custom window on the widget, so signal handler user_data is left alone. > In your example code it's passed as user_data, but user_data is > often not available since it's needed for other things, so you > have to add a "GtkWidget *tooltip_window" to the "other thing". > If "other thing" is e.g. the application toplevel window, which > of the sub-widget's tooltips should it keep? All of them? People > will in many cases end up attaching the tooltip window to the > widget. > > I also fail to see why the "has-tooltip" property has to be > set to TRUE, even tho a tooltip window was set on the widget. > i think this can be come by if we implement: - gtk_widget_set_tooltip_window() should automatically set: GtkWidget::has-tooltip = (custom_window != NULL || GtkWidget::tooltip-markup != ""); - setting GtkWidget::tooltip-markup should automatically set: GtkWidget::has-tooltip = (custom_window != NULL || GtkWidget::tooltip-markup != ""); right? > ciao, > --mitch > --- ciaoTJ From tkomulai@gmail.com Thu Jun 1 15:14:41 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 5A7023B0D70 for ; Thu, 1 Jun 2006 15:14:41 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31172-10 for ; Thu, 1 Jun 2006 15:14:40 -0400 (EDT) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.174]) by menubar.gnome.org (Postfix) with ESMTP id D35083B0CA3 for ; Thu, 1 Jun 2006 15:14:39 -0400 (EDT) Received: by ug-out-1314.google.com with SMTP id o2so222332uge for ; Thu, 01 Jun 2006 12:14:38 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=pkJ9GUF7tBRSDYTFZk62hCunrEDWh/ETW5JoJhlQx7UdB4QeOLJv/qztCngXO4Co/DiXf7ruqlpPxLBRYMp1hjNHoS2y4j0YEr7klSoN2TI6/rPnna1ZG+sfsuFqJaUK0lPq+fzd8NFeO3Vaf+6D8oJI9g3JXpXVTm3KfKENqYU= Received: by 10.78.47.15 with SMTP id u15mr181197huu; Thu, 01 Jun 2006 12:14:38 -0700 (PDT) Received: by 10.78.41.17 with HTTP; Thu, 1 Jun 2006 12:14:38 -0700 (PDT) Message-ID: <68bd3e050606011214i6c36109chff11c7242268b84@mail.gmail.com> Date: Thu, 1 Jun 2006 22:14:38 +0300 From: "Tommi Komulainen" Sender: tkomulai@gmail.com To: gtk-devel-list@gnome.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20060314132538.GA3526@babi-pangang.org> <443B4A8A.8000302@imendio.com> <20060425103017.GA15762@babi-pangang.org> <20060531183045.GA7564@babi-pangang.org> X-Google-Sender-Auth: 6188435c8e783fb2 X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.792 tagged_above=-999 required=2 tests=[AWL=-0.750, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.558, SPF_PASS=-0.001] X-Spam-Score: -1.792 X-Spam-Level: Subject: Re: Callback based tooltips (Re: New tooltips API, continued) X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2006 19:14:41 -0000 On 6/1/06, Tim Janik wrote: > On Wed, 31 May 2006, Kristian Rietveld wrote: > > > On Tue, Apr 25, 2006 at 03:08:12PM +0200, Soeren Sandmann wrote: > >> I once wrote down how tooltips should behave: > > > > I mostly like the behaviour you described below. > > > >> - Tooltips are too intrusive. The text should be smaller, and > > not sure if this has been raised already... > the font size of the tooltips should be exactly as large as the default > font size (module tooltip markup of course) to avoid reducing usability > of the tooltips in contrast to normal text (labels). As long as the font (and other things) are easily themable, the default values are not as important. And as gtk+ doesn't currently have any kind of design for using different font sizes in different contexts, I'd say the default font is a good default. Until someone comes up with a plan that looks at the bigger picture. -- Tommi Komulainen tommi.komulainen@iki.fi From mclasen@redhat.com Thu Jun 1 19:12:39 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id B0B143B0135 for ; Thu, 1 Jun 2006 19:12:39 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12736-06 for ; Thu, 1 Jun 2006 19:12:36 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id 567E43B0061 for ; Thu, 1 Jun 2006 19:12:36 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k51NCZWS017685 for ; Thu, 1 Jun 2006 19:12:35 -0400 Received: from lacrosse.corp.redhat.com (lacrosse.corp.redhat.com [172.16.52.154]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k51NCZpf020363 for ; Thu, 1 Jun 2006 19:12:35 -0400 Received: from [172.16.83.142] (vpn83-142.boston.redhat.com [172.16.83.142]) by lacrosse.corp.redhat.com (8.12.11.20060308/8.11.6) with ESMTP id k51NCXoG026214 for ; Thu, 1 Jun 2006 19:12:33 -0400 From: Matthias Clasen To: gtk-devel-list@gnome.org Content-Type: multipart/mixed; boundary="=-xjDvOKJb0tdB52kmWdgp" Organization: Red Hat Date: Thu, 01 Jun 2006 19:13:59 -0400 Message-Id: <1149203639.27455.9.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.7.2.1 (2.7.2.1-4) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.466 tagged_above=-999 required=2 tests=[AWL=-0.019, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, TW_GT=0.077, TW_XD=0.077] X-Spam-Score: -2.466 X-Spam-Level: Subject: Print preview api X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2006 23:12:39 -0000 --=-xjDvOKJb0tdB52kmWdgp Content-Type: text/plain Content-Transfer-Encoding: 7bit Ok, after a lot of work (mostly by John and Alex), we finally have a proposal for a print preview api that will allow us to use an external viewer by default, but also support internal preview. It consists of the following pieces: 1) GtkPrintOperation gets a new signal gboolean (*preview) (GtkPrintOperation *operation, GtkPrintOperationPreview *preview, GtkPrintContext *context, GtkWindow *parent); This signal is emitted when the user clicks the preview button. It the application does not handle it, the default handler will arrange for the external viewer to be spawned. An application that handles the preview internally should return TRUE from the signal handler. The GtkPrintOperationPreview that is passed to the signal handler lets the application control the preview. 2) The GtkPrintOperationPreview interface has a number of signals: void (*ready) (GtkPrintOperationPreview *preview, GtkPrintContext *context); The ready signal is emitted when pagination is done. The GtkPrintOperation::preview handler should connect to this signal to know when it is safe to start displaying pages. void (*got_page_size) (GtkPrintOperationPreview *preview, GtkPrintContext *context, GtkPageSetup *page_setup); The got-page-size signal is emitted for every rendered page, when the page setup for the page is know. This signal can be used to adjust the cairo context used for rendering the page (e.g. for resizing the preview window). And methods: void gtk_print_operation_preview_render_page (GtkPrintOperationPreview *preview, gint page_nr) Renders the requested page to the cairo context currently set on the print context for the preview. void gtk_print_operation_preview_end_preview (GtkPrintOperationPreview *preview) Must be called to clean up when the preview is finished. 3) A new way of handling the cairo context associated with a GtkPrintContext. A print context is no longer directly associated with a cairo surface. Instead, a cairo context is set with void gtk_print_context_set_cairo_context (GtkPrintContext *context, cairo_t *cr, double dpi_x, double dpi_y); And this can be repeated, typically in a got-page-size handler. The attached patch against current cvs has a very basic preview implementation in print-editor.c that demonstrates this api. Comments appreciated, Matthias --=-xjDvOKJb0tdB52kmWdgp Content-Disposition: attachment; filename=gtk-print-preview-7.diff Content-Type: text/x-patch; name=gtk-print-preview-7.diff; charset=UTF-8 Content-Transfer-Encoding: 7bit Index: gtk/Makefile.am =================================================================== RCS file: /cvs/gnome/gtk+/gtk/Makefile.am,v retrieving revision 1.308 diff -u -p -r1.308 Makefile.am --- gtk/Makefile.am 22 May 2006 17:19:09 -0000 1.308 +++ gtk/Makefile.am 1 Jun 2006 20:34:39 -0000 @@ -4,6 +4,7 @@ SUBDIRS=theme-bits if OS_UNIX SUBDIRS += xdgmime +GTK_PRINT_PREVIEW_COMMAND="evince %f" endif DIST_SUBDIRS=theme-bits xdgmime @@ -25,6 +26,7 @@ INCLUDES = \ -DGTK_HOST=\"$(host)\" \ -DGTK_COMPILATION \ -DGTK_PRINT_BACKENDS=\"$(GTK_PRINT_BACKENDS)\" \ + -DGTK_PRINT_PREVIEW_COMMAND=\"$(GTK_PRINT_PREVIEW_COMMAND)\" \ -I$(top_builddir)/gtk \ -I$(top_srcdir) -I../gdk \ -I$(top_srcdir)/gdk \ @@ -231,6 +233,7 @@ gtk_public_h_sources = \ gtkpreview.h \ gtkprintcontext.h \ gtkprintoperation.h \ + gtkprintoperationpreview.h \ gtkprintsettings.h \ gtkprivate.h \ gtkprogress.h \ @@ -487,6 +490,7 @@ gtk_c_sources = \ gtkpreview.c \ gtkprintcontext.c \ gtkprintoperation.c \ + gtkprintoperationpreview.c \ gtkprintsettings.c \ gtkprintutils.c \ gtkprogress.c \ Index: gtk/gtkmarshalers.list =================================================================== RCS file: /cvs/gnome/gtk+/gtk/gtkmarshalers.list,v retrieving revision 1.67 diff -u -p -r1.67 gtkmarshalers.list --- gtk/gtkmarshalers.list 22 May 2006 17:19:09 -0000 1.67 +++ gtk/gtkmarshalers.list 1 Jun 2006 20:34:39 -0000 @@ -32,6 +32,7 @@ BOOLEAN:OBJECT,INT,INT,UINT BOOLEAN:OBJECT,STRING,STRING,BOXED BOOLEAN:OBJECT,BOXED BOOLEAN:OBJECT,BOXED,BOXED +BOOLEAN:OBJECT,OBJECT,OBJECT BOOLEAN:OBJECT,STRING,STRING BOOLEAN:INT BOOLEAN:INT,INT Index: gtk/gtkprintbackend.c =================================================================== RCS file: /cvs/gnome/gtk+/gtk/gtkprintbackend.c,v retrieving revision 1.7 diff -u -p -r1.7 gtkprintbackend.c --- gtk/gtkprintbackend.c 1 Jun 2006 05:02:56 -0000 1.7 +++ gtk/gtkprintbackend.c 1 Jun 2006 20:34:39 -0000 @@ -200,7 +200,6 @@ _gtk_print_backend_create (const char *b GtkPrintBackendModule *pb_module; GtkPrintBackend *pb; - /* TODO: make module loading code work */ for (l = loaded_backends; l != NULL; l = l->next) { pb_module = l->data; @@ -255,6 +254,11 @@ gtk_print_backend_initialize (void) GTK_PRINT_BACKENDS, GTK_PARAM_READWRITE)); + gtk_settings_install_property (g_param_spec_string ("gtk-print-preview-command", + P_("Default command to run when displaying a print preview"), + P_("Command to run when displaying a print preview"), + GTK_PRINT_PREVIEW_COMMAND, + GTK_PARAM_READWRITE)); initialized = TRUE; } } Index: gtk/gtkprintbackend.h =================================================================== RCS file: /cvs/gnome/gtk+/gtk/gtkprintbackend.h,v retrieving revision 1.8 diff -u -p -r1.8 gtkprintbackend.h --- gtk/gtkprintbackend.h 24 May 2006 10:50:56 -0000 1.8 +++ gtk/gtkprintbackend.h 1 Jun 2006 20:34:39 -0000 @@ -140,6 +140,9 @@ void gtk_print_backend_print_stre GList * gtk_print_backend_load_modules (void); void gtk_print_backend_destroy (GtkPrintBackend *print_backend); +/* Methods private to gtk */ +GtkPrintBackend * _gtk_print_backend_create (const char *backend_name); + /* Backend-only functions for GtkPrintBackend */ void gtk_print_backend_add_printer (GtkPrintBackend *print_backend, Index: gtk/gtkprintcontext.c =================================================================== RCS file: /cvs/gnome/gtk+/gtk/gtkprintcontext.c,v retrieving revision 1.4 diff -u -p -r1.4 gtkprintcontext.c --- gtk/gtkprintcontext.c 31 May 2006 13:38:10 -0000 1.4 +++ gtk/gtkprintcontext.c 1 Jun 2006 20:34:39 -0000 @@ -40,6 +40,9 @@ struct _GtkPrintContext GtkPageSetup *page_setup; PangoFontMap *fontmap; + gdouble surface_dpi_x; + gdouble surface_dpi_y; + gdouble pixels_per_unit_x; gdouble pixels_per_unit_y; }; @@ -60,8 +63,8 @@ gtk_print_context_finalize (GObject *obj if (context->page_setup) g_object_unref (context->page_setup); - cairo_destroy (context->cr); - + if (context->cr) + cairo_destroy (context->cr); G_OBJECT_CLASS (gtk_print_context_parent_class)->finalize (object); } @@ -83,15 +86,31 @@ gtk_print_context_class_init (GtkPrintCo GtkPrintContext * _gtk_print_context_new (GtkPrintOperation *op) { - GtkPrintOperationPrivate *priv = op->priv; GtkPrintContext *context; context = g_object_new (GTK_TYPE_PRINT_CONTEXT, NULL); context->op = op; - context->cr = cairo_create (priv->surface); + context->cr = NULL; + context->fontmap = pango_cairo_font_map_new (); + + return context; +} + +void +gtk_print_context_set_cairo_context (GtkPrintContext *context, + cairo_t *cr, + double dpi_x, + double dpi_y) +{ + if (context->cr) + cairo_destroy (context->cr); + + context->cr = cairo_reference (cr); + context->surface_dpi_x = dpi_x; + context->surface_dpi_y = dpi_y; - switch (priv->unit) + switch (context->op->priv->unit) { default: case GTK_UNIT_PIXEL: @@ -100,34 +119,31 @@ _gtk_print_context_new (GtkPrintOperatio context->pixels_per_unit_y = 1.0; break; case GTK_UNIT_POINTS: - context->pixels_per_unit_x = priv->dpi_x / POINTS_PER_INCH; - context->pixels_per_unit_y = priv->dpi_y / POINTS_PER_INCH; + context->pixels_per_unit_x = dpi_x / POINTS_PER_INCH; + context->pixels_per_unit_y = dpi_y / POINTS_PER_INCH; break; case GTK_UNIT_INCH: - context->pixels_per_unit_x = priv->dpi_x; - context->pixels_per_unit_y = priv->dpi_y; + context->pixels_per_unit_x = dpi_x; + context->pixels_per_unit_y = dpi_y; break; case GTK_UNIT_MM: - context->pixels_per_unit_x = priv->dpi_x / MM_PER_INCH; - context->pixels_per_unit_y = priv->dpi_y / MM_PER_INCH; + context->pixels_per_unit_x = dpi_x / MM_PER_INCH; + context->pixels_per_unit_y = dpi_y / MM_PER_INCH; break; } cairo_scale (context->cr, context->pixels_per_unit_x, context->pixels_per_unit_y); - context->fontmap = pango_cairo_font_map_new (); /* We use the unit-scaled resolution, as we still want fonts given in points to work */ pango_cairo_font_map_set_resolution (PANGO_CAIRO_FONT_MAP (context->fontmap), - priv->dpi_y / context->pixels_per_unit_y); - - return context; + dpi_y / context->pixels_per_unit_y); } + void _gtk_print_context_rotate_according_to_orientation (GtkPrintContext *context) { - GtkPrintOperationPrivate *priv = context->op->priv; cairo_t *cr = context->cr; cairo_matrix_t matrix; GtkPaperSize *paper_size; @@ -136,9 +152,9 @@ _gtk_print_context_rotate_according_to_o paper_size = gtk_page_setup_get_paper_size (context->page_setup); width = gtk_paper_size_get_width (paper_size, GTK_UNIT_INCH); - width = width * priv->dpi_x / context->pixels_per_unit_x; + width = width * context->surface_dpi_x / context->pixels_per_unit_x; height = gtk_paper_size_get_height (paper_size, GTK_UNIT_INCH); - height = height * priv->dpi_y / context->pixels_per_unit_y; + height = height * context->surface_dpi_y / context->pixels_per_unit_y; switch (gtk_page_setup_get_orientation (context->page_setup)) { @@ -188,8 +204,8 @@ _gtk_print_context_translate_into_margin top = gtk_page_setup_get_top_margin (context->page_setup, GTK_UNIT_INCH); cairo_translate (context->cr, - left * priv->dpi_x / context->pixels_per_unit_x, - top * priv->dpi_y / context->pixels_per_unit_y); + left * context->surface_dpi_x / context->pixels_per_unit_x, + top * context->surface_dpi_y / context->pixels_per_unit_y); } void @@ -272,7 +288,7 @@ gtk_print_context_get_width (GtkPrintCon width = gtk_page_setup_get_page_width (context->page_setup, GTK_UNIT_INCH); /* Really dpi_x? What about landscape? what does dpi_x mean in that case? */ - return width * priv->dpi_x / context->pixels_per_unit_x; + return width * context->surface_dpi_x / context->pixels_per_unit_x; } /** @@ -300,8 +316,8 @@ gtk_print_context_get_height (GtkPrintCo else height = gtk_page_setup_get_page_height (context->page_setup, GTK_UNIT_INCH); - /* Really dpi_x? What about landscape? what does dpi_x mean in that case? */ - return height * priv->dpi_y / context->pixels_per_unit_y; + /* Really dpi_y? What about landscape? what does dpi_y mean in that case? */ + return height * context->surface_dpi_y / context->pixels_per_unit_y; } /** @@ -320,7 +336,7 @@ gtk_print_context_get_dpi_x (GtkPrintCon { g_return_val_if_fail (GTK_IS_PRINT_CONTEXT (context), 0); - return context->op->priv->dpi_x; + return context->surface_dpi_x; } /** @@ -339,7 +355,7 @@ gtk_print_context_get_dpi_y (GtkPrintCon { g_return_val_if_fail (GTK_IS_PRINT_CONTEXT (context), 0); - return context->op->priv->dpi_y; + return context->surface_dpi_y; } /** @@ -376,10 +392,16 @@ PangoContext * gtk_print_context_create_pango_context (GtkPrintContext *context) { PangoContext *pango_context; + cairo_font_options_t *options; g_return_val_if_fail (GTK_IS_PRINT_CONTEXT (context), NULL); pango_context = pango_cairo_font_map_create_context (PANGO_CAIRO_FONT_MAP (context->fontmap)); + + options = cairo_font_options_create (); + cairo_font_options_set_hint_metrics (options, CAIRO_HINT_METRICS_OFF); + pango_cairo_context_set_font_options (pango_context, options); + cairo_font_options_destroy (options); return pango_context; } Index: gtk/gtkprintcontext.h =================================================================== RCS file: /cvs/gnome/gtk+/gtk/gtkprintcontext.h,v retrieving revision 1.3 diff -u -p -r1.3 gtkprintcontext.h --- gtk/gtkprintcontext.h 31 May 2006 13:38:10 -0000 1.3 +++ gtk/gtkprintcontext.h 1 Jun 2006 20:34:39 -0000 @@ -51,6 +51,11 @@ PangoFontMap *gtk_print_context_get_pang PangoContext *gtk_print_context_create_pango_context (GtkPrintContext *context); PangoLayout *gtk_print_context_create_pango_layout (GtkPrintContext *context); +/* Needed for preview implementations */ +void gtk_print_context_set_cairo_context (GtkPrintContext *context, + cairo_t *cr, + double dpi_x, + double dpi_y); G_END_DECLS Index: gtk/gtkprintjob.c =================================================================== RCS file: /cvs/gnome/gtk+/gtk/gtkprintjob.c,v retrieving revision 1.8 diff -u -p -r1.8 gtkprintjob.c --- gtk/gtkprintjob.c 16 May 2006 16:13:48 -0000 1.8 +++ gtk/gtkprintjob.c 1 Jun 2006 20:34:39 -0000 @@ -212,14 +212,14 @@ gtk_print_job_constructor (GType job = GTK_PRINT_JOB (object); priv = job->priv; - g_assert (priv->printer_set && - priv->settings_set && + g_assert (priv->settings_set && priv->page_setup_set); - - _gtk_printer_prepare_for_print (priv->printer, - job, - priv->settings, - priv->page_setup); + + if (priv->printer) + _gtk_printer_prepare_for_print (priv->printer, + job, + priv->settings, + priv->page_setup); return object; } @@ -545,8 +545,12 @@ gtk_print_job_set_property (GObject case GTK_PRINT_JOB_PROP_PRINTER: priv->printer = GTK_PRINTER (g_value_dup_object (value)); - priv->printer_set = TRUE; - priv->backend = g_object_ref (gtk_printer_get_backend (priv->printer)); + + if (priv->printer != NULL) + { + priv->printer_set = TRUE; + priv->backend = g_object_ref (gtk_printer_get_backend (priv->printer)); + } break; case GTK_PRINT_JOB_PROP_PAGE_SETUP: Index: gtk/gtkprintoperation-private.h =================================================================== RCS file: /cvs/gnome/gtk+/gtk/gtkprintoperation-private.h,v retrieving revision 1.11 diff -u -p -r1.11 gtkprintoperation-private.h --- gtk/gtkprintoperation-private.h 1 Jun 2006 12:38:07 -0000 1.11 +++ gtk/gtkprintoperation-private.h 1 Jun 2006 20:34:39 -0000 @@ -46,9 +46,11 @@ struct _GtkPrintOperationPrivate guint print_pages_idle_id; guint show_progress_timeout_id; + GtkPrintContext *print_context; + /* Data for the print job: */ - cairo_surface_t *surface; - gdouble dpi_x, dpi_y; + /* cairo_surface_t *surface; */ + /* gdouble dpi_x, dpi_y; */ GtkPrintPages print_pages; GtkPageRange *page_ranges; @@ -84,11 +86,23 @@ GtkPrintOperationResult _gtk_print_opera GError **error); typedef void (* GtkPrintOperationPrintFunc) (GtkPrintOperation *op, - GtkWindow *parent); + GtkWindow *parent, + gboolean is_preview); void _gtk_print_operation_platform_backend_run_dialog_async (GtkPrintOperation *op, GtkWindow *parent, GtkPrintOperationPrintFunc print_cb); + +void _gtk_print_operation_platform_backend_launch_preview (GtkPrintOperation *op, + GtkWindow *parent, + const char *filename); + +cairo_surface_t *_gtk_print_operation_platform_backend_create_preview_surface (GtkPrintOperation *operation, + gdouble width, + gdouble heigh, + gdouble *dpi_x, + gdouble *dpi_y, + const gchar *target); void _gtk_print_operation_set_status (GtkPrintOperation *op, GtkPrintStatus status, Index: gtk/gtkprintoperation-unix.c =================================================================== RCS file: /cvs/gnome/gtk+/gtk/gtkprintoperation-unix.c,v retrieving revision 1.19 diff -u -p -r1.19 gtkprintoperation-unix.c --- gtk/gtkprintoperation-unix.c 1 Jun 2006 12:38:07 -0000 1.19 +++ gtk/gtkprintoperation-unix.c 1 Jun 2006 20:34:39 -0000 @@ -25,6 +25,9 @@ #include #include #include +#include +#include +#include #include "gtkprintoperation-private.h" #include "gtkmarshal.h" @@ -41,13 +44,17 @@ #include "gtkalias.h" #include "gtkintl.h" - typedef struct { - GtkPrintJob *job; /* the job we are sending to the printer */ - gulong job_status_changed_tag; GtkWindow *parent; /* just in case we need to throw error dialogs */ GMainLoop *loop; gboolean data_sent; + + /* Real printing (not preview: */ + GtkPrintJob *job; /* the job we are sending to the printer */ + cairo_surface_t *surface; + gulong job_status_changed_tag; + + } GtkPrintOperationUnix; typedef struct _PrinterFinder PrinterFinder; @@ -62,21 +69,24 @@ unix_start_page (GtkPrintOperation *op, GtkPrintContext *print_context, GtkPageSetup *page_setup) { + GtkPrintOperationUnix *op_unix; GtkPaperSize *paper_size; cairo_surface_type_t type; double w, h; + op_unix = op->priv->platform_data; + paper_size = gtk_page_setup_get_paper_size (page_setup); w = gtk_paper_size_get_width (paper_size, GTK_UNIT_POINTS); h = gtk_paper_size_get_height (paper_size, GTK_UNIT_POINTS); - type = cairo_surface_get_type (op->priv->surface); + type = cairo_surface_get_type (op_unix->surface); if (type == CAIRO_SURFACE_TYPE_PS) - cairo_ps_surface_set_size (op->priv->surface, w, h); + cairo_ps_surface_set_size (op_unix->surface, w, h); else if (type == CAIRO_SURFACE_TYPE_PDF) - cairo_pdf_surface_set_size (op->priv->surface, w, h); + cairo_pdf_surface_set_size (op_unix->surface, w, h); } static void @@ -102,6 +112,112 @@ op_unix_free (GtkPrintOperationUnix *op_ g_free (op_unix); } +static char * +shell_command_substitute_file (const gchar *cmd, + const gchar *filename) +{ + const char *inptr, *start; + char *result; + GString *final; + + g_return_val_if_fail (cmd != NULL, NULL); + g_return_val_if_fail (filename != NULL, NULL); + + result = NULL; + final = g_string_new (NULL); + + start = inptr = cmd; + + while ((inptr = strchr (inptr, '%')) != NULL) + { + g_string_append_len (final, start, inptr - start); + inptr++; + switch (*inptr) + { + case 'f': + g_string_append (final, filename ? filename : ""); + break; + + case '%': + g_string_append_c (final, '%'); + break; + + default: + g_string_append_c (final, '%'); + if (*inptr) + g_string_append_c (final, *inptr); + break; + } + if (*inptr) + inptr++; + start = inptr; + } + g_string_append (final, start); + + result = final->str; + + g_string_free (final, FALSE); + + return result; +} + +void +_gtk_print_operation_platform_backend_launch_preview (GtkPrintOperation *op, + GtkWindow *parent, + const char *filename) +{ + int argc; + gchar **argv; + gchar *cmd; + gchar *preview_cmd; + GtkSettings *settings; + gchar *quoted_filename; + GdkScreen *screen; + GError *error = NULL; + + settings = gtk_settings_get_default (); + g_object_get (settings, "gtk-print-preview-command", &preview_cmd, NULL); + + quoted_filename = g_shell_quote (filename); + cmd = shell_command_substitute_file (preview_cmd, quoted_filename); + g_shell_parse_argv (cmd, &argc, &argv, &error); + + if (error !=NULL) + goto out; + + if (parent) + screen = gtk_window_get_screen (parent); + else + screen = gdk_screen_get_default (); + + gdk_spawn_on_screen (screen, NULL, argv, NULL, G_SPAWN_SEARCH_PATH, NULL, NULL, NULL, &error); + + out: + if (error != NULL) + { + GtkWidget *edialog; + edialog = gtk_message_dialog_new (parent, + GTK_DIALOG_DESTROY_WITH_PARENT, + GTK_MESSAGE_ERROR, + GTK_BUTTONS_CLOSE, + _("Error launching preview") /* FIXME better text */); + gtk_message_dialog_format_secondary_text (GTK_MESSAGE_DIALOG (edialog), + "%s", error->message); + gtk_window_set_modal (GTK_WINDOW (edialog), TRUE); + g_signal_connect (edialog, "response", + G_CALLBACK (gtk_widget_destroy), NULL); + + gtk_window_present (GTK_WINDOW (edialog)); + + g_error_free (error); + } + + g_free (cmd); + g_free (quoted_filename); + g_free (preview_cmd); + g_strfreev (argv); +} + static void unix_finish_send (GtkPrintJob *job, void *user_data, @@ -129,6 +245,7 @@ unix_finish_send (GtkPrintJob *job, } op_unix->data_sent = TRUE; + if (op_unix->loop) g_main_loop_quit (op_unix->loop); } @@ -140,6 +257,8 @@ unix_end_run (GtkPrintOperation *op, { GtkPrintOperationUnix *op_unix = op->priv->platform_data; + cairo_surface_finish (op_unix->surface); + if (cancelled) return; @@ -147,10 +266,11 @@ unix_end_run (GtkPrintOperation *op, op_unix->loop = g_main_loop_new (NULL, FALSE); /* TODO: Check for error */ - gtk_print_job_send (op_unix->job, - unix_finish_send, - op_unix, NULL, - NULL); + if (op_unix->job != NULL) + gtk_print_job_send (op_unix->job, + unix_finish_send, + op_unix, NULL, + NULL); if (wait) { @@ -253,64 +373,66 @@ finish_print (PrintResponseData *rdata, { GtkPrintOperation *op = rdata->op; GtkPrintOperationPrivate *priv = op->priv; + gboolean is_preview; - priv->start_page = unix_start_page; - priv->end_page = unix_end_page; - priv->end_run = unix_end_run; + g_print ("finish_print\n"); + + is_preview = rdata->result == GTK_PRINT_OPERATION_RESULT_PREVIEW; if (rdata->do_print) { - GtkPrintOperationUnix *op_unix; - gtk_print_operation_set_print_settings (op, settings); - - op_unix = g_new0 (GtkPrintOperationUnix, 1); - op_unix->job = gtk_print_job_new (priv->job_name, - printer, - settings, - page_setup); + op->priv->print_context = _gtk_print_context_new (op); - gtk_print_job_set_track_print_status (op_unix->job, priv->track_print_status); - - rdata->op->priv->surface = gtk_print_job_get_surface (op_unix->job, rdata->error); - if (op->priv->surface == NULL) + if (!is_preview) { - rdata->do_print = FALSE; - op_unix_free (op_unix); - rdata->result = GTK_PRINT_OPERATION_RESULT_ERROR; - goto out; - } - - _gtk_print_operation_set_status (op, gtk_print_job_get_status (op_unix->job), NULL); - op_unix->job_status_changed_tag = - g_signal_connect (op_unix->job, "status-changed", - G_CALLBACK (job_status_changed_cb), op); - - op_unix->parent = rdata->parent; - - priv->dpi_x = 72; - priv->dpi_y = 72; - - priv->platform_data = op_unix; - priv->free_platform_data = (GDestroyNotify) op_unix_free; - - priv->print_pages = op_unix->job->print_pages; - priv->page_ranges = op_unix->job->page_ranges; - priv->num_page_ranges = op_unix->job->num_page_ranges; - - priv->manual_num_copies = op_unix->job->num_copies; - priv->manual_collation = op_unix->job->collate; - priv->manual_reverse = op_unix->job->reverse; - priv->manual_page_set = op_unix->job->page_set; - priv->manual_scale = op_unix->job->scale; - priv->manual_orientation = op_unix->job->rotate_to_orientation; + GtkPrintOperationUnix *op_unix; + cairo_t *cr; + + op_unix = g_new0 (GtkPrintOperationUnix, 1); + priv->platform_data = op_unix; + priv->free_platform_data = (GDestroyNotify) op_unix_free; + op_unix->parent = rdata->parent; + + priv->start_page = unix_start_page; + priv->end_page = unix_end_page; + priv->end_run = unix_end_run; + + op_unix->job = gtk_print_job_new (priv->job_name, + printer, + settings, + page_setup); + gtk_print_job_set_track_print_status (op_unix->job, priv->track_print_status); + /* TODO: handle error */ + op_unix->surface = gtk_print_job_get_surface (op_unix->job, rdata->error); + cr = cairo_create (op_unix->surface); + gtk_print_context_set_cairo_context (op->priv->print_context, + cr, 72, 72); + cairo_destroy (cr); + + _gtk_print_operation_set_status (op, gtk_print_job_get_status (op_unix->job), NULL); + + op_unix->job_status_changed_tag = + g_signal_connect (op_unix->job, "status-changed", + G_CALLBACK (job_status_changed_cb), op); + + priv->print_pages = op_unix->job->print_pages; + priv->page_ranges = op_unix->job->page_ranges; + priv->num_page_ranges = op_unix->job->num_page_ranges; + + priv->manual_num_copies = op_unix->job->num_copies; + priv->manual_collation = op_unix->job->collate; + priv->manual_reverse = op_unix->job->reverse; + priv->manual_page_set = op_unix->job->page_set; + priv->manual_scale = op_unix->job->scale; + priv->manual_orientation = op_unix->job->rotate_to_orientation; + } } - - out: + if (rdata->print_cb) { if (rdata->do_print) - rdata->print_cb (op, rdata->parent); + rdata->print_cb (op, rdata->parent, is_preview); else _gtk_print_operation_set_status (op, GTK_PRINT_STATUS_FINISHED_ABORTED, NULL); } @@ -319,7 +441,7 @@ finish_print (PrintResponseData *rdata, rdata->destroy (rdata); } -static void +static void handle_print_response (GtkWidget *dialog, gint response, gpointer data) @@ -330,6 +452,8 @@ handle_print_response (GtkWidget *dialog GtkPageSetup *page_setup = NULL; GtkPrinter *printer = NULL; + g_print ("handle_print_response\n"); + if (response == GTK_RESPONSE_OK) { rdata->result = GTK_PRINT_OPERATION_RESULT_APPLY; @@ -345,14 +469,24 @@ handle_print_response (GtkWidget *dialog g_signal_emit_by_name (rdata->op, "custom-widget-apply", rdata->op->priv->custom_widget); } + else if (response == GTK_RESPONSE_APPLY) + { + /* print preview */ + rdata->result = GTK_PRINT_OPERATION_RESULT_PREVIEW; + rdata->do_print = TRUE; + settings = gtk_print_unix_dialog_get_settings (GTK_PRINT_UNIX_DIALOG (pd)); + page_setup = gtk_print_unix_dialog_get_page_setup (GTK_PRINT_UNIX_DIALOG (pd)); + } + out: finish_print (rdata, printer, page_setup, settings); if (settings) g_object_unref (settings); - + gtk_widget_destroy (GTK_WIDGET (pd)); + } @@ -436,6 +570,19 @@ _gtk_print_operation_platform_backend_ru } } +cairo_surface_t * +_gtk_print_operation_platform_backend_create_preview_surface (GtkPrintOperation *op, + gdouble width, + gdouble height, + gdouble *dpi_x, + gdouble *dpi_y, + const gchar *target) +{ + g_print ("pdf surface size: %f x %f\n", width, height); + *dpi_x = *dpi_y = 72; + return cairo_pdf_surface_create (target, width, height); +} + GtkPrintOperationResult _gtk_print_operation_platform_backend_run_dialog (GtkPrintOperation *op, GtkWindow *parent, @@ -459,6 +606,7 @@ _gtk_print_operation_platform_backend_ru if (op->priv->show_dialog) { pd = get_print_dialog (op, parent); + response = gtk_dialog_run (GTK_DIALOG (pd)); handle_print_response (pd, response, &rdata); } Index: gtk/gtkprintoperation-win32.c =================================================================== RCS file: /cvs/gnome/gtk+/gtk/gtkprintoperation-win32.c,v retrieving revision 1.9 diff -u -p -r1.9 gtkprintoperation-win32.c --- gtk/gtkprintoperation-win32.c 23 May 2006 16:30:45 -0000 1.9 +++ gtk/gtkprintoperation-win32.c 1 Jun 2006 20:34:39 -0000 @@ -492,6 +492,7 @@ win32_end_run (GtkPrintOperation *op, GlobalFree(op_win32->devmode); GlobalFree(op_win32->devnames); + cairo_surface_finish (op->priv->surface); cairo_surface_destroy (op->priv->surface); op->priv->surface = NULL; Index: gtk/gtkprintoperation.c =================================================================== RCS file: /cvs/gnome/gtk+/gtk/gtkprintoperation.c,v retrieving revision 1.24 diff -u -p -r1.24 gtkprintoperation.c --- gtk/gtkprintoperation.c 1 Jun 2006 12:38:07 -0000 1.24 +++ gtk/gtkprintoperation.c 1 Jun 2006 20:34:39 -0000 @@ -19,6 +19,10 @@ */ #include "config.h" + +#include +#include + #include #include "gtkprintoperation-private.h" #include "gtkmarshalers.h" @@ -41,6 +45,7 @@ enum { STATUS_CHANGED, CREATE_CUSTOM_WIDGET, CUSTOM_WIDGET_APPLY, + PREVIEW, LAST_SIGNAL }; @@ -65,7 +70,15 @@ enum { static guint signals[LAST_SIGNAL] = { 0 }; static int job_nr = 0; -G_DEFINE_TYPE (GtkPrintOperation, gtk_print_operation, G_TYPE_OBJECT) +static void preview_iface_init (GtkPrintOperationPreviewIface *iface); +static GtkPageSetup *create_page_setup (GtkPrintOperation *op); +static void common_render_page (GtkPrintOperation *op, + gint page_nr); + + +G_DEFINE_TYPE_WITH_CODE (GtkPrintOperation, gtk_print_operation, G_TYPE_OBJECT, + G_IMPLEMENT_INTERFACE (GTK_TYPE_PRINT_OPERATION_PREVIEW, + preview_iface_init)) /** * gtk_print_error_quark: @@ -146,6 +159,60 @@ gtk_print_operation_init (GtkPrintOperat } static void +preview_iface_render_page (GtkPrintOperationPreview *preview, + gint page_nr) +{ + GtkPrintOperation *op; + + op = GTK_PRINT_OPERATION (preview); + common_render_page (op, page_nr); +} + +static void +preview_iface_end_preview (GtkPrintOperationPreview *preview) +{ + GtkPrintOperation *op; + + op = GTK_PRINT_OPERATION (preview); + + g_signal_emit (op, signals[END_PRINT], 0, op->priv->print_context); + + if (op->priv->rloop) + g_main_loop_quit (op->priv->rloop); + + op->priv->end_run (op, op->priv->is_sync, TRUE); +} + +static void +preview_iface_init (GtkPrintOperationPreviewIface *iface) +{ + iface->render_page = preview_iface_render_page; + iface->end_preview = preview_iface_end_preview; +} + +static void +preview_start_page (GtkPrintOperation *op, + GtkPrintContext *print_context, + GtkPageSetup *page_setup) +{ + g_signal_emit_by_name (op, "got-page-size",print_context, page_setup); +} + +static void +preview_end_page (GtkPrintOperation *op, + GtkPrintContext *print_context) +{ +} + +static void +preview_end_run (GtkPrintOperation *op, + gboolean wait, + gboolean cancelled) +{ +} + + +static void gtk_print_operation_set_property (GObject *object, guint prop_id, const GValue *value, @@ -256,6 +323,158 @@ gtk_print_operation_get_property (GObjec } } +typedef struct +{ + GtkPrintOperationPreview *preview; + GtkPrintContext *print_context; + GtkWindow *parent; + cairo_surface_t *surface; + gchar *filename; + guint page_nr; + gboolean wait; +} PreviewOp; + +static void +preview_print_idle_done (gpointer data) +{ + GtkPrintOperation *op; + PreviewOp *pop = (PreviewOp *) data; + + op = GTK_PRINT_OPERATION (pop->preview); + + _gtk_print_operation_platform_backend_launch_preview (op, + pop->parent, + pop->filename); + + g_free (pop->filename); + cairo_surface_finish (pop->surface); + cairo_surface_destroy (pop->surface); + + gtk_print_operation_preview_end_preview (pop->preview); + g_free (pop); +} + +static gboolean +preview_print_idle (gpointer data) +{ + PreviewOp *pop; + GtkPrintOperation *op; + gboolean retval = TRUE; + cairo_t *cr; + + GDK_THREADS_ENTER (); + + pop = (PreviewOp *) data; + op = GTK_PRINT_OPERATION (pop->preview); + + gtk_print_operation_preview_render_page (pop->preview, pop->page_nr); + + cr = gtk_print_context_get_cairo_context (pop->print_context); + cairo_show_page (cr); + + /* TODO: print out sheets not pages and follow ranges */ + pop->page_nr++; + if (op->priv->nr_of_pages <= pop->page_nr) + retval = FALSE; + + GDK_THREADS_LEAVE (); + + return retval; +} + +static void +preview_got_page_size (GtkPrintOperationPreview *preview, + GtkPrintContext *context, + GtkPageSetup *page_setup, + PreviewOp *pop) +{ + GtkPrintOperation *op = GTK_PRINT_OPERATION (preview); + GtkPaperSize *paper_size; + double w, h; + + paper_size = gtk_page_setup_get_paper_size (page_setup); + + w = gtk_paper_size_get_width (paper_size, GTK_UNIT_POINTS); + h = gtk_paper_size_get_height (paper_size, GTK_UNIT_POINTS); + + /* TODO: don't hardcode pdf */ + cairo_pdf_surface_set_size (pop->surface, w, h); +} + +static void +preview_ready (GtkPrintOperationPreview *preview, + GtkPrintContext *context, + PreviewOp *pop) +{ + + pop->page_nr = 0; + pop->print_context = context; + + g_idle_add_full (G_PRIORITY_DEFAULT_IDLE, + preview_print_idle, + pop, + preview_print_idle_done); + +} + +/** + * gtk_print_operation_preview_handler: + * + * Default handler for preview operations + **/ +static gboolean +gtk_print_operation_preview_handler (GtkPrintOperation *op, + GtkPrintOperationPreview *preview, + GtkPrintContext *context, + GtkWindow *parent) +{ + gdouble width, height, dpi_x, dpi_y; + gchar *tmp_dir; + gchar *dir_template; + gchar *preview_filename; + PreviewOp *pop; + GtkPrintSettings *settings; + cairo_t *cr; + + dir_template = g_build_filename (g_get_tmp_dir (), "print-preview-XXXXXX", NULL); + + /* use temp dirs because apps like evince need to have extentions + to determine the mine type */ + tmp_dir = mkdtemp(dir_template); + + preview_filename = g_build_filename (tmp_dir, + "Print Preview.pdf", + NULL); + + g_free (dir_template); + + pop = g_new0 (PreviewOp, 1); + pop->filename = preview_filename; + pop->preview = preview; + pop->parent = parent; + + settings = op->priv->print_settings; + + width = gtk_print_settings_get_paper_width (settings, GTK_UNIT_POINTS); + height = gtk_print_settings_get_paper_height (settings, GTK_UNIT_POINTS); + + pop->surface = + _gtk_print_operation_platform_backend_create_preview_surface (op, + width, height, + &dpi_x, &dpi_y, + pop->filename); + + cr = cairo_create (pop->surface); + gtk_print_context_set_cairo_context (op->priv->print_context, cr, + dpi_x, dpi_y); + cairo_destroy (cr); + + g_signal_connect (preview, "ready", (GCallback) preview_ready, pop); + g_signal_connect (preview, "got-page-size", (GCallback) preview_got_page_size, pop); + + return TRUE; +} + static GtkWidget * gtk_print_operation_create_custom_widget (GtkPrintOperation *operation) { @@ -287,7 +506,8 @@ gtk_print_operation_class_init (GtkPrint gobject_class->set_property = gtk_print_operation_set_property; gobject_class->get_property = gtk_print_operation_get_property; gobject_class->finalize = gtk_print_operation_finalize; - + + class->preview = gtk_print_operation_preview_handler; class->create_custom_widget = gtk_print_operation_create_custom_widget; g_type_class_add_private (gobject_class, sizeof (GtkPrintOperationPrivate)); @@ -530,6 +750,33 @@ gtk_print_operation_class_init (GtkPrint g_cclosure_marshal_VOID__OBJECT, G_TYPE_NONE, 1, GTK_TYPE_WIDGET); + /** + * GtkPrintOperation::preview: + * @operation: the #GtkPrintOperation on which the signal was emitted + * @preview: the #GtkPrintPreviewOperation for the current operation + * @context: the #GtkPrintContext that will be used + * @parent: the #GtkWindow to use as window parent, or NULL + * + * Gets emitted when a preview is requested from the native dialog. + * If you handle this you must set the cairo_context on the printing context. + * + * Returns: #TRUE if the listener wants to take over control of the preview + * + * Since: 2.10 + */ + signals[PREVIEW] = + g_signal_new (I_("preview"), + G_TYPE_FROM_CLASS (gobject_class), + G_SIGNAL_RUN_LAST, + G_STRUCT_OFFSET (GtkPrintOperationClass, preview), + _gtk_boolean_handled_accumulator, NULL, + _gtk_marshal_BOOLEAN__OBJECT_OBJECT_OBJECT, + G_TYPE_BOOLEAN, 3, + GTK_TYPE_PRINT_OPERATION_PREVIEW, + GTK_TYPE_PRINT_CONTEXT, + GTK_TYPE_WINDOW); + + /** * GtkPrintOperation:default-page-setup: * @@ -1436,6 +1683,7 @@ pdf_start_page (GtkPrintOperation *op, GtkPageSetup *page_setup) { GtkPaperSize *paper_size; + cairo_surface_t *surface = op->priv->platform_data; double w, h; paper_size = gtk_page_setup_get_paper_size (page_setup); @@ -1443,7 +1691,7 @@ pdf_start_page (GtkPrintOperation *op, w = gtk_paper_size_get_width (paper_size, GTK_UNIT_POINTS); h = gtk_paper_size_get_height (paper_size, GTK_UNIT_POINTS); - cairo_pdf_surface_set_size (op->priv->surface, w, h); + cairo_pdf_surface_set_size (surface, w, h); } static void @@ -1462,9 +1710,10 @@ pdf_end_run (GtkPrintOperation *op, gboolean cancelled) { GtkPrintOperationPrivate *priv = op->priv; + cairo_surface_t *surface = priv->platform_data; - cairo_surface_destroy (priv->surface); - priv->surface = NULL; + cairo_surface_finish (surface); + cairo_surface_destroy (surface); } static GtkPrintOperationResult @@ -1475,6 +1724,8 @@ run_pdf (GtkPrintOperation *op, { GtkPrintOperationPrivate *priv = op->priv; GtkPageSetup *page_setup; + cairo_surface_t *surface; + cairo_t *cr; double width, height; /* This will be overwritten later by the non-default size, but we need to pass some size: */ @@ -1484,13 +1735,19 @@ run_pdf (GtkPrintOperation *op, height = gtk_page_setup_get_paper_height (page_setup, GTK_UNIT_POINTS); g_object_unref (page_setup); - priv->surface = cairo_pdf_surface_create (priv->pdf_target, + surface = cairo_pdf_surface_create (priv->pdf_target, width, height); - cairo_pdf_surface_set_dpi (priv->surface, 300, 300); - - priv->dpi_x = 72; - priv->dpi_y = 72; + cairo_pdf_surface_set_dpi (surface, 300, 300); + + priv->platform_data = surface; + priv->free_platform_data = (GDestroyNotify) cairo_surface_destroy; + cr = cairo_create (surface); + gtk_print_context_set_cairo_context (op->priv->print_context, + cr, 72, 72); + cairo_destroy (cr); + + priv->print_pages = GTK_PRINT_PAGES_ALL; priv->page_ranges = NULL; priv->num_page_ranges = 0; @@ -1524,10 +1781,11 @@ typedef struct gint page, start, end, inc; - GtkPageSetup *initial_page_setup; - GtkPrintContext *print_context; + gboolean initialized; GtkWidget *progress; + + gboolean is_preview; } PrintPagesData; static void @@ -1599,12 +1857,9 @@ print_pages_idle_done (gpointer user_dat if (data->progress) gtk_widget_destroy (data->progress); - g_object_unref (data->print_context); - g_object_unref (data->initial_page_setup); - g_object_unref (data->op); - if (priv->rloop) + if (priv->rloop && !data->is_preview) g_main_loop_quit (priv->rloop); g_free (data); @@ -1640,15 +1895,62 @@ update_progress (PrintPagesData *data) } } +static void +common_render_page (GtkPrintOperation *op, + gint page_nr) +{ + GtkPrintOperationPrivate *priv = op->priv; + GtkPageSetup *page_setup; + GtkPrintContext *print_context; + cairo_t *cr; + + print_context = priv->print_context; + + page_setup = create_page_setup (op); + + g_signal_emit (op, signals[REQUEST_PAGE_SETUP], 0, + print_context, page_nr, page_setup); + + _gtk_print_context_set_page_setup (print_context, page_setup); + + /* TODO: override for preview */ + priv->start_page (op, print_context, page_setup); + + cr = gtk_print_context_get_cairo_context (print_context); + + cairo_save (cr); + if (priv->manual_scale != 1.0) + cairo_scale (cr, + priv->manual_scale, + priv->manual_scale); + + if (priv->manual_orientation) + _gtk_print_context_rotate_according_to_orientation (print_context); + + if (!priv->use_full_page) + _gtk_print_context_translate_into_margin (print_context); + + g_signal_emit (op, signals[DRAW_PAGE], 0, + print_context, page_nr); + + /* TODO: override for preview */ + priv->end_page (op, print_context); + + cairo_restore (cr); + + g_object_unref (page_setup); +} + static gboolean print_pages_idle (gpointer user_data) { PrintPagesData *data; GtkPrintOperationPrivate *priv; GtkPageSetup *page_setup; - cairo_t *cr; gboolean done = FALSE; + g_print ("print_pages_idle\n"); + GDK_THREADS_ENTER (); data = (PrintPagesData*)user_data; @@ -1656,15 +1958,15 @@ print_pages_idle (gpointer user_data) if (priv->status == GTK_PRINT_STATUS_PREPARING) { - if (!data->print_context) + if (!data->initialized) { - data->print_context = _gtk_print_context_new (data->op); - data->initial_page_setup = create_page_setup (data->op); - - _gtk_print_context_set_page_setup (data->print_context, - data->initial_page_setup); + data->initialized = TRUE; + page_setup = create_page_setup (data->op); + _gtk_print_context_set_page_setup (priv->print_context, + page_setup); + g_object_unref (page_setup); - g_signal_emit (data->op, signals[BEGIN_PRINT], 0, data->print_context); + g_signal_emit (data->op, signals[BEGIN_PRINT], 0, priv->print_context); if (priv->manual_collation) { @@ -1684,7 +1986,7 @@ print_pages_idle (gpointer user_data) { gboolean paginated = FALSE; - g_signal_emit (data->op, signals[PAGINATE], 0, data->print_context, &paginated); + g_signal_emit (data->op, signals[PAGINATE], 0, priv->print_context, &paginated); if (!paginated) goto out; } @@ -1751,36 +2053,18 @@ print_pages_idle (gpointer user_data) goto out; } } + + if (data->is_preview) + { + done = TRUE; - page_setup = gtk_page_setup_copy (data->initial_page_setup); - g_signal_emit (data->op, signals[REQUEST_PAGE_SETUP], 0, - data->print_context, data->page, page_setup); - - _gtk_print_context_set_page_setup (data->print_context, page_setup); - priv->start_page (data->op, data->print_context, page_setup); - - cr = gtk_print_context_get_cairo_context (data->print_context); - - cairo_save (cr); - if (priv->manual_scale != 1.0) - cairo_scale (cr, - priv->manual_scale, - priv->manual_scale); - - if (priv->manual_orientation) - _gtk_print_context_rotate_according_to_orientation (data->print_context); - - if (!priv->use_full_page) - _gtk_print_context_translate_into_margin (data->print_context); - - g_signal_emit (data->op, signals[DRAW_PAGE], 0, - data->print_context, data->page); - - priv->end_page (data->op, data->print_context); - - cairo_restore (cr); - - g_object_unref (page_setup); + g_object_ref (data->op); + + g_signal_emit_by_name (data->op, "ready", priv->print_context); + goto out; + } + + common_render_page (data->op, data->page); out: @@ -1791,11 +2075,9 @@ print_pages_idle (gpointer user_data) done = TRUE; } - if (done) + if (done && !data->is_preview) { - g_signal_emit (data->op, signals[END_PRINT], 0, data->print_context); - - cairo_surface_finish (priv->surface); + g_signal_emit (data->op, signals[END_PRINT], 0, priv->print_context); priv->end_run (data->op, priv->is_sync, priv->cancelled); } @@ -1833,15 +2115,19 @@ show_progress_timeout (PrintPagesData *d static void print_pages (GtkPrintOperation *op, - GtkWindow *parent) + GtkWindow *parent, + gboolean is_preview) { GtkPrintOperationPrivate *priv = op->priv; PrintPagesData *data; - + + g_print ("print_pages\n"); + _gtk_print_operation_set_status (op, GTK_PRINT_STATUS_PREPARING, NULL); data = g_new0 (PrintPagesData, 1); data->op = g_object_ref (op); + data->is_preview = is_preview; if (priv->show_progress) { @@ -1862,6 +2148,37 @@ print_pages (GtkPrintOperation *op, data->progress = progress; } + if (is_preview) + { + gboolean handled; + + g_signal_emit_by_name (op, "preview", + GTK_PRINT_OPERATION_PREVIEW (op), + op->priv->print_context, + parent, + &handled); + + if (!handled || + gtk_print_context_get_cairo_context (priv->print_context) == NULL) { + /* TODO: handle error */ + } + + priv->start_page = preview_start_page; + priv->end_page = preview_end_page; + priv->end_run = preview_end_run; + + /* TODO: Do we really need to set these? */ + priv->print_pages = GTK_PRINT_PAGES_ALL; + priv->page_ranges = NULL; + priv->num_page_ranges = 0; + priv->manual_num_copies = 1; + priv->manual_collation = FALSE; + priv->manual_reverse = FALSE; + priv->manual_page_set = GTK_PAGE_SET_ALL; + priv->manual_scale = 1.0; + priv->manual_orientation = TRUE; + } + priv->print_pages_idle_id = g_idle_add_full (G_PRIORITY_DEFAULT_IDLE, print_pages_idle, data, @@ -1877,9 +2194,10 @@ print_pages (GtkPrintOperation *op, GDK_THREADS_LEAVE (); g_main_loop_run (priv->rloop); GDK_THREADS_ENTER (); + + g_main_loop_unref (priv->rloop); + priv->rloop = NULL; } - g_main_loop_unref (priv->rloop); - priv->rloop = NULL; } /** @@ -1964,7 +2282,7 @@ gtk_print_operation_run (GtkPrintOperati &do_print, error); if (do_print) - print_pages (op, parent); + print_pages (op, parent, result == GTK_PRINT_OPERATION_RESULT_PREVIEW); else _gtk_print_operation_set_status (op, GTK_PRINT_STATUS_FINISHED_ABORTED, NULL); @@ -2006,7 +2324,7 @@ gtk_print_operation_run_async (GtkPrintO { run_pdf (op, parent, &do_print, NULL); if (do_print) - print_pages (op, parent); + print_pages (op, parent, FALSE); else _gtk_print_operation_set_status (op, GTK_PRINT_STATUS_FINISHED_ABORTED, NULL); } Index: gtk/gtkprintoperation.h =================================================================== RCS file: /cvs/gnome/gtk+/gtk/gtkprintoperation.h,v retrieving revision 1.10 diff -u -p -r1.10 gtkprintoperation.h --- gtk/gtkprintoperation.h 24 May 2006 16:15:14 -0000 1.10 +++ gtk/gtkprintoperation.h 1 Jun 2006 20:34:39 -0000 @@ -29,6 +29,7 @@ #include "gtkpagesetup.h" #include "gtkprintsettings.h" #include "gtkprintcontext.h" +#include "gtkprintoperationpreview.h" G_BEGIN_DECLS @@ -84,7 +85,13 @@ struct _GtkPrintOperationClass GtkWidget *(*create_custom_widget) (GtkPrintOperation *operation); void (*custom_widget_apply) (GtkPrintOperation *operation, GtkWidget *widget); + + gboolean (*preview) (GtkPrintOperation *operation, + GtkPrintOperationPreview *preview, + GtkPrintContext *context, + GtkWindow *parent); + /* Padding for future expansion */ void (*_gtk_reserved1) (void); void (*_gtk_reserved2) (void); @@ -98,7 +105,8 @@ struct _GtkPrintOperationClass typedef enum { GTK_PRINT_OPERATION_RESULT_ERROR, GTK_PRINT_OPERATION_RESULT_APPLY, - GTK_PRINT_OPERATION_RESULT_CANCEL + GTK_PRINT_OPERATION_RESULT_CANCEL, + GTK_PRINT_OPERATION_RESULT_PREVIEW } GtkPrintOperationResult; #define GTK_PRINT_ERROR gtk_print_error_quark () Index: gtk/gtkprintoperationpreview.c =================================================================== RCS file: gtk/gtkprintoperationpreview.c diff -N gtk/gtkprintoperationpreview.c --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ gtk/gtkprintoperationpreview.c 1 Jun 2006 20:34:39 -0000 @@ -0,0 +1,107 @@ +/* GTK - The GIMP Toolkit + * gtkprintoperationpreview.c: Abstract print preview interface + * Copyright (C) 2006, Red Hat, Inc. + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2 of the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library; if not, write to the + * Free Software Foundation, Inc., 59 Temple Place - Suite 330, + * Boston, MA 02111-1307, USA. + */ + +#include "config.h" + +#include "gtkprintoperationpreview.h" +#include "gtkmarshalers.h" +#include "gtkintl.h" + +static void gtk_print_operation_preview_base_init (gpointer g_iface); + +GType +gtk_print_operation_preview_get_type (void) +{ + static GType print_operation_preview_type = 0; + + if (!print_operation_preview_type) + { + static const GTypeInfo print_operation_preview_info = + { + sizeof (GtkPrintOperationPreviewIface), /* class_size */ + gtk_print_operation_preview_base_init, /* base_init */ + NULL, /* base_finalize */ + NULL, + NULL, /* class_finalize */ + NULL, /* class_data */ + 0, + 0, /* n_preallocs */ + NULL + }; + + print_operation_preview_type = + g_type_register_static (G_TYPE_INTERFACE, I_("GtkPrintOperationPreview"), + &print_operation_preview_info, 0); + + g_type_interface_add_prerequisite (print_operation_preview_type, G_TYPE_OBJECT); + } + + return print_operation_preview_type; +} + +static void +gtk_print_operation_preview_base_init (gpointer g_iface) +{ + static gboolean initialized = FALSE; + + if (!initialized) + { + g_signal_new (I_("ready"), + GTK_TYPE_PRINT_OPERATION_PREVIEW, + G_SIGNAL_RUN_LAST, + G_STRUCT_OFFSET (GtkPrintOperationPreviewIface, ready), + NULL, NULL, + g_cclosure_marshal_VOID__OBJECT, + G_TYPE_NONE, 1, + G_TYPE_OBJECT); + + g_signal_new (I_("got-page-size"), + GTK_TYPE_PRINT_OPERATION_PREVIEW, + G_SIGNAL_RUN_LAST, + G_STRUCT_OFFSET (GtkPrintOperationPreviewIface, ready), + NULL, NULL, + _gtk_marshal_VOID__OBJECT_OBJECT, + G_TYPE_NONE, 2, + GTK_TYPE_PRINT_CONTEXT, + GTK_TYPE_PAGE_SETUP); + + initialized = TRUE; + } +} + + +void +gtk_print_operation_preview_render_page (GtkPrintOperationPreview *preview, + gint page_nr) +{ + g_return_if_fail (GTK_IS_PRINT_OPERATION_PREVIEW (preview)); + + GTK_PRINT_OPERATION_PREVIEW_GET_IFACE (preview)->render_page (preview, + page_nr); +} + +void +gtk_print_operation_preview_end_preview (GtkPrintOperationPreview *preview) +{ + g_return_if_fail (GTK_IS_PRINT_OPERATION_PREVIEW (preview)); + + GTK_PRINT_OPERATION_PREVIEW_GET_IFACE (preview)->end_preview (preview); +} + Index: gtk/gtkprintoperationpreview.h =================================================================== RCS file: gtk/gtkprintoperationpreview.h diff -N gtk/gtkprintoperationpreview.h --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ gtk/gtkprintoperationpreview.h 1 Jun 2006 20:34:39 -0000 @@ -0,0 +1,75 @@ +/* GTK - The GIMP Toolkit + * gtkprintoperationpreview.h: Abstract print preview interface + * Copyright (C) 2006, Red Hat, Inc. + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2 of the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library; if not, write to the + * Free Software Foundation, Inc., 59 Temple Place - Suite 330, + * Boston, MA 02111-1307, USA. + */ + +#ifndef __GTK_PRINT_OPERATION_PREVIEW_H__ +#define __GTK_PRINT_OPERATION_PREVIEW_H__ + +#include +#include + +#include "gtkprintcontext.h" + +G_BEGIN_DECLS + +#define GTK_TYPE_PRINT_OPERATION_PREVIEW (gtk_print_operation_preview_get_type ()) +#define GTK_PRINT_OPERATION_PREVIEW(obj) (G_TYPE_CHECK_INSTANCE_CAST ((obj), GTK_TYPE_PRINT_OPERATION_PREVIEW, GtkPrintOperationPreview)) +#define GTK_IS_PRINT_OPERATION_PREVIEW(obj) (G_TYPE_CHECK_INSTANCE_TYPE ((obj), GTK_TYPE_PRINT_OPERATION_PREVIEW)) +#define GTK_PRINT_OPERATION_PREVIEW_GET_IFACE(obj) (G_TYPE_INSTANCE_GET_INTERFACE ((obj), GTK_TYPE_PRINT_OPERATION_PREVIEW, GtkPrintOperationPreviewIface)) + +typedef struct _GtkPrintOperationPreview GtkPrintOperationPreview; /*dummy typedef */ +typedef struct _GtkPrintOperationPreviewIface GtkPrintOperationPreviewIface; + + +struct _GtkPrintOperationPreviewIface +{ + GTypeInterface g_iface; + + /* signals */ + void (*ready) (GtkPrintOperationPreview *preview, + GtkPrintContext *context); + void (*got_page_size) (GtkPrintOperationPreview *preview, + GtkPrintContext *context, + GtkPageSetup *page_setup); + + /* methods */ + void (*render_page) (GtkPrintOperationPreview *preview, + gint page_nr); + void (*end_preview) (GtkPrintOperationPreview *preview); + + /* Padding for future expansion */ + void (*_gtk_reserved1) (void); + void (*_gtk_reserved2) (void); + void (*_gtk_reserved3) (void); + void (*_gtk_reserved4) (void); + void (*_gtk_reserved5) (void); + void (*_gtk_reserved6) (void); + void (*_gtk_reserved7) (void); +}; + +GType gtk_print_operation_preview_get_type (void) G_GNUC_CONST; + +void gtk_print_operation_preview_render_page (GtkPrintOperationPreview *preview, + gint page_nr); +void gtk_print_operation_preview_render_sheet (GtkPrintOperationPreview *preview, + gint page_nr); +void gtk_print_operation_preview_end_preview (GtkPrintOperationPreview *preview); + + +#endif /* __GTK_PRINT_OPERATION_PREVIEW_H__ */ Index: gtk/gtkprintunixdialog.c =================================================================== RCS file: /cvs/gnome/gtk+/gtk/gtkprintunixdialog.c,v retrieving revision 1.22 diff -u -p -r1.22 gtkprintunixdialog.c --- gtk/gtkprintunixdialog.c 1 Jun 2006 04:58:18 -0000 1.22 +++ gtk/gtkprintunixdialog.c 1 Jun 2006 20:34:39 -0000 @@ -275,7 +275,8 @@ gtk_print_unix_dialog_init (GtkPrintUnix (GCallback) gtk_print_unix_dialog_destroy, NULL); - gtk_dialog_add_buttons (GTK_DIALOG (dialog), + gtk_dialog_add_buttons (GTK_DIALOG (dialog), + GTK_STOCK_PRINT_PREVIEW, GTK_RESPONSE_APPLY, GTK_STOCK_CANCEL, GTK_RESPONSE_CANCEL, GTK_STOCK_PRINT, GTK_RESPONSE_OK, NULL); Index: tests/print-editor.c =================================================================== RCS file: /cvs/gnome/gtk+/tests/print-editor.c,v retrieving revision 1.7 diff -u -p -r1.7 print-editor.c --- tests/print-editor.c 31 May 2006 14:06:02 -0000 1.7 +++ tests/print-editor.c 1 Jun 2006 20:34:39 -0000 @@ -262,6 +262,7 @@ begin_print (GtkPrintOperation *operatio int num_lines; int line; + g_print ("begin-print\n"); width = gtk_print_context_get_width (context); height = gtk_print_context_get_height (context); @@ -304,6 +305,7 @@ begin_print (GtkPrintOperation *operatio print_data->page_breaks = page_breaks; + g_print ("found %d pages\n", g_list_length (page_breaks)); } static void @@ -317,6 +319,9 @@ draw_page (GtkPrintOperation *operation, int start, end, i; PangoLayoutIter *iter; double start_pos; + + g_print ("draw-page %d\n", page_nr); + if (page_nr == 0) start = 0; else @@ -430,17 +435,205 @@ custom_widget_apply (GtkPrintOperation * data->font = g_strdup (selected_font); } +typedef struct +{ + GtkPrintOperation *op; + GtkPrintOperationPreview *preview; + GtkWidget *spin; + GtkWidget *area; + gint page; + PrintData *data; + gdouble dpi_x, dpi_y; +} PreviewOp; + +static gboolean +preview_expose (GtkWidget *widget, + GdkEventExpose *event, + gpointer data) +{ + PreviewOp *pop = data; + + gdk_window_clear (pop->area->window); + gtk_print_operation_preview_render_page (pop->preview, + pop->page - 1); + + return TRUE; +} + +static void +preview_ready (GtkPrintOperationPreview *preview, + GtkPrintContext *context, + gpointer data) +{ + PreviewOp *pop = data; + gint n_pages; + + g_object_get (pop->op, "n-pages", &n_pages, NULL); + g_print ("ready to preview %d pages\n", n_pages); + + gtk_spin_button_set_range (GTK_SPIN_BUTTON (pop->spin), + 1.0, n_pages); + + g_signal_connect (pop->area, "expose_event", + G_CALLBACK (preview_expose), + pop); + + gtk_widget_queue_draw (pop->area); +} + +static void +preview_got_page_size (GtkPrintOperationPreview *preview, + GtkPrintContext *context, + GtkPageSetup *page_setup, + gpointer data) +{ + PreviewOp *pop = data; + GtkPaperSize *paper_size; + double w, h; + cairo_t *cr; + gdouble dpi_x, dpi_y; + + paper_size = gtk_page_setup_get_paper_size (page_setup); + + w = gtk_paper_size_get_width (paper_size, GTK_UNIT_INCH); + h = gtk_paper_size_get_height (paper_size, GTK_UNIT_INCH); + + cr = gdk_cairo_create (pop->area->window); + + dpi_x = pop->area->allocation.width/w; + dpi_y = pop->area->allocation.height/h; + + g_print ("new dpi: %f, %f\n", dpi_x, dpi_y); + if (fabs (dpi_x - pop->dpi_x) > 0.001 || + fabs (dpi_y - pop->dpi_y) > 0.001) + { + gtk_print_context_set_cairo_context (context, cr, dpi_x, dpi_y); + pop->dpi_x = dpi_x; + pop->dpi_y = dpi_y; + } + + pango_cairo_update_layout (cr, pop->data->layout); + cairo_destroy (cr); +} + +static void +update_page (GtkSpinButton *widget, + gpointer data) +{ + PreviewOp *pop = data; + + pop->page = gtk_spin_button_get_value_as_int (widget); + g_print ("go to page %d\n", pop->page); + gtk_widget_queue_draw (pop->area); +} + +static void +preview_destroy (GtkWindow *window, + PreviewOp *pop) +{ + gtk_print_operation_preview_end_preview (pop->preview); + g_object_unref (pop->op); + + g_free (pop); +} + +static gboolean +do_preview (GtkPrintOperation *op, + GtkPrintOperationPreview *preview, + GtkPrintContext *context, + GtkWindow *parent, + gpointer data) +{ + GtkPrintSettings *settings; + GtkWidget *window, *close, *page, *hbox, *vbox, *da; + gdouble width, height; + cairo_t *cr; + PreviewOp *pop; + PrintData *print_data = data; + + pop = g_new0 (PreviewOp, 1); + + pop->data = print_data; + settings = gtk_print_operation_get_print_settings (op); + +#if 0 + /* FIXME need to figure out the size */ + width = gtk_print_settings_get_paper_width (settings, GTK_UNIT_PIXEL); + height = gtk_print_settings_get_paper_height (settings, GTK_UNIT_PIXEL); + + g_print ("%f x %f\n", width, height); +#endif + width = 200; + height = 300; + window = gtk_window_new (GTK_WINDOW_TOPLEVEL); + gtk_window_set_transient_for (GTK_WINDOW (window), + GTK_WINDOW (main_window)); + vbox = gtk_vbox_new (FALSE, 0); + gtk_container_add (GTK_CONTAINER (window), vbox); + hbox = gtk_hbox_new (FALSE, 0); + gtk_box_pack_start (GTK_BOX (vbox), hbox, + FALSE, FALSE, 0); + page = gtk_spin_button_new_with_range (1, 100, 1); + gtk_box_pack_start (GTK_BOX (hbox), page, FALSE, FALSE, 0); + + close = gtk_button_new_from_stock (GTK_STOCK_CLOSE); + gtk_box_pack_start (GTK_BOX (hbox), close, FALSE, FALSE, 0); + + da = gtk_drawing_area_new (); + gtk_widget_set_size_request (GTK_WIDGET (da), width, height); + gtk_box_pack_start (GTK_BOX (vbox), da, TRUE, TRUE, 0); + + gtk_widget_set_double_buffered (da, FALSE); + + gtk_widget_realize (da); + + cr = gdk_cairo_create (da->window); + + /* TODO: What dpi to use here? This will be used for pagination.. */ + gtk_print_context_set_cairo_context (context, cr, 72, 72); + cairo_destroy (cr); + + pop->op = op; + pop->preview = preview; + pop->spin = page; + pop->area = da; + pop->page = 1; + + g_signal_connect (page, "value-changed", + G_CALLBACK (update_page), pop); + g_signal_connect_swapped (close, "clicked", + G_CALLBACK (gtk_widget_destroy), window); + + g_signal_connect (preview, "ready", + G_CALLBACK (preview_ready), pop); + g_signal_connect (preview, "got-page-size", + G_CALLBACK (preview_got_page_size), pop); + + g_signal_connect (window, "destroy", + G_CALLBACK (preview_destroy), pop); + + gtk_widget_show_all (window); + + return TRUE; +} + +/* FIXME had to move this to the heap, since previewing + * returns too early from the sync api + */ +PrintData *print_data; + static void do_print (GtkAction *action) { GtkWidget *error_dialog; GtkPrintOperation *print; - PrintData print_data; GtkPrintOperationResult res; GError *error; - print_data.text = get_text (); - print_data.font = g_strdup ("Sans 12"); + print_data = g_new0 (PrintData, 1); + + print_data->text = get_text (); + print_data->font = g_strdup ("Sans 12"); print = gtk_print_operation_new (); @@ -452,12 +645,15 @@ do_print (GtkAction *action) if (page_setup != NULL) gtk_print_operation_set_default_page_setup (print, page_setup); - g_signal_connect (print, "begin_print", G_CALLBACK (begin_print), &print_data); - g_signal_connect (print, "draw_page", G_CALLBACK (draw_page), &print_data); - g_signal_connect (print, "create_custom_widget", G_CALLBACK (create_custom_widget), &print_data); - g_signal_connect (print, "custom_widget_apply", G_CALLBACK (custom_widget_apply), &print_data); - + g_signal_connect (print, "begin_print", G_CALLBACK (begin_print), print_data); + g_signal_connect (print, "draw_page", G_CALLBACK (draw_page), print_data); + g_signal_connect (print, "create_custom_widget", G_CALLBACK (create_custom_widget), print_data); + g_signal_connect (print, "custom_widget_apply", G_CALLBACK (custom_widget_apply), print_data); + g_signal_connect (print, "preview", G_CALLBACK (do_preview), print_data); + error = NULL; + +#if 1 res = gtk_print_operation_run (print, GTK_WINDOW (main_window), &error); if (res == GTK_PRINT_OPERATION_RESULT_ERROR) @@ -467,7 +663,7 @@ do_print (GtkAction *action) GTK_MESSAGE_ERROR, GTK_BUTTONS_CLOSE, "Error printing file:\n%s", - error->message); + error ? error->message : "no details"); g_signal_connect (error_dialog, "response", G_CALLBACK (gtk_widget_destroy), NULL); gtk_widget_show (error_dialog); g_error_free (error); @@ -489,10 +685,15 @@ do_print (GtkAction *action) g_signal_connect (print, "status_changed", G_CALLBACK (status_changed_cb), NULL); } +#else + gtk_print_operation_run_async (print, GTK_WINDOW (main_window)); +#endif g_object_unref (print); +#if 0 g_free (print_data.text); g_free (print_data.font); +#endif } static void --=-xjDvOKJb0tdB52kmWdgp-- From tomasek@ebed.etf.cuni.cz Fri Jun 2 03:11:55 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 2F96F3B01C7 for ; Fri, 2 Jun 2006 03:11:55 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05061-05 for ; Fri, 2 Jun 2006 03:11:53 -0400 (EDT) Received: from ebed.etf.cuni.cz (ebed.etf.cuni.cz [195.113.5.3]) by menubar.gnome.org (Postfix) with ESMTP id 3EDBD3B011A for ; Fri, 2 Jun 2006 03:11:53 -0400 (EDT) Received: from ebed.etf.cuni.cz (localhost.localdomain [127.0.0.1]) by ebed.etf.cuni.cz (8.12.11.20060308/8.12.11) with ESMTP id k5270gLE004827 for ; Fri, 2 Jun 2006 09:00:42 +0200 Received: (from tomasek@localhost) by ebed.etf.cuni.cz (8.12.11.20060308/8.12.11/Submit) id k5270gdU004825 for gtk-devel-list@gnome.org; Fri, 2 Jun 2006 09:00:42 +0200 Date: Fri, 2 Jun 2006 09:00:42 +0200 From: Petr Tomasek To: gtk-devel-list@gnome.org Message-ID: <20060602070042.GA3470@ebed.etf.cuni.cz> References: <1149203639.27455.9.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1149203639.27455.9.camel@localhost.localdomain> User-Agent: Mutt/1.4.1i X-Homepage: http://www.etf.cuni.cz/~tomasek/ X-Echelon: bomb Arafat Intifada bus kach drugs mafia boss heroin spy Semtex Saddam Al-Qaida Usama bin Ladin Bush Sharon X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.534 tagged_above=-999 required=2 tests=[AWL=0.065, BAYES_00=-2.599] X-Spam-Score: -2.534 X-Spam-Level: Subject: Re: Print preview api X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 07:11:55 -0000 On Thu, Jun 01, 2006 at 07:13:59PM -0400, Matthias Clasen wrote: > Ok, after a lot of work (mostly by John and Alex), > we finally have a proposal for a print preview > api that will allow us to use an external viewer > by default, but also support internal preview. Hi! I think, this is very unfortunate. Many people will not want to use the external viewer (for reasons discused earlier), so everyone will write his own preview widget? Why not just have official internal preview widget like gnome-print has and support it by deafult? P.T. -- Petr Tomasek From shree_poroly@yahoo.com Fri Jun 2 06:49:17 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id DD9063B03E7 for ; Fri, 2 Jun 2006 06:49:10 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19278-08 for ; Fri, 2 Jun 2006 06:49:06 -0400 (EDT) Received: from web53308.mail.yahoo.com (web53308.mail.yahoo.com [206.190.49.98]) by menubar.gnome.org (Postfix) with SMTP id 574673B110A for ; Fri, 2 Jun 2006 06:48:56 -0400 (EDT) Received: (qmail 1625 invoked by uid 60001); 2 Jun 2006 10:48:55 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=opsX4ZJJjJ3RSp61u8057G5DaMkib9ROhHy+AzeYX+l7J8HSwJa+UppJPxFDKOjVDg5ivFj+xumB8simRH1oUSf2tMk9h8YEuyY6OEPoTApYincgsxe7YmLfJe3+jDCaLeD7TV1kXmnpIstEupgel4fQt9kXW1CGDMkwXy+xReA= ; Message-ID: <20060602104855.1623.qmail@web53308.mail.yahoo.com> Received: from [61.246.61.209] by web53308.mail.yahoo.com via HTTP; Fri, 02 Jun 2006 03:48:55 PDT Date: Fri, 2 Jun 2006 03:48:55 -0700 (PDT) From: shree nidhi To: gtk dev MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-596188450-1149245335=:1049" Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=1.399 tagged_above=-999 required=2 tests=[AWL=-3.076, BAYES_50=0.001, DNS_FROM_RFC_ABUSE=0.2, DNS_FROM_RFC_WHOIS=1.447, HTML_40_50=0.496, HTML_IMAGE_ONLY_12=1.867, HTML_IMAGE_RATIO_02=0.463, HTML_MESSAGE=0.001] X-Spam-Score: 1.399 X-Spam-Level: * Subject: Fwd: test X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 10:49:17 -0000 --0-596188450-1149245335=:1049 Content-Type: multipart/alternative; boundary="0-601274911-1149245335=:1049" --0-601274911-1149245335=:1049 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Note: forwarded message attached. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --0-601274911-1149245335=:1049 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit

Note: forwarded message attached.

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com --0-601274911-1149245335=:1049-- --0-596188450-1149245335=:1049 Content-Type: message/rfc822 X-Apparently-To: shree_poroly@yahoo.com via 206.190.49.100; Thu, 01 Jun 2006 21:38:26 -0700 X-Originating-IP: [202.71.129.68] Authentication-Results: mta129.mail.mud.yahoo.com from=galieosoft.com; domainkeys=neutral (no sig) Received: from 202.71.129.68 (EHLO smx1.net4india.com) (202.71.129.68) by mta129.mail.mud.yahoo.com with SMTP; Thu, 01 Jun 2006 21:38:26 -0700 Received: from [125.22.33.12] by smx1.net4india.com with smtp (Exim 4.51) id 1Fm1a8-00025h-AB; Fri, 02 Jun 2006 10:18:21 +0530 OM-Header: origin=omniqube Received: from unknown (192.168.0.89) by SMTP-Receiver; Fri, 2 Jun 2006 10:07:06 +0530 Subject: test From: Nidhi To: nidhi@galieosoft.com, shree_poroly@yahoo.com Content-Type: multipart/mixed; boundary="=-k0bJJnk7Qaq1V0+G97NB" Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-1) Date: Fri, 02 Jun 2006 10:12:00 +0530 Content-Length: 21206 --=-k0bJJnk7Qaq1V0+G97NB Content-Type: multipart/alternative; boundary="=-rVG5rqf50PHPN/AXL0Ln" --=-rVG5rqf50PHPN/AXL0Ln Content-Type: text/plain Content-Transfer-Encoding: 7bit I have developed an application for an handheld device, the initial window will look like this : But the device is having rectangular display if i place the window as it is my drawing area will look compressed, so i dont want to compress my drawing area. If i can tilt the window and display i hope my drawing area will look like enlarged. Is there any way to tilt an application window as shown please help me out. --=-rVG5rqf50PHPN/AXL0Ln Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
I have developed an application for an handheld device, the initial window will look like this :









But the device is having rectangular display if i place the window as it is my drawing area will look compressed, so i dont want to compress my drawing area. If i can tilt the window and display i hope my drawing area will look like enlarged.







Is there any way to tilt an application window as shown please help me out.


--=-rVG5rqf50PHPN/AXL0Ln-- --=-k0bJJnk7Qaq1V0+G97NB Content-Disposition: attachment; filename=test1.map Content-Type: application/octet-stream; name=test1.map Content-Transfer-Encoding: 7bit --=-k0bJJnk7Qaq1V0+G97NB Content-Disposition: attachment; filename=test2.map Content-Type: application/octet-stream; name=test2.map Content-Transfer-Encoding: 7bit --=-k0bJJnk7Qaq1V0+G97NB Content-Disposition: attachment; filename=wintilt.sxw Content-Type: application/vnd.sun.xml.writer; name=wintilt.sxw Content-Transfer-Encoding: base64 UEsDBBQAAAAAAJZQwTSAkGt+mxsAAJsbAAAtAAAAUGljdHVyZXMvMTAwMDAyMDEwMDAwMDEzNzAw MDAwMTM0REUzMjdBMTMucG5niVBORw0KGgoAAAANSUhEUgAAATcAAAE0CAYAAABJtnScAAAABHNC SVQICAgIfAhkiAAAABV0RVh0U29mdHdhcmUARXllIG9mIEdub21lCx+PrwAAGzFJREFUeJzt3X1w XOVh7/Hfvmglr23ZMS/BAWNbmBcrYPOSmCQ0kUMgwYQyIS+9uDdphyZtYzFzk6bJVWZaT5JbXXqH zjT3TlM70Et7XQ+95OIggkOhxAnrtBjiYBAGS7Zky/KLkLEl68162Zdzzv1jdY53VytZu9rVrh5/ PzMaafe8PUe757fPeZ7nnPVJcoQ5o2phtQLBoIb7zqY97/f7S1QioPzYtq2gJLUeP65jp8+oZ2BA I9FYqcuFHLR3dWn3rl165I+/qurqas2bN08VFRWEHS5Kw8PDuu222yQpGW7HTp/RL99sLmmhkJ+9 e/cqeu6cBgcHFQ6HFQwGVVlZqWAwmHX+eDw+5fp8Pp/3t9/v9x47jiPbtuU4U1f0Z7p8IaSWYap5 UuebbBm3vJP9Lib2Y6LJyu++1/r6+7zHQUk609+ffPM5jvzTKAjKh+M4io+NanR0VJZlye/3q7Ky UhUVFZLST1dt21ZVVZUcx5HjOGlvKPfNMZ03IlBuotGogsGgomNR77mgJA2NjimWSMhxHAXGD4Zd zzbJTiRkJRJy3E9cx5HcN3/G3z6/Xz6/Xxse3Di7e3URsx1HtmUpOjysnp4eLViwQBUVFXIcR6FQ SBUVFV7ISclaWzwel2VZXrgFAgFvvmAwmFbbAqbrBz/4gWKxmOLxuBKJxJS1dJ/Pl6xZBYN69NFH C7L82NiYqqqqNDY25s0XlKR4IqGEZcm2HVl+W5KUiMX01P/+Bx1+t1vv9fVraHR0yp07fvq0Xvjn bYolEjn+WzAjjqPoyIh+9PQOVS2sVmU4rGBlpQIVFfrhw5tUVVWlYDCoh//u72UnEkrEYrIty/tw 8gcC+uHDmzR//nxvXtrrkKvh4WE9/vjj055/3759euSRR3Tu3LmCLH/69GktXLhQI8PD3jxBSUpY luIJS5ZtezU3Kx7XoZNdemnfmxNOVbOdvr75H/+u6MiI4glr2gXMxcZP1mk0GtWze14ryvoLvb3N //lBLZo/X99+/IkClyzd6rU364H77kt77uCJk3o98rK6urq0ePFiVVRUKDYyoi3f26yO7lN6r69f w2Njajl+Qm/sjqirq0uXXHKJFi5cqKqqKgUCgaKWGeYZHa/8dHZ2Tmv+nTt3qr+/31tupsufPXtW Pp9PwyMj3jxBSYolEorG40pYloLjb2w7kdDx02cUz1ITc09pUtmWpUR0TNGMButt3/mWJKntZJf+ +//9iff81++7Vx9dfYOOnz6jzdu2X3BnPrl2jfrOndNPdv/7tHY+1Z9/8QGtWblS3/mHf9Tp/n5J 0lc+dafuuvVm/d3Pdur1tnZJ0t233qIvfvwOPfyjrTPaniQtmDdP1eHwhP9HMbzVcTTtcfv+tzQ6 OKCenh75fD5VVVUpEY2q7WSXdr62N+t8qaems9HIDLO4HVUX6rBKNTIyosR4vmQuf91116mtrS1t /sznUpcfGRnRggULstfcYu6p6fgb27Ys9Z87p2g8ntbj5fP50t787jTbtmUnEpOell575QdUWVGh odFRBQMBra1ZmVynnGmdym7860cvOM9k9nd0as3Klbph2VU62dMjSfrgiqu9cu1paZUk3bRyhfYf 7dRINDqj7UnJsz5Js3Kanvl6OLat2MiIBgYGFA6HZdu2ErGYTvb0euVxxtvr3Pmqq6sVDofT2unc Dgba4HAhlpU8Y0vk8H6PxWKybXvC8rW1tZKSYdbS0iJJWZ9LXd5tSx5JaT7zam5j420xCbfmZlmK xuNT1jz8Pt/5MEwkZFuWxmITx8n1DA7q0upq3bhiuV5+a7/W1tQoFo8rXFkpx3E0Fovp0upq/ZcH 7tc1S5dqXiikd3vP6p9e+oX2tR+WJDV97y/VOzSkr/3t/0p7/I8vvqSv3vNphSsr9c+7fqUXfvv6 hO2/3tauL3/qk/rg8qv189/s1WWLFmnpkiWSpBuWXaWxWEyVFRWqXX61Hnv+BY3FYjlvryIQ0B/d 82l94qYbFa6s9LY9FovJJ+l3P3K77l33IV26aJF6Bgb0r3tf187f7JXjOPq9uo9r4/o6ffvxJ3Sk u1t/9vnP6RM33aiGJ/5JbSe79J0vfUFDIyP68fMvTPo6uNxOhkQ06oVbNBpVIhrV2aGhtNfHGQ+9 oaEhDQ4OKhQKeZ0RwWDQq8kRcLgQ9wM2l3CzbdsLp9Tl9+/frzVr1kg6H2qu/fv3e9tIXd6yLNm2 PbFDQUq2sdmWJcfdmG0rlkjImiLcUlvXbCvZ25pt/n2H2nT3bbfqtmtXadfr+7TuulV6rfWg7vnw h7xlApLeaGvXthdfUlUopL/88u/r4fvv0x/+j785v6KM9S8Kh7VxfZ1+vf9tfe6Oj2nj+k/o53te nbD9o+++q75z53TTyhWSZemm5VdraGRER0+9p5tWrtC8YFA3LLtKFYGAXm89eH4bOWxvY90ndM+H btPOV1/TL99o1l899AdaGA7Lisd1/8c+qoc+c7d+03pQf/OTHfpi3cf10GfulmPbevaVPXrnSIe0 vk6rr7pS7SdO6IPLx2uVS5fqYOcx3bhiubb+bGfW/21qE4H7t21ZSsRievKlXygUDisQDMq2LDW3 tav70MHMFejJX+xSKBxWRdU8BUMhBSoq9N8e+kOFw2FvzBydDJiKG065nJZK52tsmcvv27fPG4zr 2rdv34T1u8vbti3LsjQWzRgK4krEYvK7NTfbTvaiZqmJZWOPDy/INv/g8LDeOdqpW69dJb9t6/Yb btD/3PFTL9wSsZiOd3frxKlTWrpkiRYtWKC+oSEtveSS9PU5SnscTyT07S0/1uDwsNavXaPFCxZM Wt4329p15623aOXll+vmmpV6s/2wjp16T2tqVuq6DyzVrauu0ZGud3W6tzev7a1fm/yk+ZeXdmlg eFixeML7n957+4clSY/9bKdOnT2rH/ed1UdW36B7b1+nHS9HdKDjqBKWpdrlV+vVt9/RwnBYPQMD uu7KD2jZkiWqDof1Zlv7tF+Ly1bWaP2nP5323IH2w3r7317wPsAc25bP79fTTz2lA8eOqaunV4Mj IzrQflhdB95RT0+PlozXbiXRyYAp5VNzcxxnQrhNtXzmtNTl3RpcIiX80sLNisckhdwllbDs5LAB yTsYvBVneazxU6IJO2E7eu1Ai9ZcU6MHPv47CldVqnm8EV9OMhhXXXWl/uIPvqIlCxfqxOnTuqS6 OlnotPWlr39kbEz9g4PJsrs7mWX7kvTGoTbdeestuvXaVVq7apWeeP5f1XXmjL7ymbt148oV+vD1 1+tX+97Ie3uXLkqWt39oaPyFOt92edmiRZKkU729sm1b7/Umrwu9bPGi5Km8ZantxEl9cMUKralZ qdbOY+o/d06rl1+tNdfUqOPdbm+7U3Fr3ZK0f7wd0XW644jsREIbbl+nyspK+f1+Pffqa3qr46ie +eWvzs935LDGhgbV29vrnZYGAgE6GTAlL1zGA+iOO+7IOt8rr7zi/e04Ttop5oWWv/322ydd3v2d 2nySHm7jA3ndjcUSCSViUU3H+ZrbxPltK6FXmpv1J/ffp4133ak9b7+j0ZHh8QLaSsSiemjDPVp6 yRJ9+Xs/0KmzZ/XYd/+rrrnyyrT1OY4mfewee5OV97cHDkiS7vvYR1Q9P6zfvvOO+oaGFIvH9anb btX7Fi7Uq2/vz3t7o9Go5s+bp4WVIQ2PjqoqFPKmn+7r15WXXapLFoTV3dOrK8ZrRGf6+rzl97e3 q3bFcn32ox/RK2+/reHRUdXdvFbrb1mrNw4enPbrMBnHtmUlEgoGg1qwYEGyXS0UUkd3d9q63UHB fX193nWqktI6Gc7/P85fApN5xQOdEReX1Ib9qaROdxxHsfGzkdTl169f780TiUQkyXvujjvu8J5L XT5bjS8t3Bzblp3yd8KyZMXjaTW0bNzTnElrbo6jE6dO6fip93T1Fe/XfzQ3n59vvObmNorX3XKz zo2O6qrLL5ckfej667V3vHcksyaV/vh8TSmbM2fPqrO7WyuWLtWJ997TqfFe05ajnbr5ums1NDyi lo6j3j851+292dau31m7Rn/24O8pVBFS5Xi42ZalZyMRPfylL+rrD3xOT774b/r98VPGZ3f/2lu+ ua1ND959l6656kr9/Y6fKuZ2iS9bpv+z8/lJasTJsrqvj1ubzvwtSXYinrzixLK8Ed7y+dQzOOSd qvr8fq+9bnBwUPPnz5ff71c8HlcoFFIgEPA6GNxPTbch1w03v9/vXfUQCAQIuItEZm/prl27ss6X GkK2bXvhlLr8rl27dNddd2nXrl1p68t8LnX5bDJOS+Nem5scR/HxS6/s8QMis/FaShkK4p6mZRsX Nz5M5IdP/ouWXfF+7Wl+K2U+R3YiocefadJffPUh/dH9v6vd+97QE8/+TH/8wOf0n+7+lF7bv//8 PyRj/Rd6nOr1Ay1asXSpXm9p9eZrPnRIN193rX5z4J2sbVrT3d6Pn96hZZdfrjXXXqutT+/Q8ive r0sXL5adSGjHrl/KL58+f+cn9aNv/7neO3tWW3f8VE//YpfX2/x2W3uyp9O21XL4sKzxNs+A36+3 Dh70tpM5xtBxHCkl+Hxu0GT8dod+PP/qawrNmyd/ICDbttXeckC9x48ll3VfW9vWT3f/WqGqKgUr KxUMheQPVuhbX/qCd0r76P/b4V2el7ziwZZ8fvkDAX3rS1/QvHnzvF5Xws18maeV0xUd7wDIXP7F F1+csK5sz7nLZ7tRhE+Ss3nbdjW3tevsyRPeJ/3hPa9o1cfuUHdry4SFJtNzrFM33XPvtOdHAbjn xz5f+vW+Wea7+vob0p463nZIR3+793wnw3hwPvnUU3rj8BEdPXVK/eeGdbztkM50HNHX7vusFixY oGAwqB89+5z+tvGv0uc7dFBnjnboa/d9VosWLVI4HPZqfDDbY489pkceeUQ7d+6c9jLPPPOMvv/9 7xdk+Wg0qiuuuEKRSESNjY2SspyWpjYcH9r9cvJaxPELWeVM0qg8fjriHx9ygPLUmfFB1XfyhKx4 XB9fc5NCoZD8fr9ebn5L+9oP69mf/zxtvrGhIfX29sqyLIVCIcWjY1POJ52/zRHhZj7HcfTNb35T IyMjyXGVKe33mXw+n3drLndc2kyXr15UPWG4Ulq42Zbl1dxWfnhdfjuZ1maFcpZsckh2MsyfPz/Z ThYK6dDJrrTX0bFtxUZHNTAwoIqKiuSdG2KxKeerqqryApNwM9/GjfndDcg9rZzp8u9bvESZNxWf UHPD3DDV0Ixs7aKpl865v5N/+71PwVAoJH8goJ6BgbQauHepVizmvZkcy7rgfGNjY4QbZsWSJe/T 0NBQ2nMTWuHOnjwxawVC6dl2MoxGR0eT99FKJNR9sFX93e+mz2clNDw87PWExsbGppyvv79fiUTC 64AAimlRdbV3hxDXhHBr+/XuWSsQysNPjhxJe3zsjX1Z53sqc759E6/jzTYfUGzf+MY3JvTKp4Vb YHygZilHo7e2tl54JgAYV1tbm/UO0tm/RUSlCZna2lrvdiYAMBNl0xjiXlIBAIVQNuEGAIVEuAEw 0qRtbuUq8/Q19Q4Cc5WJ+wSU2pwJNzcA6uvrJ0zbsmXLnAwEE/cJKBc5hVvm/cxdqV/ikO3vmYpE Il4AZBum4vP58gqDfMpYqP0q5D5dqEyl7IWmBxylknObW0tLy4Sf1GnFNNn4u3zG5bkH3WSBPVsK tU+T7Uep9w8olYJ2KEx1INXW1no/uXBrOBc62Ddt2qRIJKLVq1fntP5sMsvoPs787f6d636VYp9S TVbm1P2bbNpUj/N5fYFimZXeUreW5P6U+gBIPVXKpTypy6Supxz2K9v2s50SXqjMqdOnuz/l9H8A XDl3KGS+cWlPmVsu9Hrl83ryHkA5yjnc8n0jl9unebmVpxDcWlPq72yKse8m/j8xt83aUJB8Q3G6 PaBbt27Vpk2bLnhN7GQH/Wz26hV6n3KRuZ+FCKVirBOYqZJcoZDrm3/Lli0l+5KRYh2oxdqnC9Xa CoHwwlwwKzW3zEbmXA+89evXa8uWLV5NJtXWrVslqaA1nNTy5tLonst+zfY+pZYxs8zTCcOp/if5 rhMoprRvv+o9fkx7tm+T4zizfssjd3jEhQ6IzEuV3GCYy/eBM3GfgNlSW1urvr4+dXZ2qqmpKfu3 X80FmbUcEwLAxH0CSm3OhZuJB76J+wSUGrc8AmAkwg2AkQg3AEaass2N7zUAMFdNGm4M1AQwl2UN t9bW1oIMwCz0rXoAmKdYowWKPhSEYQ4AJlPMK1noUABQEsVu0y9quJXqYneUL9pyMVvm3BUKMMtM bqgATIVwQ8lkuw8cAYdCoc0NgJEINwBGItwAGIlwA2Akwg2AkegtRdFMNqaNXlHMBsINRTPZt8+7 wTbTLw4CpkK4oagmC7jU6UAx0OaGokutqQGzhXDDrCDYMNtm5bSUi6WRivcDZkNRw81xHO4MAqAk soZb6h108w0nx3G0fv161dXV5VcyABeF5557rijrnbTm5t5BN9+2Ep/PR7ABmJaGhoa8lrNtW9/9 7nezTivKaSltKgByletXEtTW1sqyrEmn01sKYM6Zzi3KCTcARiLcAJStmTRxEW4AypIbbPkGHOEG oOxkBlo+AUe4ASgrU90qKxfcFQRAWSnUdcjU3AAYiXADYCTCDYCRaHMDUDamc+XBdBFuAMpCoa9J J9wAlAXHcXJexrbtSacRbgDKAncFAXDR464gAC5ahBsAIxFuAIxEuAEwEuEGwEiEGwAjEW4AjES4 ATAS4QbASIQbACMRbgCMRLgBMBLhBsBIhBsAIxFuAIxEuAEwEuEGwEiEGwAjFfU7FGrW1aQ97tjb wXSmM53pWacXmk+Ss3nbdjW3tav3+DHt2b5NjuPk/GUNqdyv6KqrqytQMQGYasOGDWpoaMgpcyKR iOrr62VZlgKBgPr6+tTZ2ammpiY1NjZK4rQUgKEINwBGItwAGIlwA2Akwg2AkQg3AEYi3AAYiXAD YCTCDYCRCDcARiLcABiJcANgJMINgJEINwBGItwAGIlwA2Akwg2AkQg3AEYi3AAYiXADYCTCDYCR CDcARiLcABiJcANgJMINgJEINwBGItwAGIlwA2Akwg2AkQg3AEYi3AAYiXADYCTCDYCRCDcARiLc ABgpWMyV16yrSXvcsbeD6UxnOtOzTi80nyRn87btam5rV+/xY9qzfZscx1Fra2veK62trZUk1dXV FaiYAEy1YcMGNTQ05JQ5kUhE9fX1sixLgUBAfX196uzsVFNTkxobGyVxWgrAUIQbACMRbgCMRLgB MBLhBsBIhBsAIxFuAIxEuAEwEuEGwEiEGwAjEW4AjES4ATAS4QbASIQbACMRbgCMRLgBMBLhBsBI hBsAIxFuAIxEuAEwEuEGwEiEGwAjEW4AjES4ATAS4QbASIQbACMRbgCMRLgBMBLhBsBIhBsAIxFu AIxEuAEwEuEGwEiEGwAjBUtdAFw8Irt3e3+vr6srYUlwMbhguNXW1ua98pp1NWmPO/Z2MP0inq6U cCvH8jG9xO+PAvNJcjZv267mtnb1Hj+mPdu3yXEctba25r1SNxDr+HRGCmpuyGbDhg1qaGjIKXMi kYjq6+tlWZYCgYD6+vrU2dmppqYmNTY2SsrhtDS1BtfS0pJD0YEkAg2zaVrhVltbmxZomY8BoNzQ WwrASIQbACMRbgCMRLgBMBLhBsBIhBsAI01rKEhLSwvj3ADMKdMexEugAZhLOC0FYCTCDYCRCDcA RiLcABiJcANgpBmH20xuZgkAxVKQmhsBB6DcFOy0lIADUE4K2uZGwAEoFwUNN65iAFAuChZuBBuA clKQcCPYAJSbGYcbwQagHDGIF4CRCDcARiLcABiJcANgJMINgJEINwBGItwAGIlwA2Akwg2AkQg3 AEYi3AAYadpfypyPmnU1aY879nYwnelMZ3rW6YXmk+Rs3rZdzW3t6j1+THu2b5PjOGptbc17pe5N K+vq6gpUTACm2rBhgxoaGnLKnEgkovr6elmWpUAgoL6+PnV2dqqpqUmNjY2SOC0FYCjCDYCRCDcA RiLcABiJcANgJMINgJEINwBGItwAGIlwA2Akwg2AkQg3AEYi3AAYiXADYCTCDYCRCDcARiLcABiJ cANgJMINgJEINwBGItwAGIlwA2Akwg2AkQg3AEYi3AAYiXADYCTCDYCRCDcARiLcABiJcANgJMIN gJEINwBGItwAGIlwA2Akwg2AkQg3AEYKFnPlNetq0h537O1gOtOZzvSs0wvNJ8nZvG27mtva1Xv8 mPZs3ybHcdTa2pr3SmtrayVJdXV1BSomAFNt2LBBDQ0NOWVOJBJRfX29LMtSIBBQX1+fOjs71dTU pMbGRkmclgIwFOEGwEiEGwAjEW4AjES4ATAS4QbASIQbACMRbgCMRLgBMBLhBsBIhBsAIxFuAIxE uAEwEuEGwEiEGwAjEW4AjES4ATAS4QbASEX9DgUAyEUkEinYugg3AGXB/e6VQiHcAJQFx3FyXsa2 7UmnEW4AykKu37hXW1sry7ImnU6HAoA5Zzptc4QbACMRbgCMRJsbgLIyVa9pS0vLtNdDzQ1AWZks wHIJNolwA1CGMoMs12CTCDcAZcoNtHyCTSLcAJSxfINNItwAGIpwA2AkhoIAKBuzdleQQm4IAKYy a3cFKfSGAGAytm1PeRF8PrKGW2tr64x6KVzPPffcjNcBwGz333+/Dh06VPD1Fr3NraGhodibADBH 2bZdlGCTZqlDIZ/7NDmOk/NyAGZfvsfrhe7HNlNlNxSETgxg7sj3eJ2N47yk4UanBWCuUh/fJQu3 Uu84gOIr5XFeknAj2ICLR6mO91kPN4INuPiU4rif9XArxPg5AHNLKY77kpyWEnDAxaNUx3vJOhQI OMB8pTzOSzoUhIADzFXq47vsBvECQCHM2v3cynkkM4DCKKfjdVbCLd9uYIaNAHNHuR2vRQ+3fO/T VIz7OwEojnI8XrOGW6GqltXV1XrssccKsi4AyEXWcNu0adNslwMA8lJfX5/1+bRws+JxSZLP5yt+ iQCgCGzblpQRbpdfs0qbt20vSYEAFEZzW7sORn6lTV/4vFavXq1ly5bpgT/9uh78kz/Ne/rixYtV WVmpQCAwZyo/E05Lm9vaS1EOAAVy+shhxcbG1Nvbq+7ubklSbGxMUvL4zmf6wMCAKisr5ff751a4 uTsEwAznes6oublZXV1dWrx4cfJxynGe6/SqqioFg0H5/XNn3L9PklPqQgBAoc2dGAaAHPx/YMnV s9b8aj0AAAAASUVORK5CYIJQSwMEFAAAAAAAllDBNLasV216HwAAeh8AAC0AAABQaWN0dXJlcy8x MDAwMDIwMTAwMDAwMTM0MDAwMDAxMzdBQjUxQTdGMS5wbmeJUE5HDQoaCgAAAA1JSERSAAABNAAA ATcIBgAAACQVvTEAAAAEc0JJVAgICAh8CGSIAAAAFXRFWHRTb2Z0d2FyZQBFeWUgb2YgR25vbWUL H4+vAAAfEElEQVR4nO3de3hc5WEm8PecGd1tSb6C8QUsbNcShRAMsg2bWoBJIFwCXdJC+zRZIKGR S7fbbGG7adNsku4fLm36bLtIlDalSdjCEggEtgmlEMZJHYIxxBgs2QZ8wYCNbUmj0Whmzn3/kM7x jOZyzpyZo/nm6P09jx+kkWbmNbZef+c73/mOBMACAFmWQURUD0zTLPh4lEVGRGERBYDXXnsNqqZC ySjIZDJITU5iMpVCanISqXQamUwGGUWBrmmQJKnWmYmIcnzjG98AMF1obW1tWNS8CK2trdB1HWNj Y0gmk1AUBYZhwDRNGIZR8IVkWYYsy4hGo2hoaEA0GoUkSSw+IpoVTz31lPNx1P7Asizouo5MJoOJ iQmMjo4ilUpB0zSn1EzThK7r0HV96snRKJqbmzG/fT4WdC7E/Pnz0dHejuaWFs7JEVHgjhw5kvO5 U2imaaKpqQlNTU2IRCLo7OyErutOkRmGAcMwoOs6VFWFqqpQlKlD1MR4AqdOnkImk8GJEyec4R8R UVDGxsbyHosW+L6qGBoaCuqlq+qZZ57BvffeW+sYRHPCgQMHKnp+LBZDf39/0Sktp9Dsb7jvvvsw MjKCeDyOVCoFVVWdU6SWZTm/7MdkWUZDQwPuueeeioLWkizLvub8LMviXCHNOX7/3hebh6+mvBGa ruv4yle+gmeffdbzizzxxBNVDVULQ0NDiMVinr9/27Ztvp5HVM/8/r23nxe0vBGaaZrYsGEDFi1a BE3TnJMAxT5++eWXnZME9a6vr8/T9838g/T6PKJ65vfv/Wz+g593KtKyrJzPe3p68p408zcy8zlE RLXgFFqhY+J169YBAC666CLnsSuuuAIAsHXr1qCzCaFQoRNRLlF+TkouFjt48KDz8YYNG7Bx40bn 8xdeeCG4VIIQ5Q+JqB6I8PPiuvq10PKLuTAJLsIfDlG9qfXPDZfzF1DrPxSielbLnx/XQvNyUiBs 6mVRMJGIavnzk1do2ScH7JMCwNSOHK+88orzefZJgTAuLmWpEZWv1j83TqHZSy+yLyq3Twrs3bvX eWznzp0Ack8KRKOBXUFVU7X+wyGqJyL8vOSN0GaWk5eTAk1NTdVNJRAR/pCIRCfKz0ne0KqhoQEA cN5553l6gcWLF+PFF1+saijRhX0OkagQv3/vZ/PnJWc/NABobGzE3XffjXQ67eyFNvOidHs7Ifvj lpaWWQsclO7u7rK+3/7/Ve7ziOqZ37/32RtaBCmv0L72ta8hmUwinU573g8tk8lAUZTAwwZl+/bt tY5ANCfcdNNNgb5+3c7md3d3V+Xs6pYtW6qQpnq6ertwaNehWsfIwUzuRMsDiJkJQEX7D7ot6s8r tHraD62SrXtmazsTIsrld/9BL/up1f1+aGGboBfxX1RmcidaHkDMTLag9lPLK7S5vB8aEc2eIPZT c90PzQvuh0ZEIij74vQrrrgidId5RBQO3G1DMF29XbWOkIeZ3ImWBxAzUynV2KWDhUZENWeXWaWl lndxOhHRbJpZYpWUGkdoRFQzxcrLb6nlLdvws+AtjPuh1YqIa4eYyZ1oeQAxM81U7V068gotez+0 Qnbu3OmsQ3NeJKT7oRFRfXHdD82LMO+HRkT1g/uhEZHQyln3mldoc3U/NFGIuEMCM7kTLQ8gZiZb UPup5RXaXNwPjYhm16zttkFEFLRZ222DiGg2zMpuG1RbIs55MJM70fIAYmYKGguNiEKDhUZEdcle eZGNhUZEdSl76ZiNhSYYEfewYiZ3ouUBxMxUTYqiQFGUnMswWWhEVJfi8TgSiQQymYzzGAuNiOrS sWPHcPz4ccTjcecxrkMjoro0PDyMkZERnDp1ynmMhSYYEdcOMZM70fIAYmaqpsEnfwA1k0HyNAuN iOrc+r6rcPLdd4C16zBy9CgAzqERUZ26eN1aLD1/Tc5jHKERUd26eN1a7Mn6nCM0wYi4doiZ3ImW BxAzUzU99tDf4bt/87/w80e+4zzGQiOiuvTU3z2IB//8m/idW25xHmOhEVFdKrkOjbeiI6J6wnVo dUDEtUPM5E60PICYmaqp5Do0jtCIqJ5wHRoRhUbJdWgcoRFRveE6NMGJuHaImdyJlgcQM1M1lVyH xhEaEdUTrkMjotDgfmhEFBpch1YHRFw7xEzuRMsDiJmpmrgfGhGFBtehEVFoFFqH5hTazBt2EhHV G47QBCPi2iFmcidaHkDMTEFjoRFRaPCQk4hCg4VGRKHBQ07BiLh2iJnciZYHEDNT0FhoRBQaLDQi Cg0WGhGFBgtNMCKuHWImd6LlAcTMFDQWGhGFBguNiEKDhUZEocGFtYIRce0QM7kTLQ8gZqagcYRG RKHBQiOi0GChEVFosNAEI+LaIWZyJ1oeQMxMQWOhEVFosNCIKDRYaEQUGiw0wYi4doiZ3ImWBxAz U9BYaEQUGiw0IgoNFhoRhQYLTTAirh1iJnei5QHEzBQ0FhoRhQYLjYhCg4VGRKHBQhOMiGuHmMmd aHkAMTMFjYVGRKHBQiOi0GChEVFosNAEI+LaIWZyJ1oeQMxMQWOhEVFosNCIKDRYaEQUGiw0wYi4 doiZ3ImWBxAzU9CcQpMkqZY5iIgqxhEaEYUGR2hEFBocoQlGxLVDzOROtDyAmJmCxhEaEYUGR2hE FBocoRFRaHCEJhgR1w4xkzvR8gBiZgoaC42IQoOFRkShwUIjotBgoQlGxLVDzOROtDyAmJmC5hSa ZVm1zEFEVDGO0IgoNFhoRBQaPOQUjIhrh5jJnWh5ADEzBY2FRkShwUNOIgoNFhoRhQYLTTAirh1i Jnei5QHEzBQ0FhoRhQYLjYhCg4VGRKHBQhOMiGuHmMmdaHkAMTMFjYVGRKHBhbVEFBocoRFRaLDQ BCPi2iFmcidaHkDMTEFjoRFRaLDQiCg0WGhEFBosNMGIuHaImdyJlgcQM1PQWGhEFBosNCIKDRYa EYUGC00wIq4dYiZ3ouUBxMwUNBYaEYUGC42IQoOFRkShwUITjIhrh5jJnWh5ADEzBY2FRkShwUIj otCI1jpANfX09BT92tDQ0CwmIaJaCE2h9fT0lCwtt6+Loqu3S7i5D2ZyJ1oeQMxMQeMhJxGFBguN iEIjNIecQ0NDnEMjmuNCU2hAOEpLxDkPZnInWh5AzExBC1WhFVMvJwTIm9iOHc7HfVu21DAJiSYU hVbqULOc7yGi+uYUmiRJtcxREbfRV3aZ2d/LgiMKH+cspyzPjROeoheZiHtYiZapb8sW3HnvHUId bor2/wgQM1PQnBar5xFaOTiXRhRevufQLMuCZVkwDCPnl2mars/1MkoKonhYZkTh5hSaZVmen2SX ma7rUFUV6XQamUwGmUwGiqK4Pr8WxcIyIwo/55DTy8jKZo/MVFVFKpVCIpHA2NgY4vE4kslkxaGq Pc9VT2Um4tohZnInWh5AzExB83XIaVkWNE1DOp3G+Pg4RkZGMD4+DlVVMTk5WdZrFSqveiogIhKH 7zk0wzDwre8/icxEApmJCajpNEzDgGnonl8je8FrsY+JiLzyPYdmmiZMw8CS1V0Yee8oWtrbnbm1 U+++G0hYIqJSfC0+s4sLlolVv7IeC1asxIIVK9F5zvJq55tzRFw7xEzuRMsDiJkpaL4KTZKkqXVr kozOeW2+3zx7hwz7Yx5uEpFfvubQJEmCLMuQIxGsPvts7KkgQHZ5sciIqBK+TwpEIhFEolFcsuZ8 WDfcgAPvf4DT4+Owylj+QURUTb5HaNFoFHI0ii//6VehKRnoqgrLMKBmMp5fhxsy5hNx7RAzuRMt DyBmpqD5HqFJkoT7fuNWjI+PY2JiApOTk1BVFaOjo3jgtd2eXqNQaXEOjYj88r3Fhr10w778SVVV KIoCTdMqCuS2lTYRUTG+9kOzr+NUFAXJZBLxeNz3lQJERNXiFFq5+6FV60qBQubyIaeI91JkJnei 5QHEzBQ0TyM0+/DS3iJI0zSoqgpT17Ck63yMHD3i60qBuVxcRFR9ricFsrcKUhQFmUwGyWQSExMT 0FUVq9b9CkzDgDV9KdTYB+/PRm4iojyu13LOnC+bmJjA+Pg4xsfHoStKRVcKADzsJKLqcQqt2H5o 9lZBqVQKo6OjGBkZwdjYGBKJBNRMpqIrBbhEI5+Icx7M5E60PICYmYLmaR2aruv4s4e/g8zEBDIT CSiTk1MLaU2TVwoQkTDyCq3YCQBD07D8gl/FiYMH0NLROT1vZuC3b7sN0cZGRBobIUciMHXvZznt NWccpRFRNeTMoWUvlrXvEZBOp5FIJKCrKi5YuwamYUBXFZiGgVOH3oVlWbjy4o+hvb0dzc3NSKVS GHz9NU9vbs+fcddaIqqGnBGafQIgk8lgYmICiUQCk5OTSCQS0DJptLe2nvle04RlWZAkCaZpQtM0 yLJc1pUCLK18Iq4dYiZ3ouUBxMwUtJxCs4tpcnISIyMjOH36tHOtpppKYfniRc73StMLcSVZnlqT ZppIp9NQVbXiUDwMJSI/8ubQNE3DHz4wiFQ8jnRiHGoqBV1VAcvCBeeei1+/+iocOn4cpxMTMDQN 8Q8/xM/2vgnT0CFJMkzTKCsADzeJqFryDjkNw4BpGLhkSx+GXn8tZ9HsZ2+7DQ3NzYg2NgKSBEPT sPqyXowcPeIcgpZzpQBvkkJE1ZRXaFP3CrDQs2olNF2HomlQNA3vv/UmLNPETZs3obOzE7Is43v/ +jyvFKgyEec8mMmdaHkAMTMFLafQztwrQEJbc7PzmPN1WYZpmlBVdepkgJF7eFnOjh1ERNWWV2iR SARyJIKzFnTmfbMky1AUxVmjpqbTOV8v51Z4QO46tJk3TCEiKpdTaA0NDc5/o42N6Fp2Nm7c1Iv3 T49gdGLqBMDpI4fx41d2wdB1mLpelREab5JCRNWSM0KTZRkNDQ2Qo1Fs+/o3oSsKdFWFrihQ0yl0 X3k1jh/YPzVfpmuwLAvvHdjvPL/cERrlE3HtEDO5Ey0PIGamoBW8lvOB3/89jI6OIplMIpVKIR6P 468efQwXrF0DQ9Ng6BpMw4ChaTmjNK8jNC9bbHO0RkTlKlhouq5D0zTn0qdMJgOjwDWaMwvM6wiN 82VEFISCVwpkMhnE43HnSoHx8akFttnsdWd+Za85y/6ciMgvb1cKTM+lZZNkGdKMrYIqOSnAYpsi 4pwHM7kTLQ8gZqagRQE4O2xkbxV0ad+VeOu13c6CWdMwsO/td5wnVjpCm4nFRkSVigJTozLLsqCq KuLxOHRFwfqVK6BoGlRdR2a65LJHaYVGaJUUHIuMiCoVBYB0Og1d12EYBkZHR6FkzZdZlgVZkqDP KCtnhFbhKI1FRkTVIgNAIpHAiRMn8N577+HIkSPITCTyvtGeH8veNmj6C77euKenJ+cqAZrS1dtV 6wh5mMmdaHkAMTMFLWqaJr7y99+GkkxCy6ShTE7mjNBc+RihZa9D412fiKhaogCwZetW7Nq1a2oL bsMALAv7j03tmiFJEkx7F44sldwMhWVFREGIAsDa5cuB3t6pEwO6Dt0woOnu12naO3MQEYlAznvA Y0E5c2hUVSKuHWImd6LlAcTMFDS5bcHCqr0Y90MjolqSC12j6RV31yAikciFlmh4xREZEYnE00TY l66/Dldc0IP2trag88x5Iq4dYiZ3ouUBxMwUtILbB800v7UV/Z+5Ee2trTj04XG8vn8/Xt9/AG/s 349EMun7zbu7u3M+Hx4e9v1aRESeCu3+7z8JU9excuFCXHR+F/o+/jHcetWVME0TW75wt+83Hxwc zPm8v78fAIuNiPzxVGjrVizH2mXLsG75OVi/aiWWLlgAADB8Lq6NxWIAzhSYzS64/v5+lhoRlc1T oW2/6w4AwOnxcew7fARPvhTDvncP4cDhw2W/YSwWw7Zt2wqeIbULbnBwcM6Wmohrh5jJnWh5ADEz Bc3TSYGfvvkWRhIJtLe1oXPePLS1tKCxoQERH4tri5UZEVGlPI3Q/voHT8PUdSyZNw8Xda3G9Zs3 4XPXXQvdMHDlF3/X85vZh5pu+vv75/QojYj88VRo5y9bhu4Vy9Fz7ipccN55aG9rBTB12zsiIlF4 KrS/vPsuAIBuGDh47H3s/fnb2HPwIN48+Hag4eYiEe+lyEzuRMsDiJkpaJ4K7dHYDrz17iHsO3QY mUwGuqpM3WeggsumiIiqzVOhPb7jZ1P3FNC0it6sr68PAwMDkCSp5ImBwcFB9PX1cf6MiMriqdAk ScLNV1yOT2/sxZLODpwaG8PTO36Kx//1eRjuTy/6moVKTZIkDAwM+HxVIprLPBXajRt7ccenrnE+ P3vRInzp12+BZZr45x/9uKw3tEdpQOGL2wcGBtDX11fWa4aJiHMezOROtDyAmJmC5qnQPt17KX4x vB8PPv1DfDQyikVtrfjSLTfj5r4tZRcaAKewZo7E5nKREVHlPBXa4o4O3P9/n8DJsTgsy8KJ0VH8 8/PP43//0X+t6M1ZYERUTZ4Wkp0eH8dnt3wCZy9cCFmWsWzxIvz2tZ/CqbF40PmIiDzzNEL70a7d uONT12Bj9/qcxwe//2QgoeYyEdcOMZM70fIAYmYKmqdCe/YXr8AwDHx642VY0tGBk2NxPB2L4YkX Xgw6HxGRZ54KzQLwzM9fxg9iO2AahrOwlheZE5FIihbaX959F9pbW11f4BN3fqGqgYiI/CpaaOOT kzBME5YFLJw/DxOpFFRNB2ChubERTY2NiE9MzGLUuUHEOQ9mcidaHkDMTEErWmjf/D+PQdE0qLqO R//7ffjqw9/FwaNHYRoGIpaJb9z9Rbz06quzmZWIqCRPyzZSioKrL7kYHW1tkCQJbS0tUDUV/Z+9 Neh8RESeeTop8NM338KNmzfhxs2bch4/evxExQF6enryHhsaGqr4dYlo7vE0QvvH557H47Gf4uRY HKZpYjKdxr+/sRd/8kBlF5H39PRgaGgo71ehkpsrRLyXIjO5Ey0PIGamoHkaoWmGgUdeeBH/9KMf 5yzb4H5oRCQS7qFNRKHhaYR23WWX4va+X8P8AuvSKlmHVuzwknNoROSHp0L73Nar0NzYiHgyCcMw MHWBQHWuEmB55RJx7RAzuRMtDyBmpqB5KrSUouC5V3fjoR8+W9U5NPukgNfHiYhK8VRo337uedze twWPtbUhnkhU/KbZh5lz+YwmEVWXp0K789pPoqO1FQ//8b1IZTI5h5y3fPmPyn5Te/TFkRgRVZOn s5yL5s9HNBJBS1MTFnV0YHFnBxZ3dmJxZ2dFb84yyyfi2iFmcidaHkDMTEHzNEK75et/PnUbO1Wt +hxaMSw7IiqXp0ILCk8IEFE1FS20my/fhM093dj2twP4hy//AWBZ09NmVsVzaKXYa9NYakRUrqKF 1tLUhAXz5gGYmkOj2SHi2iFmcidaHkDMTEErWmiPvrQDj7z4EoDZn0Pj6IyI/Cg5h/bAPf3Ye/gI dh04iN3D+3FyZKSqb87iIqJqKlloT/xsJy5cfR5+9/rrcM9NN+DdDz7ErqFhvPzmXgwdOgxzlkIS EXlRstD+7fVf4l92vQrLstCzcgUuWXM+rtpwCW6/5mpMTKbwyr638PUHH6pamOxD0Lk6ehPxXorM 5E60PICYmYLmadmGomnY/94xmLqOjKLg6g2XYMH8+dja21txobHEiKhaShbapevWYu3yc7B+5Qqc u3QpJEkCAKiahj0H38aeAwd8v7FdZNmXQRERVaJkof3+Z250Pt576DDeePsdvPHOO9j3zjtQFMX3 WU6uMyOiIJS8lvOF1/fg+OgoAGD12Wfh3LPPwvIlS7CgwnVp9uJZjsryiTjnwUzuRMsDiJkpaCVH aN978SdQdR3zW1pw4bmrcHHXatx1/afxh79xK4599BF2Dw3jW997xNcb81CTiKrN00mBU+Pj+Mkv 9+DwBx/i6ImPcMPlm7DyrLOw8qyzfBeaLfvQkycIiKgSJQttaWcn1q9cgQvOXYULV5+HtuZm52tH jh/H7n3VLR2WGBFVomSh3f/FO52Px5JJvPL6L/H6gYN4dd8+nBod5W3sAiDi2iFmcidaHkDMTEEr WWh7Dx/G3kNHsPvg2zj84YfQFMW5lpOISDQlC+2vnngKqq4jo6qwrOrc5YmIKCi80TARhQYLTTAi znkwkzvR8gBiZgoaC42IQqOm9xTo7u7O+Xx4eLhGSYgoDDwV2nWXXYrb+34N81tb8772iTu/4PvN BwcHcz7v7+8HwGIjIn88Fdrntl6F5sZGxJNJGIaRc5MUP2KxGIAzBWazC66/v3/OlpqIa4eYyZ1o eQAxMwXNU6GlFAXPvbobD/3w2YrvKRCLxbBt27aCy0DsghscHJzTpUZE/ng6KfDt557HpevWob2t reI3LFZmRESV8jRCu/PaT6KjtRUP//G9SGUyvu/LaR9quunv7+cojYjK5qnQ7PtyRiMRtDQ1BRpo rhNxzoOZ3ImWBxAzU9A8FVpQ9+UkIqomLqwlotAoOkK7+fJN2NzTjW1/O4B/+PIfAJY1PW1m+Z5D 6+vrw8DAACRJKnliYHBwEH19fZw/I6KyFB2htTQ1YcG8eQCm5tAWtbdjUUc7FnV0YHFnBxZ3dmJx Z6fvN7bvIOX18bmiq7er1hHyMJM70fIAYmYKWtER2qMv7cA/Pf8CgOrOodmjNKBweQ0MDKCvr6/s 1yUi8n0tZ29PD37zmqvxn7ffX/Zz7cKyi23m40REfngqtA1r1+D3brrBOQS1aRWe5WSBEZGbcnrC U6Hd8clr0NLYiOMjI1jU3o5jJ09ixdKl+PbTP/SbkYoQce0QM7kTLQ8gZibbzJ123FiWBdM0Xb/P U6Gds2ghvvrwd5BOZ9D/mRvxpe1/gesv34yPrVlTVigiIsDfyT/DMFy/x1OhpVUVGVXFeDKJlUuX 4uyFCzGvpQVbNlxSdigioqGhIc+XQgJT14B74anQ3j1+HBd2rcbjL76E0YkJPPL1rwEA3j95suhz uru7A12CwQvcieqb17mxcorPU6H9zVPPIIKpEvmf3/0e7rjuWsiShId+8FTJ55Xbwl55bet6JOIe VszkTrQ8gJiZguap0E4nEjA0DQDwzvsf4L89MOB5HVq1z2QGUZBEFA4lC+2bn/8dWLBgWWd+wQIs y3Qug/pPf/Y/ZiUoEZGbkoW2aumS2cpBRHNQT09P0a8NDQ2V/XolC+3l4f34WNdqqJqGXwzvx869 b2LPwbeRTk1y+6CAiDjnwUzuRMsDiJlppqGhoYKl5qfMAJdCe/D//QimZeH8ZcvQu24N/sut/xGt zU14Zd8Q/n3PHvx8zxuYSCZ9vbEt+zdj/+b8/maIqP7MLLVKfv5d90PTDQNvHDqEB5/9F9y1/X48 /pMYLr/wV/Gnd96BrRt7fb8xAKe8sn8DxRqbiMLL7oBKBzOuZznnt7Rgc/d6bFi7BpesXYOWxkYA wHsnPsKxEx9V9OZERLZqHJmVLLQ/uf03sXb5OZAkCaZp4q3DR/CLfUPYuWcPjp04wTm0AIi4doiZ 3ImWBxAzU9BKFtq6FcsBTK1De+3AQSQmJ9E5bx6u27xpahmHaWLw8e/7fvOZh5f2x5xDIyJb1Xfb WNzejk9ddmnBr1VSaEDtyotzdUS1U5PdNj5//7eg6joyqirkXZ/s/yl+rxm1LIt7shHNsu3bt/t+ bnt7e8mv+96xthJeRkZuI7fsG6j4HeUNDw8jFosJdR+DHTt21DpCHmZyJ1oeQMxMg4ODFT3f7dLH mhSaSHNkkiTx8JMoJGpSaCISqWTJHRdg15dYLDYru+TkFdqPH3sUaioFJZWCrmRg6jpMw8i6OP3M fwEAkgQ5EsH6vqs8v6n9l7Ha13ER+cWCDIe8QrNME9d97vPYFYtNTfyb5nSpTRebaeb99/SRw2W9 abVWBRNVg/0PK0ut/hUstFVLl0L7D5+AomlFz3IamgbLNPH+m3s9nU4lEtHMowSWWn3Lv5bT4xk/ Sc56apnbYXMCnkRQ7O8h/37WL9eTApZlQZYkFLrfSrX29ee/ilQL/DsXPvkjtAIlZWY9ZvHwkogE lT9Cmz7kNO2zmTO/nHWoKdKCVJq7eLacbEUPOWVJgjT9i0hUbtMVnM6YW/ILbcaorNQ8WSVzaIXO LmXjX0IiKlfRQ84zn+Z+nj2H5nytzFEcy4qIgpBXaJIkYX5LS9EnZM+h2SM0WXbdyZsoELzihLLl F5os46wFnc6ZzWKHlZZpOiM0OcpLQql2WFpky2uiSDSKNecswyc3fBzvnTyFeDLpXDGg6Tp0w4Sq 69ANA5quw9B1JE7W770FLMvK2YqI6gNLjArJKzQ5GsVtX/giDE1zLkx3rt00TWB650hr+mPLshBp aJy1wNyQkaj+zNbPbV6hbb35lunRmFHyWk57x1pDP3PR+kzlbrPrVbVHVUHlJKIzZuNoKLDJL65f I6IglNpXLQoArU1Th4ymZcEwTZjm1H91w4A+fchp/zI0NW/7IEzfAcoyTSw4Zzk23vZbiDQ0zM7v jojmHEPTsOfg23mPRwFgcUcHgDNXB8iyhIgsIxqJwLQs6JEILNNEY0sLUGJJBxFRLUUB4NylS3D1 xy/GqXgcE+nM9NlMwzmbqfKGwkQkqD1ZH0sAqrMHEBFRjf1/WwoQUouhLCMAAAAASUVORK5CYIJQ SwMEFAAIAAgAllDBNAAAAAAAAAAAAAAAAAsAAABjb250ZW50LnhtbMVXbVPjNhD+3l+xdaedduYc JwSGIyW5gQtc6YSXKTDTflQkxdYgS64kJ+R+fVfySxIg4a50rh+wo9WzL9p9di2OPzzmEubcWKHV MOp1uhFwRTUTKh1G93fn8fvow+i74+/H1x/v/ro5Az2bCcoHTNMy58rFVCuHb7i5P51cfIQoTpLr gqvrAOtokybJ+G4M1XpcawH6SZKzqwiiyl6HORaNjrcZxxiVHVS7wyhzrhgkiUY3euVmr9vtJtU6 qhWsW8rd+IBo4I4/up1oD2jBZPqK7YBo4MyQxU60B2DOG/xMt+jFYtFZ9AOyd3R0lPx5O0nOtclJ G8ujFOphKz7sNlBV5lNudkdCHNnIi52nLxmvEjhvQ6YZMbvzFxCrjPTZKxnpswaMh822HPB9comb 4XE5WaXP5DuNe0B7PmpEsTvyChI17KeSWDuMKj7Uso0eaqlcKSbteoaMjhmn0o6OQ5JXEqjWiuTI qxMjiIR7JbAVOVzeRjDTFXRGciGXw+gnUmj761NcJY1gzXYhHMXkzQlCPSOT3Z5/+wSXQtFMw0Sk mYPft7l+Bny77yuRT0sLf+icKLjSRzDZ5vw58gXvlUqccsWNoMPIePRr8SUvVKoWkdKhBSdoHEy0 JQzPjYPc9Vo3ddiBK41CYZBkxglu2+MtuE/iMJpqyUIYa6a3+5mZZ45SQ4pMUNvIC2L8KA2LuNL6 1EBeiKcSZNqIzxgWkTFmdRhRNMFN9HzXcDmM0AUJbhtALozROGWUVjxUkEpRYP45dT93aQ5rf79E 4EffQJa5UET5+d79sZb58W9wFq2JDGdrq9RwrtbWU1mu66ckzwk2ZGtOahML1XbqjEjL6010pGzI FcUkxr3uWhReLcf+GkbWEcWIeaFCyVaO1BtTzZajY0+DgeV/l+iHN/R6LoQgYsIWkixjXTqc4TyW fO7TjZ/osF0V80LK0mL0Do/kw3qTsbumC95mxXP9rUbG9QfRZ3p71opKZZ3dt02NRheQkTkH5s0j wRngrCBFIQUN2UJiGi/KEJ9xyTwQK/UOXMahDj4ZCSWcn7EYDNMLfEkJUusHkOKBI1RYGNQRFl8Q VPINMaPjQGCRk5RXXF6HhdkRpBtToVdXgfjRbmK3LPhmh8/TwUIw/z0+7Bzs9WleybJ6gB129g96 XhhMf8Z+Y/wxFDdcRAaZ4bNh9MONoK403CbYad3uXje8ur3+Yf3eH5/19w5Pev1OEW5FQbcKxoq8 CLeTILOZxpsVx2sNa0QETROHSK0mmrAVhf6rAo1OSxdYUjEGkAPINGQr+BFHVFpKYqCmOYgZCMBf lAedmkjEgnBeM19CffkDHD9kjWFU5wWmyHL2DqxGIwwHIiwIPpxud58a6MCFd0iR2U5It+FTsVVU kGFP7PAe+M0VniTlrAP/A8f/FX/3voa/NVU3+VuTepO/vS/k737D45PTg97J4XnvW/O3GbuFr/9T FN5LRhfWU8JwZMMSybT0XApEeTIdVzz1ISpkMCeWA07KAnIOOLw7zWRGX1/ZYsnGVzHZ8o/f6B9Q SwcIVrL7yYQEAACfDgAAUEsDBBQACAAIAJZQwTQAAAAAAAAAAAAAAAAKAAAAc3R5bGVzLnhtbO1Y S2/jNhC+91eoLNqbLNmJmziNsmg3+2iRx6JJgPZIS5TFViIFkrKT/fUdkqJk2ZSTwkBPzSGION88 9XFmlMt3z1UZrImQlLMETScxCghLeUbZKkFPjx/Dc/Tu6pvLb6/v3z/++eVDwPOcpuQi42lTEaZC qV5KIoMvT7/c/Po+QGEU3deE3RvUhItVFF0/Xgf2+bpVCsBNFH24QwGy5iaZytDV5YhtiJDJCytM UKFUfRFFHLzw3sssjuPIPqNWwWgfxBuEgyvyrA6iNaAD4+Urtg3CwTOBNwfRGgAVd/icd+jNZjPZ nBjkdLFYRH883EQfuahwF8tzSdnfo3gjdVDWVEsiDkeCFR7URa5XPuO2gOsu5LTA4nD9DKKvyEn2 SkVOMgeGZIuRBM+jWxCaX7c3fflEddC4BnT5pYLWhyO3EOS4P7gtHWtzDozNSFrKq0tTwP4ksM8M V8CZnwXFZfDEKFwyEtw+oCDnFprjipYvCfoB11z+tIuzpyjYsl1TlUJh1higmm3RYc+fPwW3lKUF D27oqlDBb2Ou94DH+76j1bKRwe+8wiy444vgZsz5PtLj3aqEK8KIoGmChEa/Fl/keVPtke00LoWM 5Lgp2/7jjLZBrgSuC5pK5MC1AMoIRaFR6VsMpoDmIdw6Esoap3Crw4IL+hWc4jJB8WR2fpIC+8bA a20s3YcSlr3V6h7UYxOKn/KSQzP4LjY/g+q9/tIk/QqI6UzfCzgrMVs1eAVHhLXGG6YEFOzpYc9y iCXFzEvILaT24JDWjxU6V07GOCNO1nr1iXrvKa/qkjz7ruKu+w7qDaCT+kLwCvUMCXGjuH4zUCya EW4YFeKyLrCD1Q1LVYMVdJlwA+IESaqtdRHol7sUBEPflwpugOroCHMHeMtrqQm/y9DuaMDwt9C+ xgKbQH28/59L/y2XoCTFS10QhhUUKcelHB5q2ghSYcpCPXRDYyZBsz1Q3cjiFUiJs4x0csahsVRU Hc3nAvI2C88ooYMhn8OMQrNk2slsMovnuodZxEZQpZtcBYVPUClCtUTRYaZvM9zS8wFsZ1hkaJT3 7pWUWMoEmWUwGrf3yY2JfzE+tM0LrDkMObzUZOh9vboAAsQmb/j7xf3d1kAXdZs6ruWHMDshXF7v CQQpPfn1U8VqprCIE+GR7qj3FW8rbbLhjbKDyHNWkjUp22ZjBOYArodzBttqmJtVN0Ha/pu0Z0dp nxylfXqU9vwo7R+P0j47Svv8KO3FUdrTeEw9GmVgzrliXBEJbY3ldNUI05o8doCLRsPuaWtcNnAr 4/awNwM3hSrzSVBDLx/o2E8u3Z+0Pfdp26UHq9rbIqH+SJwdnWPvamjMAKzQrIWymxm2QnkuidKr 4eli0bcUXxlaI326JclVK4PhCzOH6Ckx39623WrdPuphATZpGg53bl24sIJPTyIGjbSupiMrh9HY 0Ex/G86mk/miXWvNeUH0FgCCs8nidDQpZ5bCjIbOBsHj9jVyoQSmdh+psIBZFUIP1bNnftr6aY+X XEFGPokuDrSUyfRsPhQIG1sncZuCpRNU4bmLX/f4/suqBUhSu75v048n8fS8t+RGZbgkkKzBa8w0 nnowOIeSeyE4+6uRyr5S+6LtOXT+ru7z7/tdZbAB+tfPdooQrHcK8xBtZ7d1GO3RoqfUPodagQXu MKs91JYOjvwtV2HPvS0m71iP/P+uuvoHUEsHCFT8PRwABQAAUxMAAFBLAwQUAAAAAACWUME0gbtD aWIEAABiBAAACAAAAG1ldGEueG1sPD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgi Pz4KPCFET0NUWVBFIG9mZmljZTpkb2N1bWVudC1tZXRhIFBVQkxJQyAiLS8vT3Blbk9mZmljZS5v cmcvL0RURCBPZmZpY2VEb2N1bWVudCAxLjAvL0VOIiAib2ZmaWNlLmR0ZCI+PG9mZmljZTpkb2N1 bWVudC1tZXRhIHhtbG5zOm9mZmljZT0iaHR0cDovL29wZW5vZmZpY2Uub3JnLzIwMDAvb2ZmaWNl IiB4bWxuczp4bGluaz0iaHR0cDovL3d3dy53My5vcmcvMTk5OS94bGluayIgeG1sbnM6ZGM9Imh0 dHA6Ly9wdXJsLm9yZy9kYy9lbGVtZW50cy8xLjEvIiB4bWxuczptZXRhPSJodHRwOi8vb3Blbm9m ZmljZS5vcmcvMjAwMC9tZXRhIiBvZmZpY2U6dmVyc2lvbj0iMS4wIj48b2ZmaWNlOm1ldGE+PG1l dGE6Z2VuZXJhdG9yPk9wZW5PZmZpY2Uub3JnIDEuMC4yIChMaW51eCk8L21ldGE6Z2VuZXJhdG9y PjwhLS1TUkM2NDFfWzc2NjNdX0xJTlVYX0lOVEVMX19zeWx2ZXN0ZXIuZGV2ZWwucmVkaGF0LmNv bV9hdF8yLzIwLzAzXzEyOjMzOjQ1LS0+PG1ldGE6Y3JlYXRpb24tZGF0ZT4yMDA2LTA2LTAxVDEw OjQ1OjU1PC9tZXRhOmNyZWF0aW9uLWRhdGU+PGRjOmRhdGU+MjAwNi0wNi0wMVQxMTowNDo0NDwv ZGM6ZGF0ZT48ZGM6bGFuZ3VhZ2U+ZW4tVVM8L2RjOmxhbmd1YWdlPjxtZXRhOmVkaXRpbmctY3lj bGVzPjI8L21ldGE6ZWRpdGluZy1jeWNsZXM+PG1ldGE6ZWRpdGluZy1kdXJhdGlvbj5QVDE4TTQ5 UzwvbWV0YTplZGl0aW5nLWR1cmF0aW9uPjxtZXRhOnVzZXItZGVmaW5lZCBtZXRhOm5hbWU9Iklu Zm8gMSIvPjxtZXRhOnVzZXItZGVmaW5lZCBtZXRhOm5hbWU9IkluZm8gMiIvPjxtZXRhOnVzZXIt ZGVmaW5lZCBtZXRhOm5hbWU9IkluZm8gMyIvPjxtZXRhOnVzZXItZGVmaW5lZCBtZXRhOm5hbWU9 IkluZm8gNCIvPjxtZXRhOmRvY3VtZW50LXN0YXRpc3RpYyBtZXRhOnRhYmxlLWNvdW50PSIwIiBt ZXRhOmltYWdlLWNvdW50PSIyIiBtZXRhOm9iamVjdC1jb3VudD0iMCIgbWV0YTpwYWdlLWNvdW50 PSIxIiBtZXRhOnBhcmFncmFwaC1jb3VudD0iMTIiIG1ldGE6d29yZC1jb3VudD0iNzkiIG1ldGE6 Y2hhcmFjdGVyLWNvdW50PSI0MTUiLz48L29mZmljZTptZXRhPjwvb2ZmaWNlOmRvY3VtZW50LW1l dGE+UEsDBBQACAAIAJZQwTQAAAAAAAAAAAAAAAAMAAAAc2V0dGluZ3MueG1s7Vjdd6I4FH/fv8Ll dY8F7Uxbe1rngAq1H9YKYutbJLdKJyRsCKLz129AbacVZrsqe/ZhOceDITe/e3NzP3PxbRGQyhx4 5DN6qdSONKUC1GPYp9NLZeiY1TPlW/O3i9/b9y3nqd+psOdn34NzzLw4ACqqEQghaaNKf2jcdlsV paqq9yHQ+4zuiPGpqraddmU1bq+XVSQjVe30lIqyAjzCAivNi0J0KSWNzlfTl8pMiPBcVZnkw974 1DVNU1djZb1gQXz6/ZU+SZKj5DijrTUaDTWb3ZB6jD77019g19QVibLRwTutvcq+Ebl5sSJfA1d9 AUG6n8r6M0WB3Mnch+R1l0remvf0rqTXOSCHhcpmRixDOeNToTTrF+o2wudRb+FZ5MFq+8GOfCxm ueIe1xun+2FfgT+d5QpdO67VjncDt2csGQCW5gGtGaJTiD4wmDBGAFGlKXgMu/O4AoSBj2Y+AYOz JJJGUMToGZFoD04mY6J8Tl2agcMdw3AQ+GqAwqpPMSwAb59/vsNka2Tw4MvPWVEXfxA1EjxVTzP1 zT0cqsiZvtRO97D5Isf/enK6s5dG/oTAwX0/Qz10nMpAB0Uun8aTk72gDSYECw4cTsaMBY5E+mhn M8Z3V3AKaiJPMJ4PW9N2BO5GNhDwBGCTyw87+HHOx5+dsmh67ef5BDJHfi6jrgYxR0Lm5n+SWnWM +4gjB0kzsEPklRMi+zK2iAGktQN8DDyHwL+VJc0wxEjkBeGNaewGLVMhlwYHvMWCkEOUFj8HN+tM P7bUPYFrNinMu/ueQB+FwE3OAhtE/DFEHYxLGlP7qJTyIcPPbLUE8PSkhR4LtrKkkqRvMRkPGClL OcBzzxZFcPLF8CniS6UZT2//UDVMJoG7RKO76fDqOpzQAfGm+n/yGWrYdIhhu39POtL1O/nqZgNV PTN1yxjqevtsIsd20PAHlqk92fqiRQ2596/a+LHbGNTdePx4HT4tjQcvIDG23GUraMh5V/43NTRq xH3XmHt0sHwaEa0V9OaeRYj3Q5M4vZen0YL0nc7NZGQux3USjy3zT/zY0ybp+rYm7uzk7fcQvkzq i7kXSH1fDVjf6WpSlh8Ty62PR0njTn+bxwF5GTta0iLGw6DTm6dnBJ3BDFudm6Fl0rHbCyEYnjiW q6Uyl3oI/z//5nO5RwjQKWUiKwSKk+GOeUoPQ7IcRsDbSKDDRzDTB4LLjMA2moO7usC4py3CosM0 bNtMLMImiGwuftLypIyk3o1ugFM98hHtx9QTcXbqJTDSiT+lMu/agoV9FvklsWnFnEt1pcaVZqz0 bbOYe1tGvOpV1U/nxN52Sb/pdy2gwH2vsqbcw+9MtCjm81lZsy6vpOopp9bXhS1k1VNawclZFMqu qix8i6Nw5ntlFIPvTVEW/wGiOKfw3+e6YF2UT8FA3vcpZzEtbI4OvZP9rLTNUZI1mOUUsQaR+jBl obxL0Czso9Wtu2q16Oa9+RdQSwcIYIjI8FgEAAAiGAAAUEsDBBQACAAIAJZQwTQAAAAAAAAAAAAA AAAVAAAATUVUQS1JTkYvbWFuaWZlc3QueG1svZNRa8IwEMff9ymyvDfXqMMhVlGrMNimD/qwx9Be a6BNQ3M6/faLY1VBYThkeblcuPv9/+G4/nBXFmyLtdOVibgUIWdokirVJo/4ajkLnvlw8NB/jOeT 5cdiykpldIaOes2FLVbj15cJ4wHA3KKZZ5lOUFR1DhAvY/bW1Hk2wPSdM948iZRS7uGXTG/KuGMa 8TWR7QFUnl+d+K0wlNAUeRA7kTJdYICG6v2ZY0y1CmhvMeLK2kInivyvYWtS4TZGeFHxWWvCmp+a sk1RBFbROuLA4SYNXaocwZr8Om6hE9rU6ECG/rTC7xDKdvcnduJpu9UdybY4IP5FutNYGI2f5Kg7 k3+Q/kXxRhrhjsAP5jo1qQz55sPk7sp1tC/Q3R1bIqn7e0Uiv6xHt324WKfBF1BLBwhaFbNOMAEA AOYDAABQSwECFAAUAAAAAACWUME0gJBrfpsbAACbGwAALQAAAAAAAAAAAAAAAAAAAAAAUGljdHVy ZXMvMTAwMDAyMDEwMDAwMDEzNzAwMDAwMTM0REUzMjdBMTMucG5nUEsBAhQAFAAAAAAAllDBNLas V216HwAAeh8AAC0AAAAAAAAAAAAAAAAA5hsAAFBpY3R1cmVzLzEwMDAwMjAxMDAwMDAxMzQwMDAw MDEzN0FCNTFBN0YxLnBuZ1BLAQIUABQACAAIAJZQwTRWsvvJhAQAAJ8OAAALAAAAAAAAAAAAAAAA AKs7AABjb250ZW50LnhtbFBLAQIUABQACAAIAJZQwTRU/D0cAAUAAFMTAAAKAAAAAAAAAAAAAAAA AGhAAABzdHlsZXMueG1sUEsBAhQAFAAAAAAAllDBNIG7Q2liBAAAYgQAAAgAAAAAAAAAAAAAAAAA oEUAAG1ldGEueG1sUEsBAhQAFAAIAAgAllDBNGCIyPBYBAAAIhgAAAwAAAAAAAAAAAAAAAAAKEoA AHNldHRpbmdzLnhtbFBLAQIUABQACAAIAJZQwTRaFbNOMAEAAOYDAAAVAAAAAAAAAAAAAAAAALpO AABNRVRBLUlORi9tYW5pZmVzdC54bWxQSwUGAAAAAAcABwDaAQAALVAAAAAA --=-k0bJJnk7Qaq1V0+G97NB-- --0-596188450-1149245335=:1049-- From kris@babi-pangang.org Fri Jun 2 07:03:22 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 7783B3B03DE for ; Fri, 2 Jun 2006 07:03:22 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20299-05 for ; Fri, 2 Jun 2006 07:03:21 -0400 (EDT) Received: from nasi-goreng.babi-pangang.org (nasi-goreng.babi-pangang.org [83.166.137.20]) by menubar.gnome.org (Postfix) with ESMTP id 0CC793B0196 for ; Fri, 2 Jun 2006 07:03:20 -0400 (EDT) Received: by nasi-goreng.babi-pangang.org (Postfix, from userid 1000) id 417E73DCA0; Fri, 2 Jun 2006 13:03:18 +0200 (CEST) Date: Fri, 2 Jun 2006 13:03:17 +0200 From: Kristian Rietveld To: Tim Janik Message-ID: <20060602110317.GA10757@babi-pangang.org> References: <20060314132538.GA3526@babi-pangang.org> <443B4A8A.8000302@imendio.com> <20060425103017.GA15762@babi-pangang.org> <20060531183045.GA7564@babi-pangang.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.563 tagged_above=-999 required=2 tests=[AWL=0.036, BAYES_00=-2.599] X-Spam-Score: -2.563 X-Spam-Level: Cc: Gtk+ Developers , Soeren Sandmann Subject: Re: Callback based tooltips (Re: New tooltips API, continued) X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 11:03:22 -0000 On Thu, Jun 01, 2006 at 05:16:51PM +0200, Tim Janik wrote: > On Wed, 31 May 2006, Kristian Rietveld wrote: > > >On Tue, Apr 25, 2006 at 03:08:12PM +0200, Soeren Sandmann wrote: > >>I once wrote down how tooltips should behave: > > > >I mostly like the behaviour you described below. > > > >> - Tooltips are too intrusive. The text should be smaller, and > > not sure if this has been raised already... > the font size of the tooltips should be exactly as large as the default > font size (module tooltip markup of course) to avoid reducing usability > of the tooltips in contrast to normal text (labels). The text for default/simple tooltips using toolip-markup are drawn using the default GTK+ font at this point. FireFox does this too, it seems. -kris. From lists@nabble.com Fri Jun 2 07:11:06 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 15ADC3B10CE for ; Fri, 2 Jun 2006 07:11:06 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20935-09 for ; Fri, 2 Jun 2006 07:11:04 -0400 (EDT) Received: from talk.nabble.com (www.nabble.com [72.21.53.35]) by menubar.gnome.org (Postfix) with ESMTP id 7B8A53B0E85 for ; Fri, 2 Jun 2006 07:11:04 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=talk.nabble.com) by talk.nabble.com with esmtp (Exim 4.50) id 1Fm7YV-00067i-S9 for gtk-devel-list@gnome.org; Fri, 02 Jun 2006 04:11:03 -0700 Message-ID: <4677819.post@talk.nabble.com> Date: Fri, 2 Jun 2006 04:11:03 -0700 (PDT) From: heavenscape To: gtk-devel-list@gnome.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-Sender: masonduan1@sina.com X-Nabble-From: heavenscape X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.564 tagged_above=-999 required=2 tests=[AWL=0.037, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.564 X-Spam-Level: Subject: strange trouble in displaying a 8bit monochromy grey scale image X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 11:11:06 -0000 I need to display a 8 bit monochromy image with size of 2048x2048 pixels, all the image data are already loaded into memory, and out of which I created a 24 bit RGB buffer for the GdkPixbuf (please see code below) Well, the result is: The GtkImage widget was expanded to size of 2048x2048 pixels, THREE exactly same images tile in a row in the top of the GtkImage widget, each with size shrinked to 684x684 pixels, and all the lower 2/3 space is left blank.(see the attached image below) Can anyone please look at my code and give me some suggestion on this problem? I have been debugging is problem for almost one week time! Or I wonder if there is any other alternative mean to display a grey scale monochromy image. Any help is highly appriciated! following is my code: ...... char* pDisplayBuf = malloc(sizeX*sizeY*3); for(i=0;i X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 129D43B0401 for ; Fri, 2 Jun 2006 07:42:43 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22729-02 for ; Fri, 2 Jun 2006 07:42:41 -0400 (EDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.204]) by menubar.gnome.org (Postfix) with ESMTP id AACEB3B03DC for ; Fri, 2 Jun 2006 07:42:41 -0400 (EDT) Received: by wx-out-0102.google.com with SMTP id i30so488730wxd for ; Fri, 02 Jun 2006 04:42:41 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=gT1j5ejSD/b/CcxQn0QQsSvUHhFufm/g+0pbZR2i/XzGfNpGoCbQpb21JCQ8031mkn0Ki6u8pLPOMj7RR8l3DAglKtDDYSYHma6DaM5dCPwAcVKD9bRfW3lU8+yvbKvGFEapsCpgbG/Y1Pe5Z3GQWmSp7m88CvcAjjuc1aYqX10= Received: by 10.70.62.1 with SMTP id k1mr2290069wxa; Fri, 02 Jun 2006 04:42:41 -0700 (PDT) Received: by 10.70.96.6 with HTTP; Fri, 2 Jun 2006 04:42:40 -0700 (PDT) Message-ID: <522c6460606020442q5704285jefadb260aa5ceda1@mail.gmail.com> Date: Fri, 2 Jun 2006 12:42:40 +0100 From: "John Cupitt" To: heavenscape In-Reply-To: <4677819.post@talk.nabble.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4677819.post@talk.nabble.com> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.554 tagged_above=-999 required=2 tests=[AWL=0.046, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.554 X-Spam-Level: Cc: gtk-devel-list@gnome.org Subject: Re: strange trouble in displaying a 8bit monochromy grey scale image X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 11:42:43 -0000 On 6/2/06, heavenscape wrote: > char* pDisplayBuf = malloc(sizeX*sizeY*3); > for(i=0;i { > //create a gray scale img in the display buffer > pDisplayBuf[i+1]=pDisplayBuf[i+1]=pDisplayBuf[i+2] = pixel_value; > } This isn't going to work. You're only filling the first third of the memory area. How about (untested): // malloc() can return NULL: you need to test the result // g_malloc() cannot fail char *p = g_malloc(sizeX * sizeY * 3); char *q; int i; // i loops for number of pixels // q loops pointing at each RGB triplet in turn for (q = p, i = 0; i < sizeX * sizeY; i++, q += 3) q[0] = q[1] = q[2] = pixel_value; // or alternatively in this special case memset( p, sizeX * sizeY * 3, pixel_value ) From jcupitt@gmail.com Fri Jun 2 07:44:31 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C18CD3B0402 for ; Fri, 2 Jun 2006 07:44:31 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22729-06 for ; Fri, 2 Jun 2006 07:44:30 -0400 (EDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.202]) by menubar.gnome.org (Postfix) with ESMTP id 8F0073B0413 for ; Fri, 2 Jun 2006 07:44:30 -0400 (EDT) Received: by wx-out-0102.google.com with SMTP id i30so489124wxd for ; Fri, 02 Jun 2006 04:44:29 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=EMOfucJIundQbGeCrVxW4fD6Iz3tUALWFaW8hgWFjuzmGzy3HlOTtgzn8QGVrywRA62j6kzikELTcAJL+GvTNGqGag3vtyJIcBhy5nQKUdv8v5Gm6dzT8SPDVoRKsWY874GU5fTfTuEc6cSK5TYAaWH6Ezj7csUQ73y/uo1NF/8= Received: by 10.70.128.5 with SMTP id a5mr2255574wxd; Fri, 02 Jun 2006 04:44:29 -0700 (PDT) Received: by 10.70.96.6 with HTTP; Fri, 2 Jun 2006 04:44:29 -0700 (PDT) Message-ID: <522c6460606020444q6963f934g8d7b671fb87905b0@mail.gmail.com> Date: Fri, 2 Jun 2006 12:44:29 +0100 From: "John Cupitt" To: heavenscape In-Reply-To: <522c6460606020442q5704285jefadb260aa5ceda1@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4677819.post@talk.nabble.com> <522c6460606020442q5704285jefadb260aa5ceda1@mail.gmail.com> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.555 tagged_above=-999 required=2 tests=[AWL=0.045, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.555 X-Spam-Level: Cc: gtk-devel-list@gnome.org Subject: Re: strange trouble in displaying a 8bit monochromy grey scale image X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 11:44:31 -0000 On 6/2/06, John Cupitt wrote: > memset( p, sizeX * sizeY * 3, pixel_value ) Ahem, of course that should be memset (p, pixel_value, sizeX * sizeY * 3); From cerdiogenes@yahoo.com.br Fri Jun 2 09:09:23 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id BD1CF3B03D8 for ; Fri, 2 Jun 2006 09:09:23 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27976-05 for ; Fri, 2 Jun 2006 09:09:21 -0400 (EDT) Received: from cac-bdc03.unioeste.br (pop3.unioeste.br [200.201.8.21]) by menubar.gnome.org (Postfix) with ESMTP id 8FFCD3B0351 for ; Fri, 2 Jun 2006 09:09:20 -0400 (EDT) Received: from [200.201.81.39] (200.201.81.39 [200.201.81.39]) by cac-bdc03.unioeste.br with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id L71GDA45; Fri, 2 Jun 2006 10:07:46 -0300 From: Carlos Eduardo Rodrigues =?ISO-8859-1?Q?Di=F3genes?= To: =?ISO-8859-1?Q?=D8yvind_Kol=E5s?= In-Reply-To: <7bf6f2dc0606010816q15d512aejc30a6c93bc165e6@mail.gmail.com> References: <1149104973.27709.4.camel@localhost.localdomain> <7bf6f2dc0606010816q15d512aejc30a6c93bc165e6@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Date: Fri, 02 Jun 2006 10:01:52 -0300 Message-Id: <1149253312.4847.21.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.221 tagged_above=-999 required=2 tests=[AWL=0.043, BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.221 X-Spam-Level: Cc: gtk-devel-list@gnome.org Subject: Re: Color space transformations in GTK X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 13:09:23 -0000 On Thu, 2006-06-01 at 17:16 +0200, =D8yvind Kol=E5s wrote: > On 5/31/06, Carlos Eduardo Rodrigues Di=F3genes wrote: > > Hi, > > > > There is any plan to add color spaces conversions in GTK+ (GDK or > > Gdk-Pixbuf)? If the answear is no, why not? >=20 > Pixel format conversions is not a small piece of code and the needed > pixel formats varies from scenario to scenario. Most programs will not > need such a large general infrastructure and the ones that really need > it would probably not be satisfied with a simpler solution. I think that I understand your last argument. And what I really have in mind is a simple solution, more below... >=20 > What functionality is it you miss that you think fits into a GUI > toolkit? (color management is a seperate issue to color space(pixel > format) conversions according to my interpretation of your question). I had to make RGB <-> HSL conversions, because it's more intuitive change some color properties in the HSL color space. I thinked that we could have something like GdkColor for other color spaces and functions to convert between GdkColor and the other color spaces. I think that it will help who want to play with colors in a quick way. I don't find this in any other library, and I thinked that GTK+ could be a good place for this, because it will become easiest to work with other colors representations in GTK+ applications. >=20 > /=D8yvind K. --=20 Carlos Eduardo Rodrigues Di=F3genes Projeto xLupa - http://www.unioeste.br/projetos/xlupa From murrayc@murrayc.com Fri Jun 2 09:28:59 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id A768B3B112B for ; Fri, 2 Jun 2006 09:28:59 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28843-09 for ; Fri, 2 Jun 2006 09:28:58 -0400 (EDT) Received: from webmail1.sd.dreamhost.com (webmail1.sd.dreamhost.com [66.33.201.159]) by menubar.gnome.org (Postfix) with ESMTP id 953E83B111A for ; Fri, 2 Jun 2006 09:28:58 -0400 (EDT) Received: from webmail.murrayc.com (localhost [127.0.0.1]) by webmail1.sd.dreamhost.com (Postfix) with ESMTP id 9A66F2CAF2; Fri, 2 Jun 2006 06:23:41 -0700 (PDT) Received: from 194.138.18.132 (proxying for unknown) (SquirrelMail authenticated user murrayc@murrayc.com) by webmail.murrayc.com with HTTP; Fri, 2 Jun 2006 15:23:41 +0200 (CEST) Message-ID: <1464.194.138.18.132.1149254621.squirrel@webmail.murrayc.com> In-Reply-To: <1149253312.4847.21.camel@localhost.localdomain> References: <1149104973.27709.4.camel@localhost.localdomain> <7bf6f2dc0606010816q15d512aejc30a6c93bc165e6@mail.gmail.com> <1149253312.4847.21.camel@localhost.localdomain> Date: Fri, 2 Jun 2006 15:23:41 +0200 (CEST) From: "Murray Cumming" To: Carlos Eduardo Rodrigues =?iso-8859-1?Q?Di=F3genes?= User-Agent: SquirrelMail/1.4.6 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.481 tagged_above=-999 required=2 tests=[AWL=-0.036, BAYES_00=-2.599, TW_GT=0.077, TW_TK=0.077] X-Spam-Score: -2.481 X-Spam-Level: Cc: gtk-devel-list@gnome.org, =?iso-8859-1?Q?=D8yvind_Kol=E5s?= Subject: Re: Color space transformations in GTK X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 13:28:59 -0000 > On Thu, 2006-06-01 at 17:16 +0200, yvind Kols wrote: >> On 5/31/06, Carlos Eduardo Rodrigues Digenes >> wrote: >> > Hi, >> > >> > There is any plan to add color spaces conversions in GTK+ (GDK or >> > Gdk-Pixbuf)? If the answear is no, why not? >> >> Pixel format conversions is not a small piece of code and the needed >> pixel formats varies from scenario to scenario. Most programs will not >> need such a large general infrastructure and the ones that really need >> it would probably not be satisfied with a simpler solution. > > I think that I understand your last argument. And what I really have in > mind is a simple solution, more below... > >> >> What functionality is it you miss that you think fits into a GUI >> toolkit? (color management is a seperate issue to color space(pixel >> format) conversions according to my interpretation of your question). > > I had to make RGB <-> HSL conversions, because it's more intuitive > change some color properties in the HSL color space. I thinked that we > could have something like GdkColor for other color spaces and functions > to convert between GdkColor and the other color spaces. > > I think that it will help who want to play with colors in a quick way. I > don't find this in any other library, and I thinked that GTK+ could be a > good place for this, because it will become easiest to work with other > colors representations in GTK+ applications. In case it's useful, we have some old undocumented RGB <-> HSL color value conversion code in gtkmm here: http://cvs.gnome.org/viewcvs/gtkmm/gdk/src/color.ccg?view=markup (See set_hsl(), for instance) Murray Cumming murrayc@murrayc.com www.murrayc.com www.openismus.com From timj@gtk.org Fri Jun 2 10:28:42 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 270163B043C for ; Fri, 2 Jun 2006 10:28:42 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32586-01 for ; Fri, 2 Jun 2006 10:28:40 -0400 (EDT) Received: from webmail.hansenet.de (mail04.hansenet.de [213.191.73.12]) by menubar.gnome.org (Postfix) with ESMTP id 4C4283B0272 for ; Fri, 2 Jun 2006 10:28:40 -0400 (EDT) Received: from birnet.org (213.39.189.161) by webmail.hansenet.de (7.2.059) id 447C34F100154F1E; Fri, 2 Jun 2006 16:28:37 +0200 Received: from master.birnet.private (localhost [127.0.0.1]) by birnet.org (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k52ESaZY028846 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 2 Jun 2006 16:28:36 +0200 Received: (from timj@localhost) by master.birnet.private (8.13.4/8.13.4/Submit) id k52ESPMh028844; Fri, 2 Jun 2006 16:28:25 +0200 Date: Fri, 2 Jun 2006 16:28:25 +0200 (CEST) From: Tim Janik X-X-Sender: timj@master.birnet.private To: Stefan Kost In-Reply-To: <1148567274.9054.4.camel@fluffy.local> Message-ID: References: <1148567274.9054.4.camel@fluffy.local> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.442 tagged_above=-999 required=2 tests=[AWL=0.157, BAYES_00=-2.599] X-Spam-Score: -2.442 X-Spam-Level: Cc: Gtk+ Developers Subject: Re: Serialization in libgobject X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 14:28:42 -0000 On Thu, 25 May 2006, Stefan Kost wrote: > Hi Tim, > > thanks for the extensive comments and detailed concerns. Don't you think > it would be good to keep the buzzgilla issue open. Its an enhancement > request after all and there seems to be several people wanting to have > it. well, my concern is that most of them want/think different things about serialization which was the main point of my last email. i.e. if you want to cover beast's serialization need, you already need 2 different serializers. if you then also want to cover GStreamer needs, and maybe properly human digestible config files, you can easily end up with 3 or 4 sets of mutually exclusive requirements. so without precise definition of the usage cases: - the exact required behaviour of a GLib serializer isn't clear; - we'll end up with lots of projects still rolling their own serializer because the glib one doesn't cover their needs; - the serializer will be used in scenarios that it's unplanned and suboptimal for. i'm not saying the technical issues i raised are unsolvable, in fact each one has been adressed in one way or the other in beast's serializers. rather, i'm asking: 1) what exactly do we want in glib? (i.e. which use cases should be covered) 2) which use cases should be rejected by the glib implementation(s)? 3) do the answers to (1) and (2) really cover a broad range of serialization applications out there? and i think one of the best way to be sure and positively answer (3) could be the independent development of a serialization lib outside of glib. such a library could be included into glib at a later point, once its mature enough and has an adequate track record of applications. > The bugzilla issue could serve as a tracker item. And now maybe some > more people know about thsi and add their thoughts and ideas. if you still think this should be tracked in glib bugzilla as an enhancement, you can always reopen the report. > @Andrew: is you implementation public? If so where can I find the > sources, if not can you make the serialisation part public? > > Maybe we can find a SoC student for the next summer to look at the > solutions used in our application as come up with a good proposal that > suites most apps. > > Stefan > --- ciaoTJ From timj@gtk.org Fri Jun 2 12:59:30 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id AFEC23B0140 for ; Fri, 2 Jun 2006 12:59:30 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09573-08 for ; Fri, 2 Jun 2006 12:59:29 -0400 (EDT) Received: from webmail.hansenet.de (mail01.hansenet.de [213.191.73.61]) by menubar.gnome.org (Postfix) with ESMTP id 53B8C3B00A5 for ; Fri, 2 Jun 2006 12:59:29 -0400 (EDT) Received: from birnet.org (213.39.189.161) by webmail.hansenet.de (7.2.059) id 447D3FB2000A3052; Fri, 2 Jun 2006 18:59:16 +0200 Received: from master.birnet.private (localhost [127.0.0.1]) by birnet.org (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k52GxEAY001423 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 2 Jun 2006 18:59:14 +0200 Received: (from timj@localhost) by master.birnet.private (8.13.4/8.13.4/Submit) id k52GxETr001415; Fri, 2 Jun 2006 18:59:14 +0200 Date: Fri, 2 Jun 2006 18:59:13 +0200 (CEST) From: Tim Janik X-X-Sender: timj@master.birnet.private To: Owen Taylor Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.445 tagged_above=-999 required=2 tests=[AWL=0.154, BAYES_00=-2.599] X-Spam-Score: -2.445 X-Spam-Level: Cc: Gtk+ Developers Subject: locking around source_funcs->finalize X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 16:59:30 -0000 hi Owen. reading up on g_source_unref() again, i notice that the GMainContext lock is removed and re-acquired around callback_funcs->unref(), but not around source_funcs->finalize(); supposing you're unlocking around unref() so that the handler may do things like adding a new idle handler to the context, shouldnt the same semantics be provided for source_funcs->finalize() as well? > static void > g_source_unref_internal (GSource *source, > GMainContext *context, > gboolean have_lock) > { > gpointer old_cb_data = NULL; > GSourceCallbackFuncs *old_cb_funcs = NULL; > > g_return_if_fail (source != NULL); > > if (!have_lock && context) > LOCK_CONTEXT (context); > > source->ref_count--; > if (source->ref_count == 0) > { > old_cb_data = source->callback_data; > old_cb_funcs = source->callback_funcs; > > source->callback_data = NULL; > source->callback_funcs = NULL; > > if (context && !SOURCE_DESTROYED (source)) > { > g_warning (G_STRLOC ": ref_count == 0, but source is still attached to a context!"); > source->ref_count++; > } > else if (context) > g_source_list_remove (source, context); > > if (source->source_funcs->finalize) > source->source_funcs->finalize (source); lock is being held if have_lock || context. > > g_slist_free (source->poll_fds); > source->poll_fds = NULL; > g_free (source); > } > > if (!have_lock && context) > UNLOCK_CONTEXT (context); > > if (old_cb_funcs) > { > if (have_lock) > UNLOCK_CONTEXT (context); > > old_cb_funcs->unref (old_cb_data); no lock is being held. > > if (have_lock) > LOCK_CONTEXT (context); > } > } --- ciaoTJ From matthias.clasen@gmail.com Fri Jun 2 13:14:22 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 181063B0178 for ; Fri, 2 Jun 2006 13:14:22 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10341-10 for ; Fri, 2 Jun 2006 13:14:21 -0400 (EDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.188]) by menubar.gnome.org (Postfix) with ESMTP id A84F33B0115 for ; Fri, 2 Jun 2006 13:14:20 -0400 (EDT) Received: by nf-out-0910.google.com with SMTP id l37so1131753nfc for ; Fri, 02 Jun 2006 10:14:19 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=IIiw0EjBJce9nDArNbjwYFffpCUCNPuYeqI8uOIN+ycf/KtiNjAY9VtWweGXWApORefDRcNkzdsGRROn1FJvCDC494mL9vZcz0WpDA5tNFO1IZSXHXsfZPz+YqQUJ6orpi6MA7hmCcT7pTYK8vEfd8Pic7cApyoegcqYqJXL1U8= Received: by 10.49.1.9 with SMTP id d9mr941927nfi; Fri, 02 Jun 2006 10:14:19 -0700 (PDT) Received: by 10.48.215.7 with HTTP; Fri, 2 Jun 2006 10:14:19 -0700 (PDT) Message-ID: Date: Fri, 2 Jun 2006 13:14:19 -0400 From: "Matthias Clasen" To: "Tim Janik" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.699 tagged_above=-999 required=2 tests=[AWL=-0.734, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.558, SPF_PASS=-0.001, TW_GT=0.077] X-Spam-Score: -1.699 X-Spam-Level: Cc: Owen Taylor , Gtk+ Developers Subject: Re: locking around source_funcs->finalize X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 17:14:22 -0000 On 6/2/06, Tim Janik wrote: > hi Owen. > > reading up on g_source_unref() again, i notice that the > GMainContext lock is removed and re-acquired around > callback_funcs->unref(), but not around source_funcs->finalize(); > supposing you're unlocking around unref() so that the > handler may do things like adding a new idle handler > to the context, shouldnt the same semantics be provided > for source_funcs->finalize() as well? > Interesting observation Tim. We actually ran into a deadlock in the gtk print module code where a source finalize function was trying to add another idle... So fixing this would help GTK+; it would allow us to unload the print backends. Matthias From matthias.clasen@gmail.com Fri Jun 2 13:22:11 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id B05EA3B01BA for ; Fri, 2 Jun 2006 13:22:11 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10854-10 for ; Fri, 2 Jun 2006 13:22:10 -0400 (EDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.186]) by menubar.gnome.org (Postfix) with ESMTP id 691F63B007B for ; Fri, 2 Jun 2006 13:22:10 -0400 (EDT) Received: by nf-out-0910.google.com with SMTP id l37so1137364nfc for ; Fri, 02 Jun 2006 10:22:09 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=WQtzpP4N8ZyKSiiDfpj/VtLI/AxhPsWp029H1Nvd+SG7mq6Rf64PWWm4vH8TCDmIyieOgUdMr0+Y64igzWX+Liq5FKe/p14IvHTVc7Jf8A3g/lkQrbeGGqzHTAEGhQsu+lwlvRhqNYJVH8XXuOcmjrJxkEXrBrcqWzQyQ9CuNTg= Received: by 10.48.14.19 with SMTP id 19mr950281nfn; Fri, 02 Jun 2006 10:22:09 -0700 (PDT) Received: by 10.48.215.7 with HTTP; Fri, 2 Jun 2006 10:22:09 -0700 (PDT) Message-ID: Date: Fri, 2 Jun 2006 13:22:09 -0400 From: "Matthias Clasen" To: "Petr Tomasek" In-Reply-To: <20060602070042.GA3470@ebed.etf.cuni.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1149203639.27455.9.camel@localhost.localdomain> <20060602070042.GA3470@ebed.etf.cuni.cz> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.733 tagged_above=-999 required=2 tests=[AWL=-0.691, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.558, SPF_PASS=-0.001] X-Spam-Score: -1.733 X-Spam-Level: Cc: gtk-devel-list@gnome.org Subject: Re: Print preview api X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 17:22:11 -0000 On 6/2/06, Petr Tomasek wrote: > On Thu, Jun 01, 2006 at 07:13:59PM -0400, Matthias Clasen wrote: > > Ok, after a lot of work (mostly by John and Alex), > > we finally have a proposal for a print preview > > api that will allow us to use an external viewer > > by default, but also support internal preview. > > Hi! > > I think, this is very unfortunate. Many people will > not want to use the external viewer (for reasons discused > earlier), so everyone will write his own preview > widget? Why not just have official internal > preview widget like gnome-print has and support > it by deafult? You are more than welcome to on a high-quality print preview widget and propse it for inclusion; it is a considerable amount of work though (duplicating things that are already in evince), and we are not going to hold the 2.10 release for it. Defaulting to external preview allows us to release 2.10 with preview support, which seems better than no preview support at all. In other news, Alex has just committed the preview patch with some fixes. Matthias From kris@babi-pangang.org Fri Jun 2 19:04:03 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 6F8D73B051E for ; Fri, 2 Jun 2006 19:04:03 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29568-08 for ; Fri, 2 Jun 2006 19:04:02 -0400 (EDT) Received: from nasi-goreng.babi-pangang.org (nasi-goreng.babi-pangang.org [83.166.137.20]) by menubar.gnome.org (Postfix) with ESMTP id 2B5243B04C8 for ; Fri, 2 Jun 2006 19:04:01 -0400 (EDT) Received: by nasi-goreng.babi-pangang.org (Postfix, from userid 1000) id BC1643DCA0; Sat, 3 Jun 2006 01:03:59 +0200 (CEST) Date: Sat, 3 Jun 2006 01:03:59 +0200 From: Kristian Rietveld To: Matthias Clasen Message-ID: <20060602230359.GB10757@babi-pangang.org> References: <20060531200823.GA7846@babi-pangang.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.525 tagged_above=-999 required=2 tests=[AWL=-0.003, BAYES_00=-2.599, TW_GT=0.077] X-Spam-Score: -2.525 X-Spam-Level: Cc: gtk-devel-list@gnome.org, timj@imendio.com Subject: Re: Tooltips progress X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 23:04:03 -0000 On Thu, Jun 01, 2006 at 09:33:48AM -0400, Matthias Clasen wrote: > Using x == -1 to indicate a keyboard-triggered tooltip looks a bit > odd to me; how about adding a boolean parameter for this ? Good idea, fixed this. > Regarding dedicated treeview api, I think we can do without it > (at least initially), if we have a good example in the docs. Though > lots of people will forget the selection_changed thing for keyboard > tooltips... I'll make sure some nice example code will appear in gtk-demo, where we can point people at. > Could you enhance your demo with an example of text view > tooltips on a tag ? Will do. -kris. From kris@babi-pangang.org Fri Jun 2 19:08:42 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 1CF883B11C6 for ; Fri, 2 Jun 2006 19:08:42 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29930-06 for ; Fri, 2 Jun 2006 19:08:40 -0400 (EDT) Received: from nasi-goreng.babi-pangang.org (nasi-goreng.babi-pangang.org [83.166.137.20]) by menubar.gnome.org (Postfix) with ESMTP id 89C933B11CD for ; Fri, 2 Jun 2006 19:08:40 -0400 (EDT) Received: by nasi-goreng.babi-pangang.org (Postfix, from userid 1000) id 411F73DCA0; Sat, 3 Jun 2006 01:08:37 +0200 (CEST) Date: Sat, 3 Jun 2006 01:08:37 +0200 From: Kristian Rietveld To: Tim Janik Message-ID: <20060602230837.GC10757@babi-pangang.org> References: <20060531200823.GA7846@babi-pangang.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.563 tagged_above=-999 required=2 tests=[AWL=0.036, BAYES_00=-2.599] X-Spam-Score: -2.563 X-Spam-Level: Cc: Gtk+ Developers Subject: Re: Tooltips progress X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 23:08:42 -0000 On Thu, Jun 01, 2006 at 06:21:29PM +0200, Tim Janik wrote: > On Thu, 1 Jun 2006, Matthias Clasen wrote: > the idea behind ::has-tooltip is to reduce the number of required signal > emissions to figure a tooltip. e.g. by adding a PRIVATE_GTK_* flag that > indicates if the ::query-tooltips() emission is neccessary. > maybe it'd helpt to rename that property to ::can-tooltip? Or maybe ::enable-query-tooltip? > (if you want to argue consistency with other things settable/gettable > on widgets though, then yes, you have a point for also exporting it > as a property) I would tend to add the property just for consistency. > >The example doesn't show tooltips constructed using the old tooltips > >api, but I assume those will continue to work as before, right ? > > that was the plan, i.e. you'd basically just do: I am not 100% if we can implement the complete old API using the new one, for example the public fields in the old structures and GtkTipsQuery come to mind ... I'll investigate once I get a first patch out. -kris. From exe522@hotmail.com Mon Jun 5 10:30:49 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id E7BDF3B0420 for ; Mon, 5 Jun 2006 10:30:48 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06214-09 for ; Mon, 5 Jun 2006 10:30:45 -0400 (EDT) Received: from hotmail.com (bay104-f19.bay104.hotmail.com [65.54.175.29]) by menubar.gnome.org (Postfix) with ESMTP id 81AC13B030D for ; Mon, 5 Jun 2006 10:30:44 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 5 Jun 2006 07:30:43 -0700 Message-ID: Received: from 65.54.175.200 by by104fd.bay104.hotmail.msn.com with HTTP; Mon, 05 Jun 2006 14:30:41 GMT X-Originating-IP: [83.202.13.252] X-Originating-Email: [exe522@hotmail.com] X-Sender: exe522@hotmail.com In-Reply-To: <44747D3E.8020902@imendio.com> From: "Malik NakaMura" To: richard@imendio.com Date: Mon, 05 Jun 2006 14:30:41 +0000 Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed X-OriginalArrivalTime: 05 Jun 2006 14:30:43.0753 (UTC) FILETIME=[A0A49190:01C688AC] X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-0.739 tagged_above=-999 required=2 tests=[AWL=-1.535, BAYES_05=-1.11, DNS_FROM_RFC_ABUSE=0.2, DNS_FROM_RFC_POST=1.708, MSGID_FROM_MTA_HEADER=0, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -0.739 X-Spam-Level: Cc: otaylor@redhat.com, ben2004uk@googlemail.com, scott@asofyet.org, gtk-devel-list@gnome.org Subject: Re: GTK+ >> Cocoa Native Port X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2006 14:30:49 -0000 Hi, I'm trying to implement this function : _gdk_quartz_copy_to_image (gdkimage-quartz.c) I would like to know if it is possible to get the pixels table from a GdkPixmap structure ? this is the code : GdkImage * _gdk_quartz_copy_to_image (GdkDrawable *drawable, GdkImage *image, gint src_x, gint src_y, gint dest_x, gint dest_y, gint width, gint height) { /* FIXME: Implement */ // Image Creation image = g_object_new (gdk_image_get_type (), NULL); image->width = width; image->height = height; image->byte_order = (G_BYTE_ORDER == G_LITTLE_ENDIAN) ? GDK_LSB_FIRST : GDK_MSB_FIRST; image->bpp = 4; image->bpl = image->width * image->bpp; image->bits_per_pixel = image->bpp * 8; // Get the Visual GdkColormap *colormap = gdk_drawable_get_colormap (drawable); if(colormap != NULL) { image->visual = gdk_colormap_get_visual (colormap); } // Get the depth image->depth = GDK_PIXMAP_OBJECT (drawable)->depth; // Get the pixels ??? image->mem = g_malloc (image->bpl * image->height); memset (image->mem, 0x00, image->bpl * image->height); image->mem = gdk_pixbuf_get_pixels (GDK_PIXBUF (drawable)); return image; } I think that drawable is a GdkPixmap structure, so I cant do GDK_PIXBUF (drawable), but is there a function to get the pixbuf from a pixmap ? From domlachowicz@gmail.com Mon Jun 5 10:52:51 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id B05E13B0543 for ; Mon, 5 Jun 2006 10:52:51 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08008-05 for ; Mon, 5 Jun 2006 10:52:48 -0400 (EDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.205]) by menubar.gnome.org (Postfix) with ESMTP id 0DD8B3B03E7 for ; Mon, 5 Jun 2006 10:52:47 -0400 (EDT) Received: by wx-out-0102.google.com with SMTP id i30so1182797wxd for ; Mon, 05 Jun 2006 07:52:47 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=mBHtGZClxJk0twUjUBnjIyhM/WAD6Uo9my7i+D5hoC4J+tCoUbUHFxNQxrI4rHUN+ozS7wnRgFO+uMkkEg6Pg2xZje4D8Xja5Bt7lmKFvCh6pSZMS6uV+5TpBquvMmVoaoFkNDoZEDJjdLqt3Wj9IaLQ/ggRMyfDTkEaz5x0TcU= Received: by 10.70.49.6 with SMTP id w6mr6127550wxw; Mon, 05 Jun 2006 07:52:44 -0700 (PDT) Received: by 10.70.116.12 with HTTP; Mon, 5 Jun 2006 07:52:44 -0700 (PDT) Message-ID: <2672cf4d0606050752o12a6d0d2gcb4c355cc0f35d79@mail.gmail.com> Date: Mon, 5 Jun 2006 10:52:44 -0400 From: "Dominic Lachowicz" To: "Malik NakaMura" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <44747D3E.8020902@imendio.com> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.457 tagged_above=-999 required=2 tests=[AWL=0.143, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.457 X-Spam-Level: Cc: gtk-devel-list@gnome.org Subject: Re: GTK+ >> Cocoa Native Port X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2006 14:52:51 -0000 > I think that drawable is a GdkPixmap structure, so I cant do GDK_PIXBUF > (drawable), but is there a function to get the pixbuf from a pixmap ? You might want to look at gdk_pixbuf_get_from_drawable(). Best, Dom -- Counting bodies like sheep to the rhythm of the war drums. From mclasen@redhat.com Mon Jun 5 14:15:03 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 744343B09D3; Mon, 5 Jun 2006 14:15:03 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20278-06; Mon, 5 Jun 2006 14:15:01 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id D637E3B0988; Mon, 5 Jun 2006 14:15:00 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k55IF08I024331; Mon, 5 Jun 2006 14:15:00 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k55IF0I9021827; Mon, 5 Jun 2006 14:15:00 -0400 Received: from golem.boston.redhat.com (golem.boston.redhat.com [172.16.80.24]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id k55IExAV012588; Mon, 5 Jun 2006 14:14:59 -0400 From: Matthias Clasen To: gnome-announce-list@gnome.org, gtk-devel-list@gnome.org, gtk-app-devel-list@gnome.org, gtk-list@gnome.org Content-Type: text/plain; charset=UTF-8 Date: Mon, 05 Jun 2006 14:14:59 -0400 Message-Id: <1149531299.4071.35.camel@golem.boston.redhat.com> Mime-Version: 1.0 X-Mailer: Evolution 2.7.1 (2.7.1-1) Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.543 tagged_above=-999 required=2 tests=[AWL=0.058, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.543 X-Spam-Level: Cc: Subject: GLib 2.11.2 released X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gnome-hackers@gnome.org List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2006 18:15:03 -0000 GLib 2.11.2 is now available for download at: ftp://ftp.gtk.org/pub/gtk/v2.11/ http://ftp.gnome.org/pub/GNOME/sources/glib/2.11/ glib-2.11.2.tar.bz2 md5sum: 18464b85bfd589f83897623c637a1553 glib-2.11.2.tar.gz md5sum: f728cd295ac98d4b95d850fe91c05fd5 This is a development release leading up to GLib 2.12. Notes: * This is unstable development release. While it has had a bit of testing, there are certainly plenty of bugs remaining to be found. This release should not be used in production. * Installing this version will overwrite your existing copy of GLib 2.10. If you have problems, you'll need to reinstall GLib 2.10. * GLib 2.12 will be source and binary compatible with the GLib 2.10.x series (for some caveats, see the README). At this point, the API additions in the 2.11.x series are almost finished. * Bugs should be reported to http://bugzilla.gnome.org. About GLib ========== GLib is the low-level core library that forms the basis for projects such as GTK+ and GNOME. It provides data structure handling for C, portability wrappers, and interfaces for such runtime functionality as an event loop, threads, dynamic loading, and an object system. More information about GLib is available at: http://www.gtk.org/ An installation guide for the GTK+ libraries, including GLib, can be found at: http://developer.gnome.org/doc/API/2.0/gtk/gtk-building.html Overview of Changes from GLib 2.11.1 to GLib 2.11.2 =================================================== * Add g_ascii_stroll to parse signed 64bit integers * GMarkup: add a flag to treat CDATA as text * GHashTable: add functions to remove all entries * GMainLoop: add functions to find the currently running source, and determine if it is destroyed * Bug fixes: 342563 g_atomic_thread_init() needs to be called before other _g_*_thread_init() functions 343548 Potential use after free in callers of g_string_free() 168538 Wish: Clearing contents of GHashTables 321886 GTK+ cannot be reliably used in multi-threaded applications 341826 goption.c: 'strtoll' is C99's function 343899 g_ascii_formatd dosn't work as expected for all format strings 317793 Make GEnumValue strings const 337129 Compile warnings in G_IMPLEMENT_INTERFACE 303622 What is G_TYPE_CHAR? * Updated translations (bg,dz,eu,gl,ja,nl,th,vi) A list of all bugs fixed in this release can be found at: http://bugzilla.gnome.org/buglist.cgi?bug_id=341826,342563,343548,168538,168538,321886,343899,321886,317793,337129,303622 Thanks to everybody who has contributed to this release, in the form of bug reports or patches: Peter Kjellerstedt, Kazuki Iwamoto Leonard den Ottolander, Chris Wilson, Behdad Esfahbod, Matt Barnes, ystein Johansen, Tim Janik Morten Welinder Matthias Clasen June 5, 2006 From mclasen@redhat.com Mon Jun 5 16:21:34 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 09B113B0543; Mon, 5 Jun 2006 16:21:34 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28553-01; Mon, 5 Jun 2006 16:21:32 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id 0F8903B0012; Mon, 5 Jun 2006 16:21:31 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k55KLVn7006951; Mon, 5 Jun 2006 16:21:31 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k55KLUBq020469; Mon, 5 Jun 2006 16:21:31 -0400 Received: from golem.boston.redhat.com (golem.boston.redhat.com [172.16.80.24]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id k55KLUAV025318; Mon, 5 Jun 2006 16:21:30 -0400 From: Matthias Clasen To: gnome-announce-list@gnome.org, gtk-devel-list@gnome.org, gtk-app-devel-list@gnome.org, gtk-list@gnome.org Content-Type: text/plain Date: Mon, 05 Jun 2006 16:21:30 -0400 Message-Id: <1149538890.4071.40.camel@golem.boston.redhat.com> Mime-Version: 1.0 X-Mailer: Evolution 2.7.1 (2.7.1-1) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.429 tagged_above=-999 required=2 tests=[AWL=-0.059, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, TW_GD=0.077, TW_GT=0.077, TW_XI=0.077] X-Spam-Score: -2.429 X-Spam-Level: Cc: Subject: GTK+ 2.9.2 released X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gnome-hackers@gnome.org List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2006 20:21:34 -0000 GTK+ 2.9.2 is now available for download at: http://ftp.gnome.org/pub/gnome/sources/gtk+/2.9/ gtk+-2.9.2.tar.gz md5sum: c63e7d0cf7c4e983206c3088a0fb8862 gtk+-2.9.2.tar.bz2 md5sum: 17629437af44fce03485101371c8f041 This is a development release leading up to GTK+ 2.10. Notes: * This is unstable development release. There are certainly plenty of bugs remaining to be found. This release should not be used in production. * Installing this version will overwrite your existing copy of GTK+ 2.8. If you have problems, you'll need to reinstall GTK+ 2.8. * GTK+ 2.10 will be source compatible with the GTK+ 2.8 series; the new API additions in GTK+ 2.9.0 are not yet completely finalized, so there are likely incompatibilies between this release and the final 2.10 release. * The ABI version has been bumped from 2.4.0 to 2.10.0, since the filechooser backend interface has been changed. Third-party filechooser backends need to be ported to the new interface. Other third-party modules (input methods, image loaders, etc) just need to be reinstalled in the proper location for GTK+ to find them. * Remaining issues for GTK+ 2.10 can be found with following bugzilla query: http://bugzilla.gnome.org/buglist.cgi?product=gtk%2b&target_milestone=2.10+API+Freeze&target_milestone=2.10+Freeze&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED * Bugs should be reported to http://bugzilla.gnome.org. What is GTK+ ============ GTK+ is a multi-platform toolkit for creating graphical user interfaces. Offering a complete set of widgets, GTK+ is suitable for projects ranging from small one-off tools to complete application suites. GTK+ has been designed from the ground up to support a range of languages, not only C/C++. Using GTK+ from languages such as Perl and Python (especially in combination with the Glade GUI builder) provides an effective method of rapid application development. GTK+ is free software and part of the GNU Project. However, the licensing terms for GTK+, the GNU LGPL, allow it to be used by all developers, including those developing proprietary software, without any license fees or royalties. Where to get more information about GTK+ ======================================== Information about GTK+ including links to documentation can be found at: http://www.gtk.org/ An installation guide for GTK+ 2.x is found at: http://developer.gnome.org/doc/API/2.4/gtk/gtk-building.html Common questions: http://developer.gnome.org/doc/API/2.4/gtk/gtk-question-index.html http://www.gtk.org/faq/ Overview of Changes from GTK+ 2.9.1 to 2.9.2 ============================================ * GtkPrintOperation - Support asynchronous pagination with the ::paginate signal - Add gtk_print_operation_cancel - Support application-specific widgets - Allow disabling features based on application capabilities - Optionally show progress - Change some function names in GtkPrintContext to be longer and better - Support preview, the default implementation spawns evince, but the api allows for an internal preview implementation * GtkCellView - Add a model property * GtkStatusIcon - Allow to obtain screen geometry * GtkTreeView - Many bug fixes, in particular for RTL handling - Separate sensitive and selectable properties of rows - Optionally allow rubberband selection * GtkButton - Add image-spacing style property - Add image-position property * GtkToolButton - Add icon-spacing style property * Make GTK+ work as an untrused X client * Bugs fixed: 343838 gtkprintoperationpreview.h guards 305530 Crashes while creating source code w/GtkFontSelection 341327 Memory corruption inside glib 341734 cursor blocked to dnd mode after using shift and dnd on a GtkCalendar 343453 G_DEFINE_TYPE messes up internal typenames of GdkWindow and GdkPixmap 136571 Problems running as untrusted client 168105 the right edge tab does not appear when switching tab 172535 Add support for UI builders in gtk+ 302556 GtkTreeView widget signals are badly documented 324480 Selecting first item with keyboard is difficult 340428 small cleanup 340444 don't run the custom page size dialogue 340839 Critical warnings in GtkTreeModelFilter 341898 gtk_tree_view_insert_column_with_attributes doesn't work with fixed_height_mode 342003 DnD: Conditional jump or move depends on uninitialised value 342072 Wrong drop location in GtkEntry 342096 GtkImage animation CRITICALS on switching themes 342513 widget class style property with type module 342529 gdk should set resolution on PangoCairoFontmap, not PangoCairoContext 342535 Add documentation for new GtkWidget style properties (including Since tags) 342543 can't compile gtk+ on opensolaris using sun cc 342569 Typo in decl of gdk_color_parse 342752 Need a way to specify custom tab label for custom page in Print dialog 342754 print-editor: font button dialog doesn't get focus if main window has a window group 342781 GtkPrintUnixDialog: Collate should be insensitive unless Copies is > 1 342783 GtkPrintUnixDialog: Range textinput area should be insensitive unless range radiobutton is selected 342894 Use after free inside gtk_text_view_set_buffer 342930 GtkButton should offer a way to position the image relative to the text 343088 Some typos in the PO file 343425 "grab-notify"-signal is not correctly propagated for internal children 343438 gtk_color_button_set_color() doesn't emit "color-set" signal 343475 page setup unix dialog confusion 343625 allow to get only some info from gtk_status_icon_get_geometry 343677 GtkWindow chains key-release to key-press 320431 Text too close when using East/West in a GtkToolButton 321523 GtkTreeView's test_expand_row signal emitting impractical on row expand all 342007 Warning in gtk_paned_compute_position 343233 gdk_rectangle_intersect doc 333284 expander animation not working in RTL mode 343444 change color of gtk-demo source-buffer comment color from red to DodgerBlue 343630 Small inconsistence in migration documentation 80127 Rubberbanding for GtkTreeView 341450 status icon + libnotify 341679 Allow absolute filenames in the options entries * Updated translations (bg,cy,de,el,es,et,eu,gl,gu,it,ja, nb,nl,pt_BR,th,vi) Thanks to everybody who has contributed to this release, in the form of bug reports or patches: Alexander Larsson, Behdad Esfahbod, Benjamin Berg, Caolan McNamara, Carlos Garnacho Parro, Carol Spears, Christian Persch, Chris Wilson, Claudio Saavedra, Clytie Siddall, Damon Chaplin, Daniel Lindenaar, Dan Winship, Diana Fong, Ed Catmur, Emmanuele Bassi, Havoc Pennington, Henrique Romano, Hiroyuki Ikezoe, James Moger, Johan Dahlin, Kouhei Sutou, Kristian Rietveld, Markku Vire, Mart Raudsepp, Masatake Yamato, Michael Emmel, Michael Natterer, Murray Cumming, Olexiy Avramchenko, Paolo Borelli, Patrick Monnerat, Richard Hult, Sampo Savolainen, Sebastien Bacher, Srirama Sharma, Stefan Kost, Tim Janik, Tommi Komulainen, Tor Lillqvist, Yevgen Muntyan A list of all bugs fixed in this release can be found at: http://bugzilla.gnome.org/buglist.cgi?bug_id=342072,342096,342003,341734,305530,168105,342007,342529,342535,342543,342569,341679,342752,172535,342513,342781,342783,342754,136571,341450,333284,340428,340839,341898,321523,343088,343233,324480,342894,320431,342930,343453,343425,343438,343444,340444,343475,302556,343677,343625,80127,343838,341327,168105,343630 Matthias Clasen June 5, 2006 From otaylor@redhat.com Mon Jun 5 18:10:18 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 606843B039F for ; Mon, 5 Jun 2006 18:10:18 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03967-08 for ; Mon, 5 Jun 2006 18:10:17 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id CAF5C3B0389 for ; Mon, 5 Jun 2006 18:10:16 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k55MAGwn013331; Mon, 5 Jun 2006 18:10:16 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k55MAGNr013297; Mon, 5 Jun 2006 18:10:16 -0400 Received: from localhost.localdomain (sebastian-int.corp.redhat.com [172.16.52.221]) by devserv.devel.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k55MAFJC021457; Mon, 5 Jun 2006 18:10:15 -0400 From: Owen Taylor In-Reply-To: <2672cf4d0606050752o12a6d0d2gcb4c355cc0f35d79@mail.gmail.com> References: <44747D3E.8020902@imendio.com> <2672cf4d0606050752o12a6d0d2gcb4c355cc0f35d79@mail.gmail.com> Content-Type: text/plain Date: Mon, 05 Jun 2006 15:10:09 -0400 Message-Id: <1149534609.2441.107.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 (2.6.1-1.fc5.2) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.187 tagged_above=-999 required=2 tests=[AWL=-0.199, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.478, FORGED_RCVD_HELO=0.135, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.187 X-Spam-Level: Cc: gtk-devel-list@gnome.org Subject: Re: GTK+ >> Cocoa Native Port X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2006 22:10:18 -0000 On Mon, 2006-06-05 at 10:52 -0400, Dominic Lachowicz wrote: > > I think that drawable is a GdkPixmap structure, so I cant do GDK_PIXBUF > > (drawable), but is there a function to get the pixbuf from a pixmap ? > > You might want to look at gdk_pixbuf_get_from_drawable(). Not going to help here, I think .. copy_to_image() is the backend function used to implement gdk_pixbuf_get_from_drawable(). :-) This is the point in the code where you need to figure out how to copy pixels from a native drawable into an image buffer, which is going to involve native graphics system calls. If you can find docs on how to take a screenshot of a window in OS X, that will be similar code to what is needed here. Owen From rpmcruz@clix.pt Mon Jun 5 21:41:34 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id B9E363B03FB for ; Mon, 5 Jun 2006 21:41:34 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15260-05 for ; Mon, 5 Jun 2006 21:41:33 -0400 (EDT) Received: from mailrly02.isp.novis.pt (mailrly02.isp.novis.pt [195.23.133.212]) by menubar.gnome.org (Postfix) with ESMTP id 84DA33B0076 for ; Mon, 5 Jun 2006 21:41:32 -0400 (EDT) Received: (qmail 21302 invoked from network); 6 Jun 2006 01:41:30 -0000 Received: from unknown (HELO mailfrt04.isp.novis.pt) ([195.23.133.196]) (envelope-sender ) by mailrly02.isp.novis.pt with compressed SMTP; 6 Jun 2006 01:41:30 -0000 Received: (qmail 17342 invoked from network); 6 Jun 2006 01:41:29 -0000 Received: from unknown (HELO [10.0.0.2]) (Sent_by_authenticated_user_x2476431@[87.196.74.232]) (envelope-sender ) by mailfrt04.isp.novis.pt with SMTP; 6 Jun 2006 01:41:29 -0000 From: Ricardo Cruz To: gtk-devel-list@gnome.org Date: Tue, 6 Jun 2006 02:48:21 +0100 User-Agent: KMail/1.9.1 X-Face: $29d{(U~(^/X.rR|7i6syM3jeJ}N+*%U-#Bzl5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200606060248.21205.rpmcruz@clix.pt> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.657 tagged_above=-999 required=2 tests=[AWL=-0.917, BAYES_20=-0.74] X-Spam-Score: -1.657 X-Spam-Level: Subject: GtkComboBoxEntry -- changing entry line value X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2006 01:41:34 -0000 Hi there, Is there a way to set a value for a GtkComboBoxEntry line entry? I am currently just adding an entry, set it as selected and remove it, which is a pretty nasty work-around. By the way, is it planned to add a GtkEditable interface for it? That would be really sweet and, if affirmitive, I could work on making a patch. Cheers, Ricardo -- Fourth Law of Thermodynamics: If the probability of success is not almost one, it is damn near zero. -- David Ellis From markku.vire@kolumbus.fi Tue Jun 6 04:39:15 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 5E3DD3B0C57 for ; Tue, 6 Jun 2006 04:39:15 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23318-01 for ; Tue, 6 Jun 2006 04:39:13 -0400 (EDT) Received: from fep02-app.kolumbus.fi (fep02-0.kolumbus.fi [193.229.0.44]) by menubar.gnome.org (Postfix) with ESMTP id C21BF3B0A19 for ; Tue, 6 Jun 2006 04:37:26 -0400 (EDT) Received: from smtp.kolumbus.fi ([193.229.55.124]) by fep02-app.kolumbus.fi with ESMTP id <20060606083725.NGAZ5174.fep02-app.kolumbus.fi@smtp.kolumbus.fi>; Tue, 6 Jun 2006 11:37:25 +0300 X-Mailer: Openwave WebEngine, version 2.8.12 (webedge20-101-197-20030912) X-Originating-IP: [62.236.91.3] From: To: Ricardo Cruz , Date: Tue, 6 Jun 2006 11:37:24 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <20060606083725.NGAZ5174.fep02-app.kolumbus.fi@smtp.kolumbus.fi> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.504 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, NO_REAL_NAME=0.961, SPF_PASS=-0.001] X-Spam-Score: -1.504 X-Spam-Level: X-Mailman-Approved-At: Tue, 06 Jun 2006 07:05:18 -0400 Cc: Subject: Re: GtkComboBoxEntry -- changing entry line value X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2006 08:39:15 -0000 Hi, You can get the entry by calling gtk_bin_get_child(box); and then using any methods of GtkEntry to manipulate the text. > Is there a way to set a value for a GtkComboBoxEntry line entry? I am > currently just adding an entry, set it as selected and remove it, which is a > pretty nasty work-around. -Markku- From markku.vire@kolumbus.fi Tue Jun 6 04:39:55 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 544743B0B78 for ; Tue, 6 Jun 2006 04:39:55 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23288-09 for ; Tue, 6 Jun 2006 04:39:52 -0400 (EDT) Received: from fep02-app.kolumbus.fi (fep02-0.kolumbus.fi [193.229.0.44]) by menubar.gnome.org (Postfix) with ESMTP id BD56C3B0A19 for ; Tue, 6 Jun 2006 04:39:51 -0400 (EDT) Received: from smtp.kolumbus.fi ([193.229.55.124]) by fep02-app.kolumbus.fi with ESMTP id <20060606083950.NHYK5174.fep02-app.kolumbus.fi@smtp.kolumbus.fi>; Tue, 6 Jun 2006 11:39:50 +0300 X-Mailer: Openwave WebEngine, version 2.8.12 (webedge20-101-197-20030912) X-Originating-IP: [62.236.91.3] From: To: Ricardo Cruz , Date: Tue, 6 Jun 2006 11:39:50 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <20060606083950.NHYK5174.fep02-app.kolumbus.fi@smtp.kolumbus.fi> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.504 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, NO_REAL_NAME=0.961, SPF_PASS=-0.001] X-Spam-Score: -1.504 X-Spam-Level: X-Mailman-Approved-At: Tue, 06 Jun 2006 07:05:18 -0400 Cc: Subject: Re: GtkComboBoxEntry -- changing entry line value X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2006 08:39:55 -0000 Hi, You can get the entry by calling gtk_bin_get_child(box); and then using any methods of GtkEntry to manipulate the text. > Is there a way to set a value for a GtkComboBoxEntry line entry? I am > currently just adding an entry, set it as selected and remove it, which is a > pretty nasty work-around. -Markku- From federico@ximian.com Tue Jun 6 11:45:51 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id A23E83B00FF for ; Tue, 6 Jun 2006 11:45:51 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01904-10 for ; Tue, 6 Jun 2006 11:45:35 -0400 (EDT) Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) by menubar.gnome.org (Postfix) with ESMTP id 6D4083B0ADD for ; Tue, 6 Jun 2006 11:45:33 -0400 (EDT) Received: (qmail 15590 invoked from network); 6 Jun 2006 15:45:31 -0000 Received: from localhost (HELO ?164.99.120.162?) (127.0.0.1) by localhost with SMTP; 6 Jun 2006 15:45:31 -0000 From: Federico Mena Quintero To: GTK+ development mailing list Content-Type: text/plain Date: Tue, 06 Jun 2006 10:41:22 -0500 Message-Id: <1149608483.14088.54.camel@cacharro.xalalinux.org> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.574 tagged_above=-999 required=2 tests=[AWL=0.025, BAYES_00=-2.599] X-Spam-Score: -2.574 X-Spam-Level: Cc: Michael.meeks@novell.com Subject: Default timeouts X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2006 15:45:51 -0000 In gtksettings.c we have #define DEFAULT_TIMEOUT_INITIAL 200 #define DEFAULT_TIMEOUT_REPEAT 20 for the "gtk-timeout-initial" and "gtk-timeout-repeat" settings, respectively. This means we wait for a fifth of a second before we start repeating, but then we try to repeat 50 times per second. Isn't the repeat timeout way too short? This is why clicking on a calendar arrow takes you back tens of months in no time, and also makes it hard to use spin buttons. Also, Michael Meeks has the following words of wisdom in a Novell bug about the calendar in gnome-panel's clock: > In essence the timeout is way too short for switching days; also - > in the panel applet the timeout has a higher priority than the > queued resize of the display (and hence the redraw) - so in > essence we skip days even faster since we never have to render > them. > > Lowering the priority there, and lengthening the timeouts gives > a far more reasonable, usable experience without getting rid > of the whole auto-repeat principle [...] I.e. instead of using g_timeout_add() in gtkcalendar, we would use g_timeout_add_full (G_PRIORITY_DEFAULT_IDLE, ...), or perhaps (GDK_PRIORITY_REDRAW + positive_constant): both are lower priority than GTK_PRIORITY_RESIZE. Federico From michael.meeks@novell.com Tue Jun 6 12:33:58 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 74B9F3B0197 for ; Tue, 6 Jun 2006 12:33:58 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05177-09 for ; Tue, 6 Jun 2006 12:33:57 -0400 (EDT) Received: from gwia-smtp.id2.novell.com (public.id2-vpn.continvity.gns.novell.com [195.33.99.129]) by menubar.gnome.org (Postfix) with ESMTP id 3714E3B014F for ; Tue, 6 Jun 2006 12:33:57 -0400 (EDT) Received: from [192.168.0.8] (l4-client.id2.novell.com [::ffff:149.44.117.251]) by gwia-smtp.id2.novell.com with ESMTP (TLS encrypted); Tue, 06 Jun 2006 17:33:30 +0100 From: Michael Meeks To: Federico Mena Quintero In-Reply-To: <1149608483.14088.54.camel@cacharro.xalalinux.org> References: <1149608483.14088.54.camel@cacharro.xalalinux.org> Content-Type: text/plain Organization: Novell, Inc. Date: Tue, 06 Jun 2006 17:37:54 +0100 Message-Id: <1149611874.2202.2.camel@t60p.site> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.427 tagged_above=-999 required=2 tests=[AWL=-0.028, BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2] X-Spam-Score: -2.427 X-Spam-Level: Cc: GTK+ development mailing list Subject: Re: Default timeouts X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: michael.meeks@novell.com List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2006 16:33:58 -0000 On Tue, 2006-06-06 at 10:41 -0500, Federico Mena Quintero wrote: > > In essence the timeout is way too short for switching days; also - > > in the panel applet the timeout has a higher priority than the > > queued resize of the display (and hence the redraw) - so in > > essence we skip days even faster since we never have to render > > them. Of course - this is particularly applicable for the calendar where it really makes sense to actually see the month rendered each time you switch to a different month or year. Of course with a spin-button I guess throttling the spin rate to that of the refresh rate would (perhaps) be problematic. Then again re-rendering a spin-button is presumably an extremely fast operation. HTH, Michael. -- michael.meeks@novell.com <><, Pseudo Engineer, itinerant idiot From carlosgc@gnome.org Wed Jun 7 07:48:25 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id BACA33B0C6A for ; Wed, 7 Jun 2006 07:48:25 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08136-01 for ; Wed, 7 Jun 2006 07:48:23 -0400 (EDT) Received: from localhost.localdomain (gsyc090.dat.escet.urjc.es [193.147.71.90]) by menubar.gnome.org (Postfix) with ESMTP id D0D083B01EA for ; Wed, 7 Jun 2006 07:48:22 -0400 (EDT) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 945E110F28E for ; Wed, 7 Jun 2006 13:48:19 +0200 (CEST) From: Carlos Garcia Campos To: GTK+ development mailing list Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-hBJf7M2jws0KBkd4rYip" Date: Wed, 07 Jun 2006 13:48:17 +0200 Message-Id: <1149680898.3302.9.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.285 tagged_above=-999 required=2 tests=[AWL=0.179, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.285 X-Spam-Level: Subject: Evince preview mode X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 11:48:25 -0000 --=-hBJf7M2jws0KBkd4rYip Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi,=20 since gtk+ is using evince as an external printing previewer, I'm implementing a preview mode in evince, available through the command line (--preview). It's based on the ephy printing previewer where the menubar is hidden and the toolbar contains navigation items and a close button. Here is an screenshot: http://carlosgc.linups.org/files/evince-preview-mode.png Any other thing expected by a previewer? --=20 Carlos Garcia Campos (KaL) elkalmail@yahoo.es carlosgc@gnome.org http://carlosgc.linups.org PGP key: http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0x523E6462 --=-hBJf7M2jws0KBkd4rYip Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQBEhr0BjxBOalI+ZGIRAmSgAJ9Ksy9L8QqVxpvNQCtbejp/0HRZXACeNcmq O8LT0nzkGzw+qcPFuVqZ3y8= =xZYn -----END PGP SIGNATURE----- --=-hBJf7M2jws0KBkd4rYip-- From hfiguiere@teaser.fr Wed Jun 7 08:28:18 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id AC8923B0CE2; Wed, 7 Jun 2006 08:28:18 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11220-01; Wed, 7 Jun 2006 08:28:15 -0400 (EDT) Received: from xandros.com (smtp1.xandros.com [209.87.238.70]) by menubar.gnome.org (Postfix) with ESMTP id EC3713B0CD7; Wed, 7 Jun 2006 08:28:14 -0400 (EDT) Received: from [172.18.1.132] (toronto-hs-216-138-231-194.s-ip.magma.ca [216.138.231.194]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by xandros.com (Postfix) with ESMTP id E7D80C028; Wed, 7 Jun 2006 08:28:12 -0400 (EDT) Message-ID: <4486C65A.5060800@teaser.fr> Date: Wed, 07 Jun 2006 08:28:10 -0400 From: Hubert Figuiere User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: Carlos Garcia Campos References: <1149680898.3302.9.camel@localhost.localdomain> In-Reply-To: <1149680898.3302.9.camel@localhost.localdomain> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.499 tagged_above=-999 required=2 tests=[AWL=0.100, BAYES_00=-2.599] X-Spam-Score: -2.499 X-Spam-Level: Cc: GTK+ development mailing list Subject: Re: Evince preview mode X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 12:28:19 -0000 Carlos Garcia Campos wrote: > Hi, > > since gtk+ is using evince as an external printing previewer, I'm > implementing a preview mode in evince, available through the command > line (--preview). It's based on the ephy printing previewer where the > menubar is hidden and the toolbar contains navigation items and a close > button. Here is an screenshot: > > http://carlosgc.linups.org/files/evince-preview-mode.png > > Any other thing expected by a previewer? It think it should have a menu bar, even if it is way simplier than Evince, and the button to close in the toolbar should be removed because it is "uncommon" and in fact confuse the user on what to do. Closing the window should be all that needed, or doing a file->close in the menu, Also, zoom in and zoom out are very useful. Hub From paolo.maggi@gmail.com Wed Jun 7 08:15:10 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 9C3E63B08CC for ; Wed, 7 Jun 2006 08:15:10 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10407-05 for ; Wed, 7 Jun 2006 08:15:09 -0400 (EDT) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.172]) by menubar.gnome.org (Postfix) with ESMTP id 8B7343B0303 for ; Wed, 7 Jun 2006 08:15:08 -0400 (EDT) Received: by ug-out-1314.google.com with SMTP id c2so258875ugf for ; Wed, 07 Jun 2006 05:15:07 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:subject:from:to:cc:content-type:date:message-id:mime-version:x-mailer:content-transfer-encoding; b=K90OlbUivfHjc3p7Mf7NxXYQ7dM8ZBxC+0BsgOJcKZJuB7jHCl0ZAGBW4g8105rAzePSP5EyfdcA7LlHJh+VEWxuXvCS7dbrv6RMBVJzQ/vwIPq71eGzz8nn2EwMpB2LP+LFhmJsovQOwZfLUn1MKDz4iRRATWR1zOQleW/WqEg= Received: by 10.67.105.19 with SMTP id h19mr435594ugm; Wed, 07 Jun 2006 05:15:06 -0700 (PDT) Received: from elilix.polito.it ( [130.192.16.224]) by mx.gmail.com with ESMTP id q1sm888781uge.2006.06.07.05.15.05; Wed, 07 Jun 2006 05:15:06 -0700 (PDT) From: Paolo Maggi To: carlosgc@gnome.org Content-Type: text/plain Date: Wed, 07 Jun 2006 14:15:04 +0200 Message-Id: <1149682504.5804.33.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.6 tagged_above=-999 required=2 tests=[AWL=0.000, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.6 X-Spam-Level: X-Mailman-Approved-At: Wed, 07 Jun 2006 09:03:01 -0400 Cc: gtk-devel-list@gnome.org Subject: Re: Evince preview mode X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 12:15:10 -0000 Hi, cia > since gtk+ is using evince as an external printing previewer, I'm > implementing a preview mode in evince, available through the command > line (--preview). It's based on the ephy printing previewer where the > menubar is hidden and the toolbar contains navigation items and a close > button. Here is an screenshot: > > http://carlosgc.linups.org/files/evince-preview-mode.png > > Any other thing expected by a previewer? - Zoom - Direct jump to a given page Please, look also at the gedit 2.14.x print previewer. Probably we also need a way to specify paper orientation on the command line (or is orientation already specified in the PDF file?) Ciao, Paolo From matthias.clasen@gmail.com Wed Jun 7 09:13:05 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id E24273B0D07 for ; Wed, 7 Jun 2006 09:13:04 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14781-07 for ; Wed, 7 Jun 2006 09:13:02 -0400 (EDT) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.202]) by menubar.gnome.org (Postfix) with ESMTP id 00C823B0B41 for ; Wed, 7 Jun 2006 09:13:01 -0400 (EDT) Received: by nz-out-0102.google.com with SMTP id 9so196545nzo for ; Wed, 07 Jun 2006 06:13:01 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=saqMihVje8FYa9UdpyLa1+dlefvQoIGQxKH7/1Zo60aYxymeM8Pd6GyFWAgY0o+p1vKDz7amMyAC6pjntEQBEcP8uj0rJL3yYZX1hequAVkJsd5sQslhyn8T44EZjEA/hsuQz0+1EdqmPuNMRK0Lseu0seEU88n8Ei5Ii1IMFBQ= Received: by 10.37.13.40 with SMTP id q40mr711105nzi; Wed, 07 Jun 2006 06:13:00 -0700 (PDT) Received: by 10.37.21.14 with HTTP; Wed, 7 Jun 2006 06:13:00 -0700 (PDT) Message-ID: Date: Wed, 7 Jun 2006 09:13:00 -0400 From: "Matthias Clasen" To: "Carlos Garcia Campos" In-Reply-To: <1149680898.3302.9.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1149680898.3302.9.camel@localhost.localdomain> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.508 tagged_above=-999 required=2 tests=[AWL=0.092, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.508 X-Spam-Level: Cc: GTK+ development mailing list Subject: Re: Evince preview mode X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 13:13:05 -0000 On 6/7/06, Carlos Garcia Campos wrote: > Hi, > > since gtk+ is using evince as an external printing previewer, I'm > implementing a preview mode in evince, available through the command > line (--preview). It's based on the ephy printing previewer where the > menubar is hidden and the toolbar contains navigation items and a close > button. Here is an screenshot: > > http://carlosgc.linups.org/files/evince-preview-mode.png > > Any other thing expected by a previewer? A print button. From n1huq@hotmail.com Wed Jun 7 13:11:51 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 04F873B04FC for ; Wed, 7 Jun 2006 13:11:51 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32024-05 for ; Wed, 7 Jun 2006 13:11:49 -0400 (EDT) Received: from hotmail.com (bay114-dav5.bay114.hotmail.com [65.54.169.77]) by menubar.gnome.org (Postfix) with ESMTP id 192433B00F5 for ; Wed, 7 Jun 2006 13:11:49 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 7 Jun 2006 10:11:48 -0700 Message-ID: Received: from 68.0.250.43 by BAY114-DAV5.phx.gbl with DAV; Wed, 07 Jun 2006 17:11:46 +0000 X-Originating-IP: [68.0.250.43] X-Originating-Email: [n1huq@hotmail.com] X-Sender: n1huq@hotmail.com From: "Sydney Faria" To: Date: Wed, 7 Jun 2006 13:15:56 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-OriginalArrivalTime: 07 Jun 2006 17:11:48.0135 (UTC) FILETIME=[75E3BB70:01C68A55] X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=1.984 tagged_above=-999 required=2 tests=[BAYES_50=0.001, DNS_FROM_RFC_ABUSE=0.2, DNS_FROM_RFC_POST=1.708, MSGID_FROM_MTA_HEADER=0, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, TW_GT=0.077] X-Spam-Score: 1.984 X-Spam-Level: * Subject: combo box problem X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 17:11:51 -0000 The following simple example of a gtk_combo_box compiles and works OK it the select_cb() is empty. The line marked gives a compiler error: undefined reference to gtk_combo_box_get_active_text. I am befuddled! sydney #include #include GtkWidget *window, *combo; static gboolean delete_event(GtkWidget *widget, GdkEvent *event, gpointer data) { return FALSE; } static void destroy(GtkWidget *widget, gpointer data) { gtk_main_quit(); } static void select_cb(GtkWidget *widget, gpointer data) { /* comment out following 2 lines and program compiles and works OK */ gchar *str = gtk_combo_box_get_active_text(GTK_COMBO_BOX(combo)); /* compile error */ g_print("active text: %s\n", str); } int main( int argc, char *argv[] ) { GtkWidget *button, *hbox; gtk_init (&argc, &argv); /* init gtk */ window = gtk_window_new (GTK_WINDOW_TOPLEVEL); gtk_container_set_border_width(GTK_CONTAINER(window), 10); g_signal_connect(G_OBJECT(window), "delete_event", G_CALLBACK(delete_event), NULL); g_signal_connect(G_OBJECT(window), "destroy", G_CALLBACK(destroy), NULL); hbox = gtk_hbox_new(TRUE, 20); gtk_container_add(GTK_CONTAINER(window), hbox); button = gtk_button_new_with_label("Select text"); g_signal_connect(G_OBJECT(button), "clicked", G_CALLBACK(select_cb), NULL); gtk_box_pack_start(GTK_BOX(hbox), button, FALSE, FALSE, 0); combo = gtk_combo_box_new_text(); gtk_box_pack_start(GTK_BOX(hbox), combo, FALSE, FALSE, 0); gtk_combo_box_insert_text(GTK_COMBO_BOX(combo), 0, "Astring"); gtk_combo_box_append_text(GTK_COMBO_BOX(combo), "Bstring"); gtk_combo_box_append_text(GTK_COMBO_BOX(combo), "Cstring"); gtk_combo_box_append_text(GTK_COMBO_BOX(combo), "Dstring"); gtk_combo_box_append_text(GTK_COMBO_BOX(combo), "Estring"); gtk_combo_box_insert_text(GTK_COMBO_BOX(combo), 3, "xxxxx"); gtk_widget_show_all(window); gtk_main(); return 0; } From ali@avrc.city.ac.uk Wed Jun 7 13:20:43 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id B9C6A3B0D3D for ; Wed, 7 Jun 2006 13:20:43 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32493-04 for ; Wed, 7 Jun 2006 13:20:42 -0400 (EDT) Received: from firewall.avrc.city.ac.uk (optosun2.city.ac.uk [138.40.167.2]) by menubar.gnome.org (Postfix) with ESMTP id ACA3B3B0BDC for ; Wed, 7 Jun 2006 13:20:40 -0400 (EDT) Received: from tom.avrc.city.ac.uk (IDENT:U2FsdGVkX1/zwWSA4Vc+XKbUWVXUavCLm3rPqXMMlDg@tom [192.168.137.104]) by firewall.avrc.city.ac.uk (8.9.3/8.9.3) with ESMTP id SAA27971; Wed, 7 Jun 2006 18:10:27 +0100 Received: from tom.avrc.city.ac.uk (localhost.localdomain [127.0.0.1]) by tom.avrc.city.ac.uk (8.13.1/8.13.1) with ESMTP id k57HTT2Y031243; Wed, 7 Jun 2006 18:29:29 +0100 Date: Wed, 07 Jun 2006 17:29:28 +0000 From: "J. Ali Harlow" To: Sydney Faria References: In-Reply-To: (from n1huq@hotmail.com on Wed Jun 7 18:15:56 2006) X-Mailer: Balsa 2.2.6 Message-Id: <1149701368l.5713l.3l@tom.avrc.city.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; DelSp=Yes; Format=Flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.525 tagged_above=-999 required=2 tests=[AWL=-0.003, BAYES_00=-2.599, TW_GT=0.077] X-Spam-Score: -2.525 X-Spam-Level: Cc: gtk-devel-list@gnome.org Subject: Re: combo box problem X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 17:20:43 -0000 On 07/06/06 18:15:56, Sydney Faria wrote: > The following simple example of a gtk_combo_box compiles and works OK > it the select_cb() is empty. The line marked gives a compiler error: =20 > undefined reference to gtk_combo_box_get_active_text. gtk_combo_box_get_active_text was added in Gtk+ v2.6 Ali. From carlosgc@gnome.org Wed Jun 7 14:37:47 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id D45D43B0546 for ; Wed, 7 Jun 2006 14:37:47 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05339-08 for ; Wed, 7 Jun 2006 14:37:46 -0400 (EDT) Received: from localhost.localdomain (gsyc090.dat.escet.urjc.es [193.147.71.90]) by menubar.gnome.org (Postfix) with ESMTP id 3EC7D3B03F7 for ; Wed, 7 Jun 2006 14:37:46 -0400 (EDT) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 0ABE610F28E for ; Wed, 7 Jun 2006 20:37:40 +0200 (CEST) From: Carlos Garcia Campos To: gtk-devel-list@gnome.org In-Reply-To: References: <1149680898.3302.9.camel@localhost.localdomain> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-WdU94ldj/PvL1mhYRti9" Date: Wed, 07 Jun 2006 20:37:39 +0200 Message-Id: <1149705460.3302.25.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.354 tagged_above=-999 required=2 tests=[AWL=0.110, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.354 X-Spam-Level: Subject: Re: Evince preview mode X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 18:37:48 -0000 --=-WdU94ldj/PvL1mhYRti9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable El mi=C3=A9, 07-06-2006 a las 09:13 -0400, Matthias Clasen escribi=C3=B3: > On 6/7/06, Carlos Garcia Campos wrote: > > Hi, > > > > since gtk+ is using evince as an external printing previewer, I'm > > implementing a preview mode in evince, available through the command > > line (--preview). It's based on the ephy printing previewer where the > > menubar is hidden and the toolbar contains navigation items and a close > > button. Here is an screenshot: > > > > http://carlosgc.linups.org/files/evince-preview-mode.png > > > > Any other thing expected by a previewer? >=20 > A print button. >=20 hmm, when the user selects preview from the print dialog, the dialog disappears and evince is launched, so that if evince has a print button we should print the document directly without showing the print dialog again. I see several problems in this approach. First of all we can't know the print settings selected by the user from evince. And, should we close evince or keep it opened after clicking on print? Is it possible to print a pdf file with the new gtk+ api without showing any dialog?=20 I think it's very confused. The best solution would be not to hide the dialog when the previewer is launched, so that once the user is happy with the results showed in evince, he simply clicks on print button.=20 --=20 Carlos Garcia Campos (KaL) elkalmail@yahoo.es carlosgc@gnome.org http://carlosgc.linups.org PGP key: http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0x523E6462 --=-WdU94ldj/PvL1mhYRti9 Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQBEhxzzjxBOalI+ZGIRAsatAJ4+rfTQPQwp9+YtbRKpPmVlDuEG9ACfclx7 9c9NhlEvkjGZjMS42o6vmHM= =TbYL -----END PGP SIGNATURE----- --=-WdU94ldj/PvL1mhYRti9-- From matthias.clasen@gmail.com Wed Jun 7 19:34:00 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 62A323B036A for ; Wed, 7 Jun 2006 19:34:00 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23001-06 for ; Wed, 7 Jun 2006 19:33:56 -0400 (EDT) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.203]) by menubar.gnome.org (Postfix) with ESMTP id A86BE3B0E6E for ; Wed, 7 Jun 2006 19:33:56 -0400 (EDT) Received: by nz-out-0102.google.com with SMTP id o37so261498nzf for ; Wed, 07 Jun 2006 16:33:55 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=LpgZtLrjc9Sc3giRUzuWDX2naMTMsbgrizT1aggkQjCN27Pm9kFPU1c5Bra0LikmJaw1sDQO0paAD7N3OQwY1+3Y9JTdMwkT9YBnlgCbMohSYLzhRt6yPFasRtdkLK24rM8sI5l8EdJ/+dpxDSU/+GFlNbztpO8kky973RVbTmY= Received: by 10.36.103.6 with SMTP id a6mr1426226nzc; Wed, 07 Jun 2006 16:33:53 -0700 (PDT) Received: by 10.37.21.14 with HTTP; Wed, 7 Jun 2006 16:33:52 -0700 (PDT) Message-ID: Date: Wed, 7 Jun 2006 19:33:52 -0400 From: "Matthias Clasen" To: "Carlos Garcia Campos" In-Reply-To: <1149705460.3302.25.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1149680898.3302.9.camel@localhost.localdomain> <1149705460.3302.25.camel@localhost.localdomain> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.509 tagged_above=-999 required=2 tests=[AWL=0.091, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.509 X-Spam-Level: Cc: gtk-devel-list@gnome.org Subject: Re: Evince preview mode X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 23:34:00 -0000 On 6/7/06, Carlos Garcia Campos wrote: > hmm, when the user selects preview from the print dialog, the dialog > disappears and evince is launched, so that if evince has a print button > we should print the document directly without showing the print dialog > again. I see several problems in this approach. First of all we can't > know the print settings selected by the user from evince. And, should we > close evince or keep it opened after clicking on print? Is it possible > to print a pdf file with the new gtk+ api without showing any dialog? Sure, figuring out the best way to transfer the print settings to evince is part of this. And yes, printing preformatted pdf is supported. > > I think it's very confused. The best solution would be not to hide the > dialog when the previewer is launched, so that once the user is happy > with the results showed in evince, he simply clicks on print button. > Apple does it too, so it can't be all bad... Matthias From hfiguiere@teaser.fr Wed Jun 7 21:05:56 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 3CAD23B051D for ; Wed, 7 Jun 2006 21:05:56 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27783-02 for ; Wed, 7 Jun 2006 21:05:53 -0400 (EDT) Received: from xandros.com (smtp1.xandros.com [209.87.238.70]) by menubar.gnome.org (Postfix) with ESMTP id 31DC43B0414 for ; Wed, 7 Jun 2006 21:05:53 -0400 (EDT) Received: from [172.18.1.132] (toronto-hs-216-138-231-194.s-ip.magma.ca [216.138.231.194]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by xandros.com (Postfix) with ESMTP id A37413E02E; Wed, 7 Jun 2006 21:05:51 -0400 (EDT) Message-ID: <448777ED.1020804@teaser.fr> Date: Wed, 07 Jun 2006 21:05:49 -0400 From: Hubert Figuiere User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: Matthias Clasen References: <1149680898.3302.9.camel@localhost.localdomain> <1149705460.3302.25.camel@localhost.localdomain> In-Reply-To: X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.506 tagged_above=-999 required=2 tests=[AWL=0.093, BAYES_00=-2.599] X-Spam-Score: -2.506 X-Spam-Level: Cc: gtk-devel-list@gnome.org Subject: Re: Evince preview mode X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 01:05:56 -0000 >> I think it's very confused. The best solution would be not to hide the >> dialog when the previewer is launched, so that once the user is happy >> with the results showed in evince, he simply clicks on print button. >> > > Apple does it too, so it can't be all bad... That is the kind of blind thinking that lead to nowhere. Remember just one thing: if it does not please Steve Jobs, it does not goes. That how it works at Apple. Bottom line: wrong argument. Hub From alexl@redhat.com Thu Jun 8 08:09:59 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 5B8C83B0EF5; Thu, 8 Jun 2006 08:09:59 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32659-09; Thu, 8 Jun 2006 08:09:58 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id B35BC3B075A; Thu, 8 Jun 2006 08:09:57 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k58C9u9M020757; Thu, 8 Jun 2006 08:09:56 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k58C9u0T021240; Thu, 8 Jun 2006 08:09:56 -0400 Received: from [127.0.0.1] (sebastian-int.corp.redhat.com [172.16.52.221]) by devserv.devel.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k58C9tGO011054; Thu, 8 Jun 2006 08:09:56 -0400 From: Alexander Larsson To: Matthias Clasen In-Reply-To: References: <1149680898.3302.9.camel@localhost.localdomain> <1149705460.3302.25.camel@localhost.localdomain> Content-Type: text/plain Date: Thu, 08 Jun 2006 14:09:55 +0200 Message-Id: <1149768596.3023.11.camel@greebo> Mime-Version: 1.0 X-Mailer: Evolution 2.7.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.587 tagged_above=-999 required=2 tests=[AWL=0.014, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.587 X-Spam-Level: Cc: gtk-devel-list@gnome.org Subject: Re: Evince preview mode X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 12:09:59 -0000 On Wed, 2006-06-07 at 19:33 -0400, Matthias Clasen wrote: > On 6/7/06, Carlos Garcia Campos wrote: > > > hmm, when the user selects preview from the print dialog, the dialog > > disappears and evince is launched, so that if evince has a print button > > we should print the document directly without showing the print dialog > > again. I see several problems in this approach. First of all we can't > > know the print settings selected by the user from evince. And, should we > > close evince or keep it opened after clicking on print? Is it possible > > to print a pdf file with the new gtk+ api without showing any dialog? > > Sure, figuring out the best way to transfer the print settings to evince > is part of this. And yes, printing preformatted pdf is supported. This is tricky. What if the preview was launched without even showing the dialog, or if the user hadn't picked the right printer yet when clicking on preview. Also, it will print differently by generating pdf and then converting that to postscript, instead of generating postscript directly. Ideally this should produce as-good output, but thats not really guaranteed. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl@redhat.com alla@lysator.liu.se He's an immortal umbrella-wielding cyborg with no name. She's a tortured green-skinned Hell's Angel from a different time and place. They fight crime! From lists@nabble.com Thu Jun 8 21:35:27 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id BFE263B0E9B for ; Thu, 8 Jun 2006 21:35:27 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18339-04 for ; Thu, 8 Jun 2006 21:35:26 -0400 (EDT) Received: from talk.nabble.com (www.nabble.com [72.21.53.35]) by menubar.gnome.org (Postfix) with ESMTP id 602DC3B05AC for ; Thu, 8 Jun 2006 21:35:26 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=talk.nabble.com) by talk.nabble.com with esmtp (Exim 4.50) id 1FoVuE-0000rb-3p for gtk-devel-list@gnome.org; Thu, 08 Jun 2006 18:35:24 -0700 Message-ID: <4785900.post@talk.nabble.com> Date: Thu, 8 Jun 2006 18:35:22 -0700 (PDT) From: darknecro To: gtk-devel-list@gnome.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-Sender: darknecromancer@dodgeit.com X-Nabble-From: darknecro X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-0.316 tagged_above=-999 required=2 tests=[AWL=2.285, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -0.316 X-Spam-Level: Subject: GTK Masks X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2006 01:35:27 -0000 I am attempting to create a single mask that would cover several items with in the GUI. There will by 16 circles created with gdk_pixmap_create_from_xpm_d, and I can currently do this, but only one item would be 'created' in the mask, so when i apply the mask to the window, only one of the items will be visible. I have done a lot of searching, and I have only been able to come up with that you can xor 2 masks together somehow and create one that contains both. Any help that anyone could shed on this would be greatly appreciated. -- View this message in context: http://www.nabble.com/GTK-Masks-t1759366.html#a4785900 Sent from the Gtk+ - Dev - General forum at Nabble.com. From mitch@gimp.org Fri Jun 9 06:31:35 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id D2D0C3B0216 for ; Fri, 9 Jun 2006 06:31:34 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14877-07 for ; Fri, 9 Jun 2006 06:31:33 -0400 (EDT) Received: from mitch.gimp.org (p549C9439.dip0.t-ipconnect.de [84.156.148.57]) by menubar.gnome.org (Postfix) with ESMTP id EB4033B01DA for ; Fri, 9 Jun 2006 06:31:30 -0400 (EDT) Received: from mitch by mitch.gimp.org with local (Exim 3.36 #1 (Debian)) id 1FoeIj-0003cx-00; Fri, 09 Jun 2006 12:33:13 +0200 From: Michael Natterer To: Federico Mena Quintero In-Reply-To: <1149608483.14088.54.camel@cacharro.xalalinux.org> References: <1149608483.14088.54.camel@cacharro.xalalinux.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Fri, 09 Jun 2006 12:33:12 +0200 Message-Id: <1149849193.3010.23.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=1.06 tagged_above=-999 required=2 tests=[AWL=-0.545, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, RCVD_IN_NJABL_DUL=1.946, RCVD_IN_SORBS_DUL=2.046, TW_GT=0.077] X-Spam-Score: 1.06 X-Spam-Level: * Cc: GTK+ development mailing list , Michael.meeks@novell.com Subject: Re: Default timeouts X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2006 10:31:35 -0000 On Tue, 2006-06-06 at 10:41 -0500, Federico Mena Quintero wrote: > In gtksettings.c we have > > #define DEFAULT_TIMEOUT_INITIAL 200 > #define DEFAULT_TIMEOUT_REPEAT 20 > > for the "gtk-timeout-initial" and "gtk-timeout-repeat" settings, > respectively. This means we wait for a fifth of a second before we > start repeating, but then we try to repeat 50 times per second. > > Isn't the repeat timeout way too short? This is why clicking on a > calendar arrow takes you back tens of months in no time, and also makes > it hard to use spin buttons. Yes, that's way too short. When doing the settings patch, I unified timeouts without actually changing them (the 20 ms was there before). However in some places I introduced a factor of 5 so all existing timeouts could be done with the two values from GtkSettings. See comment #10 of http://bugzilla.gnome.org/show_bug.cgi?id=142582 Actually, it may make sense to simply use the user's configured key repeat and delay for these two setting values. What do you think? ciao, --mitch > Also, Michael Meeks has the following words of wisdom in a Novell bug > about the calendar in gnome-panel's clock: > > > In essence the timeout is way too short for switching days; also - > > in the panel applet the timeout has a higher priority than the > > queued resize of the display (and hence the redraw) - so in > > essence we skip days even faster since we never have to render > > them. > > > > Lowering the priority there, and lengthening the timeouts gives > > a far more reasonable, usable experience without getting rid > > of the whole auto-repeat principle [...] > > I.e. instead of using g_timeout_add() in gtkcalendar, we would use > g_timeout_add_full (G_PRIORITY_DEFAULT_IDLE, ...), or perhaps > (GDK_PRIORITY_REDRAW + positive_constant): both are lower priority than > GTK_PRIORITY_RESIZE. > > Federico > > _______________________________________________ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-devel-list From ross@burtonini.com Fri Jun 9 07:15:10 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 1192B3B0099 for ; Fri, 9 Jun 2006 07:15:10 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18418-03 for ; Fri, 9 Jun 2006 07:15:08 -0400 (EDT) Received: from smtp.nildram.co.uk (smtp.nildram.co.uk [195.112.4.54]) by menubar.gnome.org (Postfix) with ESMTP id 279213B0081 for ; Fri, 9 Jun 2006 07:15:07 -0400 (EDT) Received: from burtonini.com (althur.gotadsl.co.uk [84.12.135.175]) by smtp.nildram.co.uk (Postfix) with ESMTP id 1DDA833C3F2; Fri, 9 Jun 2006 12:11:26 +0100 (BST) Received: from 127.0.0.1 (ident=unknown) by burtonini.com with esmtp (masqmail 0.2.21) id 1Foetj-17d-00; Fri, 09 Jun 2006 12:11:27 +0100 From: Ross Burton To: Michael Natterer In-Reply-To: <1149849193.3010.23.camel@localhost> References: <1149608483.14088.54.camel@cacharro.xalalinux.org> <1149849193.3010.23.camel@localhost> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-DKvhrUfzvCjsapgkUotZ" Date: Fri, 09 Jun 2006 12:11:27 +0100 Message-Id: <1149851487.2333.2.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.456 tagged_above=-999 required=2 tests=[AWL=0.008, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.456 X-Spam-Level: Cc: Federico Mena Quintero , GTK+ development mailing list , Michael.meeks@novell.com Subject: Re: Default timeouts X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2006 11:15:10 -0000 --=-DKvhrUfzvCjsapgkUotZ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2006-06-09 at 12:33 +0200, Michael Natterer wrote: > Actually, it may make sense to simply use the user's configured > key repeat and delay for these two setting values. What do you > think? That's probably a very good idea, on the grounds that people set the keyboard delay/repeat to values they can handle (i.e. my Dad has slowed them down as he isn't as fast as he used to be). What are the system defaults for the keyboard delay/repeat? Ross --=20 Ross Burton mail: ross@burtonini.com jabber: ross@burtonini.com www: http://www.burtonini.com./ PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF --=-DKvhrUfzvCjsapgkUotZ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQBEiVdeLQnkR9C0M98RAp+DAJ9s9H2qD2A4AQ6kXwgB+B6ka0ve8QCfZcQL IPi9sLP/fY2zOVLCX+eSrvo= =LNZu -----END PGP SIGNATURE----- --=-DKvhrUfzvCjsapgkUotZ-- From timj@gtk.org Fri Jun 9 13:30:55 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 1CAD23B00E9 for ; Fri, 9 Jun 2006 13:30:55 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10186-10 for ; Fri, 9 Jun 2006 13:30:52 -0400 (EDT) Received: from webmail.hansenet.de (mail03.hansenet.de [213.191.73.10]) by menubar.gnome.org (Postfix) with ESMTP id E3A183B011B for ; Fri, 9 Jun 2006 13:30:51 -0400 (EDT) Received: from birnet.org (80.171.4.161) by webmail.hansenet.de (7.2.059) id 4487A06D0006D98F; Fri, 9 Jun 2006 19:30:40 +0200 Received: from master.birnet.private (localhost [127.0.0.1]) by birnet.org (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k59HUdVg010604 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 9 Jun 2006 19:30:39 +0200 Received: (from timj@localhost) by master.birnet.private (8.13.4/8.13.4/Submit) id k59HUPEO010599; Fri, 9 Jun 2006 19:30:25 +0200 Date: Fri, 9 Jun 2006 19:30:25 +0200 (CEST) From: Tim Janik X-X-Sender: timj@master.birnet.private To: "Kaveh R. Ghazi" In-Reply-To: <200606091630.k59GUaES013244@caipclassic.rutgers.edu> Message-ID: References: <20060609152646.GE20719@space.twc.de> <200606091630.k59GUaES013244@caipclassic.rutgers.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.469 tagged_above=-999 required=2 tests=[AWL=0.130, BAYES_00=-2.599] X-Spam-Score: -2.469 X-Spam-Level: Cc: gcc@gcc.gnu.org, Gtk+ Developers Subject: Re: Problem with type safety and the "sentinel" attribute X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2006 17:30:55 -0000 thanks for the quick response Kaveh. On Fri, 9 Jun 2006, Kaveh R. Ghazi wrote: > > > void print_string_array (const char *array_name, > > const char *string, ...) __attribute__ > > ((__sentinel__)); > > > > print_string_array ("empty_array", NULL); /* gcc warns, but shouldn't */ > > > > The only way out for keeping the sentinel attribute and avoiding the > > warning is using > > > > static void print_string_array (const char *array_name, ...) > > __attribute__ ((__sentinel__)); > > I think you could maintain typesafety and silence the warning by > keeping the more specific prototype and adding an extra NULL, e.g.: > > print_string_array ("empty_array", NULL, NULL); > > Doesn't seem elegant, but it does the job. this is an option for a limited set of callers, yes. > > By the way, there is already an existing gcc bug, which is about the > > same thing (NULL passed within named args), but wants to have it the > > way it works now: > > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21911 > > Correct, the feature as I envisioned it expected the sentinel to > appear in the variable arguments only. This PR reflects when I found > out it didn't do that and got around to fixing it. Note the "buggy" > behavior wasn't exactly what you wanted either because GCC got fooled > by a sentinel in *any* of the named arguments, not just the last one. > > > > so if it gets changed, then gcc might need to support both > > - NULL termination within the last named parameter allowed > > - NULL termination only allowed within varargs parameters (like it is > > now) > > I'm not against this enhancement, but you need to specify a syntax > that allows the old behavior but also allows doing it your way. > > Hmm, perhaps we could check for attribute "nonnull" on the last named > argument, if it exists then that can't be the sentinel, if it's not > there then it does what you want. This is not completely backwards > compatible because anyone wanting the existing behavior has to add the > attribute nonnull. But there's precedent for this when attribute > printf split out whether the format specifier could be null... > > We could also create a new attribute name for the new behavior. This > would preserve backwards compatibility. I like this idea better. i agree here. as far as the majority of the GLib and Gtk+ APIs are concerned, we don't really need the flexibility of the sentinel attribute but rather a compiler check on whether the last argument used in a function call is NULL or 0 (regardless of whether it's the last named arg or already part of the varargs list). that's also why the actual sentinel wrapper in GLib looks like this: #define G_GNUC_NULL_TERMINATED __attribute__((__sentinel__)) so, if i was to make a call on this issue, i'd either introduce __attribute__((__null_terminated__)) with the described semantics, or have __attribute__((__sentinel__(-1))) work essentially like __attribute__((__sentinel__(0))) while also accepting 0 in the position of the last named argument. > Next you need to recruit someone to implement this enhancement, or > submit a patch. :-) Although given that you can silence the warning by > adding an extra NULL at the call site, I'm not sure it's worth it. i would say this is definitely worth it, because the issue also shows up in other code that is widely used: gpointer g_object_new (GType object_type, const gchar *first_property_name, ...); that's for instance a function which is called in many projects. putting the burden on the caller is clearly the wrong trade off here. so please take this as a vote for the worthiness of a fix ;) > --Kaveh > -- > Kaveh R. Ghazi ghazi@caip.rutgers.edu --- ciaoTJ From nshmyrev@yandex.ru Sat Jun 10 02:06:32 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 347973B00D0 for ; Sat, 10 Jun 2006 02:06:32 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12492-03 for ; Sat, 10 Jun 2006 02:06:28 -0400 (EDT) Received: from chen.mtu.ru (chen.mtu.ru [195.34.34.232]) by menubar.gnome.org (Postfix) with ESMTP id 78AC43B0126 for ; Sat, 10 Jun 2006 02:06:28 -0400 (EDT) Received: from gnome.local (ppp83-237-50-138.pppoe.mtu-net.ru [83.237.50.138]) by smtp.MTU.RU (Postfix) with ESMTP id D51B453DA7E; Sat, 10 Jun 2006 10:06:25 +0400 (MSD) (envelope-from nshmyrev@yandex.ru) From: "Nickolay V. Shmyrev" To: gtk-devel-list@gnome.org, gnome-i18n@gnome.org Content-Type: text/plain Date: Sat, 10 Jun 2006 10:06:30 +0400 Message-Id: <1149919590.2305.18.camel@gnome.local> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 (2.6.2-1.fc5.3) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.758 tagged_above=-999 required=2 tests=[AWL=-0.440, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, SPF_NEUTRAL=1.069, TW_GT=0.077] X-Spam-Score: -1.758 X-Spam-Level: Cc: Subject: Translation of gtk tuturial X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2006 06:06:32 -0000 Hello all. I now there was done quite amazing work about translation of gtk tutorial and I know there were some other translations http://linfoline.homedns.org/gtk/book1.html http://kldp.org/KoreanDoc/html/GtkTutorial/GtkTutorial.html What about making gtk tutorial translatable with docutils like all user documentation and merging those translations upstream? I don't ask about reference manual translation but it's also interesting, although not realistic. Probably it's not sensible to distribute tutorial with gtk package itself but use something like a web-based Rosetta. From matthias.clasen@gmail.com Sat Jun 10 10:02:35 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id A74883B0280 for ; Sat, 10 Jun 2006 10:02:35 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06778-09 for ; Sat, 10 Jun 2006 10:02:33 -0400 (EDT) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.200]) by menubar.gnome.org (Postfix) with ESMTP id 1C56D3B01C3 for ; Sat, 10 Jun 2006 10:02:33 -0400 (EDT) Received: by nz-out-0102.google.com with SMTP id z3so947001nzf for ; Sat, 10 Jun 2006 07:02:32 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=jUGG9w5BYrTkFmK4uobvwaXzJ1w3H4k8DuZIFGIHoBjFn1kgtf//lWo+engDAz0ImbOYOsKrWjvA9YAXvpwCcamcXXpE51E09vtpA8lmZKxAt+RA6AWeMX4blO5srWeestsf+E6dRd0OwZUmD3OCksEXAdLAjQcGBJBiKLVKPnQ= Received: by 10.37.15.76 with SMTP id s76mr5772218nzi; Sat, 10 Jun 2006 07:02:32 -0700 (PDT) Received: by 10.37.21.6 with HTTP; Sat, 10 Jun 2006 07:02:32 -0700 (PDT) Message-ID: Date: Sat, 10 Jun 2006 10:02:32 -0400 From: "Matthias Clasen" To: "Nickolay V. Shmyrev" In-Reply-To: <1149919590.2305.18.camel@gnome.local> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1149919590.2305.18.camel@gnome.local> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.471 tagged_above=-999 required=2 tests=[AWL=0.052, BAYES_00=-2.599, SPF_PASS=-0.001, TW_GT=0.077] X-Spam-Score: -2.471 X-Spam-Level: Cc: gnome-i18n@gnome.org, gtk-devel-list@gnome.org Subject: Re: Translation of gtk tuturial X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2006 14:02:35 -0000 On 6/10/06, Nickolay V. Shmyrev wrote: > Hello all. > > I now there was done quite amazing work about translation of gtk > tutorial and I know there were some other translations > > http://linfoline.homedns.org/gtk/book1.html > > http://kldp.org/KoreanDoc/html/GtkTutorial/GtkTutorial.html > > What about making gtk tutorial translatable with docutils like all > user documentation and merging those translations upstream? > > I don't ask about reference manual translation but it's also interesting, > although not realistic. Probably it's not sensible to distribute tutorial > with gtk package itself but use something like a web-based Rosetta. > The first step towards making the tutorial more useful would be updating its 2.0 era content, remove deprecated apis, and cover at least some of the important new apis. From lists@nabble.com Sat Jun 10 13:20:05 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id BB53E3B01B8 for ; Sat, 10 Jun 2006 13:20:05 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16672-08 for ; Sat, 10 Jun 2006 13:20:04 -0400 (EDT) Received: from talk.nabble.com (www.nabble.com [72.21.53.35]) by menubar.gnome.org (Postfix) with ESMTP id 2730A3B01D7 for ; Sat, 10 Jun 2006 13:20:04 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=talk.nabble.com) by talk.nabble.com with esmtp (Exim 4.50) id 1Fp77z-0000O0-FG for gtk-devel-list@gnome.org; Sat, 10 Jun 2006 10:20:03 -0700 Message-ID: <4809607.post@talk.nabble.com> Date: Sat, 10 Jun 2006 10:20:03 -0700 (PDT) From: mikecorn To: gtk-devel-list@gnome.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-Sender: mikecorn@t-online.de X-Nabble-From: mikecorn X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.565 tagged_above=-999 required=2 tests=[AWL=0.036, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.565 X-Spam-Level: Subject: GTK window edge detection sensitivity X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2006 17:20:05 -0000 To: GTK developers The resizable windows in Gnome are slick, but I often have a minor problem: After the mouse cursor changes form, indicating that the window edge is in-range for dragging, I often find myself dragging across the window behind, because the edge range was lost shortly after it was found. I ask you to consider possible improvements to make this work more reliably and with less precision required (which also means faster for the user). 1. increase the edge-detection threshold by 2x or more, or make it user-adjustable. 2. once the edge is detected, increase the threshold for losing it (time or distance). regards Mike C. -- View this message in context: http://www.nabble.com/GTK-window-edge-detection-sensitivity-t1767067.html#a4809607 Sent from the Gtk+ - Dev - General forum at Nabble.com. From marcel@telka.sk Sat Jun 10 23:05:18 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 2D8C03B05D2 for ; Sat, 10 Jun 2006 23:05:18 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06780-08 for ; Sat, 10 Jun 2006 23:05:16 -0400 (EDT) Received: from tortuga.telka.sk (unknown [193.86.173.20]) by menubar.gnome.org (Postfix) with SMTP id 7D8283B0543 for ; Sat, 10 Jun 2006 23:05:15 -0400 (EDT) Received: (qmail 14272 invoked by uid 0); 11 Jun 2006 02:57:43 -0000 Date: 11 Jun 2006 02:57:43 -0000 Message-ID: <20060611025743.14269.qmail@tortuga.telka.sk> To: From: Marcel Telka X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.443 tagged_above=-999 required=2 tests=[AWL=0.156, BAYES_00=-2.599] X-Spam-Score: -2.443 X-Spam-Level: Subject: gtk+: Missing translatable files X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jun 2006 03:05:18 -0000 Hi. I have tested module gtk+ (CVS branch HEAD) which lives in GNOME CVS for missing translatable files with `intltool-update -m` command. Here is a content of the 'missing' file: gtk/gtkfilechoosersettings.c gtk/gtkprintoperationpreview.c Please put these files into POTFILES.in or POTFILES.skip files. Thanks. Note: This report is generated automatically and you are not required to reply to this mail. If you are not maintainer of the 'gtk+' module or this CVS branch is obsolete or you don't want similar report in future, tell me and I will stop this report generation. Regards. -- +-------------------------------------------+ | Marcel Telka e-mail: marcel@telka.sk | | homepage: http://telka.sk/ | | jabber: marcel@jabber.sk | +-------------------------------------------+ From easy-b@freesurf.ch Sun Jun 11 16:22:48 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id ABE753B0159 for ; Sun, 11 Jun 2006 16:22:48 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32516-10 for ; Sun, 11 Jun 2006 16:22:46 -0400 (EDT) Received: from mail-fs.sunrise.ch (mta-fs-be-04.sunrise.ch [194.158.229.33]) by menubar.gnome.org (Postfix) with ESMTP id A306E3B00CA for ; Sun, 11 Jun 2006 16:22:45 -0400 (EDT) Received: from [10.0.1.2] (84.227.173.50) by mail-fs.sunrise.ch (7.2.073) id 44858C490024803A; Sun, 11 Jun 2006 22:21:55 +0200 In-Reply-To: References: <20060522160033.F1A8E3B1CE4@menubar.gnome.org> <772588ED-500A-4A11-8829-DA80B9A35D1F@freesurf.ch> <44720B8C.3080903@imendio.com> <0A34FCC9-6650-4737-B86D-1B503D8A9072@freesurf.ch> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7D6367DC-8689-453B-8FD7-217632BC1DAE@freesurf.ch> Content-Transfer-Encoding: 7bit From: Easy B Date: Sun, 11 Jun 2006 22:21:54 +0200 To: Gregor Riepl X-Mailer: Apple Mail (2.749.3) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.312 tagged_above=-999 required=2 tests=[AWL=-0.787, BAYES_00=-2.599, DNS_FROM_RFC_POST=1.708, FORGED_RCVD_HELO=0.135, TW_BG=0.077, TW_GD=0.077, TW_GT=0.077] X-Spam-Score: -1.312 X-Spam-Level: Cc: gtk-devel-list@gnome.org Subject: Mac OS X Framework X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jun 2006 20:22:48 -0000 Hoi Gregor Thanx for the Tips. This would make the Framework more like one. The ability to include it into the application bundle would be very handy. If I look at other Frameworks I always find a single library in the top directory, for example: /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ Frameworks/ImageIO.framework/ImageIO If I do "otool -L /System/Library/Frameworks/ ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/ ImageIO", I get references to many other libraries that are located inside the framework bundle: /System/Library/Frameworks/ApplicationServices.framework/ Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/ libJPEG.dylib (compatibility version 1.0.0, current version 1.0.0) /System/Library/Frameworks/ApplicationServices.framework/ Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/ libJP2.dylib (compatibility version 1.0.0, current version 1.0.0) /System/Library/Frameworks/ApplicationServices.framework/ Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/ libGIF.dylib (compatibility version 1.0.0, current version 1.0.0) /System/Library/Frameworks/ApplicationServices.framework/ Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/ libRaw.dylib (compatibility version 1.0.0, current version 1.0.0) /System/Library/Frameworks/ApplicationServices.framework/ Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/ libTIFF.dylib (compatibility version 1.0.0, current version 1.0.0) /System/Library/Frameworks/ApplicationServices.framework/ Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/ libPng.dylib (compatibility version 1.0.0, current version 1.0.0) /System/Library/Frameworks/ApplicationServices.framework/ Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/ libRadiance.dylib (compatibility version 1.0.0, current version 1.0.0) In my Gtk+.framework I have tons of libraries. Would it be possible to create something like the above for gtk? Would it make sense? Right now I just use pkg-config to find the libraries and the result looks like this: /Applications/Shity Apps/Gtk-Demo.app/Contents/MacOS/gtk-demo: /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libgdk_pixbuf-2.0.0.dylib (compatibility version 902.0.0, current version 902.0.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libgdk-quartz-2.0.0.dylib (compatibility version 902.0.0, current version 902.0.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libgtk-quartz-2.0.0.dylib (compatibility version 902.0.0, current version 902.0.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libpangocairo-1.0.0.dylib (compatibility version 1301.0.0, current version 1301.1.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libpangoft2-1.0.0.dylib (compatibility version 1301.0.0, current version 1301.1.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libpango-1.0.0.dylib (compatibility version 1301.0.0, current version 1301.1.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libatk-1.0.0.dylib (compatibility version 1115.0.0, current version 1115.0.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libgobject-2.0.0.dylib (compatibility version 1102.0.0, current version 1102.0.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libgmodule-2.0.0.dylib (compatibility version 1102.0.0, current version 1102.0.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libglib-2.0.0.dylib (compatibility version 1102.0.0, current version 1102.0.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libcairo.2.dylib (compatibility version 9.0.0, current version 9.0.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libpng12.0.dylib (compatibility version 11.0.0, current version 11.0.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libfontconfig.1.dylib (compatibility version 2.0.0, current version 2.4.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libfreetype.6.dylib (compatibility version 10.0.0, current version 10.8.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libxml2.2.dylib (compatibility version 9.0.0, current version 9.24.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libintl.3.dylib (compatibility version 8.0.0, current version 8.3.0) What do you think? Cheers, Ezra. On 11.06.2006, at 10:22, Gregor Riepl wrote: > Hi Ezra > >> Well it's looking better now. I even ended up with ready to use >> Installers. I still got my pkg-config/headers problem though so >> the script still has some ugly hard links in it., besides all the >> other debugging ugliness. I'm also not sure if the framework is >> usable the way it's now. I will first have to try to compile some >> apps against it. I'll definitely come with more problems soon. > > To make a framework fully usable, it's dynamic library paths need > to be adapted with install_name_tool. > For example, its the self-reference should be > @executable_path/../Frameworks/.framework/ > Versions/A/ > This makes the library includable in application bundles, instead > of having to install it. > But you may of course also use /Library/Frameworks/ framework>.framework/Versions/A/ > Have a look at the output of otool -L for some system and user- > installed libraries, i.e. > > $ otool -L /System/Library/Frameworks/Cocoa.framework/Cocoa > /System/Library/Frameworks/Cocoa.framework/Cocoa: > /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa > (compatibility version 1.0.0, current version 11.0.0) > /System/Library/Frameworks/AppKit.framework/Versions/C/ > AppKit (compatibility version 45.0.0, current version 822.0.0) > /System/Library/Frameworks/CoreData.framework/Versions/A/ > CoreData (compatibility version 1.0.0, current version 46.0.0) > /System/Library/Frameworks/Foundation.framework/Versions/C/ > Foundation (compatibility version 300.0.0, current version 566.0.0) > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, > current version 88.0.0) > > or > > $ otool -L /Library/Frameworks/SDL_image.framework/SDL_image > /Library/Frameworks/SDL_image.framework/SDL_image: > @executable_path/../Frameworks/SDL_image.framework/Versions/ > A/SDL_image (compatibility version 1.0.0, current version 1.0.0) > @executable_path/../Frameworks/SDL.framework/Versions/A/SDL > (compatibility version 1.0.0, current version 1.0.0) > /usr/lib/libz.1.dylib (compatibility version 1.0.0, current > version 1.0.0) > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, > current version 71.1.1) > > If a library has a lot of dependencies, you may run into a problem > here: The Mach-O header's area for library references isn't of > variable size, and install_name_tool may refuse to change all > paths. There's afaik no other way then to relink the binary with > the option -headerpad_max_install_names (see man ld). > From mclasen@redhat.com Mon Jun 12 12:04:32 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 41C3B3B000C; Mon, 12 Jun 2006 12:04:32 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09149-04; Mon, 12 Jun 2006 12:04:29 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id 7270D3B009D; Mon, 12 Jun 2006 12:04:29 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5CG3bc9030255; Mon, 12 Jun 2006 12:03:37 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5CG3bc3007778; Mon, 12 Jun 2006 12:03:37 -0400 Received: from golem.boston.redhat.com (golem.boston.redhat.com [172.16.80.24]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id k5CG3blQ018463; Mon, 12 Jun 2006 12:03:37 -0400 From: Matthias Clasen To: gnome-announce-list@gnome.org, gtk-devel-list@gnome.org, gtk-app-devel-list@gnome.org, gtk-list@gnome.org Content-Type: text/plain Date: Mon, 12 Jun 2006 12:03:36 -0400 Message-Id: <1150128216.15532.14.camel@golem.boston.redhat.com> Mime-Version: 1.0 X-Mailer: Evolution 2.7.1 (2.7.1-1) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.426 tagged_above=-999 required=2 tests=[AWL=-0.056, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, TW_LQ=0.077, TW_RX=0.077, TW_TR=0.077] X-Spam-Score: -2.426 X-Spam-Level: Cc: Subject: GLib 2.11.3 released X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gome-hackers@gnome.org List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2006 16:04:32 -0000 GLib 2.11.3 is now available for download at: ftp://ftp.gtk.org/pub/gtk/v2.11/ http://ftp.gnome.org/pub/GNOME/sources/glib/2.11/ glib-2.11.3.tar.bz2 md5sum: 41931c4965f7e1848f81b800914905cd glib-2.11.3.tar.gz md5sum: cd78ebc535e29cdef0fed9487aa21dac This is a development release leading up to GLib 2.12. Notes: * This is unstable development release. While it has had a bit of testing, there are certainly plenty of bugs remaining to be found. This release should not be used in production. * Installing this version will overwrite your existing copy of GLib 2.10. If you have problems, you'll need to reinstall GLib 2.10. * GLib 2.12 will be source and binary compatible with the GLib 2.10.x series (for some caveats, see the README). At this point, the API additions in the 2.11.x series are almost finished. * Bugs should be reported to http://bugzilla.gnome.org. About GLib ========== GLib is the low-level core library that forms the basis for projects such as GTK+ and GNOME. It provides data structure handling for C, portability wrappers, and interfaces for such runtime functionality as an event loop, threads, dynamic loading, and an object system. More information about GLib is available at: http://www.gtk.org/ An installation guide for the GTK+ libraries, including GLib, can be found at: http://developer.gnome.org/doc/API/2.0/gtk/gtk-building.html Overview of Changes from GLib 2.11.2 to GLib 2.11.3 =================================================== * GBookmarkFile: - g_bookmark_file_move_item: Return TRUE in case of an empty target * Bugs fixed: 343919 gunicollate.c: strxfrm bug on VC8 * Updated translations (fi) A list of all bugs fixed in this release can be found at: http://bugzilla.gnome.org/buglist.cgi?bug_id=343919 Thanks to everybody who has contributed to this release, in the form of bug reports or patches: Emmanuele Bassi, Kazuki Iwamoto, Tor Lillqvist Matthias Clasen June 12, 2006 From mclasen@redhat.com Mon Jun 12 15:43:04 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 851123B00E5; Mon, 12 Jun 2006 15:43:04 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27729-06; Mon, 12 Jun 2006 15:43:02 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id 5B16F3B0010; Mon, 12 Jun 2006 15:43:02 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5CJZWav007572; Mon, 12 Jun 2006 15:35:32 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5CJZWUd001833; Mon, 12 Jun 2006 15:35:32 -0400 Received: from golem.boston.redhat.com (golem.boston.redhat.com [172.16.80.24]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id k5CJZWlQ009694; Mon, 12 Jun 2006 15:35:32 -0400 From: Matthias Clasen To: gnome-announce-list@gnome.org, gtk-devel-list@gnome.org, gtk-app-devel-list@gnome.org, gtk-list@gnome.org Content-Type: text/plain Date: Mon, 12 Jun 2006 15:35:31 -0400 Message-Id: <1150140931.15532.18.camel@golem.boston.redhat.com> Mime-Version: 1.0 X-Mailer: Evolution 2.7.1 (2.7.1-1) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.541 tagged_above=-999 required=2 tests=[AWL=0.060, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.541 X-Spam-Level: Cc: Subject: GTK+ 2.8.19 released X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gnome-hackers@gnome.org List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2006 19:43:04 -0000 GTK+ 2.8.19 is now available for download at: ftp://ftp.gtk.org/pub/gtk/v2.8/ http://ftp.gnome.org/pub/GNOME/sources/gtk+/2.8/ gtk+-2.8.19.tar.bz2 md5sum: 1a03dbed4b794194a610e9d7eb175b06 gtk+-2.8.19.tar.gz md5sum: 604d3263498994c58af378f0ec076e6f This is a bugfix release in the 2.8.x series. It fixes a rare memory corruption issue when using the deprecated GdkFont API. What is GTK+ ============ GTK+ is a multi-platform toolkit for creating graphical user interfaces. Offering a complete set of widgets, GTK+ is suitable for projects ranging from small one-off tools to complete application suites. GTK+ has been designed from the ground up to support a range of languages, not only C/C++. Using GTK+ from languages such as Perl and Python (especially in combination with the Glade GUI builder) provides an effective method of rapid application development. GTK+ is free software and part of the GNU Project. However, the licensing terms for GTK+, the GNU LGPL, allow it to be used by all developers, including those developing proprietary software, without any license fees or royalties. Where to get more information about GTK+ ======================================== Information about GTK+ including links to documentation can be found at: http://www.gtk.org/ An installation guide for GTK+ 2.8 is found at: http://developer.gnome.org/doc/API/2.0/gtk/gtk-building.html Common questions: http://developer.gnome.org/doc/API/2.0/gtk/gtk-question-index.html http://www.gtk.org/faq/ Overview of Changes from GTK+ 2.8.18 to GTK+ 2.8.19 =================================================== Bugs fixed: 341327 Memory corruption inside glib 337491 _gdk_win32_drawable_release_dc: DeleteDC() called on a GetDC() handle 343425 "grab-notify"-signal is not correctly propagated for internal children 344244 Window resizing not working when keeping the aspect fixed 344496 CRLF converting via Clipboard Updated translations (ne) A list of all bugs fixed in this release can be found at: http://bugzilla.gnome.org/buglist.cgi?bug_id=343425,341327,344244,337491,344496 Thanks to everybody who has contributed to this release, in the form of bug reports or patches: Markku Vire, Sampo Savolainen, Tim Janik, Tor Lillqvist, Chris Wilson June 12, 2006 Matthias Clasen From mclasen@redhat.com Tue Jun 13 02:09:16 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 72FE93B00AF; Tue, 13 Jun 2006 02:09:16 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12183-04; Tue, 13 Jun 2006 02:09:13 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id B2F773B000C; Tue, 13 Jun 2006 02:09:13 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5D681s3022181; Tue, 13 Jun 2006 02:08:01 -0400 Received: from lacrosse.corp.redhat.com (lacrosse.corp.redhat.com [172.16.52.154]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5D67uRP017686; Tue, 13 Jun 2006 02:07:56 -0400 Received: from [172.16.83.145] (vpn83-145.boston.redhat.com [172.16.83.145]) by lacrosse.corp.redhat.com (8.12.11.20060308/8.11.6) with ESMTP id k5D67tQC015619; Tue, 13 Jun 2006 02:07:56 -0400 From: Matthias Clasen To: gnome-announce-list@gnome.org, gtk-devel-list@gnome.org, gtk-app-devel-list@gnome.org, gtk-list@gnome.org Content-Type: text/plain; charset=UTF-8 Organization: Red Hat Date: Tue, 13 Jun 2006 02:09:42 -0400 Message-Id: <1150178982.4081.13.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.7.2.1 (2.7.2.1-4) Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.426 tagged_above=-999 required=2 tests=[AWL=-0.056, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, TW_GD=0.077, TW_GT=0.077, TW_KB=0.077] X-Spam-Score: -2.426 X-Spam-Level: Cc: Subject: GTK+ 2.9.3 released X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gnome-hackers@gnome.org List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2006 06:09:16 -0000 GTK+ 2.9.3 is now available for download at: ftp://ftp.gtk.org/pub/gtk/v2.9/ http://ftp.gnome.org/pub/gnome/sources/gtk+/2.9/ gtk+-2.9.3.tar.bz2 md5sum: d73039a3b5847c352f5740ac908be7d2 gtk+-2.9.3.tar.gz md5sum: 0156eef91d2bbb23f1b6ccb49335fae5 This is a development release leading up to GTK+ 2.10. Notes: * This is unstable development release. There are certainly plenty of bugs remaining to be found. This release should not be used in production. * Installing this version will overwrite your existing copy of GTK+ 2.8. If you have problems, you'll need to reinstall GTK+ 2.8. * GTK+ 2.10 will be source compatible with the GTK+ 2.8 series; the new API additions in GTK+ 2.9.0 are not yet completely finalized, so there are likely incompatibilies between this release and the final 2.10 release. * The ABI version has been bumped from 2.4.0 to 2.10.0, since the filechooser backend interface has been changed. Third-party filechooser backends need to be ported to the new interface. Other third-party modules (input methods, image loaders, etc) just need to be reinstalled in the proper location for GTK+ to find them. * Remaining issues for GTK+ 2.10 can be found with following bugzilla query: http://bugzilla.gnome.org/buglist.cgi?product=gtk%2b&target_milestone=2.10+API+Freeze&target_milestone=2.10+Freeze&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED * Bugs should be reported to http://bugzilla.gnome.org. What is GTK+ ============ GTK+ is a multi-platform toolkit for creating graphical user interfaces. Offering a complete set of widgets, GTK+ is suitable for projects ranging from small one-off tools to complete application suites. GTK+ has been designed from the ground up to support a range of languages, not only C/C++. Using GTK+ from languages such as Perl and Python (especially in combination with the Glade GUI builder) provides an effective method of rapid application development. GTK+ is free software and part of the GNU Project. However, the licensing terms for GTK+, the GNU LGPL, allow it to be used by all developers, including those developing proprietary software, without any license fees or royalties. Where to get more information about GTK+ ======================================== Information about GTK+ including links to documentation can be found at: http://www.gtk.org/ An installation guide for GTK+ 2.x is found at: http://developer.gnome.org/doc/API/2.4/gtk/gtk-building.html Common questions: http://developer.gnome.org/doc/API/2.4/gtk/gtk-question-index.html http://www.gtk.org/faq/ Overview of Changes from GTK+ 2.9.2 to 2.9.3 ============================================ * GtkPrintOperation: - Introduce an allow-async property - Introduce a GtkPrintOperationAction enumeration - Rename pdf_target to export_filename - Allow to hide "Print to PDF" in the low-level API * GtkNotebook: - Add a destroy notify to gtk_notebook_set_window_creation_hook. * GtkTreeView: - Support grid lines * GtkRange: - Add a number of new stle properties which allow more fexible stepper theming * Bugs fixed: 153212 Have the Paste kbd shortcut jump to the location in the buffer 337491 _gdk_win32_drawable_release_dc: DeleteDC() called on a GetDC() handle 339739 gtk/gtkprintoperation-win32.c: 3 compile error 342339 GtkRange::stepper-spacing style property not implemented correctly 343945 Buttons of a GtkAssistant are not accessible 344148 Wrong reqs for ATK 344209 gtk_notebook_set_window_creation_hook() has no destroy func. 344232 GtkEntry's "Delete" context menu item is sensitive on a non-editable GtkEntry 344244 Window resizing not working when keeping the aspect fixed 344288 gtk_print_operation_preview_is_selected must return a value 344386 gdk-2.0-uninstalled.pc.in and gdkconfig.h 344496 CRLF converting via Clipboard 344504 GtkPrintCapabilities not in gtktypebuiltins.h 344505 Wrong signal registration for create_custom_widget 344512 cvs build issue 344513 pdf print module's print_stream not calling destroy notify 344518 NULL unref in page setup dialogue 344543 gtk_progress_bar_pulse calls gtk_progress_bar_paint directly 344560 gtk_print_settings_[sg]et_scale shouldn't be in percent 344607 memory leaks in gtkrecentchooserdefault.c and gtkrecentchoosermenu.c 344624 Memory leak in gtk_tree_model_filter_finalize: User data not freed 337603 Possible off-by-one in gdk_pango_layout_line_get_clip_region 344239 Wrong filename for gtk-find stock item. 344528 comma at end of GtkPrintOperationAction enum causes mozilla compilation error 344290 horizontal-padding not take into account when placing submenus 344558 document print dialogue response codes 339592 Add print-to-postscript 342249 Allow to draw upper and lower sides of GtkRange's trough differently 344530 gtk_recent_chooser_widget_new_for_manager and gtk_recent_chooser_menu_new_for_manager should allow NULL manager arg * Updated translations (es,fi,gu,ko,th,wa) A list of all bugs fixed in this release can be found at: http://bugzilla.gnome.org/buglist.cgi?bug_id=153212,337491,339739,342339,343945,344148,344209,344232,344244,344288,344386,344496,344504,344505,344512,344513,344518,344543,344560,344607,344624,337603,344239,344528,344290,344558,339592,342249,344530 Thanks to everybody who has contributed to this release, in the form of bug reports or patches: Behdad Esfahbod, Bastian Nocera, Alexander Larsson, Jrg Billeter, Murray Cumming, Milosz Derezynski, Tor Lillqvist, Kazuki Iwamoto, Chris Wilson, Michael Natterer, Benjamin Berg, Marko Anastasov, Christian Persch, Masatake Yamamoto, Elijah Newren, John Finlay, Emmanuele Bassi, David Malcolm, John Darrington, Christian Weiske, Yvgen Muntyan, Martyn Russell, Kristian Rietveld June 13, 2006 Matthias Clasen From exe522@hotmail.com Tue Jun 13 09:17:01 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 1FF7B3B000A for ; Tue, 13 Jun 2006 09:17:01 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24109-07 for ; Tue, 13 Jun 2006 09:17:00 -0400 (EDT) Received: from hotmail.com (bay104-f2.bay104.hotmail.com [65.54.175.12]) by menubar.gnome.org (Postfix) with ESMTP id 4C4843B00AF for ; Tue, 13 Jun 2006 09:17:00 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 13 Jun 2006 06:16:02 -0700 Message-ID: Received: from 65.54.175.200 by by104fd.bay104.hotmail.msn.com with HTTP; Tue, 13 Jun 2006 13:15:57 GMT X-Originating-IP: [86.212.127.235] X-Originating-Email: [exe522@hotmail.com] X-Sender: exe522@hotmail.com In-Reply-To: <2672cf4d0606050752o12a6d0d2gcb4c355cc0f35d79@mail.gmail.com> From: "Malik NakaMura" To: domlachowicz@gmail.com Date: Tue, 13 Jun 2006 13:15:57 +0000 Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed X-OriginalArrivalTime: 13 Jun 2006 13:16:02.0831 (UTC) FILETIME=[851C21F0:01C68EEB] X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-0.736 tagged_above=-999 required=2 tests=[AWL=-1.532, BAYES_05=-1.11, DNS_FROM_RFC_ABUSE=0.2, DNS_FROM_RFC_POST=1.708, MSGID_FROM_MTA_HEADER=0, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -0.736 X-Spam-Level: Cc: gtk-devel-list@gnome.org Subject: Re: GTK+ >> Cocoa Native Port X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2006 13:17:01 -0000 This is my first version of _gdk_quartz_copy_to_image. The only problem is that I didnt succeed in getting the color map from "drawable"... so the image is displayed without its original colors GdkImage * _gdk_quartz_copy_to_image (GdkDrawable *drawable, GdkImage *image, gint src_x, gint src_y, gint dest_x, gint dest_y, gint width, gint height) { GdkPixbuf *pixbuf; //printf("_gdk_quartz_copy_to_image : To Implement\n"); pixbuf = NULL; image = g_object_new (gdk_image_get_type (), NULL); image->type = GDK_TYPE_IMAGE; image->width = width; image->height = height; image->byte_order = (G_BYTE_ORDER == G_LITTLE_ENDIAN) ? GDK_LSB_FIRST : GDK_MSB_FIRST; image->bpp = 4; image->bpl = image->width * image->bpp; image->bits_per_pixel = image->bpp * 8; image->colormap = (GdkColormap *)g_malloc(sizeof(GdkColormap)); memcpy(image->colormap, GDK_DRAWABLE_IMPL_QUARTZ (&(GDK_PIXMAP_IMPL_QUARTZ (drawable)->parent_instance))->colormap, sizeof(GdkColormap)); if(image->colormap != NULL) { image->visual = (GdkVisual *)g_malloc(sizeof(GdkVisual)); memcpy(image->visual, gdk_colormap_get_visual (image->colormap), sizeof(GdkVisual)); if (image->visual) { void *data; int x, y; guint32 *pix, *pixels; image->depth = image->visual->depth; image->mem = g_malloc (image->bpl * image->height); memset (image->mem, 0x00, image->bpl * image->height); data = GDK_PIXMAP_IMPL_QUARTZ (drawable)->data; pixels = (guint32 *)data; for (y = 0; y < image->height; y++) { pix = pixels+((image->height - 1 - y)*width); for (x = 0; xwidth; x++) { gdk_image_put_pixel (image, x, y, *pix); pix++; } } return image; } } g_free(image); image = NULL; return NULL; } From kloczek@rudy.mif.pg.gda.pl Tue Jun 13 09:41:41 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 2C9B33B008F for ; Tue, 13 Jun 2006 09:41:41 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24974-03 for ; Tue, 13 Jun 2006 09:41:37 -0400 (EDT) Received: from rudy.mif.pg.gda.pl (rudy.mif.pg.gda.pl [153.19.42.16]) by menubar.gnome.org (Postfix) with ESMTP id 59FF13B000C for ; Tue, 13 Jun 2006 09:41:37 -0400 (EDT) X-Virus-Scanned: at rudy.mif.pg.gda.pl Received: by rudy.mif.pg.gda.pl (plum, from userid 2732) id 39ED2233B7; Tue, 13 Jun 2006 15:40:54 +0200 (CEST) Date: Tue, 13 Jun 2006 15:40:53 +0200 (CEST) From: =?ISO-8859-2?Q?Tomasz_K=B3oczko?= To: gtk-devel-list@gnome.org Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1270146782-1150206053=:31655" X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.579 tagged_above=-999 required=2 tests=[AWL=0.022, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.579 X-Spam-Level: Subject: gtk+ 2.9.3 compilation fail X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2006 13:41:41 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1270146782-1150206053=:31655 Content-Type: TEXT/PLAIN; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 8BIT gcc -DG_DISABLE_DEPRECATED -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -o .libs/gtk-query-immodules-2.0 queryimmodules.o ./.libs/libgtk-x11-2.0.so -L/lib64 /home/users/prac/nd/kloczek/rpm/BUILD/gtk+-2.9.3/gdk/.libs/libgdk-x11-2.0.so -latk-1.0 ../gdk-pixbuf/.libs/libgdk_pixbuf-2.0.so ../gdk/.libs/libgdk-x11-2.0.so -lpangocairo-1.0 -lpango-1.0 -lcairo -lfontconfig -lXext -lXrender -lX11 -lXinerama -lXi -lXrandr -lXcursor -lXfixes /home/users/prac/nd/kloczek/rpm/BUILD/gtk+-2.9.3/gdk-pixbuf/.libs/libgdk_pixbuf-2.0.so -lgmodule-2.0 -ldl -lgobject-2.0 -lglib-2.0 -lm ./.libs/libgtk-x11-2.0.so: undefined reference to `cairo_surface_set_fallback_resolution' collect2: ld returned 1 exit status make[4]: *** [gtk-query-immodules-2.0] Error 1 make[4]: Leaving directory `/home/users/prac/nd/kloczek/rpm/BUILD/gtk+-2.9.3/gtk' $ rpm -q cairo cairo-1.1.6-6 kloczek -- ----------------------------------------------------------- *Ludzie nie maj problemw, tylko sobie sami je stwarzaj* ----------------------------------------------------------- Tomasz Koczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek@rudy.mif.pg.gda.pl* --0-1270146782-1150206053=:31655-- From federico@ximian.com Tue Jun 13 12:13:42 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 31B0B3B0071 for ; Tue, 13 Jun 2006 12:13:42 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29632-05 for ; Tue, 13 Jun 2006 12:13:41 -0400 (EDT) Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) by menubar.gnome.org (Postfix) with ESMTP id 9C36B3B000A for ; Tue, 13 Jun 2006 12:13:40 -0400 (EDT) Received: (qmail 22968 invoked from network); 13 Jun 2006 16:11:48 -0000 Received: from localhost (HELO 164-99-120-90.boston.ximian.com) (127.0.0.1) by localhost with SMTP; 13 Jun 2006 16:11:48 -0000 From: Federico Mena Quintero To: Michael Natterer In-Reply-To: <1149849193.3010.23.camel@localhost> References: <1149608483.14088.54.camel@cacharro.xalalinux.org> <1149849193.3010.23.camel@localhost> Content-Type: text/plain Date: Tue, 13 Jun 2006 11:07:30 -0500 Message-Id: <1150214850.17566.118.camel@cacharro.xalalinux.org> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.574 tagged_above=-999 required=2 tests=[AWL=0.025, BAYES_00=-2.599] X-Spam-Score: -2.574 X-Spam-Level: Cc: GTK+ development mailing list , Michael.meeks@novell.com Subject: Re: Default timeouts X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2006 16:13:42 -0000 On Fri, 2006-06-09 at 12:33 +0200, Michael Natterer wrote: > However in some places I introduced a factor of 5 so all existing > timeouts could be done with the two values from GtkSettings. > > See comment #10 of http://bugzilla.gnome.org/show_bug.cgi?id=142582 > > Actually, it may make sense to simply use the user's configured > key repeat and delay for these two setting values. What do you > think? Yeah, it makes perfect sense to make it the same as the key repeat rate. You'll then get the same rate of change whether you use the mouse or the keyboard. Federico From stefan@space.twc.de Tue Jun 13 14:33:13 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id A37933B02D9 for ; Tue, 13 Jun 2006 14:33:13 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01854-06 for ; Tue, 13 Jun 2006 14:33:08 -0400 (EDT) Received: from space.twc.de (port-83-236-178-131.static.qsc.de [83.236.178.131]) by menubar.gnome.org (Postfix) with ESMTP id 1C3EE3B00C9 for ; Tue, 13 Jun 2006 14:33:07 -0400 (EDT) Received: from stefan by space.twc.de with local (Exim 4.50) id 1FqEOs-0007KV-NR; Tue, 13 Jun 2006 21:18:06 +0200 Date: Tue, 13 Jun 2006 21:18:06 +0200 To: Tim Janik Message-ID: <20060613191806.GA28032@space.twc.de> References: <20060609152646.GE20719@space.twc.de> <200606091630.k59GUaES013244@caipclassic.rutgers.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i From: Stefan Westerfeld X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.305 tagged_above=-999 required=2 tests=[AWL=0.159, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.305 X-Spam-Level: Cc: "Kaveh R. Ghazi" , Gtk+ Developers , gcc@gcc.gnu.org Subject: Re: Problem with type safety and the "sentinel" attribute X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2006 18:33:13 -0000 Hi! On Fri, Jun 09, 2006 at 07:30:25PM +0200, Tim Janik wrote: > On Fri, 9 Jun 2006, Kaveh R. Ghazi wrote: > >> void print_string_array (const char *array_name, > >> const char *string, ...) __attribute__ > >> ((__sentinel__)); > >> > >> print_string_array ("empty_array", NULL); /* gcc warns, but shouldn't > >*/ > >> > >> The only way out for keeping the sentinel attribute and avoiding the > >> warning is using > >> > >> static void print_string_array (const char *array_name, ...) > >> __attribute__ ((__sentinel__)); > > > >I think you could maintain typesafety and silence the warning by > >keeping the more specific prototype and adding an extra NULL, e.g.: > > > >print_string_array ("empty_array", NULL, NULL); > > > >Doesn't seem elegant, but it does the job. > > this is an option for a limited set of callers, yes. For the statistics, by adding the __sentinel__ attribute to the beast codebase, I have about 50 of those sentinel warnings that I don't need. So the double NULL termination would make quite some code more messy than it should be. > >> By the way, there is already an existing gcc bug, which is about the > >> same thing (NULL passed within named args), but wants to have it the > >> way it works now: > >> > >> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21911 > > > >Correct, the feature as I envisioned it expected the sentinel to > >appear in the variable arguments only. This PR reflects when I found > >out it didn't do that and got around to fixing it. Note the "buggy" > >behavior wasn't exactly what you wanted either because GCC got fooled > >by a sentinel in *any* of the named arguments, not just the last one. Ah, I see. > >> so if it gets changed, then gcc might need to support both > >> - NULL termination within the last named parameter allowed > >> - NULL termination only allowed within varargs parameters (like it is > >> now) > > > >I'm not against this enhancement, but you need to specify a syntax > >that allows the old behavior but also allows doing it your way. > > > >Hmm, perhaps we could check for attribute "nonnull" on the last named > >argument, if it exists then that can't be the sentinel, if it's not > >there then it does what you want. This is not completely backwards > >compatible because anyone wanting the existing behavior has to add the > >attribute nonnull. But there's precedent for this when attribute > >printf split out whether the format specifier could be null... > > > >We could also create a new attribute name for the new behavior. This > >would preserve backwards compatibility. I like this idea better. > > i agree here. as far as the majority of the GLib and Gtk+ APIs are > concerned, > we don't really need the flexibility of the sentinel attribute but rather > a compiler check on whether the last argument used in a function call > is NULL or 0 (regardless of whether it's the last named arg or already part > of the varargs list). > that's also why the actual sentinel wrapper in GLib looks like this: > > #define G_GNUC_NULL_TERMINATED __attribute__((__sentinel__)) > > so, if i was to make a call on this issue, i'd either introduce > __attribute__((__null_terminated__)) with the described semantics, > or have __attribute__((__sentinel__(-1))) work essentially like > __attribute__((__sentinel__(0))) while also accepting 0 in the position > of the last named argument. I also like the backwards compatible way better than trying to somehow modifying the attribute; it may break something now, or - which would also be bad - it may make something that somebody will want to check with the sentinel attribute in some future program impossible. The only case that I ever needed was NULL termination, so I think implementing one of the two proposals Tim made would be sufficient. Personally I like __attribute__((__null_terminated__)) better, because a -1 sentinel may be less intuitive to read in the source code. So this would be my suggestion for a "syntax specification". > >Next you need to recruit someone to implement this enhancement, or > >submit a patch. :-) Although given that you can silence the warning by > >adding an extra NULL at the call site, I'm not sure it's worth it. > > i would say this is definitely worth it, because the issue also shows up in > other code that is widely used: > gpointer g_object_new (GType object_type, > const gchar *first_property_name, > ...); > that's for instance a function which is called in many projects. > putting the burden on the caller is clearly the wrong trade off here. > > so please take this as a vote for the worthiness of a fix ;) Good. Of course I would be happy if somebody with knowledge of the compiler source could implement it. I never hacked gcc code before. But since you suggested sending a patch, I'll at least try to implement a new __null_terminated__ attribute, and ask for help if I can't figure out what to do. Cu... Stefan -- Stefan Westerfeld, Hamburg/Germany, http://space.twc.de/~stefan From easy-b@freesurf.ch Tue Jun 13 16:37:46 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 1FEC53B03CF for ; Tue, 13 Jun 2006 16:37:46 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05861-06 for ; Tue, 13 Jun 2006 16:37:45 -0400 (EDT) Received: from mail-fs.sunrise.ch (mta-fs-be-01.sunrise.ch [194.158.229.16]) by menubar.gnome.org (Postfix) with ESMTP id B948D3B00C8 for ; Tue, 13 Jun 2006 16:37:44 -0400 (EDT) Received: from [10.0.1.2] (84.226.131.17) by mail-fs.sunrise.ch (7.2.073) id 44795C850064786C; Tue, 13 Jun 2006 22:36:45 +0200 In-Reply-To: <89C1D6F0-EDC8-495C-B76B-9909E6388E62@freesurf.ch> References: <20060522160033.F1A8E3B1CE4@menubar.gnome.org> <772588ED-500A-4A11-8829-DA80B9A35D1F@freesurf.ch> <44720B8C.3080903@imendio.com> <0A34FCC9-6650-4737-B86D-1B503D8A9072@freesurf.ch> <7D6367DC-8689-453B-8FD7-217632BC1DAE@freesurf.ch> <89C1D6F0-EDC8-495C-B76B-9909E6388E62@freesurf.ch> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2B5653F8-341D-440C-9D5C-F166B296F94E@freesurf.ch> Content-Transfer-Encoding: 7bit From: Easy B Date: Tue, 13 Jun 2006 22:36:44 +0200 To: Gregor Riepl X-Mailer: Apple Mail (2.749.3) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-0.997 tagged_above=-999 required=2 tests=[AWL=-0.549, BAYES_00=-2.599, DNS_FROM_RFC_POST=1.708, FORGED_RCVD_HELO=0.135, TW_BG=0.077, TW_GD=0.077, TW_GT=0.077, TW_PK=0.077] X-Spam-Score: -0.997 X-Spam-Level: Cc: gtk-devel-list@gnome.org Subject: Re: Mac OS X Framework X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2006 20:37:46 -0000 Hi So i understand that we only need to link against one library that is linked to all the other ones, right? If I look at libgtk-quartz-2.0.dylib I see following: libgtk-quartz-2.0.dylib: /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libgtk-quartz-2.0.0.dylib (compatibility version 902.0.0, current version 902.0.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libgdk_pixbuf-2.0.0.dylib (compatibility version 902.0.0, current version 902.0.0) /usr/lib/libiconv.2.dylib (compatibility version 5.0.0, current version 5.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.1.5) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libgdk-quartz-2.0.0.dylib (compatibility version 902.0.0, current version 902.0.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libpangoft2-1.0.0.dylib (compatibility version 1301.0.0, current version 1301.1.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libpng12.0.dylib (compatibility version 11.0.0, current version 11.0.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libfontconfig.1.dylib (compatibility version 2.0.0, current version 2.4.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libfreetype.6.dylib (compatibility version 10.0.0, current version 10.8.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libxml2.2.dylib (compatibility version 9.0.0, current version 9.24.0) /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.3) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libpangocairo-1.0.0.dylib (compatibility version 1301.0.0, current version 1301.1.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libpango-1.0.0.dylib (compatibility version 1301.0.0, current version 1301.1.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libatk-1.0.0.dylib (compatibility version 1115.0.0, current version 1115.0.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libgobject-2.0.0.dylib (compatibility version 1102.0.0, current version 1102.0.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libgmodule-2.0.0.dylib (compatibility version 1102.0.0, current version 1102.0.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libglib-2.0.0.dylib (compatibility version 1102.0.0, current version 1102.0.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libcairo.2.dylib (compatibility version 9.0.0, current version 9.0.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libintl.3.dylib (compatibility version 8.0.0, current version 8.3.0) So I guess everything what we need is there. But I don't really get how to satisfy configure of a gtk app so that it only uses "- framework Gtk+". Sorry for my ignorance I'm pretty much a newbe on these things. Cheers, Ezra. On 12.06.2006, at 08:47, Gregor Riepl wrote: >> Thanx for the Tips. This would make the Framework more like one. >> The ability to include it into the application bundle would be >> very handy. >> >> If I look at other Frameworks I always find a single library in >> the top directory, for example: >> >> /System/Library/Frameworks/ApplicationServices.framework/Versions/ >> A/Frameworks/ImageIO.framework/ImageIO > that's right, this is the dynamic library itself. it doesn't have > the dylib suffix, but you may specify one if you like. > executables need to be linked against that, then, just -framework X > doesn't work. on the other hand, it's a good idea to either make > the "main" library (like libgtk-2.0.0.dylib) the framework (and > include all dependent libraries as either frameworks on their own > or dylibs) or just create an empty stub library that links against > those libraries or frameworks. to do that, make an empty .c source, > compile and link it against all the dylibs/frameworks you need. but > i can't tell if that's a good idea. > >> If I do "otool -L /System/Library/Frameworks/ >> ApplicationServices.framework/Versions/A/Frameworks/ >> ImageIO.framework/ImageIO", I get references to many other >> libraries that are located inside the framework bundle: > i guess that would be such a stub library, but maybe there's other > functionality contained? > otool can help you getting the symbols from mach-o binaries, much > like objdump. > >> In my Gtk+.framework I have tons of libraries. Would it be >> possible to create something like the above for gtk? Would it make >> sense? Right now I just use pkg-config to find the libraries and >> the result looks like this: >> >> /Applications/Shity Apps/Gtk-Demo.app/Contents/MacOS/gtk-demo: >> /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ >> libgdk_pixbuf-2.0.0.dylib (compatibility version 902.0.0, current >> version 902.0.0) >> ....... >> /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ >> libintl.3.dylib (compatibility version 8.0.0, current version 8.3.0) >> >> What do you think? > you should use /Library/Frameworks/Gtk+.framework/Versions/2.9.1/Gtk > + as the main library. it doesn't matter if that's just a stub or > the last library in the build chain (yes, i don't see > libgtk-2.0.0.dylib anywhere?). binaries then wouldn't require to be > linked against all those libs mentioned above. > this way you can also link gtk software with -framework Gtk+ and > nothing else, which you could even move into the pkconfig file and > thus facilitate porting. > i did something similar with the readily-available SDL framework > fpr mac os x, but it doesn't work very well because of the missing > startup code. with gtk it's easier i guess. > > have a nice day > gregor > > p.s.: on second thought, there could be a problem. afaik if a > binary loads a dylib, only that dylib's symbols become available > for it. the dependent symbols from libs that dylib's linked against > stay local for that dylib... maybe there's a workaround for this or > you come up with a better idea? From ntd@users.sourceforge.net Thu Jun 15 04:25:32 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 382C53B0324 for ; Thu, 15 Jun 2006 04:25:32 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22415-07 for ; Thu, 15 Jun 2006 04:25:29 -0400 (EDT) Received: from mailout01.albacom.net (mailout01.albacom.net [217.220.34.13]) by menubar.gnome.org (Postfix) with SMTP id 0694D3B0311 for ; Thu, 15 Jun 2006 04:25:28 -0400 (EDT) Received: (qmail 13668 invoked by uid 508); 15 Jun 2006 08:25:00 -0000 Received: from ntd@users.sourceforge.net by mailout01.albacom.net with qmail-scanner (spamassassin: ???. Clear:RC:1(217.221.76.9):SA:0(0.0/15.0):. Processed in 0.697195 secs); 15 Jun 2006 08:25:00 -0000 Received: from unknown (HELO sviluppo.internet.local) (postmaster@effe-gi.it@217.221.76.9) by mailout01.albacom.net with SMTP; 15 Jun 2006 08:24:59 -0000 Content-Disposition: inline From: Fontana Nicola Organization: Elettronica EFFE-GI s.n.c. To: gtk-devel-list@gnome.org Subject: GObject extension propose (GContainer) Date: Thu, 15 Jun 2006 11:01:12 +0000 User-Agent: KMail/1.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200606151101.12868.ntd@users.sourceforge.net> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.599 tagged_above=-999 required=2 tests=[BAYES_00=-2.599] X-Spam-Score: -2.599 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 08:25:32 -0000 Hi all, I'm a GObject based libraries (for UI purpose and not) user and I often need a generic container to derive my own types. In my opinion, I think this generic container must be included inside the GObject library ... it could be used by a lot of derived libraries providing a common approach. I published my solution - that is, what I am currently using - on sourceforge. http://sourceforge.net/projects/gcontainer/ Is it a good idea? Is something planned in this direction? Am I totally wrong? I need feedbacks ... Nicola From mclasen@redhat.com Thu Jun 15 09:54:37 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 88F2B3B00F3 for ; Thu, 15 Jun 2006 09:54:37 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14500-10 for ; Thu, 15 Jun 2006 09:54:36 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id 12BF23B0261 for ; Thu, 15 Jun 2006 09:54:36 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5FDsZ1W022208 for ; Thu, 15 Jun 2006 09:54:35 -0400 Received: from lacrosse.corp.redhat.com (lacrosse.corp.redhat.com [172.16.52.154]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5FDsZa4019641 for ; Thu, 15 Jun 2006 09:54:35 -0400 Received: from [172.16.83.98] (dhcp83-98.boston.redhat.com [172.16.83.98]) by lacrosse.corp.redhat.com (8.12.11.20060308/8.11.6) with ESMTP id k5FDsZL7008811 for ; Thu, 15 Jun 2006 09:54:35 -0400 Subject: GTK+ 2.10, the endgame From: Matthias Clasen To: gtk-devel-list@gnome.org Content-Type: text/plain Organization: Red Hat Date: Thu, 15 Jun 2006 09:56:26 -0400 Message-Id: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> Mime-Version: 1.0 X-Mailer: Evolution 2.7.3 (2.7.3-2) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.542 tagged_above=-999 required=2 tests=[AWL=0.059, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.542 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 13:54:37 -0000 I want to have GTK+ 2.10 ready at or immediately after GUADEC. I did not declare 2.9.3 api frozen in the release announcement, because we were still holding the door open for Kris' work on the new tooltips api. But he has run into some difficulties with the implementation which will take some time to overcome, so we have decided to punt this feature and try to get it into 2.12 early. Therefore, I want to consider 2.9.3 api frozen, and take a look at what still needs to happen before 2.10. Here are some things I personally would like get worked on (not sure how much time I can free to look into these myself): - I think the async filechooser conversion has caused some regressions, I noticed that .hidden support seems broken and autocompletion also behaved badly for me recently. - There is a number of FIXMEs and unimplemented bits in the print code. - The print backends need a careful look wrt to memory leaks and error reporting. Are there other important bugs or regressions that need attention before 2.10 ? Another thing I have slacked off about is organizing a GTK+ team meeting at GUADEC. So, who of the GTK+ team is there and at what times ? Should we try to find a free hour during the core days, or does everybody stay for the after hours ? If so, it may be easier to do a team meeting on Thursday... Matthias From timj@gtk.org Thu Jun 15 10:53:17 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id BBF963B04EA for ; Thu, 15 Jun 2006 10:53:17 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17592-10 for ; Thu, 15 Jun 2006 10:53:16 -0400 (EDT) Received: from holken.mikan.net (holken.mikan.net [83.145.56.183]) by menubar.gnome.org (Postfix) with ESMTP id 035EF3B04E7 for ; Thu, 15 Jun 2006 10:53:15 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by holken.mikan.net (Postfix) with ESMTP id C0DB83352B4; Thu, 15 Jun 2006 16:52:21 +0200 (CEST) Received: from holken.mikan.net ([127.0.0.1]) by localhost (holken.mikan.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16765-03; Thu, 15 Jun 2006 16:52:18 +0200 (CEST) Received: from birnet.org (c152167.adsl.hansenet.de [213.39.152.167]) by holken.mikan.net (Postfix) with ESMTP id E3B0433529D; Thu, 15 Jun 2006 16:52:17 +0200 (CEST) Received: from master.birnet.private (localhost.localdomain [127.0.0.1]) by birnet.org (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k5FEqH2d008152 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 15 Jun 2006 16:52:18 +0200 Received: (from timj@localhost) by master.birnet.private (8.13.4/8.13.4/Submit) id k5FEqHpN008151; Thu, 15 Jun 2006 16:52:17 +0200 Date: Thu, 15 Jun 2006 16:52:17 +0200 (CEST) From: Tim Janik X-X-Sender: timj@master.birnet.private To: Fontana Nicola Subject: Re: GObject extension propose (GContainer) In-Reply-To: <200606151101.12868.ntd@users.sourceforge.net> Message-ID: References: <200606151101.12868.ntd@users.sourceforge.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at holken.mikan.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.38 tagged_above=-999 required=2 tests=[AWL=0.084, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.38 X-Spam-Level: Cc: Gtk+ Developers X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 14:53:17 -0000 On Thu, 15 Jun 2006, Fontana Nicola wrote: > Hi all, > > I'm a GObject based libraries (for UI purpose and not) user and I often need > a generic container to derive my own types. In my opinion, I think this > generic container must be included inside the GObject library ... it could > be used by a lot of derived libraries providing a common approach. > > I published my solution - that is, what I am currently using - on > sourceforge. > > http://sourceforge.net/projects/gcontainer/ > > Is it a good idea? Is something planned in this direction? Am I totally > wrong? > > I need feedbacks ... hi. your gcontainer-1.0.0 looks like an interesting approach to me, but i'm not sure it's generally good to put that into stock libgobject. the main reason is that container needs are probably pretty variable out there (i've come across at least 4 different gobject container implementations in free software projects i'm woorking on) and that both, making too little assumptions in the child/container interface isn't going to be very helpful, albeit making too many has the same problem. i guess we could add a link to your project from the libgobject docs (it should probably have a Contrib section), for people possibly looking for a GObject container implementation. that way, gcontainer-1.0.0 gets a chance of being reused and maybe extended to something generally usefull for GObject applications out there. > Nicola --- ciaoTJ From timj@gtk.org Thu Jun 15 11:31:19 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 642E33B02ED for ; Thu, 15 Jun 2006 11:31:19 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19431-03 for ; Thu, 15 Jun 2006 11:31:18 -0400 (EDT) Received: from holken.mikan.net (holken.mikan.net [83.145.56.183]) by menubar.gnome.org (Postfix) with ESMTP id 2E9543B0155 for ; Thu, 15 Jun 2006 11:31:18 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by holken.mikan.net (Postfix) with ESMTP id B5DB533524B; Thu, 15 Jun 2006 16:32:01 +0200 (CEST) Received: from holken.mikan.net ([127.0.0.1]) by localhost (holken.mikan.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16412-10; Thu, 15 Jun 2006 16:31:58 +0200 (CEST) Received: from birnet.org (c152167.adsl.hansenet.de [213.39.152.167]) by holken.mikan.net (Postfix) with ESMTP id D5D7E335256; Thu, 15 Jun 2006 16:31:57 +0200 (CEST) Received: from master.birnet.private (localhost.localdomain [127.0.0.1]) by birnet.org (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k5FEVrL1007682 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 15 Jun 2006 16:31:53 +0200 Received: (from timj@localhost) by master.birnet.private (8.13.4/8.13.4/Submit) id k5FEVis7007681; Thu, 15 Jun 2006 16:31:45 +0200 Date: Thu, 15 Jun 2006 16:31:44 +0200 (CEST) From: Tim Janik X-X-Sender: timj@master.birnet.private To: Matthias Clasen Subject: GTK+ meeting at GUADEC (Re: GTK+ 2.10, the endgame) In-Reply-To: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> Message-ID: References: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at holken.mikan.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.381 tagged_above=-999 required=2 tests=[AWL=0.083, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.381 X-Spam-Level: Cc: Gtk+ Developers X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 15:31:19 -0000 On Thu, 15 Jun 2006, Matthias Clasen wrote: > I want to have GTK+ 2.10 ready at or immediately after GUADEC. > Another thing I have slacked off about is organizing a GTK+ > team meeting at GUADEC. So, who of the GTK+ team is there > and at what times ? Should we try to find a free hour during > the core days, or does everybody stay for the after hours ? > If so, it may be easier to do a team meeting on Thursday... i think i volounteered to take on arrangement of that to some extend. at least, we intended to have a meeting on GTK+ linking issues, and could probably merge that with the GTK+ team meeting during guadec. the plan for that was to send out en email next friday/saturday (i.e right at the guadec start) to figure/suggest dates suitable for everyone to attend. > Matthias --- ciaoTJ From hfiguiere@teaser.fr Thu Jun 15 11:52:14 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C00CA3B0261 for ; Thu, 15 Jun 2006 11:52:14 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20706-05 for ; Thu, 15 Jun 2006 11:52:13 -0400 (EDT) Received: from xandros.com (smtp1.xandros.com [209.87.238.70]) by menubar.gnome.org (Postfix) with ESMTP id 6D7663B053A for ; Thu, 15 Jun 2006 11:52:13 -0400 (EDT) Received: from [172.16.1.95] (unknown [209.87.238.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by xandros.com (Postfix) with ESMTP id 4B02239025; Thu, 15 Jun 2006 11:51:30 -0400 (EDT) Message-ID: <44918201.6010605@teaser.fr> Date: Thu, 15 Jun 2006 11:51:29 -0400 From: Hubert Figuiere User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: Matthias Clasen Subject: Re: GTK+ 2.10, the endgame References: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> In-Reply-To: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.54 tagged_above=-999 required=2 tests=[AWL=0.059, BAYES_00=-2.599] X-Spam-Score: -2.54 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 15:52:14 -0000 Matthias Clasen wrote: > I want to have GTK+ 2.10 ready at or immediately after GUADEC. Can somebody summarize the Mac port status? Hub From tristan.van.berkom@gmail.com Thu Jun 15 12:44:57 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 0A0273B05DC for ; Thu, 15 Jun 2006 12:44:57 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23203-02 for ; Thu, 15 Jun 2006 12:44:56 -0400 (EDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.200]) by menubar.gnome.org (Postfix) with ESMTP id 0AD9C3B007F for ; Thu, 15 Jun 2006 12:44:55 -0400 (EDT) Received: by wx-out-0102.google.com with SMTP id i30so312681wxd for ; Thu, 15 Jun 2006 09:44:14 -0700 (PDT) Received: by 10.70.100.8 with SMTP id x8mr2494520wxb; Thu, 15 Jun 2006 09:44:14 -0700 (PDT) Received: from ?66.48.170.37? ( [66.48.170.37]) by mx.gmail.com with ESMTP id i39sm1649326wxd.2006.06.15.09.44.12; Thu, 15 Jun 2006 09:44:14 -0700 (PDT) Message-ID: <44919246.8060301@gnome.org> Date: Thu, 15 Jun 2006 13:00:54 -0400 User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Janik Subject: Re: GObject extension propose (GContainer) References: <200606151101.12868.ntd@users.sourceforge.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit From: Tristan Van Berkom X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.481 tagged_above=-999 required=2 tests=[AWL=-0.414, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=1.456, SPF_PASS=-0.001, TW_GT=0.077] X-Spam-Score: -1.481 X-Spam-Level: Cc: Gtk+ Developers X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 16:44:57 -0000 Tim Janik wrote: >On Thu, 15 Jun 2006, Fontana Nicola wrote: > > > >>Hi all, >> >>I'm a GObject based libraries (for UI purpose and not) user and I often need >>a generic container to derive my own types. In my opinion, I think this >>generic container must be included inside the GObject library ... it could >>be used by a lot of derived libraries providing a common approach. >> >>I published my solution - that is, what I am currently using - on >>sourceforge. >> >>http://sourceforge.net/projects/gcontainer/ >> >>Is it a good idea? Is something planned in this direction? Am I totally >>wrong? >> >>I need feedbacks ... >> >> As a side note... I've been working on container --> child relationships and honing them down inside the glade builder... objects may for example have object delagates that are "owned" and in turn may "own" other delagates... this is all functional with libglade facilities and the future gtk builder also (from the design as of yet...)... this concept of "types of container relationships" is also usefull for GtkMenuShell --> GtkMenu for example (not just any GtkWidget can be added to a menushell). All of that just to say... I cannot count the times I've thought to myself that GtkContainer should really just be GContainerIface, and implemented by whatever interested objects that want to parent other objects... I think that what we need is not really "yet another container api", but a container api that is a unified front for generic handling of the GTK object hierarchy at runtime. Cheers, -Tristan From federico@ximian.com Thu Jun 15 12:56:13 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 0DAD63B03FF for ; Thu, 15 Jun 2006 12:56:13 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23665-06 for ; Thu, 15 Jun 2006 12:56:06 -0400 (EDT) Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) by menubar.gnome.org (Postfix) with ESMTP id 688823B0613 for ; Thu, 15 Jun 2006 12:56:05 -0400 (EDT) Received: (qmail 25104 invoked from network); 15 Jun 2006 16:54:53 -0000 Received: from localhost (HELO 164-99-120-38.boston.ximian.com) (127.0.0.1) by localhost with SMTP; 15 Jun 2006 16:54:53 -0000 Subject: Re: GTK+ 2.10, the endgame From: Federico Mena Quintero To: Matthias Clasen In-Reply-To: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> References: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> Content-Type: text/plain Date: Thu, 15 Jun 2006 11:50:29 -0500 Message-Id: <1150390229.17566.191.camel@cacharro.xalalinux.org> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.575 tagged_above=-999 required=2 tests=[AWL=0.024, BAYES_00=-2.599] X-Spam-Score: -2.575 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 16:56:13 -0000 On Thu, 2006-06-15 at 09:56 -0400, Matthias Clasen wrote: > Therefore, I want to consider 2.9.3 api frozen, and take a > look at what still needs to happen before 2.10. Here are some > things I personally would like get worked on (not sure > how much time I can free to look into these myself): > > - I think the async filechooser conversion has caused some > regressions, I noticed that .hidden support seems broken > and autocompletion also behaved badly for me recently. Yes, it's quite broken at the moment. I don't think we can do any more productive debugging (fixing something breaks something else) until we have a good set of automated tests for the basic behaviors. > - There is a number of FIXMEs and unimplemented bits in > the print code. > > - The print backends need a careful look wrt to memory leaks > and error reporting. I'm rather worried of declaring the printing API as stable and just unleashing it to the world. Is any software *really* using it? Does it contemplate things like - sites with thousands of printers - sites which want to lock-down certain printers - color management for apps that need it > Another thing I have slacked off about is organizing a GTK+ > team meeting at GUADEC. So, who of the GTK+ team is there > and at what times ? Should we try to find a free hour during > the core days, or does everybody stay for the after hours ? > If so, it may be easier to do a team meeting on Thursday... I'll be there since Sunday morning. Thursday is the Advisory Board meeting, so I'm afraid I won't have that day free for the GTK+ meeeting. Federico From mclasen@redhat.com Thu Jun 15 13:15:33 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id BC2163B0187 for ; Thu, 15 Jun 2006 13:15:33 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24531-03 for ; Thu, 15 Jun 2006 13:15:29 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id DCC933B0227 for ; Thu, 15 Jun 2006 13:15:28 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5FHDjVa014384; Thu, 15 Jun 2006 13:13:45 -0400 Received: from lacrosse.corp.redhat.com (lacrosse.corp.redhat.com [172.16.52.154]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5FHDjmo017834; Thu, 15 Jun 2006 13:13:45 -0400 Received: from [172.16.83.98] (dhcp83-98.boston.redhat.com [172.16.83.98]) by lacrosse.corp.redhat.com (8.12.11.20060308/8.11.6) with ESMTP id k5FHDjGC025752; Thu, 15 Jun 2006 13:13:45 -0400 Subject: Re: GTK+ 2.10, the endgame From: Matthias Clasen To: Federico Mena Quintero In-Reply-To: <1150390229.17566.191.camel@cacharro.xalalinux.org> References: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> <1150390229.17566.191.camel@cacharro.xalalinux.org> Content-Type: text/plain Organization: Red Hat Date: Thu, 15 Jun 2006 13:15:37 -0400 Message-Id: <1150391737.3187.33.camel@dhcp83-98.boston.redhat.com> Mime-Version: 1.0 X-Mailer: Evolution 2.7.3 (2.7.3-2) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.542 tagged_above=-999 required=2 tests=[AWL=0.059, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.542 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 17:15:33 -0000 On Thu, 2006-06-15 at 11:50 -0500, Federico Mena Quintero wrote: > On Thu, 2006-06-15 at 09:56 -0400, Matthias Clasen wrote: > > > Therefore, I want to consider 2.9.3 api frozen, and take a > > look at what still needs to happen before 2.10. Here are some > > things I personally would like get worked on (not sure > > how much time I can free to look into these myself): > > > > - I think the async filechooser conversion has caused some > > regressions, I noticed that .hidden support seems broken > > and autocompletion also behaved badly for me recently. > > Yes, it's quite broken at the moment. I don't think we can do any more > productive debugging (fixing something breaks something else) until we > have a good set of automated tests for the basic behaviors. Quite unfortunate. We spent too much time working on finetuning the filechooser behaviour to leave it broken now... > > - There is a number of FIXMEs and unimplemented bits in > > the print code. > > > > - The print backends need a careful look wrt to memory leaks > > and error reporting. > > I'm rather worried of declaring the printing API as stable and just > unleashing it to the world. Is any software *really* using it? Does it > contemplate things like Typical chicken and egg problem that won't be solved by keeping it unreleased for another year. There is no way to get any software _really_ using it without releasing it first. We got quite a bit of feedback from people looking at porting real apps to it (e.g gedit, OOo and epiphany), so it is not as if we release it straight from the whiteboard. > - sites with thousands of printers > > - sites which want to lock-down certain printers > > - color management for apps that need it No doubt that we may have to add new api in 2.12 to accomodate things like this, but all of these are special cases. From muntyan@tamu.edu Thu Jun 15 15:05:44 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 9364F3B0605 for ; Thu, 15 Jun 2006 15:05:44 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28754-04 for ; Thu, 15 Jun 2006 15:05:41 -0400 (EDT) Received: from smtp103.vzn.mail.mud.yahoo.com (smtp103.vzn.mail.mud.yahoo.com [68.142.203.47]) by menubar.gnome.org (Postfix) with SMTP id 568873B05C3 for ; Thu, 15 Jun 2006 15:05:40 -0400 (EDT) Received: (qmail 34334 invoked from network); 15 Jun 2006 19:05:00 -0000 Received: from unknown (HELO ?192.168.3.9?) (muntyan@verizon.net@71.113.224.59 with plain) by smtp103.vzn.mail.mud.yahoo.com with SMTP; 15 Jun 2006 19:04:59 -0000 Message-ID: <4491AF5A.2050702@tamu.edu> Date: Thu, 15 Jun 2006 14:04:58 -0500 From: Yevgen Muntyan User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20060216 Debian/1.7.12-1.1ubuntu2 X-Accept-Language: en MIME-Version: 1.0 To: GTK Devel List Subject: Printing and blocking ui Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.552 tagged_above=-999 required=2 tests=[AWL=0.047, BAYES_00=-2.599] X-Spam-Score: -2.552 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 19:05:44 -0000 Hi there, I print a text document from GtkTextView here. There is a problem with pagination: pagination is potentially slow, so some sort of progress dialog should be shown during it. From the other hand, the text buffer must not be modified during pagination. How to solve it? Should I show my own modal dialog and make sure user doesn't modify the buffer, or GtkPrintOperation can take care of it? Actually, it would be good to ensure printing blocks the text widget too, since in this case it wouldn't be necessary to calculate and store all the pango layouts in begin-print. Maybe just show a modal dialog between begin-print and end-print. Thanks, Yevgen From richard@imendio.com Thu Jun 15 15:08:15 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C90B13B02BF for ; Thu, 15 Jun 2006 15:08:15 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28754-07 for ; Thu, 15 Jun 2006 15:08:14 -0400 (EDT) Received: from holken.mikan.net (holken.mikan.net [83.145.56.183]) by menubar.gnome.org (Postfix) with ESMTP id 47EFB3B018C for ; Thu, 15 Jun 2006 15:08:14 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by holken.mikan.net (Postfix) with ESMTP id 418C111EB4; Thu, 15 Jun 2006 21:07:02 +0200 (CEST) Received: from holken.mikan.net ([127.0.0.1]) by localhost (holken.mikan.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04160-07; Thu, 15 Jun 2006 21:06:58 +0200 (CEST) Received: from [192.168.100.5] (c83-248-134-21.bredband.comhem.se [83.248.134.21]) by holken.mikan.net (Postfix) with ESMTP id E679E1459D; Thu, 15 Jun 2006 21:06:57 +0200 (CEST) Message-ID: <4491AFD0.5000408@imendio.com> Date: Thu, 15 Jun 2006 21:06:56 +0200 From: Richard Hult Organization: Imendio AB User-Agent: Thunderbird 1.5.0.4 (Macintosh/20060530) MIME-Version: 1.0 To: Hubert Figuiere Subject: Re: GTK+ 2.10, the endgame References: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> <44918201.6010605@teaser.fr> In-Reply-To: <44918201.6010605@teaser.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at holken.mikan.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.543 tagged_above=-999 required=2 tests=[AWL=0.056, BAYES_00=-2.599] X-Spam-Score: -2.543 X-Spam-Level: Cc: gtk-devel-list@gnome.org, Matthias Clasen X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 19:08:16 -0000 Hubert Figuiere skrev: > Matthias Clasen wrote: >> I want to have GTK+ 2.10 ready at or immediately after GUADEC. > > Can somebody summarize the Mac port status? The basic functionality is implemented and what's next in the pipeline is bug fixing, and after that looking into tighter integration with the platform in various areas. /Richard From muntyan@tamu.edu Thu Jun 15 15:12:58 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 9FC7E3B063D for ; Thu, 15 Jun 2006 15:12:58 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29079-06 for ; Thu, 15 Jun 2006 15:12:57 -0400 (EDT) Received: from smtp101.vzn.mail.mud.yahoo.com (smtp101.vzn.mail.mud.yahoo.com [68.142.203.45]) by menubar.gnome.org (Postfix) with SMTP id E72693B0613 for ; Thu, 15 Jun 2006 15:12:56 -0400 (EDT) Received: (qmail 97288 invoked from network); 15 Jun 2006 19:11:44 -0000 Received: from unknown (HELO ?192.168.3.9?) (muntyan@verizon.net@71.113.224.59 with plain) by smtp101.vzn.mail.mud.yahoo.com with SMTP; 15 Jun 2006 19:11:43 -0000 Message-ID: <4491B0EE.3040900@tamu.edu> Date: Thu, 15 Jun 2006 14:11:42 -0500 From: Yevgen Muntyan User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20060216 Debian/1.7.12-1.1ubuntu2 X-Accept-Language: en MIME-Version: 1.0 To: gtk-devel-list@gnome.org Subject: Re: GTK+ 2.10, the endgame References: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> <1150390229.17566.191.camel@cacharro.xalalinux.org> In-Reply-To: <1150390229.17566.191.camel@cacharro.xalalinux.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.514 tagged_above=-999 required=2 tests=[AWL=0.008, BAYES_00=-2.599, TW_GT=0.077] X-Spam-Score: -2.514 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 19:12:58 -0000 Federico Mena Quintero wrote: >On Thu, 2006-06-15 at 09:56 -0400, Matthias Clasen wrote: > > >>- The print backends need a careful look wrt to memory leaks >> and error reporting. >> >> > >I'm rather worried of declaring the printing API as stable and just >unleashing it to the world. Is any software *really* using it? > > Yes, there is software which is going to use gtk printing as soon as gtk-2.10 is released. And there will be much more when gtk has printing. Just think for a moment about gtk-but-not-gnome applications (win32 comes to mind too). > - sites with thousands of printers > > - sites which want to lock-down certain printers > > - color management for apps that need it > > If gtk can print to a single user's printer, it's already worth releasing. Again, there are applications which do not have printing, because they can't use gnomeprint, and developers don't feel like implement their own printing while gtk is going to get it. IMHO, etc., you know. Best regards, Yevgen From gnome-gtk-devel-list@m.gmane.org Thu Jun 15 16:40:15 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 2360D3B00D0 for ; Thu, 15 Jun 2006 16:40:15 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32360-05 for ; Thu, 15 Jun 2006 16:40:13 -0400 (EDT) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by menubar.gnome.org (Postfix) with ESMTP id 3B9113B0237 for ; Thu, 15 Jun 2006 16:40:13 -0400 (EDT) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1FqydG-0004Vk-6i for gtk-devel-list@gnome.org; Thu, 15 Jun 2006 22:40:02 +0200 Received: from cpe0004e2d9f884-cm0013718690da.cpe.net.cable.rogers.com ([70.24.212.140]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 15 Jun 2006 22:40:02 +0200 Received: from jasonspiro4+news by cpe0004e2d9f884-cm0013718690da.cpe.net.cable.rogers.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 15 Jun 2006 22:40:02 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gtk-devel-list@gnome.org From: Jason Spiro Subject: Imagine: what if points in Bugzilla had a significant effect? Date: Thu, 15 Jun 2006 19:15:34 +0000 (UTC) Lines: 15 Message-ID: X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cpe0004e2d9f884-cm0013718690da.cpe.net.cable.rogers.com User-Agent: slrn/0.9.8.1pl1 (Debian) Sender: news X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.601 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.601 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 20:40:15 -0000 Imagine: what if points did something in Bugzilla, like, the more points you have, the more votes you get? I think this would encourage people to file more bug reports, both good bug reports and not-so-good ones. Would that be a net gain or a net loss for GTK+? Regards, Jason Spiro -- Jason Spiro: computer consulting with a smile. Specializing in Linux: Red Hat AS / ES, Debian, and others. Serving homes and companies globally via remote access tools. Fair rates. Just email jasonspiro4@gmail.com or call Skype ID jasonspiro. From murrayc@murrayc.com Fri Jun 16 04:53:13 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id D68413B0007 for ; Fri, 16 Jun 2006 04:53:12 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23115-03 for ; Fri, 16 Jun 2006 04:53:08 -0400 (EDT) Received: from swarthymail-a5.dreamhost.com (sd-green-bigip-176.dreamhost.com [208.97.132.176]) by menubar.gnome.org (Postfix) with ESMTP id 7FA303B006C for ; Fri, 16 Jun 2006 04:53:08 -0400 (EDT) Received: from noname (p5497E1BF.dip.t-dialin.net [84.151.225.191]) by swarthymail-a5.dreamhost.com (Postfix) with ESMTP id 69FE4109E8B; Fri, 16 Jun 2006 01:52:14 -0700 (PDT) Subject: Re: GTK+ 2.10, the endgame From: Murray Cumming To: Matthias Clasen In-Reply-To: <1150391737.3187.33.camel@dhcp83-98.boston.redhat.com> References: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> <1150390229.17566.191.camel@cacharro.xalalinux.org> <1150391737.3187.33.camel@dhcp83-98.boston.redhat.com> Content-Type: text/plain Date: Fri, 16 Jun 2006 10:52:10 +0200 Message-Id: <1150447930.5806.4.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.481 tagged_above=-999 required=2 tests=[AWL=0.118, BAYES_00=-2.599] X-Spam-Score: -2.481 X-Spam-Level: Cc: Federico Mena Quintero , gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2006 08:53:13 -0000 I'm also concerned about the recent files stuff. Do we now have UIManager integration of that? -- Murray Cumming murrayc@murrayc.com www.murrayc.com www.openismus.com From murrayc@murrayc.com Fri Jun 16 05:06:58 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id A76AC3B0076 for ; Fri, 16 Jun 2006 05:06:58 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23550-01 for ; Fri, 16 Jun 2006 05:06:57 -0400 (EDT) Received: from kungfu.dreamhost.com (kungfu.dreamhost.com [66.33.216.126]) by menubar.gnome.org (Postfix) with ESMTP id D099D3B006B for ; Fri, 16 Jun 2006 05:06:57 -0400 (EDT) Received: from swarthymail-a4.dreamhost.com (sd-green-bigip-62.dreamhost.com [208.97.132.62]) by kungfu.dreamhost.com (Postfix) with ESMTP id 708B51F0265 for ; Fri, 16 Jun 2006 01:28:47 -0700 (PDT) Received: from noname (p5497E1BF.dip.t-dialin.net [84.151.225.191]) by swarthymail-a4.dreamhost.com (Postfix) with ESMTP id 0D51A129A83; Fri, 16 Jun 2006 01:28:10 -0700 (PDT) Subject: Re: GTK+ 2.10, the endgame From: Murray Cumming To: Matthias Clasen In-Reply-To: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> References: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> Content-Type: text/plain Date: Thu, 15 Jun 2006 23:20:27 +0200 Message-Id: <1150406427.30234.1.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.068 tagged_above=-999 required=2 tests=[AWL=-0.296, BAYES_00=-2.599, DATE_IN_PAST_06_12=0.827] X-Spam-Score: -2.068 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2006 09:06:58 -0000 On Thu, 2006-06-15 at 09:56 -0400, Matthias Clasen wrote: > I want to have GTK+ 2.10 ready at or immediately after GUADEC. [snip] I'd rather it was after rather than before. That gives us just a little more time to get everything wrapped quickly for gtkmm, which might show some small problems that need fixing. Maybe I haven't been paying attention, but I'm surprised (again) by the freeze announcement. -- Murray Cumming murrayc@murrayc.com www.murrayc.com www.openismus.com From mgiannakidis@gmail.com Thu Jun 15 11:24:35 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id B7BE73B0211 for ; Thu, 15 Jun 2006 11:24:35 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19150-09 for ; Thu, 15 Jun 2006 11:24:34 -0400 (EDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.188]) by menubar.gnome.org (Postfix) with ESMTP id AAD863B04FC for ; Thu, 15 Jun 2006 11:24:33 -0400 (EDT) Received: by nf-out-0910.google.com with SMTP id c2so90382nfe for ; Thu, 15 Jun 2006 08:23:41 -0700 (PDT) Received: by 10.48.47.15 with SMTP id u15mr674329nfu; Thu, 15 Jun 2006 08:23:39 -0700 (PDT) Received: from ?213.140.137.120? ( [213.140.137.120]) by mx.gmail.com with ESMTP id n22sm2029009nfc.2006.06.15.08.23.38; Thu, 15 Jun 2006 08:23:39 -0700 (PDT) From: Michalis Giannakidis To: gtk-devel-list@gnome.org Subject: gslice allocator: general impresions. Date: Thu, 15 Jun 2006 18:27:45 +0300 User-Agent: KMail/1.8.3 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200606151827.45477.mgiannakidis@gmail.com> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.6 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.6 X-Spam-Level: X-Mailman-Approved-At: Fri, 16 Jun 2006 05:29:57 -0400 X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 15:24:35 -0000 Dear Glib team, I have recently used the glib-glice allocator in a very malloc intensive application, and I would like to share a few observations I made, with you. The typical size I send to g_slice_alloc is 20 and 76 bytes (32 bit build). The total memory consumed by my application has decreased - which is great! However it `seems' to me, that this decrease in size is larger for the 64bit build compared to the 32bit build. (I have modified gslice to align a chunk to its own size so that I don't have unused memory between chunks eg: request 20 and get 24...) In my application now I use both g_slice_alloc and malloc.Testing the new allocator in linux I came accross the following: After using g_slice_alloc to alloc a great amount of data (eg 1500mb), each of them being 20 or 76 bytes in size, subsequent calls to malloc(8*1024) or similar sizes take much longer (the allocation does _not_ got to the swap). Also if I chage the min_page_size from 128 to 4096, then the subsequent calls to malloc(8*1024) or similar sizes take even longer. It takes for ever in the 64 bit build! Moreover, even with min_page_size set to 128, the calls to malloc take for ever on a Linux 2.4.20 glibc-2.2.4(glibc up to 2.2.5 has a broken posix_memalign so I fallback to memalign). In all of the cases above, malloc responds much faster when the gslice allocator is turned off. I know I should be providing sample code and test programms here to back up my observations. I also understand that I should provide execution times instead of just stating that the calls to malloc take for ever. I would like to ask you, if there are any known issues in mixing gslice and malloc calls in malloc intensive applications. Any suggested readings would be most welcome. Regards Michalis -- Michalis Giannakidis From timj@gtk.org Fri Jun 16 07:30:05 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id EEDE23B0011 for ; Fri, 16 Jun 2006 07:30:04 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26976-06 for ; Fri, 16 Jun 2006 07:30:04 -0400 (EDT) Received: from holken.mikan.net (holken.mikan.net [83.145.56.183]) by menubar.gnome.org (Postfix) with ESMTP id DA78D3B0007 for ; Fri, 16 Jun 2006 07:30:03 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by holken.mikan.net (Postfix) with ESMTP id BDFA43352B0; Fri, 16 Jun 2006 13:28:54 +0200 (CEST) Received: from holken.mikan.net ([127.0.0.1]) by localhost (holken.mikan.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29662-08; Fri, 16 Jun 2006 13:28:48 +0200 (CEST) Received: from birnet.org (d003098.adsl.hansenet.de [80.171.3.98]) by holken.mikan.net (Postfix) with ESMTP id DFB2633525A; Fri, 16 Jun 2006 13:28:47 +0200 (CEST) Received: from master.birnet.private (localhost.localdomain [127.0.0.1]) by birnet.org (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k5GBSi9S008066 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 16 Jun 2006 13:28:44 +0200 Received: (from timj@localhost) by master.birnet.private (8.13.4/8.13.4/Submit) id k5GBSZMj008064; Fri, 16 Jun 2006 13:28:35 +0200 Date: Fri, 16 Jun 2006 13:28:35 +0200 (CEST) From: Tim Janik X-X-Sender: timj@master.birnet.private To: "Gustavo J. A. M. Carneiro" Subject: Re: GObject extension propose (GContainer) In-Reply-To: <1150456522.5305.12.camel@localhost.localdomain> Message-ID: References: <200606151101.12868.ntd@users.sourceforge.net> <44919246.8060301@gnome.org> <1150456522.5305.12.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="656239-2144330416-1150457315=:7955" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at holken.mikan.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.677 tagged_above=-999 required=2 tests=[AWL=-0.669, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, RCVD_IN_SORBS_WEB=1.456] X-Spam-Score: -1.677 X-Spam-Level: Cc: Gtk+ Developers X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2006 11:30:05 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --656239-2144330416-1150457315=:7955 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Fri, 16 Jun 2006, Gustavo J. A. M. Carneiro wrote: > Qui, 2006-06-15 =E0s 13:00 -0400, Tristan Van Berkom escreveu: >> All of that just to say... I cannot count the times I've thought to >> myself that >> GtkContainer should really just be GContainerIface, and implemented by >> whatever interested objects that want to parent other objects... > > That's interesting, but I wonder what is the runtime penalty of > interface lookup compared to normal class structure lookup? Is it > really OK to use an interface for this, or is it better just to add a > new virtual methods to the GObject class? the lookup penalties are negligible. type node/class lookups and is_a checks are O(1); interface class lookups and conforms_to checks are O(ld(N)), where N is the number of interfaces a type node conforms to. > Gustavo J. A. M. Carneiro --- ciaoTJ --656239-2144330416-1150457315=:7955-- From gjc@inescporto.pt Fri Jun 16 07:34:21 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 74BCC3B000B for ; Fri, 16 Jun 2006 07:34:21 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26977-07 for ; Fri, 16 Jun 2006 07:34:20 -0400 (EDT) Received: from animal.inescn.pt (correio.inescn.pt [194.117.24.9]) by menubar.gnome.org (Postfix) with ESMTP id 5B7183B0011 for ; Fri, 16 Jun 2006 07:34:19 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by animal.inescn.pt (8.13.6/8.13.6/7) with ESMTP id k5GBFdIJ028014; Fri, 16 Jun 2006 12:15:39 +0100 (WEST) Received: from pong.inescporto.pt (pong.inescn.pt [194.117.26.74]) by animal.inescn.pt (8.13.6/8.13.6/5) with ESMTP id k5GBFT0a027999; Fri, 16 Jun 2006 12:15:29 +0100 (WEST) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by pong.inescporto.pt (Postfix) with ESMTP id AE13A39D8; Fri, 16 Jun 2006 12:12:16 +0100 (WEST) Subject: Re: GObject extension propose (GContainer) From: "Gustavo J. A. M. Carneiro" To: Tristan Van Berkom In-Reply-To: <44919246.8060301@gnome.org> References: <200606151101.12868.ntd@users.sourceforge.net> <44919246.8060301@gnome.org> Content-Type: text/plain; charset=UTF-8 Date: Fri, 16 Jun 2006 12:15:21 +0100 Message-Id: <1150456522.5305.12.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at inescporto.pt X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.39 tagged_above=-999 required=2 tests=[AWL=-0.002, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, SPF_PASS=-0.001, TW_GT=0.077] X-Spam-Score: -2.39 X-Spam-Level: Cc: Gtk+ Developers , Tim Janik X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2006 11:34:21 -0000 Qui, 2006-06-15 s 13:00 -0400, Tristan Van Berkom escreveu: > Tim Janik wrote: > > >On Thu, 15 Jun 2006, Fontana Nicola wrote: > > > > > > > >>Hi all, > >> > >>I'm a GObject based libraries (for UI purpose and not) user and I often need > >>a generic container to derive my own types. In my opinion, I think this > >>generic container must be included inside the GObject library ... it could > >>be used by a lot of derived libraries providing a common approach. > >> > >>I published my solution - that is, what I am currently using - on > >>sourceforge. > >> > >>http://sourceforge.net/projects/gcontainer/ > >> > >>Is it a good idea? Is something planned in this direction? Am I totally > >>wrong? > >> > >>I need feedbacks ... > >> > >> > As a side note... I've been working on container --> child relationships and > honing them down inside the glade builder... objects may for example have > object delagates that are "owned" and in turn may "own" other delagates... > this is all functional with libglade facilities and the future gtk > builder also > (from the design as of yet...)... this concept of "types of container > relationships" > is also usefull for GtkMenuShell --> GtkMenu for example (not just any > GtkWidget > can be added to a menushell). > > All of that just to say... I cannot count the times I've thought to > myself that > GtkContainer should really just be GContainerIface, and implemented by > whatever interested objects that want to parent other objects... That's interesting, but I wonder what is the runtime penalty of interface lookup compared to normal class structure lookup? Is it really OK to use an interface for this, or is it better just to add a new virtual methods to the GObject class? > I think > that what we need is not really "yet another container api", but a container > api that is a unified front for generic handling of the GTK object > hierarchy at runtime. Actually, for the python language bindings we could use a generic GObject container interface. See http://bugzilla.gnome.org/show_bug.cgi?id=303266 Regards. -- Gustavo J. A. M. Carneiro The universe is always one step beyond logic From alan@clueserver.org Fri Jun 16 12:57:14 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 502C63B0336 for ; Fri, 16 Jun 2006 12:57:14 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06317-07 for ; Fri, 16 Jun 2006 12:57:08 -0400 (EDT) Received: from clueserver.org (216-99-213-120.dsl.aracnet.com [216.99.213.120]) by menubar.gnome.org (Postfix) with ESMTP id 7529F3B041B for ; Fri, 16 Jun 2006 12:54:18 -0400 (EDT) Received: by clueserver.org (Postfix, from userid 500) id 2985BF50BE2; Fri, 16 Jun 2006 09:53:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by clueserver.org (Postfix) with ESMTP id 26461F50BE1; Fri, 16 Jun 2006 09:53:44 -0700 (PDT) Date: Fri, 16 Jun 2006 09:53:44 -0700 (PDT) From: alan X-X-Sender: alan@blackbox.fnordora.org To: Jason Spiro Subject: Re: Imagine: what if points in Bugzilla had a significant effect? In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.45 tagged_above=-999 required=2 tests=[AWL=0.014, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.45 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2006 16:57:14 -0000 On Thu, 15 Jun 2006, Jason Spiro wrote: > Imagine: what if points did something in Bugzilla, like, the more points > you have, the more votes you get? Slashzilla? -- "Waiter! This lambchop tastes like an old sock!" - Sheri Lewis From ntd@users.sourceforge.net Fri Jun 16 14:08:36 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 39BE13B03E1 for ; Fri, 16 Jun 2006 14:08:36 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11017-04 for ; Fri, 16 Jun 2006 14:08:34 -0400 (EDT) Received: from mailout02.albacom.net (mailout02.albacom.net [217.220.34.14]) by menubar.gnome.org (Postfix) with SMTP id E2E913B00E4 for ; Fri, 16 Jun 2006 14:08:33 -0400 (EDT) Received: (qmail 21669 invoked by uid 507); 16 Jun 2006 18:08:08 -0000 Received: from ntd@users.sourceforge.net by mailout02.albacom.net with qmail-scanner (spamassassin: ???. Clear:RC:1(217.221.76.9):SA:0(0.0/15.0):. Processed in 0.841774 secs); 16 Jun 2006 18:08:08 -0000 Received: from unknown (HELO sviluppo.internet.local) (postmaster@effe-gi.it@217.221.76.9) by mailout02.albacom.net with SMTP; 16 Jun 2006 18:08:07 -0000 From: Fontana Nicola Organization: Elettronica EFFE-GI s.n.c. To: Tim Janik Subject: Re: GObject extension propose (GContainer) Date: Fri, 16 Jun 2006 20:44:11 +0000 User-Agent: KMail/1.9.1 References: <200606151101.12868.ntd@users.sourceforge.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200606162044.11716.ntd@users.sourceforge.net> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.526 tagged_above=-999 required=2 tests=[AWL=-0.004, BAYES_00=-2.599, TW_GT=0.077] X-Spam-Score: -2.526 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2006 18:08:36 -0000 > On Thu, 15 Jun 2006, Fontana Nicola wrote: > > Hi all, > > > > I'm a GObject based libraries (for UI purpose and not) user and I often > > need a generic container to derive my own types. In my opinion, I think > > this generic container must be included inside the GObject library ... it > > could be used by a lot of derived libraries providing a common approach. > > > > I published my solution - that is, what I am currently using - on > > sourceforge. > > > > http://sourceforge.net/projects/gcontainer/ > > > > Is it a good idea? Is something planned in this direction? Am I totally > > wrong? > > > > I need feedbacks ... > > hi. your gcontainer-1.0.0 looks like an interesting approach to me, but > i'm not sure it's generally good to put that into stock libgobject. > the main reason is that container needs are probably pretty variable > out there (i've come across at least 4 different gobject container > implementations in free software projects i'm woorking on) and that > both, making too little assumptions in the child/container interface > isn't going to be very helpful, albeit making too many has the > same problem. Some time ago I've started a communication library based on libgobject and I feeled the need of two things: a base object with floating reference and a container. After some time, I started an experimental cairo canvas and I had the same needs. In both cases, no gtk dependency was requested. Briefly, I'm not talking about a container that cover all needs and tastes but instead about "moving the GtkContainer logic and complexity" from gtk to gobject, something similar to what was done for GtkObject and its floating reference. I wrote gcontainer with this in mind (the GContainerable interface is "compatible" with GtkContainer and GChildable with GtkWidget). Anyway, my solution presents some serious problems: I'm misusing the interface to hide as much technical details as possible to the implementing objects. I know it is a huge task but consider this as an idea or a looooong term project: I don't think to be the only one with these needs. > > i guess we could add a link to your project from the libgobject docs > (it should probably have a Contrib section), for people possibly looking > for a GObject container implementation. that way, gcontainer-1.0.0 gets > a chance of being reused and maybe extended to something generally > usefull for GObject applications out there. > > > Nicola > > --- > ciaoTJ Of course I'll be glad to have a link in the gobject documentation. Thank you for your availability. Nicola From tristan.van.berkom@gmail.com Fri Jun 16 14:26:50 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id E38F43B0139 for ; Fri, 16 Jun 2006 14:26:49 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12245-08 for ; Fri, 16 Jun 2006 14:26:49 -0400 (EDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.197]) by menubar.gnome.org (Postfix) with ESMTP id DB55F3B0179 for ; Fri, 16 Jun 2006 14:26:48 -0400 (EDT) Received: by wx-out-0102.google.com with SMTP id i30so517779wxd for ; Fri, 16 Jun 2006 11:26:15 -0700 (PDT) Received: by 10.70.83.9 with SMTP id g9mr4369121wxb; Fri, 16 Jun 2006 11:20:03 -0700 (PDT) Received: from ?66.48.170.68? ( [66.48.170.68]) by mx.gmail.com with ESMTP id h39sm2692858wxd.2006.06.16.11.20.01; Fri, 16 Jun 2006 11:20:03 -0700 (PDT) Message-ID: <4492FA3C.5060106@gmail.com> Date: Fri, 16 Jun 2006 14:36:44 -0400 From: Tristan Van Berkom User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Fontana Nicola Subject: Re: GObject extension propose (GContainer) References: <200606151101.12868.ntd@users.sourceforge.net> <200606162044.11716.ntd@users.sourceforge.net> In-Reply-To: <200606162044.11716.ntd@users.sourceforge.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.497 tagged_above=-999 required=2 tests=[AWL=-0.353, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=1.456, SPF_PASS=-0.001] X-Spam-Score: -1.497 X-Spam-Level: Cc: gtk-devel-list@gnome.org, Tim Janik X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2006 18:26:50 -0000 Fontana Nicola wrote: [...] >I wrote gcontainer with this in mind (the GContainerable interface is >"compatible" with GtkContainer and GChildable with GtkWidget). Anyway, my >solution presents some serious problems: I'm misusing the interface to hide >as much technical details as possible to the implementing objects. > >I know it is a huge task but consider this as an idea or a looooong term >project: I don't think to be the only one with these needs. > > I think you may be overcomplicating things, if for example; the GContainerable or GContainerIface were implemented by GtkContainer; then nothing in GtkContainer derivatives would really have to change (unless the api was drasticly different... but I doubt that). Then this could be extended to other object sets and other needs without having to rewrite large pieces of code. Cheers, -Tristan From behdad.esfahbod@gmail.com Fri Jun 16 15:04:20 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 611EA3B00F8 for ; Fri, 16 Jun 2006 15:04:20 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15384-03 for ; Fri, 16 Jun 2006 15:04:18 -0400 (EDT) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.228]) by menubar.gnome.org (Postfix) with ESMTP id 566D33B007C for ; Fri, 16 Jun 2006 15:04:18 -0400 (EDT) Received: by wr-out-0506.google.com with SMTP id i4so618991wra for ; Fri, 16 Jun 2006 12:03:42 -0700 (PDT) Received: by 10.54.142.9 with SMTP id p9mr3126451wrd; Fri, 16 Jun 2006 11:57:25 -0700 (PDT) Received: from ?192.168.190.5? ( [72.136.156.47]) by mx.gmail.com with ESMTP id 10sm2200187wrl.2006.06.16.11.57.23; Fri, 16 Jun 2006 11:57:24 -0700 (PDT) Subject: Re: Imagine: what if points in Bugzilla had a significant effect? From: Behdad Esfahbod To: gtk-devel-list@gnome.org In-Reply-To: References: Content-Type: text/plain Date: Fri, 16 Jun 2006 14:57:22 -0400 Message-Id: <1150484242.15469.17.camel@home> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 (2.6.1-1.fc5.2) Content-Transfer-Encoding: 7bit Sender: Behdad Esfahbod X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.561 tagged_above=-999 required=2 tests=[AWL=-0.038, BAYES_00=-2.599, SPF_PASS=-0.001, TW_GT=0.077] X-Spam-Score: -2.561 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2006 19:04:20 -0000 On Thu, 2006-06-15 at 15:15 -0400, Jason Spiro wrote: > Imagine: what if points did something in Bugzilla, like, the more points > you have, the more votes you get? > > I think this would encourage people to file more bug reports, both good > bug reports and not-so-good ones. Would that be a net gain or a net loss > for GTK+? It has evolved to be like that already. The more points one has, the more he (or she, in the near future) respects bugs/comments from high-point others. Or at least that's been my experience. behdad > Regards, > Jason Spiro > > -- > Jason Spiro: computer consulting with a smile. > Specializing in Linux: Red Hat AS / ES, Debian, and others. > Serving homes and companies globally via remote access tools. Fair rates. > Just email jasonspiro4@gmail.com or call Skype ID jasonspiro. > > _______________________________________________ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-devel-list -- behdad http://behdad.org/ "Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill" -- Dan Bern, "New American Language" From grakic@devbase.net Fri Jun 16 16:12:39 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 7B9EC3B025A for ; Fri, 16 Jun 2006 16:12:39 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19416-03 for ; Fri, 16 Jun 2006 16:12:38 -0400 (EDT) Received: from mxout-04.mxes.net (mxout-04.mxes.net [205.237.194.35]) by menubar.gnome.org (Postfix) with ESMTP id 07A823B02B4 for ; Fri, 16 Jun 2006 16:12:37 -0400 (EDT) Received: from limun.local (unknown [87.116.163.93]) by smtp.mxes.net (Postfix) with ESMTP id C5307A3292; Fri, 16 Jun 2006 16:11:35 -0400 (EDT) Subject: Re: Imagine: what if points in Bugzilla had a significant effect? From: Goran Rakic To: Jason Spiro In-Reply-To: References: Content-Type: text/plain; charset=utf-8 Date: Fri, 16 Jun 2006 22:11:33 +0200 Message-Id: <1150488693.2273.3.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.6 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, SPF_HELO_PASS=-0.001] X-Spam-Score: -2.6 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2006 20:12:39 -0000 Lary Osterman has a nice writing on this topic titled "Measuring testers by test metrics doesn't." У čet, 15. 06 2006. у 19:15 +0000, Jason Spiro пише: > Imagine: what if points did something in Bugzilla, like, the more points > you have, the more votes you get? > > I think this would encourage people to file more bug reports, both good > bug reports and not-so-good ones. Would that be a net gain or a net loss > for GTK+? > > Regards, > Jason Spiro From ame1@extratech.com Fri Jun 16 17:02:33 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 2F9013B018C for ; Fri, 16 Jun 2006 17:02:33 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21327-05 for ; Fri, 16 Jun 2006 17:02:32 -0400 (EDT) Received: from portal2.extratech.com (portal.extratech.com [67.105.201.210]) by menubar.gnome.org (Postfix) with ESMTP id BB3BD3B01C8 for ; Fri, 16 Jun 2006 17:02:31 -0400 (EDT) Received: from zosma.extratech.com (zosma.extratech.com [192.168.0.41]) by portal2.extratech.com (8.12.11/8.12.11) with ESMTP id k5GL1Quq030485 for ; Fri, 16 Jun 2006 14:01:26 -0700 Subject: Re: GObject extension propose (GContainer) From: "Alan M. Evans" To: Gtk+ Developers In-Reply-To: References: <200606151101.12868.ntd@users.sourceforge.net> <44919246.8060301@gnome.org> <1150456522.5305.12.camel@localhost.localdomain> Content-Type: text/plain; charset=UTF-8 Message-Id: <1150491686.19405.355.camel@zosma.extratech.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 16 Jun 2006 14:01:26 -0700 Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV 0.86.1/1544/Fri Jun 16 02:19:15 2006 on portal2.extratech.com X-Virus-Status: Clean X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.556 tagged_above=-999 required=2 tests=[AWL=0.044, BAYES_00=-2.599] X-Spam-Score: -2.556 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2006 21:02:33 -0000 On Fri, 2006-06-16 at 04:28, Tim Janik wrote: > On Fri, 16 Jun 2006, Gustavo J. A. M. Carneiro wrote: > > > Qui, 2006-06-15 s 13:00 -0400, Tristan Van Berkom escreveu: > > >> All of that just to say... I cannot count the times I've thought to > >> myself that > >> GtkContainer should really just be GContainerIface, and implemented by > >> whatever interested objects that want to parent other objects... > > > > That's interesting, but I wonder what is the runtime penalty of > > interface lookup compared to normal class structure lookup? Is it > > really OK to use an interface for this, or is it better just to add a > > new virtual methods to the GObject class? > > the lookup penalties are negligible. > type node/class lookups and is_a checks are O(1); > interface class lookups and conforms_to checks are O(ld(N)), where > N is the number of interfaces a type node conforms to. Your assertion that the penalties are negligable is not really supported by your response, unless the constant is also known for both orders. From ebassi@gmail.com Fri Jun 16 20:14:03 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 3E95D3B069B for ; Fri, 16 Jun 2006 20:14:03 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28883-03 for ; Fri, 16 Jun 2006 20:14:00 -0400 (EDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.185]) by menubar.gnome.org (Postfix) with ESMTP id 969133B015A for ; Fri, 16 Jun 2006 20:13:59 -0400 (EDT) Received: by nf-out-0910.google.com with SMTP id c2so667512nfe for ; Fri, 16 Jun 2006 17:13:07 -0700 (PDT) Received: by 10.49.72.13 with SMTP id z13mr2277195nfk; Fri, 16 Jun 2006 17:05:51 -0700 (PDT) Received: from ?192.168.1.74? ( [86.136.65.180]) by mx.gmail.com with ESMTP id y23sm3836170nfb.2006.06.16.17.05.51; Fri, 16 Jun 2006 17:05:51 -0700 (PDT) Subject: Re: GTK+ 2.10, the endgame From: Emmanuele Bassi To: gtk-devel-list@gnome.org In-Reply-To: <1150447930.5806.4.camel@localhost.localdomain> References: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> <1150390229.17566.191.camel@cacharro.xalalinux.org> <1150391737.3187.33.camel@dhcp83-98.boston.redhat.com> <1150447930.5806.4.camel@localhost.localdomain> Content-Type: text/plain Date: Sat, 17 Jun 2006 01:05:50 +0100 Message-Id: <1150502750.2668.12.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.34 tagged_above=-999 required=2 tests=[AWL=0.260, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.34 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2006 00:14:03 -0000 Hi Murray, On Fri, 2006-06-16 at 10:52 +0200, Murray Cumming wrote: > I'm also concerned about the recent files stuff. Do we now have > UIManager integration of that? No, and I am to blame because I had less time to spend on fixing this issue. Mostly, I've been stuck on how to implement an action for both the menu and toolbars using the same tag. In the meantime, a nice and clean way to integrate the GtkRecentChooserMenu inside a GtkUIManager is to subclass GtkAction into a custom action that automatically adds a recent chooser menu to the menu item it creates, and use a placeholder in the UI definition (most applications using EggRecentViewUIManager already have that placeholder present). A working example is available here: http://www.gnome.org/~ebassi/test-uimanager.c The action code itself is one hundred lines long and can easily be hidden inside an helper file; it's approximately how GtkRecentAction would be implemented, anyway. I hereby give permission to do whatever you want to do with it. I understand that it's sub-optimal, and hopefully this should really go away once there's an action inside GTK. Ciao, Emmanuele. -- Emmanuele Bassi, E: ebassi@gmail.com W: http://www.emmanuelebassi.net B: http://log.emmanuelebassi.net From behdad.esfahbod@gmail.com Mon Jun 12 17:52:45 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 162C73B02CD for ; Mon, 12 Jun 2006 17:52:45 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00303-05 for ; Mon, 12 Jun 2006 17:52:43 -0400 (EDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.206]) by menubar.gnome.org (Postfix) with ESMTP id 643023B0010 for ; Mon, 12 Jun 2006 17:52:43 -0400 (EDT) Received: by wx-out-0102.google.com with SMTP id h26so956965wxd for ; Mon, 12 Jun 2006 14:51:27 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:subject:from:to:content-type:date:message-id:mime-version:x-mailer:sender; b=HkVpdki0/g3XkGcHUm613LiH99RNWp83QpOiB04twtI9/oyY5QJs7xgUW9ugXUYWTW0FQESua3SiFes9GpwcHFnulMB+jmu6Frg1gjSTz94Z0WNKazKYJCx/0yCrKVvi+sIhO9793kd+R7hBbKFWLBqlIyo5yetvED1gx6HIjnc= Received: by 10.70.36.1 with SMTP id j1mr6891335wxj; Mon, 12 Jun 2006 14:44:52 -0700 (PDT) Received: from to-dhcp26.toronto.redhat.com ( [63.250.163.171]) by mx.gmail.com with ESMTP id h18sm3879342wxd.2006.06.12.14.44.50; Mon, 12 Jun 2006 14:44:51 -0700 (PDT) Subject: Pango-1.13.2 released [unstable] From: Behdad Esfahbod To: Pango Release Lists , gtk-app-devel-list@gnome.org, gtk-devel-list@gnome.org, gtk-i18n-list@gnome.org, gtk-list@gnome.org Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-HZBsNn3KdPR3jVVwB9gO" Date: Mon, 12 Jun 2006 17:44:37 -0400 Message-Id: <1150148678.10765.8.camel@home> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 (2.6.1-1.fc5.2) Sender: Behdad Esfahbod X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.6 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.6 X-Spam-Level: X-Mailman-Approved-At: Fri, 16 Jun 2006 05:27:53 -0400 X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2006 21:52:45 -0000 --=-HZBsNn3KdPR3jVVwB9gO Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Pango-1.13.2 is now available for download at: ftp://ftp.gtk.org/pub/gtk/v2.11/ or http://download.gnome.org/sources/pango/1.13/ 28a6ea9d43c4cd398e7352032f775401 pango-1.13.2.tar.bz2 17d78473c05fece044c6a3b44519b61f pango-1.13.2.tar.gz This is a development release leading up to Pango-1.14.0, which will be released just in time for GNOME-2.16. Notes: * This is unstable development release. While it has had fairly extensive testing, there are likely bugs remaining to be found. This release should not be used in production. * Installing this version will overwrite your existing copy of Pango-1.12. If you have problems, you'll need to reinstall Pango-1.12.x * Bugs should be reported to http://bugzilla.gnome.org. About Pango =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Pango is a library for layout and rendering of text, with an emphasis on internationalization. Pango can be used anywhere that text layout is needed, though most of the work on Pango so far has been done in the context of the GTK+ widget toolkit. Pango forms the core of text and font handling for GTK+-2.x. Pango is designed to be modular; the core Pango layout engine can be used with different font backends. There are three basic backends, with multiple options for rendering with each. - Client side fonts using the FreeType and fontconfig libraries. Rendering can be with with Cairo or Xft libraries, or directly to an in-memory buffer with no additional libraries. - Native fonts on Microsoft Windows. (Optionally using Uniscribe for complex-text handling). Rendering can be done via Cairo or directly using the native Win32 API. - Native fonts on MacOS X, rendering via Cairo. The integration of Pango with Cairo (http://cairographics.org) provides a complete solution with high quality text handling and graphics rendering. Dynamically loaded modules then handle text layout for particular combinations of script and font backend. Pango ships with a wide selection of modules, including modules for Hebrew, Arabic, Hangul, Thai, and a number of Indic scripts. Virtually all of the world's major scripts are supported. As well as the low level layout rendering routines, Pango includes PangoLayout, a high level driver for laying out entire blocks of text, and routines to assist in editing internationalized text. More information about Pango is available from http://www.pango.org/. Pango 1.13.2 depends on version 2.10.0 or newer of the GLib library and version 1.1.2 or newer of the cairo library (if the cairo backend is desired); more information about GLib and cairo can be found at http://www.gtk.org/ and http://cairographics.org/ respectively. Overview of changes between 1.13.1 and 1.13.2 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D * Improved hexbox drawing, and font metrics calculations. * Synthesize italic variants on win32 [Hans Breuer] * New public API: - pango_cairo_show_error_underline - pango_cairo_error_underline_path - pango_font_describe_with_absolute_size * Misc fixes. * Bugs fixed in this release: Bug 326960 =E2=80=93 hex box drawing for win32 and atsui backends of cairo Bug 343717 =E2=80=93 License information in unclear. Bug 343355 =E2=80=93 Add pango_cairo_show_error_underline & pango_cairo_error_underline_path Bug 343966 =E2=80=93 pango Cygwin build fixes Patch from Cygwin Ports maintainer. Bug 343796 =E2=80=93 Italic Chinese character can't be show correctly in Win32. Bug 314114 =E2=80=93 max_x_advance not appropriate for approximate_(char|digit)_width Bug 341138 =E2=80=93 Using TTC font, Gtk2 programs begin to eating big mem= ory and have many cpu usage. Patch from Yong Li. Bug 336153 =E2=80=93 Mark to mark positioning (Lookup Type 6) isn't correc= t when using MarkAttchmentType Patch from Tin Myo Htet. Bug 333984 =E2=80=93 pango_language_from_string improvements Bug 125378 =E2=80=93 Better underline thickness handling Bug 339730 =E2=80=93 Pango needlessly falls back away from a Type 1 font i= nto a TTF font Bug 342562 =E2=80=93 Support absolute sizes in pango_font_description_to/from_string Bug 341922 =E2=80=93 pango should handle more characters as zero width Patch from Roozbeh Pournader Bug 342525 =E2=80=93 With PangoFc and PangoWin32, approximate digit width = is not what it says Bug 342079 =E2=80=93 pangoatsui-private.h missing from release Behdad Esfahbod 12 June 2006 --=-HZBsNn3KdPR3jVVwB9gO Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQBEjeBFn+4E5dNTERURApTwAJ9OvqbaG1xnQYzGPC9u0WPi30b6ggCfXNvZ oFfMwctzkAaKRETc/0aDRj0= =Wl7j -----END PGP SIGNATURE----- --=-HZBsNn3KdPR3jVVwB9gO-- From Klaus.Stengel@asamnet.de Tue Jun 13 06:57:05 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 1BD1E3B008F for ; Tue, 13 Jun 2006 06:57:05 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20572-03 for ; Tue, 13 Jun 2006 06:57:03 -0400 (EDT) Received: from mail.asamnet.de (mail.asamnet.de [194.25.81.18]) by menubar.gnome.org (Postfix) with ESMTP id A52473B000C for ; Tue, 13 Jun 2006 06:57:03 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.asamnet.de (Asamnet e.V. Mailserver) with ESMTP id D01E8A7076 for ; Tue, 13 Jun 2006 12:56:24 +0200 (CEST) Received: from mail.asamnet.de ([127.0.0.1]) by localhost (mail.asamnet.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00951-06 for ; Tue, 13 Jun 2006 12:56:24 +0200 (CEST) Received: from aquarian.nathanet.lan (p5492D6A6.dip.t-dialin.net [84.146.214.166]) by mail.asamnet.de (Asamnet e.V. Mailserver) with ESMTP id 6350FA7066 for ; Tue, 13 Jun 2006 12:56:24 +0200 (CEST) Subject: Pango memory leak in get_ruleset() in modules/basic/basic-fc.c From: Klaus Stengel To: gtk-devel-list@gnome.org Content-Type: text/plain Date: Tue, 13 Jun 2006 12:56:34 +0200 Message-Id: <1150196194.9594.16.camel@aquarian.nathanet.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at asamnet.de X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.464 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.464 X-Spam-Level: X-Mailman-Approved-At: Fri, 16 Jun 2006 05:27:53 -0400 X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2006 10:57:05 -0000 Hi, while working with the diagram editor "dia" I noticed a major memory leak when editing text objects. I tracked this down to a problem in the above function. From what I understand the function looks for an ruleset associated with the given font face and in case there is none, the ruleset is created with pango_ot_ruleset_new() and finally attached to the font face. The g_object_unref() is given as "notification callback" so that the ruleset is destroyed when the font face is finalized. In theory this should work, but unfortunately it doesn't in practice, because pango_ot_ruleset_new() internally references "info" itself, thus creating a circular dependency that keeps the objects alive indefinitely. Unfortunately I don't see an simple solution, except to drop that kind of caching again... Bye, Klaus. P.S.: Please reply to my email address as well, as I'm not subscribed to the list. From newren@gmail.com Sat Jun 17 01:54:29 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 7F2843B066E for ; Sat, 17 Jun 2006 01:54:29 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08609-05 for ; Sat, 17 Jun 2006 01:54:28 -0400 (EDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.198]) by menubar.gnome.org (Postfix) with ESMTP id 354E43B050E for ; Sat, 17 Jun 2006 01:54:28 -0400 (EDT) Received: by wx-out-0102.google.com with SMTP id h26so603851wxd for ; Fri, 16 Jun 2006 22:53:32 -0700 (PDT) Received: by 10.70.24.3 with SMTP id 3mr5192323wxx; Fri, 16 Jun 2006 22:53:32 -0700 (PDT) Received: by 10.70.102.9 with HTTP; Fri, 16 Jun 2006 22:53:32 -0700 (PDT) Message-ID: <51419b2c0606162253pfe0e7edsba8af3f8a1573477@mail.gmail.com> Date: Fri, 16 Jun 2006 23:53:32 -0600 From: "Elijah Newren" To: "Jason Spiro" Subject: Re: Imagine: what if points in Bugzilla had a significant effect? In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.572 tagged_above=-999 required=2 tests=[AWL=0.028, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.572 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2006 05:54:29 -0000 On 6/15/06, Jason Spiro wrote: > Imagine: what if points did something in Bugzilla, like, the more points > you have, the more votes you get? > > I think this would encourage people to file more bug reports, both good > bug reports and not-so-good ones. Would that be a net gain or a net loss > for GTK+? This isn't the right list for this email; bugzilla-devel or filed in bugzilla (against the bugzilla.gnome.org module) would be much better. Thanks, Elijah From timj@gtk.org Sat Jun 17 10:12:11 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id CD5003B00A6 for ; Sat, 17 Jun 2006 10:12:11 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23968-01 for ; Sat, 17 Jun 2006 10:12:08 -0400 (EDT) Received: from holken.mikan.net (holken.mikan.net [83.145.56.183]) by menubar.gnome.org (Postfix) with ESMTP id 34EA13B00D5 for ; Sat, 17 Jun 2006 10:12:07 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by holken.mikan.net (Postfix) with ESMTP id AC6413352A5; Sat, 17 Jun 2006 13:44:21 +0200 (CEST) Received: from holken.mikan.net ([127.0.0.1]) by localhost (holken.mikan.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07456-06; Sat, 17 Jun 2006 13:44:16 +0200 (CEST) Received: from birnet.org (d003096.adsl.hansenet.de [80.171.3.96]) by holken.mikan.net (Postfix) with ESMTP id 7CD8233524F; Sat, 17 Jun 2006 13:44:16 +0200 (CEST) Received: from master.birnet.private (localhost.localdomain [127.0.0.1]) by birnet.org (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k5HBiART015834 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 17 Jun 2006 13:44:11 +0200 Received: (from timj@localhost) by master.birnet.private (8.13.4/8.13.4/Submit) id k5HBhvjK015833; Sat, 17 Jun 2006 13:43:57 +0200 Date: Sat, 17 Jun 2006 13:43:57 +0200 (CEST) From: Tim Janik X-X-Sender: timj@master.birnet.private To: Michalis Giannakidis Subject: Re: gslice allocator: general impresions. In-Reply-To: <200606151827.45477.mgiannakidis@gmail.com> Message-ID: References: <200606151827.45477.mgiannakidis@gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at holken.mikan.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.339 tagged_above=-999 required=2 tests=[AWL=0.048, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, TW_TX=0.077] X-Spam-Score: -2.339 X-Spam-Level: Cc: Gtk+ Developers X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2006 14:12:12 -0000 On Thu, 15 Jun 2006, Michalis Giannakidis wrote: > Dear Glib team, > > I have recently used the glib-glice allocator in a very malloc intensive > application, and I would like to share a few observations I made, with you. > > The typical size I send to g_slice_alloc is 20 and 76 bytes (32 bit build). > The total memory consumed by my application has decreased - which is great! > However it `seems' to me, that this decrease in size is larger for the 64bit > build compared to the 32bit build. (I have modified gslice to align a chunk > to its own size so that I don't have unused memory between chunks eg: request > 20 and get 24...) you mean you've set P2ALIGNMENT to 1 * sizeof(void*) to get better granularity of the slices? have you left NATIVE_MALLOC_PADDING at 2*sizeof(void*) at least? (if not, memory fragmentation on some glibc systems and on all 64bit systems can become etxremely bad). > In my application now I use both g_slice_alloc and malloc.Testing the new > allocator in linux I came accross the following: > After using g_slice_alloc to alloc a great amount of data (eg 1500mb), each of > them being 20 or 76 bytes in size, subsequent calls to malloc(8*1024) or > similar sizes take much longer (the allocation does _not_ got to the swap). this is a magnitude of memory allocations where gslice hasn't been well tested. (my machine only has 1GB of memory for instance). while gslice should perform well even much beyond 1GB, i'd suspect that malloc()/memalign() don't, and thus could result in *some* GSlice slowdown as well. > Also if I chage the min_page_size from 128 to 4096, then the subsequent calls > to malloc(8*1024) or similar sizes take even longer. It takes for ever in the > 64 bit build! maybe due to your alignment tweaks. but maybe also because some malloc() buckets will have even longer lists that way. > Moreover, even with min_page_size set to 128, the calls to malloc take for > ever on a Linux 2.4.20 glibc-2.2.4(glibc up to 2.2.5 has a broken > posix_memalign so I fallback to memalign). broken in what way? > In all of the cases above, malloc responds much faster when the gslice > allocator is turned off. aparently some malloc implementations aren't too good at handling large numbers of page allocations. if modifying GSlice is an option for you, you could try to work around this at the expense of read-only allocation of the memory used by GSlice. to do that, you need to disable the HAVE_COMPLIANT_POSIX_MEMALIGN, HAVE_MEMALIGN and HAVE_VALLOC branches in allocator_memalign() and allocator_memfree() so the read-only malloc()-based fallback allocator is enabled. on 32bit systems, that'll by default allocate 16*4096=64k areas to allocate pages from. by doing: - const guint n_pages = 16; + const guint n_pages = 2560; you'll instead allocate 10MB areas, which should put far less stress on the system malloc() (that way, to fill 1GB, a maximum of 100 allocations are required). > I know I should be providing sample code and test programms here to back up > my observations. I also understand that I should provide execution times > instead of just stating that the calls to malloc take for ever. test programs would be great. allthough this kind of stress test can only be run and examined on a limited set of machines. e.g. the development machines i use have just 1GB and normally have only 30%-40% of free memory to spare for tests during runs like make check -C glib/test ;) > I would like to ask you, if there are any known issues in mixing gslice and > malloc calls in malloc intensive applications. > Any suggested readings would be most welcome. you've already seen the two papers cited in the big comment block at the start of gslice.c? it links to: http://citeseer.ist.psu.edu/bonwick94slab.html http://citeseer.ist.psu.edu/bonwick01magazines.html the first of which describes a kernel page allocator which isn't implemented by GSlice. we use memalign() instead, on the assumption that this is good enough for the vast majority of applications out there. if malloc is too stressed out by the aligned allocations gslice makes in your scenario, implementing this page allocator on top of mmap() and using that as a base allocator for gslice may be another option. > Regards > Michalis --- ciaoTJ From tristan.van.berkom@gmail.com Sat Jun 17 12:09:06 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 2E2D13B013A for ; Sat, 17 Jun 2006 12:09:06 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26133-07 for ; Sat, 17 Jun 2006 12:09:03 -0400 (EDT) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.239]) by menubar.gnome.org (Postfix) with ESMTP id DEE4F3B0061 for ; Sat, 17 Jun 2006 12:09:02 -0400 (EDT) Received: by wr-out-0506.google.com with SMTP id 57so940143wri for ; Sat, 17 Jun 2006 09:07:30 -0700 (PDT) Received: by 10.54.116.7 with SMTP id o7mr3977729wrc; Sat, 17 Jun 2006 09:00:41 -0700 (PDT) Received: from ?66.48.170.156? ( [66.48.170.156]) by mx.gmail.com with ESMTP id 44sm2844499wri.2006.06.17.09.02.05; Sat, 17 Jun 2006 09:02:06 -0700 (PDT) Message-ID: <44942B5F.2090903@gnome.org> Date: Sat, 17 Jun 2006 12:18:39 -0400 User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Alan M. Evans" Subject: Re: GObject extension propose (GContainer) References: <200606151101.12868.ntd@users.sourceforge.net> <44919246.8060301@gnome.org> <1150456522.5305.12.camel@localhost.localdomain> <1150491686.19405.355.camel@zosma.extratech.com> In-Reply-To: <1150491686.19405.355.camel@zosma.extratech.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit From: Tristan Van Berkom X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.208 tagged_above=-999 required=2 tests=[AWL=0.392, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.208 X-Spam-Level: Cc: Gtk+ Developers X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2006 16:09:06 -0000 Alan M. Evans wrote: [...] >>the lookup penalties are negligible. >>type node/class lookups and is_a checks are O(1); >>interface class lookups and conforms_to checks are O(ld(N)), where >>N is the number of interfaces a type node conforms to. >> >> > >Your assertion that the penalties are negligable is not really supported >by your response, unless the constant is also known for both orders. > > From my swift glance at gtype.c, it seems that in the case of an interface, the implementing interface is searched on that class's list of implementing interfaces... so when classes implement hundreds of interfaces it might be a performance hit. I dont think we've yet reached the day that we have to ditch good design and avoid using interfaces because of performance woes, that would be sorry day indeed... (I also dont think GTK+ code will be the only OO code needing major refactoring in those areas too... if these interface lookups weren't negligable) Cheers, -Tristan From chris@gnome-de.org Sat Jun 17 12:59:38 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 89E3F3B00A7 for ; Sat, 17 Jun 2006 12:59:38 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27929-06 for ; Sat, 17 Jun 2006 12:59:35 -0400 (EDT) Received: from mail.bytecamp.net (mail.bytecamp.net [212.204.60.9]) by menubar.gnome.org (Postfix) with SMTP id DF0E93B000D for ; Sat, 17 Jun 2006 12:59:34 -0400 (EDT) Received: (qmail 40076 invoked by uid 85); 17 Jun 2006 16:58:00 -0000 Received: from chris@gnome-de.org by mail.bytecamp.net by uid 88 with qmail-scanner-1.20 (clamscan: 0.88.1 Clear:RC:0(84.150.174.158):. Processed in 0.431315 secs); 17 Jun 2006 16:58:00 -0000 Received: from p5496ae9e.dip0.t-ipconnect.de (HELO ?192.168.123.112?) (chris@gnome-de.org@84.150.174.158) by mail.bytecamp.net with RC4-MD5 encrypted SMTP; 17 Jun 2006 16:57:59 -0000 Subject: GtkFileChooser/GnomeVFS backend still messing up authentication manager? (was: GTK+ 2.10, the endgame) From: Christian Neumair To: Matthias Clasen In-Reply-To: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> References: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> Content-Type: text/plain Date: Sat, 17 Jun 2006 18:57:54 +0200 Message-Id: <1150563475.24534.12.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.586 tagged_above=-999 required=2 tests=[AWL=0.013, BAYES_00=-2.599] X-Spam-Score: -2.586 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2006 16:59:38 -0000 Am Donnerstag, den 15.06.2006, 09:56 -0400 schrieb Matthias Clasen: > I want to have GTK+ 2.10 ready at or immediately after GUADEC. > > I did not declare 2.9.3 api frozen in the release announcement, > because we were still holding the door open for Kris' work on > the new tooltips api. But he has run into some difficulties > with the implementation which will take some time to overcome, > so we have decided to punt this feature and try to get it > into 2.12 early. > > Therefore, I want to consider 2.9.3 api frozen, and take a > look at what still needs to happen before 2.10. Here are some > things I personally would like get worked on (not sure > how much time I can free to look into these myself): > > - I think the async filechooser conversion has caused some > regressions, I noticed that .hidden support seems broken > and autocompletion also behaved badly for me recently. > > - There is a number of FIXMEs and unimplemented bits in > the print code. > > - The print backends need a careful look wrt to memory leaks > and error reporting. > > Are there other important bugs or regressions that need > attention before 2.10 ? Some months ago I investigated an issue where the GtkFileChooser requested file info for all shortcuts and caused mass login requests for all bookmarked remote locations on startup that require login with the GnomeVFS backend. I think the issue was that the file chooser has no way of requesting file info, but signalling at the same time that failure due to unavailability of resources or access constraints isn't fatal, allowing the GnomeVFS backend to not request login data when it is invoked through gtkfilechooserdefault.c:shortcuts_reload_icons. In that case, we may want to fall back to a folder icon. >From reading the GTK+ HEAD source code, the shortcut code still doesn't seem to pass any special flags, so it still seems to be relevant. -- Christian Neumair From gcottenc@gmail.com Sat Jun 17 13:23:55 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 81FC83B000D for ; Sat, 17 Jun 2006 13:23:55 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30389-08 for ; Sat, 17 Jun 2006 13:23:54 -0400 (EDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.197]) by menubar.gnome.org (Postfix) with ESMTP id 01A153B010F for ; Sat, 17 Jun 2006 13:23:53 -0400 (EDT) Received: by wx-out-0102.google.com with SMTP id h26so659270wxd for ; Sat, 17 Jun 2006 10:22:54 -0700 (PDT) Received: by 10.70.116.8 with SMTP id o8mr5867050wxc; Sat, 17 Jun 2006 10:22:54 -0700 (PDT) Received: by 10.70.19.4 with HTTP; Sat, 17 Jun 2006 10:22:54 -0700 (PDT) Message-ID: Date: Sat, 17 Jun 2006 19:22:54 +0200 From: "Guillaume Cottenceau" To: "Matthias Clasen" Subject: Re: GTK+ 2.10, the endgame In-Reply-To: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.6 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.6 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2006 17:23:55 -0000 On 6/15/06, Matthias Clasen wrote: > Therefore, I want to consider 2.9.3 api frozen, and take a Does this mean that http://developer.gnome.org/doc/API/2.0/gtk/ix07.html (and equivalents for gdk, pango, atk) is now a fully stable source for bindings which want to support new features of 2.10? -- Guillaume Cottenceau - http://zarb.org/~gc/ From timj@gtk.org Sun Jun 18 07:31:59 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id D384A3B0316 for ; Sun, 18 Jun 2006 07:31:59 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21403-07 for ; Sun, 18 Jun 2006 07:31:57 -0400 (EDT) Received: from holken.mikan.net (holken.mikan.net [83.145.56.183]) by menubar.gnome.org (Postfix) with ESMTP id 5988B3B09AB for ; Sun, 18 Jun 2006 07:31:57 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by holken.mikan.net (Postfix) with ESMTP id D1B0818461; Sun, 18 Jun 2006 13:31:12 +0200 (CEST) Received: from holken.mikan.net ([127.0.0.1]) by localhost (holken.mikan.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16166-04; Sun, 18 Jun 2006 13:31:09 +0200 (CEST) Received: from birnet.org (d003096.adsl.hansenet.de [80.171.3.96]) by holken.mikan.net (Postfix) with ESMTP id DE31E14571; Sun, 18 Jun 2006 13:31:08 +0200 (CEST) Received: from master.birnet.private (localhost.localdomain [127.0.0.1]) by birnet.org (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k5IBV5n9025330 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 18 Jun 2006 13:31:05 +0200 Received: (from timj@localhost) by master.birnet.private (8.13.4/8.13.4/Submit) id k5IBUuX0025320; Sun, 18 Jun 2006 13:30:56 +0200 Date: Sun, 18 Jun 2006 13:30:56 +0200 (CEST) From: Tim Janik X-X-Sender: timj@master.birnet.private To: Tristan Van Berkom Subject: Re: GObject extension propose (GContainer) In-Reply-To: <44942B5F.2090903@gnome.org> Message-ID: References: <200606151101.12868.ntd@users.sourceforge.net> <44919246.8060301@gnome.org> <1150456522.5305.12.camel@localhost.localdomain> <1150491686.19405.355.camel@zosma.extratech.com> <44942B5F.2090903@gnome.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at holken.mikan.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.378 tagged_above=-999 required=2 tests=[AWL=0.086, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.378 X-Spam-Level: Cc: Gtk+ Developers X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jun 2006 11:32:00 -0000 On Sat, 17 Jun 2006, Tristan Van Berkom wrote: > Alan M. Evans wrote: > [...] > >>> the lookup penalties are negligible. >>> type node/class lookups and is_a checks are O(1); >>> interface class lookups and conforms_to checks are O(ld(N)), where >>> N is the number of interfaces a type node conforms to. >>> >>> >> >> Your assertion that the penalties are negligable is not really supported >> by your response, unless the constant is also known for both orders. >> >> > From my swift glance at gtype.c, it seems that in the case of > an interface, the implementing interface is searched on that class's > list of implementing interfaces... so when classes implement > hundreds of interfaces it might be a performance hit. no there won't be a performance hit. that's because gtype.c uses a binary search for the lookups (as indicated in my last email by the O(ld(N)) complexity). the function used for frequent interface lookups is: gpointer g_type_interface_peek (gpointer instance_class, GType iface_type); and in a nutshell, it does: { TypeNode *node = lookup_type_node_I (class->g_type); // O(1) TypeNode *iface = lookup_type_node_I (iface_type); // O(1) IFaceEntry *entry = type_lookup_iface_entry_L (node, iface); // O(ld(N)) return entry->vtable; } take a look at gtype.c and type_lookup_iface_entry_L() to confirm. using a binary lookup in type_lookup_iface_entry_L() means, lookups in terms of number of interfaces and node visits during the search relate like this: interfaces-per-node | visits-per-lookup 1 | 1.0 2 | 2.0 3 | 2.6 4 | 3.0 5 | 3.3 6 | 3.6 8 | 4.0 16 | 5.0 32 | 6.0 64 | 7.0 128 | 8.0 256 | 9.0 512 | 10.0 1024 | 11.0 65536 | 17.0 262144 | 19.0 1048576 | 21.0 67108864 | 27.0 268435456 | 29.0 2147483648 | 32.0 that is, for all practical purposes, interface lookups are negligible even for many thausands of interfaces implemented per node. and now, please show me the OO system that gets into the hundreds at least... > Cheers, > -Tristan --- ciaoTJ From nicola@effe-gi.it Wed Jun 14 13:42:30 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id D182C3B0003 for ; Wed, 14 Jun 2006 13:42:30 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20727-04 for ; Wed, 14 Jun 2006 13:42:29 -0400 (EDT) Received: from mailout01.albacom.net (mailout01.albacom.net [217.220.34.13]) by menubar.gnome.org (Postfix) with SMTP id 968DC3B0081 for ; Wed, 14 Jun 2006 13:42:28 -0400 (EDT) Received: (qmail 15057 invoked by uid 508); 14 Jun 2006 17:41:43 -0000 Received: from nicola@effe-gi.it by mailout01.albacom.net with qmail-scanner (spamassassin: ???. Clear:RC:1(217.221.76.9):SA:0(0.0/15.0):. Processed in 2.56365 secs); 14 Jun 2006 17:41:43 -0000 Received: from unknown (HELO sviluppo.internet.local) (postmaster@effe-gi.it@217.221.76.9) by mailout01.albacom.net with SMTP; 14 Jun 2006 17:41:40 -0000 From: Fontana Nicola Organization: Elettronica EFFE-GI s.n.c. To: gtk-devel-list@gnome.org Subject: GObject extension propose (GContainer) Date: Wed, 14 Jun 2006 20:17:53 +0000 User-Agent: KMail/1.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200606142017.53525.nicola@effe-gi.it> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.599 tagged_above=-999 required=2 tests=[BAYES_00=-2.599] X-Spam-Score: -2.599 X-Spam-Level: X-Mailman-Approved-At: Sun, 18 Jun 2006 10:56:05 -0400 X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2006 17:42:31 -0000 Hi all, I'm a GObject based libraries (for UI purpose and not) user and I often need a generic container to derive my own types. In my opinion, I think this generic container must be included inside the GObject library ... it could be used by a lot of derived libraries providing a common approach. I published my solution - that is, what I am currently using - on sourceforge. http://sourceforge.net/projects/gcontainer/ Is it a good idea? Is something planned in this direction? Am I totally wrong? I need feedbacks ... Nicola From tristan.van.berkom@gmail.com Sun Jun 18 12:43:27 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 15A9A3B0BF9 for ; Sun, 18 Jun 2006 12:43:27 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03626-01 for ; Sun, 18 Jun 2006 12:43:26 -0400 (EDT) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.225]) by menubar.gnome.org (Postfix) with ESMTP id 1D9F83B0C2D for ; Sun, 18 Jun 2006 12:43:26 -0400 (EDT) Received: by wr-out-0506.google.com with SMTP id 37so824607wra for ; Sun, 18 Jun 2006 09:42:28 -0700 (PDT) Received: by 10.54.153.8 with SMTP id a8mr5030935wre; Sun, 18 Jun 2006 09:42:28 -0700 (PDT) Received: from ?66.48.170.160? ( [66.48.170.160]) by mx.gmail.com with ESMTP id 25sm98918wra.2006.06.18.09.42.26; Sun, 18 Jun 2006 09:42:27 -0700 (PDT) Message-ID: <44958664.4050704@gmail.com> Date: Sun, 18 Jun 2006 12:59:16 -0400 From: Tristan Van Berkom User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Janik Subject: Re: GObject extension propose (GContainer) References: <200606151101.12868.ntd@users.sourceforge.net> <44919246.8060301@gnome.org> <1150456522.5305.12.camel@localhost.localdomain> <1150491686.19405.355.camel@zosma.extratech.com> <44942B5F.2090903@gnome.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.495 tagged_above=-999 required=2 tests=[AWL=-0.351, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=1.456, SPF_PASS=-0.001] X-Spam-Score: -1.495 X-Spam-Level: Cc: Gtk+ Developers X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jun 2006 16:43:27 -0000 Tim Janik wrote: [...] > no there won't be a performance hit. [...] > 268435456 | 29.0 > 2147483648 | 32.0 > > that is, for all practical purposes, interface lookups are negligible > even > for many thausands of interfaces implemented per node. > Those stats look great Tim, sorry for any confusion I may have unwillingly caused in this thread, I think its of great importance that people not fear the GInterface. Cheers, -Tristan From jnoreiko@yahoo.com Sun Jun 18 15:19:51 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id E64063B0114 for ; Sun, 18 Jun 2006 15:19:50 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08166-08 for ; Sun, 18 Jun 2006 15:19:48 -0400 (EDT) Received: from web32405.mail.mud.yahoo.com (web32405.mail.mud.yahoo.com [68.142.207.198]) by menubar.gnome.org (Postfix) with SMTP id 24E153B00E5 for ; Sun, 18 Jun 2006 15:19:47 -0400 (EDT) Received: (qmail 1542 invoked by uid 60001); 18 Jun 2006 19:19:02 -0000 Message-ID: <20060618191902.1540.qmail@web32405.mail.mud.yahoo.com> Received: from [172.213.179.4] by web32405.mail.mud.yahoo.com via HTTP; Sun, 18 Jun 2006 20:19:02 BST Date: Sun, 18 Jun 2006 20:19:02 +0100 (BST) From: Joachim Noreiko Subject: Re: GtkFileChooser/GnomeVFS backend still messing up authentication manager? (was: GTK+ 2.10, the endgame) To: gtk-devel-list@gnome.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.64 tagged_above=-999 required=2 tests=[AWL=-0.688, BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2, DNS_FROM_RFC_WHOIS=1.447] X-Spam-Score: -1.64 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jun 2006 19:19:51 -0000 > Date: Sat, 17 Jun 2006 18:57:54 +0200 > From: Christian Neumair > Subject: GtkFileChooser/GnomeVFS backend still > > Are there other important bugs or regressions that > need > > attention before 2.10 ? Yes! Please could you implement a help button in the filechooser. The documentation is already written and is ready to be linked to. ___________________________________________________________ All new Yahoo! Mail "The new Interface is stunning in its simplicity and ease of use." - PC Magazine http://uk.docs.yahoo.com/nowyoucan.html From alexl@redhat.com Mon Jun 19 05:47:41 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id AB66D3B00A4 for ; Mon, 19 Jun 2006 05:47:41 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02513-02 for ; Mon, 19 Jun 2006 05:47:40 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id 4A6763B0014 for ; Mon, 19 Jun 2006 05:47:40 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5J9Aqqj029011; Mon, 19 Jun 2006 05:10:52 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5J9AqpA029834; Mon, 19 Jun 2006 05:10:52 -0400 Received: from [127.0.0.1] (sebastian-int.corp.redhat.com [172.16.52.221]) by devserv.devel.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5J9Ap4k026344; Mon, 19 Jun 2006 05:10:51 -0400 Subject: Re: Printing and blocking ui From: Alexander Larsson To: Yevgen Muntyan In-Reply-To: <4491AF5A.2050702@tamu.edu> References: <4491AF5A.2050702@tamu.edu> Content-Type: text/plain Date: Mon, 19 Jun 2006 11:10:51 +0200 Message-Id: <1150708251.1962.23.camel@greebo> Mime-Version: 1.0 X-Mailer: Evolution 2.7.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.588 tagged_above=-999 required=2 tests=[AWL=0.013, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.588 X-Spam-Level: Cc: GTK Devel List X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2006 09:47:41 -0000 On Thu, 2006-06-15 at 14:04 -0500, Yevgen Muntyan wrote: > Hi there, > > I print a text document from GtkTextView here. There is a problem > with pagination: pagination is potentially slow, so some sort of progress > dialog should be shown during it. From the other hand, the text buffer > must not be modified during pagination. > How to solve it? Should I show my own modal dialog and make sure user > doesn't modify the buffer, or GtkPrintOperation can take care of it? This is supported now with the Gtkprintoperation::paginate signal and gtk_print_operation_set_show_progress(). > Actually, it would be good to ensure printing blocks the text widget too, > since in this case it wouldn't be necessary to calculate and store all > the pango > layouts in begin-print. Maybe just show a modal dialog between begin-print > and end-print. Locking the editing widget is probably something you have to do yourself. You could also do a snapshot of the data at print time. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl@redhat.com alla@lysator.liu.se He's an otherworldly guerilla ex-con with a secret. She's a scantily clad belly-dancing widow who can talk to animals. They fight crime! From muntyan@tamu.edu Mon Jun 19 06:17:07 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 591293B00FB for ; Mon, 19 Jun 2006 06:17:07 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04050-03 for ; Mon, 19 Jun 2006 06:17:05 -0400 (EDT) Received: from smtp101.vzn.mail.mud.yahoo.com (smtp101.vzn.mail.mud.yahoo.com [68.142.203.45]) by menubar.gnome.org (Postfix) with SMTP id 64EE03B00C8 for ; Mon, 19 Jun 2006 06:17:05 -0400 (EDT) Received: (qmail 1322 invoked from network); 19 Jun 2006 10:16:02 -0000 Received: from unknown (HELO ?192.168.3.9?) (muntyan@verizon.net@71.113.224.59 with plain) by smtp101.vzn.mail.mud.yahoo.com with SMTP; 19 Jun 2006 10:16:01 -0000 Message-ID: <44967960.3060609@tamu.edu> Date: Mon, 19 Jun 2006 05:16:00 -0500 From: Yevgen Muntyan User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20060216 Debian/1.7.12-1.1ubuntu2 X-Accept-Language: en MIME-Version: 1.0 To: Alexander Larsson Subject: Re: Printing and blocking ui References: <4491AF5A.2050702@tamu.edu> <1150708251.1962.23.camel@greebo> In-Reply-To: <1150708251.1962.23.camel@greebo> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.553 tagged_above=-999 required=2 tests=[AWL=0.046, BAYES_00=-2.599] X-Spam-Score: -2.553 X-Spam-Level: Cc: GTK Devel List X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2006 10:17:07 -0000 Alexander Larsson wrote: >On Thu, 2006-06-15 at 14:04 -0500, Yevgen Muntyan wrote: > > >>Hi there, >> >>I print a text document from GtkTextView here. There is a problem >>with pagination: pagination is potentially slow, so some sort of progress >>dialog should be shown during it. From the other hand, the text buffer >>must not be modified during pagination. >>How to solve it? Should I show my own modal dialog and make sure user >>doesn't modify the buffer, or GtkPrintOperation can take care of it? >> >> > >This is supported now with the Gtkprintoperation::paginate signal and >gtk_print_operation_set_show_progress(). > > I don't know how paginate works, but the dialog which shows up during printing is not modal, and it appears only after some delay. I can erase text in the buffer between clicking Print button and the time when progress dialog appears. >>Actually, it would be good to ensure printing blocks the text widget too, >>since in this case it wouldn't be necessary to calculate and store all >>the pango >>layouts in begin-print. Maybe just show a modal dialog between begin-print >>and end-print. >> >> > >Locking the editing widget is probably something you have to do >yourself. You could also do a snapshot of the data at print time. > > Well, locking is easy, but I have to tell user about what's happening. So I guess the solution is to have my own modal progress dialog. Regards, Yevgen From mardy@users.sourceforge.net Mon Jun 19 10:20:09 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id B4CCC3B018E for ; Mon, 19 Jun 2006 10:20:09 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14994-07 for ; Mon, 19 Jun 2006 10:20:06 -0400 (EDT) Received: from smtp008.mail.ukl.yahoo.com (smtp008.mail.ukl.yahoo.com [217.12.11.62]) by menubar.gnome.org (Postfix) with SMTP id 190673B0076 for ; Mon, 19 Jun 2006 10:20:05 -0400 (EDT) Received: (qmail 79361 invoked from network); 19 Jun 2006 14:12:00 -0000 Received: from unknown (HELO pupilla) (mardy78@151.38.48.109 with login) by smtp008.mail.ukl.yahoo.com with SMTP; 19 Jun 2006 14:12:00 -0000 Received: by pupilla (Postfix, from userid 1000) id D59DB6B883; Mon, 19 Jun 2006 16:10:17 +0200 (CEST) Date: Mon, 19 Jun 2006 16:10:17 +0200 From: Alberto Mardegan To: gtk-devel-list@gnome.org Subject: GtkLabel as a child of a windowless widget Message-ID: <20060619141017.GA31744@pupilla> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Accept-Language: it,ia,en,bg,es,fr User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.599 tagged_above=-999 required=2 tests=[BAYES_00=-2.599] X-Spam-Score: -2.599 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2006 14:20:09 -0000 Hi all! I'm creating a Widget based on GtkFrame, with little differences: 1) It's not a container 2) It has the GTK_NO_WINDOW flag set. I'm going to use this widget inside a GtkFixed container, with the only goal of having it paint its frame (and draw its label) on the screen. I want it windowless, so that I can insert other widgets which will appear to be inside it, but which will be actually be owned by the GtkFixed. I know this is not really senseful, but I need such a widget for porting lots of applications from Prolific's Panther GUI to Gtk+. The problem I have, is that the frame label isn't drawn. I'm not sure if there are any operation I should do on it... I just create it, and call gtk_widget_set_parent(). On size_allocate, I'm not sure whether the child's x and y members of the size_allocation struct should be relative to (0,0) or to the parent widget's x and y allocation (since the parent is windowless, too). But this won't work in any case... Any hints? I have no clue. -- Saluti, Mardy http://interlingua.altervista.org Chiacchiera con i tuoi amici in tempo reale! http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com From ame1@extratech.com Mon Jun 19 11:13:35 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 1E8293B03A9 for ; Mon, 19 Jun 2006 11:13:35 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16850-05 for ; Mon, 19 Jun 2006 11:13:32 -0400 (EDT) Received: from portal2.extratech.com (portal.extratech.com [67.105.201.210]) by menubar.gnome.org (Postfix) with ESMTP id BF3D93B0076 for ; Mon, 19 Jun 2006 11:13:30 -0400 (EDT) Received: from zosma.extratech.com (zosma.extratech.com [192.168.0.41]) by portal2.extratech.com (8.12.11/8.12.11) with ESMTP id k5JFBMdd004376; Mon, 19 Jun 2006 08:11:22 -0700 Subject: Re: GObject extension propose (GContainer) From: "Alan M. Evans" To: Tristan Van Berkom In-Reply-To: <44942B5F.2090903@gnome.org> References: <200606151101.12868.ntd@users.sourceforge.net> <44919246.8060301@gnome.org> <1150456522.5305.12.camel@localhost.localdomain> <1150491686.19405.355.camel@zosma.extratech.com> <44942B5F.2090903@gnome.org> Content-Type: text/plain Message-Id: <1150729881.19405.420.camel@zosma.extratech.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 19 Jun 2006 08:11:21 -0700 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.86.1/1549/Sat Jun 17 15:20:39 2006 on portal2.extratech.com X-Virus-Status: Clean X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.551 tagged_above=-999 required=2 tests=[AWL=0.048, BAYES_00=-2.599] X-Spam-Score: -2.551 X-Spam-Level: Cc: Gtk+ Developers X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2006 15:13:35 -0000 On Sat, 2006-06-17 at 09:18, Tristan Van Berkom wrote: > Alan M. Evans wrote: > >>the lookup penalties are negligible. > >>type node/class lookups and is_a checks are O(1); > >>interface class lookups and conforms_to checks are O(ld(N)), where > >>N is the number of interfaces a type node conforms to. > > > >Your assertion that the penalties are negligable is not really supported > >by your response, unless the constant is also known for both orders.> > > > From my swift glance at gtype.c, it seems that in the case of > an interface, the implementing interface is searched on that class's > list of implementing interfaces... so when classes implement > hundreds of interfaces it might be a performance hit. My impression from the original question, which I didn't ask, was not so much about access to a large number of members. If a single variable needs to be examined many times then the performance penalty of a generic interface lookup can add up. In any case, I merely observed an assertion, "the lookup penalties are negligible," and the what appeared to be supporting data, the order of the lookups. This doesn't tell us what the penalty is, only that there is a penalty that gets worse as the number of members increases. Maybe the penalty is negligible, but the data presented didn't say so. That's all I was saying. > I dont think we've yet reached the day that we have to ditch good design > and avoid using interfaces because of performance woes, that would > be sorry day indeed... (I also dont think GTK+ code will be the only OO code > needing major refactoring in those areas too... if these interface > lookups weren't negligable) Indeed. I would certainly not advocate dispensing with good design. In fact, I usually advocate the purist design in my own software, and let Moore's Law fix the performance issues. But some cases still call for direct access for essential performance. I, too, would like to know the performance penalty of the generic interface. Being lazy, I suppose I will set up some experiment to discover it pragmatically. From federico@ximian.com Mon Jun 19 13:28:06 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id B62B13B05EF for ; Mon, 19 Jun 2006 13:28:06 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23010-05 for ; Mon, 19 Jun 2006 13:28:05 -0400 (EDT) Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) by menubar.gnome.org (Postfix) with ESMTP id 163BA3B0809 for ; Mon, 19 Jun 2006 13:28:04 -0400 (EDT) Received: (qmail 29558 invoked from network); 19 Jun 2006 17:27:00 -0000 Received: from localhost (HELO 164-99-120-63.boston.ximian.com) (127.0.0.1) by localhost with SMTP; 19 Jun 2006 17:27:00 -0000 Subject: Re: GtkFileChooser/GnomeVFS backend still messing up authentication manager? (was: GTK+ 2.10, the endgame) From: Federico Mena Quintero To: Joachim Noreiko In-Reply-To: <20060618191902.1540.qmail@web32405.mail.mud.yahoo.com> References: <20060618191902.1540.qmail@web32405.mail.mud.yahoo.com> Content-Type: text/plain Date: Mon, 19 Jun 2006 12:22:31 -0500 Message-Id: <1150737751.8452.77.camel@cacharro.xalalinux.org> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.575 tagged_above=-999 required=2 tests=[AWL=0.024, BAYES_00=-2.599] X-Spam-Score: -2.575 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2006 17:28:06 -0000 On Sun, 2006-06-18 at 20:19 +0100, Joachim Noreiko wrote: > Yes! > Please could you implement a help button in the > filechooser. The documentation is already written and > is ready to be linked to. Do we have a mechanism for this? I see that GtkColorSelectionDialog creates a Help button but hides it by default, and it gives GTK_RESPONSE_HELP when pressed. Does that get captured anywhere so that it can take you to the right help page? Federico From tvb@gnome.org Mon Jun 19 14:23:28 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 8657F3B04AC for ; Mon, 19 Jun 2006 14:23:28 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25353-05 for ; Mon, 19 Jun 2006 14:23:26 -0400 (EDT) Received: from mail.touchtunes.com (mail.touchtunes.com [207.96.182.162]) by menubar.gnome.org (Postfix) with ESMTP id 74D063B03C7 for ; Mon, 19 Jun 2006 14:23:26 -0400 (EDT) Received: from [192.168.0.138] (unknown [192.168.0.138]) by mail.touchtunes.com (Postfix) with ESMTP id 1C61615AAA; Mon, 19 Jun 2006 14:22:06 -0400 (EDT) Message-ID: <4496ED9C.3090009@gnome.org> Date: Mon, 19 Jun 2006 14:31:56 -0400 From: Tristan Van Berkom User-Agent: Mozilla Thunderbird 0.8 (X11/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alberto Mardegan Subject: Re: GtkLabel as a child of a windowless widget References: <20060619141017.GA31744@pupilla> In-Reply-To: <20060619141017.GA31744@pupilla> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.517 tagged_above=-999 required=2 tests=[AWL=0.006, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, TW_GT=0.077] X-Spam-Score: -2.517 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2006 18:23:28 -0000 Alberto Mardegan wrote: [...] > > Any hints? I have no clue. This mailing list is for the discussion of GTK+ development itself, for questions related to writing applications in gtk+ please write to gtk-app-devel-list@gnome.org or gtk-list@gnome.org. FYI: Widgets do not overlap in any containers in gtk+ (I've heard that there is z-ordering in gnomecanvas... you might want to check that out). You can: - Draw the frame yourself in the GtkFixed and place a child label where the frames label would be - Add a fixed as the child widget of the frame (probably what you want anyway). Cheers, -Tristan From federico@ximian.com Mon Jun 19 22:53:07 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 955513B044F for ; Mon, 19 Jun 2006 22:53:07 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18923-10 for ; Mon, 19 Jun 2006 22:53:06 -0400 (EDT) Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) by menubar.gnome.org (Postfix) with ESMTP id E23A03B0301 for ; Mon, 19 Jun 2006 22:53:05 -0400 (EDT) Received: (qmail 30485 invoked from network); 20 Jun 2006 02:52:00 -0000 Received: from localhost (HELO 164-99-120-63.boston.ximian.com) (127.0.0.1) by localhost with SMTP; 20 Jun 2006 02:52:00 -0000 Subject: Re: GtkLabel as a child of a windowless widget From: Federico Mena Quintero To: Alberto Mardegan In-Reply-To: <20060619141017.GA31744@pupilla> References: <20060619141017.GA31744@pupilla> Content-Type: text/plain Date: Mon, 19 Jun 2006 21:47:24 -0500 Message-Id: <1150771645.8452.94.camel@cacharro.xalalinux.org> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.575 tagged_above=-999 required=2 tests=[AWL=0.024, BAYES_00=-2.599] X-Spam-Score: -2.575 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2006 02:53:07 -0000 On Mon, 2006-06-19 at 16:10 +0200, Alberto Mardegan wrote: > Hi all! > I'm creating a Widget based on GtkFrame, with little differences: > 1) It's not a container > 2) It has the GTK_NO_WINDOW flag set. > > I'm going to use this widget inside a GtkFixed container, with the only > goal of having it paint its frame (and draw its label) on the screen. > I want it windowless, so that I can insert other widgets which will > appear to be inside it, but which will be actually be owned by the > GtkFixed. First, can you simply use a GtkFrame inside a GtkFixed, and just not put a child inside the frame? > The problem I have, is that the frame label isn't drawn. I'm not sure if > there are any operation I should do on it... I just create it, and call > gtk_widget_set_parent(). > On size_allocate, I'm not sure whether the child's x and y members of > the size_allocation struct should be relative to (0,0) or to the parent > widget's x and y allocation (since the parent is windowless, too). But > this won't work in any case... Allocations are always with respect to the parent window. So if you have a windowed parent, then inside it a no-window container at (10, 20), and a child of that container which is supposed to be offset (3, 4) pixels from the container's top-left corner, then the child's allocation will be at (13, 24). Federico From mclasen@redhat.com Tue Jun 20 09:27:18 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 4C2873B02C2 for ; Tue, 20 Jun 2006 09:27:18 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17744-01 for ; Tue, 20 Jun 2006 09:27:17 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id D5CE13B0184 for ; Tue, 20 Jun 2006 09:27:16 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5KDQgQV017831 for ; Tue, 20 Jun 2006 09:26:42 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5KDQbkk003106 for ; Tue, 20 Jun 2006 09:26:37 -0400 Received: from golem.boston.redhat.com (golem.boston.redhat.com [172.16.80.24]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id k5KDQbdH021200 for ; Tue, 20 Jun 2006 09:26:37 -0400 Subject: GTK+ team meeting From: Matthias Clasen To: gtk-devel-list@gnome.org Content-Type: text/plain Date: Tue, 20 Jun 2006 09:26:36 -0400 Message-Id: <1150809996.15532.50.camel@golem.boston.redhat.com> Mime-Version: 1.0 X-Mailer: Evolution 2.7.1 (2.7.1-1) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.543 tagged_above=-999 required=2 tests=[AWL=0.058, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.543 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2006 13:27:18 -0000 After a few weeks, we should probably have a team meeting today. The meeting is intended for the GTK+ team, but everybody is welcome to come and listen. The meeting logs will be posted on the GTK+ website (http://www.gtk.org/plan/meetings). Place: irc.gnome.org:#gtk-devel Time: 19:30 UTC (15:30 EDT), Tue, Jun 20 Possible agenda items: - GUADEC meeting - 2.10 + when to release + what needs to be on the 2.10 milestone but isn't ? Matthias From mclasen@redhat.com Tue Jun 20 11:22:11 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 3B32C3B043F; Tue, 20 Jun 2006 11:22:11 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22457-09; Tue, 20 Jun 2006 11:22:09 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id 71CF13B00E7; Tue, 20 Jun 2006 11:22:09 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5KFLLnL004523; Tue, 20 Jun 2006 11:21:21 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5KFLLNA016479; Tue, 20 Jun 2006 11:21:21 -0400 Received: from golem.boston.redhat.com (golem.boston.redhat.com [172.16.80.24]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id k5KFLKdH032719; Tue, 20 Jun 2006 11:21:20 -0400 Subject: GLib 2.11.4 released From: Matthias Clasen To: gnome-announce-list@gnome.org, gtk-devel-list@gnome.org, gtk-list@gnome.org, gtk-app-devel-list@gnome.org Content-Type: text/plain Date: Tue, 20 Jun 2006 11:21:20 -0400 Message-Id: <1150816880.15532.58.camel@golem.boston.redhat.com> Mime-Version: 1.0 X-Mailer: Evolution 2.7.1 (2.7.1-1) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.543 tagged_above=-999 required=2 tests=[AWL=0.058, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.543 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: gnome-hackers@gnome.org List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2006 15:22:11 -0000 GLib 2.11.4 is now available for download at: ftp://ftp.gtk.org/pub/gtk/v2.11/ http://ftp.gnome.org/pub/GNOME/sources/glib/2.11/ glib-2.11.4.tar.bz2 md5sum: 9d3a94baa4bfcd9a579b45eea6de3a8c glib-2.11.4.tar.gz md5sum: f7768bc7ed524c6b40cb87daccb6c2b2 This is a development release leading up to GLib 2.12. Notes: * This is unstable development release. While it has had a bit of testing, there are certainly plenty of bugs remaining to be found. This release should not be used in production. * Installing this version will overwrite your existing copy of GLib 2.10. If you have problems, you'll need to reinstall GLib 2.10. * GLib 2.12 will be source and binary compatible with the GLib 2.10.x series (for some caveats, see the README). At this point, the API additions in the 2.11.x series are finished. * Bugs should be reported to http://bugzilla.gnome.org. About GLib ========== GLib is the low-level core library that forms the basis for projects such as GTK+ and GNOME. It provides data structure handling for C, portability wrappers, and interfaces for such runtime functionality as an event loop, threads, dynamic loading, and an object system. More information about GLib is available at: http://www.gtk.org/ An installation guide for the GTK+ libraries, including GLib, can be found at: http://developer.gnome.org/doc/API/2.0/gtk/gtk-building.html Overview of Changes from GLib 2.11.3 to GLib 2.11.4 =================================================== * GBookmarkFile: - g_bookmark_file_remove_item returns a boolean * g_mkstemp accepts the XXXXXX in the middle of the template * Bugs fixed: 344868 g_key_file_to_data should separate groups * Updated translations (de,es,fr,gu,hi,ko,th) A list of all bugs fixed in this release can be found at: http://bugzilla.gnome.org/buglist.cgi?bug_id=344868 Thanks to everybody who has contributed to this release, in the form of bug reports or patches: Emmanuele Bassi, Christian Persch, Federico Mena Quintero Matthias Clasen June 20, 2006 From mgiannakidis@gmail.com Mon Jun 19 08:23:48 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id E62893B0AAF for ; Mon, 19 Jun 2006 08:23:47 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10711-01 for ; Mon, 19 Jun 2006 08:23:44 -0400 (EDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.191]) by menubar.gnome.org (Postfix) with ESMTP id E721A3B089A for ; Mon, 19 Jun 2006 08:23:43 -0400 (EDT) Received: by nf-out-0910.google.com with SMTP id x30so1070652nfb for ; Mon, 19 Jun 2006 05:22:35 -0700 (PDT) Received: by 10.48.14.1 with SMTP id 1mr1206423nfn; Mon, 19 Jun 2006 05:16:27 -0700 (PDT) Received: from ?213.140.137.120? ( [213.140.137.120]) by mx.gmail.com with ESMTP id d2sm4750763nfe.2006.06.19.05.16.26; Mon, 19 Jun 2006 05:16:26 -0700 (PDT) From: Michalis Giannakidis To: gtk-devel-list@gnome.org Subject: Re: gslice allocator: general impresions. Date: Mon, 19 Jun 2006 15:20:48 +0300 User-Agent: KMail/1.8.3 References: <200606151827.45477.mgiannakidis@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200606191520.48220.mgiannakidis@gmail.com> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.526 tagged_above=-999 required=2 tests=[AWL=-0.002, BAYES_00=-2.599, SPF_PASS=-0.001, TW_TX=0.077] X-Spam-Score: -2.526 X-Spam-Level: X-Mailman-Approved-At: Tue, 20 Jun 2006 12:30:13 -0400 X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2006 12:23:48 -0000 Dear Tim > > (I have modified gslice > > to align a chunk to its own size so that I don't have unused memory > > between chunks eg: request 20 and get 24...) > > you mean you've set P2ALIGNMENT to 1 * sizeof(void*) to get better > granularity of the slices? have you left NATIVE_MALLOC_PADDING at > 2*sizeof(void*) at least? (if not, memory fragmentation on some glibc > systems and on all 64bit systems can become etxremely bad). > I didn't change P2ALIGNMENT . I modified SLAB_INDEX to (asize - 1), SLAB_CHUNK_SIZE to (ix + 1) I also modified P2ALIGN to (size) for all occurances of P2ALIGN except for SLAB_INFO_SIZE. I understand that this will create different memory pools for each size I alloc for, but this is accpeted since I only call g_slice_alloc for two sizes. The tweak seem to be OK since I don't get any segfaults. > maybe due to your alignment tweaks. but maybe also because some malloc() > buckets will have even longer lists that way. > The slowdown also occurred without the alignment tweaks. My understanding is that it is a general malloc slowdown that occurres of the many small mallocs done in the application plus the many larger mallocs done by the gslice allocator. I have read the references available in the gslice allocator comments and were very helpful. What I am looking for know is some sort of comparisons in memory usage and speed in applications changing from malloc to gslice. Also, any tweaks in the gslice allocation sizes providing a more responsive malloc would be great! Any suggestions would be very welcome. Thank you very much. Michalis -- Michalis Giannakidis From mclasen@redhat.com Wed Jun 21 09:13:22 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C2BA53B1007 for ; Wed, 21 Jun 2006 09:13:22 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07614-06 for ; Wed, 21 Jun 2006 09:13:21 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id E02C63B0FE5 for ; Wed, 21 Jun 2006 09:13:20 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5LDDKUh027657; Wed, 21 Jun 2006 09:13:20 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5LDDJnE017553; Wed, 21 Jun 2006 09:13:19 -0400 Received: from golem.boston.redhat.com (golem.boston.redhat.com [172.16.80.24]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id k5LDDJdH018065; Wed, 21 Jun 2006 09:13:19 -0400 Subject: Re: Fwd: GTK+ 2.10, the endgame From: Matthias Clasen To: Guillaume Cottenceau In-Reply-To: References: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> Content-Type: text/plain Date: Wed, 21 Jun 2006 09:13:19 -0400 Message-Id: <1150895599.15532.80.camel@golem.boston.redhat.com> Mime-Version: 1.0 X-Mailer: Evolution 2.7.1 (2.7.1-1) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.506 tagged_above=-999 required=2 tests=[AWL=0.018, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, TW_GT=0.077] X-Spam-Score: -2.506 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2006 13:13:23 -0000 On Wed, 2006-06-21 at 08:38 +0200, Guillaume Cottenceau wrote: > Hi Matthias, > > Could you just drop a line on the list about this question? > > Thanks in advance. > > ---------- Forwarded message ---------- > From: Guillaume Cottenceau > Date: Jun 17, 2006 7:22 PM > Subject: Re: GTK+ 2.10, the endgame > To: Matthias Clasen > Cc: gtk-devel-list@gnome.org > > > On 6/15/06, Matthias Clasen wrote: > > Therefore, I want to consider 2.9.3 api frozen, and take a > > Does this mean that > http://developer.gnome.org/doc/API/2.0/gtk/ix07.html (and equivalents > for gdk, pango, atk) is now a fully stable source for bindings which > want to support new features of 2.10? > > -- > Guillaume Cottenceau - http://zarb.org/~gc/ > The online documentation is still at 2.9.2. I hope to find time to update it to 2.9.4 before leaving for GUADEC tomorrow. A small number of API additions turned out to be necessary in the lowlevel printing apis after 2.9.3: gtk_enumerate_printers GTK_PRINT_CAPABILITY_CAN_GENERATE_PS GTK_PRINT_SETTINGS_OUTPUT_FILE_FORMAT GTK_PRINT_SETTINGS_OUTPUT_URI Furthermore, GTK_PRINT_SETTINGS_PRINT_TO_FILE was found to be unused and removed, together with its setter and getter. Matthias From mclasen@redhat.com Wed Jun 21 13:35:58 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id EE5983B046D for ; Wed, 21 Jun 2006 13:35:57 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25325-06 for ; Wed, 21 Jun 2006 13:35:56 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id 7ACFF3B02CE for ; Wed, 21 Jun 2006 13:35:56 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5LHZtpq012200 for ; Wed, 21 Jun 2006 13:35:55 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5LHZthC009595 for ; Wed, 21 Jun 2006 13:35:55 -0400 Received: from golem.boston.redhat.com (golem.boston.redhat.com [172.16.80.24]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id k5LHZtdH019718 for ; Wed, 21 Jun 2006 13:35:55 -0400 Subject: Looking beyond 2.10 From: Matthias Clasen To: gtk-devel-list@gnome.org Content-Type: text/plain Date: Wed, 21 Jun 2006 13:35:55 -0400 Message-Id: <1150911355.15532.100.camel@golem.boston.redhat.com> Mime-Version: 1.0 X-Mailer: Evolution 2.7.1 (2.7.1-1) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.545 tagged_above=-999 required=2 tests=[AWL=0.056, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.545 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2006 17:35:58 -0000 So, with GTK+ 2.10 on the finish line, I tried to make a quick list of things we may want to look at for 2.12, as input to GUADEC discussions. Patches almost ready to go in - libglade integration - new tooltips api Stuff that needs more work - introspection - international calendar support Stuff that we need to figure out - canvas - libsexy cherrypicking ? (Of course, bugzilla has an endless supply of feature requests and bugs that one can work on, these are just the things that came to my mind first) Matthias From hfiguiere@teaser.fr Wed Jun 21 15:04:27 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C0B713B00F6 for ; Wed, 21 Jun 2006 15:04:27 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31064-02 for ; Wed, 21 Jun 2006 15:04:19 -0400 (EDT) Received: from xandros.com (smtp1.xandros.com [209.87.238.70]) by menubar.gnome.org (Postfix) with ESMTP id 873C83B02DA for ; Wed, 21 Jun 2006 15:04:14 -0400 (EDT) Received: from [172.16.1.95] (unknown [209.87.238.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by xandros.com (Postfix) with ESMTP id 09337A030 for ; Wed, 21 Jun 2006 15:04:13 -0400 (EDT) Message-ID: <4499982C.1010004@teaser.fr> Date: Wed, 21 Jun 2006 15:04:12 -0400 From: Hubert Figuiere User-Agent: Thunderbird 1.5.0.4 (X11/20060615) MIME-Version: 1.0 To: gtk-devel-list@gnome.org Subject: Re: Looking beyond 2.10 References: <1150911355.15532.100.camel@golem.boston.redhat.com> In-Reply-To: <1150911355.15532.100.camel@golem.boston.redhat.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.542 tagged_above=-999 required=2 tests=[AWL=0.057, BAYES_00=-2.599] X-Spam-Score: -2.542 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2006 19:04:27 -0000 Matthias Clasen wrote: > Stuff that needs more work > > - introspection > - international calendar support Complete MacOS X support? I'm about to pick Qt as a toolkit for a personal project just because of that. Hub From matthias.clasen@gmail.com Wed Jun 21 18:26:02 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id A5B4E3B006C for ; Wed, 21 Jun 2006 18:26:02 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09882-05 for ; Wed, 21 Jun 2006 18:26:01 -0400 (EDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.177]) by menubar.gnome.org (Postfix) with ESMTP id 477AE3B00F8 for ; Wed, 21 Jun 2006 18:26:01 -0400 (EDT) Received: by py-out-1112.google.com with SMTP id e30so107107pya for ; Wed, 21 Jun 2006 15:26:00 -0700 (PDT) Received: by 10.35.111.14 with SMTP id o14mr363031pym; Wed, 21 Jun 2006 15:26:00 -0700 (PDT) Received: by 10.35.39.16 with HTTP; Wed, 21 Jun 2006 15:26:00 -0700 (PDT) Message-ID: Date: Wed, 21 Jun 2006 18:26:00 -0400 From: "Matthias Clasen" To: "Hubert Figuiere" Subject: Re: Looking beyond 2.10 In-Reply-To: <4499982C.1010004@teaser.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1150911355.15532.100.camel@golem.boston.redhat.com> <4499982C.1010004@teaser.fr> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.51 tagged_above=-999 required=2 tests=[AWL=0.090, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.51 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2006 22:26:02 -0000 On 6/21/06, Hubert Figuiere wrote: > Matthias Clasen wrote: > > > Stuff that needs more work > > > > - introspection > > - international calendar support > > Complete MacOS X support? Sure, if someone with access to a Mac works on it. I don't have a Mac... > I'm about to pick Qt as a toolkit for a personal project just because of > that. Good luck. Matthias From trowbrds@gmail.com Wed Jun 21 18:29:52 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 103073B0011 for ; Wed, 21 Jun 2006 18:29:52 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10124-04 for ; Wed, 21 Jun 2006 18:29:49 -0400 (EDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.185]) by menubar.gnome.org (Postfix) with ESMTP id B842D3B00E4 for ; Wed, 21 Jun 2006 18:29:48 -0400 (EDT) Received: by nf-out-0910.google.com with SMTP id h2so177759nfe for ; Wed, 21 Jun 2006 15:29:47 -0700 (PDT) Received: by 10.49.81.12 with SMTP id i12mr1011269nfl; Wed, 21 Jun 2006 15:29:47 -0700 (PDT) Received: by 10.49.36.8 with HTTP; Wed, 21 Jun 2006 15:29:47 -0700 (PDT) Message-ID: Date: Wed, 21 Jun 2006 16:29:47 -0600 From: "David Trowbridge" To: gtk-devel-list@gnome.org Subject: Re: Looking beyond 2.10 In-Reply-To: <1150911355.15532.100.camel@golem.boston.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1150911355.15532.100.camel@golem.boston.redhat.com> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.538 tagged_above=-999 required=2 tests=[AWL=0.062, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.538 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2006 22:29:52 -0000 On 6/21/06, Matthias Clasen wrote: > - libsexy cherrypicking ? The icon entry and url labels are probably robust enough (and widely useful enough) to go in. For anything else, it will require some work. -David From mclasen@redhat.com Wed Jun 21 23:10:41 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id AA4213B0172; Wed, 21 Jun 2006 23:10:41 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23030-07; Wed, 21 Jun 2006 23:10:39 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id 63BA23B0008; Wed, 21 Jun 2006 23:10:39 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5M3AclX021506; Wed, 21 Jun 2006 23:10:38 -0400 Received: from lacrosse.corp.redhat.com (lacrosse.corp.redhat.com [172.16.52.154]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5M3AcnM019751; Wed, 21 Jun 2006 23:10:38 -0400 Received: from [172.16.83.158] (vpn83-158.boston.redhat.com [172.16.83.158]) by lacrosse.corp.redhat.com (8.12.11.20060308/8.11.6) with ESMTP id k5M3AciB004961; Wed, 21 Jun 2006 23:10:38 -0400 Subject: GTK+ 2.9.4 released From: Matthias Clasen To: gnome-announce-list@gnome.org, gtk-devel-list@gnome.org, gtk-app-devel-list@gnome.org, gtk-list@gnome.org Content-Type: text/plain Organization: Red Hat Date: Wed, 21 Jun 2006 23:12:41 -0400 Message-Id: <1150945961.4457.2.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.7.3 (2.7.3-2) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.507 tagged_above=-999 required=2 tests=[AWL=0.017, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, TW_GT=0.077] X-Spam-Score: -2.507 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: gnome-hackers@gnome.org List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 03:10:42 -0000 GTK+ 2.9.4 is now available for download at: http://ftp.gnome.org/pub/gnome/sources/gtk+/2.9/ gtk+-2.9.4.tar.bz2 md5sum: c06cf2cfa66485600d90789c9e58f27c gtk+-2.9.4.tar.gz md5sum: e3fefedc7f1a89b66c71c9967168a857 This is a development release leading up to GTK+ 2.10. Notes: * This is unstable development release. There are certainly plenty of bugs remaining to be found. This release should not be used in production. * Installing this version will overwrite your existing copy of GTK+ 2.8. If you have problems, you'll need to reinstall GTK+ 2.8. * GTK+ 2.10 will be source compatible with the GTK+ 2.8 series; the new API additions in GTK+ 2.9.0 are finalized by now. * The ABI version has been bumped from 2.4.0 to 2.10.0, since the filechooser backend interface has been changed. Third-party filechooser backends need to be ported to the new interface. Other third-party modules (input methods, image loaders, etc) just need to be reinstalled in the proper location for GTK+ to find them. * Remaining issues for GTK+ 2.10 can be found with following bugzilla query: http://bugzilla.gnome.org/buglist.cgi?product=gtk%2b&target_milestone=2.10+API+Freeze&target_milestone=2.10+Freeze&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED * Bugs should be reported to http://bugzilla.gnome.org. What is GTK+ ============ GTK+ is a multi-platform toolkit for creating graphical user interfaces. Offering a complete set of widgets, GTK+ is suitable for projects ranging from small one-off tools to complete application suites. GTK+ has been designed from the ground up to support a range of languages, not only C/C++. Using GTK+ from languages such as Perl and Python (especially in combination with the Glade GUI builder) provides an effective method of rapid application development. GTK+ is free software and part of the GNU Project. However, the licensing terms for GTK+, the GNU LGPL, allow it to be used by all developers, including those developing proprietary software, without any license fees or royalties. Where to get more information about GTK+ ======================================== Information about GTK+ including links to documentation can be found at: http://www.gtk.org/ An installation guide for GTK+ 2.x is found at: http://developer.gnome.org/doc/API/2.4/gtk/gtk-building.html Common questions: http://developer.gnome.org/doc/API/2.4/gtk/gtk-question-index.html http://www.gtk.org/faq/ Overview of Changes from GTK+ 2.9.3 to 2.9.4 ============================================ * GtkPrintOperation: - UI improvements in the print dialog - Make printing work without a display connection - Replace "Print to PDF" by "Print to file" that can generate PDF or PostScript - Add a function to the low-level API to enumerate all printers * GtkNotebook tab DND has been improved * GtkProgressbar supports text in activity mode * GtkLabel allows to set the wrap mode * GtkStatusIcon supports transparency * Bugs fixed: 344850 Dragging a GtkTreeViewColumn segfaults when using certain GtkTreeViewColumnDropFunc 342458 Stock menu items without icons are broken in recent GTK+ releases. 335873 notebook DND + popup windows 337882 gtk_progress_bar_set_text() does nothing in activity mode 339456 unix print dialogue help button bug 339702 Make sure printing works without a display 341571 tabs too easily reordered 344074 New Feature: get printer list, and get default print 344743 gtk_targets_include_text() should initialize atoms 344838 Allow func to be NULL in gtk_tree_view_set_search_position_func 344891 GtkPrintOperationPreview signal defs correction 345008 Need updated cairo req 345093 print preview temp file issues 345107 Memory leak in gtk_entry_completion_finalize: User data not freed 345194 gdk_window_set_functions() docs need to be updated 345456 grid-lines property is wrongly registered and get/set. 314278 strings in gtk-update-icon-cache are not marked for translation 344707 size group with widgets in hidden container 344897 Entry completion model NULL handling should be documented 345038 gtk_print_job_set_status' status 345106 dialog button box spacings 345176 GtkIconView doc about drag and drop 345275 doc imporovements for gtk_window_move 345320 Two very similiar strings should be made equal 345321 Add meaning of "shortcut" as translator comment 320034 transparency gtkstatusicon 339592 Add print-to-postscript 344867 custom paper file could use keyfile * Updated translations (cs,de,es,fr,gl,gu,hi,ko,ta,th) A list of all bugs fixed in this release can be found at http://bugzilla.gnome.org/buglist.cgi?bug_id=344838,344743,344867,344891,345008,341571,345038,337882,345093,344707,339456,345107,345275,339702,344074,345320,345321,344897,314278,320034,344850,345194,345176,345106,335873,342458,339592,345456 Thanks to everybody who has contributed to this release, in the form of bug reports or patches: Christian Persch, John Finlay, Federico Mena Quintero, Michael Emmel, Marko Anastasov, Bastien Nocera, Carlos Garnacho, Yevgen Muntyan, Tommi Komulainen, Tim Janik, Christian Weiske, Behdad Esfahbod, Alexander Larsson, Felipe Heidrich, Hendrik Richter, Claudio Saavedra, Dan Winship, Callum McKenzie, John Palmieri, Murray Cumming, Kristian Rietveld June 21, 2006 Matthias Clasen From alexl@redhat.com Thu Jun 22 03:30:13 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id F02D73B04C8 for ; Thu, 22 Jun 2006 03:30:12 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04379-10 for ; Thu, 22 Jun 2006 03:30:11 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id 3177C3B021B for ; Thu, 22 Jun 2006 03:30:11 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5M7UAw1025719 for ; Thu, 22 Jun 2006 03:30:10 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5M7UAI5026706; Thu, 22 Jun 2006 03:30:10 -0400 Received: from [127.0.0.1] (sebastian-int.corp.redhat.com [172.16.52.221]) by devserv.devel.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5M7U90l029917; Thu, 22 Jun 2006 03:30:09 -0400 Subject: Re: Looking beyond 2.10 From: Alexander Larsson To: Matthias Clasen In-Reply-To: <1150911355.15532.100.camel@golem.boston.redhat.com> References: <1150911355.15532.100.camel@golem.boston.redhat.com> Content-Type: text/plain Date: Thu, 22 Jun 2006 09:30:09 +0200 Message-Id: <1150961409.16397.101.camel@greebo> Mime-Version: 1.0 X-Mailer: Evolution 2.7.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.588 tagged_above=-999 required=2 tests=[AWL=0.013, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.588 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 07:30:13 -0000 On Wed, 2006-06-21 at 13:35 -0400, Matthias Clasen wrote: > So, with GTK+ 2.10 on the finish line, I tried to make a quick > list of things we may want to look at for 2.12, as input to > GUADEC discussions. The EditableLable stuff would be nice to have in gtk+: http://live.gnome.org/ProjectRidley/EelEditableLabel This would mean i could drop EelEditableLabel, and i'm sure others need something like this too. For instance, GtkIconView would need it to support renaming. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl@redhat.com alla@lysator.liu.se He's a lonely hunchbacked matador on the edge. She's a radical impetuous single mother who don't take no shit from nobody. They fight crime! From mclasen@redhat.com Thu Jun 22 09:23:37 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 8880D3B0667 for ; Thu, 22 Jun 2006 09:23:37 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30015-09 for ; Thu, 22 Jun 2006 09:23:23 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id 58F4B3B03E5 for ; Thu, 22 Jun 2006 09:23:04 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5MDN3ca016505 for ; Thu, 22 Jun 2006 09:23:03 -0400 Received: from lacrosse.corp.redhat.com (lacrosse.corp.redhat.com [172.16.52.154]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5MDN3dV000789; Thu, 22 Jun 2006 09:23:03 -0400 Received: from [172.16.83.176] (vpn83-176.boston.redhat.com [172.16.83.176]) by lacrosse.corp.redhat.com (8.12.11.20060308/8.11.6) with ESMTP id k5MDN2MM012188; Thu, 22 Jun 2006 09:23:03 -0400 Subject: Re: Looking beyond 2.10 From: Matthias Clasen To: Alexander Larsson In-Reply-To: <1150961409.16397.101.camel@greebo> References: <1150911355.15532.100.camel@golem.boston.redhat.com> <1150961409.16397.101.camel@greebo> Content-Type: text/plain Organization: Red Hat Date: Thu, 22 Jun 2006 09:25:07 -0400 Message-Id: <1150982707.2966.6.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.7.3 (2.7.3-2) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.546 tagged_above=-999 required=2 tests=[AWL=0.055, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.546 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 13:23:37 -0000 On Thu, 2006-06-22 at 09:30 +0200, Alexander Larsson wrote: > On Wed, 2006-06-21 at 13:35 -0400, Matthias Clasen wrote: > > So, with GTK+ 2.10 on the finish line, I tried to make a quick > > list of things we may want to look at for 2.12, as input to > > GUADEC discussions. > > The EditableLable stuff would be nice to have in gtk+: > http://live.gnome.org/ProjectRidley/EelEditableLabel > > This would mean i could drop EelEditableLabel, and i'm sure others need > something like this too. For instance, GtkIconView would need it to > support renaming. > Not that it would not be useful, but GtkIconView uses cell renderers, and already supports editing... From alexl@redhat.com Thu Jun 22 09:33:59 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 9529C3B0748 for ; Thu, 22 Jun 2006 09:33:59 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30708-06 for ; Thu, 22 Jun 2006 09:33:54 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id B4FBD3B0559 for ; Thu, 22 Jun 2006 09:33:54 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5MDXsaJ021314 for ; Thu, 22 Jun 2006 09:33:54 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5MDXrtU004254; Thu, 22 Jun 2006 09:33:53 -0400 Received: from [127.0.0.1] (sebastian-int.corp.redhat.com [172.16.52.221]) by devserv.devel.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5MDXqt9025805; Thu, 22 Jun 2006 09:33:53 -0400 Subject: Re: Looking beyond 2.10 From: Alexander Larsson To: Matthias Clasen In-Reply-To: <1150982707.2966.6.camel@localhost.localdomain> References: <1150911355.15532.100.camel@golem.boston.redhat.com> <1150961409.16397.101.camel@greebo> <1150982707.2966.6.camel@localhost.localdomain> Content-Type: text/plain Date: Thu, 22 Jun 2006 15:33:52 +0200 Message-Id: <1150983232.16397.107.camel@greebo> Mime-Version: 1.0 X-Mailer: Evolution 2.7.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.588 tagged_above=-999 required=2 tests=[AWL=0.013, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.588 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 13:33:59 -0000 On Thu, 2006-06-22 at 09:25 -0400, Matthias Clasen wrote: > On Thu, 2006-06-22 at 09:30 +0200, Alexander Larsson wrote: > > On Wed, 2006-06-21 at 13:35 -0400, Matthias Clasen wrote: > > > So, with GTK+ 2.10 on the finish line, I tried to make a quick > > > list of things we may want to look at for 2.12, as input to > > > GUADEC discussions. > > > > The EditableLable stuff would be nice to have in gtk+: > > http://live.gnome.org/ProjectRidley/EelEditableLabel > > > > This would mean i could drop EelEditableLabel, and i'm sure others need > > something like this too. For instance, GtkIconView would need it to > > support renaming. > > > > Not that it would not be useful, but GtkIconView uses cell renderers, > and already supports editing... How does that handle labels that are several lines long? =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl@redhat.com alla@lysator.liu.se He's a war-weary moralistic waffle chef with nothing left to lose. She's an orphaned red-headed barmaid looking for love in all the wrong places. They fight crime! From mclasen@redhat.com Thu Jun 22 09:48:21 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 98DD03B04F0 for ; Thu, 22 Jun 2006 09:48:21 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31802-05 for ; Thu, 22 Jun 2006 09:48:20 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id DD2613B00DE for ; Thu, 22 Jun 2006 09:48:19 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5MDmJQS027439 for ; Thu, 22 Jun 2006 09:48:19 -0400 Received: from lacrosse.corp.redhat.com (lacrosse.corp.redhat.com [172.16.52.154]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5MDmJB6008537; Thu, 22 Jun 2006 09:48:19 -0400 Received: from [172.16.83.176] (vpn83-176.boston.redhat.com [172.16.83.176]) by lacrosse.corp.redhat.com (8.12.11.20060308/8.11.6) with ESMTP id k5MDmIjF015592; Thu, 22 Jun 2006 09:48:18 -0400 Subject: Re: Looking beyond 2.10 From: Matthias Clasen To: Alexander Larsson In-Reply-To: <1150983232.16397.107.camel@greebo> References: <1150911355.15532.100.camel@golem.boston.redhat.com> <1150961409.16397.101.camel@greebo> <1150982707.2966.6.camel@localhost.localdomain> <1150983232.16397.107.camel@greebo> Content-Type: text/plain Organization: Red Hat Date: Thu, 22 Jun 2006 09:50:23 -0400 Message-Id: <1150984223.2966.10.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.7.3 (2.7.3-2) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.546 tagged_above=-999 required=2 tests=[AWL=0.055, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.546 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 13:48:21 -0000 On Thu, 2006-06-22 at 15:33 +0200, Alexander Larsson wrote: > On Thu, 2006-06-22 at 09:25 -0400, Matthias Clasen wrote: > > On Thu, 2006-06-22 at 09:30 +0200, Alexander Larsson wrote: > > > On Wed, 2006-06-21 at 13:35 -0400, Matthias Clasen wrote: > > > > So, with GTK+ 2.10 on the finish line, I tried to make a quick > > > > list of things we may want to look at for 2.12, as input to > > > > GUADEC discussions. > > > > > > The EditableLable stuff would be nice to have in gtk+: > > > http://live.gnome.org/ProjectRidley/EelEditableLabel > > > > > > This would mean i could drop EelEditableLabel, and i'm sure others need > > > something like this too. For instance, GtkIconView would need it to > > > support renaming. > > > > > > > Not that it would not be useful, but GtkIconView uses cell renderers, > > and already supports editing... > > How does that handle labels that are several lines long? > As well as the treeview does... eventually we'll have to sit down and add multline to GtkEntry... From alexl@redhat.com Thu Jun 22 09:52:23 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 292473B081B for ; Thu, 22 Jun 2006 09:52:23 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32031-08 for ; Thu, 22 Jun 2006 09:52:21 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id 83E8E3B0811 for ; Thu, 22 Jun 2006 09:52:21 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5MDqKud029180 for ; Thu, 22 Jun 2006 09:52:21 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5MDqFg0009757; Thu, 22 Jun 2006 09:52:15 -0400 Received: from [127.0.0.1] (sebastian-int.corp.redhat.com [172.16.52.221]) by devserv.devel.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5MDqE6x027583; Thu, 22 Jun 2006 09:52:14 -0400 Subject: Re: Looking beyond 2.10 From: Alexander Larsson To: Matthias Clasen In-Reply-To: <1150984223.2966.10.camel@localhost.localdomain> References: <1150911355.15532.100.camel@golem.boston.redhat.com> <1150961409.16397.101.camel@greebo> <1150982707.2966.6.camel@localhost.localdomain> <1150983232.16397.107.camel@greebo> <1150984223.2966.10.camel@localhost.localdomain> Content-Type: text/plain Date: Thu, 22 Jun 2006 15:52:14 +0200 Message-Id: <1150984334.16397.110.camel@greebo> Mime-Version: 1.0 X-Mailer: Evolution 2.7.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.588 tagged_above=-999 required=2 tests=[AWL=0.013, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.588 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 13:52:23 -0000 On Thu, 2006-06-22 at 09:50 -0400, Matthias Clasen wrote: > On Thu, 2006-06-22 at 15:33 +0200, Alexander Larsson wrote: > > > How does that handle labels that are several lines long? > > As well as the treeview does... eventually we'll have to sit down > and add multline to GtkEntry... Thats basically what EelEditableLabel is. I'm not sure its better to combine the two into one than having a separate widget for it. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl@redhat.com alla@lysator.liu.se He's a sword-wielding Catholic gangster fleeing from a secret government programme. She's a beautiful mute snake charmer with the power to bend men's minds. They fight crime! From Bill.Haneman@Sun.COM Thu Jun 22 09:59:01 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id A04A33B06B5 for ; Thu, 22 Jun 2006 09:59:01 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32611-04 for ; Thu, 22 Jun 2006 09:58:59 -0400 (EDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by menubar.gnome.org (Postfix) with ESMTP id EC16D3B0487 for ; Thu, 22 Jun 2006 09:58:52 -0400 (EDT) Received: from phys-gadget-1 ([129.156.85.171]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k5MDwpH2016279 for ; Thu, 22 Jun 2006 07:58:52 -0600 (MDT) Received: from conversion-daemon.gadget-mail1.uk.sun.com by gadget-mail1.uk.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0J1900F01LG3TK@gadget-mail1.uk.sun.com> (original mail from Bill.Haneman@Sun.COM) for gtk-devel-list@gnome.org; Thu, 22 Jun 2006 14:58:51 +0100 (BST) Received: from [192.168.1.120] (vpn-129-150-116-130.UK.Sun.COM [129.150.116.130]) by gadget-mail1.uk.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0J1900AYWLI2KV@gadget-mail1.uk.sun.com> for gtk-devel-list@gnome.org; Thu, 22 Jun 2006 14:58:51 +0100 (BST) Date: Thu, 22 Jun 2006 15:00:03 +0100 From: Bill Haneman Subject: GtkTextBuffer serialization formats: why no "text/plain" ? To: gtk-devel-list@gnome.org Message-id: <1150984802.7100.4.camel@linux.site> MIME-version: 1.0 X-Mailer: Ximian Evolution 1.4.6.338 Content-type: text/plain Content-transfer-encoding: 7BIT X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.538 tagged_above=-999 required=2 tests=[AWL=-0.017, BAYES_00=-2.599, TW_GT=0.077, UNPARSEABLE_RELAY=0.001] X-Spam-Score: -2.538 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 13:59:01 -0000 Hi; The new serialize/deserialize API for GtkTextBuffer looks to be very useful to accessibility among other things. I am currently using it to implement AtkStreamableContent, an interface which allows objects with streamable backing data (for instance images, HTML widgets, text containers...) to advertise that fact and stream the data to remote clients such as assistive technologies. However I am somewhat surprised to see in gtk-demo's Hypertext widget that, although there's a serialization format called "application/x-gtk-rich-text", there's no "text/plain". Of course serialization via plain text would not be lossless, but why isn't there a plain text serialization available for all GtkTextBuffer instances? We certainly need it for the accessibility case - otherwise we'll have to fake one in gail, necessitating multiple code paths or at least some odd concatenation of "text/plain" if it is not among those returned by gtk_text_buffer_get_serialize_formats... regards, Bill From ebassi@gmail.com Thu Jun 22 10:02:56 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id D0CCE3B074F for ; Thu, 22 Jun 2006 10:02:56 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00339-10 for ; Thu, 22 Jun 2006 10:02:55 -0400 (EDT) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.171]) by menubar.gnome.org (Postfix) with ESMTP id CC4073B0634 for ; Thu, 22 Jun 2006 10:02:54 -0400 (EDT) Received: by ug-out-1314.google.com with SMTP id o2so482915uge for ; Thu, 22 Jun 2006 07:02:53 -0700 (PDT) Received: by 10.78.151.3 with SMTP id y3mr507751hud; Thu, 22 Jun 2006 07:02:53 -0700 (PDT) Received: from ?192.168.1.70? ( [86.136.65.180]) by mx.gmail.com with ESMTP id 8sm364730hug.2006.06.22.07.02.53; Thu, 22 Jun 2006 07:02:53 -0700 (PDT) Subject: Re: Looking beyond 2.10 From: Emmanuele Bassi To: gtk-devel-list@gnome.org In-Reply-To: <1150911355.15532.100.camel@golem.boston.redhat.com> References: <1150911355.15532.100.camel@golem.boston.redhat.com> Content-Type: text/plain Date: Thu, 22 Jun 2006 15:02:51 +0100 Message-Id: <1150984971.5346.12.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.362 tagged_above=-999 required=2 tests=[AWL=0.238, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.362 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 14:02:57 -0000 Hi; On Wed, 2006-06-21 at 13:35 -0400, Matthias Clasen wrote: > So, with GTK+ 2.10 on the finish line, I tried to make a quick > list of things we may want to look at for 2.12, as input to > GUADEC discussions. > Stuff that needs more work > > - introspection > - international calendar support - use GBookmarkFile inside GtkFileSystem and add recent files inside GtkFileChooser. > Stuff that we need to figure out > > - canvas > - libsexy cherrypicking ? - EggIconChooser. AFAIR there were issues but I can't find any pointer to those. Also, I'd like to see the thumbnailing code added to GTK, and the thumbnail helpers changed from using GConf to a lower level position in the stack. Ciao, Emmanuele. -- Emmanuele Bassi, E: ebassi@gmail.com W: http://www.emmanuelebassi.net B: http://log.emmanuelebassi.net From kris@babi-pangang.org Thu Jun 22 10:07:12 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 9474E3B07EB for ; Thu, 22 Jun 2006 10:07:12 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00887-04 for ; Thu, 22 Jun 2006 10:07:09 -0400 (EDT) Received: from nasi-goreng.babi-pangang.org (nasi-goreng.babi-pangang.org [83.166.137.20]) by menubar.gnome.org (Postfix) with ESMTP id ECDDC3B07F0 for ; Thu, 22 Jun 2006 10:07:08 -0400 (EDT) Received: by nasi-goreng.babi-pangang.org (Postfix, from userid 1000) id 5DB383DCA0; Thu, 22 Jun 2006 16:07:04 +0200 (CEST) Date: Thu, 22 Jun 2006 16:07:04 +0200 From: Kristian Rietveld To: Matthias Clasen Subject: Re: Looking beyond 2.10 Message-ID: <20060622140703.GA15275@babi-pangang.org> References: <1150911355.15532.100.camel@golem.boston.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1150911355.15532.100.camel@golem.boston.redhat.com> User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.565 tagged_above=-999 required=2 tests=[AWL=0.034, BAYES_00=-2.599] X-Spam-Score: -2.565 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 14:07:12 -0000 On Wed, Jun 21, 2006 at 01:35:55PM -0400, Matthias Clasen wrote: > Stuff that needs more work > > - introspection > - international calendar support (I want to try to do multiple row DnD in GtkTreeView for real now. But I won't promise anything :) -kris. From jnoreiko@yahoo.com Thu Jun 22 10:28:15 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id CEBD43B0110 for ; Thu, 22 Jun 2006 10:28:15 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01906-05 for ; Thu, 22 Jun 2006 10:28:15 -0400 (EDT) Received: from web32406.mail.mud.yahoo.com (web32406.mail.mud.yahoo.com [68.142.207.199]) by menubar.gnome.org (Postfix) with SMTP id DCE8B3B0251 for ; Thu, 22 Jun 2006 10:28:14 -0400 (EDT) Received: (qmail 59923 invoked by uid 60001); 22 Jun 2006 14:28:14 -0000 Message-ID: <20060622142814.59921.qmail@web32406.mail.mud.yahoo.com> Received: from [172.203.129.193] by web32406.mail.mud.yahoo.com via HTTP; Thu, 22 Jun 2006 15:28:14 BST Date: Thu, 22 Jun 2006 15:28:14 +0100 (BST) From: Joachim Noreiko Subject: Re: Looking beyond 2.10 To: gtk-devel-list@gnome.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-0.405 tagged_above=-999 required=2 tests=[AWL=-1.612, BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2, DNS_FROM_RFC_WHOIS=1.447, RCVD_IN_SORBS_SOCKS=2.159] X-Spam-Score: -0.405 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 14:28:16 -0000 > Date: Wed, 21 Jun 2006 13:35:55 -0400 > From: Matthias Clasen > Subject: Looking beyond 2.10 > So, with GTK+ 2.10 on the finish line, I tried to > make a quick > list of things we may want to look at for 2.12, as > input to > GUADEC discussions. > > (Of course, bugzilla has an endless supply of > feature requests > and bugs that one can work on, these are just the > things that > came to my mind first) > I feel like I'm talking to myself here, but please could someone look at adding a help button to the fileselector. ___________________________________________________________ Inbox full of spam? Get leading spam protection and 1GB storage with All New Yahoo! Mail. http://uk.docs.yahoo.com/nowyoucan.html From tristan.van.berkom@gmail.com Thu Jun 22 13:10:30 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id A0DBC3B0690 for ; Thu, 22 Jun 2006 13:10:30 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12156-06 for ; Thu, 22 Jun 2006 13:10:28 -0400 (EDT) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.225]) by menubar.gnome.org (Postfix) with ESMTP id 215163B0137 for ; Thu, 22 Jun 2006 13:10:28 -0400 (EDT) Received: by wr-out-0506.google.com with SMTP id i12so437125wra for ; Thu, 22 Jun 2006 10:10:27 -0700 (PDT) Received: by 10.54.153.18 with SMTP id a18mr2404093wre; Thu, 22 Jun 2006 10:10:27 -0700 (PDT) Received: from ?66.48.170.242? ( [66.48.170.242]) by mx.gmail.com with ESMTP id 7sm1704382wrl.2006.06.22.10.10.22; Thu, 22 Jun 2006 10:10:27 -0700 (PDT) Message-ID: <449AD300.3030809@gnome.org> Date: Thu, 22 Jun 2006 13:27:28 -0400 User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mclasen@redhat.com Subject: Re: Looking beyond 2.10 References: <1150911355.15532.100.camel@golem.boston.redhat.com> <1150984971.5346.12.camel@localhost> In-Reply-To: <1150984971.5346.12.camel@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit From: Tristan Van Berkom X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.216 tagged_above=-999 required=2 tests=[AWL=0.384, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.216 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 17:10:30 -0000 Emmanuele Bassi wrote: >Hi; > >On Wed, 2006-06-21 at 13:35 -0400, Matthias Clasen wrote: > > >>So, with GTK+ 2.10 on the finish line, I tried to make a quick >>list of things we may want to look at for 2.12, as input to >>GUADEC discussions. >> >> Heh, unfortunately I wont be at GAUDEC to discuss any of this (which I am sure would be a great experience), so I'll do my best from the mailing lists and irc to tag along :) In light of the new Gtk Builder code getting in, I would like to propose that we depricate UIManager completely in favour of the Gtk Builder and provide a unified front for the creation of GObjects parsed from ui descriptions (or whatever the new "glade file" is to be called). My proposals to address issues of UI merging and handling of GtkActions are described in detail in these to emails: http://mail.gnome.org/archives/gtk-devel-list/2006-May/msg00157.html http://mail.gnome.org/archives/gtk-devel-list/2006-May/msg00166.html Please let me know your thoughts on the proposition and design, if accepted; I am sure I can get all this "ui merging/action subscription" stuff working properly inside of one month... hopefully leaving time enough for it to mature before 2.12. Cheers, -Tristan From sven@gimp.org Thu Jun 22 14:23:14 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C09883B062A for ; Thu, 22 Jun 2006 14:23:14 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16777-05 for ; Thu, 22 Jun 2006 14:23:11 -0400 (EDT) Received: from buzzloop.caiaq.de (buzzloop.caiaq.de [212.112.241.133]) by menubar.gnome.org (Postfix) with ESMTP id 26D1A3B05BF for ; Thu, 22 Jun 2006 14:23:08 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by buzzloop.caiaq.de (Postfix) with ESMTP id 194427F402E; Thu, 22 Jun 2006 20:23:10 +0200 (CEST) Received: from buzzloop.caiaq.de ([127.0.0.1]) by localhost (buzzloop [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11007-03; Thu, 22 Jun 2006 20:23:09 +0200 (CEST) Received: from [192.168.3.158] (i577B6734.versanet.de [87.123.103.52]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by buzzloop.caiaq.de (Postfix) with ESMTP id A11AD7F4024; Thu, 22 Jun 2006 20:23:09 +0200 (CEST) Subject: Re: Looking beyond 2.10 From: Sven Neumann To: Joachim Noreiko In-Reply-To: <20060622142814.59921.qmail@web32406.mail.mud.yahoo.com> References: <20060622142814.59921.qmail@web32406.mail.mud.yahoo.com> Content-Type: text/plain Date: Thu, 22 Jun 2006 20:22:49 +0200 Message-Id: <1151000569.12681.22.camel@bender> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.692 tagged_above=-999 required=2 tests=[AWL=0.907, BAYES_00=-2.599] X-Spam-Score: -1.692 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 18:23:15 -0000 Hi, On Thu, 2006-06-22 at 15:28 +0100, Joachim Noreiko wrote: > I feel like I'm talking to myself here, but please > could someone look at adding a help button to the fileselector. GIMP has done that for quite a while already, so there's nothing that would keep an application from adding a Help button to the file-chooser. What's the point of adding one by default? By default it won't be connected to anything useful and what good is a help button that does nothing when the user clicks it? Sven From murrayc@murrayc.com Thu Jun 22 14:45:17 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 2C2CB3B0649 for ; Thu, 22 Jun 2006 14:45:17 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18110-06 for ; Thu, 22 Jun 2006 14:45:13 -0400 (EDT) Received: from swarthymail-a1.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by menubar.gnome.org (Postfix) with ESMTP id A79253B083A for ; Thu, 22 Jun 2006 14:45:12 -0400 (EDT) Received: from noname (p5497EA12.dip.t-dialin.net [84.151.234.18]) by swarthymail-a1.dreamhost.com (Postfix) with ESMTP id 71BF690FA6; Thu, 22 Jun 2006 11:45:00 -0700 (PDT) Subject: Re: GTK+ 2.10, the endgame From: Murray Cumming To: Emmanuele Bassi In-Reply-To: <1150502750.2668.12.camel@localhost> References: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> <1150390229.17566.191.camel@cacharro.xalalinux.org> <1150391737.3187.33.camel@dhcp83-98.boston.redhat.com> <1150447930.5806.4.camel@localhost.localdomain> <1150502750.2668.12.camel@localhost> Content-Type: text/plain Date: Thu, 22 Jun 2006 20:44:54 +0200 Message-Id: <1151001894.5804.33.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.477 tagged_above=-999 required=2 tests=[AWL=0.122, BAYES_00=-2.599] X-Spam-Score: -2.477 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 18:45:17 -0000 On Sat, 2006-06-17 at 01:05 +0100, Emmanuele Bassi wrote: > Hi Murray, > > On Fri, 2006-06-16 at 10:52 +0200, Murray Cumming wrote: > > I'm also concerned about the recent files stuff. Do we now have > > UIManager integration of that? > > No, and I am to blame because I had less time to spend on fixing this > issue. > > Mostly, I've been stuck on how to implement an action for both the menu > and toolbars using the same tag. In the meantime, a nice and clean way > to integrate the GtkRecentChooserMenu inside a GtkUIManager is to > subclass GtkAction into a custom action that automatically adds a recent > chooser menu to the menu item it creates, and use a placeholder in the > UI definition (most applications using EggRecentViewUIManager already > have that placeholder present). > > A working example is available here: > > http://www.gnome.org/~ebassi/test-uimanager.c > > The action code itself is one hundred lines long and can easily be > hidden inside an helper file; it's approximately how GtkRecentAction > would be implemented, anyway. I hereby give permission to do whatever > you want to do with it. > > I understand that it's sub-optimal, and hopefully this should really go > away once there's an action inside GTK. Do you feel that the existing API might need to be changed to add this to a future version of GTK+? For instance, would it need need existing classes to implement new interfaces, or add new signals? -- Murray Cumming murrayc@murrayc.com www.murrayc.com www.openismus.com From ebassi@gmail.com Thu Jun 22 15:19:39 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id F26233B077F for ; Thu, 22 Jun 2006 15:19:38 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20426-04 for ; Thu, 22 Jun 2006 15:19:35 -0400 (EDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.186]) by menubar.gnome.org (Postfix) with ESMTP id 2A7653B062A for ; Thu, 22 Jun 2006 15:19:35 -0400 (EDT) Received: by nf-out-0910.google.com with SMTP id h2so304101nfe for ; Thu, 22 Jun 2006 12:19:34 -0700 (PDT) Received: by 10.48.242.3 with SMTP id p3mr1697803nfh; Thu, 22 Jun 2006 12:19:34 -0700 (PDT) Received: from ?192.168.1.70? ( [86.136.65.180]) by mx.gmail.com with ESMTP id z73sm2097413nfb.2006.06.22.12.19.33; Thu, 22 Jun 2006 12:19:33 -0700 (PDT) Subject: Re: GTK+ 2.10, the endgame From: Emmanuele Bassi To: Murray Cumming In-Reply-To: <1151001894.5804.33.camel@localhost.localdomain> References: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> <1150390229.17566.191.camel@cacharro.xalalinux.org> <1150391737.3187.33.camel@dhcp83-98.boston.redhat.com> <1150447930.5806.4.camel@localhost.localdomain> <1150502750.2668.12.camel@localhost> <1151001894.5804.33.camel@localhost.localdomain> Content-Type: text/plain Date: Thu, 22 Jun 2006 20:19:32 +0100 Message-Id: <1151003972.5346.29.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.371 tagged_above=-999 required=2 tests=[AWL=0.229, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.371 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 19:19:39 -0000 Hi Murray; On Thu, 2006-06-22 at 20:44 +0200, Murray Cumming wrote: > > The action code itself is one hundred lines long and can easily be > > hidden inside an helper file; it's approximately how GtkRecentAction > > would be implemented, anyway. I hereby give permission to do whatever > > you want to do with it. > > > > I understand that it's sub-optimal, and hopefully this should really go > > away once there's an action inside GTK. > > Do you feel that the existing API might need to be changed to add this > to a future version of GTK+? For instance, would it need need existing > classes to implement new interfaces, or add new signals? The point is: I don't know. :-) The currently unresolved issue is that I can't find a way to use this UI definition:

which is the "right" way to offer a submenu and a menu inside a toolbar item. The only case where I know for sure would require adding API is the case where you want an inlined recent files list - as it would require the ability to create a list of menu items instead of a single widget with the same GtkAction. At this point, I'd like a UIManager author/guru to step in and see if I'm doing something wrong. The bug is #338843 [1]. +++ http://bugzilla.gnome.org/show_bug.cgi?id=338843 -- Emmanuele Bassi, E: ebassi@gmail.com W: http://www.emmanuelebassi.net B: http://log.emmanuelebassi.net From jnoreiko@yahoo.com Thu Jun 22 17:19:57 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 48DC33B07DC for ; Thu, 22 Jun 2006 17:19:57 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27254-05 for ; Thu, 22 Jun 2006 17:19:56 -0400 (EDT) Received: from web32404.mail.mud.yahoo.com (web32404.mail.mud.yahoo.com [68.142.207.197]) by menubar.gnome.org (Postfix) with SMTP id 6C40C3B0601 for ; Thu, 22 Jun 2006 17:19:56 -0400 (EDT) Received: (qmail 9697 invoked by uid 60001); 22 Jun 2006 21:19:55 -0000 Message-ID: <20060622211955.9695.qmail@web32404.mail.mud.yahoo.com> Received: from [172.216.98.138] by web32404.mail.mud.yahoo.com via HTTP; Thu, 22 Jun 2006 22:19:55 BST Date: Thu, 22 Jun 2006 22:19:55 +0100 (BST) From: Joachim Noreiko Subject: Re: Looking beyond 2.10 To: Sven Neumann In-Reply-To: <1151000569.12681.22.camel@bender> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.693 tagged_above=-999 required=2 tests=[AWL=-0.741, BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2, DNS_FROM_RFC_WHOIS=1.447] X-Spam-Score: -1.693 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 21:19:57 -0000 --- Sven Neumann wrote: > Hi, > > On Thu, 2006-06-22 at 15:28 +0100, Joachim Noreiko > wrote: > > > I feel like I'm talking to myself here, but please > > could someone look at adding a help button to the > fileselector. > > GIMP has done that for quite a while already, so > there's nothing that > would keep an application from adding a Help button > to the file-chooser. > What's the point of adding one by default? By > default it won't be > connected to anything useful and what good is a help > button that does > nothing when the user clicks it? The documentation for the fileselector has been in the GNOME Desktop User Guide since 2.14. I'm sure I posted on this list when I wrote it. ___________________________________________________________ All new Yahoo! Mail "The new Interface is stunning in its simplicity and ease of use." - PC Magazine http://uk.docs.yahoo.com/nowyoucan.html From scott@asofyet.org Thu Jun 22 22:52:08 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 046A73B05F9 for ; Thu, 22 Jun 2006 22:52:08 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09189-02 for ; Thu, 22 Jun 2006 22:52:06 -0400 (EDT) Received: from looneymail-a2.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by menubar.gnome.org (Postfix) with ESMTP id 39B703B071C for ; Thu, 22 Jun 2006 22:52:06 -0400 (EDT) Received: from [192.168.0.100] (unknown [74.131.115.107]) by looneymail-a2.dreamhost.com (Postfix) with ESMTP id 2C0F016E8CD for ; Thu, 22 Jun 2006 19:52:05 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v750) In-Reply-To: <20060622211955.9695.qmail@web32404.mail.mud.yahoo.com> References: <20060622211955.9695.qmail@web32404.mail.mud.yahoo.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: muppet Subject: Re: Looking beyond 2.10 Date: Thu, 22 Jun 2006 22:51:48 -0400 To: GTK+ development mailing list X-Mailer: Apple Mail (2.750) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.558 tagged_above=-999 required=2 tests=[AWL=0.041, BAYES_00=-2.599] X-Spam-Score: -2.558 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2006 02:52:08 -0000 On Jun 22, 2006, at 5:19 PM, Joachim Noreiko wrote: > > --- Sven Neumann wrote: > >> GIMP has done that for quite a while already, so there's nothing >> that would keep an application from adding a Help button to the >> file-chooser. What's the point of adding one by default? By >> default it won't be connected to anything useful and what good is >> a help button that does nothing when the user clicks it? > > The documentation for the fileselector has been in the GNOME > Desktop User Guide since 2.14. I'm sure I posted on this list when > I wrote it. That doesn't do much good for gtk+ environments that don't involve GNOME. -- Jolt is my co-pilot. -- Slogan on a giant paper airplane hung in Lobby 7 at MIT. http://hacks.mit.edu/ From magnusbe@algonet.se Fri Jun 23 05:33:19 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 0D0353B0591 for ; Fri, 23 Jun 2006 05:33:19 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31880-05 for ; Fri, 23 Jun 2006 05:33:17 -0400 (EDT) Received: from pne-smtpout2-sn2.hy.skanova.net (pne-smtpout2-sn2.hy.skanova.net [81.228.8.164]) by menubar.gnome.org (Postfix) with ESMTP id 294473B041F for ; Fri, 23 Jun 2006 05:33:16 -0400 (EDT) Received: from feathers (83.252.145.175) by pne-smtpout2-sn2.hy.skanova.net (7.2.072.1) (authenticated as u73906364) id 449A811D0002C366 for gtk-devel-list@gnome.org; Fri, 23 Jun 2006 11:33:15 +0200 Date: Fri, 23 Jun 2006 12:31:05 +0200 From: Magnus Bergman To: GTK+ devel list Subject: Problems making loaders for header-less images Message-ID: <20060623123105.1589fed8@feathers> X-Mailer: Sylpheed-Claws 2.3.0 (GTK+ 2.8.16; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.522 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, TW_GD=0.077] X-Spam-Score: -2.522 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2006 09:33:19 -0000 I've made a couple of gdk-pixbuf loaders for formats that cannot be finger printed using a pattern, because they totaly lack some kind of header or that information is located at the end of the file. This has causes me the following problems: * If one loader handles several (similar) formats that cannot be distinguished from each other by looking at the first bytes. Then gdk-pixbuf uses other means to distinguish between them (extension or mime-type) but the information about what the match was based on is unavailable to loader (or am I missing something). Can this be solved is some way (except by making a different loader for each variant)? Example: There is an image format called pi1 (the most common format on the Atari ST). It consists of one word telling about the resolution, the palette and a copy of the screen memory. A variant of the format is called pc1 and has the only difference that the screen memory image is compressed. It is easy to distinguish between them using the extension or by looking at the file size (pi1 has a fixed size of 32066 bytes while pc1 is always smaller). * If a loader doesn't provide any fingerprinting pattern gdk-pixbuf causes a segfault at runtime then trying to load a picture in any format. Is the loader required to provide at least one pattern or is this a bug? * If the only thing that is known about the format is that it starts with one or more zeros, then gdk-pixbuf-query-loaders will refuse to register the loader because it considers the pattern to be empty. This could be avoided to checking the length of the mask field instead to the prefix field. A bug? From gcottenc@gmail.com Fri Jun 23 07:57:54 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id DA1E43B0678 for ; Fri, 23 Jun 2006 07:57:54 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08025-10 for ; Fri, 23 Jun 2006 07:57:53 -0400 (EDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.192]) by menubar.gnome.org (Postfix) with ESMTP id 7D8543B01A4 for ; Fri, 23 Jun 2006 07:57:53 -0400 (EDT) Received: by wx-out-0102.google.com with SMTP id s6so466104wxc for ; Fri, 23 Jun 2006 04:57:53 -0700 (PDT) Received: by 10.70.103.17 with SMTP id a17mr4494204wxc; Fri, 23 Jun 2006 04:57:52 -0700 (PDT) Received: by 10.70.46.6 with HTTP; Fri, 23 Jun 2006 04:57:52 -0700 (PDT) Message-ID: Date: Fri, 23 Jun 2006 13:57:52 +0200 From: "Guillaume Cottenceau" To: "Matthias Clasen" Subject: Re: Fwd: GTK+ 2.10, the endgame In-Reply-To: <1150895599.15532.80.camel@golem.boston.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> <1150895599.15532.80.camel@golem.boston.redhat.com> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.564 tagged_above=-999 required=2 tests=[AWL=0.036, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.564 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2006 11:57:55 -0000 Hi Matthias, > The online documentation is still at 2.9.2. I hope to find time > to update it to 2.9.4 before leaving for GUADEC tomorrow. Please warn us when the online API documentation regarding new symbols is fully freezed for 2.10 so that we can start working on adding the new symbols in bindings. Thanks! -- Guillaume Cottenceau - http://zarb.org/~gc/ From hfiguiere@teaser.fr Fri Jun 23 11:50:42 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 100083B04A7 for ; Fri, 23 Jun 2006 11:50:42 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21632-05 for ; Fri, 23 Jun 2006 11:50:39 -0400 (EDT) Received: from xandros.com (smtp1.xandros.com [209.87.238.70]) by menubar.gnome.org (Postfix) with ESMTP id 83AC63B0907 for ; Fri, 23 Jun 2006 11:50:33 -0400 (EDT) Received: from [172.16.1.95] (unknown [209.87.238.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by xandros.com (Postfix) with ESMTP id 6A6F223033 for ; Fri, 23 Jun 2006 11:50:32 -0400 (EDT) Message-ID: <449C0DC7.60502@teaser.fr> Date: Fri, 23 Jun 2006 11:50:31 -0400 From: Hubert Figuiere User-Agent: Thunderbird 1.5.0.4 (X11/20060615) MIME-Version: 1.0 To: gtk-devel-list@gnome.org Subject: Re: Looking beyond 2.10 References: <20060622142814.59921.qmail@web32406.mail.mud.yahoo.com> <1151000569.12681.22.camel@bender> In-Reply-To: <1151000569.12681.22.camel@bender> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.544 tagged_above=-999 required=2 tests=[AWL=0.055, BAYES_00=-2.599] X-Spam-Score: -2.544 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2006 15:50:42 -0000 Sven Neumann wrote: > GIMP has done that for quite a while already, so there's nothing that > would keep an application from adding a Help button to the file-chooser. > What's the point of adding one by default? By default it won't be > connected to anything useful and what good is a help button that does > nothing when the user clicks it? Why not putting it in only if the signal is connected ? (a signal like "help_requested"). Hub From gjc@inescporto.pt Fri Jun 23 18:23:20 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 9B8D83B0847 for ; Fri, 23 Jun 2006 18:23:20 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08741-04 for ; Fri, 23 Jun 2006 18:23:19 -0400 (EDT) Received: from animal.inescn.pt (animal.inescn.pt [194.117.24.9]) by menubar.gnome.org (Postfix) with ESMTP id AC38C3B0971 for ; Fri, 23 Jun 2006 18:23:18 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by animal.inescn.pt (8.13.6/8.13.6/7) with ESMTP id k5NMNG4Z018417; Fri, 23 Jun 2006 23:23:17 +0100 (WEST) Received: from pong.inescporto.pt (pong.inescn.pt [194.117.26.74]) by animal.inescn.pt (8.13.6/8.13.6/5) with ESMTP id k5NMN5ql018402; Fri, 23 Jun 2006 23:23:05 +0100 (WEST) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by pong.inescporto.pt (Postfix) with ESMTP id 31501155721; Fri, 23 Jun 2006 23:19:37 +0100 (WEST) Subject: Re: Looking beyond 2.10 From: "Gustavo J. A. M. Carneiro" To: Matthias Clasen In-Reply-To: <1150911355.15532.100.camel@golem.boston.redhat.com> References: <1150911355.15532.100.camel@golem.boston.redhat.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-2prtuoBhNnmmz3lcPkNU" Date: Fri, 23 Jun 2006 23:22:59 +0100 Message-Id: <1151101379.5189.5.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 X-Virus-Scanned: by amavisd-new at inescporto.pt X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.428 tagged_above=-999 required=2 tests=[AWL=0.038, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.428 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2006 22:23:20 -0000 --=-2prtuoBhNnmmz3lcPkNU Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Qua, 2006-06-21 =C3=A0s 13:35 -0400, Matthias Clasen escreveu: > So, with GTK+ 2.10 on the finish line, I tried to make a quick > list of things we may want to look at for 2.12, as input to > GUADEC discussions. >=20 > Patches almost ready to go in >=20 > - libglade integration > - new tooltips api >=20 >=20 > Stuff that needs more work >=20 > - introspection I'm willing to do some work in introspection. However, if you say it needs more work then I think you should identify precisely what work needs to be done. I could try guessing, but that usually leads to patches sitting in bugzilla for whole release cycles (e.g. #313268). Regards. --=20 Gustavo J. A. M. Carneiro The universe is always one step beyond logic --=-2prtuoBhNnmmz3lcPkNU Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta =?ISO-8859-1?Q?=E9?= uma parte de mensagem assinada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQBEnGnD2XoHyMdS6TARAk0JAJ95rFWntIs1xJ0hPTYMBwXdg26PgACeJo0x DrkoftT0jbf/hSym/poi0Uo= =WVRK -----END PGP SIGNATURE----- --=-2prtuoBhNnmmz3lcPkNU-- From jnoreiko@yahoo.com Sat Jun 24 03:40:19 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id EBA9B3B00F5 for ; Sat, 24 Jun 2006 03:40:18 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30651-07 for ; Sat, 24 Jun 2006 03:40:17 -0400 (EDT) Received: from web32401.mail.mud.yahoo.com (web32401.mail.mud.yahoo.com [68.142.207.194]) by menubar.gnome.org (Postfix) with SMTP id BD1E03B0194 for ; Sat, 24 Jun 2006 03:40:16 -0400 (EDT) Received: (qmail 229 invoked by uid 60001); 24 Jun 2006 07:40:15 -0000 Message-ID: <20060624074015.227.qmail@web32401.mail.mud.yahoo.com> Received: from [172.212.40.3] by web32401.mail.mud.yahoo.com via HTTP; Sat, 24 Jun 2006 08:40:15 BST Date: Sat, 24 Jun 2006 08:40:15 +0100 (BST) From: Joachim Noreiko Subject: Re: Looking beyond 2.10 To: gtk-devel-list@gnome.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.681 tagged_above=-999 required=2 tests=[AWL=-0.729, BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2, DNS_FROM_RFC_WHOIS=1.447] X-Spam-Score: -1.681 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2006 07:40:19 -0000 Message: 6 Date: Thu, 22 Jun 2006 22:51:48 -0400 From: muppet Subject: Re: Looking beyond 2.10 > The documentation for the fileselector has been in the GNOME > Desktop User Guide since 2.14. I'm sure I posted on this list when > I wrote it. That doesn't do much good for gtk+ environments that don't involve GNOME. -------------- Then figure out some way for it to detect whether it's on GNOME or not, maybe? Dialog boxes used in GNOME required help buttons, especially ones with as many features as the fileselector. Please could somebody look into this? I put a lot of work into writing the docs, and that's not a huge amount of use until it's linked to. ___________________________________________________________ Inbox full of spam? Get leading spam protection and 1GB storage with All New Yahoo! Mail. http://uk.docs.yahoo.com/nowyoucan.html From macfreesoft@free.fr Sat Jun 24 05:56:35 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C31133B02D5 for ; Sat, 24 Jun 2006 05:56:35 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05338-06 for ; Sat, 24 Jun 2006 05:56:33 -0400 (EDT) Received: from smtp010.mail.ukl.yahoo.com (smtp010.mail.ukl.yahoo.com [217.12.11.79]) by menubar.gnome.org (Postfix) with SMTP id 3D48E3B02B2 for ; Sat, 24 Jun 2006 05:56:33 -0400 (EDT) Received: (qmail 6982 invoked from network); 24 Jun 2006 09:56:32 -0000 Received: from unknown (HELO ?192.168.1.10?) (a?gillaizeau@217.66.126.141 with plain) by smtp010.mail.ukl.yahoo.com with SMTP; 24 Jun 2006 09:56:32 -0000 Message-ID: <449D0C4E.504@free.fr> Date: Sat, 24 Jun 2006 11:56:30 +0200 From: Aymeric GILLAIZEAU User-Agent: Thunderbird 1.5 (Macintosh/20051201) MIME-Version: 1.0 To: Easy B Subject: Gtk+.framework snapshot Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.033 tagged_above=-999 required=2 tests=[BAYES_05=-1.11, TW_GT=0.077] X-Spam-Score: -1.033 X-Spam-Level: X-Mailman-Approved-At: Sat, 24 Jun 2006 06:24:14 -0400 Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2006 09:56:36 -0000 > Hi guys > > Well I wasn't that happy with the result I got from the mono scripts > so I pretty much rewrote them. I now install everything into one > framework. I still don't have libtiff and jpeg support though. How is > the best way to make the gtk configure look for libtiff 3.8.2? I saw > that it looks for 3.4. Do I have to patch configure? > > Anyway, who's interested can give my installer a try. It installs the > framework into /Library/Frameworks and Gtk-Demo into /Applications. I > managed to compile one of my small apps by setting PKG_CONFIG_PATH to > /Library/Frameworks/Gtk+.framework/Libraries/pkgconfig/ and > ./configure, make. > > To make an application bundles I use this script: > http://www.easyb.ch/files/bundleApp.sh > > The Installer you can download here: > http://www.easyb.ch/files/Gtk%2B-2.9.1%20Framework%20snapshot.pkg.zip > > Cheers, > Ezra. Why to not use the already built Frameworks used by Scribus ? Instead of having many times the same things, it is present once and used by anyone. The problem with OpenSource is that everyone makes his cooking in his place without never taking consideration in the work others has already done. It could save time, also use less space on the drive, and so save room. http://www.scribus.net/index.php?name=Sections&req=viewarticle&artid=3&page=1 > ome support libraries, which should be moved to /Library/Frameworks : > Qt.framework > Freetype.framework > Fontconfig2.framework > libart.framework > libexpat.framework > libjpeg.framework > liblcms.framework > libpng.framework > libtiff.framework ___________________________________________________________________________ Yahoo! Mail rinvente le mail ! Dcouvrez le nouveau Yahoo! Mail et son interface rvolutionnaire. http://fr.mail.yahoo.com From alex@halogen-dg.com Sat Jun 24 08:41:32 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 92B9B3B013A for ; Sat, 24 Jun 2006 08:41:32 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13862-09 for ; Sat, 24 Jun 2006 08:41:31 -0400 (EDT) Received: from appserver.halogen.kharkov.ua (appserver.halogen.kharkov.ua [217.144.70.65]) by menubar.gnome.org (Postfix) with ESMTP id 256C33B00FB for ; Sat, 24 Jun 2006 08:41:31 -0400 (EDT) Received: (qmail 29949 invoked from network); 24 Jun 2006 15:41:32 +0300 Received: from dom.koval.kharkov.ua (217.144.70.182) by alex.halogen.kharkov.ua with AES256-SHA encrypted SMTP; 24 Jun 2006 15:41:32 +0300 Date: Sat, 24 Jun 2006 15:45:30 +0300 (EEST) From: alex@halogen-dg.com X-X-Sender: alex@dom.koval.kharkov.ua To: gtk-devel-list@gnome.org Subject: gtk file open dialog usability. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-0.858 tagged_above=-999 required=2 tests=[AWL=-0.709, BAYES_05=-1.11, NO_REAL_NAME=0.961] X-Spam-Score: -0.858 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2006 12:41:32 -0000 Anyone except me also disappointed by it? Any way how we can have old file open dialog back? I really find it very frustating and explained why, with some images here: http://www.halogen-dg.com/alex/file_selection_dialog/GtkFileOpenBadUsability -- Alex V. Koval http://www.halogen-dg.com/ http://www.zwarehouse.org/ From gnome-gtk-devel-list@m.gmane.org Sat Jun 24 08:49:58 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id F15263B00A8 for ; Sat, 24 Jun 2006 08:49:57 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14302-05 for ; Sat, 24 Jun 2006 08:49:55 -0400 (EDT) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by menubar.gnome.org (Postfix) with ESMTP id 402703B00FB for ; Sat, 24 Jun 2006 08:49:55 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Fu7a8-0004yS-Mc for gtk-devel-list@gnome.org; Sat, 24 Jun 2006 14:49:48 +0200 Received: from 84.52.165.220 ([84.52.165.220]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 24 Jun 2006 14:49:48 +0200 Received: from jernej.listsonly by 84.52.165.220 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 24 Jun 2006 14:49:48 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gtk-devel-list@gnome.org From: Jernej =?utf-7?Q?Simon+AQ0-i+AQ0-?= Subject: Re: gtk file open dialog usability. Date: Sat, 24 Jun 2006 14:49:37 +0200 Lines: 9 Message-ID: <10umqokepyu8y.10vhe4alqj04.dlg@40tude.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset="utf-7" Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 84.52.165.220 User-Agent: 40tude_Dialog/2.0.15.84 (cfc06cd9.460.419) X-Face: BOCQpf4)pfW>6Ya?'@oBT]=LBF; <6`_r[6pwqLggP!RG:*D)^Fz; O(I'n(FwJ{]5lo>g.H. _,Z:_`nLsfz]]8V'&9OmX)o-bXd?(P|CO=@5}[y\0rH9!AN&Qt:GXC(r!1}$q@@C]x`](7+#C]WRzw L|0W}vdFR/b@AFWIw~ X-Ultimate-Answer: 42 Sender: news X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.008 tagged_above=-999 required=2 tests=[AWL=0.016, BAYES_00=-2.599, FROM_EXCESS_QP=0, RCVD_NUMERIC_HELO=1.5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, TW_GT=0.077] X-Spam-Score: -1.008 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2006 12:49:58 -0000 On Sat, 24 Jun 2006 15:45:30 +-0300 (EEST), alex@halogen-dg.com wrote: > Anyone except me also disappointed by it? Search the archives, you're far from being the only one. -- < Jernej Simon+AQ0-i+AQ0- >< http://deepthought.ena.si/ > < Contact address: >< jernej simoncic at isg si > From alex@halogen-dg.com Sat Jun 24 09:01:55 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id F3A283B00A8 for ; Sat, 24 Jun 2006 09:01:54 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15013-06 for ; Sat, 24 Jun 2006 09:01:54 -0400 (EDT) Received: from appserver.halogen.kharkov.ua (appserver.halogen.kharkov.ua [217.144.70.65]) by menubar.gnome.org (Postfix) with ESMTP id 388713B0490 for ; Sat, 24 Jun 2006 09:01:53 -0400 (EDT) Received: (qmail 32296 invoked from network); 24 Jun 2006 16:01:54 +0300 Received: from dom.koval.kharkov.ua (217.144.70.182) by alex.halogen.kharkov.ua with AES256-SHA encrypted SMTP; 24 Jun 2006 16:01:54 +0300 Date: Sat, 24 Jun 2006 16:05:52 +0300 (EEST) From: alex@halogen-dg.com X-X-Sender: alex@dom.koval.kharkov.ua To: gtk-devel-list@gnome.org Subject: Re: gtk file open dialog usability. In-Reply-To: <10umqokepyu8y.10vhe4alqj04.dlg@40tude.net> Message-ID: References: <10umqokepyu8y.10vhe4alqj04.dlg@40tude.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.533 tagged_above=-999 required=2 tests=[AWL=0.028, BAYES_00=-2.599, NO_REAL_NAME=0.961, TW_GT=0.077] X-Spam-Score: -1.533 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2006 13:01:55 -0000 Hi Jernej On Sat, 24 Jun 2006, Jernej Simon+AQ0-i+AQ0- wrote: > On Sat, 24 Jun 2006 15:45:30 +-0300 (EEST), alex@halogen-dg.com wrote: > >> Anyone except me also disappointed by it? I am happy that people noticed that, too. The question is what can we do to fix this? My feeling is that at least 2 things could be done: 1. Make automatic selection of file optional (like its being done in KDE, in grey) 2. Do not display additional file open dialog when I *already* typed file name. > > Search the archives, you're far from being the only one. > BTW, before doing this post I've tried to search for "file dialog usability GTK". To my regret mail.gnome.org mailman search is not working ("The requested URL /mailman/search was not found on this server."),so I searched google a little, did not found any good results and posted here... Althrough this search returns more results: http://www.google.com.ua/search?q=gtk+file+open+usability&start=0&ie=utf-8&oe=utf-8&client=firefox-a&rls=org.mozilla:en-US:official Alex From g.tagliaretti@gmail.com Sat Jun 24 09:53:34 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 2C1C83B02E0 for ; Sat, 24 Jun 2006 09:53:34 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17447-04 for ; Sat, 24 Jun 2006 09:53:33 -0400 (EDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.178]) by menubar.gnome.org (Postfix) with ESMTP id 054D13B0228 for ; Sat, 24 Jun 2006 09:53:32 -0400 (EDT) Received: by py-out-1112.google.com with SMTP id i49so1099450pyi for ; Sat, 24 Jun 2006 06:52:59 -0700 (PDT) Received: by 10.35.99.14 with SMTP id b14mr3541165pym; Sat, 24 Jun 2006 06:52:56 -0700 (PDT) Received: by 10.35.132.18 with HTTP; Sat, 24 Jun 2006 06:52:56 -0700 (PDT) Message-ID: <35bf41160606240652s3da0fe6brd3915cd84c601114@mail.gmail.com> Date: Sat, 24 Jun 2006 15:52:56 +0200 From: "Gian Mario Tagliaretti" To: "alex@halogen-dg.com" Subject: Re: gtk file open dialog usability. In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.257 tagged_above=-999 required=2 tests=[AWL=0.066, BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2, SPF_PASS=-0.001, TW_GT=0.077] X-Spam-Score: -2.257 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2006 13:53:34 -0000 2006/6/24, alex@halogen-dg.com : > > Anyone except me also disappointed by it? > Any way how we can have old file open dialog back? code not complain :) > I really find it very frustating and explained > why, with some images here: > http://www.halogen-dg.com/alex/file_selection_dialog/GtkFileOpenBadUsability are you using gtk+ 2.9.x ? ciao -- Gian Mario Tagliaretti http://www.parafernalia.org/pygtk/ http://pygstdocs.berlios.de From timj@gtk.org Sat Jun 24 13:36:49 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 6B4403B006E; Sat, 24 Jun 2006 13:36:49 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27591-06; Sat, 24 Jun 2006 13:36:45 -0400 (EDT) Received: from holken.mikan.net (holken.mikan.net [83.145.56.183]) by menubar.gnome.org (Postfix) with ESMTP id C28AD3B06ED; Sat, 24 Jun 2006 13:36:44 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by holken.mikan.net (Postfix) with ESMTP id 59BF93352A5; Sat, 24 Jun 2006 19:36:26 +0200 (CEST) Received: from holken.mikan.net ([127.0.0.1]) by localhost (holken.mikan.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27952-05; Sat, 24 Jun 2006 19:36:22 +0200 (CEST) Received: from birnet.org (c135173.adsl.hansenet.de [213.39.135.173]) by holken.mikan.net (Postfix) with ESMTP id E12711844A; Sat, 24 Jun 2006 19:36:21 +0200 (CEST) Received: from master.birnet.private (localhost.localdomain [127.0.0.1]) by birnet.org (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k5OHaLjt023300 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 24 Jun 2006 19:36:21 +0200 Received: (from timj@localhost) by master.birnet.private (8.13.4/8.13.4/Submit) id k5OHZcXs023295; Sat, 24 Jun 2006 19:35:38 +0200 Date: Sat, 24 Jun 2006 19:35:38 +0200 (CEST) From: Tim Janik X-X-Sender: timj@master.birnet.private To: Gtk+ Developers Subject: Re: GTK+ meeting at GUADEC (Re: GTK+ 2.10, the endgame) In-Reply-To: Message-ID: References: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at holken.mikan.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.637 tagged_above=-999 required=2 tests=[AWL=-0.662, BAYES_05=-1.11, FORGED_RCVD_HELO=0.135] X-Spam-Score: -1.637 X-Spam-Level: X-Mailman-Approved-At: Sat, 24 Jun 2006 13:47:30 -0400 Cc: Federico Mena Quintero , Jonathan Blandford , Tim Janik , sandmann@daimi.au.dk, cworth@cworth.org, Komulainen Tommi , Alex Larsson , Michael Natterer , Kristian Rietveld , Matthias Clasen , Richard Hult , johan@gnome.org, michael meeks X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2006 17:36:49 -0000 On Thu, 15 Jun 2006, Tim Janik wrote: > the plan for that was to send out en email next friday/saturday (i.e > right at the guadec start) to figure/suggest dates suitable for > everyone to attend. we have gotten a room for the Gtk+ meeting now. it's on Sunday the 25th from 16:00-18:00 in the blue room (at the conference facility, second floor). --- ciaoTJ From torriem@chem.byu.edu Sun Jun 25 01:08:26 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id EA0E73B0079 for ; Sun, 25 Jun 2006 01:08:25 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17289-04 for ; Sun, 25 Jun 2006 01:08:22 -0400 (EDT) Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [63.240.77.83]) by menubar.gnome.org (Postfix) with ESMTP id ACB1F3B00A6 for ; Sun, 25 Jun 2006 01:08:22 -0400 (EDT) Received: from enterprise.local.lan (c-24-2-75-5.hsd1.ut.comcast.net[24.2.75.5]) by comcast.net (sccrmhc13) with ESMTP id <2006062505073001300me7qte>; Sun, 25 Jun 2006 05:07:31 +0000 Received: from enterprise.local.lan (enterprise.local.lan [127.0.0.1]) by enterprise.local.lan (8.13.1/8.12.8) with ESMTP id k5P57TFs002388 for ; Sat, 24 Jun 2006 23:07:29 -0600 Received: (from torriem@localhost) by enterprise.local.lan (8.13.1/8.13.1/Submit) id k5P57T1Z002387 for gtk-devel-list@gnome.org; Sat, 24 Jun 2006 23:07:29 -0600 X-Authentication-Warning: enterprise.local.lan: torriem set sender to torriem@chem.byu.edu using -f Subject: Re: Looking beyond 2.10 From: Michael Torrie To: gtk-devel-list@gnome.org In-Reply-To: References: <1150911355.15532.100.camel@golem.boston.redhat.com> <4499982C.1010004@teaser.fr> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Sat, 24 Jun 2006 23:07:29 -0600 Message-Id: <1151212049.32440.11.camel@enterprise.local.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-7) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.377 tagged_above=-999 required=2 tests=[AWL=0.010, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, TW_GT=0.077] X-Spam-Score: -2.377 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jun 2006 05:08:26 -0000 On Wed, 2006-06-21 at 18:26 -0400, Matthias Clasen wrote: > > I'm about to pick Qt as a toolkit for a personal project just because of > > that. > > Good luck. I was in the same boat as Hubert. I also ended up picking Qt. Although I like GTK much better, Qt was the best choice given the circumstances. I have not regretted it. But, as soon as GTK is fully supported on OS X, I will abandon Qt entirely, as GTK is cleaner, a little easier to work with, and, ironically, has better C++ bindings than Qt. > > Matthias > _______________________________________________ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-devel-list > From torriem@chem.byu.edu Sun Jun 25 01:21:50 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 36FD43B01F4 for ; Sun, 25 Jun 2006 01:21:50 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18141-02 for ; Sun, 25 Jun 2006 01:21:47 -0400 (EDT) Received: from sccrmhc14.comcast.net (sccrmhc14.comcast.net [204.127.200.84]) by menubar.gnome.org (Postfix) with ESMTP id DD6353B02BD for ; Sun, 25 Jun 2006 01:21:46 -0400 (EDT) Received: from enterprise.local.lan (c-24-2-75-5.hsd1.ut.comcast.net[24.2.75.5]) by comcast.net (sccrmhc14) with ESMTP id <2006062505211801400apa3je>; Sun, 25 Jun 2006 05:21:19 +0000 Received: from enterprise.local.lan (enterprise.local.lan [127.0.0.1]) by enterprise.local.lan (8.13.1/8.12.8) with ESMTP id k5P5LHWa002930; Sat, 24 Jun 2006 23:21:17 -0600 Received: (from torriem@localhost) by enterprise.local.lan (8.13.1/8.13.1/Submit) id k5P5LH4T002929; Sat, 24 Jun 2006 23:21:17 -0600 X-Authentication-Warning: enterprise.local.lan: torriem set sender to torriem@chem.byu.edu using -f Subject: Re: gtk file open dialog usability. From: Michael Torrie To: Gian Mario Tagliaretti In-Reply-To: <35bf41160606240652s3da0fe6brd3915cd84c601114@mail.gmail.com> References: <35bf41160606240652s3da0fe6brd3915cd84c601114@mail.gmail.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Sat, 24 Jun 2006 23:21:16 -0600 Message-Id: <1151212877.32440.24.camel@enterprise.local.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-7) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.378 tagged_above=-999 required=2 tests=[AWL=0.009, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, TW_GT=0.077] X-Spam-Score: -2.378 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jun 2006 05:21:50 -0000 On Sat, 2006-06-24 at 15:52 +0200, Gian Mario Tagliaretti wrote: > 2006/6/24, alex@halogen-dg.com : > > > > Anyone except me also disappointed by it? > > Any way how we can have old file open dialog back? > > code not complain :) BS. Before anyone can code anything, especially in the framework of GTK, the design has to be worked out. You can't just willy-nilly code up some pseudo-compatible widget. The problem is that every time this is discussed there is never any consensus on what the problems are, why they are problems, and how to fix them. And without this, we cannot convince developers to do anything about the problem. Now having said that, if someone wants to prototype a better widget (one that is API compatible with the current one), maybe that would jump- start the process. Myself, I fear that inertia guarantees we're stuck with this bad design for the duration. > > > I really find it very frustating and explained > > why, with some images here: > > http://www.halogen-dg.com/alex/file_selection_dialog/GtkFileOpenBadUsability > > are you using gtk+ 2.9.x ? > > ciao From dan@entropy.homelinux.org Mon Jun 26 21:13:46 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id D7F733B029A for ; Mon, 26 Jun 2006 21:13:46 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27746-05 for ; Mon, 26 Jun 2006 21:13:44 -0400 (EDT) Received: from screamer.nusconsulting.com.au (mail.nusconsulting.com.au [203.191.186.114]) by menubar.gnome.org (Postfix) with ESMTP id 5E0173B00FE for ; Mon, 26 Jun 2006 21:13:43 -0400 (EDT) Received: from [10.146.1.25] (dkasak.nusconsulting.com.au [10.146.1.25]) by screamer.nusconsulting.com.au (8.13.6/8.13.6) with ESMTP id k5R1FSwU022408 for ; Tue, 27 Jun 2006 11:15:28 +1000 Message-ID: <44A08654.1090208@entropy.homelinux.org> Date: Tue, 27 Jun 2006 11:13:56 +1000 From: Daniel Kasak User-Agent: Thunderbird 1.5.0.2 (X11/20060531) MIME-Version: 1.0 To: gtk-devel-list@gnome.org Subject: Custom Cell Renderers in a TreeView that requires scrolling broken in gtk+-2.8.18 and 2.8.19 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Canit-Stats-ID: 464197 - 7afdf0e072d5 X-Antispam-Training: Train as spam: http://screamer.nusconsulting.com.au/internal/canit/b.php?c=s&i=464197&m=7afdf0e072d5 X-Antispam-Training: Train as non-spam: http://screamer.nusconsulting.com.au/internal/canit/b.php?c=n&i=464197&m=7afdf0e072d5 X-Antispam-Training: Cancel training: http://screamer.nusconsulting.com.au/internal/canit/b.php?c=f&i=464197&m=7afdf0e072d5 X-Scanned-By: CanIt (www . roaringpenguin . com) on 10.146.0.254 X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.564 tagged_above=-999 required=2 tests=[AWL=0.035, BAYES_00=-2.599] X-Spam-Score: -2.564 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2006 01:13:47 -0000 Hi all. I've just noticed a very strange bug in my TreeViews since updating gtk. I have some apps that use a custom cell renderer to provide a pop-up GtkCalender. When I insert a row in the model, the custom cell renderer pops up ( begins editing ) as it's the 1st column. After I select a date and accept changes AND IF THERE ARE MORE ROWS THAN WILL FIT IN THE TREEVIEW WITHOUT SCROLLING, the new row DISAPPEARS from the TreeView. I scroll right from top to bottom - the new row certainly *looks* like it's gone. However if I insert *another* row, my previous missing row appears ( momentarily ) at the bottom again ... until I accept changes from the custom cell renderer on the newest row, and then they both ( or ALL, if I've inserted a number of rows ) disappear. For completeness ( partial anyway - it's a pretty complicated beast, but I can post an entire working example if required - please reply and request this if necessary, but note that it will be in Perl ), I'm pasting the entire CellRendererDate.pm module that provides the custom cell renderer at the bottom, however I note again that everything has worked properly for every version of gtk+ prior to 2.8.18. I initially updated from 2.8.17 to 2.8.19, and then when I found the bug, reverted to 2.8.17 ... tested some more ( no such bug here ), and then updated to 2.8.18 and did some more testing. It definitely arrived in 2.8.18. Has anyone noticed this behaviour with custom cell renderers? I have tested many other TreeViews that *don't* have a custom cell renderer, and have also tried moving the custom cell renderer to another position ( column ). I am almost positive that something is broken with displaying rows with a custom cell renderer when scrolling is required. I would greatly appreciate some help / suggests / confirmations / etc. Dan --- use strict; use Gtk2 -init; package Gtk2::Ex::Datasheet::DBI::CellRendererDate; use Glib::Object::Subclass "Gtk2::CellRenderer", signals => { edited => { flags => [qw(run-last)], param_types => [qw(Glib::String Glib::Scalar)], }, }, properties => [ Glib::ParamSpec -> boolean("editable", "Editable", "Can I change that?", 0, [qw(readable writable)]), Glib::ParamSpec -> string("date", "Date", "What's the date again?", "", [qw(readable writable)]), ] ; use constant x_padding => 2; use constant y_padding => 3; use constant arrow_width => 15; use constant arrow_height => 15; sub hide_popup { my ($cell) = @_; Gtk2 -> grab_remove($cell -> { _popup }); $cell -> { _popup } -> hide(); } sub get_today { my ($cell) = @_; my ($day, $month, $year) = (localtime())[3, 4, 5]; $year += 1900; $month += 1; return ($year, $month, $day); } sub get_date { my ($cell) = @_; my $text = $cell -> get("date"); my ($year, $month, $day) = $text ? split(/[\/-]/, $text) : $cell -> get_today(); return ($year, $month, $day); } sub add_padding { my ($cell, $year, $month, $day) = @_; return ($year, sprintf("%02d", $month), sprintf("%02d", $day)); } sub INIT_INSTANCE { my ($cell) = @_; my $popup = Gtk2::Window -> new ('popup'); my $vbox = Gtk2::VBox -> new(0, 0); my $calendar = Gtk2::Calendar -> new(); my $hbox = Gtk2::HBox -> new(0, 0); my $today = Gtk2::Button -> new('Today'); my $none = Gtk2::Button -> new('None'); $cell -> {_arrow} = Gtk2::Arrow -> new("down", "none"); # We can't just provide the callbacks now because they might need access to # cell-specific variables. And we can't just connect the signals in # START_EDITING because we'd be connecting many signal handlers to the same # widgets. $today -> signal_connect(clicked => sub { $cell -> { _today_clicked_callback } -> (@_) if (exists($cell -> { _today_clicked_callback })); }); $none -> signal_connect(clicked => sub { $cell -> { _none_clicked_callback } -> (@_) if (exists($cell -> { _none_clicked_callback })); }); $calendar -> signal_connect(day_selected_double_click => sub { $cell -> { _day_selected_double_click_callback } -> (@_) if (exists($cell -> { _day_selected_double_click_callback })); }); $calendar -> signal_connect(month_changed => sub { $cell -> { _month_changed } -> (@_) if (exists($cell -> { _month_changed })); }); $hbox -> pack_start($today, 1, 1, 0); $hbox -> pack_start($none, 1, 1, 0); $vbox -> pack_start($calendar, 1, 1, 0); $vbox -> pack_start($hbox, 0, 0, 0); # Find out if the click happended outside of our window. If so, hide it. # Largely copied from Planner (the former MrProject). # Implement via Gtk2::get_event_widget? $popup -> signal_connect(button_press_event => sub { my ($popup, $event) = @_; if ($event -> button() == 1) { my ($x, $y) = ($event -> x_root(), $event -> y_root()); my ($xoffset, $yoffset) = $popup -> window() -> get_root_origin(); my $allocation = $popup -> allocation(); my $x1 = $xoffset + 2 * $allocation -> x(); my $y1 = $yoffset + 2 * $allocation -> y(); my $x2 = $x1 + $allocation -> width(); my $y2 = $y1 + $allocation -> height(); unless ($x > $x1 && $x < $x2 && $y > $y1 && $y < $y2) { $cell -> hide_popup(); return 1; } } return 0; }); $popup -> add($vbox); $cell -> { _popup } = $popup; $cell -> { _calendar } = $calendar; } sub START_EDITING { my ($cell, $event, $view, $path, $background_area, $cell_area, $flags) = @_; my $popup = $cell -> { _popup }; my $calendar = $cell -> { _calendar }; # Specify the callbacks. Will be called by the signal handlers set up in # INIT_INSTANCE. $cell -> { _today_clicked_callback } = sub { my ($button) = @_; my ($year, $month, $day) = $cell -> get_today(); $cell -> signal_emit(edited => $path, join("-", $cell -> add_padding($year, $month, $day))); $cell -> hide_popup(); }; $cell -> { _none_clicked_callback } = sub { my ($button) = @_; $cell -> signal_emit(edited => $path, ""); $cell -> hide_popup(); }; $cell -> { _day_selected_double_click_callback } = sub { my ($calendar) = @_; my ($year, $month, $day) = $calendar -> get_date(); $cell -> signal_emit(edited => $path, join("-", $cell -> add_padding($year, ++$month, $day))); $cell -> hide_popup(); }; $cell -> { _month_changed } = sub { my ($calendar) = @_; my ($selected_year, $selected_month) = $calendar -> get_date(); my ($current_year, $current_month, $current_day) = $cell -> get_today(); if ($selected_year == $current_year && ++$selected_month == $current_month) { $calendar -> mark_day($current_day); } else { $calendar -> unmark_day($current_day); } }; my ($year, $month, $day) = $cell -> get_date(); $calendar -> select_month($month - 1, $year); $calendar -> select_day($day); # Necessary to get the correct allocation of the popup. $popup -> move(-500, -500); $popup -> show_all(); # Figure out where to put the popup - ie don't put it offscreen, # as it's not movable ( by the user ) my $screen_height = $popup->get_screen->get_height; my $requisition = $popup->size_request(); my $popup_width = $requisition->width; my $popup_height = $requisition->height; my ($x_origin, $y_origin) = $view -> get_bin_window() -> get_origin(); my ($popup_x, $popup_y); $popup_x = $x_origin + $cell_area->x() + $cell_area->width() - $popup_width; $popup_x = 0 if $popup_x < 0; $popup_y = $y_origin + $cell_area -> y() + $cell_area -> height(); if ( $popup_y + $popup_height > $screen_height ) { $popup_y = $y_origin + $cell_area -> y() - $popup_height; } $popup -> move( $popup_x, $popup_y ); # Grab the focus and the pointer. Gtk2 -> grab_add($popup); $popup -> grab_focus(); Gtk2::Gdk -> pointer_grab($popup -> window(), 1, [qw(button-press-mask button-release-mask pointer-motion-mask)], undef, undef, 0); return; } sub get_date_string { my $cell = shift; return $cell->get ('date'); } sub calc_size { my ($cell, $layout) = @_; my ($width, $height) = $layout -> get_pixel_size(); return (0, 0, $width + x_padding * 2 + arrow_width, $height + y_padding * 2); } sub GET_SIZE { my ($cell, $widget, $cell_area) = @_; my $layout = $cell -> get_layout($widget); $layout -> set_text( $cell -> get_date_string() || '' ); return $cell -> calc_size($layout); } sub get_layout { my ($cell, $widget) = @_; return $widget -> create_pango_layout(""); } sub RENDER { my ($cell, $window, $widget, $background_area, $cell_area, $expose_area, $flags) = @_; my $state; if ($flags & 'selected') { $state = $widget -> has_focus() ? 'selected' : 'active'; } else { $state = $widget -> state() eq 'insensitive' ? 'insensitive' : 'normal'; } my $layout = $cell -> get_layout($widget); $layout -> set_text( $cell -> get_date_string() || '' ); my ($x_offset, $y_offset, $width, $height) = $cell -> calc_size($layout); $widget -> get_style -> paint_layout($window, $state, 1, $cell_area, $widget, "cellrenderertext", $cell_area -> x() + $x_offset + x_padding, $cell_area -> y() + $y_offset + y_padding, $layout); $widget -> get_style -> paint_arrow ($window, $widget->state, 'none', $cell_area, $cell -> { _arrow }, "", "down", 1, $cell_area -> x + $cell_area -> width - arrow_width, $cell_area -> y + $cell_area -> height - arrow_height - 2, arrow_width - 3, arrow_height); } 1; From mail2karuna@hotmail.com Tue Jun 27 05:53:25 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 0ECA43B00E4 for ; Tue, 27 Jun 2006 05:53:25 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21270-07 for ; Tue, 27 Jun 2006 05:53:11 -0400 (EDT) Received: from hotmail.com (bay123-f24.bay123.hotmail.com [207.46.11.104]) by menubar.gnome.org (Postfix) with ESMTP id 2C7C03B0104 for ; Tue, 27 Jun 2006 05:53:11 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 27 Jun 2006 02:53:10 -0700 Message-ID: Received: from 207.46.11.123 by by123fd.bay123.hotmail.msn.com with HTTP; Tue, 27 Jun 2006 09:53:09 GMT X-Originating-IP: [62.193.236.100] X-Originating-Email: [mail2karuna@hotmail.com] X-Sender: mail2karuna@hotmail.com From: "karuna karan" To: gtk-devel-list@gnome.org Subject: Re: Failed building GTK with the DFB backend Date: Tue, 27 Jun 2006 09:53:09 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 27 Jun 2006 09:53:10.0427 (UTC) FILETIME=[7F932EB0:01C699CF] X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-0.958 tagged_above=-999 required=2 tests=[BAYES_05=-1.11, MSGID_FROM_MTA_HEADER=0, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, TW_BG=0.077, TW_GT=0.077] X-Spam-Score: -0.958 X-Spam-Level: Cc: skar@tataelxsi.co.in X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2006 09:53:25 -0000 Hi all, I tried to build gtk 2.9.1 with directFB backend with following dependencies, glib 2.11.1 atk 1.10.1 cairo 1.1.6 pango 1.13.1 directfb 0.9.25.1 while building gtk with, 1 ./configure --prefix=/opt/gtkdfb/ --without-x --with-gdktarget=directfb --enable-debug=no 2 make the buld fails and throws the error as, queryimmodules.c: In function `query_module': queryimmodules.c:116: warning: dereferencing type-punned pointer will break strict-aliasing rules queryimmodules.c:117: warning: dereferencing type-punned pointer will break strict-aliasing rules queryimmodules.c:118: warning: dereferencing type-punned pointer will break strict-aliasing rules queryimmodules.c:119: warning: dereferencing type-punned pointer will break strict-aliasing rules /bin/sh ../libtool --mode=link gcc -g -O2 -Wall -o gtk-query-immodules-2.0 queryimmodules.o libgtk-directfb-2.0.la .../gdk-pixbuf/libgdk_pixbuf-2.0.la ../gdk/libgdk-directfb-2.0.la gcc -g -O2 -Wall -o .libs/gtk-query-immodules-2.0 queryimmodules.o ../.libs/libgtk-directfb-2.0.so -L/opt/gtkdfb/lib /root/gtk+-2.9.1/gdk/.libs/libgdk-directfb-2.0.so /opt/gtkdfb/lib/libatk-1.0.so ../gdk-pixbuf/.libs/libgdk_pixbuf-2.0.so .../gdk/.libs/libgdk-directfb-2.0.so /opt/gtkdfb/lib/libpangocairo-1.0.so /opt/gtkdfb/lib/libpangoft2-1.0.so /opt/gtkdfb/lib/libpango-1.0.so /opt/gtkdfb/lib/libcairo.so -lpng12 /opt/gtkdfb/lib/libdirectfb.so /opt/gtkdfb/lib/libfusion.so /opt/gtkdfb/lib/libdirect.so -lfontconfig /usr/lib/libfreetype.so /usr/lib/libxml2.so -lpthread -lz /root/gtk+-2.9.1/gdk-pixbuf/.libs/libgdk_pixbuf-2.0.so /opt/gtkdfb/lib/libgmodule-2.0.so -ldl /opt/gtkdfb/lib/libgobject-2.0.so /opt/gtkdfb/lib/libglib-2.0.so -lm -Wl,--rpath -Wl,/opt/gtkdfb/lib ../.libs/libgtk-directfb-2.0.so: undefined reference to `gdk_screen_is_composited' /root/gtk+-2.9.1/gdk/.libs/libgdk-directfb-2.0.so: undefined reference to `IA__gdk_screen_is_composited' collect2: ld returned 1 exit status make[4]: *** [gtk-query-immodules-2.0] Error 1 make[4]: Leaving directory `/root/gtk+-2.9.1/gtk' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/root/gtk+-2.9.1/gtk' make[2]: *** [all] Error 2 make[2]: Leaving directory `/root/gtk+-2.9.1/gtk' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/root/gtk+-2.9.1' make: *** [all] Error 2 help me out in this.. Thanks, Karunakaran A. _________________________________________________________________ Dont just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/ From fiandro@tiscali.it Tue Jun 27 06:05:04 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C52653B0010 for ; Tue, 27 Jun 2006 06:05:04 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22230-02 for ; Tue, 27 Jun 2006 06:05:02 -0400 (EDT) Received: from polito.it (anacreon.polito.it [130.192.3.82]) by menubar.gnome.org (Postfix) with ESMTP id 1B1113B0088 for ; Tue, 27 Jun 2006 06:05:00 -0400 (EDT) X-ExtScanner: Niversoft's FindAttachments (free) Received: from [130.192.31.127] (HELO [130.192.31.127]) by anacreon.polito.it (CommuniGate Pro SMTP 5.0.9) with ESMTP id 39350329; Tue, 27 Jun 2006 12:04:58 +0200 Message-ID: <44A103E0.8000000@tiscali.it> Date: Tue, 27 Jun 2006 12:09:36 +0200 From: Attilio Fiandrotti User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.13) Gecko/20060620 Debian/1.7.13-0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: karuna karan Subject: Re: Failed building GTK with the DFB backend References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.224 tagged_above=-999 required=2 tests=[AWL=-0.337, BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2, FORGED_RCVD_HELO=0.135, SPF_NEUTRAL=1.069, TW_DF=0.077, TW_GT=0.077, TW_KD=0.077, TW_TK=0.077] X-Spam-Score: -1.224 X-Spam-Level: Cc: gtk-devel-list@gnome.org, skar@tataelxsi.co.in X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2006 10:05:05 -0000 karuna karan wrote: > Hi all, > > I tried to build gtk 2.9.1 with directFB backend with following > dependencies, DFB support in was broken: you should try 2.9.4 or follow instructions in the wiki page to build from sratch. If you're a debian user, you can also use precompiled i386 official packages that were built this week http://download.dajobe.org/debian/experimental/ <-cairodfb http://people.debian.org/~joss/packages/ <-gtkdfb Attilio From kris@babi-pangang.org Tue Jun 27 08:43:52 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 623A53B00AE for ; Tue, 27 Jun 2006 08:43:52 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29028-04 for ; Tue, 27 Jun 2006 08:43:48 -0400 (EDT) Received: from nasi-goreng.babi-pangang.org (nasi-goreng.babi-pangang.org [83.166.137.20]) by menubar.gnome.org (Postfix) with ESMTP id 5BA363B008D for ; Tue, 27 Jun 2006 08:43:48 -0400 (EDT) Received: by nasi-goreng.babi-pangang.org (Postfix, from userid 1000) id C52593DCA0; Tue, 27 Jun 2006 14:42:09 +0200 (CEST) Date: Tue, 27 Jun 2006 14:42:09 +0200 From: Kristian Rietveld To: gtk-devel-list@gnome.org Subject: Minutes of the GTK+ meeting at GUADEC Message-ID: <20060627124209.GA23474@babi-pangang.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.564 tagged_above=-999 required=2 tests=[AWL=0.035, BAYES_00=-2.599] X-Spam-Score: -2.564 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2006 12:43:52 -0000 Hey, We had a GTK+ meeting in person at GUADEC last Sunday. Below are the minutes (or really just the notes I took). -kris. ---- GTK+ Meeting, 25 June 2006, GUADEC7 ----------------------------------- * 2.10 is basically done, we are aiming for a release next week. * Tommi asks whether the GTK+ development/maintainer team is big enough. Matthias and Tim both answer that the team has been too small for the last few years, everybody else seems to agree. * Planning 2.12, possible new features: - Canvas, and we need off-screen rendering for that. # At least 3 different candidate canvases around. # Some ideas from Soeren; immediate mode, callbacks. He will write up his ideas and send it to the list for discussion. # Defining the feature set for a canvas is really difficult, though most people agreed that GnomeCanvas does cover most of the features needed by general applications. # Might want to look at the new canvas in Qt 4.1. - Introspection - GtkBuilder, the libglade integration into GTK+. - The new tooltips API. - Maemo.org patches # Menu patches, # Input method, # Tap and hold. - International calendar support # GLib patch is about ready, # After that the GTK+ widget (GtkCalendar) needs some fixing up. - Support for editable multi-line labels, probably by extending GtkEntry. - libsexy cherrypicking # Support having an icon in the entry. # Input masks. - Recent file code updates # GtkRecentAction. # GtkFileChooser integration. * Matthias continues on Tommi's previous question on maintenance, mentioning the OS X backend. Micke and Richard explain that the backend is mostly working, but does need some bug fixing. It's marked as still experimental. * The file chooser API does have some issues. For example the backend API is private, and getting the model from the file chooser dialog is impossible. Also the code for supporting the pluggability of the UI does not work/has not been tested at all. * We decided to target the GTK+ 2.12 release on January '07. This should give us enough time to put all new features in. If we decide to include a canvas with GTK+ 2.12, we might have to depend on a new release of Cairo. According to Carl Worth the next releases of Cairo are pretty much "open". They will probably focus on performance for the next release. Making a new release for supporting some special canvas features should be feasible. * We get interrupted by some guys of the board. Jeff speaks about having the GTK+ project join the GNOME foundation. The foundation can provide help to the GTK+ project with financial and administrative tasks. It has been doing this for the GIMP project already, which has been working fine so far. The foundation does not get any influence on the technical decisions made by the GTK+ team. Also, the plan is to get a press release out on this. * The board leaves and the core team pretty much decides that doing this is not bad at all, and the only thing that needs work is the wording in the press release. Nobody appears to be against. * The topic of GTK+ 3.0 was brought up after this. 3.0 would be an API and ABI breaking release. The team decided that we would like to avoid breaking API since a lot of companies invested into GTK+ 2.x and expect that it'll be supported for some more years. Most of the team seems to agree that we want to get rid of the cruft in the 2.x series, some of which is still sticking around from the 1.x series. Matthias mentions that FC6 will not ship with GTK+ 1.x. (People cheered and Tim complained about he won't be able to run xmms then). The idea of introducing compiling subsets was brought up. We could set up a make system where the full library or only a subset is built, for example omitting all the old stuff and the printing support. The people using GTK+ on embedded devices would be really happy if we implemented something like this. If we want the compiling subsets to work, we need to make sure that none of the internal code is using deprecated widgets. Breaking API is not really something we really want to do soon. If we ever do it, we want to do it right so it can last for at least a couple of years. Also, we would prefer the development on 3.0 to happen in parallel with 2.x development. Alex brought up the idea of creating a bug which we can use to track all issues which require breaking the API, so we get a formalized list of stuff which needs API breakage. According to Tim breaking the ABI is not a real problem, since distributions and also for example the Maemo.org platform can just be recompiled. * Tim also mentioned that Michael Meeks has been working on optimizing shared library loading optimization in OpenOffice.org. We wondered if there's anything we can do to improve GTK+'s performance in this area. As Michael was unable to attend Tim and/or Matthias will try to have a talk with Michael about this. As there was nothing left discuss, we decided to close the meeting. From skar@tataelxsi.co.in Tue Jun 27 07:22:44 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 665AF3B0072 for ; Tue, 27 Jun 2006 07:22:44 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25789-03 for ; Tue, 27 Jun 2006 07:22:43 -0400 (EDT) Received: from mail.tataelxsi.co.in (mail.tataelxsi.co.in [203.200.1.48]) by menubar.gnome.org (Postfix) with ESMTP id 1DFEF3B0011 for ; Tue, 27 Jun 2006 07:22:41 -0400 (EDT) Received: from skar (tataelxsi.co.in [203.197.169.80] (may be forged)) by mail.tataelxsi.co.in (MOS 3.7.4b-GA) with ESMTP id BRG33699 (AUTH skar); Tue, 27 Jun 2006 16:52:16 +0530 (IST) From: Suman Kar To: "'Attilio Fiandrotti'" , "'karuna karan'" Subject: RE: Failed building GTK with the DFB backend Date: Tue, 27 Jun 2006 16:51:13 +0530 Message-ID: <002301c699db$cd352ea0$381b320a@telxsi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal In-Reply-To: <44A103E0.8000000@tiscali.it> X-Junkmail: Blacklisted X-Mirapoint-Sig: mail.tataelxsi.co.in X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=0.386 tagged_above=-999 required=2 tests=[BAYES_50=0.001, TW_DF=0.077, TW_GD=0.077, TW_GT=0.077, TW_KD=0.077, TW_TK=0.077] X-Spam-Score: 0.386 X-Spam-Level: X-Mailman-Approved-At: Tue, 27 Jun 2006 10:07:05 -0400 Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: Suman Kar List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2006 11:22:44 -0000 Hello Attilio, Thanks for the quick update. However, the problem goes away when we added the following: gboolean gdk_screen_is_composited (GdkScreen *screen) { g_return_val_if_fail (GDK_IS_SCREEN (screen), NULL); return FALSE; } is added to gdkscreen-directfb.c (from http://mail.gnome.org/archives/gtk-devel-list/2006-May/msg00210.html ). We will definitely try building gtk+2.9.4 and will get back in case there are any issues. One more thing: we would be really interested in gtk+-2.10. Any idea when this will be out? Regards, Suman. -----Original Message----- From: Attilio Fiandrotti [mailto:fiandro@tiscali.it] Sent: Tuesday, June 27, 2006 3:40 PM To: karuna karan Cc: gtk-devel-list@gnome.org; skar@tataelxsi.co.in Subject: Re: Failed building GTK with the DFB backend karuna karan wrote: > Hi all, > > I tried to build gtk 2.9.1 with directFB backend with following > dependencies, DFB support in was broken: you should try 2.9.4 or follow instructions in the wiki page to build from sratch. If you're a debian user, you can also use precompiled i386 official packages that were built this week http://download.dajobe.org/debian/experimental/ <-cairodfb http://people.debian.org/~joss/packages/ <-gtkdfb Attilio The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s)and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender or administrator@tataelxsi.co.in From mail2karuna@hotmail.com Wed Jun 28 01:21:49 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 761EF3B002A for ; Wed, 28 Jun 2006 01:21:49 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27811-08 for ; Wed, 28 Jun 2006 01:21:48 -0400 (EDT) Received: from hotmail.com (bay123-f28.bay123.hotmail.com [207.46.11.108]) by menubar.gnome.org (Postfix) with ESMTP id 40EF13B000F for ; Wed, 28 Jun 2006 01:21:48 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 27 Jun 2006 22:19:26 -0700 Message-ID: Received: from 207.46.11.123 by by123fd.bay123.hotmail.msn.com with HTTP; Wed, 28 Jun 2006 05:19:23 GMT X-Originating-IP: [62.193.236.96] X-Originating-Email: [mail2karuna@hotmail.com] X-Sender: mail2karuna@hotmail.com In-Reply-To: <002301c699db$cd352ea0$381b320a@telxsi.com> From: "karuna karan" To: fiandro@tiscali.it, skar@tataelxsi.co.in, amirthakaruna@tataelxsi.co.in Subject: RE: Failed building GTK with the DFB backend Date: Wed, 28 Jun 2006 05:19:23 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 28 Jun 2006 05:19:26.0977 (UTC) FILETIME=[6CD95710:01C69A72] X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-0.502 tagged_above=-999 required=2 tests=[AWL=-1.829, BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2, DNS_FROM_RFC_POST=1.708, MSGID_FROM_MTA_HEADER=0, RCVD_IN_BL_SPAMCOP_NET=1.558, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, TW_DF=0.077, TW_DK=0.077, TW_GD=0.077, TW_GT=0.077, TW_KD=0.077, TW_TK=0.077] X-Spam-Score: -0.502 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2006 05:21:49 -0000 Hi, we have tried to build gtk+ 2.9.4 with backend dfb. we got the follwing error while building, gdkwindow-directfb.c: In function `gdk_directfb_create_child_window': gdkwindow-directfb.c:2508: error: structure has no member named `GetPosition' make[4]: *** [gdkwindow-directfb.lo] Error 1 make[4]: Leaving directory `/root/new/gtk+-2.9.4/gdk/directfb' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/root/new/gtk+-2.9.4/gdk' make[2]: *** [all] Error 2 make[2]: Leaving directory `/root/new/gtk+-2.9.4/gdk' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/root/new/gtk+-2.9.4' make: *** [all] Error 2 so kindly give feedback on this issue.. Thanks, Karunakaran A. >From: Suman Kar >Reply-To: Suman Kar >To: "'Attilio Fiandrotti'" , "'karuna karan'" > >CC: >Subject: RE: Failed building GTK with the DFB backend >Date: Tue, 27 Jun 2006 16:51:13 +0530 > >Hello Attilio, > >Thanks for the quick update. However, the problem goes away when we added >the following: > >gboolean >gdk_screen_is_composited (GdkScreen *screen) >{ > g_return_val_if_fail (GDK_IS_SCREEN (screen), NULL); > return FALSE; >} > > >is added to gdkscreen-directfb.c (from >http://mail.gnome.org/archives/gtk-devel-list/2006-May/msg00210.html ). > >We will definitely try building gtk+2.9.4 and will get back in case there >are any issues. > >One more thing: we would be really interested in gtk+-2.10. Any idea when >this will be out? > >Regards, >Suman. > >-----Original Message----- >From: Attilio Fiandrotti [mailto:fiandro@tiscali.it] >Sent: Tuesday, June 27, 2006 3:40 PM >To: karuna karan >Cc: gtk-devel-list@gnome.org; skar@tataelxsi.co.in >Subject: Re: Failed building GTK with the DFB backend > > >karuna karan wrote: > > Hi all, > > > > I tried to build gtk 2.9.1 with directFB backend with following > > dependencies, > >DFB support in was broken: you should try 2.9.4 or follow instructions >in the wiki page to build from sratch. >If you're a debian user, you can also use precompiled i386 official >packages that were built this week > >http://download.dajobe.org/debian/experimental/ <-cairodfb >http://people.debian.org/~joss/packages/ <-gtkdfb > >Attilio > >The information contained in this electronic message and any attachments to >this message are intended for the exclusive use of the addressee(s)and may >contain confidential or privileged information. If you are not the intended >recipient, please notify the sender or administrator@tataelxsi.co.in _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today - it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ From matthias.clasen@gmail.com Wed Jun 28 03:10:14 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 5BEF93B002C for ; Wed, 28 Jun 2006 03:10:14 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30060-02 for ; Wed, 28 Jun 2006 03:10:12 -0400 (EDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.183]) by menubar.gnome.org (Postfix) with ESMTP id 603903B009C for ; Wed, 28 Jun 2006 03:10:12 -0400 (EDT) Received: by py-out-1112.google.com with SMTP id c30so2171621pyc for ; Wed, 28 Jun 2006 00:09:17 -0700 (PDT) Received: by 10.35.83.6 with SMTP id k6mr338054pyl; Wed, 28 Jun 2006 00:09:17 -0700 (PDT) Received: by 10.35.39.16 with HTTP; Wed, 28 Jun 2006 00:09:17 -0700 (PDT) Message-ID: Date: Wed, 28 Jun 2006 03:09:17 -0400 From: "Matthias Clasen" To: "Suman Kar" Subject: Re: Failed building GTK with the DFB backend In-Reply-To: <002301c699db$cd352ea0$381b320a@telxsi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <44A103E0.8000000@tiscali.it> <002301c699db$cd352ea0$381b320a@telxsi.com> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.41 tagged_above=-999 required=2 tests=[AWL=-0.010, BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2, SPF_PASS=-0.001] X-Spam-Score: -2.41 X-Spam-Level: Cc: gtk-devel-list@gnome.org, karuna karan X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2006 07:10:14 -0000 On 6/27/06, Suman Kar wrote: > One more thing: we would be really interested in gtk+-2.10. Any idea when > this will be out? > I'll start working on the release when I'm back from Guadec next week. From fiandro@tiscali.it Wed Jun 28 03:57:13 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 3E6E73B0002 for ; Wed, 28 Jun 2006 03:57:13 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31177-01 for ; Wed, 28 Jun 2006 03:57:10 -0400 (EDT) Received: from aa003msr.fastwebnet.it (aa003msr.fastwebnet.it [85.18.95.66]) by menubar.gnome.org (Postfix) with ESMTP id 4417B3B0005 for ; Wed, 28 Jun 2006 03:57:10 -0400 (EDT) Received: from [192.168.2.2] (41.255.136.50) by aa003msr.fastwebnet.it (7.2.070.1) id 44965DC20058C56D; Wed, 28 Jun 2006 09:55:45 +0200 Message-ID: <44A23718.3020008@tiscali.it> Date: Wed, 28 Jun 2006 10:00:24 +0200 From: Attilio Fiandrotti User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.13) Gecko/20060620 Debian/1.7.13-0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: karuna karan Subject: Re: Failed building GTK with the DFB backend References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=1.347 tagged_above=-999 required=2 tests=[AWL=-0.215, BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2, RCVD_IN_WHOIS_BOGONS=2.43, SPF_NEUTRAL=1.069, TW_DF=0.077, TW_DK=0.077, TW_GD=0.077, TW_GT=0.077, TW_KD=0.077, TW_TK=0.077] X-Spam-Score: 1.347 X-Spam-Level: * Cc: gtk-devel-list@gnome.org, skar@tataelxsi.co.in, amirthakaruna@tataelxsi.co.in X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2006 07:57:13 -0000 A couple of days ago mike checked in the patch that excludes from compilation some extra code that requires DFB 0.9.25 in the case DFN 0.9.24 is used. Use CVS sources or apply to GTK 2.9.4 gdkdirectfb.h and gdkwindow-directfb.c from current SVN. If you're a Debian user and run on i386, simply install cairodfb and gtkdfb packages [1] which were made recently available (other archs will follow soon). Attilio [1] http://mail.directfb.org/pipermail/directfb-dev/2006-June/001973.html karuna karan wrote: > Hi, > > we have tried to build gtk+ 2.9.4 with backend dfb. > we got the follwing error while building, > > gdkwindow-directfb.c: In function `gdk_directfb_create_child_window': > gdkwindow-directfb.c:2508: error: structure has no member named > `GetPosition' > make[4]: *** [gdkwindow-directfb.lo] Error 1 > make[4]: Leaving directory `/root/new/gtk+-2.9.4/gdk/directfb' > make[3]: *** [all-recursive] Error 1 > make[3]: Leaving directory `/root/new/gtk+-2.9.4/gdk' > make[2]: *** [all] Error 2 > make[2]: Leaving directory `/root/new/gtk+-2.9.4/gdk' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/root/new/gtk+-2.9.4' > make: *** [all] Error 2 > > so kindly give feedback on this issue.. > > Thanks, > Karunakaran A. > > > > >> From: Suman Kar >> Reply-To: Suman Kar >> To: "'Attilio Fiandrotti'" , "'karuna >> karan'" >> CC: >> Subject: RE: Failed building GTK with the DFB backend >> Date: Tue, 27 Jun 2006 16:51:13 +0530 >> >> Hello Attilio, >> >> Thanks for the quick update. However, the problem goes away when we added >> the following: >> >> gboolean >> gdk_screen_is_composited (GdkScreen *screen) >> { >> g_return_val_if_fail (GDK_IS_SCREEN (screen), NULL); >> return FALSE; >> } >> >> >> is added to gdkscreen-directfb.c (from >> http://mail.gnome.org/archives/gtk-devel-list/2006-May/msg00210.html ). >> >> We will definitely try building gtk+2.9.4 and will get back in case there >> are any issues. >> >> One more thing: we would be really interested in gtk+-2.10. Any idea when >> this will be out? >> >> Regards, >> Suman. >> >> -----Original Message----- >> From: Attilio Fiandrotti [mailto:fiandro@tiscali.it] >> Sent: Tuesday, June 27, 2006 3:40 PM >> To: karuna karan >> Cc: gtk-devel-list@gnome.org; skar@tataelxsi.co.in >> Subject: Re: Failed building GTK with the DFB backend >> >> >> karuna karan wrote: >> > Hi all, >> > >> > I tried to build gtk 2.9.1 with directFB backend with following >> > dependencies, >> >> DFB support in was broken: you should try 2.9.4 or follow instructions >> in the wiki page to build from sratch. >> If you're a debian user, you can also use precompiled i386 official >> packages that were built this week >> >> http://download.dajobe.org/debian/experimental/ <-cairodfb >> http://people.debian.org/~joss/packages/ <-gtkdfb >> >> Attilio >> >> The information contained in this electronic message and any >> attachments to this message are intended for the exclusive use of the >> addressee(s)and may contain confidential or privileged information. If >> you are not the intended recipient, please notify the sender or >> administrator@tataelxsi.co.in > > > _________________________________________________________________ > Express yourself instantly with MSN Messenger! Download today - it's > FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ > > From mail2karuna@hotmail.com Wed Jun 28 04:51:51 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 8EFB63B0079 for ; Wed, 28 Jun 2006 04:51:51 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00776-08 for ; Wed, 28 Jun 2006 04:51:50 -0400 (EDT) Received: from hotmail.com (bay123-f31.bay123.hotmail.com [207.46.11.111]) by menubar.gnome.org (Postfix) with ESMTP id 2CB433B0005 for ; Wed, 28 Jun 2006 04:51:50 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 28 Jun 2006 01:50:10 -0700 Message-ID: Received: from 207.46.11.123 by by123fd.bay123.hotmail.msn.com with HTTP; Wed, 28 Jun 2006 08:50:07 GMT X-Originating-IP: [62.193.226.74] X-Originating-Email: [mail2karuna@hotmail.com] X-Sender: mail2karuna@hotmail.com In-Reply-To: <44A23718.3020008@tiscali.it> From: "karuna karan" To: fiandro@tiscali.it Subject: Re: Failed building GTK with the DFB backend Date: Wed, 28 Jun 2006 08:50:07 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 28 Jun 2006 08:50:10.0376 (UTC) FILETIME=[DCE6EC80:01C69A8F] X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=1.17 tagged_above=-999 required=2 tests=[AWL=-3.240, BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2, DNS_FROM_RFC_POST=1.708, MSGID_FROM_MTA_HEADER=0, RCVD_IN_BL_SPAMCOP_NET=1.558, RCVD_IN_SBL=3.16, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, TW_DF=0.077, TW_GD=0.077, TW_GT=0.077, TW_KD=0.077, TW_TK=0.077] X-Spam-Score: 1.17 X-Spam-Level: * Cc: gtk-devel-list@gnome.org, skar@tataelxsi.co.in, amirthakaruna@tataelxsi.co.in X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2006 08:51:51 -0000 hi, we are already working with DirectFB 0.9.25.1 and GTK 2.9.4(released) we will start work with GTK 2.9.4 from CVS as suggested by you. we will get back if any issue arises. Thanks, Karunakaran A. >From: Attilio Fiandrotti >A couple of days ago mike checked in the patch that excludes from >compilation some extra code that requires DFB 0.9.25 in the case DFN 0.9.24 >is used. >Use CVS sources or apply to GTK 2.9.4 gdkdirectfb.h and >gdkwindow-directfb.c from current SVN. >If you're a Debian user and run on i386, simply install cairodfb and gtkdfb >packages [1] which were made recently available (other archs will follow >soon). > >Attilio > >[1] http://mail.directfb.org/pipermail/directfb-dev/2006-June/001973.html > >karuna karan wrote: >>Hi, >> >>we have tried to build gtk+ 2.9.4 with backend dfb. >>we got the follwing error while building, >> >>gdkwindow-directfb.c: In function `gdk_directfb_create_child_window': >>gdkwindow-directfb.c:2508: error: structure has no member named >>`GetPosition' >>make[4]: *** [gdkwindow-directfb.lo] Error 1 >>make[4]: Leaving directory `/root/new/gtk+-2.9.4/gdk/directfb' >>make[3]: *** [all-recursive] Error 1 >>make[3]: Leaving directory `/root/new/gtk+-2.9.4/gdk' >>make[2]: *** [all] Error 2 >>make[2]: Leaving directory `/root/new/gtk+-2.9.4/gdk' >>make[1]: *** [all-recursive] Error 1 >>make[1]: Leaving directory `/root/new/gtk+-2.9.4' >>make: *** [all] Error 2 >> >>so kindly give feedback on this issue.. >> >>Thanks, >>Karunakaran A. >> >> >> >> >>>From: Suman Kar >>>Reply-To: Suman Kar >>>To: "'Attilio Fiandrotti'" , "'karuna karan'" >>> >>>CC: >>>Subject: RE: Failed building GTK with the DFB backend >>>Date: Tue, 27 Jun 2006 16:51:13 +0530 >>> >>>Hello Attilio, >>> >>>Thanks for the quick update. However, the problem goes away when we added >>>the following: >>> >>>gboolean >>>gdk_screen_is_composited (GdkScreen *screen) >>>{ >>> g_return_val_if_fail (GDK_IS_SCREEN (screen), NULL); >>> return FALSE; >>>} >>> >>> >>>is added to gdkscreen-directfb.c (from >>>http://mail.gnome.org/archives/gtk-devel-list/2006-May/msg00210.html ). >>> >>>We will definitely try building gtk+2.9.4 and will get back in case there >>>are any issues. >>> >>>One more thing: we would be really interested in gtk+-2.10. Any idea when >>>this will be out? >>> >>>Regards, >>>Suman. >>> >>>-----Original Message----- >>>From: Attilio Fiandrotti [mailto:fiandro@tiscali.it] >>>Sent: Tuesday, June 27, 2006 3:40 PM >>>To: karuna karan >>>Cc: gtk-devel-list@gnome.org; skar@tataelxsi.co.in >>>Subject: Re: Failed building GTK with the DFB backend >>> >>> >>>karuna karan wrote: >>> > Hi all, >>> > >>> > I tried to build gtk 2.9.1 with directFB backend with following >>> > dependencies, >>> >>>DFB support in was broken: you should try 2.9.4 or follow instructions >>>in the wiki page to build from sratch. >>>If you're a debian user, you can also use precompiled i386 official >>>packages that were built this week >>> >>>http://download.dajobe.org/debian/experimental/ <-cairodfb >>>http://people.debian.org/~joss/packages/ <-gtkdfb >>> >>>Attilio >>> >>>The information contained in this electronic message and any attachments >>>to this message are intended for the exclusive use of the addressee(s)and >>>may contain confidential or privileged information. If you are not the >>>intended recipient, please notify the sender or >>>administrator@tataelxsi.co.in >> >> >>_________________________________________________________________ >>Express yourself instantly with MSN Messenger! Download today - it's FREE! >>http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ >> >> > _________________________________________________________________ Dont just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/ From mail2karuna@hotmail.com Wed Jun 28 04:57:44 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id EB6A23B00A2 for ; Wed, 28 Jun 2006 04:57:43 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01098-06 for ; Wed, 28 Jun 2006 04:57:42 -0400 (EDT) Received: from bay0-omc3-s25.bay0.hotmail.com (bay0-omc3-s25.bay0.hotmail.com [65.54.246.225]) by menubar.gnome.org (Postfix) with ESMTP id 8E64F3B0002 for ; Wed, 28 Jun 2006 04:57:42 -0400 (EDT) Received: from hotmail.com ([207.46.11.110]) by bay0-omc3-s25.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Jun 2006 01:57:15 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 28 Jun 2006 01:57:15 -0700 Message-ID: Received: from 207.46.11.123 by by123fd.bay123.hotmail.msn.com with HTTP; Wed, 28 Jun 2006 08:57:12 GMT X-Originating-IP: [62.193.235.46] X-Originating-Email: [mail2karuna@hotmail.com] X-Sender: mail2karuna@hotmail.com In-Reply-To: <006101c69a90$871e5d00$361b320a@telxsi.com> From: "karuna karan" To: gtk-devel-list@gnome.org Subject: RE: Failed building GTK with the DFB backend Date: Wed, 28 Jun 2006 08:57:12 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 28 Jun 2006 08:57:15.0331 (UTC) FILETIME=[DA31E930:01C69A90] X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-0.194 tagged_above=-999 required=2 tests=[AWL=-1.445, BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2, DNS_FROM_RFC_POST=1.708, MSGID_FROM_MTA_HEADER=0, RCVD_IN_BL_SPAMCOP_NET=1.558, SPF_PASS=-0.001, TW_DF=0.077, TW_GD=0.077, TW_GT=0.077, TW_KD=0.077, TW_TK=0.077] X-Spam-Score: -0.194 X-Spam-Level: Cc: amirthakaruna@tataelxsi.co.in, skar@tataelxsi.co.in X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2006 08:57:44 -0000 hi, we are already working with DirectFB 0.9.25.1 and GTK 2.9.4(released) we will start work with GTK 2.9.4 from CVS as suggested by you. we will get back if any issue arises. Thanks, Karunakaran A. >From: Attilio Fiandrotti >A couple of days ago mike checked in the patch that excludes from >compilation some extra code that requires DFB 0.9.25 in the case DFN 0.9.24 >is used. >Use CVS sources or apply to GTK 2.9.4 gdkdirectfb.h and >gdkwindow-directfb.c from current SVN. >If you're a Debian user and run on i386, simply install cairodfb and gtkdfb >packages [1] which were made recently available (other archs will follow >soon). > >Attilio > >[1] http://mail.directfb.org/pipermail/directfb-dev/2006-June/001973.html > >karuna karan wrote: >>Hi, >> >>we have tried to build gtk+ 2.9.4 with backend dfb. >>we got the follwing error while building, >> >>gdkwindow-directfb.c: In function `gdk_directfb_create_child_window': >>gdkwindow-directfb.c:2508: error: structure has no member named >>`GetPosition' >>make[4]: *** [gdkwindow-directfb.lo] Error 1 >>make[4]: Leaving directory `/root/new/gtk+-2.9.4/gdk/directfb' >>make[3]: *** [all-recursive] Error 1 >>make[3]: Leaving directory `/root/new/gtk+-2.9.4/gdk' >>make[2]: *** [all] Error 2 >>make[2]: Leaving directory `/root/new/gtk+-2.9.4/gdk' >>make[1]: *** [all-recursive] Error 1 >>make[1]: Leaving directory `/root/new/gtk+-2.9.4' >>make: *** [all] Error 2 >> >>so kindly give feedback on this issue.. >> >>Thanks, >>Karunakaran A. >> >> >> >> >>>From: Suman Kar >>>Reply-To: Suman Kar >>>To: "'Attilio Fiandrotti'" , "'karuna karan'" >>> >>>CC: >>>Subject: RE: Failed building GTK with the DFB backend >>>Date: Tue, 27 Jun 2006 16:51:13 +0530 >>> >>>Hello Attilio, >>> >>>Thanks for the quick update. However, the problem goes away when we added >>>the following: >>> >>>gboolean >>>gdk_screen_is_composited (GdkScreen *screen) >>>{ >>> g_return_val_if_fail (GDK_IS_SCREEN (screen), NULL); >>> return FALSE; >>>} >>> >>> >>>is added to gdkscreen-directfb.c (from >>>http://mail.gnome.org/archives/gtk-devel-list/2006-May/msg00210.html ). >>> >>>We will definitely try building gtk+2.9.4 and will get back in case there > >>>are any issues. > >>> > >>>One more thing: we would be really interested in gtk+-2.10. Any idea >when > >>>this will be out? > >>> > >>>Regards, > >>>Suman. > >>> > >>>-----Original Message----- > >>>From: Attilio Fiandrotti [mailto:fiandro@tiscali.it] > >>>Sent: Tuesday, June 27, 2006 3:40 PM > >>>To: karuna karan > >>>Cc: gtk-devel-list@gnome.org; skar@tataelxsi.co.in > >>>Subject: Re: Failed building GTK with the DFB backend > >>> > >>> > >>>karuna karan wrote: > >>> > Hi all, > >>> > > >>> > I tried to build gtk 2.9.1 with directFB backend with following > >>> > dependencies, > >>> > >>>DFB support in was broken: you should try 2.9.4 or follow instructions > >>>in the wiki page to build from sratch. > >>>If you're a debian user, you can also use precompiled i386 official > >>>packages that were built this week > >>> > >>>http://download.dajobe.org/debian/experimental/ <-cairodfb > >>>http://people.debian.org/~joss/packages/ <-gtkdfb > >>> > >>>Attilio > >>> > >>>The information contained in this electronic message and any >attachments > >>>to this message are intended for the exclusive use of the >addressee(s)and > >>>may contain confidential or privileged information. If you are not the > >>>intended recipient, please notify the sender or > >>>administrator@tataelxsi.co.in > >> > >> > >>_________________________________________________________________ > >>Express yourself instantly with MSN Messenger! Download today - it's >FREE! > >>http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ > >> > >> > > > >_________________________________________________________________ >Dont just search. Find. Check out the new MSN Search! >http://search.msn.click-url.com/go/onm00200636ave/direct/01/ > >The information contained in this electronic message and any attachments to >this message are intended for the exclusive use of the addressee(s)and may >contain confidential or privileged information. If you are not the intended >recipient, please notify the sender or administrator@tataelxsi.co.in _________________________________________________________________ Dont just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/ From dave.foster@gmail.com Tue Jun 27 23:09:46 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id A42223B0010 for ; Tue, 27 Jun 2006 23:09:46 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25505-01 for ; Tue, 27 Jun 2006 23:09:45 -0400 (EDT) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.225]) by menubar.gnome.org (Postfix) with ESMTP id CEB183B0005 for ; Tue, 27 Jun 2006 23:09:44 -0400 (EDT) Received: by wr-out-0506.google.com with SMTP id i4so303425wra for ; Tue, 27 Jun 2006 20:08:24 -0700 (PDT) Received: by 10.54.80.7 with SMTP id d7mr394957wrb; Tue, 27 Jun 2006 20:08:24 -0700 (PDT) Received: from ?192.168.1.107? ( [68.0.246.8]) by mx.gmail.com with ESMTP id 64sm2194346wra.2006.06.27.20.08.24; Tue, 27 Jun 2006 20:08:24 -0700 (PDT) Subject: gdk_display_close segfault? From: Dave Foster To: gtk-devel-list@gnome.org Content-Type: text/plain Date: Wed, 28 Jun 2006 01:01:55 -0400 Message-Id: <1151470915.4791.3.camel@neptune.minuslab.net> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.6 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.6 X-Spam-Level: X-Mailman-Approved-At: Wed, 28 Jun 2006 07:11:10 -0400 X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2006 03:09:46 -0000 Hi, I've been trying to write a small section of code in my program which makes a second connection to the X display, using gtkmm.. I kept having problems, after rewriting it about 5 or 6 times, I tried writing it in straight gdk, and STILL got the problems. I seem to get a segfault whenever I call gdk_display_close(). Here is a rediculously simple example that gives the problem: Glib::ustring disp = ":0.0"; GdkDisplay* gdisp = gdk_display_open(disp.c_str()); if (!gdisp) ... gdk_display_close(gdisp); /* Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1224202560 (LWP 5689)] 0xb7b413d0 in gdk_display_x11_dispose () from /usr/lib/libgdk-x11-2.0.so.0 (gdb) bt #0 0xb7b413d0 in gdk_display_x11_dispose () from /usr/lib/libgdk-x11-2.0.so.0 #1 0xb7a11f2b in g_object_unref () from /usr/lib/libgobject-2.0.so.0 #2 0xb7b20c04 in gdk_display_close () from /usr/lib/libgdk-x11-2.0.so.0 #3 0x080571d5 in SetBG::set_bg (disp=@0xbfe1b2b0, file=@0xbfe1b2ac, mode=SetBG::SET_SCALE, bgcolor=@0xbfe1b2a8) at SetBG.cc:67 ... */ The display is opening fine. I'm running: gtk: 2.8.17-1 glib: 2.10.2-1 (hmm, didn't notice that before,t he 2.8 vs 2.10 thing, could that be it?) Anyway, I've spent all night trying to debug this and weeks trying to sort this problem out in my program. What is up with this, what can I do? thanks all. dave From fiandro@tiscali.it Wed Jun 28 07:47:12 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id EF7893B0087 for ; Wed, 28 Jun 2006 07:47:11 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08611-03 for ; Wed, 28 Jun 2006 07:47:10 -0400 (EDT) Received: from polito.it (anacreon.polito.it [130.192.3.82]) by menubar.gnome.org (Postfix) with ESMTP id AEB163B00A0 for ; Wed, 28 Jun 2006 07:47:09 -0400 (EDT) X-ExtScanner: Niversoft's FindAttachments (free) Received: from [130.192.31.127] (HELO [130.192.31.127]) by anacreon.polito.it (CommuniGate Pro SMTP 5.0.9) with ESMTP id 39386694; Wed, 28 Jun 2006 13:46:14 +0200 Message-ID: <44A26D1D.9090905@tiscali.it> Date: Wed, 28 Jun 2006 13:50:53 +0200 From: Attilio Fiandrotti User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.13) Gecko/20060620 Debian/1.7.13-0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Suman Kar Subject: Re: Failed building GTK with the DFB backend References: <000101c69aa6$6547c9d0$381b320a@telxsi.com> In-Reply-To: <000101c69aa6$6547c9d0$381b320a@telxsi.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.35 tagged_above=-999 required=2 tests=[AWL=-0.540, BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2, FORGED_RCVD_HELO=0.135, SPF_NEUTRAL=1.069, TW_DF=0.077, TW_GD=0.077, TW_GT=0.077, TW_KD=0.077, TW_TK=0.077] X-Spam-Score: -1.35 X-Spam-Level: Cc: gtk-devel-list@gnome.org, amirthakaruna@tataelxsi.co.in X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2006 11:47:12 -0000 I apologize for my mistake: only now i realize taht getposition() and getsize() were introduced *after* DFB 0.9.25 was released! Yesterday mike checked in a patch ("Added ifdef to compile with 0.9.24 removes creating a child GdkWindow since it u...") that allows GTK+ to be compiled against DFB >= 0.9.24 (so, also 0.9.25 will do) The correct recipe is: DFB >= 0.9.24 GTK+ HEAD from CVS Attilio Suman Kar wrote: > Hello Attilio, > > Let me try to explain Karuna's problem: we are using the > downloadable source tarball from > http://directfb.org/index.php?path=Main%2FDownloads: > DirectFB-0.9.25.1.tar.gz > > Also, this was released on 03-May-2006. Mike's checkin has happened > on 11-June-2006. Moreover, we could not find the GetPosition() > member in either the http://directfb.org/index.php?path=Main%2FNews > page or in the source files Mike has mentioned in the mail to > the directFB list. > > These indicates to me that this is not really an issue with some path > variable as you suggested. Your inputs are awaited. > > Regards, > Suman. > > -----Original Message----- > From: Attilio Fiandrotti [mailto:fiandro@tiscali.it] > Sent: Wednesday, June 28, 2006 3:03 PM > To: karuna karan > Cc: skar@tataelxsi.co.in; amirthakaruna@tataelxsi.co.in > Subject: Re: Failed building GTK with the DFB backend > > > the symbol GetPosition (and getsize, too) were introduced in DFB 0.9.25 > : if you're trying to compile GTKDFB against DFB 0.9.25, then you must > have provided wrong pkg_config_path or ld_library_path > > Attilio > > karuna karan wrote: > >>hi, >> >>we are already working with DirectFB 0.9.25.1 and GTK 2.9.4(released) >> >>we will start work with GTK 2.9.4 from CVS as suggested by you. >> >>we will get back if any issue arises. >> >>Thanks, >>Karunakaran A. >> >> >> >> >From: Attilio Fiandrotti >> >> >A couple of days ago mike checked in the patch that excludes from >> >compilation some extra code that requires DFB 0.9.25 in the case DFN >>0.9.24 >> >is used. >> >Use CVS sources or apply to GTK 2.9.4 gdkdirectfb.h and >> >gdkwindow-directfb.c from current SVN. >> >If you're a Debian user and run on i386, simply install cairodfb and >>gtkdfb >> >packages [1] which were made recently available (other archs will follow >> >soon). >> > >> >Attilio >> > >> >[1] > > http://mail.directfb.org/pipermail/directfb-dev/2006-June/001973.html > >> > >> >karuna karan wrote: >> >>Hi, >> >> >> >>we have tried to build gtk+ 2.9.4 with backend dfb. >> >>we got the follwing error while building, >> >> >> >>gdkwindow-directfb.c: In function `gdk_directfb_create_child_window': >> >>gdkwindow-directfb.c:2508: error: structure has no member named >> >>`GetPosition' >> >>make[4]: *** [gdkwindow-directfb.lo] Error 1 >> >>make[4]: Leaving directory `/root/new/gtk+-2.9.4/gdk/directfb' >> >>make[3]: *** [all-recursive] Error 1 >> >>make[3]: Leaving directory `/root/new/gtk+-2.9.4/gdk' >> >>make[2]: *** [all] Error 2 >> >>make[2]: Leaving directory `/root/new/gtk+-2.9.4/gdk' >> >>make[1]: *** [all-recursive] Error 1 >> >>make[1]: Leaving directory `/root/new/gtk+-2.9.4' >> >>make: *** [all] Error 2 >> >> >> >>so kindly give feedback on this issue.. >> >> >> >>Thanks, >> >>Karunakaran A. >> >> >> >> >> >> >> >> >> >>>From: Suman Kar >> >>>Reply-To: Suman Kar >> >>>To: "'Attilio Fiandrotti'" , "'karuna >>karan'" >> >>> >> >>>CC: >> >>>Subject: RE: Failed building GTK with the DFB backend >> >>>Date: Tue, 27 Jun 2006 16:51:13 +0530 >> >>> >> >>>Hello Attilio, >> >>> >> >>>Thanks for the quick update. However, the problem goes away when we >>added >> >>>the following: >> >>> >> >>>gboolean >> >>>gdk_screen_is_composited (GdkScreen *screen) >> >>>{ >> >>> g_return_val_if_fail (GDK_IS_SCREEN (screen), NULL); >> >>> return FALSE; >> >>>} >> >>> >> >>> >> >>>is added to gdkscreen-directfb.c (from >> >> >>>>>http://mail.gnome.org/archives/gtk-devel-list/2006-May/msg00210.html ). >> >> >>> >> >>>We will definitely try building gtk+2.9.4 and will get back in case >>there >> >> >>>>>>are any issues. >>>>>> >>>>>>One more thing: we would be really interested in gtk+-2.10. Any >>> >>>idea when >>> >>>>>>this will be out? >>>>>> >>>>>>Regards, >>>>>>Suman. >>>>>> >>>>>>-----Original Message----- >>>>>>From: Attilio Fiandrotti [mailto:fiandro@tiscali.it] >>>>>>Sent: Tuesday, June 27, 2006 3:40 PM >>>>>>To: karuna karan >>>>>>Cc: gtk-devel-list@gnome.org; skar@tataelxsi.co.in >>>>>>Subject: Re: Failed building GTK with the DFB backend >>>>>> >>>>>> >>>>>>karuna karan wrote: >>>>>> >>>>>>>Hi all, >>>>>>> >>>>>>>I tried to build gtk 2.9.1 with directFB backend with following >>>>>>>dependencies, >>>>>> >>>>>>DFB support in was broken: you should try 2.9.4 or follow instructions >>>>>>in the wiki page to build from sratch. >>>>>>If you're a debian user, you can also use precompiled i386 official >>>>>>packages that were built this week >>>>>> >>>>>>http://download.dajobe.org/debian/experimental/ <-cairodfb >>>>>>http://people.debian.org/~joss/packages/ <-gtkdfb >>>>>> >>>>>>Attilio >>>>>> >>>>>>The information contained in this electronic message and any >>> >>>attachments >>> >>>>>>to this message are intended for the exclusive use of the >>> >>>addressee(s)and >>> >>>>>>may contain confidential or privileged information. If you are not the >>>>>>intended recipient, please notify the sender or >>>>>>administrator@tataelxsi.co.in >>>>> >>>>> >>>>>_________________________________________________________________ >>>>>Express yourself instantly with MSN Messenger! Download today - it's >>> >>>FREE! >>> >>>>>http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ >>>>> >>>>> >>>> >>>_________________________________________________________________ >>>Dont just search. Find. Check out the new MSN Search! >>>http://search.msn.click-url.com/go/onm00200636ave/direct/01/ >>> >>>The information contained in this electronic message and any >>>attachments to this message are intended for the exclusive use of the >>>addressee(s)and may contain confidential or privileged information. If >>>you are not the intended recipient, please notify the sender or >>>administrator@tataelxsi.co.in >> >> >>_________________________________________________________________ >>Dont just search. Find. Check out the new MSN Search! >>http://search.msn.click-url.com/go/onm00200636ave/direct/01/ >> >> >> >> >>------------------------------------------------------------------------ >> >>The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s)and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender or administrator@tataelxsi.co.in From skar@tataelxsi.co.in Wed Jun 28 07:31:56 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id B3F193B006C for ; Wed, 28 Jun 2006 07:31:56 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07955-07 for ; Wed, 28 Jun 2006 07:31:55 -0400 (EDT) Received: from mail.tataelxsi.co.in (mail.tataelxsi.co.in [203.200.1.48]) by menubar.gnome.org (Postfix) with ESMTP id 0CA9D3B00F3 for ; Wed, 28 Jun 2006 07:31:53 -0400 (EDT) Received: from skar (tataelxsi.co.in [203.197.169.80] (may be forged)) by mail.tataelxsi.co.in (MOS 3.7.4b-GA) with ESMTP id BRJ72122 (AUTH skar); Wed, 28 Jun 2006 17:02:27 +0530 (IST) From: Suman Kar To: "'Attilio Fiandrotti'" , Subject: RE: Failed building GTK with the DFB backend Date: Wed, 28 Jun 2006 17:01:26 +0530 Message-ID: <000101c69aa6$6547c9d0$381b320a@telxsi.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <44A24CDC.4070707@tiscali.it> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Junkmail: Blacklisted Content-Type: multipart/mixed; boundary="MIRAPOINT_PART1_44a268cc" X-Mirapoint-Sig: mail.tataelxsi.co.in X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.291 tagged_above=-999 required=2 tests=[AWL=-0.635, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.558, TW_DF=0.077, TW_GD=0.077, TW_GT=0.077, TW_KD=0.077, TW_TK=0.077] X-Spam-Score: -1.291 X-Spam-Level: X-Mailman-Approved-At: Wed, 28 Jun 2006 08:28:51 -0400 Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: Suman Kar List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2006 11:31:56 -0000 --MIRAPOINT_PART1_44a268cc Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 8bit Hello Attilio, Let me try to explain Karuna's problem: we are using the downloadable source tarball from http://directfb.org/index.php?path=Main%2FDownloads: DirectFB-0.9.25.1.tar.gz Also, this was released on 03-May-2006. Mike's checkin has happened on 11-June-2006. Moreover, we could not find the GetPosition() member in either the http://directfb.org/index.php?path=Main%2FNews page or in the source files Mike has mentioned in the mail to the directFB list. These indicates to me that this is not really an issue with some path variable as you suggested. Your inputs are awaited. Regards, Suman. -----Original Message----- From: Attilio Fiandrotti [mailto:fiandro@tiscali.it] Sent: Wednesday, June 28, 2006 3:03 PM To: karuna karan Cc: skar@tataelxsi.co.in; amirthakaruna@tataelxsi.co.in Subject: Re: Failed building GTK with the DFB backend the symbol GetPosition (and getsize, too) were introduced in DFB 0.9.25 : if you're trying to compile GTKDFB against DFB 0.9.25, then you must have provided wrong pkg_config_path or ld_library_path Attilio karuna karan wrote: > hi, > > we are already working with DirectFB 0.9.25.1 and GTK 2.9.4(released) > > we will start work with GTK 2.9.4 from CVS as suggested by you. > > we will get back if any issue arises. > > Thanks, > Karunakaran A. > > > > >From: Attilio Fiandrotti > > >A couple of days ago mike checked in the patch that excludes from > >compilation some extra code that requires DFB 0.9.25 in the case DFN > 0.9.24 > >is used. > >Use CVS sources or apply to GTK 2.9.4 gdkdirectfb.h and > >gdkwindow-directfb.c from current SVN. > >If you're a Debian user and run on i386, simply install cairodfb and > gtkdfb > >packages [1] which were made recently available (other archs will follow > >soon). > > > >Attilio > > > >[1] http://mail.directfb.org/pipermail/directfb-dev/2006-June/001973.html > > > >karuna karan wrote: > >>Hi, > >> > >>we have tried to build gtk+ 2.9.4 with backend dfb. > >>we got the follwing error while building, > >> > >>gdkwindow-directfb.c: In function `gdk_directfb_create_child_window': > >>gdkwindow-directfb.c:2508: error: structure has no member named > >>`GetPosition' > >>make[4]: *** [gdkwindow-directfb.lo] Error 1 > >>make[4]: Leaving directory `/root/new/gtk+-2.9.4/gdk/directfb' > >>make[3]: *** [all-recursive] Error 1 > >>make[3]: Leaving directory `/root/new/gtk+-2.9.4/gdk' > >>make[2]: *** [all] Error 2 > >>make[2]: Leaving directory `/root/new/gtk+-2.9.4/gdk' > >>make[1]: *** [all-recursive] Error 1 > >>make[1]: Leaving directory `/root/new/gtk+-2.9.4' > >>make: *** [all] Error 2 > >> > >>so kindly give feedback on this issue.. > >> > >>Thanks, > >>Karunakaran A. > >> > >> > >> > >> > >>>From: Suman Kar > >>>Reply-To: Suman Kar > >>>To: "'Attilio Fiandrotti'" , "'karuna > karan'" > >>> > >>>CC: > >>>Subject: RE: Failed building GTK with the DFB backend > >>>Date: Tue, 27 Jun 2006 16:51:13 +0530 > >>> > >>>Hello Attilio, > >>> > >>>Thanks for the quick update. However, the problem goes away when we > added > >>>the following: > >>> > >>>gboolean > >>>gdk_screen_is_composited (GdkScreen *screen) > >>>{ > >>> g_return_val_if_fail (GDK_IS_SCREEN (screen), NULL); > >>> return FALSE; > >>>} > >>> > >>> > >>>is added to gdkscreen-directfb.c (from > >>>> http://mail.gnome.org/archives/gtk-devel-list/2006-May/msg00210.html ). > > >>> > >>>We will definitely try building gtk+2.9.4 and will get back in case > there > >> >>>are any issues. >> >>> >> >>>One more thing: we would be really interested in gtk+-2.10. Any >> idea when >> >>>this will be out? >> >>> >> >>>Regards, >> >>>Suman. >> >>> >> >>>-----Original Message----- >> >>>From: Attilio Fiandrotti [mailto:fiandro@tiscali.it] >> >>>Sent: Tuesday, June 27, 2006 3:40 PM >> >>>To: karuna karan >> >>>Cc: gtk-devel-list@gnome.org; skar@tataelxsi.co.in >> >>>Subject: Re: Failed building GTK with the DFB backend >> >>> >> >>> >> >>>karuna karan wrote: >> >>> > Hi all, >> >>> > >> >>> > I tried to build gtk 2.9.1 with directFB backend with following >> >>> > dependencies, >> >>> >> >>>DFB support in was broken: you should try 2.9.4 or follow instructions >> >>>in the wiki page to build from sratch. >> >>>If you're a debian user, you can also use precompiled i386 official >> >>>packages that were built this week >> >>> >> >>>http://download.dajobe.org/debian/experimental/ <-cairodfb >> >>>http://people.debian.org/~joss/packages/ <-gtkdfb >> >>> >> >>>Attilio >> >>> >> >>>The information contained in this electronic message and any >> attachments >> >>>to this message are intended for the exclusive use of the >> addressee(s)and >> >>>may contain confidential or privileged information. If you are not the >> >>>intended recipient, please notify the sender or >> >>>administrator@tataelxsi.co.in >> >> >> >> >> >>_________________________________________________________________ >> >>Express yourself instantly with MSN Messenger! Download today - it's >> FREE! >> >>http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ >> >> >> >> >> > >> >> _________________________________________________________________ >> Dont just search. Find. Check out the new MSN Search! >> http://search.msn.click-url.com/go/onm00200636ave/direct/01/ >> >> The information contained in this electronic message and any >> attachments to this message are intended for the exclusive use of the >> addressee(s)and may contain confidential or privileged information. If >> you are not the intended recipient, please notify the sender or >> administrator@tataelxsi.co.in > > > _________________________________________________________________ > Dont just search. Find. Check out the new MSN Search! > http://search.msn.click-url.com/go/onm00200636ave/direct/01/ > > --MIRAPOINT_PART1_44a268cc Content-Disposition: inline The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s)and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender or administrator@tataelxsi.co.in --MIRAPOINT_PART1_44a268cc-- From skar@tataelxsi.co.in Wed Jun 28 08:09:32 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id B55753B016E for ; Wed, 28 Jun 2006 08:09:32 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09711-02 for ; Wed, 28 Jun 2006 08:09:31 -0400 (EDT) Received: from mail.tataelxsi.co.in (mail.tataelxsi.co.in [203.200.1.48]) by menubar.gnome.org (Postfix) with ESMTP id B45AB3B01C1 for ; Wed, 28 Jun 2006 08:09:29 -0400 (EDT) Received: from skar (tataelxsi.co.in [203.197.169.80] (may be forged)) by mail.tataelxsi.co.in (MOS 3.7.4b-GA) with ESMTP id BRJ80256 (AUTH skar); Wed, 28 Jun 2006 17:40:28 +0530 (IST) From: Suman Kar To: "'Attilio Fiandrotti'" Subject: RE: Failed building GTK with the DFB backend Date: Wed, 28 Jun 2006 17:39:28 +0530 Message-ID: <000801c69aab$b5138bc0$381b320a@telxsi.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <44A26D1D.9090905@tiscali.it> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Junkmail: Blacklisted Content-Type: multipart/mixed; boundary="MIRAPOINT_PART1_44a271b6" X-Mirapoint-Sig: mail.tataelxsi.co.in X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.227 tagged_above=-999 required=2 tests=[AWL=-0.571, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.558, TW_DF=0.077, TW_GD=0.077, TW_GT=0.077, TW_KD=0.077, TW_TK=0.077] X-Spam-Score: -1.227 X-Spam-Level: X-Mailman-Approved-At: Wed, 28 Jun 2006 08:29:04 -0400 Cc: gtk-devel-list@gnome.org, amirthakaruna@tataelxsi.co.in X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: Suman Kar List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2006 12:09:32 -0000 --MIRAPOINT_PART1_44a271b6 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 8bit Can you please post a link to Mike's change? URL to the CVS will do. I am a little confused as the GNOME cvs did not show any results when searching for entries by memmel and the directFB CVS did not throw up a check-in in the last two days. Regards, Suman. -----Original Message----- From: Attilio Fiandrotti [mailto:fiandro@tiscali.it] Sent: Wednesday, June 28, 2006 5:21 PM To: Suman Kar Cc: amirthakaruna@tataelxsi.co.in; gtk-devel-list@gnome.org Subject: Re: Failed building GTK with the DFB backend I apologize for my mistake: only now i realize taht getposition() and getsize() were introduced *after* DFB 0.9.25 was released! Yesterday mike checked in a patch ("Added ifdef to compile with 0.9.24 removes creating a child GdkWindow since it u...") that allows GTK+ to be compiled against DFB >= 0.9.24 (so, also 0.9.25 will do) The correct recipe is: DFB >= 0.9.24 GTK+ HEAD from CVS Attilio Suman Kar wrote: > Hello Attilio, > > Let me try to explain Karuna's problem: we are using the > downloadable source tarball from > http://directfb.org/index.php?path=Main%2FDownloads: > DirectFB-0.9.25.1.tar.gz > > Also, this was released on 03-May-2006. Mike's checkin has happened > on 11-June-2006. Moreover, we could not find the GetPosition() > member in either the http://directfb.org/index.php?path=Main%2FNews > page or in the source files Mike has mentioned in the mail to > the directFB list. > > These indicates to me that this is not really an issue with some path > variable as you suggested. Your inputs are awaited. > > Regards, > Suman. > > -----Original Message----- > From: Attilio Fiandrotti [mailto:fiandro@tiscali.it] > Sent: Wednesday, June 28, 2006 3:03 PM > To: karuna karan > Cc: skar@tataelxsi.co.in; amirthakaruna@tataelxsi.co.in > Subject: Re: Failed building GTK with the DFB backend > > > the symbol GetPosition (and getsize, too) were introduced in DFB 0.9.25 > : if you're trying to compile GTKDFB against DFB 0.9.25, then you must > have provided wrong pkg_config_path or ld_library_path > > Attilio > > karuna karan wrote: > >>hi, >> >>we are already working with DirectFB 0.9.25.1 and GTK 2.9.4(released) >> >>we will start work with GTK 2.9.4 from CVS as suggested by you. >> >>we will get back if any issue arises. >> >>Thanks, >>Karunakaran A. >> >> >> >> >From: Attilio Fiandrotti >> >> >A couple of days ago mike checked in the patch that excludes from >> >compilation some extra code that requires DFB 0.9.25 in the case DFN >>0.9.24 >> >is used. >> >Use CVS sources or apply to GTK 2.9.4 gdkdirectfb.h and >> >gdkwindow-directfb.c from current SVN. >> >If you're a Debian user and run on i386, simply install cairodfb and >>gtkdfb >> >packages [1] which were made recently available (other archs will follow >> >soon). >> > >> >Attilio >> > >> >[1] > > http://mail.directfb.org/pipermail/directfb-dev/2006-June/001973.html > >> > >> >karuna karan wrote: >> >>Hi, >> >> >> >>we have tried to build gtk+ 2.9.4 with backend dfb. >> >>we got the follwing error while building, >> >> >> >>gdkwindow-directfb.c: In function `gdk_directfb_create_child_window': >> >>gdkwindow-directfb.c:2508: error: structure has no member named >> >>`GetPosition' >> >>make[4]: *** [gdkwindow-directfb.lo] Error 1 >> >>make[4]: Leaving directory `/root/new/gtk+-2.9.4/gdk/directfb' >> >>make[3]: *** [all-recursive] Error 1 >> >>make[3]: Leaving directory `/root/new/gtk+-2.9.4/gdk' >> >>make[2]: *** [all] Error 2 >> >>make[2]: Leaving directory `/root/new/gtk+-2.9.4/gdk' >> >>make[1]: *** [all-recursive] Error 1 >> >>make[1]: Leaving directory `/root/new/gtk+-2.9.4' >> >>make: *** [all] Error 2 >> >> >> >>so kindly give feedback on this issue.. >> >> >> >>Thanks, >> >>Karunakaran A. >> >> >> >> >> >> >> >> >> >>>From: Suman Kar >> >>>Reply-To: Suman Kar >> >>>To: "'Attilio Fiandrotti'" , "'karuna >>karan'" >> >>> >> >>>CC: >> >>>Subject: RE: Failed building GTK with the DFB backend >> >>>Date: Tue, 27 Jun 2006 16:51:13 +0530 >> >>> >> >>>Hello Attilio, >> >>> >> >>>Thanks for the quick update. However, the problem goes away when we >>added >> >>>the following: >> >>> >> >>>gboolean >> >>>gdk_screen_is_composited (GdkScreen *screen) >> >>>{ >> >>> g_return_val_if_fail (GDK_IS_SCREEN (screen), NULL); >> >>> return FALSE; >> >>>} >> >>> >> >>> >> >>>is added to gdkscreen-directfb.c (from >> >> >>>>>http://mail.gnome.org/archives/gtk-devel-list/2006-May/msg00210.html ). >> >> >>> >> >>>We will definitely try building gtk+2.9.4 and will get back in case >>there >> >> >>>>>>are any issues. >>>>>> >>>>>>One more thing: we would be really interested in gtk+-2.10. Any >>> >>>idea when >>> >>>>>>this will be out? >>>>>> >>>>>>Regards, >>>>>>Suman. >>>>>> >>>>>>-----Original Message----- >>>>>>From: Attilio Fiandrotti [mailto:fiandro@tiscali.it] >>>>>>Sent: Tuesday, June 27, 2006 3:40 PM >>>>>>To: karuna karan >>>>>>Cc: gtk-devel-list@gnome.org; skar@tataelxsi.co.in >>>>>>Subject: Re: Failed building GTK with the DFB backend >>>>>> >>>>>> >>>>>>karuna karan wrote: >>>>>> >>>>>>>Hi all, >>>>>>> >>>>>>>I tried to build gtk 2.9.1 with directFB backend with following >>>>>>>dependencies, >>>>>> >>>>>>DFB support in was broken: you should try 2.9.4 or follow instructions >>>>>>in the wiki page to build from sratch. >>>>>>If you're a debian user, you can also use precompiled i386 official >>>>>>packages that were built this week >>>>>> >>>>>>http://download.dajobe.org/debian/experimental/ <-cairodfb >>>>>>http://people.debian.org/~joss/packages/ <-gtkdfb >>>>>> >>>>>>Attilio >>>>>> >>>>>>The information contained in this electronic message and any >>> >>>attachments >>> >>>>>>to this message are intended for the exclusive use of the >>> >>>addressee(s)and >>> >>>>>>may contain confidential or privileged information. If you are not the >>>>>>intended recipient, please notify the sender or >>>>>>administrator@tataelxsi.co.in >>>>> >>>>> >>>>>_________________________________________________________________ >>>>>Express yourself instantly with MSN Messenger! Download today - it's >>> >>>FREE! >>> >>>>>http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ >>>>> >>>>> >>>> >>>_________________________________________________________________ >>>Dont just search. Find. Check out the new MSN Search! >>>http://search.msn.click-url.com/go/onm00200636ave/direct/01/ >>> >>>The information contained in this electronic message and any >>>attachments to this message are intended for the exclusive use of the >>>addressee(s)and may contain confidential or privileged information. If >>>you are not the intended recipient, please notify the sender or >>>administrator@tataelxsi.co.in >> >> >>_________________________________________________________________ >>Dont just search. Find. Check out the new MSN Search! >>http://search.msn.click-url.com/go/onm00200636ave/direct/01/ >> >> >> >> >>------------------------------------------------------------------------ >> >>The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s)and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender or administrator@tataelxsi.co.in --MIRAPOINT_PART1_44a271b6 Content-Disposition: inline The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s)and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender or administrator@tataelxsi.co.in --MIRAPOINT_PART1_44a271b6-- From skar@tataelxsi.co.in Wed Jun 28 08:23:02 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 0B3E43B00B1 for ; Wed, 28 Jun 2006 08:23:02 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10159-01 for ; Wed, 28 Jun 2006 08:23:01 -0400 (EDT) Received: from mail.tataelxsi.co.in (mail.tataelxsi.co.in [203.200.1.48]) by menubar.gnome.org (Postfix) with ESMTP id 8F3FE3B006C for ; Wed, 28 Jun 2006 08:23:00 -0400 (EDT) Received: from skar (tataelxsi.co.in [203.197.169.80] (may be forged)) by mail.tataelxsi.co.in (MOS 3.7.4b-GA) with ESMTP id BRJ83266 (AUTH skar); Wed, 28 Jun 2006 17:53:15 +0530 (IST) From: Suman Kar To: "'Matthias Clasen'" Subject: RE: Failed building GTK with the DFB backend Date: Wed, 28 Jun 2006 17:52:15 +0530 Message-ID: <000a01c69aad$7e2b6270$381b320a@telxsi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Junkmail: Blacklisted X-Mirapoint-Sig: mail.tataelxsi.co.in X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-0.029 tagged_above=-999 required=2 tests=[AWL=-1.665, BAYES_50=0.001, RCVD_IN_BL_SPAMCOP_NET=1.558, TW_GT=0.077] X-Spam-Score: -0.029 X-Spam-Level: X-Mailman-Approved-At: Wed, 28 Jun 2006 08:29:19 -0400 Cc: gtk-devel-list@gnome.org, Karunakaran A X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: Suman Kar List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2006 12:23:02 -0000 Matthias, Thanks for the update! Regards, Suman. -----Original Message----- From: Matthias Clasen [mailto:matthias.clasen@gmail.com] Sent: Wednesday, June 28, 2006 12:39 PM To: Suman Kar Cc: Attilio Fiandrotti; karuna karan; gtk-devel-list@gnome.org Subject: Re: Failed building GTK with the DFB backend On 6/27/06, Suman Kar wrote: > One more thing: we would be really interested in gtk+-2.10. Any idea when > this will be out? > I'll start working on the release when I'm back from Guadec next week. The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s)and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender or administrator@tataelxsi.co.in From matthias.clasen@gmail.com Wed Jun 28 09:56:21 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id A02133B0238 for ; Wed, 28 Jun 2006 09:56:21 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14093-02 for ; Wed, 28 Jun 2006 09:56:20 -0400 (EDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.183]) by menubar.gnome.org (Postfix) with ESMTP id 9B78C3B017A for ; Wed, 28 Jun 2006 09:56:20 -0400 (EDT) Received: by py-out-1112.google.com with SMTP id c30so2229313pyc for ; Wed, 28 Jun 2006 06:55:43 -0700 (PDT) Received: by 10.35.63.2 with SMTP id q2mr140094pyk; Wed, 28 Jun 2006 06:55:43 -0700 (PDT) Received: by 10.35.39.16 with HTTP; Wed, 28 Jun 2006 06:55:43 -0700 (PDT) Message-ID: Date: Wed, 28 Jun 2006 09:55:43 -0400 From: "Matthias Clasen" To: "Dave Foster" Subject: Re: gdk_display_close segfault? In-Reply-To: <1151470915.4791.3.camel@neptune.minuslab.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1151470915.4791.3.camel@neptune.minuslab.net> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.41 tagged_above=-999 required=2 tests=[AWL=-0.010, BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2, SPF_PASS=-0.001] X-Spam-Score: -2.41 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2006 13:56:21 -0000 On 6/28/06, Dave Foster wrote: > Hi, > > I've been trying to write a small section of code in my program which > makes a second connection to the X display, using gtkmm.. I kept having > problems, after rewriting it about 5 or 6 times, I tried writing it in > straight gdk, and STILL got the problems. > > I seem to get a segfault whenever I call gdk_display_close(). Here is a > rediculously simple example that gives the problem: > > Glib::ustring disp = ":0.0"; > GdkDisplay* gdisp = gdk_display_open(disp.c_str()); > if (!gdisp) ... > gdk_display_close(gdisp); > > /* > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread -1224202560 (LWP 5689)] > 0xb7b413d0 in gdk_display_x11_dispose () from /usr/lib/libgdk-x11-2.0.so.0 > (gdb) bt > #0 0xb7b413d0 in gdk_display_x11_dispose () from /usr/lib/libgdk-x11-2.0.so.0 > #1 0xb7a11f2b in g_object_unref () from /usr/lib/libgobject-2.0.so.0 > #2 0xb7b20c04 in gdk_display_close () from /usr/lib/libgdk-x11-2.0.so.0 > #3 0x080571d5 in SetBG::set_bg (disp=@0xbfe1b2b0, file=@0xbfe1b2ac, > mode=SetBG::SET_SCALE, bgcolor=@0xbfe1b2a8) at SetBG.cc:67 > ... > */ > > The display is opening fine. I'm running: > > gtk: 2.8.17-1 > glib: 2.10.2-1 > > (hmm, didn't notice that before,t he 2.8 vs 2.10 thing, could that be it?) > > Anyway, I've spent all night trying to debug this and weeks trying to > sort this problem out in my program. What is up with this, what can I > do? gdk_display_close has been fixed in GTK+ 2.10, which should be available soon. From dave.foster@gmail.com Wed Jun 28 10:19:15 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 006DC3B02CA for ; Wed, 28 Jun 2006 10:19:15 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15554-01 for ; Wed, 28 Jun 2006 10:19:14 -0400 (EDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.193]) by menubar.gnome.org (Postfix) with ESMTP id 907993B02D3 for ; Wed, 28 Jun 2006 10:19:13 -0400 (EDT) Received: by wx-out-0102.google.com with SMTP id s15so69257wxc for ; Wed, 28 Jun 2006 07:18:46 -0700 (PDT) Received: by 10.70.49.13 with SMTP id w13mr1383280wxw; Wed, 28 Jun 2006 07:18:46 -0700 (PDT) Received: by 10.70.6.9 with HTTP; Wed, 28 Jun 2006 07:18:46 -0700 (PDT) Message-ID: Date: Wed, 28 Jun 2006 10:18:46 -0400 From: "Dave Foster" To: "Matthias Clasen" Subject: Re: gdk_display_close segfault? In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_68848_11799959.1151504326383" References: <1151470915.4791.3.camel@neptune.minuslab.net> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.399 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2, HTML_MESSAGE=0.001, SPF_PASS=-0.001] X-Spam-Score: -2.399 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2006 14:19:15 -0000 ------=_Part_68848_11799959.1151504326383 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline ok, thank you Matthias. dave On 6/28/06, Matthias Clasen wrote: > > On 6/28/06, Dave Foster wrote: > > Hi, > > > > I've been trying to write a small section of code in my program which > > makes a second connection to the X display, using gtkmm.. I kept having > > problems, after rewriting it about 5 or 6 times, I tried writing it in > > straight gdk, and STILL got the problems. > > > > I seem to get a segfault whenever I call gdk_display_close(). Here is a > > rediculously simple example that gives the problem: > > > > Glib::ustring disp = ":0.0"; > > GdkDisplay* gdisp = gdk_display_open(disp.c_str()); > > if (!gdisp) ... > > gdk_display_close(gdisp); > > > > /* > > Program received signal SIGSEGV, Segmentation fault. > > [Switching to Thread -1224202560 (LWP 5689)] > > 0xb7b413d0 in gdk_display_x11_dispose () from /usr/lib/libgdk- > x11-2.0.so.0 > > (gdb) bt > > #0 0xb7b413d0 in gdk_display_x11_dispose () from /usr/lib/libgdk- > x11-2.0.so.0 > > #1 0xb7a11f2b in g_object_unref () from /usr/lib/libgobject-2.0.so.0 > > #2 0xb7b20c04 in gdk_display_close () from /usr/lib/libgdk-x11-2.0.so.0 > > #3 0x080571d5 in SetBG::set_bg (disp=@0xbfe1b2b0, file=@0xbfe1b2ac, > > mode=SetBG::SET_SCALE, bgcolor=@0xbfe1b2a8) at SetBG.cc:67 > > ... > > */ > > > > The display is opening fine. I'm running: > > > > gtk: 2.8.17-1 > > glib: 2.10.2-1 > > > > (hmm, didn't notice that before,t he 2.8 vs 2.10 thing, could that be > it?) > > > > Anyway, I've spent all night trying to debug this and weeks trying to > > sort this problem out in my program. What is up with this, what can I > > do? > > gdk_display_close has been fixed in GTK+ 2.10, which should be > available soon. > ------=_Part_68848_11799959.1151504326383 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline ok, thank you Matthias.

dave

On 6/28/06, Matthias Clasen <matthias.clasen@gmail.com> wrote:
On 6/28/06, Dave Foster <dave.foster@gmail.com > wrote:
> Hi,
>
> I've been trying to write a small section of code in my program which
> makes a second connection to the X display, using gtkmm.. I kept having
> problems, after rewriting it about 5 or 6 times, I tried writing it in
> straight gdk, and STILL got the problems.
>
> I seem to get a segfault whenever I call gdk_display_close().  Here is a
> rediculously simple example that gives the problem:
>
> Glib::ustring disp = ": 0.0";
> GdkDisplay* gdisp = gdk_display_open(disp.c_str());
> if (!gdisp) ...
> gdk_display_close(gdisp);
>
> /*
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread -1224202560 (LWP 5689)]
> 0xb7b413d0 in gdk_display_x11_dispose () from /usr/lib/libgdk-x11-2.0.so.0
> (gdb) bt
> #0  0xb7b413d0 in gdk_display_x11_dispose () from /usr/lib/libgdk-x11-2.0.so.0
> #1  0xb7a11f2b in g_object_unref () from /usr/lib/libgobject- 2.0.so.0
> #2  0xb7b20c04 in gdk_display_close () from /usr/lib/libgdk-x11-2.0.so.0
> #3  0x080571d5 in SetBG::set_bg (disp=@0xbfe1b2b0, file=@0xbfe1b2ac,
>     mode=SetBG::SET_SCALE, bgcolor=@0xbfe1b2a8) at SetBG.cc:67
> ...
> */
>
> The display is opening fine.  I'm running:
>
> gtk: 2.8.17-1
> glib: 2.10.2-1
>
> (hmm, didn't notice that before,t he 2.8 vs 2.10 thing, could that be it?)
>
> Anyway, I've spent all night trying to debug this and weeks trying to
> sort this problem out in my program.  What is up with this, what can I
> do?

gdk_display_close has been fixed in GTK+ 2.10, which should  be
available soon.

------=_Part_68848_11799959.1151504326383-- From amirthakaruna@tataelxsi.co.in Wed Jun 28 10:30:48 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 6BE0F3B00A7 for ; Wed, 28 Jun 2006 10:30:48 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15942-08 for ; Wed, 28 Jun 2006 10:30:47 -0400 (EDT) Received: from mail.tataelxsi.co.in (mail.tataelxsi.co.in [203.200.1.48]) by menubar.gnome.org (Postfix) with ESMTP id 2C7823B00B0 for ; Wed, 28 Jun 2006 10:30:46 -0400 (EDT) Received: from amirthakaruna (tataelxsi.co.in [203.197.169.80] (may be forged)) by mail.tataelxsi.co.in (MOS 3.7.4b-GA) with ESMTP id BRK15473 (AUTH amirthakaruna); Wed, 28 Jun 2006 20:00:59 +0530 (IST) From: Karunakaran A To: "'Attilio Fiandrotti'" , "'Suman Kar'" Subject: RE: Failed building GTK with the DFB backend Date: Wed, 28 Jun 2006 20:00:01 +0530 Message-ID: <000601c69abf$5747eb80$361b320a@telxsi.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <44A26D1D.9090905@tiscali.it> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Junkmail: Blacklisted Content-Type: multipart/mixed; boundary="MIRAPOINT_PART1_44a292a6" X-Mirapoint-Sig: mail.tataelxsi.co.in X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-0.656 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.558, TW_DF=0.077, TW_GD=0.077, TW_GT=0.077, TW_KD=0.077, TW_TK=0.077] X-Spam-Score: -0.656 X-Spam-Level: X-Mailman-Approved-At: Thu, 29 Jun 2006 03:02:46 -0400 Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2006 14:30:48 -0000 --MIRAPOINT_PART1_44a292a6 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 8bit Hi all, We also tried to build gtk 2.8.18 with patch( gtk+-directfb.patch downloaded from https://debian.polito.it/downloads/gtk+-directfb.tar.bzip ) with DFB as a backend on a different machine. In that, the patch file alters only configure.in file, not the Makefile.in. so while building,it throws error in the directory `/root/gtkdfb/gtk+-2.8.18/gdk' as, make[4]: *** No rule to make target `libgdk-directfb-2.0.la',needed by `all-am'. help me out in this. Karunakaran A. -----Original Message----- From: Attilio Fiandrotti [mailto:fiandro@tiscali.it] Sent: Wednesday, June 28, 2006 5:21 PM To: Suman Kar Cc: amirthakaruna@tataelxsi.co.in; gtk-devel-list@gnome.org Subject: Re: Failed building GTK with the DFB backend I apologize for my mistake: only now i realize taht getposition() and getsize() were introduced *after* DFB 0.9.25 was released! Yesterday mike checked in a patch ("Added ifdef to compile with 0.9.24 removes creating a child GdkWindow since it u...") that allows GTK+ to be compiled against DFB >= 0.9.24 (so, also 0.9.25 will do) The correct recipe is: DFB >= 0.9.24 GTK+ HEAD from CVS Attilio Suman Kar wrote: > Hello Attilio, > > Let me try to explain Karuna's problem: we are using the > downloadable source tarball from > http://directfb.org/index.php?path=Main%2FDownloads: > DirectFB-0.9.25.1.tar.gz > > Also, this was released on 03-May-2006. Mike's checkin has happened > on 11-June-2006. Moreover, we could not find the GetPosition() > member in either the http://directfb.org/index.php?path=Main%2FNews > page or in the source files Mike has mentioned in the mail to > the directFB list. > > These indicates to me that this is not really an issue with some path > variable as you suggested. Your inputs are awaited. > > Regards, > Suman. > > -----Original Message----- > From: Attilio Fiandrotti [mailto:fiandro@tiscali.it] > Sent: Wednesday, June 28, 2006 3:03 PM > To: karuna karan > Cc: skar@tataelxsi.co.in; amirthakaruna@tataelxsi.co.in > Subject: Re: Failed building GTK with the DFB backend > > > the symbol GetPosition (and getsize, too) were introduced in DFB 0.9.25 > : if you're trying to compile GTKDFB against DFB 0.9.25, then you must > have provided wrong pkg_config_path or ld_library_path > > Attilio > > karuna karan wrote: > >>hi, >> >>we are already working with DirectFB 0.9.25.1 and GTK 2.9.4(released) >> >>we will start work with GTK 2.9.4 from CVS as suggested by you. >> >>we will get back if any issue arises. >> >>Thanks, >>Karunakaran A. >> >> >> >> >From: Attilio Fiandrotti >> >> >A couple of days ago mike checked in the patch that excludes from >> >compilation some extra code that requires DFB 0.9.25 in the case DFN >>0.9.24 >> >is used. >> >Use CVS sources or apply to GTK 2.9.4 gdkdirectfb.h and >> >gdkwindow-directfb.c from current SVN. >> >If you're a Debian user and run on i386, simply install cairodfb and >>gtkdfb >> >packages [1] which were made recently available (other archs will follow >> >soon). >> > >> >Attilio >> > >> >[1] > > http://mail.directfb.org/pipermail/directfb-dev/2006-June/001973.html > >> > >> >karuna karan wrote: >> >>Hi, >> >> >> >>we have tried to build gtk+ 2.9.4 with backend dfb. >> >>we got the follwing error while building, >> >> >> >>gdkwindow-directfb.c: In function `gdk_directfb_create_child_window': >> >>gdkwindow-directfb.c:2508: error: structure has no member named >> >>`GetPosition' >> >>make[4]: *** [gdkwindow-directfb.lo] Error 1 >> >>make[4]: Leaving directory `/root/new/gtk+-2.9.4/gdk/directfb' >> >>make[3]: *** [all-recursive] Error 1 >> >>make[3]: Leaving directory `/root/new/gtk+-2.9.4/gdk' >> >>make[2]: *** [all] Error 2 >> >>make[2]: Leaving directory `/root/new/gtk+-2.9.4/gdk' >> >>make[1]: *** [all-recursive] Error 1 >> >>make[1]: Leaving directory `/root/new/gtk+-2.9.4' >> >>make: *** [all] Error 2 >> >> >> >>so kindly give feedback on this issue.. >> >> >> >>Thanks, >> >>Karunakaran A. >> >> >> >> >> >> >> >> >> >>>From: Suman Kar >> >>>Reply-To: Suman Kar >> >>>To: "'Attilio Fiandrotti'" , "'karuna >>karan'" >> >>> >> >>>CC: >> >>>Subject: RE: Failed building GTK with the DFB backend >> >>>Date: Tue, 27 Jun 2006 16:51:13 +0530 >> >>> >> >>>Hello Attilio, >> >>> >> >>>Thanks for the quick update. However, the problem goes away when we >>added >> >>>the following: >> >>> >> >>>gboolean >> >>>gdk_screen_is_composited (GdkScreen *screen) >> >>>{ >> >>> g_return_val_if_fail (GDK_IS_SCREEN (screen), NULL); >> >>> return FALSE; >> >>>} >> >>> >> >>> >> >>>is added to gdkscreen-directfb.c (from >> >> >>>>>http://mail.gnome.org/archives/gtk-devel-list/2006-May/msg00210.html ). >> >> >>> >> >>>We will definitely try building gtk+2.9.4 and will get back in case >>there >> >> >>>>>>are any issues. >>>>>> >>>>>>One more thing: we would be really interested in gtk+-2.10. Any >>> >>>idea when >>> >>>>>>this will be out? >>>>>> >>>>>>Regards, >>>>>>Suman. >>>>>> >>>>>>-----Original Message----- >>>>>>From: Attilio Fiandrotti [mailto:fiandro@tiscali.it] >>>>>>Sent: Tuesday, June 27, 2006 3:40 PM >>>>>>To: karuna karan >>>>>>Cc: gtk-devel-list@gnome.org; skar@tataelxsi.co.in >>>>>>Subject: Re: Failed building GTK with the DFB backend >>>>>> >>>>>> >>>>>>karuna karan wrote: >>>>>> >>>>>>>Hi all, >>>>>>> >>>>>>>I tried to build gtk 2.9.1 with directFB backend with following >>>>>>>dependencies, >>>>>> >>>>>>DFB support in was broken: you should try 2.9.4 or follow instructions >>>>>>in the wiki page to build from sratch. >>>>>>If you're a debian user, you can also use precompiled i386 official >>>>>>packages that were built this week >>>>>> >>>>>>http://download.dajobe.org/debian/experimental/ <-cairodfb >>>>>>http://people.debian.org/~joss/packages/ <-gtkdfb >>>>>> >>>>>>Attilio >>>>>> >>>>>>The information contained in this electronic message and any >>> >>>attachments >>> >>>>>>to this message are intended for the exclusive use of the >>> >>>addressee(s)and >>> >>>>>>may contain confidential or privileged information. If you are not the >>>>>>intended recipient, please notify the sender or >>>>>>administrator@tataelxsi.co.in >>>>> >>>>> >>>>>_________________________________________________________________ >>>>>Express yourself instantly with MSN Messenger! Download today - it's >>> >>>FREE! >>> >>>>>http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ >>>>> >>>>> >>>> >>>_________________________________________________________________ >>>Dont just search. Find. Check out the new MSN Search! >>>http://search.msn.click-url.com/go/onm00200636ave/direct/01/ >>> >>>The information contained in this electronic message and any >>>attachments to this message are intended for the exclusive use of the >>>addressee(s)and may contain confidential or privileged information. If >>>you are not the intended recipient, please notify the sender or >>>administrator@tataelxsi.co.in >> >> >>_________________________________________________________________ >>Dont just search. Find. Check out the new MSN Search! >>http://search.msn.click-url.com/go/onm00200636ave/direct/01/ >> >> >> >> >>------------------------------------------------------------------------ >> >>The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s)and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender or administrator@tataelxsi.co.in --MIRAPOINT_PART1_44a292a6 Content-Disposition: inline The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s)and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender or administrator@tataelxsi.co.in --MIRAPOINT_PART1_44a292a6-- From jalaganapathy@tataelxsi.co.in Thu Jun 29 03:08:28 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 62B543B03EF for ; Thu, 29 Jun 2006 03:08:28 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24602-01 for ; Thu, 29 Jun 2006 03:08:26 -0400 (EDT) Received: from mail.tataelxsi.co.in (mail.tataelxsi.co.in [203.200.1.48]) by menubar.gnome.org (Postfix) with ESMTP id 1B5DF3B03B2 for ; Thu, 29 Jun 2006 03:08:25 -0400 (EDT) Received: (from mail.tataelxsi.co.in [203.197.169.20]) by mail.tataelxsi.co.in (MOS 3.7.4b-GA) with HTTP/1.1 id BRM16267 (AUTH jalaganapathy); Thu, 29 Jun 2006 12:39:37 +0530 (IST) From: Jalagandeswari G Subject: Installing GTK+2.9.1 in Fedora core2 To: gtk-devel-list@gnome.org X-Mailer: Mirapoint Webmail Direct 3.7.4b-GA MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20060629123937.BRM16267@mail.tataelxsi.co.in> Date: Thu, 29 Jun 2006 12:39:37 +0530 (IST) X-Junkmail: Blacklisted X-Mirapoint-Sig: mail.tataelxsi.co.in X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.599 tagged_above=-999 required=2 tests=[BAYES_00=-2.599] X-Spam-Score: -2.599 X-Spam-Level: X-Mailman-Approved-At: Thu, 29 Jun 2006 07:31:44 -0400 X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2006 07:08:28 -0000 Hello All, Iam trying to install gtk+2.9.1 in fedora core2. i am using glib-1.10.1, cairo-1.1.6,atk-1.0.1 and pango-1.13.1 my configure options are ./configure --prefix=/exp/ffox Confugure works fine. While running make i am getting the following errors. gcc -DHAVE_CONFIG_H -I. -I. -I.. -DG_LOG_DOMAIN=\"Gtk\" -DGTK_LIBDIR=\"/exp/ffox/lib\" -DGTK_DATADIR=\"/exp/ffox/share\" -DGTK_DATA_PREFIX=\"/exp/ffox\" -DGTK_SYSCONFDIR=\"/exp/ffox/etc\" -DGTK_VERSION=\"2.9.1\" -DGTK_BINARY_VERSION=\"2.10.0\" -DGTK_HOST=\"i686-pc-linux-gnu\" -DGTK_COMPILATION -DGTK_PRINT_BACKENDS=\"pdf,cups\" -I../gtk -I.. -I../gdk -I../gdk -I../gdk-pixbuf -I../gdk-pixbuf -DGDK_PIXBUF_DISABLE_DEPRECATED -DGDK_DISABLE_DEPRECATED -DGTK_DISABLE_DEPRECATED -DGTK_FILE_SYSTEM_ENABLE_UNSUPPORTED -DGTK_PRINT_BACKEND_ENABLE_UNSUPPORTED -DG_ENABLE_DEBUG -pthread -I/exp/ffox//include/glib-2.0 -I/exp/ffox//lib/glib-2.0/include -I/exp/ffox//include/pango-1.0 -I/exp/ffox//include/cairo -I/exp/ffox//include/atk-1.0 -I/exp/ffox/include -I/usr/X11R6/include -DG_DISABLE_DEPRECATED -g -O2 -g -Wall -MT gtkrecentmanager.lo -MD -MP -MF .deps/gtkrecentmanager.Tpo -c gtkrecentmanager.c -fPIC -DPIC -o .libs/gtkrecentmanager.o gtkrecentmanager.c:109: error: syntax error before "GBookmarkFile" gtkrecentmanager.c:109: warning: no semicolon at end of struct or union gtkrecentmanager.c:113: error: syntax error before '}' token gtkrecentmanager.c: In function `gtk_recent_manager_class_init': gtkrecentmanager.c:274: error: invalid application of `sizeof' to an incomplete type gtkrecentmanager.c: In function `gtk_recent_manager_init': gtkrecentmanager.c:286: error: dereferencing pointer to incomplete type gtkrecentmanager.c:290: error: dereferencing pointer to incomplete type gtkrecentmanager.c:291: error: dereferencing pointer to incomplete type gtkrecentmanager.c:293: error: dereferencing pointer to incomplete type gtkrecentmanager.c:294: error: dereferencing pointer to incomplete type gtkrecentmanager.c:295: error: dereferencing pointer to incomplete type gtkrecentmanager.c:296: error: dereferencing pointer to incomplete type gtkrecentmanager.c:298: error: dereferencing pointer to incomplete type gtkrecentmanager.c: In function `gtk_recent_manager_get_property': gtkrecentmanager.c:336: error: dereferencing pointer to incomplete type gtkrecentmanager.c:339: error: dereferencing pointer to incomplete type gtkrecentmanager.c:342: error: dereferencing pointer to incomplete type gtkrecentmanager.c: In function `gtk_recent_manager_finalize': gtkrecentmanager.c:357: error: dereferencing pointer to incomplete type gtkrecentmanager.c:358: error: dereferencing pointer to incomplete type gtkrecentmanager.c:360: error: dereferencing pointer to incomplete type gtkrecentmanager.c:361: error: dereferencing pointer to incomplete type gtkrecentmanager.c:363: error: dereferencing pointer to incomplete type gtkrecentmanager.c:364: warning: implicit declaration of function `g_bookmark_file_free' gtkrecentmanager.c:364: error: dereferencing pointer to incomplete type gtkrecentmanager.c: In function `gtk_recent_manager_real_changed': gtkrecentmanager.c:377: error: dereferencing pointer to incomplete type gtkrecentmanager.c:385: error: dereferencing pointer to incomplete type gtkrecentmanager.c:387: error: dereferencing pointer to incomplete type gtkrecentmanager.c:392: error: dereferencing pointer to incomplete type gtkrecentmanager.c:394: error: dereferencing pointer to incomplete type gtkrecentmanager.c:394: warning: implicit declaration of function `g_bookmark_file_new' gtkrecentmanager.c:395: error: dereferencing pointer to incomplete type gtkrecentmanager.c:399: warning: implicit declaration of function `g_bookmark_file_to_file' gtkrecentmanager.c:399: error: dereferencing pointer to incomplete type gtkrecentmanager.c:400: error: dereferencing pointer to incomplete type gtkrecentmanager.c:406: error: dereferencing pointer to incomplete type gtkrecentmanager.c:415: error: dereferencing pointer to incomplete type gtkrecentmanager.c:419: error: dereferencing pointer to incomplete type gtkrecentmanager.c:422: error: dereferencing pointer to incomplete type gtkrecentmanager.c:429: error: dereferencing pointer to incomplete type gtkrecentmanager.c:432: error: dereferencing pointer to incomplete type gtkrecentmanager.c: In function `gtk_recent_manager_poll_timeout': gtkrecentmanager.c:458: error: dereferencing pointer to incomplete type gtkrecentmanager.c:458: error: dereferencing pointer to incomplete type gtkrecentmanager.c:461: error: dereferencing pointer to incomplete type gtkrecentmanager.c:470: error: dereferencing pointer to incomplete type gtkrecentmanager.c:477: error: dereferencing pointer to incomplete type gtkrecentmanager.c: In function `gtk_recent_manager_set_filename': gtkrecentmanager.c:498: error: dereferencing pointer to incomplete type gtkrecentmanager.c:500: error: dereferencing pointer to incomplete type gtkrecentmanager.c:502: error: dereferencing pointer to incomplete type gtkrecentmanager.c:503: error: dereferencing pointer to incomplete type gtkrecentmanager.c:506: error: dereferencing pointer to incomplete type gtkrecentmanager.c:507: error: dereferencing pointer to incomplete type gtkrecentmanager.c:514: error: dereferencing pointer to incomplete type gtkrecentmanager.c: In function `build_recent_items_list': gtkrecentmanager.c:534: error: dereferencing pointer to incomplete type gtkrecentmanager.c:536: error: dereferencing pointer to incomplete type gtkrecentmanager.c:538: error: dereferencing pointer to incomplete type gtkrecentmanager.c:539: error: dereferencing pointer to incomplete type gtkrecentmanager.c:542: error: dereferencing pointer to incomplete type gtkrecentmanager.c:555: error: dereferencing pointer to incomplete type gtkrecentmanager.c:563: error: dereferencing pointer to incomplete type gtkrecentmanager.c:565: error: dereferencing pointer to incomplete type gtkrecentmanager.c:571: warning: implicit declaration of function `g_bookmark_file_load_from_file' gtkrecentmanager.c:571: error: dereferencing pointer to incomplete type gtkrecentmanager.c:572: error: dereferencing pointer to incomplete type gtkrecentmanager.c:578: error: dereferencing pointer to incomplete type gtkrecentmanager.c:581: error: dereferencing pointer to incomplete type gtkrecentmanager.c:582: error: dereferencing pointer to incomplete type gtkrecentmanager.c:587: warning: implicit declaration of function `g_bookmark_file_get_size' gtkrecentmanager.c:587: error: dereferencing pointer to incomplete type gtkrecentmanager.c:588: error: dereferencing pointer to incomplete type gtkrecentmanager.c:590: error: dereferencing pointer to incomplete type gtkrecentmanager.c:595: error: dereferencing pointer to incomplete type gtkrecentmanager.c:596: error: dereferencing pointer to incomplete type gtkrecentmanager.c: In function `IA__gtk_recent_manager_get_for_screen': gtkrecentmanager.c:683: error: dereferencing pointer to incomplete type gtkrecentmanager.c: In function `display_closed': gtkrecentmanager.c:697: error: dereferencing pointer to incomplete type gtkrecentmanager.c:698: error: dereferencing pointer to incomplete type gtkrecentmanager.c:703: error: dereferencing pointer to incomplete type gtkrecentmanager.c: In function `unset_screen': gtkrecentmanager.c:718: error: dereferencing pointer to incomplete type gtkrecentmanager.c:720: error: dereferencing pointer to incomplete type gtkrecentmanager.c:726: error: dereferencing pointer to incomplete type gtkrecentmanager.c: In function `IA__gtk_recent_manager_set_screen': gtkrecentmanager.c:759: error: dereferencing pointer to incomplete type gtkrecentmanager.c: In function `IA__gtk_recent_manager_set_limit': gtkrecentmanager.c:786: error: dereferencing pointer to incomplete type gtkrecentmanager.c: In function `IA__gtk_recent_manager_get_limit': gtkrecentmanager.c:808: error: dereferencing pointer to incomplete type gtkrecentmanager.c: In function `IA__gtk_recent_manager_add_full': gtkrecentmanager.c:977: error: dereferencing pointer to incomplete type gtkrecentmanager.c:979: error: dereferencing pointer to incomplete type gtkrecentmanager.c:980: error: dereferencing pointer to incomplete type gtkrecentmanager.c:984: warning: implicit declaration of function `g_bookmark_file_set_title' gtkrecentmanager.c:984: error: dereferencing pointer to incomplete type gtkrecentmanager.c:987: warning: implicit declaration of function `g_bookmark_file_set_description' gtkrecentmanager.c:987: error: dereferencing pointer to incomplete type gtkrecentmanager.c:989: warning: implicit declaration of function `g_bookmark_file_set_mime_type' gtkrecentmanager.c:989: error: dereferencing pointer to incomplete type gtkrecentmanager.c:996: warning: implicit declaration of function `g_bookmark_file_add_group' gtkrecentmanager.c:996: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1003: warning: implicit declaration of function `g_bookmark_file_add_application' gtkrecentmanager.c:1003: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1007: warning: implicit declaration of function `g_bookmark_file_set_is_private' gtkrecentmanager.c:1007: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1013: error: dereferencing pointer to incomplete type gtkrecentmanager.c: In function `IA__gtk_recent_manager_remove_item': gtkrecentmanager.c:1048: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1050: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1051: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1061: warning: implicit declaration of function `g_bookmark_file_remove_item' gtkrecentmanager.c:1061: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1069: error: dereferencing pointer to incomplete type gtkrecentmanager.c: In function `IA__gtk_recent_manager_has_item': gtkrecentmanager.c:1098: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1100: warning: implicit declaration of function `g_bookmark_file_has_item' gtkrecentmanager.c:1100: error: dereferencing pointer to incomplete type gtkrecentmanager.c: At top level: gtkrecentmanager.c:1104: error: syntax error before '*' token gtkrecentmanager.c: In function `build_recent_info': gtkrecentmanager.c:1110: error: `bookmarks' undeclared (first use in this function) gtkrecentmanager.c:1110: error: (Each undeclared identifier is reported only once gtkrecentmanager.c:1110: error: for each function it appears in.) gtkrecentmanager.c:1111: error: `info' undeclared (first use in this function) gtkrecentmanager.c:1113: warning: implicit declaration of function `g_bookmark_file_get_title' gtkrecentmanager.c:1114: warning: implicit declaration of function `g_bookmark_file_get_description' gtkrecentmanager.c:1115: warning: implicit declaration of function `g_bookmark_file_get_mime_type' gtkrecentmanager.c:1117: warning: implicit declaration of function `g_bookmark_file_get_is_private' gtkrecentmanager.c:1119: warning: implicit declaration of function `g_bookmark_file_get_added' gtkrecentmanager.c:1120: warning: implicit declaration of function `g_bookmark_file_get_modified' gtkrecentmanager.c:1121: warning: implicit declaration of function `g_bookmark_file_get_visited' gtkrecentmanager.c:1123: warning: implicit declaration of function `g_bookmark_file_get_groups' gtkrecentmanager.c:1123: warning: assignment makes pointer from integer without a cast gtkrecentmanager.c:1133: warning: implicit declaration of function `g_bookmark_file_get_applications' gtkrecentmanager.c:1133: warning: assignment makes pointer from integer without a cast gtkrecentmanager.c:1144: warning: implicit declaration of function `g_bookmark_file_get_app_info' gtkrecentmanager.c: In function `IA__gtk_recent_manager_lookup_item': gtkrecentmanager.c:1196: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1198: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1199: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1209: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1224: error: dereferencing pointer to incomplete type gtkrecentmanager.c: In function `IA__gtk_recent_manager_move_item': gtkrecentmanager.c:1268: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1278: warning: implicit declaration of function `g_bookmark_file_move_item' gtkrecentmanager.c:1278: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1287: error: dereferencing pointer to incomplete type gtkrecentmanager.c: In function `IA__gtk_recent_manager_get_items': gtkrecentmanager.c:1317: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1320: warning: implicit declaration of function `g_bookmark_file_get_uris' gtkrecentmanager.c:1320: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1320: warning: assignment makes pointer from integer without a cast gtkrecentmanager.c:1327: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1344: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1345: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1349: error: dereferencing pointer to incomplete type gtkrecentmanager.c: In function `purge_recent_items_list': gtkrecentmanager.c:1370: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1373: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1374: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1376: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1377: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1378: error: dereferencing pointer to incomplete type gtkrecentmanager.c: In function `IA__gtk_recent_manager_purge_items': gtkrecentmanager.c:1406: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1409: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1415: error: dereferencing pointer to incomplete type make[4]: *** [gtkrecentmanager.lo] Error 1 make[4]: Leaving directory `/exp/ffox/gtk+-2.9.1/gtk' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/exp/ffox/gtk+-2.9.1/gtk' make[2]: *** [all] Error 2 make[2]: Leaving directory `/exp/ffox/gtk+-2.9.1/gtk' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/exp/ffox/gtk+-2.9.1' make: *** [all] Error 2 Pls help me out to find a solution. regards, Jala The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s)and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender or administrator@tataelxsi.co.in From mitch@gimp.org Fri Jun 30 13:17:37 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 4D29A3B00D8 for ; Fri, 30 Jun 2006 13:17:37 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02485-01 for ; Fri, 30 Jun 2006 13:17:35 -0400 (EDT) Received: from mitch.gimp.org (unknown [88.134.98.187]) by menubar.gnome.org (Postfix) with ESMTP id 96E4C3B00FF for ; Fri, 30 Jun 2006 13:17:35 -0400 (EDT) Received: from mitch by mitch.gimp.org with local (Exim 3.36 #1 (Debian)) id 1FvZfn-00022M-00; Wed, 28 Jun 2006 15:01:39 +0200 Subject: Re: gdk_display_close segfault? From: Michael Natterer To: Dave Foster In-Reply-To: <1151470915.4791.3.camel@neptune.minuslab.net> References: <1151470915.4791.3.camel@neptune.minuslab.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Wed, 28 Jun 2006 15:01:39 +0200 Message-Id: <1151499699.4451.0.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-0.219 tagged_above=-999 required=2 tests=[AWL=-2.068, BAYES_00=-2.599, DATE_IN_PAST_48_96=0.379, RCVD_IN_NJABL_DUL=1.946, RCVD_IN_SORBS_DUL=2.046, TW_GT=0.077] X-Spam-Score: -0.219 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jun 2006 17:17:37 -0000 Hi, you can stop debugging right away. Display closing *only* works in GTK+ 2.9.x (upcoming 2.10). No way of making this work in any earlier version. ciao, --mitch On Wed, 2006-06-28 at 01:01 -0400, Dave Foster wrote: > Hi, > > I've been trying to write a small section of code in my program which > makes a second connection to the X display, using gtkmm.. I kept having > problems, after rewriting it about 5 or 6 times, I tried writing it in > straight gdk, and STILL got the problems. > > I seem to get a segfault whenever I call gdk_display_close(). Here is a > rediculously simple example that gives the problem: > > Glib::ustring disp = ":0.0"; > GdkDisplay* gdisp = gdk_display_open(disp.c_str()); > if (!gdisp) ... > gdk_display_close(gdisp); > > /* > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread -1224202560 (LWP 5689)] > 0xb7b413d0 in gdk_display_x11_dispose () from /usr/lib/libgdk-x11-2.0.so.0 > (gdb) bt > #0 0xb7b413d0 in gdk_display_x11_dispose () from /usr/lib/libgdk-x11-2.0.so.0 > #1 0xb7a11f2b in g_object_unref () from /usr/lib/libgobject-2.0.so.0 > #2 0xb7b20c04 in gdk_display_close () from /usr/lib/libgdk-x11-2.0.so.0 > #3 0x080571d5 in SetBG::set_bg (disp=@0xbfe1b2b0, file=@0xbfe1b2ac, > mode=SetBG::SET_SCALE, bgcolor=@0xbfe1b2a8) at SetBG.cc:67 > ... > */ > > The display is opening fine. I'm running: > > gtk: 2.8.17-1 > glib: 2.10.2-1 > > (hmm, didn't notice that before,t he 2.8 vs 2.10 thing, could that be it?) > > Anyway, I've spent all night trying to debug this and weeks trying to > sort this problem out in my program. What is up with this, what can I > do? > > thanks all. > dave > > > > _______________________________________________ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-devel-list From jalaganapathy@tataelxsi.co.in Fri Jun 30 02:45:45 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id DF5083B0105 for ; Fri, 30 Jun 2006 02:45:44 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30527-07 for ; Fri, 30 Jun 2006 02:45:41 -0400 (EDT) Received: from mail.tataelxsi.co.in (mail.tataelxsi.co.in [203.200.1.48]) by menubar.gnome.org (Postfix) with ESMTP id 39FF93B00B8 for ; Fri, 30 Jun 2006 02:45:39 -0400 (EDT) Received: from jalaganapathy (tataelxsi.co.in [203.197.169.80] (may be forged)) by mail.tataelxsi.co.in (MOS 3.7.4b-GA) with ESMTP id BRR48672 (AUTH jalaganapathy); Fri, 30 Jun 2006 12:17:02 +0530 (IST) From: Jalagandeswari G To: Subject: Installing Cairo1.1.6 Date: Fri, 30 Jun 2006 12:16:06 +0530 Message-ID: <006301c69c10$ddbbf3d0$321b320a@telxsi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal X-Junkmail: Blacklisted X-Mirapoint-Sig: mail.tataelxsi.co.in X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-0.964 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.558, TW_BP=0.077] X-Spam-Score: -0.964 X-Spam-Level: X-Mailman-Approved-At: Fri, 30 Jun 2006 18:07:05 -0400 X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jun 2006 06:45:45 -0000 Hello All, While installing cairo-1.1.6 on FC3 i am getting following errors during configure I am using glib-2.11.1 $./configure checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking whether to enable maintainer-specific portions of Makefiles... no checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for style of include used by make... GNU checking dependency style of gcc... gcc3 checking how to run the C preprocessor... gcc -E checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking for a sed that does not truncate output... /bin/sed checking for egrep... grep -E checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking dependency style of g++... gcc3 checking how to run the C++ preprocessor... g++ -E checking for g77... g77 checking whether we are using the GNU Fortran 77 compiler... yes checking whether g77 accepts -g... yes checking the maximum length of command line arguments... 32768 checking command to parse /usr/bin/nm -B output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc supports -fno-rtti -fno-exceptions... no checking for gcc option to produce PIC... -fPIC checking if gcc PIC flag -fPIC works... yes checking if gcc static flag -static works... yes checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by g++... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking for g++ option to produce PIC... -fPIC checking if g++ PIC flag -fPIC works... yes checking if g++ static flag -static works... yes checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate appending configuration tag "F77" to libtool checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes checking for g77 option to produce PIC... -fPIC checking if g77 PIC flag -fPIC works... yes checking if g77 static flag -static works... yes checking if g77 supports -c -o file.o... yes checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking for ANSI C header files... (cached) yes checking whether byte ordering is bigendian... no checking for vasnprintf... no checking for cos in -lm... yes checking for pkg-config... /usr/bin/pkg-config checking pkg-config is at least version 0.9.0... yes checking for cairo's xlib backend... checking for XRENDER... Package xrender was not found in the pkg-config search path. Perhaps you should add the directory containing `xrender.pc' to the PKG_CONFIG_PATH environment variable No package 'xrender' found checking X11/extensions/Xrender.h usability... no checking X11/extensions/Xrender.h presence... no checking for X11/extensions/Xrender.h... no checking for XrmFinalize... no checking whether cairo's xlib backend could be enabled... no (requires Xrender http://freedesktop.org/Software/xlibs) checking for cairo's win32 backend... checking whether cairo's win32 backend could be enabled... no (the Microsoft Windows backend requires a Win32 platform) checking for cairo's png backend... configure: WARNING: Could not find libpng in the pkg-config Can any one please post a solution for this. regards, Jala The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s)and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender or administrator@tataelxsi.co.in From sandmann@daimi.au.dk Wed May 31 23:16:04 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id F331F3B0084 for ; Wed, 31 May 2006 23:16:03 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01799-09 for ; Wed, 31 May 2006 23:16:01 -0400 (EDT) Received: from daimi.au.dk (daimi.au.dk [130.225.16.1]) by menubar.gnome.org (Postfix) with ESMTP id 48A283B00AD for ; Wed, 31 May 2006 23:16:00 -0400 (EDT) Received: from camel30.daimi.au.dk (camel30 [130.225.16.149]) by daimi.au.dk (8.12.11.20060308/8.12.11) with ESMTP id k513FvkJ026470; Thu, 1 Jun 2006 05:15:58 +0200 Received: from camel30.daimi.au.dk (IDENT:U2FsdGVkX1+qd3TE3mk4InNR0+PybNGNUpbzCHnIsw0@localhost [127.0.0.1]) by camel30.daimi.au.dk (8.13.1/8.13.1) with ESMTP id k513Fvit009418; Thu, 1 Jun 2006 05:15:57 +0200 Received: (from sandmann@localhost) by camel30.daimi.au.dk (8.13.1/8.13.1/Submit) id k513FvG8009413; Thu, 1 Jun 2006 05:15:57 +0200 X-Authentication-Warning: camel30.daimi.au.dk: sandmann set sender to sandmann@daimi.au.dk using -f Sender: sandmann@daimi.au.dk To: Kristian Rietveld References: <20060314132538.GA3526@babi-pangang.org> <443B4A8A.8000302@imendio.com> <20060425103017.GA15762@babi-pangang.org> <20060531183045.GA7564@babi-pangang.org> From: Soeren Sandmann Date: 01 Jun 2006 05:15:57 +0200 In-Reply-To: <20060531183045.GA7564@babi-pangang.org> Message-ID: Lines: 28 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.56 on 130.225.16.1 X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.575 tagged_above=-999 required=2 tests=[AWL=0.024, BAYES_00=-2.599] X-Spam-Score: -2.575 X-Spam-Level: Cc: Gtk+ Developers , Tim Janik Subject: Re: Callback based tooltips (Re: New tooltips API, continued) X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2006 03:16:04 -0000 Kristian Rietveld writes: > I mostly like the behaviour you described below. > > > - Tooltips are too intrusive. The text should be smaller, and > > they should to the right of the cursor, and a little below > > the cursor's center. > > > > |\ ___________ > > | | tooltip | > > > > not centered below the cursor. > > If you want to have the tooltip right of the cursor, a little below the > cursor's center, does this also mean you want to have the tooltip follow > the mouse pointer? Might make sense else in this case, else the tooltip > might end up being positioned statically above the middle of a widget > ... Probably not; I'd have to try it out to see. Mostly the important thing is that the tooltip is positioned to the right of the cursor rather than centered as it is currently. I think Firefox gets the positioning mostly right, so copying that might not be the worst idea. Soren From mardy@users.sourceforge.net Thu Jun 1 07:04:29 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 633423B0C7E for ; Thu, 1 Jun 2006 07:04:29 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28962-04 for ; Thu, 1 Jun 2006 07:04:28 -0400 (EDT) Received: from smtp010.mail.ukl.yahoo.com (smtp010.mail.ukl.yahoo.com [217.12.11.79]) by menubar.gnome.org (Postfix) with SMTP id 690073B013F for ; Thu, 1 Jun 2006 07:04:27 -0400 (EDT) Received: (qmail 61490 invoked from network); 1 Jun 2006 11:04:26 -0000 Received: from unknown (HELO pupilla) (mardy78@151.42.226.237 with login) by smtp010.mail.ukl.yahoo.com with SMTP; 1 Jun 2006 11:04:26 -0000 Received: by pupilla (Postfix, from userid 1000) id 038336B7FF; Thu, 1 Jun 2006 13:03:17 +0200 (CEST) Date: Thu, 1 Jun 2006 13:03:17 +0200 From: Alberto Mardegan To: gtk-devel-list@gnome.org Message-ID: <20060601110317.GA23802@pupilla> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Accept-Language: it,ia,en,bg,es,fr User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.599 tagged_above=-999 required=2 tests=[BAYES_00=-2.599] X-Spam-Score: -2.599 X-Spam-Level: Subject: Histogram widget X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2006 11:04:29 -0000 Hi all! I'm going to write a widget for displaying histograms. Would it be elegant/smart/useful if it were to fetch the data from a GtkTreeModel, or would it be an unneeded complexity and just some GArrays are better? I'm thinking of a GtkTreeModel, in which every row is a histogram bar; hence we would/could have a double field for the value, a string field for the label in the X axis, maybe a GdkColor for the color and whatever can come to mind. Many thanks in advance to all those who will share their thoughts on the matter. -- Saluti, Mardy http://www.interlingua.com ___________________________________ Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB http://mail.yahoo.it From matthias.clasen@gmail.com Thu Jun 1 09:35:39 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 44D6D3B0213 for ; Thu, 1 Jun 2006 09:35:39 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06492-04 for ; Thu, 1 Jun 2006 09:35:37 -0400 (EDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.190]) by menubar.gnome.org (Postfix) with ESMTP id 2B1463B019C for ; Thu, 1 Jun 2006 09:35:37 -0400 (EDT) Received: by nf-out-0910.google.com with SMTP id l37so564726nfc for ; Thu, 01 Jun 2006 06:35:36 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=AXg4pkieJhFwK/fsPTG5BVq6Sv29H8f6t8wbUeiehWS8QFuJL4sEqqu5dTplyA7vdRrz50uICadI8ZT1y2rp+BasRLmOBacUSSXY1blUEAIWfvb1udC+bqhsXFVhdU6V4+2wZCjIuaczx07TxLq1x+v9zHm4YPkA8kydW+5SycA= Received: by 10.48.31.10 with SMTP id e10mr779574nfe; Thu, 01 Jun 2006 06:33:48 -0700 (PDT) Received: by 10.48.215.7 with HTTP; Thu, 1 Jun 2006 06:33:48 -0700 (PDT) Message-ID: Date: Thu, 1 Jun 2006 09:33:48 -0400 From: "Matthias Clasen" To: "Kristian Rietveld" In-Reply-To: <20060531200823.GA7846@babi-pangang.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20060531200823.GA7846@babi-pangang.org> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.742 tagged_above=-999 required=2 tests=[AWL=-0.700, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.558, SPF_PASS=-0.001] X-Spam-Score: -1.742 X-Spam-Level: Cc: gtk-devel-list@gnome.org, timj@imendio.com Subject: Re: Tooltips progress X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2006 13:35:39 -0000 > Attached is some sample code using the new API. Opinions, comments, > suggestions are appreciated. > I don't remember too much of the original proposal, so I'll just go by what I see in the examples... What is the relation between the tooltip-markup and has-tooltip properties ? Is has-tooltip automatically set when setting tooltip-markup ? Or do you only need to set has-tooltip if you want to connect to query-tooltip ? Is the tooltip window available as a property too ? (The example uses a dedicated setter for it). The example doesn't show tooltips constructed using the old tooltips api, but I assume those will continue to work as before, right ? Using x == -1 to indicate a keyboard-triggered tooltip looks a bit odd to me; how about adding a boolean parameter for this ? Regarding dedicated treeview api, I think we can do without it (at least initially), if we have a good example in the docs. Though lots of people will forget the selection_changed thing for keyboard tooltips... Could you enhance your demo with an example of text view tooltips on a tag ? Matthias From jean.brefort@normalesup.org Thu Jun 1 09:58:21 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 479CD3B0171 for ; Thu, 1 Jun 2006 09:58:03 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08512-08 for ; Thu, 1 Jun 2006 09:58:01 -0400 (EDT) Received: from smtp4-g19.free.fr (smtp4-g19.free.fr [212.27.42.30]) by menubar.gnome.org (Postfix) with ESMTP id 84A533B0CBB for ; Thu, 1 Jun 2006 09:57:52 -0400 (EDT) Received: from che21-1-82-239-125-56.fbx.proxad.net (che21-1-82-239-125-56.fbx.proxad.net [82.239.125.56]) by smtp4-g19.free.fr (Postfix) with ESMTP id DE3EA54C0D; Thu, 1 Jun 2006 15:57:50 +0200 (CEST) From: Jean =?ISO-8859-1?Q?Br=E9fort?= To: Alberto Mardegan In-Reply-To: <20060601110317.GA23802@pupilla> References: <20060601110317.GA23802@pupilla> Content-Type: text/plain; charset=utf-8 Date: Thu, 01 Jun 2006 16:00:49 +0200 Message-Id: <1149170449.11316.1.camel@athlon.brefort.fr> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.884 tagged_above=-999 required=2 tests=[AWL=-0.354, BAYES_00=-2.599, SPF_NEUTRAL=1.069] X-Spam-Score: -1.884 X-Spam-Level: Cc: gtk-devel-list@gnome.org Subject: Re: Histogram widget X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2006 13:58:21 -0000 Le jeudi 01 juin 2006 13:03 +0200, Alberto Mardegan a crit : > Hi all! > I'm going to write a widget for displaying histograms. Would it be > elegant/smart/useful if it were to fetch the data from a GtkTreeModel, > or would it be an unneeded complexity and just some GArrays are better? > > I'm thinking of a GtkTreeModel, in which every row is a histogram bar; > hence we would/could have a double field for the value, a string field > for the label in the X axis, maybe a GdkColor for the color and whatever > can come to mind. > > Many thanks in advance to all those who will share their thoughts on the > matter. Do you want histograms or column charts? Anyway both already exist in goffice and we have the GOGraphWidget widget to display a large variety of 2D charts. Regards, Jean Brfort From mitch@gimp.org Thu Jun 1 10:37:41 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 9C8673B0253 for ; Thu, 1 Jun 2006 10:37:41 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12026-06 for ; Thu, 1 Jun 2006 10:37:40 -0400 (EDT) Received: from mitch.gimp.org (p549C9506.dip0.t-ipconnect.de [84.156.149.6]) by menubar.gnome.org (Postfix) with ESMTP id 630D53B0171 for ; Thu, 1 Jun 2006 10:37:40 -0400 (EDT) Received: from mitch by mitch.gimp.org with local (Exim 3.36 #1 (Debian)) id 1FloKa-0005tI-00; Thu, 01 Jun 2006 16:39:24 +0200 From: Michael Natterer To: Kristian Rietveld In-Reply-To: <20060531200823.GA7846@babi-pangang.org> References: <20060531200823.GA7846@babi-pangang.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Thu, 01 Jun 2006 16:39:24 +0200 Message-Id: <1149172764.5721.13.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-0.468 tagged_above=-999 required=2 tests=[AWL=-1.996, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, RCVD_IN_NJABL_DUL=1.946, RCVD_IN_SORBS_DUL=2.046] X-Spam-Score: -0.468 X-Spam-Level: Cc: gtk-devel-list@gnome.org, timj@imendio.com Subject: Re: Tooltips progress X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2006 14:37:41 -0000 On Wed, 2006-05-31 at 22:08 +0200, Kristian Rietveld wrote: > Currently, we are using the following query-tooltips signal: > > gboolean (*query_tooltip) (GtkWidget *widget, > gint x, > gint y, > GtkTooltip *tooltip); > > But if a user sets a custom using gtk_widget_set_custom_window(), we don't > have to pass a GtkTooltip around. So currently I just set the tooltip > field to NULL, so the user knows he has to use his own custom tooltip > window (and we assume he has a reference to that). Is this okay or do > we want to change this? We could also move the _set_custom_window() > functions into GtkTooltip for example. I would very much appreciate if the GtkTooltip object also kept track of the custom window. IMHO it makes no sense to handle this differently. gtk_tooltip_set_markup() vs. gtk_tooltip_set_window() simply feels much better than the asymmetry in gtk_tooltip_set_markup() vs. gtk_widget_set_tooltip_window() The current approach even limits the new tooltip system's use cases, since you have to set the custom window *outside* the callback. There is no way to decide *in* the callback if a standard tooltip is sufficient, or if a custom window is needed. Another problem is the assymetry in getting the relevant data to the callback. With markup, the GtkTooltip can be queried for the markup, if it's a custom window, you have to get it to the callback somehow. In your example code it's passed as user_data, but user_data is often not available since it's needed for other things, so you have to add a "GtkWidget *tooltip_window" to the "other thing". If "other thing" is e.g. the application toplevel window, which of the sub-widget's tooltips should it keep? All of them? People will in many cases end up attaching the tooltip window to the widget. I also fail to see why the "has-tooltip" property has to be set to TRUE, even tho a tooltip window was set on the widget. ciao, --mitch From islewind@gmail.com Thu Jun 1 11:16:53 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id CCF0F3B027D for ; Thu, 1 Jun 2006 11:16:53 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15167-10 for ; Thu, 1 Jun 2006 11:16:52 -0400 (EDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.181]) by menubar.gnome.org (Postfix) with ESMTP id EBDF73B02A2 for ; Thu, 1 Jun 2006 11:16:51 -0400 (EDT) Received: by py-out-1112.google.com with SMTP id x31so492875pye for ; Thu, 01 Jun 2006 08:16:51 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=TJcxirCpCUc11Q5e90yGryvZPvt6/4y9oixknOJbU9D0ul2vMJTRqtCSsnJU4SxRLn9lAKaOyN+GZ5nbxOOcf0T99ZPfjnqzOA3KseyOVQ4Ap+A8c67skU0CG6t40az7MwaWe4KCKIFXgrpOCN10KzuNVCisW4dtldpMgxlx5bQ= Received: by 10.35.36.13 with SMTP id o13mr1010511pyj; Thu, 01 Jun 2006 08:16:51 -0700 (PDT) Received: by 10.35.10.17 with HTTP; Thu, 1 Jun 2006 08:16:50 -0700 (PDT) Message-ID: <7bf6f2dc0606010816q15d512aejc30a6c93bc165e6@mail.gmail.com> Date: Thu, 1 Jun 2006 17:16:50 +0200 From: "=?ISO-8859-1?Q?=D8yvind_Kol=E5s?=" Sender: islewind@gmail.com To: "=?ISO-8859-1?Q?Carlos_Eduardo_Rodrigues_Di=F3genes?=" In-Reply-To: <1149104973.27709.4.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <1149104973.27709.4.camel@localhost.localdomain> X-Google-Sender-Auth: aee248fb7aae0f83 X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.571 tagged_above=-999 required=2 tests=[AWL=0.029, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.571 X-Spam-Level: Cc: gtk-devel-list@gnome.org Subject: Re: Color space transformations in GTK X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2006 15:16:54 -0000 On 5/31/06, Carlos Eduardo Rodrigues Di=F3genes = wrote: > Hi, > > There is any plan to add color spaces conversions in GTK+ (GDK or > Gdk-Pixbuf)? If the answear is no, why not? Pixel format conversions is not a small piece of code and the needed pixel formats varies from scenario to scenario. Most programs will not need such a large general infrastructure and the ones that really need it would probably not be satisfied with a simpler solution. What functionality is it you miss that you think fits into a GUI toolkit? (color management is a seperate issue to color space(pixel format) conversions according to my interpretation of your question). /=D8yvind K. --=20 =ABThe future is already here. It's just not very evenly distributed=BB -- William Gibson http://pippin.gimp.org/ http://ffii.org/ From timj@gtk.org Thu Jun 1 11:17:09 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 565CF3B0DC9 for ; Thu, 1 Jun 2006 11:17:09 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15377-03 for ; Thu, 1 Jun 2006 11:17:02 -0400 (EDT) Received: from webmail.hansenet.de (mail01.hansenet.de [213.191.73.61]) by menubar.gnome.org (Postfix) with ESMTP id 8AFEE3B0DB5 for ; Thu, 1 Jun 2006 11:17:00 -0400 (EDT) Received: from birnet.org (213.39.195.111) by webmail.hansenet.de (7.2.059) id 447D3FB2000502B1; Thu, 1 Jun 2006 17:16:59 +0200 Received: from master.birnet.private (localhost [127.0.0.1]) by birnet.org (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k51FGvIU003186 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 1 Jun 2006 17:16:57 +0200 Received: (from timj@localhost) by master.birnet.private (8.13.4/8.13.4/Submit) id k51FGpl3003183; Thu, 1 Jun 2006 17:16:51 +0200 Date: Thu, 1 Jun 2006 17:16:51 +0200 (CEST) From: Tim Janik X-X-Sender: timj@master.birnet.private To: Kristian Rietveld In-Reply-To: <20060531183045.GA7564@babi-pangang.org> Message-ID: References: <20060314132538.GA3526@babi-pangang.org> <443B4A8A.8000302@imendio.com> <20060425103017.GA15762@babi-pangang.org> <20060531183045.GA7564@babi-pangang.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.431 tagged_above=-999 required=2 tests=[AWL=0.168, BAYES_00=-2.599] X-Spam-Score: -2.431 X-Spam-Level: Cc: Gtk+ Developers , Soeren Sandmann Subject: Re: Callback based tooltips (Re: New tooltips API, continued) X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2006 15:17:10 -0000 On Wed, 31 May 2006, Kristian Rietveld wrote: > On Tue, Apr 25, 2006 at 03:08:12PM +0200, Soeren Sandmann wrote: >> I once wrote down how tooltips should behave: > > I mostly like the behaviour you described below. > >> - Tooltips are too intrusive. The text should be smaller, and not sure if this has been raised already... the font size of the tooltips should be exactly as large as the default font size (module tooltip markup of course) to avoid reducing usability of the tooltips in contrast to normal text (labels). >> they should to the right of the cursor, and a little below >> the cursor's center. --- ciaoTJ From timj@gtk.org Thu Jun 1 12:12:43 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id E5C0F3B0171 for ; Thu, 1 Jun 2006 12:12:42 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19272-05 for ; Thu, 1 Jun 2006 12:12:40 -0400 (EDT) Received: from webmail.hansenet.de (mail03.hansenet.de [213.191.73.10]) by menubar.gnome.org (Postfix) with ESMTP id 9C9433B015C for ; Thu, 1 Jun 2006 12:12:39 -0400 (EDT) Received: from birnet.org (213.39.195.111) by webmail.hansenet.de (7.2.059) id 447C08450012767E; Thu, 1 Jun 2006 18:12:37 +0200 Received: from master.birnet.private (localhost [127.0.0.1]) by birnet.org (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k51GCZTL005312 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 1 Jun 2006 18:12:35 +0200 Received: (from timj@localhost) by master.birnet.private (8.13.4/8.13.4/Submit) id k51GCY4h005311; Thu, 1 Jun 2006 18:12:34 +0200 Date: Thu, 1 Jun 2006 18:12:34 +0200 (CEST) From: Tim Janik X-X-Sender: timj@master.birnet.private To: Kristian Rietveld In-Reply-To: <20060531200823.GA7846@babi-pangang.org> Message-ID: References: <20060531200823.GA7846@babi-pangang.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.434 tagged_above=-999 required=2 tests=[AWL=0.165, BAYES_00=-2.599] X-Spam-Score: -2.434 X-Spam-Level: Cc: Gtk+ Developers , Matthias Clasen Subject: Re: Tooltips progress X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2006 16:12:43 -0000 On Wed, 31 May 2006, Kristian Rietveld wrote: > Last week I've been working on the tooltips implementation, using the > callback-based approach/interface discussed earlier on this mailing list. > The basics are working already including keyboard support and custom > windows. Before I can finalize a patch for reviewal, I have some comments > and questions. > > > In a follow up to his original mail, Tim is talking about adding the > following function: > > gdk_display_force_query_display (GdkDisplay *); > > I am not sure if this really belongs in GdkDisplay. Currently I have a: > > gtk_widget_force_query_tooltip (GtkWidget *widget); > > which works just fine for forcably updating a tooltip, in both keyboard > and mouse mode. I guess most people will usually know which widget's > tooltip to update. Opinions? yes, in most cases the widget will be known, but not in all. the trivial example is changing per-display settings like ::display-tooltips = off or the timeout. also, since we support nesting/overlaying of widgets. even the display might not be clear, which is why i actually proposed: void gtk_display_force_tooltip_query (GdkDisplay*); /* display may be NULL */ /* because of nesting/overlapping tooltips, widget is not always known * http://mail.gnome.org/archives/gtk-devel-list/2006-April/msg00030.html */ but you have a point here, since in most cases the widget will indeed be known, it'll be most convenient to also provide: void gtk_widget_force_query_tooltip (GtkWidget *widget) { gtk_display_force_tooltip_query (gtk_widget_get_display (widget)); } > Currently, we are using the following query-tooltips signal: > > gboolean (*query_tooltip) (GtkWidget *widget, > gint x, > gint y, > GtkTooltip *tooltip); > > But if a user sets a custom using gtk_widget_set_custom_window(), we don't > have to pass a GtkTooltip around. So currently I just set the tooltip > field to NULL, so the user knows he has to use his own custom tooltip > window (and we assume he has a reference to that). my original proposal http://mail.gnome.org/archives/gtk-devel-list/2006-April/msg00010.html included: GtkWindow* gtk_widget_get_tooltip_window (GtkWidget *widget); so the user doesn't need to duplicate tracking of this window. > Is this okay or do > we want to change this? We could also move the _set_custom_window() > functions into GtkTooltip for example. no, i intentionally didn't put it there. the reasoning for this was: - the setter should go along with a getter - the user should get at the custom window but *not* the tooltips window used by gtk. the latter is violated with a getter on GtkTooltip. > Implementing GtkTreeView tooltips in your application is now pretty easy, > just set up a query_tooltip callback and call gtk_tree_view_get_path_at_pos() > with the coordinates which are provided to you (but if x == -1, the keyboard > mode is enabled and then you should really call gtk_tree_view_get_cursor()). using x==-1&&y==-1 for keyboard mode was a bit of an aftermath patchup to my original proposal. Matthias Clasen now pointed out: > Using x == -1 to indicate a keyboard-triggered tooltip looks a bit > odd to me; how about adding a boolean parameter for this ? and i thnk he is right. another indication that we'd not want (-1,-1) is that you already talk about querying the cursor yourself. so it's probably better to adapt the signal to: gboolean (*query_tooltip) (GtkWidget *widget, gint x, gint y, gboolean keyboard_tip, GtkTooltip *tooltip); and preserve the x,y position. > Would this be sufficient, or do we want to add some special API for supporting > tooltips in the tree view, like having GtkTreeView implement the query > tooltip callback and have tooltip-markup properties on cell renderers. > Personally I think implementing the query-tooltip yourself is easy enough > for people to do and also really flexible, so there's no need for more API. i'd say let's first nail the basic tooltip API. GtkWidget already comes with a default handler. we can still add treeview convenience API later on if that is required. (and for that, i think it'd be easiest to forward the query_tooltip() signal to signals on the columns and cell renderers). > Since we re-query for a tooltip on mouse motion, I was wondering what we > should do in keyboard mode if a key is pressed in, for example, GtkTreeView. > A key press there might change the cursor and we might want to update the > tooltip contents. Do we want stock GTK+ to take care of this, or should the > user do this himself? (For example by calling gtk_widget_force_tooltip_query > from the GtkTreeSelection::changed callback). i think i'd handle key press events like mouse motion and scroll events, i.e. re-query. that eases things on the user side and is consistent with movement. (the basic idea behind my proposal was that gtk+ takes care of the required granularity whenever possible, so gtk_display_force_tooltip_query() needs to allmost never be used). > thanks, > > -kris. > --- ciaoTJ From timj@gtk.org Thu Jun 1 12:21:35 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 96AD53B0E27 for ; Thu, 1 Jun 2006 12:21:35 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19725-05 for ; Thu, 1 Jun 2006 12:21:33 -0400 (EDT) Received: from webmail.hansenet.de (mail02.hansenet.de [213.191.73.62]) by menubar.gnome.org (Postfix) with ESMTP id AE4893B0115 for ; Thu, 1 Jun 2006 12:21:33 -0400 (EDT) Received: from birnet.org (213.39.195.111) by webmail.hansenet.de (7.2.059) id 447C276B001342DD; Thu, 1 Jun 2006 18:21:31 +0200 Received: from master.birnet.private (localhost [127.0.0.1]) by birnet.org (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k51GLTmR005587 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 1 Jun 2006 18:21:29 +0200 Received: (from timj@localhost) by master.birnet.private (8.13.4/8.13.4/Submit) id k51GLTBN005586; Thu, 1 Jun 2006 18:21:29 +0200 Date: Thu, 1 Jun 2006 18:21:29 +0200 (CEST) From: Tim Janik X-X-Sender: timj@master.birnet.private To: Matthias Clasen In-Reply-To: Message-ID: References: <20060531200823.GA7846@babi-pangang.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.436 tagged_above=-999 required=2 tests=[AWL=0.163, BAYES_00=-2.599] X-Spam-Score: -2.436 X-Spam-Level: Cc: Gtk+ Developers , Kristian Rietveld Subject: Re: Tooltips progress X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2006 16:21:35 -0000 On Thu, 1 Jun 2006, Matthias Clasen wrote: >> Attached is some sample code using the new API. Opinions, comments, >> suggestions are appreciated. >> > > I don't remember too much of the original proposal, so I'll just go > by what I see in the examples... > > What is the relation between the tooltip-markup and has-tooltip > properties ? setting ::tooltip-markup should automatically set ::has-tooltip=TRUE; as mentioned in the original proposal: http://mail.gnome.org/archives/gtk-devel-list/2006-April/msg00010.html > Is has-tooltip automatically set when setting tooltip-markup ? > Or do you only need to set has-tooltip if you want to connect to > query-tooltip ? the idea behind ::has-tooltip is to reduce the number of required signal emissions to figure a tooltip. e.g. by adding a PRIVATE_GTK_* flag that indicates if the ::query-tooltips() emission is neccessary. maybe it'd helpt to rename that property to ::can-tooltip? > Is the tooltip window available as a property too ? (The example uses > a dedicated setter for it). i don't quite see a need for that. the custom window is only useful if you implement your own ::query-tooltip() handler anyway and there you could simply use the getter. (if you want to argue consistency with other things settable/gettable on widgets though, then yes, you have a point for also exporting it as a property) > The example doesn't show tooltips constructed using the old tooltips > api, but I assume those will continue to work as before, right ? that was the plan, i.e. you'd basically just do: void gtk_tooltips_set_tip (GtkTooltips *tooltips, GtkWidget *widget, const gchar *tip_text, const gchar *tip_private) { g_object_set (widget, "tooltip-markup", tip_text, NULL); } > Matthias --- ciaoTJ From timj@gtk.org Thu Jun 1 12:37:26 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 777F13B0DE5 for ; Thu, 1 Jun 2006 12:37:26 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20777-08 for ; Thu, 1 Jun 2006 12:37:17 -0400 (EDT) Received: from webmail.hansenet.de (mail03.hansenet.de [213.191.73.10]) by menubar.gnome.org (Postfix) with ESMTP id DD7453B0E15 for ; Thu, 1 Jun 2006 12:37:16 -0400 (EDT) Received: from birnet.org (213.39.195.111) by webmail.hansenet.de (7.2.059) id 447C084500128D01; Thu, 1 Jun 2006 18:36:53 +0200 Received: from master.birnet.private (localhost [127.0.0.1]) by birnet.org (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k51Gaj8T006024 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 1 Jun 2006 18:36:45 +0200 Received: (from timj@localhost) by master.birnet.private (8.13.4/8.13.4/Submit) id k51Gaj0d006023; Thu, 1 Jun 2006 18:36:45 +0200 Date: Thu, 1 Jun 2006 18:36:45 +0200 (CEST) From: Tim Janik X-X-Sender: timj@master.birnet.private To: Michael Natterer In-Reply-To: <1149172764.5721.13.camel@localhost> Message-ID: References: <20060531200823.GA7846@babi-pangang.org> <1149172764.5721.13.camel@localhost> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.439 tagged_above=-999 required=2 tests=[AWL=0.160, BAYES_00=-2.599] X-Spam-Score: -2.439 X-Spam-Level: Cc: Gtk+ Developers , Kristian Rietveld Subject: Re: Tooltips progress X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2006 16:37:26 -0000 On Thu, 1 Jun 2006, Michael Natterer wrote: > On Wed, 2006-05-31 at 22:08 +0200, Kristian Rietveld wrote: > >> Currently, we are using the following query-tooltips signal: >> >> gboolean (*query_tooltip) (GtkWidget *widget, >> gint x, >> gint y, >> GtkTooltip *tooltip); >> >> But if a user sets a custom using gtk_widget_set_custom_window(), we don't >> have to pass a GtkTooltip around. So currently I just set the tooltip >> field to NULL, so the user knows he has to use his own custom tooltip >> window (and we assume he has a reference to that). Is this okay or do >> we want to change this? We could also move the _set_custom_window() >> functions into GtkTooltip for example. > > I would very much appreciate if the GtkTooltip object also kept track > of the custom window. IMHO it makes no sense to handle this differently. the widget is meant to do that: void gtk_widget_set_tooltip_window (GtkWidget *widget, GtkWindow *custom_window); GtkWindow* gtk_widget_get_tooltip_window (GtkWidget *widget); for reasons outlined in a previous reply from me to kris. > gtk_tooltip_set_markup() vs. gtk_tooltip_set_window() > > simply feels much better than the asymmetry in > > gtk_tooltip_set_markup() vs. gtk_widget_set_tooltip_window() well, you'd not use GtkTooltip at all if you used gtk_widget_set_tooltip_window() before. in that way, the "asymmetry" simply reflects your usage. > The current approach even limits the new tooltip system's use cases, > since you have to set the custom window *outside* the callback. There > is no way to decide *in* the callback if a standard tooltip is > sufficient, or if a custom window is needed. i don't think it'd be clear that/if the custom window will be available in the GtkTooltip object again upon the next ::query-tooltip() emission. especially since users are not supposed to access GtkTooltip objects/structures in anyway *outside* of ::query-tooltip(), as outlined originally: http://mail.gnome.org/archives/gtk-devel-list/2006-April/msg00010.html also, passing GtkTooltip as NULL is meant to be as a clear indication that the user has to tinker with gtk_widget_get_tooltip_window() instead of the tooltip object. this avoids ambiguities like: static gboolean query_tooltip (GtkWidget *widget, gint x, gint y, GtkTooltip *tooltip) { gtk_tooltip_set_markup (tooltip, "See Me?"); g_object_new (GTK_TYPE_BUTTON, "parent", gtk_widget_get_tooltip_window(), "label", "Can You Click Me?", NULL); gtk_tooltip_set_icon (tooltip, messup_pixbuf); } what's the tooltip code supposed to do here? and yes, the API basically enforces that you decide per widget if an own tooltip window is needed or not. but i don't think that is a strong limitation, we have been discussing usage cases quite some in thise thread and nothing required to defer this decision into the callback (and no existing tooltip code i know of requires this either). so giving the benefits in API (and implementation) this provides, i think it is a reasonable limitation to make. > Another problem is the assymetry in getting the relevant data to the > callback. With markup, the GtkTooltip can be queried for the markup, > if it's a custom window, you have to get it to the callback somehow. Kris just forgot the getter for the custom window on the widget, so signal handler user_data is left alone. > In your example code it's passed as user_data, but user_data is > often not available since it's needed for other things, so you > have to add a "GtkWidget *tooltip_window" to the "other thing". > If "other thing" is e.g. the application toplevel window, which > of the sub-widget's tooltips should it keep? All of them? People > will in many cases end up attaching the tooltip window to the > widget. > > I also fail to see why the "has-tooltip" property has to be > set to TRUE, even tho a tooltip window was set on the widget. > i think this can be come by if we implement: - gtk_widget_set_tooltip_window() should automatically set: GtkWidget::has-tooltip = (custom_window != NULL || GtkWidget::tooltip-markup != ""); - setting GtkWidget::tooltip-markup should automatically set: GtkWidget::has-tooltip = (custom_window != NULL || GtkWidget::tooltip-markup != ""); right? > ciao, > --mitch > --- ciaoTJ From tkomulai@gmail.com Thu Jun 1 15:14:41 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 5A7023B0D70 for ; Thu, 1 Jun 2006 15:14:41 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31172-10 for ; Thu, 1 Jun 2006 15:14:40 -0400 (EDT) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.174]) by menubar.gnome.org (Postfix) with ESMTP id D35083B0CA3 for ; Thu, 1 Jun 2006 15:14:39 -0400 (EDT) Received: by ug-out-1314.google.com with SMTP id o2so222332uge for ; Thu, 01 Jun 2006 12:14:38 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=pkJ9GUF7tBRSDYTFZk62hCunrEDWh/ETW5JoJhlQx7UdB4QeOLJv/qztCngXO4Co/DiXf7ruqlpPxLBRYMp1hjNHoS2y4j0YEr7klSoN2TI6/rPnna1ZG+sfsuFqJaUK0lPq+fzd8NFeO3Vaf+6D8oJI9g3JXpXVTm3KfKENqYU= Received: by 10.78.47.15 with SMTP id u15mr181197huu; Thu, 01 Jun 2006 12:14:38 -0700 (PDT) Received: by 10.78.41.17 with HTTP; Thu, 1 Jun 2006 12:14:38 -0700 (PDT) Message-ID: <68bd3e050606011214i6c36109chff11c7242268b84@mail.gmail.com> Date: Thu, 1 Jun 2006 22:14:38 +0300 From: "Tommi Komulainen" Sender: tkomulai@gmail.com To: gtk-devel-list@gnome.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20060314132538.GA3526@babi-pangang.org> <443B4A8A.8000302@imendio.com> <20060425103017.GA15762@babi-pangang.org> <20060531183045.GA7564@babi-pangang.org> X-Google-Sender-Auth: 6188435c8e783fb2 X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.792 tagged_above=-999 required=2 tests=[AWL=-0.750, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.558, SPF_PASS=-0.001] X-Spam-Score: -1.792 X-Spam-Level: Subject: Re: Callback based tooltips (Re: New tooltips API, continued) X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2006 19:14:41 -0000 On 6/1/06, Tim Janik wrote: > On Wed, 31 May 2006, Kristian Rietveld wrote: > > > On Tue, Apr 25, 2006 at 03:08:12PM +0200, Soeren Sandmann wrote: > >> I once wrote down how tooltips should behave: > > > > I mostly like the behaviour you described below. > > > >> - Tooltips are too intrusive. The text should be smaller, and > > not sure if this has been raised already... > the font size of the tooltips should be exactly as large as the default > font size (module tooltip markup of course) to avoid reducing usability > of the tooltips in contrast to normal text (labels). As long as the font (and other things) are easily themable, the default values are not as important. And as gtk+ doesn't currently have any kind of design for using different font sizes in different contexts, I'd say the default font is a good default. Until someone comes up with a plan that looks at the bigger picture. -- Tommi Komulainen tommi.komulainen@iki.fi From mclasen@redhat.com Thu Jun 1 19:12:39 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id B0B143B0135 for ; Thu, 1 Jun 2006 19:12:39 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12736-06 for ; Thu, 1 Jun 2006 19:12:36 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id 567E43B0061 for ; Thu, 1 Jun 2006 19:12:36 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k51NCZWS017685 for ; Thu, 1 Jun 2006 19:12:35 -0400 Received: from lacrosse.corp.redhat.com (lacrosse.corp.redhat.com [172.16.52.154]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k51NCZpf020363 for ; Thu, 1 Jun 2006 19:12:35 -0400 Received: from [172.16.83.142] (vpn83-142.boston.redhat.com [172.16.83.142]) by lacrosse.corp.redhat.com (8.12.11.20060308/8.11.6) with ESMTP id k51NCXoG026214 for ; Thu, 1 Jun 2006 19:12:33 -0400 From: Matthias Clasen To: gtk-devel-list@gnome.org Content-Type: multipart/mixed; boundary="=-xjDvOKJb0tdB52kmWdgp" Organization: Red Hat Date: Thu, 01 Jun 2006 19:13:59 -0400 Message-Id: <1149203639.27455.9.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.7.2.1 (2.7.2.1-4) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.466 tagged_above=-999 required=2 tests=[AWL=-0.019, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, TW_GT=0.077, TW_XD=0.077] X-Spam-Score: -2.466 X-Spam-Level: Subject: Print preview api X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2006 23:12:39 -0000 --=-xjDvOKJb0tdB52kmWdgp Content-Type: text/plain Content-Transfer-Encoding: 7bit Ok, after a lot of work (mostly by John and Alex), we finally have a proposal for a print preview api that will allow us to use an external viewer by default, but also support internal preview. It consists of the following pieces: 1) GtkPrintOperation gets a new signal gboolean (*preview) (GtkPrintOperation *operation, GtkPrintOperationPreview *preview, GtkPrintContext *context, GtkWindow *parent); This signal is emitted when the user clicks the preview button. It the application does not handle it, the default handler will arrange for the external viewer to be spawned. An application that handles the preview internally should return TRUE from the signal handler. The GtkPrintOperationPreview that is passed to the signal handler lets the application control the preview. 2) The GtkPrintOperationPreview interface has a number of signals: void (*ready) (GtkPrintOperationPreview *preview, GtkPrintContext *context); The ready signal is emitted when pagination is done. The GtkPrintOperation::preview handler should connect to this signal to know when it is safe to start displaying pages. void (*got_page_size) (GtkPrintOperationPreview *preview, GtkPrintContext *context, GtkPageSetup *page_setup); The got-page-size signal is emitted for every rendered page, when the page setup for the page is know. This signal can be used to adjust the cairo context used for rendering the page (e.g. for resizing the preview window). And methods: void gtk_print_operation_preview_render_page (GtkPrintOperationPreview *preview, gint page_nr) Renders the requested page to the cairo context currently set on the print context for the preview. void gtk_print_operation_preview_end_preview (GtkPrintOperationPreview *preview) Must be called to clean up when the preview is finished. 3) A new way of handling the cairo context associated with a GtkPrintContext. A print context is no longer directly associated with a cairo surface. Instead, a cairo context is set with void gtk_print_context_set_cairo_context (GtkPrintContext *context, cairo_t *cr, double dpi_x, double dpi_y); And this can be repeated, typically in a got-page-size handler. The attached patch against current cvs has a very basic preview implementation in print-editor.c that demonstrates this api. Comments appreciated, Matthias --=-xjDvOKJb0tdB52kmWdgp Content-Disposition: attachment; filename=gtk-print-preview-7.diff Content-Type: text/x-patch; name=gtk-print-preview-7.diff; charset=UTF-8 Content-Transfer-Encoding: 7bit Index: gtk/Makefile.am =================================================================== RCS file: /cvs/gnome/gtk+/gtk/Makefile.am,v retrieving revision 1.308 diff -u -p -r1.308 Makefile.am --- gtk/Makefile.am 22 May 2006 17:19:09 -0000 1.308 +++ gtk/Makefile.am 1 Jun 2006 20:34:39 -0000 @@ -4,6 +4,7 @@ SUBDIRS=theme-bits if OS_UNIX SUBDIRS += xdgmime +GTK_PRINT_PREVIEW_COMMAND="evince %f" endif DIST_SUBDIRS=theme-bits xdgmime @@ -25,6 +26,7 @@ INCLUDES = \ -DGTK_HOST=\"$(host)\" \ -DGTK_COMPILATION \ -DGTK_PRINT_BACKENDS=\"$(GTK_PRINT_BACKENDS)\" \ + -DGTK_PRINT_PREVIEW_COMMAND=\"$(GTK_PRINT_PREVIEW_COMMAND)\" \ -I$(top_builddir)/gtk \ -I$(top_srcdir) -I../gdk \ -I$(top_srcdir)/gdk \ @@ -231,6 +233,7 @@ gtk_public_h_sources = \ gtkpreview.h \ gtkprintcontext.h \ gtkprintoperation.h \ + gtkprintoperationpreview.h \ gtkprintsettings.h \ gtkprivate.h \ gtkprogress.h \ @@ -487,6 +490,7 @@ gtk_c_sources = \ gtkpreview.c \ gtkprintcontext.c \ gtkprintoperation.c \ + gtkprintoperationpreview.c \ gtkprintsettings.c \ gtkprintutils.c \ gtkprogress.c \ Index: gtk/gtkmarshalers.list =================================================================== RCS file: /cvs/gnome/gtk+/gtk/gtkmarshalers.list,v retrieving revision 1.67 diff -u -p -r1.67 gtkmarshalers.list --- gtk/gtkmarshalers.list 22 May 2006 17:19:09 -0000 1.67 +++ gtk/gtkmarshalers.list 1 Jun 2006 20:34:39 -0000 @@ -32,6 +32,7 @@ BOOLEAN:OBJECT,INT,INT,UINT BOOLEAN:OBJECT,STRING,STRING,BOXED BOOLEAN:OBJECT,BOXED BOOLEAN:OBJECT,BOXED,BOXED +BOOLEAN:OBJECT,OBJECT,OBJECT BOOLEAN:OBJECT,STRING,STRING BOOLEAN:INT BOOLEAN:INT,INT Index: gtk/gtkprintbackend.c =================================================================== RCS file: /cvs/gnome/gtk+/gtk/gtkprintbackend.c,v retrieving revision 1.7 diff -u -p -r1.7 gtkprintbackend.c --- gtk/gtkprintbackend.c 1 Jun 2006 05:02:56 -0000 1.7 +++ gtk/gtkprintbackend.c 1 Jun 2006 20:34:39 -0000 @@ -200,7 +200,6 @@ _gtk_print_backend_create (const char *b GtkPrintBackendModule *pb_module; GtkPrintBackend *pb; - /* TODO: make module loading code work */ for (l = loaded_backends; l != NULL; l = l->next) { pb_module = l->data; @@ -255,6 +254,11 @@ gtk_print_backend_initialize (void) GTK_PRINT_BACKENDS, GTK_PARAM_READWRITE)); + gtk_settings_install_property (g_param_spec_string ("gtk-print-preview-command", + P_("Default command to run when displaying a print preview"), + P_("Command to run when displaying a print preview"), + GTK_PRINT_PREVIEW_COMMAND, + GTK_PARAM_READWRITE)); initialized = TRUE; } } Index: gtk/gtkprintbackend.h =================================================================== RCS file: /cvs/gnome/gtk+/gtk/gtkprintbackend.h,v retrieving revision 1.8 diff -u -p -r1.8 gtkprintbackend.h --- gtk/gtkprintbackend.h 24 May 2006 10:50:56 -0000 1.8 +++ gtk/gtkprintbackend.h 1 Jun 2006 20:34:39 -0000 @@ -140,6 +140,9 @@ void gtk_print_backend_print_stre GList * gtk_print_backend_load_modules (void); void gtk_print_backend_destroy (GtkPrintBackend *print_backend); +/* Methods private to gtk */ +GtkPrintBackend * _gtk_print_backend_create (const char *backend_name); + /* Backend-only functions for GtkPrintBackend */ void gtk_print_backend_add_printer (GtkPrintBackend *print_backend, Index: gtk/gtkprintcontext.c =================================================================== RCS file: /cvs/gnome/gtk+/gtk/gtkprintcontext.c,v retrieving revision 1.4 diff -u -p -r1.4 gtkprintcontext.c --- gtk/gtkprintcontext.c 31 May 2006 13:38:10 -0000 1.4 +++ gtk/gtkprintcontext.c 1 Jun 2006 20:34:39 -0000 @@ -40,6 +40,9 @@ struct _GtkPrintContext GtkPageSetup *page_setup; PangoFontMap *fontmap; + gdouble surface_dpi_x; + gdouble surface_dpi_y; + gdouble pixels_per_unit_x; gdouble pixels_per_unit_y; }; @@ -60,8 +63,8 @@ gtk_print_context_finalize (GObject *obj if (context->page_setup) g_object_unref (context->page_setup); - cairo_destroy (context->cr); - + if (context->cr) + cairo_destroy (context->cr); G_OBJECT_CLASS (gtk_print_context_parent_class)->finalize (object); } @@ -83,15 +86,31 @@ gtk_print_context_class_init (GtkPrintCo GtkPrintContext * _gtk_print_context_new (GtkPrintOperation *op) { - GtkPrintOperationPrivate *priv = op->priv; GtkPrintContext *context; context = g_object_new (GTK_TYPE_PRINT_CONTEXT, NULL); context->op = op; - context->cr = cairo_create (priv->surface); + context->cr = NULL; + context->fontmap = pango_cairo_font_map_new (); + + return context; +} + +void +gtk_print_context_set_cairo_context (GtkPrintContext *context, + cairo_t *cr, + double dpi_x, + double dpi_y) +{ + if (context->cr) + cairo_destroy (context->cr); + + context->cr = cairo_reference (cr); + context->surface_dpi_x = dpi_x; + context->surface_dpi_y = dpi_y; - switch (priv->unit) + switch (context->op->priv->unit) { default: case GTK_UNIT_PIXEL: @@ -100,34 +119,31 @@ _gtk_print_context_new (GtkPrintOperatio context->pixels_per_unit_y = 1.0; break; case GTK_UNIT_POINTS: - context->pixels_per_unit_x = priv->dpi_x / POINTS_PER_INCH; - context->pixels_per_unit_y = priv->dpi_y / POINTS_PER_INCH; + context->pixels_per_unit_x = dpi_x / POINTS_PER_INCH; + context->pixels_per_unit_y = dpi_y / POINTS_PER_INCH; break; case GTK_UNIT_INCH: - context->pixels_per_unit_x = priv->dpi_x; - context->pixels_per_unit_y = priv->dpi_y; + context->pixels_per_unit_x = dpi_x; + context->pixels_per_unit_y = dpi_y; break; case GTK_UNIT_MM: - context->pixels_per_unit_x = priv->dpi_x / MM_PER_INCH; - context->pixels_per_unit_y = priv->dpi_y / MM_PER_INCH; + context->pixels_per_unit_x = dpi_x / MM_PER_INCH; + context->pixels_per_unit_y = dpi_y / MM_PER_INCH; break; } cairo_scale (context->cr, context->pixels_per_unit_x, context->pixels_per_unit_y); - context->fontmap = pango_cairo_font_map_new (); /* We use the unit-scaled resolution, as we still want fonts given in points to work */ pango_cairo_font_map_set_resolution (PANGO_CAIRO_FONT_MAP (context->fontmap), - priv->dpi_y / context->pixels_per_unit_y); - - return context; + dpi_y / context->pixels_per_unit_y); } + void _gtk_print_context_rotate_according_to_orientation (GtkPrintContext *context) { - GtkPrintOperationPrivate *priv = context->op->priv; cairo_t *cr = context->cr; cairo_matrix_t matrix; GtkPaperSize *paper_size; @@ -136,9 +152,9 @@ _gtk_print_context_rotate_according_to_o paper_size = gtk_page_setup_get_paper_size (context->page_setup); width = gtk_paper_size_get_width (paper_size, GTK_UNIT_INCH); - width = width * priv->dpi_x / context->pixels_per_unit_x; + width = width * context->surface_dpi_x / context->pixels_per_unit_x; height = gtk_paper_size_get_height (paper_size, GTK_UNIT_INCH); - height = height * priv->dpi_y / context->pixels_per_unit_y; + height = height * context->surface_dpi_y / context->pixels_per_unit_y; switch (gtk_page_setup_get_orientation (context->page_setup)) { @@ -188,8 +204,8 @@ _gtk_print_context_translate_into_margin top = gtk_page_setup_get_top_margin (context->page_setup, GTK_UNIT_INCH); cairo_translate (context->cr, - left * priv->dpi_x / context->pixels_per_unit_x, - top * priv->dpi_y / context->pixels_per_unit_y); + left * context->surface_dpi_x / context->pixels_per_unit_x, + top * context->surface_dpi_y / context->pixels_per_unit_y); } void @@ -272,7 +288,7 @@ gtk_print_context_get_width (GtkPrintCon width = gtk_page_setup_get_page_width (context->page_setup, GTK_UNIT_INCH); /* Really dpi_x? What about landscape? what does dpi_x mean in that case? */ - return width * priv->dpi_x / context->pixels_per_unit_x; + return width * context->surface_dpi_x / context->pixels_per_unit_x; } /** @@ -300,8 +316,8 @@ gtk_print_context_get_height (GtkPrintCo else height = gtk_page_setup_get_page_height (context->page_setup, GTK_UNIT_INCH); - /* Really dpi_x? What about landscape? what does dpi_x mean in that case? */ - return height * priv->dpi_y / context->pixels_per_unit_y; + /* Really dpi_y? What about landscape? what does dpi_y mean in that case? */ + return height * context->surface_dpi_y / context->pixels_per_unit_y; } /** @@ -320,7 +336,7 @@ gtk_print_context_get_dpi_x (GtkPrintCon { g_return_val_if_fail (GTK_IS_PRINT_CONTEXT (context), 0); - return context->op->priv->dpi_x; + return context->surface_dpi_x; } /** @@ -339,7 +355,7 @@ gtk_print_context_get_dpi_y (GtkPrintCon { g_return_val_if_fail (GTK_IS_PRINT_CONTEXT (context), 0); - return context->op->priv->dpi_y; + return context->surface_dpi_y; } /** @@ -376,10 +392,16 @@ PangoContext * gtk_print_context_create_pango_context (GtkPrintContext *context) { PangoContext *pango_context; + cairo_font_options_t *options; g_return_val_if_fail (GTK_IS_PRINT_CONTEXT (context), NULL); pango_context = pango_cairo_font_map_create_context (PANGO_CAIRO_FONT_MAP (context->fontmap)); + + options = cairo_font_options_create (); + cairo_font_options_set_hint_metrics (options, CAIRO_HINT_METRICS_OFF); + pango_cairo_context_set_font_options (pango_context, options); + cairo_font_options_destroy (options); return pango_context; } Index: gtk/gtkprintcontext.h =================================================================== RCS file: /cvs/gnome/gtk+/gtk/gtkprintcontext.h,v retrieving revision 1.3 diff -u -p -r1.3 gtkprintcontext.h --- gtk/gtkprintcontext.h 31 May 2006 13:38:10 -0000 1.3 +++ gtk/gtkprintcontext.h 1 Jun 2006 20:34:39 -0000 @@ -51,6 +51,11 @@ PangoFontMap *gtk_print_context_get_pang PangoContext *gtk_print_context_create_pango_context (GtkPrintContext *context); PangoLayout *gtk_print_context_create_pango_layout (GtkPrintContext *context); +/* Needed for preview implementations */ +void gtk_print_context_set_cairo_context (GtkPrintContext *context, + cairo_t *cr, + double dpi_x, + double dpi_y); G_END_DECLS Index: gtk/gtkprintjob.c =================================================================== RCS file: /cvs/gnome/gtk+/gtk/gtkprintjob.c,v retrieving revision 1.8 diff -u -p -r1.8 gtkprintjob.c --- gtk/gtkprintjob.c 16 May 2006 16:13:48 -0000 1.8 +++ gtk/gtkprintjob.c 1 Jun 2006 20:34:39 -0000 @@ -212,14 +212,14 @@ gtk_print_job_constructor (GType job = GTK_PRINT_JOB (object); priv = job->priv; - g_assert (priv->printer_set && - priv->settings_set && + g_assert (priv->settings_set && priv->page_setup_set); - - _gtk_printer_prepare_for_print (priv->printer, - job, - priv->settings, - priv->page_setup); + + if (priv->printer) + _gtk_printer_prepare_for_print (priv->printer, + job, + priv->settings, + priv->page_setup); return object; } @@ -545,8 +545,12 @@ gtk_print_job_set_property (GObject case GTK_PRINT_JOB_PROP_PRINTER: priv->printer = GTK_PRINTER (g_value_dup_object (value)); - priv->printer_set = TRUE; - priv->backend = g_object_ref (gtk_printer_get_backend (priv->printer)); + + if (priv->printer != NULL) + { + priv->printer_set = TRUE; + priv->backend = g_object_ref (gtk_printer_get_backend (priv->printer)); + } break; case GTK_PRINT_JOB_PROP_PAGE_SETUP: Index: gtk/gtkprintoperation-private.h =================================================================== RCS file: /cvs/gnome/gtk+/gtk/gtkprintoperation-private.h,v retrieving revision 1.11 diff -u -p -r1.11 gtkprintoperation-private.h --- gtk/gtkprintoperation-private.h 1 Jun 2006 12:38:07 -0000 1.11 +++ gtk/gtkprintoperation-private.h 1 Jun 2006 20:34:39 -0000 @@ -46,9 +46,11 @@ struct _GtkPrintOperationPrivate guint print_pages_idle_id; guint show_progress_timeout_id; + GtkPrintContext *print_context; + /* Data for the print job: */ - cairo_surface_t *surface; - gdouble dpi_x, dpi_y; + /* cairo_surface_t *surface; */ + /* gdouble dpi_x, dpi_y; */ GtkPrintPages print_pages; GtkPageRange *page_ranges; @@ -84,11 +86,23 @@ GtkPrintOperationResult _gtk_print_opera GError **error); typedef void (* GtkPrintOperationPrintFunc) (GtkPrintOperation *op, - GtkWindow *parent); + GtkWindow *parent, + gboolean is_preview); void _gtk_print_operation_platform_backend_run_dialog_async (GtkPrintOperation *op, GtkWindow *parent, GtkPrintOperationPrintFunc print_cb); + +void _gtk_print_operation_platform_backend_launch_preview (GtkPrintOperation *op, + GtkWindow *parent, + const char *filename); + +cairo_surface_t *_gtk_print_operation_platform_backend_create_preview_surface (GtkPrintOperation *operation, + gdouble width, + gdouble heigh, + gdouble *dpi_x, + gdouble *dpi_y, + const gchar *target); void _gtk_print_operation_set_status (GtkPrintOperation *op, GtkPrintStatus status, Index: gtk/gtkprintoperation-unix.c =================================================================== RCS file: /cvs/gnome/gtk+/gtk/gtkprintoperation-unix.c,v retrieving revision 1.19 diff -u -p -r1.19 gtkprintoperation-unix.c --- gtk/gtkprintoperation-unix.c 1 Jun 2006 12:38:07 -0000 1.19 +++ gtk/gtkprintoperation-unix.c 1 Jun 2006 20:34:39 -0000 @@ -25,6 +25,9 @@ #include #include #include +#include +#include +#include #include "gtkprintoperation-private.h" #include "gtkmarshal.h" @@ -41,13 +44,17 @@ #include "gtkalias.h" #include "gtkintl.h" - typedef struct { - GtkPrintJob *job; /* the job we are sending to the printer */ - gulong job_status_changed_tag; GtkWindow *parent; /* just in case we need to throw error dialogs */ GMainLoop *loop; gboolean data_sent; + + /* Real printing (not preview: */ + GtkPrintJob *job; /* the job we are sending to the printer */ + cairo_surface_t *surface; + gulong job_status_changed_tag; + + } GtkPrintOperationUnix; typedef struct _PrinterFinder PrinterFinder; @@ -62,21 +69,24 @@ unix_start_page (GtkPrintOperation *op, GtkPrintContext *print_context, GtkPageSetup *page_setup) { + GtkPrintOperationUnix *op_unix; GtkPaperSize *paper_size; cairo_surface_type_t type; double w, h; + op_unix = op->priv->platform_data; + paper_size = gtk_page_setup_get_paper_size (page_setup); w = gtk_paper_size_get_width (paper_size, GTK_UNIT_POINTS); h = gtk_paper_size_get_height (paper_size, GTK_UNIT_POINTS); - type = cairo_surface_get_type (op->priv->surface); + type = cairo_surface_get_type (op_unix->surface); if (type == CAIRO_SURFACE_TYPE_PS) - cairo_ps_surface_set_size (op->priv->surface, w, h); + cairo_ps_surface_set_size (op_unix->surface, w, h); else if (type == CAIRO_SURFACE_TYPE_PDF) - cairo_pdf_surface_set_size (op->priv->surface, w, h); + cairo_pdf_surface_set_size (op_unix->surface, w, h); } static void @@ -102,6 +112,112 @@ op_unix_free (GtkPrintOperationUnix *op_ g_free (op_unix); } +static char * +shell_command_substitute_file (const gchar *cmd, + const gchar *filename) +{ + const char *inptr, *start; + char *result; + GString *final; + + g_return_val_if_fail (cmd != NULL, NULL); + g_return_val_if_fail (filename != NULL, NULL); + + result = NULL; + final = g_string_new (NULL); + + start = inptr = cmd; + + while ((inptr = strchr (inptr, '%')) != NULL) + { + g_string_append_len (final, start, inptr - start); + inptr++; + switch (*inptr) + { + case 'f': + g_string_append (final, filename ? filename : ""); + break; + + case '%': + g_string_append_c (final, '%'); + break; + + default: + g_string_append_c (final, '%'); + if (*inptr) + g_string_append_c (final, *inptr); + break; + } + if (*inptr) + inptr++; + start = inptr; + } + g_string_append (final, start); + + result = final->str; + + g_string_free (final, FALSE); + + return result; +} + +void +_gtk_print_operation_platform_backend_launch_preview (GtkPrintOperation *op, + GtkWindow *parent, + const char *filename) +{ + int argc; + gchar **argv; + gchar *cmd; + gchar *preview_cmd; + GtkSettings *settings; + gchar *quoted_filename; + GdkScreen *screen; + GError *error = NULL; + + settings = gtk_settings_get_default (); + g_object_get (settings, "gtk-print-preview-command", &preview_cmd, NULL); + + quoted_filename = g_shell_quote (filename); + cmd = shell_command_substitute_file (preview_cmd, quoted_filename); + g_shell_parse_argv (cmd, &argc, &argv, &error); + + if (error !=NULL) + goto out; + + if (parent) + screen = gtk_window_get_screen (parent); + else + screen = gdk_screen_get_default (); + + gdk_spawn_on_screen (screen, NULL, argv, NULL, G_SPAWN_SEARCH_PATH, NULL, NULL, NULL, &error); + + out: + if (error != NULL) + { + GtkWidget *edialog; + edialog = gtk_message_dialog_new (parent, + GTK_DIALOG_DESTROY_WITH_PARENT, + GTK_MESSAGE_ERROR, + GTK_BUTTONS_CLOSE, + _("Error launching preview") /* FIXME better text */); + gtk_message_dialog_format_secondary_text (GTK_MESSAGE_DIALOG (edialog), + "%s", error->message); + gtk_window_set_modal (GTK_WINDOW (edialog), TRUE); + g_signal_connect (edialog, "response", + G_CALLBACK (gtk_widget_destroy), NULL); + + gtk_window_present (GTK_WINDOW (edialog)); + + g_error_free (error); + } + + g_free (cmd); + g_free (quoted_filename); + g_free (preview_cmd); + g_strfreev (argv); +} + static void unix_finish_send (GtkPrintJob *job, void *user_data, @@ -129,6 +245,7 @@ unix_finish_send (GtkPrintJob *job, } op_unix->data_sent = TRUE; + if (op_unix->loop) g_main_loop_quit (op_unix->loop); } @@ -140,6 +257,8 @@ unix_end_run (GtkPrintOperation *op, { GtkPrintOperationUnix *op_unix = op->priv->platform_data; + cairo_surface_finish (op_unix->surface); + if (cancelled) return; @@ -147,10 +266,11 @@ unix_end_run (GtkPrintOperation *op, op_unix->loop = g_main_loop_new (NULL, FALSE); /* TODO: Check for error */ - gtk_print_job_send (op_unix->job, - unix_finish_send, - op_unix, NULL, - NULL); + if (op_unix->job != NULL) + gtk_print_job_send (op_unix->job, + unix_finish_send, + op_unix, NULL, + NULL); if (wait) { @@ -253,64 +373,66 @@ finish_print (PrintResponseData *rdata, { GtkPrintOperation *op = rdata->op; GtkPrintOperationPrivate *priv = op->priv; + gboolean is_preview; - priv->start_page = unix_start_page; - priv->end_page = unix_end_page; - priv->end_run = unix_end_run; + g_print ("finish_print\n"); + + is_preview = rdata->result == GTK_PRINT_OPERATION_RESULT_PREVIEW; if (rdata->do_print) { - GtkPrintOperationUnix *op_unix; - gtk_print_operation_set_print_settings (op, settings); - - op_unix = g_new0 (GtkPrintOperationUnix, 1); - op_unix->job = gtk_print_job_new (priv->job_name, - printer, - settings, - page_setup); + op->priv->print_context = _gtk_print_context_new (op); - gtk_print_job_set_track_print_status (op_unix->job, priv->track_print_status); - - rdata->op->priv->surface = gtk_print_job_get_surface (op_unix->job, rdata->error); - if (op->priv->surface == NULL) + if (!is_preview) { - rdata->do_print = FALSE; - op_unix_free (op_unix); - rdata->result = GTK_PRINT_OPERATION_RESULT_ERROR; - goto out; - } - - _gtk_print_operation_set_status (op, gtk_print_job_get_status (op_unix->job), NULL); - op_unix->job_status_changed_tag = - g_signal_connect (op_unix->job, "status-changed", - G_CALLBACK (job_status_changed_cb), op); - - op_unix->parent = rdata->parent; - - priv->dpi_x = 72; - priv->dpi_y = 72; - - priv->platform_data = op_unix; - priv->free_platform_data = (GDestroyNotify) op_unix_free; - - priv->print_pages = op_unix->job->print_pages; - priv->page_ranges = op_unix->job->page_ranges; - priv->num_page_ranges = op_unix->job->num_page_ranges; - - priv->manual_num_copies = op_unix->job->num_copies; - priv->manual_collation = op_unix->job->collate; - priv->manual_reverse = op_unix->job->reverse; - priv->manual_page_set = op_unix->job->page_set; - priv->manual_scale = op_unix->job->scale; - priv->manual_orientation = op_unix->job->rotate_to_orientation; + GtkPrintOperationUnix *op_unix; + cairo_t *cr; + + op_unix = g_new0 (GtkPrintOperationUnix, 1); + priv->platform_data = op_unix; + priv->free_platform_data = (GDestroyNotify) op_unix_free; + op_unix->parent = rdata->parent; + + priv->start_page = unix_start_page; + priv->end_page = unix_end_page; + priv->end_run = unix_end_run; + + op_unix->job = gtk_print_job_new (priv->job_name, + printer, + settings, + page_setup); + gtk_print_job_set_track_print_status (op_unix->job, priv->track_print_status); + /* TODO: handle error */ + op_unix->surface = gtk_print_job_get_surface (op_unix->job, rdata->error); + cr = cairo_create (op_unix->surface); + gtk_print_context_set_cairo_context (op->priv->print_context, + cr, 72, 72); + cairo_destroy (cr); + + _gtk_print_operation_set_status (op, gtk_print_job_get_status (op_unix->job), NULL); + + op_unix->job_status_changed_tag = + g_signal_connect (op_unix->job, "status-changed", + G_CALLBACK (job_status_changed_cb), op); + + priv->print_pages = op_unix->job->print_pages; + priv->page_ranges = op_unix->job->page_ranges; + priv->num_page_ranges = op_unix->job->num_page_ranges; + + priv->manual_num_copies = op_unix->job->num_copies; + priv->manual_collation = op_unix->job->collate; + priv->manual_reverse = op_unix->job->reverse; + priv->manual_page_set = op_unix->job->page_set; + priv->manual_scale = op_unix->job->scale; + priv->manual_orientation = op_unix->job->rotate_to_orientation; + } } - - out: + if (rdata->print_cb) { if (rdata->do_print) - rdata->print_cb (op, rdata->parent); + rdata->print_cb (op, rdata->parent, is_preview); else _gtk_print_operation_set_status (op, GTK_PRINT_STATUS_FINISHED_ABORTED, NULL); } @@ -319,7 +441,7 @@ finish_print (PrintResponseData *rdata, rdata->destroy (rdata); } -static void +static void handle_print_response (GtkWidget *dialog, gint response, gpointer data) @@ -330,6 +452,8 @@ handle_print_response (GtkWidget *dialog GtkPageSetup *page_setup = NULL; GtkPrinter *printer = NULL; + g_print ("handle_print_response\n"); + if (response == GTK_RESPONSE_OK) { rdata->result = GTK_PRINT_OPERATION_RESULT_APPLY; @@ -345,14 +469,24 @@ handle_print_response (GtkWidget *dialog g_signal_emit_by_name (rdata->op, "custom-widget-apply", rdata->op->priv->custom_widget); } + else if (response == GTK_RESPONSE_APPLY) + { + /* print preview */ + rdata->result = GTK_PRINT_OPERATION_RESULT_PREVIEW; + rdata->do_print = TRUE; + settings = gtk_print_unix_dialog_get_settings (GTK_PRINT_UNIX_DIALOG (pd)); + page_setup = gtk_print_unix_dialog_get_page_setup (GTK_PRINT_UNIX_DIALOG (pd)); + } + out: finish_print (rdata, printer, page_setup, settings); if (settings) g_object_unref (settings); - + gtk_widget_destroy (GTK_WIDGET (pd)); + } @@ -436,6 +570,19 @@ _gtk_print_operation_platform_backend_ru } } +cairo_surface_t * +_gtk_print_operation_platform_backend_create_preview_surface (GtkPrintOperation *op, + gdouble width, + gdouble height, + gdouble *dpi_x, + gdouble *dpi_y, + const gchar *target) +{ + g_print ("pdf surface size: %f x %f\n", width, height); + *dpi_x = *dpi_y = 72; + return cairo_pdf_surface_create (target, width, height); +} + GtkPrintOperationResult _gtk_print_operation_platform_backend_run_dialog (GtkPrintOperation *op, GtkWindow *parent, @@ -459,6 +606,7 @@ _gtk_print_operation_platform_backend_ru if (op->priv->show_dialog) { pd = get_print_dialog (op, parent); + response = gtk_dialog_run (GTK_DIALOG (pd)); handle_print_response (pd, response, &rdata); } Index: gtk/gtkprintoperation-win32.c =================================================================== RCS file: /cvs/gnome/gtk+/gtk/gtkprintoperation-win32.c,v retrieving revision 1.9 diff -u -p -r1.9 gtkprintoperation-win32.c --- gtk/gtkprintoperation-win32.c 23 May 2006 16:30:45 -0000 1.9 +++ gtk/gtkprintoperation-win32.c 1 Jun 2006 20:34:39 -0000 @@ -492,6 +492,7 @@ win32_end_run (GtkPrintOperation *op, GlobalFree(op_win32->devmode); GlobalFree(op_win32->devnames); + cairo_surface_finish (op->priv->surface); cairo_surface_destroy (op->priv->surface); op->priv->surface = NULL; Index: gtk/gtkprintoperation.c =================================================================== RCS file: /cvs/gnome/gtk+/gtk/gtkprintoperation.c,v retrieving revision 1.24 diff -u -p -r1.24 gtkprintoperation.c --- gtk/gtkprintoperation.c 1 Jun 2006 12:38:07 -0000 1.24 +++ gtk/gtkprintoperation.c 1 Jun 2006 20:34:39 -0000 @@ -19,6 +19,10 @@ */ #include "config.h" + +#include +#include + #include #include "gtkprintoperation-private.h" #include "gtkmarshalers.h" @@ -41,6 +45,7 @@ enum { STATUS_CHANGED, CREATE_CUSTOM_WIDGET, CUSTOM_WIDGET_APPLY, + PREVIEW, LAST_SIGNAL }; @@ -65,7 +70,15 @@ enum { static guint signals[LAST_SIGNAL] = { 0 }; static int job_nr = 0; -G_DEFINE_TYPE (GtkPrintOperation, gtk_print_operation, G_TYPE_OBJECT) +static void preview_iface_init (GtkPrintOperationPreviewIface *iface); +static GtkPageSetup *create_page_setup (GtkPrintOperation *op); +static void common_render_page (GtkPrintOperation *op, + gint page_nr); + + +G_DEFINE_TYPE_WITH_CODE (GtkPrintOperation, gtk_print_operation, G_TYPE_OBJECT, + G_IMPLEMENT_INTERFACE (GTK_TYPE_PRINT_OPERATION_PREVIEW, + preview_iface_init)) /** * gtk_print_error_quark: @@ -146,6 +159,60 @@ gtk_print_operation_init (GtkPrintOperat } static void +preview_iface_render_page (GtkPrintOperationPreview *preview, + gint page_nr) +{ + GtkPrintOperation *op; + + op = GTK_PRINT_OPERATION (preview); + common_render_page (op, page_nr); +} + +static void +preview_iface_end_preview (GtkPrintOperationPreview *preview) +{ + GtkPrintOperation *op; + + op = GTK_PRINT_OPERATION (preview); + + g_signal_emit (op, signals[END_PRINT], 0, op->priv->print_context); + + if (op->priv->rloop) + g_main_loop_quit (op->priv->rloop); + + op->priv->end_run (op, op->priv->is_sync, TRUE); +} + +static void +preview_iface_init (GtkPrintOperationPreviewIface *iface) +{ + iface->render_page = preview_iface_render_page; + iface->end_preview = preview_iface_end_preview; +} + +static void +preview_start_page (GtkPrintOperation *op, + GtkPrintContext *print_context, + GtkPageSetup *page_setup) +{ + g_signal_emit_by_name (op, "got-page-size",print_context, page_setup); +} + +static void +preview_end_page (GtkPrintOperation *op, + GtkPrintContext *print_context) +{ +} + +static void +preview_end_run (GtkPrintOperation *op, + gboolean wait, + gboolean cancelled) +{ +} + + +static void gtk_print_operation_set_property (GObject *object, guint prop_id, const GValue *value, @@ -256,6 +323,158 @@ gtk_print_operation_get_property (GObjec } } +typedef struct +{ + GtkPrintOperationPreview *preview; + GtkPrintContext *print_context; + GtkWindow *parent; + cairo_surface_t *surface; + gchar *filename; + guint page_nr; + gboolean wait; +} PreviewOp; + +static void +preview_print_idle_done (gpointer data) +{ + GtkPrintOperation *op; + PreviewOp *pop = (PreviewOp *) data; + + op = GTK_PRINT_OPERATION (pop->preview); + + _gtk_print_operation_platform_backend_launch_preview (op, + pop->parent, + pop->filename); + + g_free (pop->filename); + cairo_surface_finish (pop->surface); + cairo_surface_destroy (pop->surface); + + gtk_print_operation_preview_end_preview (pop->preview); + g_free (pop); +} + +static gboolean +preview_print_idle (gpointer data) +{ + PreviewOp *pop; + GtkPrintOperation *op; + gboolean retval = TRUE; + cairo_t *cr; + + GDK_THREADS_ENTER (); + + pop = (PreviewOp *) data; + op = GTK_PRINT_OPERATION (pop->preview); + + gtk_print_operation_preview_render_page (pop->preview, pop->page_nr); + + cr = gtk_print_context_get_cairo_context (pop->print_context); + cairo_show_page (cr); + + /* TODO: print out sheets not pages and follow ranges */ + pop->page_nr++; + if (op->priv->nr_of_pages <= pop->page_nr) + retval = FALSE; + + GDK_THREADS_LEAVE (); + + return retval; +} + +static void +preview_got_page_size (GtkPrintOperationPreview *preview, + GtkPrintContext *context, + GtkPageSetup *page_setup, + PreviewOp *pop) +{ + GtkPrintOperation *op = GTK_PRINT_OPERATION (preview); + GtkPaperSize *paper_size; + double w, h; + + paper_size = gtk_page_setup_get_paper_size (page_setup); + + w = gtk_paper_size_get_width (paper_size, GTK_UNIT_POINTS); + h = gtk_paper_size_get_height (paper_size, GTK_UNIT_POINTS); + + /* TODO: don't hardcode pdf */ + cairo_pdf_surface_set_size (pop->surface, w, h); +} + +static void +preview_ready (GtkPrintOperationPreview *preview, + GtkPrintContext *context, + PreviewOp *pop) +{ + + pop->page_nr = 0; + pop->print_context = context; + + g_idle_add_full (G_PRIORITY_DEFAULT_IDLE, + preview_print_idle, + pop, + preview_print_idle_done); + +} + +/** + * gtk_print_operation_preview_handler: + * + * Default handler for preview operations + **/ +static gboolean +gtk_print_operation_preview_handler (GtkPrintOperation *op, + GtkPrintOperationPreview *preview, + GtkPrintContext *context, + GtkWindow *parent) +{ + gdouble width, height, dpi_x, dpi_y; + gchar *tmp_dir; + gchar *dir_template; + gchar *preview_filename; + PreviewOp *pop; + GtkPrintSettings *settings; + cairo_t *cr; + + dir_template = g_build_filename (g_get_tmp_dir (), "print-preview-XXXXXX", NULL); + + /* use temp dirs because apps like evince need to have extentions + to determine the mine type */ + tmp_dir = mkdtemp(dir_template); + + preview_filename = g_build_filename (tmp_dir, + "Print Preview.pdf", + NULL); + + g_free (dir_template); + + pop = g_new0 (PreviewOp, 1); + pop->filename = preview_filename; + pop->preview = preview; + pop->parent = parent; + + settings = op->priv->print_settings; + + width = gtk_print_settings_get_paper_width (settings, GTK_UNIT_POINTS); + height = gtk_print_settings_get_paper_height (settings, GTK_UNIT_POINTS); + + pop->surface = + _gtk_print_operation_platform_backend_create_preview_surface (op, + width, height, + &dpi_x, &dpi_y, + pop->filename); + + cr = cairo_create (pop->surface); + gtk_print_context_set_cairo_context (op->priv->print_context, cr, + dpi_x, dpi_y); + cairo_destroy (cr); + + g_signal_connect (preview, "ready", (GCallback) preview_ready, pop); + g_signal_connect (preview, "got-page-size", (GCallback) preview_got_page_size, pop); + + return TRUE; +} + static GtkWidget * gtk_print_operation_create_custom_widget (GtkPrintOperation *operation) { @@ -287,7 +506,8 @@ gtk_print_operation_class_init (GtkPrint gobject_class->set_property = gtk_print_operation_set_property; gobject_class->get_property = gtk_print_operation_get_property; gobject_class->finalize = gtk_print_operation_finalize; - + + class->preview = gtk_print_operation_preview_handler; class->create_custom_widget = gtk_print_operation_create_custom_widget; g_type_class_add_private (gobject_class, sizeof (GtkPrintOperationPrivate)); @@ -530,6 +750,33 @@ gtk_print_operation_class_init (GtkPrint g_cclosure_marshal_VOID__OBJECT, G_TYPE_NONE, 1, GTK_TYPE_WIDGET); + /** + * GtkPrintOperation::preview: + * @operation: the #GtkPrintOperation on which the signal was emitted + * @preview: the #GtkPrintPreviewOperation for the current operation + * @context: the #GtkPrintContext that will be used + * @parent: the #GtkWindow to use as window parent, or NULL + * + * Gets emitted when a preview is requested from the native dialog. + * If you handle this you must set the cairo_context on the printing context. + * + * Returns: #TRUE if the listener wants to take over control of the preview + * + * Since: 2.10 + */ + signals[PREVIEW] = + g_signal_new (I_("preview"), + G_TYPE_FROM_CLASS (gobject_class), + G_SIGNAL_RUN_LAST, + G_STRUCT_OFFSET (GtkPrintOperationClass, preview), + _gtk_boolean_handled_accumulator, NULL, + _gtk_marshal_BOOLEAN__OBJECT_OBJECT_OBJECT, + G_TYPE_BOOLEAN, 3, + GTK_TYPE_PRINT_OPERATION_PREVIEW, + GTK_TYPE_PRINT_CONTEXT, + GTK_TYPE_WINDOW); + + /** * GtkPrintOperation:default-page-setup: * @@ -1436,6 +1683,7 @@ pdf_start_page (GtkPrintOperation *op, GtkPageSetup *page_setup) { GtkPaperSize *paper_size; + cairo_surface_t *surface = op->priv->platform_data; double w, h; paper_size = gtk_page_setup_get_paper_size (page_setup); @@ -1443,7 +1691,7 @@ pdf_start_page (GtkPrintOperation *op, w = gtk_paper_size_get_width (paper_size, GTK_UNIT_POINTS); h = gtk_paper_size_get_height (paper_size, GTK_UNIT_POINTS); - cairo_pdf_surface_set_size (op->priv->surface, w, h); + cairo_pdf_surface_set_size (surface, w, h); } static void @@ -1462,9 +1710,10 @@ pdf_end_run (GtkPrintOperation *op, gboolean cancelled) { GtkPrintOperationPrivate *priv = op->priv; + cairo_surface_t *surface = priv->platform_data; - cairo_surface_destroy (priv->surface); - priv->surface = NULL; + cairo_surface_finish (surface); + cairo_surface_destroy (surface); } static GtkPrintOperationResult @@ -1475,6 +1724,8 @@ run_pdf (GtkPrintOperation *op, { GtkPrintOperationPrivate *priv = op->priv; GtkPageSetup *page_setup; + cairo_surface_t *surface; + cairo_t *cr; double width, height; /* This will be overwritten later by the non-default size, but we need to pass some size: */ @@ -1484,13 +1735,19 @@ run_pdf (GtkPrintOperation *op, height = gtk_page_setup_get_paper_height (page_setup, GTK_UNIT_POINTS); g_object_unref (page_setup); - priv->surface = cairo_pdf_surface_create (priv->pdf_target, + surface = cairo_pdf_surface_create (priv->pdf_target, width, height); - cairo_pdf_surface_set_dpi (priv->surface, 300, 300); - - priv->dpi_x = 72; - priv->dpi_y = 72; + cairo_pdf_surface_set_dpi (surface, 300, 300); + + priv->platform_data = surface; + priv->free_platform_data = (GDestroyNotify) cairo_surface_destroy; + cr = cairo_create (surface); + gtk_print_context_set_cairo_context (op->priv->print_context, + cr, 72, 72); + cairo_destroy (cr); + + priv->print_pages = GTK_PRINT_PAGES_ALL; priv->page_ranges = NULL; priv->num_page_ranges = 0; @@ -1524,10 +1781,11 @@ typedef struct gint page, start, end, inc; - GtkPageSetup *initial_page_setup; - GtkPrintContext *print_context; + gboolean initialized; GtkWidget *progress; + + gboolean is_preview; } PrintPagesData; static void @@ -1599,12 +1857,9 @@ print_pages_idle_done (gpointer user_dat if (data->progress) gtk_widget_destroy (data->progress); - g_object_unref (data->print_context); - g_object_unref (data->initial_page_setup); - g_object_unref (data->op); - if (priv->rloop) + if (priv->rloop && !data->is_preview) g_main_loop_quit (priv->rloop); g_free (data); @@ -1640,15 +1895,62 @@ update_progress (PrintPagesData *data) } } +static void +common_render_page (GtkPrintOperation *op, + gint page_nr) +{ + GtkPrintOperationPrivate *priv = op->priv; + GtkPageSetup *page_setup; + GtkPrintContext *print_context; + cairo_t *cr; + + print_context = priv->print_context; + + page_setup = create_page_setup (op); + + g_signal_emit (op, signals[REQUEST_PAGE_SETUP], 0, + print_context, page_nr, page_setup); + + _gtk_print_context_set_page_setup (print_context, page_setup); + + /* TODO: override for preview */ + priv->start_page (op, print_context, page_setup); + + cr = gtk_print_context_get_cairo_context (print_context); + + cairo_save (cr); + if (priv->manual_scale != 1.0) + cairo_scale (cr, + priv->manual_scale, + priv->manual_scale); + + if (priv->manual_orientation) + _gtk_print_context_rotate_according_to_orientation (print_context); + + if (!priv->use_full_page) + _gtk_print_context_translate_into_margin (print_context); + + g_signal_emit (op, signals[DRAW_PAGE], 0, + print_context, page_nr); + + /* TODO: override for preview */ + priv->end_page (op, print_context); + + cairo_restore (cr); + + g_object_unref (page_setup); +} + static gboolean print_pages_idle (gpointer user_data) { PrintPagesData *data; GtkPrintOperationPrivate *priv; GtkPageSetup *page_setup; - cairo_t *cr; gboolean done = FALSE; + g_print ("print_pages_idle\n"); + GDK_THREADS_ENTER (); data = (PrintPagesData*)user_data; @@ -1656,15 +1958,15 @@ print_pages_idle (gpointer user_data) if (priv->status == GTK_PRINT_STATUS_PREPARING) { - if (!data->print_context) + if (!data->initialized) { - data->print_context = _gtk_print_context_new (data->op); - data->initial_page_setup = create_page_setup (data->op); - - _gtk_print_context_set_page_setup (data->print_context, - data->initial_page_setup); + data->initialized = TRUE; + page_setup = create_page_setup (data->op); + _gtk_print_context_set_page_setup (priv->print_context, + page_setup); + g_object_unref (page_setup); - g_signal_emit (data->op, signals[BEGIN_PRINT], 0, data->print_context); + g_signal_emit (data->op, signals[BEGIN_PRINT], 0, priv->print_context); if (priv->manual_collation) { @@ -1684,7 +1986,7 @@ print_pages_idle (gpointer user_data) { gboolean paginated = FALSE; - g_signal_emit (data->op, signals[PAGINATE], 0, data->print_context, &paginated); + g_signal_emit (data->op, signals[PAGINATE], 0, priv->print_context, &paginated); if (!paginated) goto out; } @@ -1751,36 +2053,18 @@ print_pages_idle (gpointer user_data) goto out; } } + + if (data->is_preview) + { + done = TRUE; - page_setup = gtk_page_setup_copy (data->initial_page_setup); - g_signal_emit (data->op, signals[REQUEST_PAGE_SETUP], 0, - data->print_context, data->page, page_setup); - - _gtk_print_context_set_page_setup (data->print_context, page_setup); - priv->start_page (data->op, data->print_context, page_setup); - - cr = gtk_print_context_get_cairo_context (data->print_context); - - cairo_save (cr); - if (priv->manual_scale != 1.0) - cairo_scale (cr, - priv->manual_scale, - priv->manual_scale); - - if (priv->manual_orientation) - _gtk_print_context_rotate_according_to_orientation (data->print_context); - - if (!priv->use_full_page) - _gtk_print_context_translate_into_margin (data->print_context); - - g_signal_emit (data->op, signals[DRAW_PAGE], 0, - data->print_context, data->page); - - priv->end_page (data->op, data->print_context); - - cairo_restore (cr); - - g_object_unref (page_setup); + g_object_ref (data->op); + + g_signal_emit_by_name (data->op, "ready", priv->print_context); + goto out; + } + + common_render_page (data->op, data->page); out: @@ -1791,11 +2075,9 @@ print_pages_idle (gpointer user_data) done = TRUE; } - if (done) + if (done && !data->is_preview) { - g_signal_emit (data->op, signals[END_PRINT], 0, data->print_context); - - cairo_surface_finish (priv->surface); + g_signal_emit (data->op, signals[END_PRINT], 0, priv->print_context); priv->end_run (data->op, priv->is_sync, priv->cancelled); } @@ -1833,15 +2115,19 @@ show_progress_timeout (PrintPagesData *d static void print_pages (GtkPrintOperation *op, - GtkWindow *parent) + GtkWindow *parent, + gboolean is_preview) { GtkPrintOperationPrivate *priv = op->priv; PrintPagesData *data; - + + g_print ("print_pages\n"); + _gtk_print_operation_set_status (op, GTK_PRINT_STATUS_PREPARING, NULL); data = g_new0 (PrintPagesData, 1); data->op = g_object_ref (op); + data->is_preview = is_preview; if (priv->show_progress) { @@ -1862,6 +2148,37 @@ print_pages (GtkPrintOperation *op, data->progress = progress; } + if (is_preview) + { + gboolean handled; + + g_signal_emit_by_name (op, "preview", + GTK_PRINT_OPERATION_PREVIEW (op), + op->priv->print_context, + parent, + &handled); + + if (!handled || + gtk_print_context_get_cairo_context (priv->print_context) == NULL) { + /* TODO: handle error */ + } + + priv->start_page = preview_start_page; + priv->end_page = preview_end_page; + priv->end_run = preview_end_run; + + /* TODO: Do we really need to set these? */ + priv->print_pages = GTK_PRINT_PAGES_ALL; + priv->page_ranges = NULL; + priv->num_page_ranges = 0; + priv->manual_num_copies = 1; + priv->manual_collation = FALSE; + priv->manual_reverse = FALSE; + priv->manual_page_set = GTK_PAGE_SET_ALL; + priv->manual_scale = 1.0; + priv->manual_orientation = TRUE; + } + priv->print_pages_idle_id = g_idle_add_full (G_PRIORITY_DEFAULT_IDLE, print_pages_idle, data, @@ -1877,9 +2194,10 @@ print_pages (GtkPrintOperation *op, GDK_THREADS_LEAVE (); g_main_loop_run (priv->rloop); GDK_THREADS_ENTER (); + + g_main_loop_unref (priv->rloop); + priv->rloop = NULL; } - g_main_loop_unref (priv->rloop); - priv->rloop = NULL; } /** @@ -1964,7 +2282,7 @@ gtk_print_operation_run (GtkPrintOperati &do_print, error); if (do_print) - print_pages (op, parent); + print_pages (op, parent, result == GTK_PRINT_OPERATION_RESULT_PREVIEW); else _gtk_print_operation_set_status (op, GTK_PRINT_STATUS_FINISHED_ABORTED, NULL); @@ -2006,7 +2324,7 @@ gtk_print_operation_run_async (GtkPrintO { run_pdf (op, parent, &do_print, NULL); if (do_print) - print_pages (op, parent); + print_pages (op, parent, FALSE); else _gtk_print_operation_set_status (op, GTK_PRINT_STATUS_FINISHED_ABORTED, NULL); } Index: gtk/gtkprintoperation.h =================================================================== RCS file: /cvs/gnome/gtk+/gtk/gtkprintoperation.h,v retrieving revision 1.10 diff -u -p -r1.10 gtkprintoperation.h --- gtk/gtkprintoperation.h 24 May 2006 16:15:14 -0000 1.10 +++ gtk/gtkprintoperation.h 1 Jun 2006 20:34:39 -0000 @@ -29,6 +29,7 @@ #include "gtkpagesetup.h" #include "gtkprintsettings.h" #include "gtkprintcontext.h" +#include "gtkprintoperationpreview.h" G_BEGIN_DECLS @@ -84,7 +85,13 @@ struct _GtkPrintOperationClass GtkWidget *(*create_custom_widget) (GtkPrintOperation *operation); void (*custom_widget_apply) (GtkPrintOperation *operation, GtkWidget *widget); + + gboolean (*preview) (GtkPrintOperation *operation, + GtkPrintOperationPreview *preview, + GtkPrintContext *context, + GtkWindow *parent); + /* Padding for future expansion */ void (*_gtk_reserved1) (void); void (*_gtk_reserved2) (void); @@ -98,7 +105,8 @@ struct _GtkPrintOperationClass typedef enum { GTK_PRINT_OPERATION_RESULT_ERROR, GTK_PRINT_OPERATION_RESULT_APPLY, - GTK_PRINT_OPERATION_RESULT_CANCEL + GTK_PRINT_OPERATION_RESULT_CANCEL, + GTK_PRINT_OPERATION_RESULT_PREVIEW } GtkPrintOperationResult; #define GTK_PRINT_ERROR gtk_print_error_quark () Index: gtk/gtkprintoperationpreview.c =================================================================== RCS file: gtk/gtkprintoperationpreview.c diff -N gtk/gtkprintoperationpreview.c --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ gtk/gtkprintoperationpreview.c 1 Jun 2006 20:34:39 -0000 @@ -0,0 +1,107 @@ +/* GTK - The GIMP Toolkit + * gtkprintoperationpreview.c: Abstract print preview interface + * Copyright (C) 2006, Red Hat, Inc. + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2 of the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library; if not, write to the + * Free Software Foundation, Inc., 59 Temple Place - Suite 330, + * Boston, MA 02111-1307, USA. + */ + +#include "config.h" + +#include "gtkprintoperationpreview.h" +#include "gtkmarshalers.h" +#include "gtkintl.h" + +static void gtk_print_operation_preview_base_init (gpointer g_iface); + +GType +gtk_print_operation_preview_get_type (void) +{ + static GType print_operation_preview_type = 0; + + if (!print_operation_preview_type) + { + static const GTypeInfo print_operation_preview_info = + { + sizeof (GtkPrintOperationPreviewIface), /* class_size */ + gtk_print_operation_preview_base_init, /* base_init */ + NULL, /* base_finalize */ + NULL, + NULL, /* class_finalize */ + NULL, /* class_data */ + 0, + 0, /* n_preallocs */ + NULL + }; + + print_operation_preview_type = + g_type_register_static (G_TYPE_INTERFACE, I_("GtkPrintOperationPreview"), + &print_operation_preview_info, 0); + + g_type_interface_add_prerequisite (print_operation_preview_type, G_TYPE_OBJECT); + } + + return print_operation_preview_type; +} + +static void +gtk_print_operation_preview_base_init (gpointer g_iface) +{ + static gboolean initialized = FALSE; + + if (!initialized) + { + g_signal_new (I_("ready"), + GTK_TYPE_PRINT_OPERATION_PREVIEW, + G_SIGNAL_RUN_LAST, + G_STRUCT_OFFSET (GtkPrintOperationPreviewIface, ready), + NULL, NULL, + g_cclosure_marshal_VOID__OBJECT, + G_TYPE_NONE, 1, + G_TYPE_OBJECT); + + g_signal_new (I_("got-page-size"), + GTK_TYPE_PRINT_OPERATION_PREVIEW, + G_SIGNAL_RUN_LAST, + G_STRUCT_OFFSET (GtkPrintOperationPreviewIface, ready), + NULL, NULL, + _gtk_marshal_VOID__OBJECT_OBJECT, + G_TYPE_NONE, 2, + GTK_TYPE_PRINT_CONTEXT, + GTK_TYPE_PAGE_SETUP); + + initialized = TRUE; + } +} + + +void +gtk_print_operation_preview_render_page (GtkPrintOperationPreview *preview, + gint page_nr) +{ + g_return_if_fail (GTK_IS_PRINT_OPERATION_PREVIEW (preview)); + + GTK_PRINT_OPERATION_PREVIEW_GET_IFACE (preview)->render_page (preview, + page_nr); +} + +void +gtk_print_operation_preview_end_preview (GtkPrintOperationPreview *preview) +{ + g_return_if_fail (GTK_IS_PRINT_OPERATION_PREVIEW (preview)); + + GTK_PRINT_OPERATION_PREVIEW_GET_IFACE (preview)->end_preview (preview); +} + Index: gtk/gtkprintoperationpreview.h =================================================================== RCS file: gtk/gtkprintoperationpreview.h diff -N gtk/gtkprintoperationpreview.h --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ gtk/gtkprintoperationpreview.h 1 Jun 2006 20:34:39 -0000 @@ -0,0 +1,75 @@ +/* GTK - The GIMP Toolkit + * gtkprintoperationpreview.h: Abstract print preview interface + * Copyright (C) 2006, Red Hat, Inc. + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2 of the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library; if not, write to the + * Free Software Foundation, Inc., 59 Temple Place - Suite 330, + * Boston, MA 02111-1307, USA. + */ + +#ifndef __GTK_PRINT_OPERATION_PREVIEW_H__ +#define __GTK_PRINT_OPERATION_PREVIEW_H__ + +#include +#include + +#include "gtkprintcontext.h" + +G_BEGIN_DECLS + +#define GTK_TYPE_PRINT_OPERATION_PREVIEW (gtk_print_operation_preview_get_type ()) +#define GTK_PRINT_OPERATION_PREVIEW(obj) (G_TYPE_CHECK_INSTANCE_CAST ((obj), GTK_TYPE_PRINT_OPERATION_PREVIEW, GtkPrintOperationPreview)) +#define GTK_IS_PRINT_OPERATION_PREVIEW(obj) (G_TYPE_CHECK_INSTANCE_TYPE ((obj), GTK_TYPE_PRINT_OPERATION_PREVIEW)) +#define GTK_PRINT_OPERATION_PREVIEW_GET_IFACE(obj) (G_TYPE_INSTANCE_GET_INTERFACE ((obj), GTK_TYPE_PRINT_OPERATION_PREVIEW, GtkPrintOperationPreviewIface)) + +typedef struct _GtkPrintOperationPreview GtkPrintOperationPreview; /*dummy typedef */ +typedef struct _GtkPrintOperationPreviewIface GtkPrintOperationPreviewIface; + + +struct _GtkPrintOperationPreviewIface +{ + GTypeInterface g_iface; + + /* signals */ + void (*ready) (GtkPrintOperationPreview *preview, + GtkPrintContext *context); + void (*got_page_size) (GtkPrintOperationPreview *preview, + GtkPrintContext *context, + GtkPageSetup *page_setup); + + /* methods */ + void (*render_page) (GtkPrintOperationPreview *preview, + gint page_nr); + void (*end_preview) (GtkPrintOperationPreview *preview); + + /* Padding for future expansion */ + void (*_gtk_reserved1) (void); + void (*_gtk_reserved2) (void); + void (*_gtk_reserved3) (void); + void (*_gtk_reserved4) (void); + void (*_gtk_reserved5) (void); + void (*_gtk_reserved6) (void); + void (*_gtk_reserved7) (void); +}; + +GType gtk_print_operation_preview_get_type (void) G_GNUC_CONST; + +void gtk_print_operation_preview_render_page (GtkPrintOperationPreview *preview, + gint page_nr); +void gtk_print_operation_preview_render_sheet (GtkPrintOperationPreview *preview, + gint page_nr); +void gtk_print_operation_preview_end_preview (GtkPrintOperationPreview *preview); + + +#endif /* __GTK_PRINT_OPERATION_PREVIEW_H__ */ Index: gtk/gtkprintunixdialog.c =================================================================== RCS file: /cvs/gnome/gtk+/gtk/gtkprintunixdialog.c,v retrieving revision 1.22 diff -u -p -r1.22 gtkprintunixdialog.c --- gtk/gtkprintunixdialog.c 1 Jun 2006 04:58:18 -0000 1.22 +++ gtk/gtkprintunixdialog.c 1 Jun 2006 20:34:39 -0000 @@ -275,7 +275,8 @@ gtk_print_unix_dialog_init (GtkPrintUnix (GCallback) gtk_print_unix_dialog_destroy, NULL); - gtk_dialog_add_buttons (GTK_DIALOG (dialog), + gtk_dialog_add_buttons (GTK_DIALOG (dialog), + GTK_STOCK_PRINT_PREVIEW, GTK_RESPONSE_APPLY, GTK_STOCK_CANCEL, GTK_RESPONSE_CANCEL, GTK_STOCK_PRINT, GTK_RESPONSE_OK, NULL); Index: tests/print-editor.c =================================================================== RCS file: /cvs/gnome/gtk+/tests/print-editor.c,v retrieving revision 1.7 diff -u -p -r1.7 print-editor.c --- tests/print-editor.c 31 May 2006 14:06:02 -0000 1.7 +++ tests/print-editor.c 1 Jun 2006 20:34:39 -0000 @@ -262,6 +262,7 @@ begin_print (GtkPrintOperation *operatio int num_lines; int line; + g_print ("begin-print\n"); width = gtk_print_context_get_width (context); height = gtk_print_context_get_height (context); @@ -304,6 +305,7 @@ begin_print (GtkPrintOperation *operatio print_data->page_breaks = page_breaks; + g_print ("found %d pages\n", g_list_length (page_breaks)); } static void @@ -317,6 +319,9 @@ draw_page (GtkPrintOperation *operation, int start, end, i; PangoLayoutIter *iter; double start_pos; + + g_print ("draw-page %d\n", page_nr); + if (page_nr == 0) start = 0; else @@ -430,17 +435,205 @@ custom_widget_apply (GtkPrintOperation * data->font = g_strdup (selected_font); } +typedef struct +{ + GtkPrintOperation *op; + GtkPrintOperationPreview *preview; + GtkWidget *spin; + GtkWidget *area; + gint page; + PrintData *data; + gdouble dpi_x, dpi_y; +} PreviewOp; + +static gboolean +preview_expose (GtkWidget *widget, + GdkEventExpose *event, + gpointer data) +{ + PreviewOp *pop = data; + + gdk_window_clear (pop->area->window); + gtk_print_operation_preview_render_page (pop->preview, + pop->page - 1); + + return TRUE; +} + +static void +preview_ready (GtkPrintOperationPreview *preview, + GtkPrintContext *context, + gpointer data) +{ + PreviewOp *pop = data; + gint n_pages; + + g_object_get (pop->op, "n-pages", &n_pages, NULL); + g_print ("ready to preview %d pages\n", n_pages); + + gtk_spin_button_set_range (GTK_SPIN_BUTTON (pop->spin), + 1.0, n_pages); + + g_signal_connect (pop->area, "expose_event", + G_CALLBACK (preview_expose), + pop); + + gtk_widget_queue_draw (pop->area); +} + +static void +preview_got_page_size (GtkPrintOperationPreview *preview, + GtkPrintContext *context, + GtkPageSetup *page_setup, + gpointer data) +{ + PreviewOp *pop = data; + GtkPaperSize *paper_size; + double w, h; + cairo_t *cr; + gdouble dpi_x, dpi_y; + + paper_size = gtk_page_setup_get_paper_size (page_setup); + + w = gtk_paper_size_get_width (paper_size, GTK_UNIT_INCH); + h = gtk_paper_size_get_height (paper_size, GTK_UNIT_INCH); + + cr = gdk_cairo_create (pop->area->window); + + dpi_x = pop->area->allocation.width/w; + dpi_y = pop->area->allocation.height/h; + + g_print ("new dpi: %f, %f\n", dpi_x, dpi_y); + if (fabs (dpi_x - pop->dpi_x) > 0.001 || + fabs (dpi_y - pop->dpi_y) > 0.001) + { + gtk_print_context_set_cairo_context (context, cr, dpi_x, dpi_y); + pop->dpi_x = dpi_x; + pop->dpi_y = dpi_y; + } + + pango_cairo_update_layout (cr, pop->data->layout); + cairo_destroy (cr); +} + +static void +update_page (GtkSpinButton *widget, + gpointer data) +{ + PreviewOp *pop = data; + + pop->page = gtk_spin_button_get_value_as_int (widget); + g_print ("go to page %d\n", pop->page); + gtk_widget_queue_draw (pop->area); +} + +static void +preview_destroy (GtkWindow *window, + PreviewOp *pop) +{ + gtk_print_operation_preview_end_preview (pop->preview); + g_object_unref (pop->op); + + g_free (pop); +} + +static gboolean +do_preview (GtkPrintOperation *op, + GtkPrintOperationPreview *preview, + GtkPrintContext *context, + GtkWindow *parent, + gpointer data) +{ + GtkPrintSettings *settings; + GtkWidget *window, *close, *page, *hbox, *vbox, *da; + gdouble width, height; + cairo_t *cr; + PreviewOp *pop; + PrintData *print_data = data; + + pop = g_new0 (PreviewOp, 1); + + pop->data = print_data; + settings = gtk_print_operation_get_print_settings (op); + +#if 0 + /* FIXME need to figure out the size */ + width = gtk_print_settings_get_paper_width (settings, GTK_UNIT_PIXEL); + height = gtk_print_settings_get_paper_height (settings, GTK_UNIT_PIXEL); + + g_print ("%f x %f\n", width, height); +#endif + width = 200; + height = 300; + window = gtk_window_new (GTK_WINDOW_TOPLEVEL); + gtk_window_set_transient_for (GTK_WINDOW (window), + GTK_WINDOW (main_window)); + vbox = gtk_vbox_new (FALSE, 0); + gtk_container_add (GTK_CONTAINER (window), vbox); + hbox = gtk_hbox_new (FALSE, 0); + gtk_box_pack_start (GTK_BOX (vbox), hbox, + FALSE, FALSE, 0); + page = gtk_spin_button_new_with_range (1, 100, 1); + gtk_box_pack_start (GTK_BOX (hbox), page, FALSE, FALSE, 0); + + close = gtk_button_new_from_stock (GTK_STOCK_CLOSE); + gtk_box_pack_start (GTK_BOX (hbox), close, FALSE, FALSE, 0); + + da = gtk_drawing_area_new (); + gtk_widget_set_size_request (GTK_WIDGET (da), width, height); + gtk_box_pack_start (GTK_BOX (vbox), da, TRUE, TRUE, 0); + + gtk_widget_set_double_buffered (da, FALSE); + + gtk_widget_realize (da); + + cr = gdk_cairo_create (da->window); + + /* TODO: What dpi to use here? This will be used for pagination.. */ + gtk_print_context_set_cairo_context (context, cr, 72, 72); + cairo_destroy (cr); + + pop->op = op; + pop->preview = preview; + pop->spin = page; + pop->area = da; + pop->page = 1; + + g_signal_connect (page, "value-changed", + G_CALLBACK (update_page), pop); + g_signal_connect_swapped (close, "clicked", + G_CALLBACK (gtk_widget_destroy), window); + + g_signal_connect (preview, "ready", + G_CALLBACK (preview_ready), pop); + g_signal_connect (preview, "got-page-size", + G_CALLBACK (preview_got_page_size), pop); + + g_signal_connect (window, "destroy", + G_CALLBACK (preview_destroy), pop); + + gtk_widget_show_all (window); + + return TRUE; +} + +/* FIXME had to move this to the heap, since previewing + * returns too early from the sync api + */ +PrintData *print_data; + static void do_print (GtkAction *action) { GtkWidget *error_dialog; GtkPrintOperation *print; - PrintData print_data; GtkPrintOperationResult res; GError *error; - print_data.text = get_text (); - print_data.font = g_strdup ("Sans 12"); + print_data = g_new0 (PrintData, 1); + + print_data->text = get_text (); + print_data->font = g_strdup ("Sans 12"); print = gtk_print_operation_new (); @@ -452,12 +645,15 @@ do_print (GtkAction *action) if (page_setup != NULL) gtk_print_operation_set_default_page_setup (print, page_setup); - g_signal_connect (print, "begin_print", G_CALLBACK (begin_print), &print_data); - g_signal_connect (print, "draw_page", G_CALLBACK (draw_page), &print_data); - g_signal_connect (print, "create_custom_widget", G_CALLBACK (create_custom_widget), &print_data); - g_signal_connect (print, "custom_widget_apply", G_CALLBACK (custom_widget_apply), &print_data); - + g_signal_connect (print, "begin_print", G_CALLBACK (begin_print), print_data); + g_signal_connect (print, "draw_page", G_CALLBACK (draw_page), print_data); + g_signal_connect (print, "create_custom_widget", G_CALLBACK (create_custom_widget), print_data); + g_signal_connect (print, "custom_widget_apply", G_CALLBACK (custom_widget_apply), print_data); + g_signal_connect (print, "preview", G_CALLBACK (do_preview), print_data); + error = NULL; + +#if 1 res = gtk_print_operation_run (print, GTK_WINDOW (main_window), &error); if (res == GTK_PRINT_OPERATION_RESULT_ERROR) @@ -467,7 +663,7 @@ do_print (GtkAction *action) GTK_MESSAGE_ERROR, GTK_BUTTONS_CLOSE, "Error printing file:\n%s", - error->message); + error ? error->message : "no details"); g_signal_connect (error_dialog, "response", G_CALLBACK (gtk_widget_destroy), NULL); gtk_widget_show (error_dialog); g_error_free (error); @@ -489,10 +685,15 @@ do_print (GtkAction *action) g_signal_connect (print, "status_changed", G_CALLBACK (status_changed_cb), NULL); } +#else + gtk_print_operation_run_async (print, GTK_WINDOW (main_window)); +#endif g_object_unref (print); +#if 0 g_free (print_data.text); g_free (print_data.font); +#endif } static void --=-xjDvOKJb0tdB52kmWdgp-- From tomasek@ebed.etf.cuni.cz Fri Jun 2 03:11:55 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 2F96F3B01C7 for ; Fri, 2 Jun 2006 03:11:55 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05061-05 for ; Fri, 2 Jun 2006 03:11:53 -0400 (EDT) Received: from ebed.etf.cuni.cz (ebed.etf.cuni.cz [195.113.5.3]) by menubar.gnome.org (Postfix) with ESMTP id 3EDBD3B011A for ; Fri, 2 Jun 2006 03:11:53 -0400 (EDT) Received: from ebed.etf.cuni.cz (localhost.localdomain [127.0.0.1]) by ebed.etf.cuni.cz (8.12.11.20060308/8.12.11) with ESMTP id k5270gLE004827 for ; Fri, 2 Jun 2006 09:00:42 +0200 Received: (from tomasek@localhost) by ebed.etf.cuni.cz (8.12.11.20060308/8.12.11/Submit) id k5270gdU004825 for gtk-devel-list@gnome.org; Fri, 2 Jun 2006 09:00:42 +0200 Date: Fri, 2 Jun 2006 09:00:42 +0200 From: Petr Tomasek To: gtk-devel-list@gnome.org Message-ID: <20060602070042.GA3470@ebed.etf.cuni.cz> References: <1149203639.27455.9.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1149203639.27455.9.camel@localhost.localdomain> User-Agent: Mutt/1.4.1i X-Homepage: http://www.etf.cuni.cz/~tomasek/ X-Echelon: bomb Arafat Intifada bus kach drugs mafia boss heroin spy Semtex Saddam Al-Qaida Usama bin Ladin Bush Sharon X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.534 tagged_above=-999 required=2 tests=[AWL=0.065, BAYES_00=-2.599] X-Spam-Score: -2.534 X-Spam-Level: Subject: Re: Print preview api X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 07:11:55 -0000 On Thu, Jun 01, 2006 at 07:13:59PM -0400, Matthias Clasen wrote: > Ok, after a lot of work (mostly by John and Alex), > we finally have a proposal for a print preview > api that will allow us to use an external viewer > by default, but also support internal preview. Hi! I think, this is very unfortunate. Many people will not want to use the external viewer (for reasons discused earlier), so everyone will write his own preview widget? Why not just have official internal preview widget like gnome-print has and support it by deafult? P.T. -- Petr Tomasek From shree_poroly@yahoo.com Fri Jun 2 06:49:17 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id DD9063B03E7 for ; Fri, 2 Jun 2006 06:49:10 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19278-08 for ; Fri, 2 Jun 2006 06:49:06 -0400 (EDT) Received: from web53308.mail.yahoo.com (web53308.mail.yahoo.com [206.190.49.98]) by menubar.gnome.org (Postfix) with SMTP id 574673B110A for ; Fri, 2 Jun 2006 06:48:56 -0400 (EDT) Received: (qmail 1625 invoked by uid 60001); 2 Jun 2006 10:48:55 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=opsX4ZJJjJ3RSp61u8057G5DaMkib9ROhHy+AzeYX+l7J8HSwJa+UppJPxFDKOjVDg5ivFj+xumB8simRH1oUSf2tMk9h8YEuyY6OEPoTApYincgsxe7YmLfJe3+jDCaLeD7TV1kXmnpIstEupgel4fQt9kXW1CGDMkwXy+xReA= ; Message-ID: <20060602104855.1623.qmail@web53308.mail.yahoo.com> Received: from [61.246.61.209] by web53308.mail.yahoo.com via HTTP; Fri, 02 Jun 2006 03:48:55 PDT Date: Fri, 2 Jun 2006 03:48:55 -0700 (PDT) From: shree nidhi To: gtk dev MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-596188450-1149245335=:1049" Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=1.399 tagged_above=-999 required=2 tests=[AWL=-3.076, BAYES_50=0.001, DNS_FROM_RFC_ABUSE=0.2, DNS_FROM_RFC_WHOIS=1.447, HTML_40_50=0.496, HTML_IMAGE_ONLY_12=1.867, HTML_IMAGE_RATIO_02=0.463, HTML_MESSAGE=0.001] X-Spam-Score: 1.399 X-Spam-Level: * Subject: Fwd: test X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 10:49:17 -0000 --0-596188450-1149245335=:1049 Content-Type: multipart/alternative; boundary="0-601274911-1149245335=:1049" --0-601274911-1149245335=:1049 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Note: forwarded message attached. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --0-601274911-1149245335=:1049 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit

Note: forwarded message attached.

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com --0-601274911-1149245335=:1049-- --0-596188450-1149245335=:1049 Content-Type: message/rfc822 X-Apparently-To: shree_poroly@yahoo.com via 206.190.49.100; Thu, 01 Jun 2006 21:38:26 -0700 X-Originating-IP: [202.71.129.68] Authentication-Results: mta129.mail.mud.yahoo.com from=galieosoft.com; domainkeys=neutral (no sig) Received: from 202.71.129.68 (EHLO smx1.net4india.com) (202.71.129.68) by mta129.mail.mud.yahoo.com with SMTP; Thu, 01 Jun 2006 21:38:26 -0700 Received: from [125.22.33.12] by smx1.net4india.com with smtp (Exim 4.51) id 1Fm1a8-00025h-AB; Fri, 02 Jun 2006 10:18:21 +0530 OM-Header: origin=omniqube Received: from unknown (192.168.0.89) by SMTP-Receiver; Fri, 2 Jun 2006 10:07:06 +0530 Subject: test From: Nidhi To: nidhi@galieosoft.com, shree_poroly@yahoo.com Content-Type: multipart/mixed; boundary="=-k0bJJnk7Qaq1V0+G97NB" Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-1) Date: Fri, 02 Jun 2006 10:12:00 +0530 Content-Length: 21206 --=-k0bJJnk7Qaq1V0+G97NB Content-Type: multipart/alternative; boundary="=-rVG5rqf50PHPN/AXL0Ln" --=-rVG5rqf50PHPN/AXL0Ln Content-Type: text/plain Content-Transfer-Encoding: 7bit I have developed an application for an handheld device, the initial window will look like this : But the device is having rectangular display if i place the window as it is my drawing area will look compressed, so i dont want to compress my drawing area. If i can tilt the window and display i hope my drawing area will look like enlarged. Is there any way to tilt an application window as shown please help me out. --=-rVG5rqf50PHPN/AXL0Ln Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
I have developed an application for an handheld device, the initial window will look like this :









But the device is having rectangular display if i place the window as it is my drawing area will look compressed, so i dont want to compress my drawing area. If i can tilt the window and display i hope my drawing area will look like enlarged.







Is there any way to tilt an application window as shown please help me out.


--=-rVG5rqf50PHPN/AXL0Ln-- --=-k0bJJnk7Qaq1V0+G97NB Content-Disposition: attachment; filename=test1.map Content-Type: application/octet-stream; name=test1.map Content-Transfer-Encoding: 7bit --=-k0bJJnk7Qaq1V0+G97NB Content-Disposition: attachment; filename=test2.map Content-Type: application/octet-stream; name=test2.map Content-Transfer-Encoding: 7bit --=-k0bJJnk7Qaq1V0+G97NB Content-Disposition: attachment; filename=wintilt.sxw Content-Type: application/vnd.sun.xml.writer; name=wintilt.sxw Content-Transfer-Encoding: base64 UEsDBBQAAAAAAJZQwTSAkGt+mxsAAJsbAAAtAAAAUGljdHVyZXMvMTAwMDAyMDEwMDAwMDEzNzAw MDAwMTM0REUzMjdBMTMucG5niVBORw0KGgoAAAANSUhEUgAAATcAAAE0CAYAAABJtnScAAAABHNC SVQICAgIfAhkiAAAABV0RVh0U29mdHdhcmUARXllIG9mIEdub21lCx+PrwAAGzFJREFUeJzt3X1w XOVh7/Hfvmglr23ZMS/BAWNbmBcrYPOSmCQ0kUMgwYQyIS+9uDdphyZtYzFzk6bJVWZaT5JbXXqH zjT3TlM70Et7XQ+95OIggkOhxAnrtBjiYBAGS7Zky/KLkLEl68162Zdzzv1jdY53VytZu9rVrh5/ PzMaafe8PUe757fPeZ7nnPVJcoQ5o2phtQLBoIb7zqY97/f7S1QioPzYtq2gJLUeP65jp8+oZ2BA I9FYqcuFHLR3dWn3rl165I+/qurqas2bN08VFRWEHS5Kw8PDuu222yQpGW7HTp/RL99sLmmhkJ+9 e/cqeu6cBgcHFQ6HFQwGVVlZqWAwmHX+eDw+5fp8Pp/3t9/v9x47jiPbtuU4U1f0Z7p8IaSWYap5 UuebbBm3vJP9Lib2Y6LJyu++1/r6+7zHQUk609+ffPM5jvzTKAjKh+M4io+NanR0VJZlye/3q7Ky UhUVFZLST1dt21ZVVZUcx5HjOGlvKPfNMZ03IlBuotGogsGgomNR77mgJA2NjimWSMhxHAXGD4Zd zzbJTiRkJRJy3E9cx5HcN3/G3z6/Xz6/Xxse3Di7e3URsx1HtmUpOjysnp4eLViwQBUVFXIcR6FQ SBUVFV7ISclaWzwel2VZXrgFAgFvvmAwmFbbAqbrBz/4gWKxmOLxuBKJxJS1dJ/Pl6xZBYN69NFH C7L82NiYqqqqNDY25s0XlKR4IqGEZcm2HVl+W5KUiMX01P/+Bx1+t1vv9fVraHR0yp07fvq0Xvjn bYolEjn+WzAjjqPoyIh+9PQOVS2sVmU4rGBlpQIVFfrhw5tUVVWlYDCoh//u72UnEkrEYrIty/tw 8gcC+uHDmzR//nxvXtrrkKvh4WE9/vjj055/3759euSRR3Tu3LmCLH/69GktXLhQI8PD3jxBSUpY luIJS5ZtezU3Kx7XoZNdemnfmxNOVbOdvr75H/+u6MiI4glr2gXMxcZP1mk0GtWze14ryvoLvb3N //lBLZo/X99+/IkClyzd6rU364H77kt77uCJk3o98rK6urq0ePFiVVRUKDYyoi3f26yO7lN6r69f w2Njajl+Qm/sjqirq0uXXHKJFi5cqKqqKgUCgaKWGeYZHa/8dHZ2Tmv+nTt3qr+/31tupsufPXtW Pp9PwyMj3jxBSYolEorG40pYloLjb2w7kdDx02cUz1ITc09pUtmWpUR0TNGMButt3/mWJKntZJf+ +//9iff81++7Vx9dfYOOnz6jzdu2X3BnPrl2jfrOndNPdv/7tHY+1Z9/8QGtWblS3/mHf9Tp/n5J 0lc+dafuuvVm/d3Pdur1tnZJ0t233qIvfvwOPfyjrTPaniQtmDdP1eHwhP9HMbzVcTTtcfv+tzQ6 OKCenh75fD5VVVUpEY2q7WSXdr62N+t8qaems9HIDLO4HVUX6rBKNTIyosR4vmQuf91116mtrS1t /sznUpcfGRnRggULstfcYu6p6fgb27Ys9Z87p2g8ntbj5fP50t787jTbtmUnEpOell575QdUWVGh odFRBQMBra1ZmVynnGmdym7860cvOM9k9nd0as3Klbph2VU62dMjSfrgiqu9cu1paZUk3bRyhfYf 7dRINDqj7UnJsz5Js3Kanvl6OLat2MiIBgYGFA6HZdu2ErGYTvb0euVxxtvr3Pmqq6sVDofT2unc Dgba4HAhlpU8Y0vk8H6PxWKybXvC8rW1tZKSYdbS0iJJWZ9LXd5tSx5JaT7zam5j420xCbfmZlmK xuNT1jz8Pt/5MEwkZFuWxmITx8n1DA7q0upq3bhiuV5+a7/W1tQoFo8rXFkpx3E0Fovp0upq/ZcH 7tc1S5dqXiikd3vP6p9e+oX2tR+WJDV97y/VOzSkr/3t/0p7/I8vvqSv3vNphSsr9c+7fqUXfvv6 hO2/3tauL3/qk/rg8qv189/s1WWLFmnpkiWSpBuWXaWxWEyVFRWqXX61Hnv+BY3FYjlvryIQ0B/d 82l94qYbFa6s9LY9FovJJ+l3P3K77l33IV26aJF6Bgb0r3tf187f7JXjOPq9uo9r4/o6ffvxJ3Sk u1t/9vnP6RM33aiGJ/5JbSe79J0vfUFDIyP68fMvTPo6uNxOhkQ06oVbNBpVIhrV2aGhtNfHGQ+9 oaEhDQ4OKhQKeZ0RwWDQq8kRcLgQ9wM2l3CzbdsLp9Tl9+/frzVr1kg6H2qu/fv3e9tIXd6yLNm2 PbFDQUq2sdmWJcfdmG0rlkjImiLcUlvXbCvZ25pt/n2H2nT3bbfqtmtXadfr+7TuulV6rfWg7vnw h7xlApLeaGvXthdfUlUopL/88u/r4fvv0x/+j785v6KM9S8Kh7VxfZ1+vf9tfe6Oj2nj+k/o53te nbD9o+++q75z53TTyhWSZemm5VdraGRER0+9p5tWrtC8YFA3LLtKFYGAXm89eH4bOWxvY90ndM+H btPOV1/TL99o1l899AdaGA7Lisd1/8c+qoc+c7d+03pQf/OTHfpi3cf10GfulmPbevaVPXrnSIe0 vk6rr7pS7SdO6IPLx2uVS5fqYOcx3bhiubb+bGfW/21qE4H7t21ZSsRievKlXygUDisQDMq2LDW3 tav70MHMFejJX+xSKBxWRdU8BUMhBSoq9N8e+kOFw2FvzBydDJiKG065nJZK52tsmcvv27fPG4zr 2rdv34T1u8vbti3LsjQWzRgK4krEYvK7NTfbTvaiZqmJZWOPDy/INv/g8LDeOdqpW69dJb9t6/Yb btD/3PFTL9wSsZiOd3frxKlTWrpkiRYtWKC+oSEtveSS9PU5SnscTyT07S0/1uDwsNavXaPFCxZM Wt4329p15623aOXll+vmmpV6s/2wjp16T2tqVuq6DyzVrauu0ZGud3W6tzev7a1fm/yk+ZeXdmlg eFixeML7n957+4clSY/9bKdOnT2rH/ed1UdW36B7b1+nHS9HdKDjqBKWpdrlV+vVt9/RwnBYPQMD uu7KD2jZkiWqDof1Zlv7tF+Ly1bWaP2nP5323IH2w3r7317wPsAc25bP79fTTz2lA8eOqaunV4Mj IzrQflhdB95RT0+PlozXbiXRyYAp5VNzcxxnQrhNtXzmtNTl3RpcIiX80sLNisckhdwllbDs5LAB yTsYvBVneazxU6IJO2E7eu1Ai9ZcU6MHPv47CldVqnm8EV9OMhhXXXWl/uIPvqIlCxfqxOnTuqS6 OlnotPWlr39kbEz9g4PJsrs7mWX7kvTGoTbdeestuvXaVVq7apWeeP5f1XXmjL7ymbt148oV+vD1 1+tX+97Ie3uXLkqWt39oaPyFOt92edmiRZKkU729sm1b7/Umrwu9bPGi5Km8ZantxEl9cMUKralZ qdbOY+o/d06rl1+tNdfUqOPdbm+7U3Fr3ZK0f7wd0XW644jsREIbbl+nyspK+f1+Pffqa3qr46ie +eWvzs935LDGhgbV29vrnZYGAgE6GTAlL1zGA+iOO+7IOt8rr7zi/e04Ttop5oWWv/322ydd3v2d 2nySHm7jA3ndjcUSCSViUU3H+ZrbxPltK6FXmpv1J/ffp4133ak9b7+j0ZHh8QLaSsSiemjDPVp6 yRJ9+Xs/0KmzZ/XYd/+rrrnyyrT1OY4mfewee5OV97cHDkiS7vvYR1Q9P6zfvvOO+oaGFIvH9anb btX7Fi7Uq2/vz3t7o9Go5s+bp4WVIQ2PjqoqFPKmn+7r15WXXapLFoTV3dOrK8ZrRGf6+rzl97e3 q3bFcn32ox/RK2+/reHRUdXdvFbrb1mrNw4enPbrMBnHtmUlEgoGg1qwYEGyXS0UUkd3d9q63UHB fX193nWqktI6Gc7/P85fApN5xQOdEReX1Ib9qaROdxxHsfGzkdTl169f780TiUQkyXvujjvu8J5L XT5bjS8t3Bzblp3yd8KyZMXjaTW0bNzTnElrbo6jE6dO6fip93T1Fe/XfzQ3n59vvObmNorX3XKz zo2O6qrLL5ckfej667V3vHcksyaV/vh8TSmbM2fPqrO7WyuWLtWJ997TqfFe05ajnbr5ums1NDyi lo6j3j851+292dau31m7Rn/24O8pVBFS5Xi42ZalZyMRPfylL+rrD3xOT774b/r98VPGZ3f/2lu+ ua1ND959l6656kr9/Y6fKuZ2iS9bpv+z8/lJasTJsrqvj1ubzvwtSXYinrzixLK8Ed7y+dQzOOSd qvr8fq+9bnBwUPPnz5ff71c8HlcoFFIgEPA6GNxPTbch1w03v9/vXfUQCAQIuItEZm/prl27ss6X GkK2bXvhlLr8rl27dNddd2nXrl1p68t8LnX5bDJOS+Nem5scR/HxS6/s8QMis/FaShkK4p6mZRsX Nz5M5IdP/ouWXfF+7Wl+K2U+R3YiocefadJffPUh/dH9v6vd+97QE8/+TH/8wOf0n+7+lF7bv//8 PyRj/Rd6nOr1Ay1asXSpXm9p9eZrPnRIN193rX5z4J2sbVrT3d6Pn96hZZdfrjXXXqutT+/Q8ive r0sXL5adSGjHrl/KL58+f+cn9aNv/7neO3tWW3f8VE//YpfX2/x2W3uyp9O21XL4sKzxNs+A36+3 Dh70tpM5xtBxHCkl+Hxu0GT8dod+PP/qawrNmyd/ICDbttXeckC9x48ll3VfW9vWT3f/WqGqKgUr KxUMheQPVuhbX/qCd0r76P/b4V2el7ziwZZ8fvkDAX3rS1/QvHnzvF5Xws18maeV0xUd7wDIXP7F F1+csK5sz7nLZ7tRhE+Ss3nbdjW3tevsyRPeJ/3hPa9o1cfuUHdry4SFJtNzrFM33XPvtOdHAbjn xz5f+vW+Wea7+vob0p463nZIR3+793wnw3hwPvnUU3rj8BEdPXVK/eeGdbztkM50HNHX7vusFixY oGAwqB89+5z+tvGv0uc7dFBnjnboa/d9VosWLVI4HPZqfDDbY489pkceeUQ7d+6c9jLPPPOMvv/9 7xdk+Wg0qiuuuEKRSESNjY2SspyWpjYcH9r9cvJaxPELWeVM0qg8fjriHx9ygPLUmfFB1XfyhKx4 XB9fc5NCoZD8fr9ebn5L+9oP69mf/zxtvrGhIfX29sqyLIVCIcWjY1POJ52/zRHhZj7HcfTNb35T IyMjyXGVKe33mXw+n3drLndc2kyXr15UPWG4Ulq42Zbl1dxWfnhdfjuZ1maFcpZsckh2MsyfPz/Z ThYK6dDJrrTX0bFtxUZHNTAwoIqKiuSdG2KxKeerqqryApNwM9/GjfndDcg9rZzp8u9bvESZNxWf UHPD3DDV0Ixs7aKpl865v5N/+71PwVAoJH8goJ6BgbQauHepVizmvZkcy7rgfGNjY4QbZsWSJe/T 0NBQ2nMTWuHOnjwxawVC6dl2MoxGR0eT99FKJNR9sFX93e+mz2clNDw87PWExsbGppyvv79fiUTC 64AAimlRdbV3hxDXhHBr+/XuWSsQysNPjhxJe3zsjX1Z53sqc759E6/jzTYfUGzf+MY3JvTKp4Vb YHygZilHo7e2tl54JgAYV1tbm/UO0tm/RUSlCZna2lrvdiYAMBNl0xjiXlIBAIVQNuEGAIVEuAEw 0qRtbuUq8/Q19Q4Cc5WJ+wSU2pwJNzcA6uvrJ0zbsmXLnAwEE/cJKBc5hVvm/cxdqV/ikO3vmYpE Il4AZBum4vP58gqDfMpYqP0q5D5dqEyl7IWmBxylknObW0tLy4Sf1GnFNNn4u3zG5bkH3WSBPVsK tU+T7Uep9w8olYJ2KEx1INXW1no/uXBrOBc62Ddt2qRIJKLVq1fntP5sMsvoPs787f6d636VYp9S TVbm1P2bbNpUj/N5fYFimZXeUreW5P6U+gBIPVXKpTypy6Supxz2K9v2s50SXqjMqdOnuz/l9H8A XDl3KGS+cWlPmVsu9Hrl83ryHkA5yjnc8n0jl9unebmVpxDcWlPq72yKse8m/j8xt83aUJB8Q3G6 PaBbt27Vpk2bLnhN7GQH/Wz26hV6n3KRuZ+FCKVirBOYqZJcoZDrm3/Lli0l+5KRYh2oxdqnC9Xa CoHwwlwwKzW3zEbmXA+89evXa8uWLV5NJtXWrVslqaA1nNTy5tLonst+zfY+pZYxs8zTCcOp/if5 rhMoprRvv+o9fkx7tm+T4zizfssjd3jEhQ6IzEuV3GCYy/eBM3GfgNlSW1urvr4+dXZ2qqmpKfu3 X80FmbUcEwLAxH0CSm3OhZuJB76J+wSUGrc8AmAkwg2AkQg3AEaass2N7zUAMFdNGm4M1AQwl2UN t9bW1oIMwCz0rXoAmKdYowWKPhSEYQ4AJlPMK1noUABQEsVu0y9quJXqYneUL9pyMVvm3BUKMMtM bqgATIVwQ8lkuw8cAYdCoc0NgJEINwBGItwAGIlwA2Akwg2AkegtRdFMNqaNXlHMBsINRTPZt8+7 wTbTLw4CpkK4oagmC7jU6UAx0OaGokutqQGzhXDDrCDYMNtm5bSUi6WRivcDZkNRw81xHO4MAqAk soZb6h108w0nx3G0fv161dXV5VcyABeF5557rijrnbTm5t5BN9+2Ep/PR7ABmJaGhoa8lrNtW9/9 7nezTivKaSltKgByletXEtTW1sqyrEmn01sKYM6Zzi3KCTcARiLcAJStmTRxEW4AypIbbPkGHOEG oOxkBlo+AUe4ASgrU90qKxfcFQRAWSnUdcjU3AAYiXADYCTCDYCRaHMDUDamc+XBdBFuAMpCoa9J J9wAlAXHcXJexrbtSacRbgDKAncFAXDR464gAC5ahBsAIxFuAIxEuAEwEuEGwEiEGwAjEW4AjES4 ATAS4QbASIQbACMRbgCMRLgBMBLhBsBIhBsAIxFuAIxEuAEwEuEGwEiEGwAjFfU7FGrW1aQ97tjb wXSmM53pWacXmk+Ss3nbdjW3tav3+DHt2b5NjuPk/GUNqdyv6KqrqytQMQGYasOGDWpoaMgpcyKR iOrr62VZlgKBgPr6+tTZ2ammpiY1NjZK4rQUgKEINwBGItwAGIlwA2Akwg2AkQg3AEYi3AAYiXAD YCTCDYCRCDcARiLcABiJcANgJMINgJEINwBGItwAGIlwA2Akwg2AkQg3AEYi3AAYiXADYCTCDYCR CDcARiLcABiJcANgJMINgJEINwBGItwAGIlwA2Akwg2AkQg3AEYi3AAYiXADYCTCDYCRCDcARiLc ABgpWMyV16yrSXvcsbeD6UxnOtOzTi80nyRn87btam5rV+/xY9qzfZscx1Fra2veK62trZUk1dXV FaiYAEy1YcMGNTQ05JQ5kUhE9fX1sixLgUBAfX196uzsVFNTkxobGyVxWgrAUIQbACMRbgCMRLgB MBLhBsBIhBsAIxFuAIxEuAEwEuEGwEiEGwAjEW4AjES4ATAS4QbASIQbACMRbgCMRLgBMBLhBsBI hBsAIxFuAIxEuAEwEuEGwEiEGwAjEW4AjES4ATAS4QbASIQbACMRbgCMRLgBMBLhBsBIhBsAIxFu AIxEuAEwEuEGwEiEGwAjBUtdAFw8Irt3e3+vr6srYUlwMbhguNXW1ua98pp1NWmPO/Z2MP0inq6U cCvH8jG9xO+PAvNJcjZv267mtnb1Hj+mPdu3yXEctba25r1SNxDr+HRGCmpuyGbDhg1qaGjIKXMi kYjq6+tlWZYCgYD6+vrU2dmppqYmNTY2SsrhtDS1BtfS0pJD0YEkAg2zaVrhVltbmxZomY8BoNzQ WwrASIQbACMRbgCMRLgBMBLhBsBIhBsAI01rKEhLSwvj3ADMKdMexEugAZhLOC0FYCTCDYCRCDcA RiLcABiJcANgpBmH20xuZgkAxVKQmhsBB6DcFOy0lIADUE4K2uZGwAEoFwUNN65iAFAuChZuBBuA clKQcCPYAJSbGYcbwQagHDGIF4CRCDcARiLcABiJcANgJMINgJEINwBGItwAGIlwA2Akwg2AkQg3 AEYi3AAYadpfypyPmnU1aY879nYwnelMZ3rW6YXmk+Rs3rZdzW3t6j1+THu2b5PjOGptbc17pe5N K+vq6gpUTACm2rBhgxoaGnLKnEgkovr6elmWpUAgoL6+PnV2dqqpqUmNjY2SOC0FYCjCDYCRCDcA RiLcABiJcANgJMINgJEINwBGItwAGIlwA2Akwg2AkQg3AEYi3AAYiXADYCTCDYCRCDcARiLcABiJ cANgJMINgJEINwBGItwAGIlwA2Akwg2AkQg3AEYi3AAYiXADYCTCDYCRCDcARiLcABiJcANgJMIN gJEINwBGItwAGIlwA2Akwg2AkQg3AEYKFnPlNetq0h537O1gOtOZzvSs0wvNJ8nZvG27mtva1Xv8 mPZs3ybHcdTa2pr3SmtrayVJdXV1BSomAFNt2LBBDQ0NOWVOJBJRfX29LMtSIBBQX1+fOjs71dTU pMbGRkmclgIwFOEGwEiEGwAjEW4AjES4ATAS4QbASIQbACMRbgCMRLgBMBLhBsBIhBsAIxFuAIxE uAEwEuEGwEiEGwAjEW4AjES4ATAS4QbASEX9DgUAyEUkEinYugg3AGXB/e6VQiHcAJQFx3FyXsa2 7UmnEW4AykKu37hXW1sry7ImnU6HAoA5Zzptc4QbACMRbgCMRJsbgLIyVa9pS0vLtNdDzQ1AWZks wHIJNolwA1CGMoMs12CTCDcAZcoNtHyCTSLcAJSxfINNItwAGIpwA2AkhoIAKBuzdleQQm4IAKYy a3cFKfSGAGAytm1PeRF8PrKGW2tr64x6KVzPPffcjNcBwGz333+/Dh06VPD1Fr3NraGhodibADBH 2bZdlGCTZqlDIZ/7NDmOk/NyAGZfvsfrhe7HNlNlNxSETgxg7sj3eJ2N47yk4UanBWCuUh/fJQu3 Uu84gOIr5XFeknAj2ICLR6mO91kPN4INuPiU4rif9XArxPg5AHNLKY77kpyWEnDAxaNUx3vJOhQI OMB8pTzOSzoUhIADzFXq47vsBvECQCHM2v3cynkkM4DCKKfjdVbCLd9uYIaNAHNHuR2vRQ+3fO/T VIz7OwEojnI8XrOGW6GqltXV1XrssccKsi4AyEXWcNu0adNslwMA8lJfX5/1+bRws+JxSZLP5yt+ iQCgCGzblpQRbpdfs0qbt20vSYEAFEZzW7sORn6lTV/4vFavXq1ly5bpgT/9uh78kz/Ne/rixYtV WVmpQCAwZyo/E05Lm9vaS1EOAAVy+shhxcbG1Nvbq+7ubklSbGxMUvL4zmf6wMCAKisr5ff751a4 uTsEwAznes6oublZXV1dWrx4cfJxynGe6/SqqioFg0H5/XNn3L9PklPqQgBAoc2dGAaAHPx/YMnV s9b8aj0AAAAASUVORK5CYIJQSwMEFAAAAAAAllDBNLasV216HwAAeh8AAC0AAABQaWN0dXJlcy8x MDAwMDIwMTAwMDAwMTM0MDAwMDAxMzdBQjUxQTdGMS5wbmeJUE5HDQoaCgAAAA1JSERSAAABNAAA ATcIBgAAACQVvTEAAAAEc0JJVAgICAh8CGSIAAAAFXRFWHRTb2Z0d2FyZQBFeWUgb2YgR25vbWUL H4+vAAAfEElEQVR4nO3de3hc5WEm8PecGd1tSb6C8QUsbNcShRAMsg2bWoBJIFwCXdJC+zRZIKGR S7fbbGG7adNsku4fLm36bLtIlDalSdjCEggEtgmlEMZJHYIxxBgs2QZ8wYCNbUmj0Whmzn3/kM7x jOZyzpyZo/nm6P09jx+kkWbmNbZef+c73/mOBMACAFmWQURUD0zTLPh4lEVGRGERBYDXXnsNqqZC ySjIZDJITU5iMpVCanISqXQamUwGGUWBrmmQJKnWmYmIcnzjG98AMF1obW1tWNS8CK2trdB1HWNj Y0gmk1AUBYZhwDRNGIZR8IVkWYYsy4hGo2hoaEA0GoUkSSw+IpoVTz31lPNx1P7Asizouo5MJoOJ iQmMjo4ilUpB0zSn1EzThK7r0HV96snRKJqbmzG/fT4WdC7E/Pnz0dHejuaWFs7JEVHgjhw5kvO5 U2imaaKpqQlNTU2IRCLo7OyErutOkRmGAcMwoOs6VFWFqqpQlKlD1MR4AqdOnkImk8GJEyec4R8R UVDGxsbyHosW+L6qGBoaCuqlq+qZZ57BvffeW+sYRHPCgQMHKnp+LBZDf39/0Sktp9Dsb7jvvvsw MjKCeDyOVCoFVVWdU6SWZTm/7MdkWUZDQwPuueeeioLWkizLvub8LMviXCHNOX7/3hebh6+mvBGa ruv4yle+gmeffdbzizzxxBNVDVULQ0NDiMVinr9/27Ztvp5HVM/8/r23nxe0vBGaaZrYsGEDFi1a BE3TnJMAxT5++eWXnZME9a6vr8/T9838g/T6PKJ65vfv/Wz+g593KtKyrJzPe3p68p408zcy8zlE RLXgFFqhY+J169YBAC666CLnsSuuuAIAsHXr1qCzCaFQoRNRLlF+TkouFjt48KDz8YYNG7Bx40bn 8xdeeCG4VIIQ5Q+JqB6I8PPiuvq10PKLuTAJLsIfDlG9qfXPDZfzF1DrPxSielbLnx/XQvNyUiBs 6mVRMJGIavnzk1do2ScH7JMCwNSOHK+88orzefZJgTAuLmWpEZWv1j83TqHZSy+yLyq3Twrs3bvX eWznzp0Ack8KRKOBXUFVU7X+wyGqJyL8vOSN0GaWk5eTAk1NTdVNJRAR/pCIRCfKz0ne0KqhoQEA cN5553l6gcWLF+PFF1+saijRhX0OkagQv3/vZ/PnJWc/NABobGzE3XffjXQ67eyFNvOidHs7Ifvj lpaWWQsclO7u7rK+3/7/Ve7ziOqZ37/32RtaBCmv0L72ta8hmUwinU573g8tk8lAUZTAwwZl+/bt tY5ANCfcdNNNgb5+3c7md3d3V+Xs6pYtW6qQpnq6ertwaNehWsfIwUzuRMsDiJkJQEX7D7ot6s8r tHraD62SrXtmazsTIsrld/9BL/up1f1+aGGboBfxX1RmcidaHkDMTLag9lPLK7S5vB8aEc2eIPZT c90PzQvuh0ZEIij74vQrrrgidId5RBQO3G1DMF29XbWOkIeZ3ImWBxAzUynV2KWDhUZENWeXWaWl lndxOhHRbJpZYpWUGkdoRFQzxcrLb6nlLdvws+AtjPuh1YqIa4eYyZ1oeQAxM81U7V068gotez+0 Qnbu3OmsQ3NeJKT7oRFRfXHdD82LMO+HRkT1g/uhEZHQyln3mldoc3U/NFGIuEMCM7kTLQ8gZiZb UPup5RXaXNwPjYhm16zttkFEFLRZ222DiGg2zMpuG1RbIs55MJM70fIAYmYKGguNiEKDhUZEdcle eZGNhUZEdSl76ZiNhSYYEfewYiZ3ouUBxMxUTYqiQFGUnMswWWhEVJfi8TgSiQQymYzzGAuNiOrS sWPHcPz4ccTjcecxrkMjoro0PDyMkZERnDp1ynmMhSYYEdcOMZM70fIAYmaqpsEnfwA1k0HyNAuN iOrc+r6rcPLdd4C16zBy9CgAzqERUZ26eN1aLD1/Tc5jHKERUd26eN1a7Mn6nCM0wYi4doiZ3ImW BxAzUzU99tDf4bt/87/w80e+4zzGQiOiuvTU3z2IB//8m/idW25xHmOhEVFdKrkOjbeiI6J6wnVo dUDEtUPM5E60PICYmaqp5Do0jtCIqJ5wHRoRhUbJdWgcoRFRveE6NMGJuHaImdyJlgcQM1M1lVyH xhEaEdUTrkMjotDgfmhEFBpch1YHRFw7xEzuRMsDiJmpmrgfGhGFBtehEVFoFFqH5hTazBt2EhHV G47QBCPi2iFmcidaHkDMTEFjoRFRaPCQk4hCg4VGRKHBQ07BiLh2iJnciZYHEDNT0FhoRBQaLDQi Cg0WGhGFBgtNMCKuHWImd6LlAcTMFDQWGhGFBguNiEKDhUZEocGFtYIRce0QM7kTLQ8gZqagcYRG RKHBQiOi0GChEVFosNAEI+LaIWZyJ1oeQMxMQWOhEVFosNCIKDRYaEQUGiw0wYi4doiZ3ImWBxAz U9BYaEQUGiw0IgoNFhoRhQYLTTAirh1iJnei5QHEzBQ0FhoRhQYLjYhCg4VGRKHBQhOMiGuHmMmd aHkAMTMFjYVGRKHBQiOi0GChEVFosNAEI+LaIWZyJ1oeQMxMQWOhEVFosNCIKDRYaEQUGiw0wYi4 doiZ3ImWBxAzU9CcQpMkqZY5iIgqxhEaEYUGR2hEFBocoQlGxLVDzOROtDyAmJmCxhEaEYUGR2hE FBocoRFRaHCEJhgR1w4xkzvR8gBiZgoaC42IQoOFRkShwUIjotBgoQlGxLVDzOROtDyAmJmC5hSa ZVm1zEFEVDGO0IgoNFhoRBQaPOQUjIhrh5jJnWh5ADEzBY2FRkShwUNOIgoNFhoRhQYLTTAirh1i Jnei5QHEzBQ0FhoRhQYLjYhCg4VGRKHBQhOMiGuHmMmdaHkAMTMFjYVGRKHBhbVEFBocoRFRaLDQ BCPi2iFmcidaHkDMTEFjoRFRaLDQiCg0WGhEFBosNMGIuHaImdyJlgcQM1PQWGhEFBosNCIKDRYa EYUGC00wIq4dYiZ3ouUBxMwUNBYaEYUGC42IQoOFRkShwUITjIhrh5jJnWh5ADEzBY2FRkShwUIj otCI1jpANfX09BT92tDQ0CwmIaJaCE2h9fT0lCwtt6+Loqu3S7i5D2ZyJ1oeQMxMQeMhJxGFBguN iEIjNIecQ0NDnEMjmuNCU2hAOEpLxDkPZnInWh5AzExBC1WhFVMvJwTIm9iOHc7HfVu21DAJiSYU hVbqULOc7yGi+uYUmiRJtcxREbfRV3aZ2d/LgiMKH+cspyzPjROeoheZiHtYiZapb8sW3HnvHUId bor2/wgQM1PQnBar5xFaOTiXRhRevufQLMuCZVkwDCPnl2mars/1MkoKonhYZkTh5hSaZVmen2SX ma7rUFUV6XQamUwGmUwGiqK4Pr8WxcIyIwo/55DTy8jKZo/MVFVFKpVCIpHA2NgY4vE4kslkxaGq Pc9VT2Um4tohZnInWh5AzExB83XIaVkWNE1DOp3G+Pg4RkZGMD4+DlVVMTk5WdZrFSqveiogIhKH 7zk0wzDwre8/icxEApmJCajpNEzDgGnonl8je8FrsY+JiLzyPYdmmiZMw8CS1V0Yee8oWtrbnbm1 U+++G0hYIqJSfC0+s4sLlolVv7IeC1asxIIVK9F5zvJq55tzRFw7xEzuRMsDiJkpaL4KTZKkqXVr kozOeW2+3zx7hwz7Yx5uEpFfvubQJEmCLMuQIxGsPvts7KkgQHZ5sciIqBK+TwpEIhFEolFcsuZ8 WDfcgAPvf4DT4+Owylj+QURUTb5HaNFoFHI0ii//6VehKRnoqgrLMKBmMp5fhxsy5hNx7RAzuRMt DyBmpqD5HqFJkoT7fuNWjI+PY2JiApOTk1BVFaOjo3jgtd2eXqNQaXEOjYj88r3Fhr10w778SVVV KIoCTdMqCuS2lTYRUTG+9kOzr+NUFAXJZBLxeNz3lQJERNXiFFq5+6FV60qBQubyIaeI91JkJnei 5QHEzBQ0TyM0+/DS3iJI0zSoqgpT17Ck63yMHD3i60qBuVxcRFR9ricFsrcKUhQFmUwGyWQSExMT 0FUVq9b9CkzDgDV9KdTYB+/PRm4iojyu13LOnC+bmJjA+Pg4xsfHoStKRVcKADzsJKLqcQqt2H5o 9lZBqVQKo6OjGBkZwdjYGBKJBNRMpqIrBbhEI5+Icx7M5E60PICYmYLmaR2aruv4s4e/g8zEBDIT CSiTk1MLaU2TVwoQkTDyCq3YCQBD07D8gl/FiYMH0NLROT1vZuC3b7sN0cZGRBobIUciMHXvZznt NWccpRFRNeTMoWUvlrXvEZBOp5FIJKCrKi5YuwamYUBXFZiGgVOH3oVlWbjy4o+hvb0dzc3NSKVS GHz9NU9vbs+fcddaIqqGnBGafQIgk8lgYmICiUQCk5OTSCQS0DJptLe2nvle04RlWZAkCaZpQtM0 yLJc1pUCLK18Iq4dYiZ3ouUBxMwUtJxCs4tpcnISIyMjOH36tHOtpppKYfniRc73StMLcSVZnlqT ZppIp9NQVbXiUDwMJSI/8ubQNE3DHz4wiFQ8jnRiHGoqBV1VAcvCBeeei1+/+iocOn4cpxMTMDQN 8Q8/xM/2vgnT0CFJMkzTKCsADzeJqFryDjkNw4BpGLhkSx+GXn8tZ9HsZ2+7DQ3NzYg2NgKSBEPT sPqyXowcPeIcgpZzpQBvkkJE1ZRXaFP3CrDQs2olNF2HomlQNA3vv/UmLNPETZs3obOzE7Is43v/ +jyvFKgyEec8mMmdaHkAMTMFLafQztwrQEJbc7PzmPN1WYZpmlBVdepkgJF7eFnOjh1ERNWWV2iR SARyJIKzFnTmfbMky1AUxVmjpqbTOV8v51Z4QO46tJk3TCEiKpdTaA0NDc5/o42N6Fp2Nm7c1Iv3 T49gdGLqBMDpI4fx41d2wdB1mLpelREab5JCRNWSM0KTZRkNDQ2Qo1Fs+/o3oSsKdFWFrihQ0yl0 X3k1jh/YPzVfpmuwLAvvHdjvPL/cERrlE3HtEDO5Ey0PIGamoBW8lvOB3/89jI6OIplMIpVKIR6P 468efQwXrF0DQ9Ng6BpMw4ChaTmjNK8jNC9bbHO0RkTlKlhouq5D0zTn0qdMJgOjwDWaMwvM6wiN 82VEFISCVwpkMhnE43HnSoHx8akFttnsdWd+Za85y/6ciMgvb1cKTM+lZZNkGdKMrYIqOSnAYpsi 4pwHM7kTLQ8gZqagRQE4O2xkbxV0ad+VeOu13c6CWdMwsO/td5wnVjpCm4nFRkSVigJTozLLsqCq KuLxOHRFwfqVK6BoGlRdR2a65LJHaYVGaJUUHIuMiCoVBYB0Og1d12EYBkZHR6FkzZdZlgVZkqDP KCtnhFbhKI1FRkTVIgNAIpHAiRMn8N577+HIkSPITCTyvtGeH8veNmj6C77euKenJ+cqAZrS1dtV 6wh5mMmdaHkAMTMFLWqaJr7y99+GkkxCy6ShTE7mjNBc+RihZa9D412fiKhaogCwZetW7Nq1a2oL bsMALAv7j03tmiFJEkx7F44sldwMhWVFREGIAsDa5cuB3t6pEwO6Dt0woOnu12naO3MQEYlAznvA Y0E5c2hUVSKuHWImd6LlAcTMFDS5bcHCqr0Y90MjolqSC12j6RV31yAikciFlmh4xREZEYnE00TY l66/Dldc0IP2trag88x5Iq4dYiZ3ouUBxMwUtILbB800v7UV/Z+5Ee2trTj04XG8vn8/Xt9/AG/s 349EMun7zbu7u3M+Hx4e9v1aRESeCu3+7z8JU9excuFCXHR+F/o+/jHcetWVME0TW75wt+83Hxwc zPm8v78fAIuNiPzxVGjrVizH2mXLsG75OVi/aiWWLlgAADB8Lq6NxWIAzhSYzS64/v5+lhoRlc1T oW2/6w4AwOnxcew7fARPvhTDvncP4cDhw2W/YSwWw7Zt2wqeIbULbnBwcM6Wmohrh5jJnWh5ADEz Bc3TSYGfvvkWRhIJtLe1oXPePLS1tKCxoQERH4tri5UZEVGlPI3Q/voHT8PUdSyZNw8Xda3G9Zs3 4XPXXQvdMHDlF3/X85vZh5pu+vv75/QojYj88VRo5y9bhu4Vy9Fz7ipccN55aG9rBTB12zsiIlF4 KrS/vPsuAIBuGDh47H3s/fnb2HPwIN48+Hag4eYiEe+lyEzuRMsDiJkpaJ4K7dHYDrz17iHsO3QY mUwGuqpM3WeggsumiIiqzVOhPb7jZ1P3FNC0it6sr68PAwMDkCSp5ImBwcFB9PX1cf6MiMriqdAk ScLNV1yOT2/sxZLODpwaG8PTO36Kx//1eRjuTy/6moVKTZIkDAwM+HxVIprLPBXajRt7ccenrnE+ P3vRInzp12+BZZr45x/9uKw3tEdpQOGL2wcGBtDX11fWa4aJiHMezOROtDyAmJmC5qnQPt17KX4x vB8PPv1DfDQyikVtrfjSLTfj5r4tZRcaAKewZo7E5nKREVHlPBXa4o4O3P9/n8DJsTgsy8KJ0VH8 8/PP43//0X+t6M1ZYERUTZ4Wkp0eH8dnt3wCZy9cCFmWsWzxIvz2tZ/CqbF40PmIiDzzNEL70a7d uONT12Bj9/qcxwe//2QgoeYyEdcOMZM70fIAYmYKmqdCe/YXr8AwDHx642VY0tGBk2NxPB2L4YkX Xgw6HxGRZ54KzQLwzM9fxg9iO2AahrOwlheZE5FIihbaX959F9pbW11f4BN3fqGqgYiI/CpaaOOT kzBME5YFLJw/DxOpFFRNB2ChubERTY2NiE9MzGLUuUHEOQ9mcidaHkDMTEErWmjf/D+PQdE0qLqO R//7ffjqw9/FwaNHYRoGIpaJb9z9Rbz06quzmZWIqCRPyzZSioKrL7kYHW1tkCQJbS0tUDUV/Z+9 Neh8RESeeTop8NM338KNmzfhxs2bch4/evxExQF6enryHhsaGqr4dYlo7vE0QvvH557H47Gf4uRY HKZpYjKdxr+/sRd/8kBlF5H39PRgaGgo71ehkpsrRLyXIjO5Ey0PIGamoHkaoWmGgUdeeBH/9KMf 5yzb4H5oRCQS7qFNRKHhaYR23WWX4va+X8P8AuvSKlmHVuzwknNoROSHp0L73Nar0NzYiHgyCcMw MHWBQHWuEmB55RJx7RAzuRMtDyBmpqB5KrSUouC5V3fjoR8+W9U5NPukgNfHiYhK8VRo337uedze twWPtbUhnkhU/KbZh5lz+YwmEVWXp0K789pPoqO1FQ//8b1IZTI5h5y3fPmPyn5Te/TFkRgRVZOn s5yL5s9HNBJBS1MTFnV0YHFnBxZ3dmJxZ2dFb84yyyfi2iFmcidaHkDMTEHzNEK75et/PnUbO1Wt +hxaMSw7IiqXp0ILCk8IEFE1FS20my/fhM093dj2twP4hy//AWBZ09NmVsVzaKXYa9NYakRUrqKF 1tLUhAXz5gGYmkOj2SHi2iFmcidaHkDMTEErWmiPvrQDj7z4EoDZn0Pj6IyI/Cg5h/bAPf3Ye/gI dh04iN3D+3FyZKSqb87iIqJqKlloT/xsJy5cfR5+9/rrcM9NN+DdDz7ErqFhvPzmXgwdOgxzlkIS EXlRstD+7fVf4l92vQrLstCzcgUuWXM+rtpwCW6/5mpMTKbwyr638PUHH6pamOxD0Lk6ehPxXorM 5E60PICYmYLmadmGomnY/94xmLqOjKLg6g2XYMH8+dja21txobHEiKhaShbapevWYu3yc7B+5Qqc u3QpJEkCAKiahj0H38aeAwd8v7FdZNmXQRERVaJkof3+Z250Pt576DDeePsdvPHOO9j3zjtQFMX3 WU6uMyOiIJS8lvOF1/fg+OgoAGD12Wfh3LPPwvIlS7CgwnVp9uJZjsryiTjnwUzuRMsDiJkpaCVH aN978SdQdR3zW1pw4bmrcHHXatx1/afxh79xK4599BF2Dw3jW997xNcb81CTiKrN00mBU+Pj+Mkv 9+DwBx/i6ImPcMPlm7DyrLOw8qyzfBeaLfvQkycIiKgSJQttaWcn1q9cgQvOXYULV5+HtuZm52tH jh/H7n3VLR2WGBFVomSh3f/FO52Px5JJvPL6L/H6gYN4dd8+nBod5W3sAiDi2iFmcidaHkDMTEEr WWh7Dx/G3kNHsPvg2zj84YfQFMW5lpOISDQlC+2vnngKqq4jo6qwrOrc5YmIKCi80TARhQYLTTAi znkwkzvR8gBiZgoaC42IQqOm9xTo7u7O+Xx4eLhGSYgoDDwV2nWXXYrb+34N81tb8772iTu/4PvN BwcHcz7v7+8HwGIjIn88Fdrntl6F5sZGxJNJGIaRc5MUP2KxGIAzBWazC66/v3/OlpqIa4eYyZ1o eQAxMwXNU6GlFAXPvbobD/3w2YrvKRCLxbBt27aCy0DsghscHJzTpUZE/ng6KfDt557HpevWob2t reI3LFZmRESV8jRCu/PaT6KjtRUP//G9SGUyvu/LaR9quunv7+cojYjK5qnQ7PtyRiMRtDQ1BRpo rhNxzoOZ3ImWBxAzU9A8FVpQ9+UkIqomLqwlotAoOkK7+fJN2NzTjW1/O4B/+PIfAJY1PW1m+Z5D 6+vrw8DAACRJKnliYHBwEH19fZw/I6KyFB2htTQ1YcG8eQCm5tAWtbdjUUc7FnV0YHFnBxZ3dmJx Z6fvN7bvIOX18bmiq7er1hHyMJM70fIAYmYKWtER2qMv7cA/Pf8CgOrOodmjNKBweQ0MDKCvr6/s 1yUi8n0tZ29PD37zmqvxn7ffX/Zz7cKyi23m40REfngqtA1r1+D3brrBOQS1aRWe5WSBEZGbcnrC U6Hd8clr0NLYiOMjI1jU3o5jJ09ixdKl+PbTP/SbkYoQce0QM7kTLQ8gZibbzJ123FiWBdM0Xb/P U6Gds2ghvvrwd5BOZ9D/mRvxpe1/gesv34yPrVlTVigiIsDfyT/DMFy/x1OhpVUVGVXFeDKJlUuX 4uyFCzGvpQVbNlxSdigioqGhIc+XQgJT14B74anQ3j1+HBd2rcbjL76E0YkJPPL1rwEA3j95suhz uru7A12CwQvcieqb17mxcorPU6H9zVPPIIKpEvmf3/0e7rjuWsiShId+8FTJ55Xbwl55bet6JOIe VszkTrQ8gJiZguap0E4nEjA0DQDwzvsf4L89MOB5HVq1z2QGUZBEFA4lC+2bn/8dWLBgWWd+wQIs y3Qug/pPf/Y/ZiUoEZGbkoW2aumS2cpBRHNQT09P0a8NDQ2V/XolC+3l4f34WNdqqJqGXwzvx869 b2LPwbeRTk1y+6CAiDjnwUzuRMsDiJlppqGhoYKl5qfMAJdCe/D//QimZeH8ZcvQu24N/sut/xGt zU14Zd8Q/n3PHvx8zxuYSCZ9vbEt+zdj/+b8/maIqP7MLLVKfv5d90PTDQNvHDqEB5/9F9y1/X48 /pMYLr/wV/Gnd96BrRt7fb8xAKe8sn8DxRqbiMLL7oBKBzOuZznnt7Rgc/d6bFi7BpesXYOWxkYA wHsnPsKxEx9V9OZERLZqHJmVLLQ/uf03sXb5OZAkCaZp4q3DR/CLfUPYuWcPjp04wTm0AIi4doiZ 3ImWBxAzU9BKFtq6FcsBTK1De+3AQSQmJ9E5bx6u27xpahmHaWLw8e/7fvOZh5f2x5xDIyJb1Xfb WNzejk9ddmnBr1VSaEDtyotzdUS1U5PdNj5//7eg6joyqirkXZ/s/yl+rxm1LIt7shHNsu3bt/t+ bnt7e8mv+96xthJeRkZuI7fsG6j4HeUNDw8jFosJdR+DHTt21DpCHmZyJ1oeQMxMg4ODFT3f7dLH mhSaSHNkkiTx8JMoJGpSaCISqWTJHRdg15dYLDYru+TkFdqPH3sUaioFJZWCrmRg6jpMw8i6OP3M fwEAkgQ5EsH6vqs8v6n9l7Ha13ER+cWCDIe8QrNME9d97vPYFYtNTfyb5nSpTRebaeb99/SRw2W9 abVWBRNVg/0PK0ut/hUstFVLl0L7D5+AomlFz3IamgbLNPH+m3s9nU4lEtHMowSWWn3Lv5bT4xk/ Sc56apnbYXMCnkRQ7O8h/37WL9eTApZlQZYkFLrfSrX29ee/ilQL/DsXPvkjtAIlZWY9ZvHwkogE lT9Cmz7kNO2zmTO/nHWoKdKCVJq7eLacbEUPOWVJgjT9i0hUbtMVnM6YW/ILbcaorNQ8WSVzaIXO LmXjX0IiKlfRQ84zn+Z+nj2H5nytzFEcy4qIgpBXaJIkYX5LS9EnZM+h2SM0WXbdyZsoELzihLLl F5os46wFnc6ZzWKHlZZpOiM0OcpLQql2WFpky2uiSDSKNecswyc3fBzvnTyFeDLpXDGg6Tp0w4Sq 69ANA5quw9B1JE7W770FLMvK2YqI6gNLjArJKzQ5GsVtX/giDE1zLkx3rt00TWB650hr+mPLshBp aJy1wNyQkaj+zNbPbV6hbb35lunRmFHyWk57x1pDP3PR+kzlbrPrVbVHVUHlJKIzZuNoKLDJL65f I6IglNpXLQoArU1Th4ymZcEwTZjm1H91w4A+fchp/zI0NW/7IEzfAcoyTSw4Zzk23vZbiDQ0zM7v jojmHEPTsOfg23mPRwFgcUcHgDNXB8iyhIgsIxqJwLQs6JEILNNEY0sLUGJJBxFRLUUB4NylS3D1 xy/GqXgcE+nM9NlMwzmbqfKGwkQkqD1ZH0sAqrMHEBFRjf1/WwoQUouhLCMAAAAASUVORK5CYIJQ SwMEFAAIAAgAllDBNAAAAAAAAAAAAAAAAAsAAABjb250ZW50LnhtbMVXbVPjNhD+3l+xdaedduYc JwSGIyW5gQtc6YSXKTDTflQkxdYgS64kJ+R+fVfySxIg4a50rh+wo9WzL9p9di2OPzzmEubcWKHV MOp1uhFwRTUTKh1G93fn8fvow+i74+/H1x/v/ro5Az2bCcoHTNMy58rFVCuHb7i5P51cfIQoTpLr gqvrAOtokybJ+G4M1XpcawH6SZKzqwiiyl6HORaNjrcZxxiVHVS7wyhzrhgkiUY3euVmr9vtJtU6 qhWsW8rd+IBo4I4/up1oD2jBZPqK7YBo4MyQxU60B2DOG/xMt+jFYtFZ9AOyd3R0lPx5O0nOtclJ G8ujFOphKz7sNlBV5lNudkdCHNnIi52nLxmvEjhvQ6YZMbvzFxCrjPTZKxnpswaMh822HPB9comb 4XE5WaXP5DuNe0B7PmpEsTvyChI17KeSWDuMKj7Uso0eaqlcKSbteoaMjhmn0o6OQ5JXEqjWiuTI qxMjiIR7JbAVOVzeRjDTFXRGciGXw+gnUmj761NcJY1gzXYhHMXkzQlCPSOT3Z5/+wSXQtFMw0Sk mYPft7l+Bny77yuRT0sLf+icKLjSRzDZ5vw58gXvlUqccsWNoMPIePRr8SUvVKoWkdKhBSdoHEy0 JQzPjYPc9Vo3ddiBK41CYZBkxglu2+MtuE/iMJpqyUIYa6a3+5mZZ45SQ4pMUNvIC2L8KA2LuNL6 1EBeiKcSZNqIzxgWkTFmdRhRNMFN9HzXcDmM0AUJbhtALozROGWUVjxUkEpRYP45dT93aQ5rf79E 4EffQJa5UET5+d79sZb58W9wFq2JDGdrq9RwrtbWU1mu66ckzwk2ZGtOahML1XbqjEjL6010pGzI FcUkxr3uWhReLcf+GkbWEcWIeaFCyVaO1BtTzZajY0+DgeV/l+iHN/R6LoQgYsIWkixjXTqc4TyW fO7TjZ/osF0V80LK0mL0Do/kw3qTsbumC95mxXP9rUbG9QfRZ3p71opKZZ3dt02NRheQkTkH5s0j wRngrCBFIQUN2UJiGi/KEJ9xyTwQK/UOXMahDj4ZCSWcn7EYDNMLfEkJUusHkOKBI1RYGNQRFl8Q VPINMaPjQGCRk5RXXF6HhdkRpBtToVdXgfjRbmK3LPhmh8/TwUIw/z0+7Bzs9WleybJ6gB129g96 XhhMf8Z+Y/wxFDdcRAaZ4bNh9MONoK403CbYad3uXje8ur3+Yf3eH5/19w5Pev1OEW5FQbcKxoq8 CLeTILOZxpsVx2sNa0QETROHSK0mmrAVhf6rAo1OSxdYUjEGkAPINGQr+BFHVFpKYqCmOYgZCMBf lAedmkjEgnBeM19CffkDHD9kjWFU5wWmyHL2DqxGIwwHIiwIPpxud58a6MCFd0iR2U5It+FTsVVU kGFP7PAe+M0VniTlrAP/A8f/FX/3voa/NVU3+VuTepO/vS/k737D45PTg97J4XnvW/O3GbuFr/9T FN5LRhfWU8JwZMMSybT0XApEeTIdVzz1ISpkMCeWA07KAnIOOLw7zWRGX1/ZYsnGVzHZ8o/f6B9Q SwcIVrL7yYQEAACfDgAAUEsDBBQACAAIAJZQwTQAAAAAAAAAAAAAAAAKAAAAc3R5bGVzLnhtbO1Y S2/jNhC+91eoLNqbLNmJmziNsmg3+2iRx6JJgPZIS5TFViIFkrKT/fUdkqJk2ZSTwkBPzSGION88 9XFmlMt3z1UZrImQlLMETScxCghLeUbZKkFPjx/Dc/Tu6pvLb6/v3z/++eVDwPOcpuQi42lTEaZC qV5KIoMvT7/c/Po+QGEU3deE3RvUhItVFF0/Xgf2+bpVCsBNFH24QwGy5iaZytDV5YhtiJDJCytM UKFUfRFFHLzw3sssjuPIPqNWwWgfxBuEgyvyrA6iNaAD4+Urtg3CwTOBNwfRGgAVd/icd+jNZjPZ nBjkdLFYRH883EQfuahwF8tzSdnfo3gjdVDWVEsiDkeCFR7URa5XPuO2gOsu5LTA4nD9DKKvyEn2 SkVOMgeGZIuRBM+jWxCaX7c3fflEddC4BnT5pYLWhyO3EOS4P7gtHWtzDozNSFrKq0tTwP4ksM8M V8CZnwXFZfDEKFwyEtw+oCDnFprjipYvCfoB11z+tIuzpyjYsl1TlUJh1higmm3RYc+fPwW3lKUF D27oqlDBb2Ou94DH+76j1bKRwe+8wiy444vgZsz5PtLj3aqEK8KIoGmChEa/Fl/keVPtke00LoWM 5Lgp2/7jjLZBrgSuC5pK5MC1AMoIRaFR6VsMpoDmIdw6Esoap3Crw4IL+hWc4jJB8WR2fpIC+8bA a20s3YcSlr3V6h7UYxOKn/KSQzP4LjY/g+q9/tIk/QqI6UzfCzgrMVs1eAVHhLXGG6YEFOzpYc9y iCXFzEvILaT24JDWjxU6V07GOCNO1nr1iXrvKa/qkjz7ruKu+w7qDaCT+kLwCvUMCXGjuH4zUCya EW4YFeKyLrCD1Q1LVYMVdJlwA+IESaqtdRHol7sUBEPflwpugOroCHMHeMtrqQm/y9DuaMDwt9C+ xgKbQH28/59L/y2XoCTFS10QhhUUKcelHB5q2ghSYcpCPXRDYyZBsz1Q3cjiFUiJs4x0csahsVRU Hc3nAvI2C88ooYMhn8OMQrNk2slsMovnuodZxEZQpZtcBYVPUClCtUTRYaZvM9zS8wFsZ1hkaJT3 7pWUWMoEmWUwGrf3yY2JfzE+tM0LrDkMObzUZOh9vboAAsQmb/j7xf3d1kAXdZs6ruWHMDshXF7v CQQpPfn1U8VqprCIE+GR7qj3FW8rbbLhjbKDyHNWkjUp22ZjBOYArodzBttqmJtVN0Ha/pu0Z0dp nxylfXqU9vwo7R+P0j47Svv8KO3FUdrTeEw9GmVgzrliXBEJbY3ldNUI05o8doCLRsPuaWtcNnAr 4/awNwM3hSrzSVBDLx/o2E8u3Z+0Pfdp26UHq9rbIqH+SJwdnWPvamjMAKzQrIWymxm2QnkuidKr 4eli0bcUXxlaI326JclVK4PhCzOH6Ckx39623WrdPuphATZpGg53bl24sIJPTyIGjbSupiMrh9HY 0Ex/G86mk/miXWvNeUH0FgCCs8nidDQpZ5bCjIbOBsHj9jVyoQSmdh+psIBZFUIP1bNnftr6aY+X XEFGPokuDrSUyfRsPhQIG1sncZuCpRNU4bmLX/f4/suqBUhSu75v048n8fS8t+RGZbgkkKzBa8w0 nnowOIeSeyE4+6uRyr5S+6LtOXT+ru7z7/tdZbAB+tfPdooQrHcK8xBtZ7d1GO3RoqfUPodagQXu MKs91JYOjvwtV2HPvS0m71iP/P+uuvoHUEsHCFT8PRwABQAAUxMAAFBLAwQUAAAAAACWUME0gbtD aWIEAABiBAAACAAAAG1ldGEueG1sPD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgi Pz4KPCFET0NUWVBFIG9mZmljZTpkb2N1bWVudC1tZXRhIFBVQkxJQyAiLS8vT3Blbk9mZmljZS5v cmcvL0RURCBPZmZpY2VEb2N1bWVudCAxLjAvL0VOIiAib2ZmaWNlLmR0ZCI+PG9mZmljZTpkb2N1 bWVudC1tZXRhIHhtbG5zOm9mZmljZT0iaHR0cDovL29wZW5vZmZpY2Uub3JnLzIwMDAvb2ZmaWNl IiB4bWxuczp4bGluaz0iaHR0cDovL3d3dy53My5vcmcvMTk5OS94bGluayIgeG1sbnM6ZGM9Imh0 dHA6Ly9wdXJsLm9yZy9kYy9lbGVtZW50cy8xLjEvIiB4bWxuczptZXRhPSJodHRwOi8vb3Blbm9m ZmljZS5vcmcvMjAwMC9tZXRhIiBvZmZpY2U6dmVyc2lvbj0iMS4wIj48b2ZmaWNlOm1ldGE+PG1l dGE6Z2VuZXJhdG9yPk9wZW5PZmZpY2Uub3JnIDEuMC4yIChMaW51eCk8L21ldGE6Z2VuZXJhdG9y PjwhLS1TUkM2NDFfWzc2NjNdX0xJTlVYX0lOVEVMX19zeWx2ZXN0ZXIuZGV2ZWwucmVkaGF0LmNv bV9hdF8yLzIwLzAzXzEyOjMzOjQ1LS0+PG1ldGE6Y3JlYXRpb24tZGF0ZT4yMDA2LTA2LTAxVDEw OjQ1OjU1PC9tZXRhOmNyZWF0aW9uLWRhdGU+PGRjOmRhdGU+MjAwNi0wNi0wMVQxMTowNDo0NDwv ZGM6ZGF0ZT48ZGM6bGFuZ3VhZ2U+ZW4tVVM8L2RjOmxhbmd1YWdlPjxtZXRhOmVkaXRpbmctY3lj bGVzPjI8L21ldGE6ZWRpdGluZy1jeWNsZXM+PG1ldGE6ZWRpdGluZy1kdXJhdGlvbj5QVDE4TTQ5 UzwvbWV0YTplZGl0aW5nLWR1cmF0aW9uPjxtZXRhOnVzZXItZGVmaW5lZCBtZXRhOm5hbWU9Iklu Zm8gMSIvPjxtZXRhOnVzZXItZGVmaW5lZCBtZXRhOm5hbWU9IkluZm8gMiIvPjxtZXRhOnVzZXIt ZGVmaW5lZCBtZXRhOm5hbWU9IkluZm8gMyIvPjxtZXRhOnVzZXItZGVmaW5lZCBtZXRhOm5hbWU9 IkluZm8gNCIvPjxtZXRhOmRvY3VtZW50LXN0YXRpc3RpYyBtZXRhOnRhYmxlLWNvdW50PSIwIiBt ZXRhOmltYWdlLWNvdW50PSIyIiBtZXRhOm9iamVjdC1jb3VudD0iMCIgbWV0YTpwYWdlLWNvdW50 PSIxIiBtZXRhOnBhcmFncmFwaC1jb3VudD0iMTIiIG1ldGE6d29yZC1jb3VudD0iNzkiIG1ldGE6 Y2hhcmFjdGVyLWNvdW50PSI0MTUiLz48L29mZmljZTptZXRhPjwvb2ZmaWNlOmRvY3VtZW50LW1l dGE+UEsDBBQACAAIAJZQwTQAAAAAAAAAAAAAAAAMAAAAc2V0dGluZ3MueG1s7Vjdd6I4FH/fv8Ll dY8F7Uxbe1rngAq1H9YKYutbJLdKJyRsCKLz129AbacVZrsqe/ZhOceDITe/e3NzP3PxbRGQyhx4 5DN6qdSONKUC1GPYp9NLZeiY1TPlW/O3i9/b9y3nqd+psOdn34NzzLw4ACqqEQghaaNKf2jcdlsV paqq9yHQ+4zuiPGpqraddmU1bq+XVSQjVe30lIqyAjzCAivNi0J0KSWNzlfTl8pMiPBcVZnkw974 1DVNU1djZb1gQXz6/ZU+SZKj5DijrTUaDTWb3ZB6jD77019g19QVibLRwTutvcq+Ebl5sSJfA1d9 AUG6n8r6M0WB3Mnch+R1l0remvf0rqTXOSCHhcpmRixDOeNToTTrF+o2wudRb+FZ5MFq+8GOfCxm ueIe1xun+2FfgT+d5QpdO67VjncDt2csGQCW5gGtGaJTiD4wmDBGAFGlKXgMu/O4AoSBj2Y+AYOz JJJGUMToGZFoD04mY6J8Tl2agcMdw3AQ+GqAwqpPMSwAb59/vsNka2Tw4MvPWVEXfxA1EjxVTzP1 zT0cqsiZvtRO97D5Isf/enK6s5dG/oTAwX0/Qz10nMpAB0Uun8aTk72gDSYECw4cTsaMBY5E+mhn M8Z3V3AKaiJPMJ4PW9N2BO5GNhDwBGCTyw87+HHOx5+dsmh67ef5BDJHfi6jrgYxR0Lm5n+SWnWM +4gjB0kzsEPklRMi+zK2iAGktQN8DDyHwL+VJc0wxEjkBeGNaewGLVMhlwYHvMWCkEOUFj8HN+tM P7bUPYFrNinMu/ueQB+FwE3OAhtE/DFEHYxLGlP7qJTyIcPPbLUE8PSkhR4LtrKkkqRvMRkPGClL OcBzzxZFcPLF8CniS6UZT2//UDVMJoG7RKO76fDqOpzQAfGm+n/yGWrYdIhhu39POtL1O/nqZgNV PTN1yxjqevtsIsd20PAHlqk92fqiRQ2596/a+LHbGNTdePx4HT4tjQcvIDG23GUraMh5V/43NTRq xH3XmHt0sHwaEa0V9OaeRYj3Q5M4vZen0YL0nc7NZGQux3USjy3zT/zY0ybp+rYm7uzk7fcQvkzq i7kXSH1fDVjf6WpSlh8Ty62PR0njTn+bxwF5GTta0iLGw6DTm6dnBJ3BDFudm6Fl0rHbCyEYnjiW q6Uyl3oI/z//5nO5RwjQKWUiKwSKk+GOeUoPQ7IcRsDbSKDDRzDTB4LLjMA2moO7usC4py3CosM0 bNtMLMImiGwuftLypIyk3o1ugFM98hHtx9QTcXbqJTDSiT+lMu/agoV9FvklsWnFnEt1pcaVZqz0 bbOYe1tGvOpV1U/nxN52Sb/pdy2gwH2vsqbcw+9MtCjm81lZsy6vpOopp9bXhS1k1VNawclZFMqu qix8i6Nw5ntlFIPvTVEW/wGiOKfw3+e6YF2UT8FA3vcpZzEtbI4OvZP9rLTNUZI1mOUUsQaR+jBl obxL0Czso9Wtu2q16Oa9+RdQSwcIYIjI8FgEAAAiGAAAUEsDBBQACAAIAJZQwTQAAAAAAAAAAAAA AAAVAAAATUVUQS1JTkYvbWFuaWZlc3QueG1svZNRa8IwEMff9ymyvDfXqMMhVlGrMNimD/qwx9Be a6BNQ3M6/faLY1VBYThkeblcuPv9/+G4/nBXFmyLtdOVibgUIWdokirVJo/4ajkLnvlw8NB/jOeT 5cdiykpldIaOes2FLVbj15cJ4wHA3KKZZ5lOUFR1DhAvY/bW1Hk2wPSdM948iZRS7uGXTG/KuGMa 8TWR7QFUnl+d+K0wlNAUeRA7kTJdYICG6v2ZY0y1CmhvMeLK2kInivyvYWtS4TZGeFHxWWvCmp+a sk1RBFbROuLA4SYNXaocwZr8Om6hE9rU6ECG/rTC7xDKdvcnduJpu9UdybY4IP5FutNYGI2f5Kg7 k3+Q/kXxRhrhjsAP5jo1qQz55sPk7sp1tC/Q3R1bIqn7e0Uiv6xHt324WKfBF1BLBwhaFbNOMAEA AOYDAABQSwECFAAUAAAAAACWUME0gJBrfpsbAACbGwAALQAAAAAAAAAAAAAAAAAAAAAAUGljdHVy ZXMvMTAwMDAyMDEwMDAwMDEzNzAwMDAwMTM0REUzMjdBMTMucG5nUEsBAhQAFAAAAAAAllDBNLas V216HwAAeh8AAC0AAAAAAAAAAAAAAAAA5hsAAFBpY3R1cmVzLzEwMDAwMjAxMDAwMDAxMzQwMDAw MDEzN0FCNTFBN0YxLnBuZ1BLAQIUABQACAAIAJZQwTRWsvvJhAQAAJ8OAAALAAAAAAAAAAAAAAAA AKs7AABjb250ZW50LnhtbFBLAQIUABQACAAIAJZQwTRU/D0cAAUAAFMTAAAKAAAAAAAAAAAAAAAA AGhAAABzdHlsZXMueG1sUEsBAhQAFAAAAAAAllDBNIG7Q2liBAAAYgQAAAgAAAAAAAAAAAAAAAAA oEUAAG1ldGEueG1sUEsBAhQAFAAIAAgAllDBNGCIyPBYBAAAIhgAAAwAAAAAAAAAAAAAAAAAKEoA AHNldHRpbmdzLnhtbFBLAQIUABQACAAIAJZQwTRaFbNOMAEAAOYDAAAVAAAAAAAAAAAAAAAAALpO AABNRVRBLUlORi9tYW5pZmVzdC54bWxQSwUGAAAAAAcABwDaAQAALVAAAAAA --=-k0bJJnk7Qaq1V0+G97NB-- --0-596188450-1149245335=:1049-- From kris@babi-pangang.org Fri Jun 2 07:03:22 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 7783B3B03DE for ; Fri, 2 Jun 2006 07:03:22 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20299-05 for ; Fri, 2 Jun 2006 07:03:21 -0400 (EDT) Received: from nasi-goreng.babi-pangang.org (nasi-goreng.babi-pangang.org [83.166.137.20]) by menubar.gnome.org (Postfix) with ESMTP id 0CC793B0196 for ; Fri, 2 Jun 2006 07:03:20 -0400 (EDT) Received: by nasi-goreng.babi-pangang.org (Postfix, from userid 1000) id 417E73DCA0; Fri, 2 Jun 2006 13:03:18 +0200 (CEST) Date: Fri, 2 Jun 2006 13:03:17 +0200 From: Kristian Rietveld To: Tim Janik Message-ID: <20060602110317.GA10757@babi-pangang.org> References: <20060314132538.GA3526@babi-pangang.org> <443B4A8A.8000302@imendio.com> <20060425103017.GA15762@babi-pangang.org> <20060531183045.GA7564@babi-pangang.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.563 tagged_above=-999 required=2 tests=[AWL=0.036, BAYES_00=-2.599] X-Spam-Score: -2.563 X-Spam-Level: Cc: Gtk+ Developers , Soeren Sandmann Subject: Re: Callback based tooltips (Re: New tooltips API, continued) X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 11:03:22 -0000 On Thu, Jun 01, 2006 at 05:16:51PM +0200, Tim Janik wrote: > On Wed, 31 May 2006, Kristian Rietveld wrote: > > >On Tue, Apr 25, 2006 at 03:08:12PM +0200, Soeren Sandmann wrote: > >>I once wrote down how tooltips should behave: > > > >I mostly like the behaviour you described below. > > > >> - Tooltips are too intrusive. The text should be smaller, and > > not sure if this has been raised already... > the font size of the tooltips should be exactly as large as the default > font size (module tooltip markup of course) to avoid reducing usability > of the tooltips in contrast to normal text (labels). The text for default/simple tooltips using toolip-markup are drawn using the default GTK+ font at this point. FireFox does this too, it seems. -kris. From lists@nabble.com Fri Jun 2 07:11:06 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 15ADC3B10CE for ; Fri, 2 Jun 2006 07:11:06 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20935-09 for ; Fri, 2 Jun 2006 07:11:04 -0400 (EDT) Received: from talk.nabble.com (www.nabble.com [72.21.53.35]) by menubar.gnome.org (Postfix) with ESMTP id 7B8A53B0E85 for ; Fri, 2 Jun 2006 07:11:04 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=talk.nabble.com) by talk.nabble.com with esmtp (Exim 4.50) id 1Fm7YV-00067i-S9 for gtk-devel-list@gnome.org; Fri, 02 Jun 2006 04:11:03 -0700 Message-ID: <4677819.post@talk.nabble.com> Date: Fri, 2 Jun 2006 04:11:03 -0700 (PDT) From: heavenscape To: gtk-devel-list@gnome.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-Sender: masonduan1@sina.com X-Nabble-From: heavenscape X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.564 tagged_above=-999 required=2 tests=[AWL=0.037, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.564 X-Spam-Level: Subject: strange trouble in displaying a 8bit monochromy grey scale image X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 11:11:06 -0000 I need to display a 8 bit monochromy image with size of 2048x2048 pixels, all the image data are already loaded into memory, and out of which I created a 24 bit RGB buffer for the GdkPixbuf (please see code below) Well, the result is: The GtkImage widget was expanded to size of 2048x2048 pixels, THREE exactly same images tile in a row in the top of the GtkImage widget, each with size shrinked to 684x684 pixels, and all the lower 2/3 space is left blank.(see the attached image below) Can anyone please look at my code and give me some suggestion on this problem? I have been debugging is problem for almost one week time! Or I wonder if there is any other alternative mean to display a grey scale monochromy image. Any help is highly appriciated! following is my code: ...... char* pDisplayBuf = malloc(sizeX*sizeY*3); for(i=0;i X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 129D43B0401 for ; Fri, 2 Jun 2006 07:42:43 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22729-02 for ; Fri, 2 Jun 2006 07:42:41 -0400 (EDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.204]) by menubar.gnome.org (Postfix) with ESMTP id AACEB3B03DC for ; Fri, 2 Jun 2006 07:42:41 -0400 (EDT) Received: by wx-out-0102.google.com with SMTP id i30so488730wxd for ; Fri, 02 Jun 2006 04:42:41 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=gT1j5ejSD/b/CcxQn0QQsSvUHhFufm/g+0pbZR2i/XzGfNpGoCbQpb21JCQ8031mkn0Ki6u8pLPOMj7RR8l3DAglKtDDYSYHma6DaM5dCPwAcVKD9bRfW3lU8+yvbKvGFEapsCpgbG/Y1Pe5Z3GQWmSp7m88CvcAjjuc1aYqX10= Received: by 10.70.62.1 with SMTP id k1mr2290069wxa; Fri, 02 Jun 2006 04:42:41 -0700 (PDT) Received: by 10.70.96.6 with HTTP; Fri, 2 Jun 2006 04:42:40 -0700 (PDT) Message-ID: <522c6460606020442q5704285jefadb260aa5ceda1@mail.gmail.com> Date: Fri, 2 Jun 2006 12:42:40 +0100 From: "John Cupitt" To: heavenscape In-Reply-To: <4677819.post@talk.nabble.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4677819.post@talk.nabble.com> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.554 tagged_above=-999 required=2 tests=[AWL=0.046, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.554 X-Spam-Level: Cc: gtk-devel-list@gnome.org Subject: Re: strange trouble in displaying a 8bit monochromy grey scale image X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 11:42:43 -0000 On 6/2/06, heavenscape wrote: > char* pDisplayBuf = malloc(sizeX*sizeY*3); > for(i=0;i { > //create a gray scale img in the display buffer > pDisplayBuf[i+1]=pDisplayBuf[i+1]=pDisplayBuf[i+2] = pixel_value; > } This isn't going to work. You're only filling the first third of the memory area. How about (untested): // malloc() can return NULL: you need to test the result // g_malloc() cannot fail char *p = g_malloc(sizeX * sizeY * 3); char *q; int i; // i loops for number of pixels // q loops pointing at each RGB triplet in turn for (q = p, i = 0; i < sizeX * sizeY; i++, q += 3) q[0] = q[1] = q[2] = pixel_value; // or alternatively in this special case memset( p, sizeX * sizeY * 3, pixel_value ) From jcupitt@gmail.com Fri Jun 2 07:44:31 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C18CD3B0402 for ; Fri, 2 Jun 2006 07:44:31 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22729-06 for ; Fri, 2 Jun 2006 07:44:30 -0400 (EDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.202]) by menubar.gnome.org (Postfix) with ESMTP id 8F0073B0413 for ; Fri, 2 Jun 2006 07:44:30 -0400 (EDT) Received: by wx-out-0102.google.com with SMTP id i30so489124wxd for ; Fri, 02 Jun 2006 04:44:29 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=EMOfucJIundQbGeCrVxW4fD6Iz3tUALWFaW8hgWFjuzmGzy3HlOTtgzn8QGVrywRA62j6kzikELTcAJL+GvTNGqGag3vtyJIcBhy5nQKUdv8v5Gm6dzT8SPDVoRKsWY874GU5fTfTuEc6cSK5TYAaWH6Ezj7csUQ73y/uo1NF/8= Received: by 10.70.128.5 with SMTP id a5mr2255574wxd; Fri, 02 Jun 2006 04:44:29 -0700 (PDT) Received: by 10.70.96.6 with HTTP; Fri, 2 Jun 2006 04:44:29 -0700 (PDT) Message-ID: <522c6460606020444q6963f934g8d7b671fb87905b0@mail.gmail.com> Date: Fri, 2 Jun 2006 12:44:29 +0100 From: "John Cupitt" To: heavenscape In-Reply-To: <522c6460606020442q5704285jefadb260aa5ceda1@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4677819.post@talk.nabble.com> <522c6460606020442q5704285jefadb260aa5ceda1@mail.gmail.com> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.555 tagged_above=-999 required=2 tests=[AWL=0.045, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.555 X-Spam-Level: Cc: gtk-devel-list@gnome.org Subject: Re: strange trouble in displaying a 8bit monochromy grey scale image X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 11:44:31 -0000 On 6/2/06, John Cupitt wrote: > memset( p, sizeX * sizeY * 3, pixel_value ) Ahem, of course that should be memset (p, pixel_value, sizeX * sizeY * 3); From cerdiogenes@yahoo.com.br Fri Jun 2 09:09:23 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id BD1CF3B03D8 for ; Fri, 2 Jun 2006 09:09:23 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27976-05 for ; Fri, 2 Jun 2006 09:09:21 -0400 (EDT) Received: from cac-bdc03.unioeste.br (pop3.unioeste.br [200.201.8.21]) by menubar.gnome.org (Postfix) with ESMTP id 8FFCD3B0351 for ; Fri, 2 Jun 2006 09:09:20 -0400 (EDT) Received: from [200.201.81.39] (200.201.81.39 [200.201.81.39]) by cac-bdc03.unioeste.br with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id L71GDA45; Fri, 2 Jun 2006 10:07:46 -0300 From: Carlos Eduardo Rodrigues =?ISO-8859-1?Q?Di=F3genes?= To: =?ISO-8859-1?Q?=D8yvind_Kol=E5s?= In-Reply-To: <7bf6f2dc0606010816q15d512aejc30a6c93bc165e6@mail.gmail.com> References: <1149104973.27709.4.camel@localhost.localdomain> <7bf6f2dc0606010816q15d512aejc30a6c93bc165e6@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Date: Fri, 02 Jun 2006 10:01:52 -0300 Message-Id: <1149253312.4847.21.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.221 tagged_above=-999 required=2 tests=[AWL=0.043, BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.221 X-Spam-Level: Cc: gtk-devel-list@gnome.org Subject: Re: Color space transformations in GTK X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 13:09:23 -0000 On Thu, 2006-06-01 at 17:16 +0200, =D8yvind Kol=E5s wrote: > On 5/31/06, Carlos Eduardo Rodrigues Di=F3genes wrote: > > Hi, > > > > There is any plan to add color spaces conversions in GTK+ (GDK or > > Gdk-Pixbuf)? If the answear is no, why not? >=20 > Pixel format conversions is not a small piece of code and the needed > pixel formats varies from scenario to scenario. Most programs will not > need such a large general infrastructure and the ones that really need > it would probably not be satisfied with a simpler solution. I think that I understand your last argument. And what I really have in mind is a simple solution, more below... >=20 > What functionality is it you miss that you think fits into a GUI > toolkit? (color management is a seperate issue to color space(pixel > format) conversions according to my interpretation of your question). I had to make RGB <-> HSL conversions, because it's more intuitive change some color properties in the HSL color space. I thinked that we could have something like GdkColor for other color spaces and functions to convert between GdkColor and the other color spaces. I think that it will help who want to play with colors in a quick way. I don't find this in any other library, and I thinked that GTK+ could be a good place for this, because it will become easiest to work with other colors representations in GTK+ applications. >=20 > /=D8yvind K. --=20 Carlos Eduardo Rodrigues Di=F3genes Projeto xLupa - http://www.unioeste.br/projetos/xlupa From murrayc@murrayc.com Fri Jun 2 09:28:59 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id A768B3B112B for ; Fri, 2 Jun 2006 09:28:59 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28843-09 for ; Fri, 2 Jun 2006 09:28:58 -0400 (EDT) Received: from webmail1.sd.dreamhost.com (webmail1.sd.dreamhost.com [66.33.201.159]) by menubar.gnome.org (Postfix) with ESMTP id 953E83B111A for ; Fri, 2 Jun 2006 09:28:58 -0400 (EDT) Received: from webmail.murrayc.com (localhost [127.0.0.1]) by webmail1.sd.dreamhost.com (Postfix) with ESMTP id 9A66F2CAF2; Fri, 2 Jun 2006 06:23:41 -0700 (PDT) Received: from 194.138.18.132 (proxying for unknown) (SquirrelMail authenticated user murrayc@murrayc.com) by webmail.murrayc.com with HTTP; Fri, 2 Jun 2006 15:23:41 +0200 (CEST) Message-ID: <1464.194.138.18.132.1149254621.squirrel@webmail.murrayc.com> In-Reply-To: <1149253312.4847.21.camel@localhost.localdomain> References: <1149104973.27709.4.camel@localhost.localdomain> <7bf6f2dc0606010816q15d512aejc30a6c93bc165e6@mail.gmail.com> <1149253312.4847.21.camel@localhost.localdomain> Date: Fri, 2 Jun 2006 15:23:41 +0200 (CEST) From: "Murray Cumming" To: Carlos Eduardo Rodrigues =?iso-8859-1?Q?Di=F3genes?= User-Agent: SquirrelMail/1.4.6 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.481 tagged_above=-999 required=2 tests=[AWL=-0.036, BAYES_00=-2.599, TW_GT=0.077, TW_TK=0.077] X-Spam-Score: -2.481 X-Spam-Level: Cc: gtk-devel-list@gnome.org, =?iso-8859-1?Q?=D8yvind_Kol=E5s?= Subject: Re: Color space transformations in GTK X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 13:28:59 -0000 > On Thu, 2006-06-01 at 17:16 +0200, yvind Kols wrote: >> On 5/31/06, Carlos Eduardo Rodrigues Digenes >> wrote: >> > Hi, >> > >> > There is any plan to add color spaces conversions in GTK+ (GDK or >> > Gdk-Pixbuf)? If the answear is no, why not? >> >> Pixel format conversions is not a small piece of code and the needed >> pixel formats varies from scenario to scenario. Most programs will not >> need such a large general infrastructure and the ones that really need >> it would probably not be satisfied with a simpler solution. > > I think that I understand your last argument. And what I really have in > mind is a simple solution, more below... > >> >> What functionality is it you miss that you think fits into a GUI >> toolkit? (color management is a seperate issue to color space(pixel >> format) conversions according to my interpretation of your question). > > I had to make RGB <-> HSL conversions, because it's more intuitive > change some color properties in the HSL color space. I thinked that we > could have something like GdkColor for other color spaces and functions > to convert between GdkColor and the other color spaces. > > I think that it will help who want to play with colors in a quick way. I > don't find this in any other library, and I thinked that GTK+ could be a > good place for this, because it will become easiest to work with other > colors representations in GTK+ applications. In case it's useful, we have some old undocumented RGB <-> HSL color value conversion code in gtkmm here: http://cvs.gnome.org/viewcvs/gtkmm/gdk/src/color.ccg?view=markup (See set_hsl(), for instance) Murray Cumming murrayc@murrayc.com www.murrayc.com www.openismus.com From timj@gtk.org Fri Jun 2 10:28:42 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 270163B043C for ; Fri, 2 Jun 2006 10:28:42 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32586-01 for ; Fri, 2 Jun 2006 10:28:40 -0400 (EDT) Received: from webmail.hansenet.de (mail04.hansenet.de [213.191.73.12]) by menubar.gnome.org (Postfix) with ESMTP id 4C4283B0272 for ; Fri, 2 Jun 2006 10:28:40 -0400 (EDT) Received: from birnet.org (213.39.189.161) by webmail.hansenet.de (7.2.059) id 447C34F100154F1E; Fri, 2 Jun 2006 16:28:37 +0200 Received: from master.birnet.private (localhost [127.0.0.1]) by birnet.org (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k52ESaZY028846 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 2 Jun 2006 16:28:36 +0200 Received: (from timj@localhost) by master.birnet.private (8.13.4/8.13.4/Submit) id k52ESPMh028844; Fri, 2 Jun 2006 16:28:25 +0200 Date: Fri, 2 Jun 2006 16:28:25 +0200 (CEST) From: Tim Janik X-X-Sender: timj@master.birnet.private To: Stefan Kost In-Reply-To: <1148567274.9054.4.camel@fluffy.local> Message-ID: References: <1148567274.9054.4.camel@fluffy.local> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.442 tagged_above=-999 required=2 tests=[AWL=0.157, BAYES_00=-2.599] X-Spam-Score: -2.442 X-Spam-Level: Cc: Gtk+ Developers Subject: Re: Serialization in libgobject X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 14:28:42 -0000 On Thu, 25 May 2006, Stefan Kost wrote: > Hi Tim, > > thanks for the extensive comments and detailed concerns. Don't you think > it would be good to keep the buzzgilla issue open. Its an enhancement > request after all and there seems to be several people wanting to have > it. well, my concern is that most of them want/think different things about serialization which was the main point of my last email. i.e. if you want to cover beast's serialization need, you already need 2 different serializers. if you then also want to cover GStreamer needs, and maybe properly human digestible config files, you can easily end up with 3 or 4 sets of mutually exclusive requirements. so without precise definition of the usage cases: - the exact required behaviour of a GLib serializer isn't clear; - we'll end up with lots of projects still rolling their own serializer because the glib one doesn't cover their needs; - the serializer will be used in scenarios that it's unplanned and suboptimal for. i'm not saying the technical issues i raised are unsolvable, in fact each one has been adressed in one way or the other in beast's serializers. rather, i'm asking: 1) what exactly do we want in glib? (i.e. which use cases should be covered) 2) which use cases should be rejected by the glib implementation(s)? 3) do the answers to (1) and (2) really cover a broad range of serialization applications out there? and i think one of the best way to be sure and positively answer (3) could be the independent development of a serialization lib outside of glib. such a library could be included into glib at a later point, once its mature enough and has an adequate track record of applications. > The bugzilla issue could serve as a tracker item. And now maybe some > more people know about thsi and add their thoughts and ideas. if you still think this should be tracked in glib bugzilla as an enhancement, you can always reopen the report. > @Andrew: is you implementation public? If so where can I find the > sources, if not can you make the serialisation part public? > > Maybe we can find a SoC student for the next summer to look at the > solutions used in our application as come up with a good proposal that > suites most apps. > > Stefan > --- ciaoTJ From timj@gtk.org Fri Jun 2 12:59:30 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id AFEC23B0140 for ; Fri, 2 Jun 2006 12:59:30 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09573-08 for ; Fri, 2 Jun 2006 12:59:29 -0400 (EDT) Received: from webmail.hansenet.de (mail01.hansenet.de [213.191.73.61]) by menubar.gnome.org (Postfix) with ESMTP id 53B8C3B00A5 for ; Fri, 2 Jun 2006 12:59:29 -0400 (EDT) Received: from birnet.org (213.39.189.161) by webmail.hansenet.de (7.2.059) id 447D3FB2000A3052; Fri, 2 Jun 2006 18:59:16 +0200 Received: from master.birnet.private (localhost [127.0.0.1]) by birnet.org (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k52GxEAY001423 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 2 Jun 2006 18:59:14 +0200 Received: (from timj@localhost) by master.birnet.private (8.13.4/8.13.4/Submit) id k52GxETr001415; Fri, 2 Jun 2006 18:59:14 +0200 Date: Fri, 2 Jun 2006 18:59:13 +0200 (CEST) From: Tim Janik X-X-Sender: timj@master.birnet.private To: Owen Taylor Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.445 tagged_above=-999 required=2 tests=[AWL=0.154, BAYES_00=-2.599] X-Spam-Score: -2.445 X-Spam-Level: Cc: Gtk+ Developers Subject: locking around source_funcs->finalize X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 16:59:30 -0000 hi Owen. reading up on g_source_unref() again, i notice that the GMainContext lock is removed and re-acquired around callback_funcs->unref(), but not around source_funcs->finalize(); supposing you're unlocking around unref() so that the handler may do things like adding a new idle handler to the context, shouldnt the same semantics be provided for source_funcs->finalize() as well? > static void > g_source_unref_internal (GSource *source, > GMainContext *context, > gboolean have_lock) > { > gpointer old_cb_data = NULL; > GSourceCallbackFuncs *old_cb_funcs = NULL; > > g_return_if_fail (source != NULL); > > if (!have_lock && context) > LOCK_CONTEXT (context); > > source->ref_count--; > if (source->ref_count == 0) > { > old_cb_data = source->callback_data; > old_cb_funcs = source->callback_funcs; > > source->callback_data = NULL; > source->callback_funcs = NULL; > > if (context && !SOURCE_DESTROYED (source)) > { > g_warning (G_STRLOC ": ref_count == 0, but source is still attached to a context!"); > source->ref_count++; > } > else if (context) > g_source_list_remove (source, context); > > if (source->source_funcs->finalize) > source->source_funcs->finalize (source); lock is being held if have_lock || context. > > g_slist_free (source->poll_fds); > source->poll_fds = NULL; > g_free (source); > } > > if (!have_lock && context) > UNLOCK_CONTEXT (context); > > if (old_cb_funcs) > { > if (have_lock) > UNLOCK_CONTEXT (context); > > old_cb_funcs->unref (old_cb_data); no lock is being held. > > if (have_lock) > LOCK_CONTEXT (context); > } > } --- ciaoTJ From matthias.clasen@gmail.com Fri Jun 2 13:14:22 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 181063B0178 for ; Fri, 2 Jun 2006 13:14:22 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10341-10 for ; Fri, 2 Jun 2006 13:14:21 -0400 (EDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.188]) by menubar.gnome.org (Postfix) with ESMTP id A84F33B0115 for ; Fri, 2 Jun 2006 13:14:20 -0400 (EDT) Received: by nf-out-0910.google.com with SMTP id l37so1131753nfc for ; Fri, 02 Jun 2006 10:14:19 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=IIiw0EjBJce9nDArNbjwYFffpCUCNPuYeqI8uOIN+ycf/KtiNjAY9VtWweGXWApORefDRcNkzdsGRROn1FJvCDC494mL9vZcz0WpDA5tNFO1IZSXHXsfZPz+YqQUJ6orpi6MA7hmCcT7pTYK8vEfd8Pic7cApyoegcqYqJXL1U8= Received: by 10.49.1.9 with SMTP id d9mr941927nfi; Fri, 02 Jun 2006 10:14:19 -0700 (PDT) Received: by 10.48.215.7 with HTTP; Fri, 2 Jun 2006 10:14:19 -0700 (PDT) Message-ID: Date: Fri, 2 Jun 2006 13:14:19 -0400 From: "Matthias Clasen" To: "Tim Janik" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.699 tagged_above=-999 required=2 tests=[AWL=-0.734, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.558, SPF_PASS=-0.001, TW_GT=0.077] X-Spam-Score: -1.699 X-Spam-Level: Cc: Owen Taylor , Gtk+ Developers Subject: Re: locking around source_funcs->finalize X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 17:14:22 -0000 On 6/2/06, Tim Janik wrote: > hi Owen. > > reading up on g_source_unref() again, i notice that the > GMainContext lock is removed and re-acquired around > callback_funcs->unref(), but not around source_funcs->finalize(); > supposing you're unlocking around unref() so that the > handler may do things like adding a new idle handler > to the context, shouldnt the same semantics be provided > for source_funcs->finalize() as well? > Interesting observation Tim. We actually ran into a deadlock in the gtk print module code where a source finalize function was trying to add another idle... So fixing this would help GTK+; it would allow us to unload the print backends. Matthias From matthias.clasen@gmail.com Fri Jun 2 13:22:11 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id B05EA3B01BA for ; Fri, 2 Jun 2006 13:22:11 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10854-10 for ; Fri, 2 Jun 2006 13:22:10 -0400 (EDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.186]) by menubar.gnome.org (Postfix) with ESMTP id 691F63B007B for ; Fri, 2 Jun 2006 13:22:10 -0400 (EDT) Received: by nf-out-0910.google.com with SMTP id l37so1137364nfc for ; Fri, 02 Jun 2006 10:22:09 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=WQtzpP4N8ZyKSiiDfpj/VtLI/AxhPsWp029H1Nvd+SG7mq6Rf64PWWm4vH8TCDmIyieOgUdMr0+Y64igzWX+Liq5FKe/p14IvHTVc7Jf8A3g/lkQrbeGGqzHTAEGhQsu+lwlvRhqNYJVH8XXuOcmjrJxkEXrBrcqWzQyQ9CuNTg= Received: by 10.48.14.19 with SMTP id 19mr950281nfn; Fri, 02 Jun 2006 10:22:09 -0700 (PDT) Received: by 10.48.215.7 with HTTP; Fri, 2 Jun 2006 10:22:09 -0700 (PDT) Message-ID: Date: Fri, 2 Jun 2006 13:22:09 -0400 From: "Matthias Clasen" To: "Petr Tomasek" In-Reply-To: <20060602070042.GA3470@ebed.etf.cuni.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1149203639.27455.9.camel@localhost.localdomain> <20060602070042.GA3470@ebed.etf.cuni.cz> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.733 tagged_above=-999 required=2 tests=[AWL=-0.691, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.558, SPF_PASS=-0.001] X-Spam-Score: -1.733 X-Spam-Level: Cc: gtk-devel-list@gnome.org Subject: Re: Print preview api X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 17:22:11 -0000 On 6/2/06, Petr Tomasek wrote: > On Thu, Jun 01, 2006 at 07:13:59PM -0400, Matthias Clasen wrote: > > Ok, after a lot of work (mostly by John and Alex), > > we finally have a proposal for a print preview > > api that will allow us to use an external viewer > > by default, but also support internal preview. > > Hi! > > I think, this is very unfortunate. Many people will > not want to use the external viewer (for reasons discused > earlier), so everyone will write his own preview > widget? Why not just have official internal > preview widget like gnome-print has and support > it by deafult? You are more than welcome to on a high-quality print preview widget and propse it for inclusion; it is a considerable amount of work though (duplicating things that are already in evince), and we are not going to hold the 2.10 release for it. Defaulting to external preview allows us to release 2.10 with preview support, which seems better than no preview support at all. In other news, Alex has just committed the preview patch with some fixes. Matthias From kris@babi-pangang.org Fri Jun 2 19:04:03 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 6F8D73B051E for ; Fri, 2 Jun 2006 19:04:03 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29568-08 for ; Fri, 2 Jun 2006 19:04:02 -0400 (EDT) Received: from nasi-goreng.babi-pangang.org (nasi-goreng.babi-pangang.org [83.166.137.20]) by menubar.gnome.org (Postfix) with ESMTP id 2B5243B04C8 for ; Fri, 2 Jun 2006 19:04:01 -0400 (EDT) Received: by nasi-goreng.babi-pangang.org (Postfix, from userid 1000) id BC1643DCA0; Sat, 3 Jun 2006 01:03:59 +0200 (CEST) Date: Sat, 3 Jun 2006 01:03:59 +0200 From: Kristian Rietveld To: Matthias Clasen Message-ID: <20060602230359.GB10757@babi-pangang.org> References: <20060531200823.GA7846@babi-pangang.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.525 tagged_above=-999 required=2 tests=[AWL=-0.003, BAYES_00=-2.599, TW_GT=0.077] X-Spam-Score: -2.525 X-Spam-Level: Cc: gtk-devel-list@gnome.org, timj@imendio.com Subject: Re: Tooltips progress X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 23:04:03 -0000 On Thu, Jun 01, 2006 at 09:33:48AM -0400, Matthias Clasen wrote: > Using x == -1 to indicate a keyboard-triggered tooltip looks a bit > odd to me; how about adding a boolean parameter for this ? Good idea, fixed this. > Regarding dedicated treeview api, I think we can do without it > (at least initially), if we have a good example in the docs. Though > lots of people will forget the selection_changed thing for keyboard > tooltips... I'll make sure some nice example code will appear in gtk-demo, where we can point people at. > Could you enhance your demo with an example of text view > tooltips on a tag ? Will do. -kris. From kris@babi-pangang.org Fri Jun 2 19:08:42 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 1CF883B11C6 for ; Fri, 2 Jun 2006 19:08:42 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29930-06 for ; Fri, 2 Jun 2006 19:08:40 -0400 (EDT) Received: from nasi-goreng.babi-pangang.org (nasi-goreng.babi-pangang.org [83.166.137.20]) by menubar.gnome.org (Postfix) with ESMTP id 89C933B11CD for ; Fri, 2 Jun 2006 19:08:40 -0400 (EDT) Received: by nasi-goreng.babi-pangang.org (Postfix, from userid 1000) id 411F73DCA0; Sat, 3 Jun 2006 01:08:37 +0200 (CEST) Date: Sat, 3 Jun 2006 01:08:37 +0200 From: Kristian Rietveld To: Tim Janik Message-ID: <20060602230837.GC10757@babi-pangang.org> References: <20060531200823.GA7846@babi-pangang.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.563 tagged_above=-999 required=2 tests=[AWL=0.036, BAYES_00=-2.599] X-Spam-Score: -2.563 X-Spam-Level: Cc: Gtk+ Developers Subject: Re: Tooltips progress X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 23:08:42 -0000 On Thu, Jun 01, 2006 at 06:21:29PM +0200, Tim Janik wrote: > On Thu, 1 Jun 2006, Matthias Clasen wrote: > the idea behind ::has-tooltip is to reduce the number of required signal > emissions to figure a tooltip. e.g. by adding a PRIVATE_GTK_* flag that > indicates if the ::query-tooltips() emission is neccessary. > maybe it'd helpt to rename that property to ::can-tooltip? Or maybe ::enable-query-tooltip? > (if you want to argue consistency with other things settable/gettable > on widgets though, then yes, you have a point for also exporting it > as a property) I would tend to add the property just for consistency. > >The example doesn't show tooltips constructed using the old tooltips > >api, but I assume those will continue to work as before, right ? > > that was the plan, i.e. you'd basically just do: I am not 100% if we can implement the complete old API using the new one, for example the public fields in the old structures and GtkTipsQuery come to mind ... I'll investigate once I get a first patch out. -kris. From exe522@hotmail.com Mon Jun 5 10:30:49 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id E7BDF3B0420 for ; Mon, 5 Jun 2006 10:30:48 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06214-09 for ; Mon, 5 Jun 2006 10:30:45 -0400 (EDT) Received: from hotmail.com (bay104-f19.bay104.hotmail.com [65.54.175.29]) by menubar.gnome.org (Postfix) with ESMTP id 81AC13B030D for ; Mon, 5 Jun 2006 10:30:44 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 5 Jun 2006 07:30:43 -0700 Message-ID: Received: from 65.54.175.200 by by104fd.bay104.hotmail.msn.com with HTTP; Mon, 05 Jun 2006 14:30:41 GMT X-Originating-IP: [83.202.13.252] X-Originating-Email: [exe522@hotmail.com] X-Sender: exe522@hotmail.com In-Reply-To: <44747D3E.8020902@imendio.com> From: "Malik NakaMura" To: richard@imendio.com Date: Mon, 05 Jun 2006 14:30:41 +0000 Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed X-OriginalArrivalTime: 05 Jun 2006 14:30:43.0753 (UTC) FILETIME=[A0A49190:01C688AC] X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-0.739 tagged_above=-999 required=2 tests=[AWL=-1.535, BAYES_05=-1.11, DNS_FROM_RFC_ABUSE=0.2, DNS_FROM_RFC_POST=1.708, MSGID_FROM_MTA_HEADER=0, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -0.739 X-Spam-Level: Cc: otaylor@redhat.com, ben2004uk@googlemail.com, scott@asofyet.org, gtk-devel-list@gnome.org Subject: Re: GTK+ >> Cocoa Native Port X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2006 14:30:49 -0000 Hi, I'm trying to implement this function : _gdk_quartz_copy_to_image (gdkimage-quartz.c) I would like to know if it is possible to get the pixels table from a GdkPixmap structure ? this is the code : GdkImage * _gdk_quartz_copy_to_image (GdkDrawable *drawable, GdkImage *image, gint src_x, gint src_y, gint dest_x, gint dest_y, gint width, gint height) { /* FIXME: Implement */ // Image Creation image = g_object_new (gdk_image_get_type (), NULL); image->width = width; image->height = height; image->byte_order = (G_BYTE_ORDER == G_LITTLE_ENDIAN) ? GDK_LSB_FIRST : GDK_MSB_FIRST; image->bpp = 4; image->bpl = image->width * image->bpp; image->bits_per_pixel = image->bpp * 8; // Get the Visual GdkColormap *colormap = gdk_drawable_get_colormap (drawable); if(colormap != NULL) { image->visual = gdk_colormap_get_visual (colormap); } // Get the depth image->depth = GDK_PIXMAP_OBJECT (drawable)->depth; // Get the pixels ??? image->mem = g_malloc (image->bpl * image->height); memset (image->mem, 0x00, image->bpl * image->height); image->mem = gdk_pixbuf_get_pixels (GDK_PIXBUF (drawable)); return image; } I think that drawable is a GdkPixmap structure, so I cant do GDK_PIXBUF (drawable), but is there a function to get the pixbuf from a pixmap ? From domlachowicz@gmail.com Mon Jun 5 10:52:51 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id B05E13B0543 for ; Mon, 5 Jun 2006 10:52:51 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08008-05 for ; Mon, 5 Jun 2006 10:52:48 -0400 (EDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.205]) by menubar.gnome.org (Postfix) with ESMTP id 0DD8B3B03E7 for ; Mon, 5 Jun 2006 10:52:47 -0400 (EDT) Received: by wx-out-0102.google.com with SMTP id i30so1182797wxd for ; Mon, 05 Jun 2006 07:52:47 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=mBHtGZClxJk0twUjUBnjIyhM/WAD6Uo9my7i+D5hoC4J+tCoUbUHFxNQxrI4rHUN+ozS7wnRgFO+uMkkEg6Pg2xZje4D8Xja5Bt7lmKFvCh6pSZMS6uV+5TpBquvMmVoaoFkNDoZEDJjdLqt3Wj9IaLQ/ggRMyfDTkEaz5x0TcU= Received: by 10.70.49.6 with SMTP id w6mr6127550wxw; Mon, 05 Jun 2006 07:52:44 -0700 (PDT) Received: by 10.70.116.12 with HTTP; Mon, 5 Jun 2006 07:52:44 -0700 (PDT) Message-ID: <2672cf4d0606050752o12a6d0d2gcb4c355cc0f35d79@mail.gmail.com> Date: Mon, 5 Jun 2006 10:52:44 -0400 From: "Dominic Lachowicz" To: "Malik NakaMura" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <44747D3E.8020902@imendio.com> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.457 tagged_above=-999 required=2 tests=[AWL=0.143, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.457 X-Spam-Level: Cc: gtk-devel-list@gnome.org Subject: Re: GTK+ >> Cocoa Native Port X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2006 14:52:51 -0000 > I think that drawable is a GdkPixmap structure, so I cant do GDK_PIXBUF > (drawable), but is there a function to get the pixbuf from a pixmap ? You might want to look at gdk_pixbuf_get_from_drawable(). Best, Dom -- Counting bodies like sheep to the rhythm of the war drums. From mclasen@redhat.com Mon Jun 5 14:15:03 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 744343B09D3; Mon, 5 Jun 2006 14:15:03 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20278-06; Mon, 5 Jun 2006 14:15:01 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id D637E3B0988; Mon, 5 Jun 2006 14:15:00 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k55IF08I024331; Mon, 5 Jun 2006 14:15:00 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k55IF0I9021827; Mon, 5 Jun 2006 14:15:00 -0400 Received: from golem.boston.redhat.com (golem.boston.redhat.com [172.16.80.24]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id k55IExAV012588; Mon, 5 Jun 2006 14:14:59 -0400 From: Matthias Clasen To: gnome-announce-list@gnome.org, gtk-devel-list@gnome.org, gtk-app-devel-list@gnome.org, gtk-list@gnome.org Content-Type: text/plain; charset=UTF-8 Date: Mon, 05 Jun 2006 14:14:59 -0400 Message-Id: <1149531299.4071.35.camel@golem.boston.redhat.com> Mime-Version: 1.0 X-Mailer: Evolution 2.7.1 (2.7.1-1) Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.543 tagged_above=-999 required=2 tests=[AWL=0.058, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.543 X-Spam-Level: Cc: Subject: GLib 2.11.2 released X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gnome-hackers@gnome.org List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2006 18:15:03 -0000 GLib 2.11.2 is now available for download at: ftp://ftp.gtk.org/pub/gtk/v2.11/ http://ftp.gnome.org/pub/GNOME/sources/glib/2.11/ glib-2.11.2.tar.bz2 md5sum: 18464b85bfd589f83897623c637a1553 glib-2.11.2.tar.gz md5sum: f728cd295ac98d4b95d850fe91c05fd5 This is a development release leading up to GLib 2.12. Notes: * This is unstable development release. While it has had a bit of testing, there are certainly plenty of bugs remaining to be found. This release should not be used in production. * Installing this version will overwrite your existing copy of GLib 2.10. If you have problems, you'll need to reinstall GLib 2.10. * GLib 2.12 will be source and binary compatible with the GLib 2.10.x series (for some caveats, see the README). At this point, the API additions in the 2.11.x series are almost finished. * Bugs should be reported to http://bugzilla.gnome.org. About GLib ========== GLib is the low-level core library that forms the basis for projects such as GTK+ and GNOME. It provides data structure handling for C, portability wrappers, and interfaces for such runtime functionality as an event loop, threads, dynamic loading, and an object system. More information about GLib is available at: http://www.gtk.org/ An installation guide for the GTK+ libraries, including GLib, can be found at: http://developer.gnome.org/doc/API/2.0/gtk/gtk-building.html Overview of Changes from GLib 2.11.1 to GLib 2.11.2 =================================================== * Add g_ascii_stroll to parse signed 64bit integers * GMarkup: add a flag to treat CDATA as text * GHashTable: add functions to remove all entries * GMainLoop: add functions to find the currently running source, and determine if it is destroyed * Bug fixes: 342563 g_atomic_thread_init() needs to be called before other _g_*_thread_init() functions 343548 Potential use after free in callers of g_string_free() 168538 Wish: Clearing contents of GHashTables 321886 GTK+ cannot be reliably used in multi-threaded applications 341826 goption.c: 'strtoll' is C99's function 343899 g_ascii_formatd dosn't work as expected for all format strings 317793 Make GEnumValue strings const 337129 Compile warnings in G_IMPLEMENT_INTERFACE 303622 What is G_TYPE_CHAR? * Updated translations (bg,dz,eu,gl,ja,nl,th,vi) A list of all bugs fixed in this release can be found at: http://bugzilla.gnome.org/buglist.cgi?bug_id=341826,342563,343548,168538,168538,321886,343899,321886,317793,337129,303622 Thanks to everybody who has contributed to this release, in the form of bug reports or patches: Peter Kjellerstedt, Kazuki Iwamoto Leonard den Ottolander, Chris Wilson, Behdad Esfahbod, Matt Barnes, ystein Johansen, Tim Janik Morten Welinder Matthias Clasen June 5, 2006 From mclasen@redhat.com Mon Jun 5 16:21:34 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 09B113B0543; Mon, 5 Jun 2006 16:21:34 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28553-01; Mon, 5 Jun 2006 16:21:32 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id 0F8903B0012; Mon, 5 Jun 2006 16:21:31 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k55KLVn7006951; Mon, 5 Jun 2006 16:21:31 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k55KLUBq020469; Mon, 5 Jun 2006 16:21:31 -0400 Received: from golem.boston.redhat.com (golem.boston.redhat.com [172.16.80.24]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id k55KLUAV025318; Mon, 5 Jun 2006 16:21:30 -0400 From: Matthias Clasen To: gnome-announce-list@gnome.org, gtk-devel-list@gnome.org, gtk-app-devel-list@gnome.org, gtk-list@gnome.org Content-Type: text/plain Date: Mon, 05 Jun 2006 16:21:30 -0400 Message-Id: <1149538890.4071.40.camel@golem.boston.redhat.com> Mime-Version: 1.0 X-Mailer: Evolution 2.7.1 (2.7.1-1) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.429 tagged_above=-999 required=2 tests=[AWL=-0.059, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, TW_GD=0.077, TW_GT=0.077, TW_XI=0.077] X-Spam-Score: -2.429 X-Spam-Level: Cc: Subject: GTK+ 2.9.2 released X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gnome-hackers@gnome.org List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2006 20:21:34 -0000 GTK+ 2.9.2 is now available for download at: http://ftp.gnome.org/pub/gnome/sources/gtk+/2.9/ gtk+-2.9.2.tar.gz md5sum: c63e7d0cf7c4e983206c3088a0fb8862 gtk+-2.9.2.tar.bz2 md5sum: 17629437af44fce03485101371c8f041 This is a development release leading up to GTK+ 2.10. Notes: * This is unstable development release. There are certainly plenty of bugs remaining to be found. This release should not be used in production. * Installing this version will overwrite your existing copy of GTK+ 2.8. If you have problems, you'll need to reinstall GTK+ 2.8. * GTK+ 2.10 will be source compatible with the GTK+ 2.8 series; the new API additions in GTK+ 2.9.0 are not yet completely finalized, so there are likely incompatibilies between this release and the final 2.10 release. * The ABI version has been bumped from 2.4.0 to 2.10.0, since the filechooser backend interface has been changed. Third-party filechooser backends need to be ported to the new interface. Other third-party modules (input methods, image loaders, etc) just need to be reinstalled in the proper location for GTK+ to find them. * Remaining issues for GTK+ 2.10 can be found with following bugzilla query: http://bugzilla.gnome.org/buglist.cgi?product=gtk%2b&target_milestone=2.10+API+Freeze&target_milestone=2.10+Freeze&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED * Bugs should be reported to http://bugzilla.gnome.org. What is GTK+ ============ GTK+ is a multi-platform toolkit for creating graphical user interfaces. Offering a complete set of widgets, GTK+ is suitable for projects ranging from small one-off tools to complete application suites. GTK+ has been designed from the ground up to support a range of languages, not only C/C++. Using GTK+ from languages such as Perl and Python (especially in combination with the Glade GUI builder) provides an effective method of rapid application development. GTK+ is free software and part of the GNU Project. However, the licensing terms for GTK+, the GNU LGPL, allow it to be used by all developers, including those developing proprietary software, without any license fees or royalties. Where to get more information about GTK+ ======================================== Information about GTK+ including links to documentation can be found at: http://www.gtk.org/ An installation guide for GTK+ 2.x is found at: http://developer.gnome.org/doc/API/2.4/gtk/gtk-building.html Common questions: http://developer.gnome.org/doc/API/2.4/gtk/gtk-question-index.html http://www.gtk.org/faq/ Overview of Changes from GTK+ 2.9.1 to 2.9.2 ============================================ * GtkPrintOperation - Support asynchronous pagination with the ::paginate signal - Add gtk_print_operation_cancel - Support application-specific widgets - Allow disabling features based on application capabilities - Optionally show progress - Change some function names in GtkPrintContext to be longer and better - Support preview, the default implementation spawns evince, but the api allows for an internal preview implementation * GtkCellView - Add a model property * GtkStatusIcon - Allow to obtain screen geometry * GtkTreeView - Many bug fixes, in particular for RTL handling - Separate sensitive and selectable properties of rows - Optionally allow rubberband selection * GtkButton - Add image-spacing style property - Add image-position property * GtkToolButton - Add icon-spacing style property * Make GTK+ work as an untrused X client * Bugs fixed: 343838 gtkprintoperationpreview.h guards 305530 Crashes while creating source code w/GtkFontSelection 341327 Memory corruption inside glib 341734 cursor blocked to dnd mode after using shift and dnd on a GtkCalendar 343453 G_DEFINE_TYPE messes up internal typenames of GdkWindow and GdkPixmap 136571 Problems running as untrusted client 168105 the right edge tab does not appear when switching tab 172535 Add support for UI builders in gtk+ 302556 GtkTreeView widget signals are badly documented 324480 Selecting first item with keyboard is difficult 340428 small cleanup 340444 don't run the custom page size dialogue 340839 Critical warnings in GtkTreeModelFilter 341898 gtk_tree_view_insert_column_with_attributes doesn't work with fixed_height_mode 342003 DnD: Conditional jump or move depends on uninitialised value 342072 Wrong drop location in GtkEntry 342096 GtkImage animation CRITICALS on switching themes 342513 widget class style property with type module 342529 gdk should set resolution on PangoCairoFontmap, not PangoCairoContext 342535 Add documentation for new GtkWidget style properties (including Since tags) 342543 can't compile gtk+ on opensolaris using sun cc 342569 Typo in decl of gdk_color_parse 342752 Need a way to specify custom tab label for custom page in Print dialog 342754 print-editor: font button dialog doesn't get focus if main window has a window group 342781 GtkPrintUnixDialog: Collate should be insensitive unless Copies is > 1 342783 GtkPrintUnixDialog: Range textinput area should be insensitive unless range radiobutton is selected 342894 Use after free inside gtk_text_view_set_buffer 342930 GtkButton should offer a way to position the image relative to the text 343088 Some typos in the PO file 343425 "grab-notify"-signal is not correctly propagated for internal children 343438 gtk_color_button_set_color() doesn't emit "color-set" signal 343475 page setup unix dialog confusion 343625 allow to get only some info from gtk_status_icon_get_geometry 343677 GtkWindow chains key-release to key-press 320431 Text too close when using East/West in a GtkToolButton 321523 GtkTreeView's test_expand_row signal emitting impractical on row expand all 342007 Warning in gtk_paned_compute_position 343233 gdk_rectangle_intersect doc 333284 expander animation not working in RTL mode 343444 change color of gtk-demo source-buffer comment color from red to DodgerBlue 343630 Small inconsistence in migration documentation 80127 Rubberbanding for GtkTreeView 341450 status icon + libnotify 341679 Allow absolute filenames in the options entries * Updated translations (bg,cy,de,el,es,et,eu,gl,gu,it,ja, nb,nl,pt_BR,th,vi) Thanks to everybody who has contributed to this release, in the form of bug reports or patches: Alexander Larsson, Behdad Esfahbod, Benjamin Berg, Caolan McNamara, Carlos Garnacho Parro, Carol Spears, Christian Persch, Chris Wilson, Claudio Saavedra, Clytie Siddall, Damon Chaplin, Daniel Lindenaar, Dan Winship, Diana Fong, Ed Catmur, Emmanuele Bassi, Havoc Pennington, Henrique Romano, Hiroyuki Ikezoe, James Moger, Johan Dahlin, Kouhei Sutou, Kristian Rietveld, Markku Vire, Mart Raudsepp, Masatake Yamato, Michael Emmel, Michael Natterer, Murray Cumming, Olexiy Avramchenko, Paolo Borelli, Patrick Monnerat, Richard Hult, Sampo Savolainen, Sebastien Bacher, Srirama Sharma, Stefan Kost, Tim Janik, Tommi Komulainen, Tor Lillqvist, Yevgen Muntyan A list of all bugs fixed in this release can be found at: http://bugzilla.gnome.org/buglist.cgi?bug_id=342072,342096,342003,341734,305530,168105,342007,342529,342535,342543,342569,341679,342752,172535,342513,342781,342783,342754,136571,341450,333284,340428,340839,341898,321523,343088,343233,324480,342894,320431,342930,343453,343425,343438,343444,340444,343475,302556,343677,343625,80127,343838,341327,168105,343630 Matthias Clasen June 5, 2006 From otaylor@redhat.com Mon Jun 5 18:10:18 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 606843B039F for ; Mon, 5 Jun 2006 18:10:18 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03967-08 for ; Mon, 5 Jun 2006 18:10:17 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id CAF5C3B0389 for ; Mon, 5 Jun 2006 18:10:16 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k55MAGwn013331; Mon, 5 Jun 2006 18:10:16 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k55MAGNr013297; Mon, 5 Jun 2006 18:10:16 -0400 Received: from localhost.localdomain (sebastian-int.corp.redhat.com [172.16.52.221]) by devserv.devel.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k55MAFJC021457; Mon, 5 Jun 2006 18:10:15 -0400 From: Owen Taylor In-Reply-To: <2672cf4d0606050752o12a6d0d2gcb4c355cc0f35d79@mail.gmail.com> References: <44747D3E.8020902@imendio.com> <2672cf4d0606050752o12a6d0d2gcb4c355cc0f35d79@mail.gmail.com> Content-Type: text/plain Date: Mon, 05 Jun 2006 15:10:09 -0400 Message-Id: <1149534609.2441.107.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 (2.6.1-1.fc5.2) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.187 tagged_above=-999 required=2 tests=[AWL=-0.199, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.478, FORGED_RCVD_HELO=0.135, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.187 X-Spam-Level: Cc: gtk-devel-list@gnome.org Subject: Re: GTK+ >> Cocoa Native Port X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2006 22:10:18 -0000 On Mon, 2006-06-05 at 10:52 -0400, Dominic Lachowicz wrote: > > I think that drawable is a GdkPixmap structure, so I cant do GDK_PIXBUF > > (drawable), but is there a function to get the pixbuf from a pixmap ? > > You might want to look at gdk_pixbuf_get_from_drawable(). Not going to help here, I think .. copy_to_image() is the backend function used to implement gdk_pixbuf_get_from_drawable(). :-) This is the point in the code where you need to figure out how to copy pixels from a native drawable into an image buffer, which is going to involve native graphics system calls. If you can find docs on how to take a screenshot of a window in OS X, that will be similar code to what is needed here. Owen From rpmcruz@clix.pt Mon Jun 5 21:41:34 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id B9E363B03FB for ; Mon, 5 Jun 2006 21:41:34 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15260-05 for ; Mon, 5 Jun 2006 21:41:33 -0400 (EDT) Received: from mailrly02.isp.novis.pt (mailrly02.isp.novis.pt [195.23.133.212]) by menubar.gnome.org (Postfix) with ESMTP id 84DA33B0076 for ; Mon, 5 Jun 2006 21:41:32 -0400 (EDT) Received: (qmail 21302 invoked from network); 6 Jun 2006 01:41:30 -0000 Received: from unknown (HELO mailfrt04.isp.novis.pt) ([195.23.133.196]) (envelope-sender ) by mailrly02.isp.novis.pt with compressed SMTP; 6 Jun 2006 01:41:30 -0000 Received: (qmail 17342 invoked from network); 6 Jun 2006 01:41:29 -0000 Received: from unknown (HELO [10.0.0.2]) (Sent_by_authenticated_user_x2476431@[87.196.74.232]) (envelope-sender ) by mailfrt04.isp.novis.pt with SMTP; 6 Jun 2006 01:41:29 -0000 From: Ricardo Cruz To: gtk-devel-list@gnome.org Date: Tue, 6 Jun 2006 02:48:21 +0100 User-Agent: KMail/1.9.1 X-Face: $29d{(U~(^/X.rR|7i6syM3jeJ}N+*%U-#Bzl5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200606060248.21205.rpmcruz@clix.pt> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.657 tagged_above=-999 required=2 tests=[AWL=-0.917, BAYES_20=-0.74] X-Spam-Score: -1.657 X-Spam-Level: Subject: GtkComboBoxEntry -- changing entry line value X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2006 01:41:34 -0000 Hi there, Is there a way to set a value for a GtkComboBoxEntry line entry? I am currently just adding an entry, set it as selected and remove it, which is a pretty nasty work-around. By the way, is it planned to add a GtkEditable interface for it? That would be really sweet and, if affirmitive, I could work on making a patch. Cheers, Ricardo -- Fourth Law of Thermodynamics: If the probability of success is not almost one, it is damn near zero. -- David Ellis From markku.vire@kolumbus.fi Tue Jun 6 04:39:15 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 5E3DD3B0C57 for ; Tue, 6 Jun 2006 04:39:15 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23318-01 for ; Tue, 6 Jun 2006 04:39:13 -0400 (EDT) Received: from fep02-app.kolumbus.fi (fep02-0.kolumbus.fi [193.229.0.44]) by menubar.gnome.org (Postfix) with ESMTP id C21BF3B0A19 for ; Tue, 6 Jun 2006 04:37:26 -0400 (EDT) Received: from smtp.kolumbus.fi ([193.229.55.124]) by fep02-app.kolumbus.fi with ESMTP id <20060606083725.NGAZ5174.fep02-app.kolumbus.fi@smtp.kolumbus.fi>; Tue, 6 Jun 2006 11:37:25 +0300 X-Mailer: Openwave WebEngine, version 2.8.12 (webedge20-101-197-20030912) X-Originating-IP: [62.236.91.3] From: To: Ricardo Cruz , Date: Tue, 6 Jun 2006 11:37:24 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <20060606083725.NGAZ5174.fep02-app.kolumbus.fi@smtp.kolumbus.fi> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.504 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, NO_REAL_NAME=0.961, SPF_PASS=-0.001] X-Spam-Score: -1.504 X-Spam-Level: X-Mailman-Approved-At: Tue, 06 Jun 2006 07:05:18 -0400 Cc: Subject: Re: GtkComboBoxEntry -- changing entry line value X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2006 08:39:15 -0000 Hi, You can get the entry by calling gtk_bin_get_child(box); and then using any methods of GtkEntry to manipulate the text. > Is there a way to set a value for a GtkComboBoxEntry line entry? I am > currently just adding an entry, set it as selected and remove it, which is a > pretty nasty work-around. -Markku- From markku.vire@kolumbus.fi Tue Jun 6 04:39:55 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 544743B0B78 for ; Tue, 6 Jun 2006 04:39:55 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23288-09 for ; Tue, 6 Jun 2006 04:39:52 -0400 (EDT) Received: from fep02-app.kolumbus.fi (fep02-0.kolumbus.fi [193.229.0.44]) by menubar.gnome.org (Postfix) with ESMTP id BD56C3B0A19 for ; Tue, 6 Jun 2006 04:39:51 -0400 (EDT) Received: from smtp.kolumbus.fi ([193.229.55.124]) by fep02-app.kolumbus.fi with ESMTP id <20060606083950.NHYK5174.fep02-app.kolumbus.fi@smtp.kolumbus.fi>; Tue, 6 Jun 2006 11:39:50 +0300 X-Mailer: Openwave WebEngine, version 2.8.12 (webedge20-101-197-20030912) X-Originating-IP: [62.236.91.3] From: To: Ricardo Cruz , Date: Tue, 6 Jun 2006 11:39:50 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <20060606083950.NHYK5174.fep02-app.kolumbus.fi@smtp.kolumbus.fi> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.504 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, NO_REAL_NAME=0.961, SPF_PASS=-0.001] X-Spam-Score: -1.504 X-Spam-Level: X-Mailman-Approved-At: Tue, 06 Jun 2006 07:05:18 -0400 Cc: Subject: Re: GtkComboBoxEntry -- changing entry line value X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2006 08:39:55 -0000 Hi, You can get the entry by calling gtk_bin_get_child(box); and then using any methods of GtkEntry to manipulate the text. > Is there a way to set a value for a GtkComboBoxEntry line entry? I am > currently just adding an entry, set it as selected and remove it, which is a > pretty nasty work-around. -Markku- From federico@ximian.com Tue Jun 6 11:45:51 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id A23E83B00FF for ; Tue, 6 Jun 2006 11:45:51 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01904-10 for ; Tue, 6 Jun 2006 11:45:35 -0400 (EDT) Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) by menubar.gnome.org (Postfix) with ESMTP id 6D4083B0ADD for ; Tue, 6 Jun 2006 11:45:33 -0400 (EDT) Received: (qmail 15590 invoked from network); 6 Jun 2006 15:45:31 -0000 Received: from localhost (HELO ?164.99.120.162?) (127.0.0.1) by localhost with SMTP; 6 Jun 2006 15:45:31 -0000 From: Federico Mena Quintero To: GTK+ development mailing list Content-Type: text/plain Date: Tue, 06 Jun 2006 10:41:22 -0500 Message-Id: <1149608483.14088.54.camel@cacharro.xalalinux.org> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.574 tagged_above=-999 required=2 tests=[AWL=0.025, BAYES_00=-2.599] X-Spam-Score: -2.574 X-Spam-Level: Cc: Michael.meeks@novell.com Subject: Default timeouts X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2006 15:45:51 -0000 In gtksettings.c we have #define DEFAULT_TIMEOUT_INITIAL 200 #define DEFAULT_TIMEOUT_REPEAT 20 for the "gtk-timeout-initial" and "gtk-timeout-repeat" settings, respectively. This means we wait for a fifth of a second before we start repeating, but then we try to repeat 50 times per second. Isn't the repeat timeout way too short? This is why clicking on a calendar arrow takes you back tens of months in no time, and also makes it hard to use spin buttons. Also, Michael Meeks has the following words of wisdom in a Novell bug about the calendar in gnome-panel's clock: > In essence the timeout is way too short for switching days; also - > in the panel applet the timeout has a higher priority than the > queued resize of the display (and hence the redraw) - so in > essence we skip days even faster since we never have to render > them. > > Lowering the priority there, and lengthening the timeouts gives > a far more reasonable, usable experience without getting rid > of the whole auto-repeat principle [...] I.e. instead of using g_timeout_add() in gtkcalendar, we would use g_timeout_add_full (G_PRIORITY_DEFAULT_IDLE, ...), or perhaps (GDK_PRIORITY_REDRAW + positive_constant): both are lower priority than GTK_PRIORITY_RESIZE. Federico From michael.meeks@novell.com Tue Jun 6 12:33:58 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 74B9F3B0197 for ; Tue, 6 Jun 2006 12:33:58 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05177-09 for ; Tue, 6 Jun 2006 12:33:57 -0400 (EDT) Received: from gwia-smtp.id2.novell.com (public.id2-vpn.continvity.gns.novell.com [195.33.99.129]) by menubar.gnome.org (Postfix) with ESMTP id 3714E3B014F for ; Tue, 6 Jun 2006 12:33:57 -0400 (EDT) Received: from [192.168.0.8] (l4-client.id2.novell.com [::ffff:149.44.117.251]) by gwia-smtp.id2.novell.com with ESMTP (TLS encrypted); Tue, 06 Jun 2006 17:33:30 +0100 From: Michael Meeks To: Federico Mena Quintero In-Reply-To: <1149608483.14088.54.camel@cacharro.xalalinux.org> References: <1149608483.14088.54.camel@cacharro.xalalinux.org> Content-Type: text/plain Organization: Novell, Inc. Date: Tue, 06 Jun 2006 17:37:54 +0100 Message-Id: <1149611874.2202.2.camel@t60p.site> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.427 tagged_above=-999 required=2 tests=[AWL=-0.028, BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2] X-Spam-Score: -2.427 X-Spam-Level: Cc: GTK+ development mailing list Subject: Re: Default timeouts X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: michael.meeks@novell.com List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2006 16:33:58 -0000 On Tue, 2006-06-06 at 10:41 -0500, Federico Mena Quintero wrote: > > In essence the timeout is way too short for switching days; also - > > in the panel applet the timeout has a higher priority than the > > queued resize of the display (and hence the redraw) - so in > > essence we skip days even faster since we never have to render > > them. Of course - this is particularly applicable for the calendar where it really makes sense to actually see the month rendered each time you switch to a different month or year. Of course with a spin-button I guess throttling the spin rate to that of the refresh rate would (perhaps) be problematic. Then again re-rendering a spin-button is presumably an extremely fast operation. HTH, Michael. -- michael.meeks@novell.com <><, Pseudo Engineer, itinerant idiot From carlosgc@gnome.org Wed Jun 7 07:48:25 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id BACA33B0C6A for ; Wed, 7 Jun 2006 07:48:25 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08136-01 for ; Wed, 7 Jun 2006 07:48:23 -0400 (EDT) Received: from localhost.localdomain (gsyc090.dat.escet.urjc.es [193.147.71.90]) by menubar.gnome.org (Postfix) with ESMTP id D0D083B01EA for ; Wed, 7 Jun 2006 07:48:22 -0400 (EDT) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 945E110F28E for ; Wed, 7 Jun 2006 13:48:19 +0200 (CEST) From: Carlos Garcia Campos To: GTK+ development mailing list Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-hBJf7M2jws0KBkd4rYip" Date: Wed, 07 Jun 2006 13:48:17 +0200 Message-Id: <1149680898.3302.9.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.285 tagged_above=-999 required=2 tests=[AWL=0.179, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.285 X-Spam-Level: Subject: Evince preview mode X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 11:48:25 -0000 --=-hBJf7M2jws0KBkd4rYip Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi,=20 since gtk+ is using evince as an external printing previewer, I'm implementing a preview mode in evince, available through the command line (--preview). It's based on the ephy printing previewer where the menubar is hidden and the toolbar contains navigation items and a close button. Here is an screenshot: http://carlosgc.linups.org/files/evince-preview-mode.png Any other thing expected by a previewer? --=20 Carlos Garcia Campos (KaL) elkalmail@yahoo.es carlosgc@gnome.org http://carlosgc.linups.org PGP key: http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0x523E6462 --=-hBJf7M2jws0KBkd4rYip Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQBEhr0BjxBOalI+ZGIRAmSgAJ9Ksy9L8QqVxpvNQCtbejp/0HRZXACeNcmq O8LT0nzkGzw+qcPFuVqZ3y8= =xZYn -----END PGP SIGNATURE----- --=-hBJf7M2jws0KBkd4rYip-- From hfiguiere@teaser.fr Wed Jun 7 08:28:18 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id AC8923B0CE2; Wed, 7 Jun 2006 08:28:18 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11220-01; Wed, 7 Jun 2006 08:28:15 -0400 (EDT) Received: from xandros.com (smtp1.xandros.com [209.87.238.70]) by menubar.gnome.org (Postfix) with ESMTP id EC3713B0CD7; Wed, 7 Jun 2006 08:28:14 -0400 (EDT) Received: from [172.18.1.132] (toronto-hs-216-138-231-194.s-ip.magma.ca [216.138.231.194]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by xandros.com (Postfix) with ESMTP id E7D80C028; Wed, 7 Jun 2006 08:28:12 -0400 (EDT) Message-ID: <4486C65A.5060800@teaser.fr> Date: Wed, 07 Jun 2006 08:28:10 -0400 From: Hubert Figuiere User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: Carlos Garcia Campos References: <1149680898.3302.9.camel@localhost.localdomain> In-Reply-To: <1149680898.3302.9.camel@localhost.localdomain> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.499 tagged_above=-999 required=2 tests=[AWL=0.100, BAYES_00=-2.599] X-Spam-Score: -2.499 X-Spam-Level: Cc: GTK+ development mailing list Subject: Re: Evince preview mode X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 12:28:19 -0000 Carlos Garcia Campos wrote: > Hi, > > since gtk+ is using evince as an external printing previewer, I'm > implementing a preview mode in evince, available through the command > line (--preview). It's based on the ephy printing previewer where the > menubar is hidden and the toolbar contains navigation items and a close > button. Here is an screenshot: > > http://carlosgc.linups.org/files/evince-preview-mode.png > > Any other thing expected by a previewer? It think it should have a menu bar, even if it is way simplier than Evince, and the button to close in the toolbar should be removed because it is "uncommon" and in fact confuse the user on what to do. Closing the window should be all that needed, or doing a file->close in the menu, Also, zoom in and zoom out are very useful. Hub From paolo.maggi@gmail.com Wed Jun 7 08:15:10 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 9C3E63B08CC for ; Wed, 7 Jun 2006 08:15:10 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10407-05 for ; Wed, 7 Jun 2006 08:15:09 -0400 (EDT) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.172]) by menubar.gnome.org (Postfix) with ESMTP id 8B7343B0303 for ; Wed, 7 Jun 2006 08:15:08 -0400 (EDT) Received: by ug-out-1314.google.com with SMTP id c2so258875ugf for ; Wed, 07 Jun 2006 05:15:07 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:subject:from:to:cc:content-type:date:message-id:mime-version:x-mailer:content-transfer-encoding; b=K90OlbUivfHjc3p7Mf7NxXYQ7dM8ZBxC+0BsgOJcKZJuB7jHCl0ZAGBW4g8105rAzePSP5EyfdcA7LlHJh+VEWxuXvCS7dbrv6RMBVJzQ/vwIPq71eGzz8nn2EwMpB2LP+LFhmJsovQOwZfLUn1MKDz4iRRATWR1zOQleW/WqEg= Received: by 10.67.105.19 with SMTP id h19mr435594ugm; Wed, 07 Jun 2006 05:15:06 -0700 (PDT) Received: from elilix.polito.it ( [130.192.16.224]) by mx.gmail.com with ESMTP id q1sm888781uge.2006.06.07.05.15.05; Wed, 07 Jun 2006 05:15:06 -0700 (PDT) From: Paolo Maggi To: carlosgc@gnome.org Content-Type: text/plain Date: Wed, 07 Jun 2006 14:15:04 +0200 Message-Id: <1149682504.5804.33.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.6 tagged_above=-999 required=2 tests=[AWL=0.000, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.6 X-Spam-Level: X-Mailman-Approved-At: Wed, 07 Jun 2006 09:03:01 -0400 Cc: gtk-devel-list@gnome.org Subject: Re: Evince preview mode X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 12:15:10 -0000 Hi, cia > since gtk+ is using evince as an external printing previewer, I'm > implementing a preview mode in evince, available through the command > line (--preview). It's based on the ephy printing previewer where the > menubar is hidden and the toolbar contains navigation items and a close > button. Here is an screenshot: > > http://carlosgc.linups.org/files/evince-preview-mode.png > > Any other thing expected by a previewer? - Zoom - Direct jump to a given page Please, look also at the gedit 2.14.x print previewer. Probably we also need a way to specify paper orientation on the command line (or is orientation already specified in the PDF file?) Ciao, Paolo From matthias.clasen@gmail.com Wed Jun 7 09:13:05 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id E24273B0D07 for ; Wed, 7 Jun 2006 09:13:04 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14781-07 for ; Wed, 7 Jun 2006 09:13:02 -0400 (EDT) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.202]) by menubar.gnome.org (Postfix) with ESMTP id 00C823B0B41 for ; Wed, 7 Jun 2006 09:13:01 -0400 (EDT) Received: by nz-out-0102.google.com with SMTP id 9so196545nzo for ; Wed, 07 Jun 2006 06:13:01 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=saqMihVje8FYa9UdpyLa1+dlefvQoIGQxKH7/1Zo60aYxymeM8Pd6GyFWAgY0o+p1vKDz7amMyAC6pjntEQBEcP8uj0rJL3yYZX1hequAVkJsd5sQslhyn8T44EZjEA/hsuQz0+1EdqmPuNMRK0Lseu0seEU88n8Ei5Ii1IMFBQ= Received: by 10.37.13.40 with SMTP id q40mr711105nzi; Wed, 07 Jun 2006 06:13:00 -0700 (PDT) Received: by 10.37.21.14 with HTTP; Wed, 7 Jun 2006 06:13:00 -0700 (PDT) Message-ID: Date: Wed, 7 Jun 2006 09:13:00 -0400 From: "Matthias Clasen" To: "Carlos Garcia Campos" In-Reply-To: <1149680898.3302.9.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1149680898.3302.9.camel@localhost.localdomain> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.508 tagged_above=-999 required=2 tests=[AWL=0.092, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.508 X-Spam-Level: Cc: GTK+ development mailing list Subject: Re: Evince preview mode X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 13:13:05 -0000 On 6/7/06, Carlos Garcia Campos wrote: > Hi, > > since gtk+ is using evince as an external printing previewer, I'm > implementing a preview mode in evince, available through the command > line (--preview). It's based on the ephy printing previewer where the > menubar is hidden and the toolbar contains navigation items and a close > button. Here is an screenshot: > > http://carlosgc.linups.org/files/evince-preview-mode.png > > Any other thing expected by a previewer? A print button. From n1huq@hotmail.com Wed Jun 7 13:11:51 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 04F873B04FC for ; Wed, 7 Jun 2006 13:11:51 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32024-05 for ; Wed, 7 Jun 2006 13:11:49 -0400 (EDT) Received: from hotmail.com (bay114-dav5.bay114.hotmail.com [65.54.169.77]) by menubar.gnome.org (Postfix) with ESMTP id 192433B00F5 for ; Wed, 7 Jun 2006 13:11:49 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 7 Jun 2006 10:11:48 -0700 Message-ID: Received: from 68.0.250.43 by BAY114-DAV5.phx.gbl with DAV; Wed, 07 Jun 2006 17:11:46 +0000 X-Originating-IP: [68.0.250.43] X-Originating-Email: [n1huq@hotmail.com] X-Sender: n1huq@hotmail.com From: "Sydney Faria" To: Date: Wed, 7 Jun 2006 13:15:56 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-OriginalArrivalTime: 07 Jun 2006 17:11:48.0135 (UTC) FILETIME=[75E3BB70:01C68A55] X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=1.984 tagged_above=-999 required=2 tests=[BAYES_50=0.001, DNS_FROM_RFC_ABUSE=0.2, DNS_FROM_RFC_POST=1.708, MSGID_FROM_MTA_HEADER=0, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, TW_GT=0.077] X-Spam-Score: 1.984 X-Spam-Level: * Subject: combo box problem X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 17:11:51 -0000 The following simple example of a gtk_combo_box compiles and works OK it the select_cb() is empty. The line marked gives a compiler error: undefined reference to gtk_combo_box_get_active_text. I am befuddled! sydney #include #include GtkWidget *window, *combo; static gboolean delete_event(GtkWidget *widget, GdkEvent *event, gpointer data) { return FALSE; } static void destroy(GtkWidget *widget, gpointer data) { gtk_main_quit(); } static void select_cb(GtkWidget *widget, gpointer data) { /* comment out following 2 lines and program compiles and works OK */ gchar *str = gtk_combo_box_get_active_text(GTK_COMBO_BOX(combo)); /* compile error */ g_print("active text: %s\n", str); } int main( int argc, char *argv[] ) { GtkWidget *button, *hbox; gtk_init (&argc, &argv); /* init gtk */ window = gtk_window_new (GTK_WINDOW_TOPLEVEL); gtk_container_set_border_width(GTK_CONTAINER(window), 10); g_signal_connect(G_OBJECT(window), "delete_event", G_CALLBACK(delete_event), NULL); g_signal_connect(G_OBJECT(window), "destroy", G_CALLBACK(destroy), NULL); hbox = gtk_hbox_new(TRUE, 20); gtk_container_add(GTK_CONTAINER(window), hbox); button = gtk_button_new_with_label("Select text"); g_signal_connect(G_OBJECT(button), "clicked", G_CALLBACK(select_cb), NULL); gtk_box_pack_start(GTK_BOX(hbox), button, FALSE, FALSE, 0); combo = gtk_combo_box_new_text(); gtk_box_pack_start(GTK_BOX(hbox), combo, FALSE, FALSE, 0); gtk_combo_box_insert_text(GTK_COMBO_BOX(combo), 0, "Astring"); gtk_combo_box_append_text(GTK_COMBO_BOX(combo), "Bstring"); gtk_combo_box_append_text(GTK_COMBO_BOX(combo), "Cstring"); gtk_combo_box_append_text(GTK_COMBO_BOX(combo), "Dstring"); gtk_combo_box_append_text(GTK_COMBO_BOX(combo), "Estring"); gtk_combo_box_insert_text(GTK_COMBO_BOX(combo), 3, "xxxxx"); gtk_widget_show_all(window); gtk_main(); return 0; } From ali@avrc.city.ac.uk Wed Jun 7 13:20:43 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id B9C6A3B0D3D for ; Wed, 7 Jun 2006 13:20:43 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32493-04 for ; Wed, 7 Jun 2006 13:20:42 -0400 (EDT) Received: from firewall.avrc.city.ac.uk (optosun2.city.ac.uk [138.40.167.2]) by menubar.gnome.org (Postfix) with ESMTP id ACA3B3B0BDC for ; Wed, 7 Jun 2006 13:20:40 -0400 (EDT) Received: from tom.avrc.city.ac.uk (IDENT:U2FsdGVkX1/zwWSA4Vc+XKbUWVXUavCLm3rPqXMMlDg@tom [192.168.137.104]) by firewall.avrc.city.ac.uk (8.9.3/8.9.3) with ESMTP id SAA27971; Wed, 7 Jun 2006 18:10:27 +0100 Received: from tom.avrc.city.ac.uk (localhost.localdomain [127.0.0.1]) by tom.avrc.city.ac.uk (8.13.1/8.13.1) with ESMTP id k57HTT2Y031243; Wed, 7 Jun 2006 18:29:29 +0100 Date: Wed, 07 Jun 2006 17:29:28 +0000 From: "J. Ali Harlow" To: Sydney Faria References: In-Reply-To: (from n1huq@hotmail.com on Wed Jun 7 18:15:56 2006) X-Mailer: Balsa 2.2.6 Message-Id: <1149701368l.5713l.3l@tom.avrc.city.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; DelSp=Yes; Format=Flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.525 tagged_above=-999 required=2 tests=[AWL=-0.003, BAYES_00=-2.599, TW_GT=0.077] X-Spam-Score: -2.525 X-Spam-Level: Cc: gtk-devel-list@gnome.org Subject: Re: combo box problem X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 17:20:43 -0000 On 07/06/06 18:15:56, Sydney Faria wrote: > The following simple example of a gtk_combo_box compiles and works OK > it the select_cb() is empty. The line marked gives a compiler error: =20 > undefined reference to gtk_combo_box_get_active_text. gtk_combo_box_get_active_text was added in Gtk+ v2.6 Ali. From carlosgc@gnome.org Wed Jun 7 14:37:47 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id D45D43B0546 for ; Wed, 7 Jun 2006 14:37:47 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05339-08 for ; Wed, 7 Jun 2006 14:37:46 -0400 (EDT) Received: from localhost.localdomain (gsyc090.dat.escet.urjc.es [193.147.71.90]) by menubar.gnome.org (Postfix) with ESMTP id 3EC7D3B03F7 for ; Wed, 7 Jun 2006 14:37:46 -0400 (EDT) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 0ABE610F28E for ; Wed, 7 Jun 2006 20:37:40 +0200 (CEST) From: Carlos Garcia Campos To: gtk-devel-list@gnome.org In-Reply-To: References: <1149680898.3302.9.camel@localhost.localdomain> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-WdU94ldj/PvL1mhYRti9" Date: Wed, 07 Jun 2006 20:37:39 +0200 Message-Id: <1149705460.3302.25.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.354 tagged_above=-999 required=2 tests=[AWL=0.110, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.354 X-Spam-Level: Subject: Re: Evince preview mode X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 18:37:48 -0000 --=-WdU94ldj/PvL1mhYRti9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable El mi=C3=A9, 07-06-2006 a las 09:13 -0400, Matthias Clasen escribi=C3=B3: > On 6/7/06, Carlos Garcia Campos wrote: > > Hi, > > > > since gtk+ is using evince as an external printing previewer, I'm > > implementing a preview mode in evince, available through the command > > line (--preview). It's based on the ephy printing previewer where the > > menubar is hidden and the toolbar contains navigation items and a close > > button. Here is an screenshot: > > > > http://carlosgc.linups.org/files/evince-preview-mode.png > > > > Any other thing expected by a previewer? >=20 > A print button. >=20 hmm, when the user selects preview from the print dialog, the dialog disappears and evince is launched, so that if evince has a print button we should print the document directly without showing the print dialog again. I see several problems in this approach. First of all we can't know the print settings selected by the user from evince. And, should we close evince or keep it opened after clicking on print? Is it possible to print a pdf file with the new gtk+ api without showing any dialog?=20 I think it's very confused. The best solution would be not to hide the dialog when the previewer is launched, so that once the user is happy with the results showed in evince, he simply clicks on print button.=20 --=20 Carlos Garcia Campos (KaL) elkalmail@yahoo.es carlosgc@gnome.org http://carlosgc.linups.org PGP key: http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0x523E6462 --=-WdU94ldj/PvL1mhYRti9 Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQBEhxzzjxBOalI+ZGIRAsatAJ4+rfTQPQwp9+YtbRKpPmVlDuEG9ACfclx7 9c9NhlEvkjGZjMS42o6vmHM= =TbYL -----END PGP SIGNATURE----- --=-WdU94ldj/PvL1mhYRti9-- From matthias.clasen@gmail.com Wed Jun 7 19:34:00 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 62A323B036A for ; Wed, 7 Jun 2006 19:34:00 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23001-06 for ; Wed, 7 Jun 2006 19:33:56 -0400 (EDT) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.203]) by menubar.gnome.org (Postfix) with ESMTP id A86BE3B0E6E for ; Wed, 7 Jun 2006 19:33:56 -0400 (EDT) Received: by nz-out-0102.google.com with SMTP id o37so261498nzf for ; Wed, 07 Jun 2006 16:33:55 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=LpgZtLrjc9Sc3giRUzuWDX2naMTMsbgrizT1aggkQjCN27Pm9kFPU1c5Bra0LikmJaw1sDQO0paAD7N3OQwY1+3Y9JTdMwkT9YBnlgCbMohSYLzhRt6yPFasRtdkLK24rM8sI5l8EdJ/+dpxDSU/+GFlNbztpO8kky973RVbTmY= Received: by 10.36.103.6 with SMTP id a6mr1426226nzc; Wed, 07 Jun 2006 16:33:53 -0700 (PDT) Received: by 10.37.21.14 with HTTP; Wed, 7 Jun 2006 16:33:52 -0700 (PDT) Message-ID: Date: Wed, 7 Jun 2006 19:33:52 -0400 From: "Matthias Clasen" To: "Carlos Garcia Campos" In-Reply-To: <1149705460.3302.25.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1149680898.3302.9.camel@localhost.localdomain> <1149705460.3302.25.camel@localhost.localdomain> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.509 tagged_above=-999 required=2 tests=[AWL=0.091, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.509 X-Spam-Level: Cc: gtk-devel-list@gnome.org Subject: Re: Evince preview mode X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 23:34:00 -0000 On 6/7/06, Carlos Garcia Campos wrote: > hmm, when the user selects preview from the print dialog, the dialog > disappears and evince is launched, so that if evince has a print button > we should print the document directly without showing the print dialog > again. I see several problems in this approach. First of all we can't > know the print settings selected by the user from evince. And, should we > close evince or keep it opened after clicking on print? Is it possible > to print a pdf file with the new gtk+ api without showing any dialog? Sure, figuring out the best way to transfer the print settings to evince is part of this. And yes, printing preformatted pdf is supported. > > I think it's very confused. The best solution would be not to hide the > dialog when the previewer is launched, so that once the user is happy > with the results showed in evince, he simply clicks on print button. > Apple does it too, so it can't be all bad... Matthias From hfiguiere@teaser.fr Wed Jun 7 21:05:56 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 3CAD23B051D for ; Wed, 7 Jun 2006 21:05:56 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27783-02 for ; Wed, 7 Jun 2006 21:05:53 -0400 (EDT) Received: from xandros.com (smtp1.xandros.com [209.87.238.70]) by menubar.gnome.org (Postfix) with ESMTP id 31DC43B0414 for ; Wed, 7 Jun 2006 21:05:53 -0400 (EDT) Received: from [172.18.1.132] (toronto-hs-216-138-231-194.s-ip.magma.ca [216.138.231.194]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by xandros.com (Postfix) with ESMTP id A37413E02E; Wed, 7 Jun 2006 21:05:51 -0400 (EDT) Message-ID: <448777ED.1020804@teaser.fr> Date: Wed, 07 Jun 2006 21:05:49 -0400 From: Hubert Figuiere User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: Matthias Clasen References: <1149680898.3302.9.camel@localhost.localdomain> <1149705460.3302.25.camel@localhost.localdomain> In-Reply-To: X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.506 tagged_above=-999 required=2 tests=[AWL=0.093, BAYES_00=-2.599] X-Spam-Score: -2.506 X-Spam-Level: Cc: gtk-devel-list@gnome.org Subject: Re: Evince preview mode X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 01:05:56 -0000 >> I think it's very confused. The best solution would be not to hide the >> dialog when the previewer is launched, so that once the user is happy >> with the results showed in evince, he simply clicks on print button. >> > > Apple does it too, so it can't be all bad... That is the kind of blind thinking that lead to nowhere. Remember just one thing: if it does not please Steve Jobs, it does not goes. That how it works at Apple. Bottom line: wrong argument. Hub From alexl@redhat.com Thu Jun 8 08:09:59 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 5B8C83B0EF5; Thu, 8 Jun 2006 08:09:59 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32659-09; Thu, 8 Jun 2006 08:09:58 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id B35BC3B075A; Thu, 8 Jun 2006 08:09:57 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k58C9u9M020757; Thu, 8 Jun 2006 08:09:56 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k58C9u0T021240; Thu, 8 Jun 2006 08:09:56 -0400 Received: from [127.0.0.1] (sebastian-int.corp.redhat.com [172.16.52.221]) by devserv.devel.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k58C9tGO011054; Thu, 8 Jun 2006 08:09:56 -0400 From: Alexander Larsson To: Matthias Clasen In-Reply-To: References: <1149680898.3302.9.camel@localhost.localdomain> <1149705460.3302.25.camel@localhost.localdomain> Content-Type: text/plain Date: Thu, 08 Jun 2006 14:09:55 +0200 Message-Id: <1149768596.3023.11.camel@greebo> Mime-Version: 1.0 X-Mailer: Evolution 2.7.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.587 tagged_above=-999 required=2 tests=[AWL=0.014, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.587 X-Spam-Level: Cc: gtk-devel-list@gnome.org Subject: Re: Evince preview mode X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 12:09:59 -0000 On Wed, 2006-06-07 at 19:33 -0400, Matthias Clasen wrote: > On 6/7/06, Carlos Garcia Campos wrote: > > > hmm, when the user selects preview from the print dialog, the dialog > > disappears and evince is launched, so that if evince has a print button > > we should print the document directly without showing the print dialog > > again. I see several problems in this approach. First of all we can't > > know the print settings selected by the user from evince. And, should we > > close evince or keep it opened after clicking on print? Is it possible > > to print a pdf file with the new gtk+ api without showing any dialog? > > Sure, figuring out the best way to transfer the print settings to evince > is part of this. And yes, printing preformatted pdf is supported. This is tricky. What if the preview was launched without even showing the dialog, or if the user hadn't picked the right printer yet when clicking on preview. Also, it will print differently by generating pdf and then converting that to postscript, instead of generating postscript directly. Ideally this should produce as-good output, but thats not really guaranteed. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl@redhat.com alla@lysator.liu.se He's an immortal umbrella-wielding cyborg with no name. She's a tortured green-skinned Hell's Angel from a different time and place. They fight crime! From lists@nabble.com Thu Jun 8 21:35:27 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id BFE263B0E9B for ; Thu, 8 Jun 2006 21:35:27 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18339-04 for ; Thu, 8 Jun 2006 21:35:26 -0400 (EDT) Received: from talk.nabble.com (www.nabble.com [72.21.53.35]) by menubar.gnome.org (Postfix) with ESMTP id 602DC3B05AC for ; Thu, 8 Jun 2006 21:35:26 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=talk.nabble.com) by talk.nabble.com with esmtp (Exim 4.50) id 1FoVuE-0000rb-3p for gtk-devel-list@gnome.org; Thu, 08 Jun 2006 18:35:24 -0700 Message-ID: <4785900.post@talk.nabble.com> Date: Thu, 8 Jun 2006 18:35:22 -0700 (PDT) From: darknecro To: gtk-devel-list@gnome.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-Sender: darknecromancer@dodgeit.com X-Nabble-From: darknecro X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-0.316 tagged_above=-999 required=2 tests=[AWL=2.285, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -0.316 X-Spam-Level: Subject: GTK Masks X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2006 01:35:27 -0000 I am attempting to create a single mask that would cover several items with in the GUI. There will by 16 circles created with gdk_pixmap_create_from_xpm_d, and I can currently do this, but only one item would be 'created' in the mask, so when i apply the mask to the window, only one of the items will be visible. I have done a lot of searching, and I have only been able to come up with that you can xor 2 masks together somehow and create one that contains both. Any help that anyone could shed on this would be greatly appreciated. -- View this message in context: http://www.nabble.com/GTK-Masks-t1759366.html#a4785900 Sent from the Gtk+ - Dev - General forum at Nabble.com. From mitch@gimp.org Fri Jun 9 06:31:35 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id D2D0C3B0216 for ; Fri, 9 Jun 2006 06:31:34 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14877-07 for ; Fri, 9 Jun 2006 06:31:33 -0400 (EDT) Received: from mitch.gimp.org (p549C9439.dip0.t-ipconnect.de [84.156.148.57]) by menubar.gnome.org (Postfix) with ESMTP id EB4033B01DA for ; Fri, 9 Jun 2006 06:31:30 -0400 (EDT) Received: from mitch by mitch.gimp.org with local (Exim 3.36 #1 (Debian)) id 1FoeIj-0003cx-00; Fri, 09 Jun 2006 12:33:13 +0200 From: Michael Natterer To: Federico Mena Quintero In-Reply-To: <1149608483.14088.54.camel@cacharro.xalalinux.org> References: <1149608483.14088.54.camel@cacharro.xalalinux.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Fri, 09 Jun 2006 12:33:12 +0200 Message-Id: <1149849193.3010.23.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=1.06 tagged_above=-999 required=2 tests=[AWL=-0.545, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, RCVD_IN_NJABL_DUL=1.946, RCVD_IN_SORBS_DUL=2.046, TW_GT=0.077] X-Spam-Score: 1.06 X-Spam-Level: * Cc: GTK+ development mailing list , Michael.meeks@novell.com Subject: Re: Default timeouts X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2006 10:31:35 -0000 On Tue, 2006-06-06 at 10:41 -0500, Federico Mena Quintero wrote: > In gtksettings.c we have > > #define DEFAULT_TIMEOUT_INITIAL 200 > #define DEFAULT_TIMEOUT_REPEAT 20 > > for the "gtk-timeout-initial" and "gtk-timeout-repeat" settings, > respectively. This means we wait for a fifth of a second before we > start repeating, but then we try to repeat 50 times per second. > > Isn't the repeat timeout way too short? This is why clicking on a > calendar arrow takes you back tens of months in no time, and also makes > it hard to use spin buttons. Yes, that's way too short. When doing the settings patch, I unified timeouts without actually changing them (the 20 ms was there before). However in some places I introduced a factor of 5 so all existing timeouts could be done with the two values from GtkSettings. See comment #10 of http://bugzilla.gnome.org/show_bug.cgi?id=142582 Actually, it may make sense to simply use the user's configured key repeat and delay for these two setting values. What do you think? ciao, --mitch > Also, Michael Meeks has the following words of wisdom in a Novell bug > about the calendar in gnome-panel's clock: > > > In essence the timeout is way too short for switching days; also - > > in the panel applet the timeout has a higher priority than the > > queued resize of the display (and hence the redraw) - so in > > essence we skip days even faster since we never have to render > > them. > > > > Lowering the priority there, and lengthening the timeouts gives > > a far more reasonable, usable experience without getting rid > > of the whole auto-repeat principle [...] > > I.e. instead of using g_timeout_add() in gtkcalendar, we would use > g_timeout_add_full (G_PRIORITY_DEFAULT_IDLE, ...), or perhaps > (GDK_PRIORITY_REDRAW + positive_constant): both are lower priority than > GTK_PRIORITY_RESIZE. > > Federico > > _______________________________________________ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-devel-list From ross@burtonini.com Fri Jun 9 07:15:10 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 1192B3B0099 for ; Fri, 9 Jun 2006 07:15:10 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18418-03 for ; Fri, 9 Jun 2006 07:15:08 -0400 (EDT) Received: from smtp.nildram.co.uk (smtp.nildram.co.uk [195.112.4.54]) by menubar.gnome.org (Postfix) with ESMTP id 279213B0081 for ; Fri, 9 Jun 2006 07:15:07 -0400 (EDT) Received: from burtonini.com (althur.gotadsl.co.uk [84.12.135.175]) by smtp.nildram.co.uk (Postfix) with ESMTP id 1DDA833C3F2; Fri, 9 Jun 2006 12:11:26 +0100 (BST) Received: from 127.0.0.1 (ident=unknown) by burtonini.com with esmtp (masqmail 0.2.21) id 1Foetj-17d-00; Fri, 09 Jun 2006 12:11:27 +0100 From: Ross Burton To: Michael Natterer In-Reply-To: <1149849193.3010.23.camel@localhost> References: <1149608483.14088.54.camel@cacharro.xalalinux.org> <1149849193.3010.23.camel@localhost> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-DKvhrUfzvCjsapgkUotZ" Date: Fri, 09 Jun 2006 12:11:27 +0100 Message-Id: <1149851487.2333.2.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.456 tagged_above=-999 required=2 tests=[AWL=0.008, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.456 X-Spam-Level: Cc: Federico Mena Quintero , GTK+ development mailing list , Michael.meeks@novell.com Subject: Re: Default timeouts X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2006 11:15:10 -0000 --=-DKvhrUfzvCjsapgkUotZ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2006-06-09 at 12:33 +0200, Michael Natterer wrote: > Actually, it may make sense to simply use the user's configured > key repeat and delay for these two setting values. What do you > think? That's probably a very good idea, on the grounds that people set the keyboard delay/repeat to values they can handle (i.e. my Dad has slowed them down as he isn't as fast as he used to be). What are the system defaults for the keyboard delay/repeat? Ross --=20 Ross Burton mail: ross@burtonini.com jabber: ross@burtonini.com www: http://www.burtonini.com./ PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF --=-DKvhrUfzvCjsapgkUotZ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQBEiVdeLQnkR9C0M98RAp+DAJ9s9H2qD2A4AQ6kXwgB+B6ka0ve8QCfZcQL IPi9sLP/fY2zOVLCX+eSrvo= =LNZu -----END PGP SIGNATURE----- --=-DKvhrUfzvCjsapgkUotZ-- From timj@gtk.org Fri Jun 9 13:30:55 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 1CAD23B00E9 for ; Fri, 9 Jun 2006 13:30:55 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10186-10 for ; Fri, 9 Jun 2006 13:30:52 -0400 (EDT) Received: from webmail.hansenet.de (mail03.hansenet.de [213.191.73.10]) by menubar.gnome.org (Postfix) with ESMTP id E3A183B011B for ; Fri, 9 Jun 2006 13:30:51 -0400 (EDT) Received: from birnet.org (80.171.4.161) by webmail.hansenet.de (7.2.059) id 4487A06D0006D98F; Fri, 9 Jun 2006 19:30:40 +0200 Received: from master.birnet.private (localhost [127.0.0.1]) by birnet.org (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k59HUdVg010604 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 9 Jun 2006 19:30:39 +0200 Received: (from timj@localhost) by master.birnet.private (8.13.4/8.13.4/Submit) id k59HUPEO010599; Fri, 9 Jun 2006 19:30:25 +0200 Date: Fri, 9 Jun 2006 19:30:25 +0200 (CEST) From: Tim Janik X-X-Sender: timj@master.birnet.private To: "Kaveh R. Ghazi" In-Reply-To: <200606091630.k59GUaES013244@caipclassic.rutgers.edu> Message-ID: References: <20060609152646.GE20719@space.twc.de> <200606091630.k59GUaES013244@caipclassic.rutgers.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.469 tagged_above=-999 required=2 tests=[AWL=0.130, BAYES_00=-2.599] X-Spam-Score: -2.469 X-Spam-Level: Cc: gcc@gcc.gnu.org, Gtk+ Developers Subject: Re: Problem with type safety and the "sentinel" attribute X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2006 17:30:55 -0000 thanks for the quick response Kaveh. On Fri, 9 Jun 2006, Kaveh R. Ghazi wrote: > > > void print_string_array (const char *array_name, > > const char *string, ...) __attribute__ > > ((__sentinel__)); > > > > print_string_array ("empty_array", NULL); /* gcc warns, but shouldn't */ > > > > The only way out for keeping the sentinel attribute and avoiding the > > warning is using > > > > static void print_string_array (const char *array_name, ...) > > __attribute__ ((__sentinel__)); > > I think you could maintain typesafety and silence the warning by > keeping the more specific prototype and adding an extra NULL, e.g.: > > print_string_array ("empty_array", NULL, NULL); > > Doesn't seem elegant, but it does the job. this is an option for a limited set of callers, yes. > > By the way, there is already an existing gcc bug, which is about the > > same thing (NULL passed within named args), but wants to have it the > > way it works now: > > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21911 > > Correct, the feature as I envisioned it expected the sentinel to > appear in the variable arguments only. This PR reflects when I found > out it didn't do that and got around to fixing it. Note the "buggy" > behavior wasn't exactly what you wanted either because GCC got fooled > by a sentinel in *any* of the named arguments, not just the last one. > > > > so if it gets changed, then gcc might need to support both > > - NULL termination within the last named parameter allowed > > - NULL termination only allowed within varargs parameters (like it is > > now) > > I'm not against this enhancement, but you need to specify a syntax > that allows the old behavior but also allows doing it your way. > > Hmm, perhaps we could check for attribute "nonnull" on the last named > argument, if it exists then that can't be the sentinel, if it's not > there then it does what you want. This is not completely backwards > compatible because anyone wanting the existing behavior has to add the > attribute nonnull. But there's precedent for this when attribute > printf split out whether the format specifier could be null... > > We could also create a new attribute name for the new behavior. This > would preserve backwards compatibility. I like this idea better. i agree here. as far as the majority of the GLib and Gtk+ APIs are concerned, we don't really need the flexibility of the sentinel attribute but rather a compiler check on whether the last argument used in a function call is NULL or 0 (regardless of whether it's the last named arg or already part of the varargs list). that's also why the actual sentinel wrapper in GLib looks like this: #define G_GNUC_NULL_TERMINATED __attribute__((__sentinel__)) so, if i was to make a call on this issue, i'd either introduce __attribute__((__null_terminated__)) with the described semantics, or have __attribute__((__sentinel__(-1))) work essentially like __attribute__((__sentinel__(0))) while also accepting 0 in the position of the last named argument. > Next you need to recruit someone to implement this enhancement, or > submit a patch. :-) Although given that you can silence the warning by > adding an extra NULL at the call site, I'm not sure it's worth it. i would say this is definitely worth it, because the issue also shows up in other code that is widely used: gpointer g_object_new (GType object_type, const gchar *first_property_name, ...); that's for instance a function which is called in many projects. putting the burden on the caller is clearly the wrong trade off here. so please take this as a vote for the worthiness of a fix ;) > --Kaveh > -- > Kaveh R. Ghazi ghazi@caip.rutgers.edu --- ciaoTJ From nshmyrev@yandex.ru Sat Jun 10 02:06:32 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 347973B00D0 for ; Sat, 10 Jun 2006 02:06:32 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12492-03 for ; Sat, 10 Jun 2006 02:06:28 -0400 (EDT) Received: from chen.mtu.ru (chen.mtu.ru [195.34.34.232]) by menubar.gnome.org (Postfix) with ESMTP id 78AC43B0126 for ; Sat, 10 Jun 2006 02:06:28 -0400 (EDT) Received: from gnome.local (ppp83-237-50-138.pppoe.mtu-net.ru [83.237.50.138]) by smtp.MTU.RU (Postfix) with ESMTP id D51B453DA7E; Sat, 10 Jun 2006 10:06:25 +0400 (MSD) (envelope-from nshmyrev@yandex.ru) From: "Nickolay V. Shmyrev" To: gtk-devel-list@gnome.org, gnome-i18n@gnome.org Content-Type: text/plain Date: Sat, 10 Jun 2006 10:06:30 +0400 Message-Id: <1149919590.2305.18.camel@gnome.local> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 (2.6.2-1.fc5.3) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.758 tagged_above=-999 required=2 tests=[AWL=-0.440, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, SPF_NEUTRAL=1.069, TW_GT=0.077] X-Spam-Score: -1.758 X-Spam-Level: Cc: Subject: Translation of gtk tuturial X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2006 06:06:32 -0000 Hello all. I now there was done quite amazing work about translation of gtk tutorial and I know there were some other translations http://linfoline.homedns.org/gtk/book1.html http://kldp.org/KoreanDoc/html/GtkTutorial/GtkTutorial.html What about making gtk tutorial translatable with docutils like all user documentation and merging those translations upstream? I don't ask about reference manual translation but it's also interesting, although not realistic. Probably it's not sensible to distribute tutorial with gtk package itself but use something like a web-based Rosetta. From matthias.clasen@gmail.com Sat Jun 10 10:02:35 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id A74883B0280 for ; Sat, 10 Jun 2006 10:02:35 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06778-09 for ; Sat, 10 Jun 2006 10:02:33 -0400 (EDT) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.200]) by menubar.gnome.org (Postfix) with ESMTP id 1C56D3B01C3 for ; Sat, 10 Jun 2006 10:02:33 -0400 (EDT) Received: by nz-out-0102.google.com with SMTP id z3so947001nzf for ; Sat, 10 Jun 2006 07:02:32 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=jUGG9w5BYrTkFmK4uobvwaXzJ1w3H4k8DuZIFGIHoBjFn1kgtf//lWo+engDAz0ImbOYOsKrWjvA9YAXvpwCcamcXXpE51E09vtpA8lmZKxAt+RA6AWeMX4blO5srWeestsf+E6dRd0OwZUmD3OCksEXAdLAjQcGBJBiKLVKPnQ= Received: by 10.37.15.76 with SMTP id s76mr5772218nzi; Sat, 10 Jun 2006 07:02:32 -0700 (PDT) Received: by 10.37.21.6 with HTTP; Sat, 10 Jun 2006 07:02:32 -0700 (PDT) Message-ID: Date: Sat, 10 Jun 2006 10:02:32 -0400 From: "Matthias Clasen" To: "Nickolay V. Shmyrev" In-Reply-To: <1149919590.2305.18.camel@gnome.local> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1149919590.2305.18.camel@gnome.local> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.471 tagged_above=-999 required=2 tests=[AWL=0.052, BAYES_00=-2.599, SPF_PASS=-0.001, TW_GT=0.077] X-Spam-Score: -2.471 X-Spam-Level: Cc: gnome-i18n@gnome.org, gtk-devel-list@gnome.org Subject: Re: Translation of gtk tuturial X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2006 14:02:35 -0000 On 6/10/06, Nickolay V. Shmyrev wrote: > Hello all. > > I now there was done quite amazing work about translation of gtk > tutorial and I know there were some other translations > > http://linfoline.homedns.org/gtk/book1.html > > http://kldp.org/KoreanDoc/html/GtkTutorial/GtkTutorial.html > > What about making gtk tutorial translatable with docutils like all > user documentation and merging those translations upstream? > > I don't ask about reference manual translation but it's also interesting, > although not realistic. Probably it's not sensible to distribute tutorial > with gtk package itself but use something like a web-based Rosetta. > The first step towards making the tutorial more useful would be updating its 2.0 era content, remove deprecated apis, and cover at least some of the important new apis. From lists@nabble.com Sat Jun 10 13:20:05 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id BB53E3B01B8 for ; Sat, 10 Jun 2006 13:20:05 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16672-08 for ; Sat, 10 Jun 2006 13:20:04 -0400 (EDT) Received: from talk.nabble.com (www.nabble.com [72.21.53.35]) by menubar.gnome.org (Postfix) with ESMTP id 2730A3B01D7 for ; Sat, 10 Jun 2006 13:20:04 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=talk.nabble.com) by talk.nabble.com with esmtp (Exim 4.50) id 1Fp77z-0000O0-FG for gtk-devel-list@gnome.org; Sat, 10 Jun 2006 10:20:03 -0700 Message-ID: <4809607.post@talk.nabble.com> Date: Sat, 10 Jun 2006 10:20:03 -0700 (PDT) From: mikecorn To: gtk-devel-list@gnome.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-Sender: mikecorn@t-online.de X-Nabble-From: mikecorn X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.565 tagged_above=-999 required=2 tests=[AWL=0.036, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.565 X-Spam-Level: Subject: GTK window edge detection sensitivity X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2006 17:20:05 -0000 To: GTK developers The resizable windows in Gnome are slick, but I often have a minor problem: After the mouse cursor changes form, indicating that the window edge is in-range for dragging, I often find myself dragging across the window behind, because the edge range was lost shortly after it was found. I ask you to consider possible improvements to make this work more reliably and with less precision required (which also means faster for the user). 1. increase the edge-detection threshold by 2x or more, or make it user-adjustable. 2. once the edge is detected, increase the threshold for losing it (time or distance). regards Mike C. -- View this message in context: http://www.nabble.com/GTK-window-edge-detection-sensitivity-t1767067.html#a4809607 Sent from the Gtk+ - Dev - General forum at Nabble.com. From marcel@telka.sk Sat Jun 10 23:05:18 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 2D8C03B05D2 for ; Sat, 10 Jun 2006 23:05:18 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06780-08 for ; Sat, 10 Jun 2006 23:05:16 -0400 (EDT) Received: from tortuga.telka.sk (unknown [193.86.173.20]) by menubar.gnome.org (Postfix) with SMTP id 7D8283B0543 for ; Sat, 10 Jun 2006 23:05:15 -0400 (EDT) Received: (qmail 14272 invoked by uid 0); 11 Jun 2006 02:57:43 -0000 Date: 11 Jun 2006 02:57:43 -0000 Message-ID: <20060611025743.14269.qmail@tortuga.telka.sk> To: From: Marcel Telka X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.443 tagged_above=-999 required=2 tests=[AWL=0.156, BAYES_00=-2.599] X-Spam-Score: -2.443 X-Spam-Level: Subject: gtk+: Missing translatable files X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jun 2006 03:05:18 -0000 Hi. I have tested module gtk+ (CVS branch HEAD) which lives in GNOME CVS for missing translatable files with `intltool-update -m` command. Here is a content of the 'missing' file: gtk/gtkfilechoosersettings.c gtk/gtkprintoperationpreview.c Please put these files into POTFILES.in or POTFILES.skip files. Thanks. Note: This report is generated automatically and you are not required to reply to this mail. If you are not maintainer of the 'gtk+' module or this CVS branch is obsolete or you don't want similar report in future, tell me and I will stop this report generation. Regards. -- +-------------------------------------------+ | Marcel Telka e-mail: marcel@telka.sk | | homepage: http://telka.sk/ | | jabber: marcel@jabber.sk | +-------------------------------------------+ From easy-b@freesurf.ch Sun Jun 11 16:22:48 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id ABE753B0159 for ; Sun, 11 Jun 2006 16:22:48 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32516-10 for ; Sun, 11 Jun 2006 16:22:46 -0400 (EDT) Received: from mail-fs.sunrise.ch (mta-fs-be-04.sunrise.ch [194.158.229.33]) by menubar.gnome.org (Postfix) with ESMTP id A306E3B00CA for ; Sun, 11 Jun 2006 16:22:45 -0400 (EDT) Received: from [10.0.1.2] (84.227.173.50) by mail-fs.sunrise.ch (7.2.073) id 44858C490024803A; Sun, 11 Jun 2006 22:21:55 +0200 In-Reply-To: References: <20060522160033.F1A8E3B1CE4@menubar.gnome.org> <772588ED-500A-4A11-8829-DA80B9A35D1F@freesurf.ch> <44720B8C.3080903@imendio.com> <0A34FCC9-6650-4737-B86D-1B503D8A9072@freesurf.ch> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7D6367DC-8689-453B-8FD7-217632BC1DAE@freesurf.ch> Content-Transfer-Encoding: 7bit From: Easy B Date: Sun, 11 Jun 2006 22:21:54 +0200 To: Gregor Riepl X-Mailer: Apple Mail (2.749.3) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.312 tagged_above=-999 required=2 tests=[AWL=-0.787, BAYES_00=-2.599, DNS_FROM_RFC_POST=1.708, FORGED_RCVD_HELO=0.135, TW_BG=0.077, TW_GD=0.077, TW_GT=0.077] X-Spam-Score: -1.312 X-Spam-Level: Cc: gtk-devel-list@gnome.org Subject: Mac OS X Framework X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jun 2006 20:22:48 -0000 Hoi Gregor Thanx for the Tips. This would make the Framework more like one. The ability to include it into the application bundle would be very handy. If I look at other Frameworks I always find a single library in the top directory, for example: /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ Frameworks/ImageIO.framework/ImageIO If I do "otool -L /System/Library/Frameworks/ ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/ ImageIO", I get references to many other libraries that are located inside the framework bundle: /System/Library/Frameworks/ApplicationServices.framework/ Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/ libJPEG.dylib (compatibility version 1.0.0, current version 1.0.0) /System/Library/Frameworks/ApplicationServices.framework/ Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/ libJP2.dylib (compatibility version 1.0.0, current version 1.0.0) /System/Library/Frameworks/ApplicationServices.framework/ Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/ libGIF.dylib (compatibility version 1.0.0, current version 1.0.0) /System/Library/Frameworks/ApplicationServices.framework/ Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/ libRaw.dylib (compatibility version 1.0.0, current version 1.0.0) /System/Library/Frameworks/ApplicationServices.framework/ Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/ libTIFF.dylib (compatibility version 1.0.0, current version 1.0.0) /System/Library/Frameworks/ApplicationServices.framework/ Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/ libPng.dylib (compatibility version 1.0.0, current version 1.0.0) /System/Library/Frameworks/ApplicationServices.framework/ Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/ libRadiance.dylib (compatibility version 1.0.0, current version 1.0.0) In my Gtk+.framework I have tons of libraries. Would it be possible to create something like the above for gtk? Would it make sense? Right now I just use pkg-config to find the libraries and the result looks like this: /Applications/Shity Apps/Gtk-Demo.app/Contents/MacOS/gtk-demo: /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libgdk_pixbuf-2.0.0.dylib (compatibility version 902.0.0, current version 902.0.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libgdk-quartz-2.0.0.dylib (compatibility version 902.0.0, current version 902.0.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libgtk-quartz-2.0.0.dylib (compatibility version 902.0.0, current version 902.0.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libpangocairo-1.0.0.dylib (compatibility version 1301.0.0, current version 1301.1.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libpangoft2-1.0.0.dylib (compatibility version 1301.0.0, current version 1301.1.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libpango-1.0.0.dylib (compatibility version 1301.0.0, current version 1301.1.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libatk-1.0.0.dylib (compatibility version 1115.0.0, current version 1115.0.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libgobject-2.0.0.dylib (compatibility version 1102.0.0, current version 1102.0.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libgmodule-2.0.0.dylib (compatibility version 1102.0.0, current version 1102.0.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libglib-2.0.0.dylib (compatibility version 1102.0.0, current version 1102.0.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libcairo.2.dylib (compatibility version 9.0.0, current version 9.0.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libpng12.0.dylib (compatibility version 11.0.0, current version 11.0.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libfontconfig.1.dylib (compatibility version 2.0.0, current version 2.4.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libfreetype.6.dylib (compatibility version 10.0.0, current version 10.8.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libxml2.2.dylib (compatibility version 9.0.0, current version 9.24.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libintl.3.dylib (compatibility version 8.0.0, current version 8.3.0) What do you think? Cheers, Ezra. On 11.06.2006, at 10:22, Gregor Riepl wrote: > Hi Ezra > >> Well it's looking better now. I even ended up with ready to use >> Installers. I still got my pkg-config/headers problem though so >> the script still has some ugly hard links in it., besides all the >> other debugging ugliness. I'm also not sure if the framework is >> usable the way it's now. I will first have to try to compile some >> apps against it. I'll definitely come with more problems soon. > > To make a framework fully usable, it's dynamic library paths need > to be adapted with install_name_tool. > For example, its the self-reference should be > @executable_path/../Frameworks/.framework/ > Versions/A/ > This makes the library includable in application bundles, instead > of having to install it. > But you may of course also use /Library/Frameworks/ framework>.framework/Versions/A/ > Have a look at the output of otool -L for some system and user- > installed libraries, i.e. > > $ otool -L /System/Library/Frameworks/Cocoa.framework/Cocoa > /System/Library/Frameworks/Cocoa.framework/Cocoa: > /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa > (compatibility version 1.0.0, current version 11.0.0) > /System/Library/Frameworks/AppKit.framework/Versions/C/ > AppKit (compatibility version 45.0.0, current version 822.0.0) > /System/Library/Frameworks/CoreData.framework/Versions/A/ > CoreData (compatibility version 1.0.0, current version 46.0.0) > /System/Library/Frameworks/Foundation.framework/Versions/C/ > Foundation (compatibility version 300.0.0, current version 566.0.0) > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, > current version 88.0.0) > > or > > $ otool -L /Library/Frameworks/SDL_image.framework/SDL_image > /Library/Frameworks/SDL_image.framework/SDL_image: > @executable_path/../Frameworks/SDL_image.framework/Versions/ > A/SDL_image (compatibility version 1.0.0, current version 1.0.0) > @executable_path/../Frameworks/SDL.framework/Versions/A/SDL > (compatibility version 1.0.0, current version 1.0.0) > /usr/lib/libz.1.dylib (compatibility version 1.0.0, current > version 1.0.0) > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, > current version 71.1.1) > > If a library has a lot of dependencies, you may run into a problem > here: The Mach-O header's area for library references isn't of > variable size, and install_name_tool may refuse to change all > paths. There's afaik no other way then to relink the binary with > the option -headerpad_max_install_names (see man ld). > From mclasen@redhat.com Mon Jun 12 12:04:32 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 41C3B3B000C; Mon, 12 Jun 2006 12:04:32 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09149-04; Mon, 12 Jun 2006 12:04:29 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id 7270D3B009D; Mon, 12 Jun 2006 12:04:29 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5CG3bc9030255; Mon, 12 Jun 2006 12:03:37 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5CG3bc3007778; Mon, 12 Jun 2006 12:03:37 -0400 Received: from golem.boston.redhat.com (golem.boston.redhat.com [172.16.80.24]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id k5CG3blQ018463; Mon, 12 Jun 2006 12:03:37 -0400 From: Matthias Clasen To: gnome-announce-list@gnome.org, gtk-devel-list@gnome.org, gtk-app-devel-list@gnome.org, gtk-list@gnome.org Content-Type: text/plain Date: Mon, 12 Jun 2006 12:03:36 -0400 Message-Id: <1150128216.15532.14.camel@golem.boston.redhat.com> Mime-Version: 1.0 X-Mailer: Evolution 2.7.1 (2.7.1-1) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.426 tagged_above=-999 required=2 tests=[AWL=-0.056, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, TW_LQ=0.077, TW_RX=0.077, TW_TR=0.077] X-Spam-Score: -2.426 X-Spam-Level: Cc: Subject: GLib 2.11.3 released X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gome-hackers@gnome.org List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2006 16:04:32 -0000 GLib 2.11.3 is now available for download at: ftp://ftp.gtk.org/pub/gtk/v2.11/ http://ftp.gnome.org/pub/GNOME/sources/glib/2.11/ glib-2.11.3.tar.bz2 md5sum: 41931c4965f7e1848f81b800914905cd glib-2.11.3.tar.gz md5sum: cd78ebc535e29cdef0fed9487aa21dac This is a development release leading up to GLib 2.12. Notes: * This is unstable development release. While it has had a bit of testing, there are certainly plenty of bugs remaining to be found. This release should not be used in production. * Installing this version will overwrite your existing copy of GLib 2.10. If you have problems, you'll need to reinstall GLib 2.10. * GLib 2.12 will be source and binary compatible with the GLib 2.10.x series (for some caveats, see the README). At this point, the API additions in the 2.11.x series are almost finished. * Bugs should be reported to http://bugzilla.gnome.org. About GLib ========== GLib is the low-level core library that forms the basis for projects such as GTK+ and GNOME. It provides data structure handling for C, portability wrappers, and interfaces for such runtime functionality as an event loop, threads, dynamic loading, and an object system. More information about GLib is available at: http://www.gtk.org/ An installation guide for the GTK+ libraries, including GLib, can be found at: http://developer.gnome.org/doc/API/2.0/gtk/gtk-building.html Overview of Changes from GLib 2.11.2 to GLib 2.11.3 =================================================== * GBookmarkFile: - g_bookmark_file_move_item: Return TRUE in case of an empty target * Bugs fixed: 343919 gunicollate.c: strxfrm bug on VC8 * Updated translations (fi) A list of all bugs fixed in this release can be found at: http://bugzilla.gnome.org/buglist.cgi?bug_id=343919 Thanks to everybody who has contributed to this release, in the form of bug reports or patches: Emmanuele Bassi, Kazuki Iwamoto, Tor Lillqvist Matthias Clasen June 12, 2006 From mclasen@redhat.com Mon Jun 12 15:43:04 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 851123B00E5; Mon, 12 Jun 2006 15:43:04 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27729-06; Mon, 12 Jun 2006 15:43:02 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id 5B16F3B0010; Mon, 12 Jun 2006 15:43:02 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5CJZWav007572; Mon, 12 Jun 2006 15:35:32 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5CJZWUd001833; Mon, 12 Jun 2006 15:35:32 -0400 Received: from golem.boston.redhat.com (golem.boston.redhat.com [172.16.80.24]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id k5CJZWlQ009694; Mon, 12 Jun 2006 15:35:32 -0400 From: Matthias Clasen To: gnome-announce-list@gnome.org, gtk-devel-list@gnome.org, gtk-app-devel-list@gnome.org, gtk-list@gnome.org Content-Type: text/plain Date: Mon, 12 Jun 2006 15:35:31 -0400 Message-Id: <1150140931.15532.18.camel@golem.boston.redhat.com> Mime-Version: 1.0 X-Mailer: Evolution 2.7.1 (2.7.1-1) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.541 tagged_above=-999 required=2 tests=[AWL=0.060, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.541 X-Spam-Level: Cc: Subject: GTK+ 2.8.19 released X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gnome-hackers@gnome.org List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2006 19:43:04 -0000 GTK+ 2.8.19 is now available for download at: ftp://ftp.gtk.org/pub/gtk/v2.8/ http://ftp.gnome.org/pub/GNOME/sources/gtk+/2.8/ gtk+-2.8.19.tar.bz2 md5sum: 1a03dbed4b794194a610e9d7eb175b06 gtk+-2.8.19.tar.gz md5sum: 604d3263498994c58af378f0ec076e6f This is a bugfix release in the 2.8.x series. It fixes a rare memory corruption issue when using the deprecated GdkFont API. What is GTK+ ============ GTK+ is a multi-platform toolkit for creating graphical user interfaces. Offering a complete set of widgets, GTK+ is suitable for projects ranging from small one-off tools to complete application suites. GTK+ has been designed from the ground up to support a range of languages, not only C/C++. Using GTK+ from languages such as Perl and Python (especially in combination with the Glade GUI builder) provides an effective method of rapid application development. GTK+ is free software and part of the GNU Project. However, the licensing terms for GTK+, the GNU LGPL, allow it to be used by all developers, including those developing proprietary software, without any license fees or royalties. Where to get more information about GTK+ ======================================== Information about GTK+ including links to documentation can be found at: http://www.gtk.org/ An installation guide for GTK+ 2.8 is found at: http://developer.gnome.org/doc/API/2.0/gtk/gtk-building.html Common questions: http://developer.gnome.org/doc/API/2.0/gtk/gtk-question-index.html http://www.gtk.org/faq/ Overview of Changes from GTK+ 2.8.18 to GTK+ 2.8.19 =================================================== Bugs fixed: 341327 Memory corruption inside glib 337491 _gdk_win32_drawable_release_dc: DeleteDC() called on a GetDC() handle 343425 "grab-notify"-signal is not correctly propagated for internal children 344244 Window resizing not working when keeping the aspect fixed 344496 CRLF converting via Clipboard Updated translations (ne) A list of all bugs fixed in this release can be found at: http://bugzilla.gnome.org/buglist.cgi?bug_id=343425,341327,344244,337491,344496 Thanks to everybody who has contributed to this release, in the form of bug reports or patches: Markku Vire, Sampo Savolainen, Tim Janik, Tor Lillqvist, Chris Wilson June 12, 2006 Matthias Clasen From mclasen@redhat.com Tue Jun 13 02:09:16 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 72FE93B00AF; Tue, 13 Jun 2006 02:09:16 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12183-04; Tue, 13 Jun 2006 02:09:13 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id B2F773B000C; Tue, 13 Jun 2006 02:09:13 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5D681s3022181; Tue, 13 Jun 2006 02:08:01 -0400 Received: from lacrosse.corp.redhat.com (lacrosse.corp.redhat.com [172.16.52.154]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5D67uRP017686; Tue, 13 Jun 2006 02:07:56 -0400 Received: from [172.16.83.145] (vpn83-145.boston.redhat.com [172.16.83.145]) by lacrosse.corp.redhat.com (8.12.11.20060308/8.11.6) with ESMTP id k5D67tQC015619; Tue, 13 Jun 2006 02:07:56 -0400 From: Matthias Clasen To: gnome-announce-list@gnome.org, gtk-devel-list@gnome.org, gtk-app-devel-list@gnome.org, gtk-list@gnome.org Content-Type: text/plain; charset=UTF-8 Organization: Red Hat Date: Tue, 13 Jun 2006 02:09:42 -0400 Message-Id: <1150178982.4081.13.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.7.2.1 (2.7.2.1-4) Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.426 tagged_above=-999 required=2 tests=[AWL=-0.056, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, TW_GD=0.077, TW_GT=0.077, TW_KB=0.077] X-Spam-Score: -2.426 X-Spam-Level: Cc: Subject: GTK+ 2.9.3 released X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gnome-hackers@gnome.org List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2006 06:09:16 -0000 GTK+ 2.9.3 is now available for download at: ftp://ftp.gtk.org/pub/gtk/v2.9/ http://ftp.gnome.org/pub/gnome/sources/gtk+/2.9/ gtk+-2.9.3.tar.bz2 md5sum: d73039a3b5847c352f5740ac908be7d2 gtk+-2.9.3.tar.gz md5sum: 0156eef91d2bbb23f1b6ccb49335fae5 This is a development release leading up to GTK+ 2.10. Notes: * This is unstable development release. There are certainly plenty of bugs remaining to be found. This release should not be used in production. * Installing this version will overwrite your existing copy of GTK+ 2.8. If you have problems, you'll need to reinstall GTK+ 2.8. * GTK+ 2.10 will be source compatible with the GTK+ 2.8 series; the new API additions in GTK+ 2.9.0 are not yet completely finalized, so there are likely incompatibilies between this release and the final 2.10 release. * The ABI version has been bumped from 2.4.0 to 2.10.0, since the filechooser backend interface has been changed. Third-party filechooser backends need to be ported to the new interface. Other third-party modules (input methods, image loaders, etc) just need to be reinstalled in the proper location for GTK+ to find them. * Remaining issues for GTK+ 2.10 can be found with following bugzilla query: http://bugzilla.gnome.org/buglist.cgi?product=gtk%2b&target_milestone=2.10+API+Freeze&target_milestone=2.10+Freeze&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED * Bugs should be reported to http://bugzilla.gnome.org. What is GTK+ ============ GTK+ is a multi-platform toolkit for creating graphical user interfaces. Offering a complete set of widgets, GTK+ is suitable for projects ranging from small one-off tools to complete application suites. GTK+ has been designed from the ground up to support a range of languages, not only C/C++. Using GTK+ from languages such as Perl and Python (especially in combination with the Glade GUI builder) provides an effective method of rapid application development. GTK+ is free software and part of the GNU Project. However, the licensing terms for GTK+, the GNU LGPL, allow it to be used by all developers, including those developing proprietary software, without any license fees or royalties. Where to get more information about GTK+ ======================================== Information about GTK+ including links to documentation can be found at: http://www.gtk.org/ An installation guide for GTK+ 2.x is found at: http://developer.gnome.org/doc/API/2.4/gtk/gtk-building.html Common questions: http://developer.gnome.org/doc/API/2.4/gtk/gtk-question-index.html http://www.gtk.org/faq/ Overview of Changes from GTK+ 2.9.2 to 2.9.3 ============================================ * GtkPrintOperation: - Introduce an allow-async property - Introduce a GtkPrintOperationAction enumeration - Rename pdf_target to export_filename - Allow to hide "Print to PDF" in the low-level API * GtkNotebook: - Add a destroy notify to gtk_notebook_set_window_creation_hook. * GtkTreeView: - Support grid lines * GtkRange: - Add a number of new stle properties which allow more fexible stepper theming * Bugs fixed: 153212 Have the Paste kbd shortcut jump to the location in the buffer 337491 _gdk_win32_drawable_release_dc: DeleteDC() called on a GetDC() handle 339739 gtk/gtkprintoperation-win32.c: 3 compile error 342339 GtkRange::stepper-spacing style property not implemented correctly 343945 Buttons of a GtkAssistant are not accessible 344148 Wrong reqs for ATK 344209 gtk_notebook_set_window_creation_hook() has no destroy func. 344232 GtkEntry's "Delete" context menu item is sensitive on a non-editable GtkEntry 344244 Window resizing not working when keeping the aspect fixed 344288 gtk_print_operation_preview_is_selected must return a value 344386 gdk-2.0-uninstalled.pc.in and gdkconfig.h 344496 CRLF converting via Clipboard 344504 GtkPrintCapabilities not in gtktypebuiltins.h 344505 Wrong signal registration for create_custom_widget 344512 cvs build issue 344513 pdf print module's print_stream not calling destroy notify 344518 NULL unref in page setup dialogue 344543 gtk_progress_bar_pulse calls gtk_progress_bar_paint directly 344560 gtk_print_settings_[sg]et_scale shouldn't be in percent 344607 memory leaks in gtkrecentchooserdefault.c and gtkrecentchoosermenu.c 344624 Memory leak in gtk_tree_model_filter_finalize: User data not freed 337603 Possible off-by-one in gdk_pango_layout_line_get_clip_region 344239 Wrong filename for gtk-find stock item. 344528 comma at end of GtkPrintOperationAction enum causes mozilla compilation error 344290 horizontal-padding not take into account when placing submenus 344558 document print dialogue response codes 339592 Add print-to-postscript 342249 Allow to draw upper and lower sides of GtkRange's trough differently 344530 gtk_recent_chooser_widget_new_for_manager and gtk_recent_chooser_menu_new_for_manager should allow NULL manager arg * Updated translations (es,fi,gu,ko,th,wa) A list of all bugs fixed in this release can be found at: http://bugzilla.gnome.org/buglist.cgi?bug_id=153212,337491,339739,342339,343945,344148,344209,344232,344244,344288,344386,344496,344504,344505,344512,344513,344518,344543,344560,344607,344624,337603,344239,344528,344290,344558,339592,342249,344530 Thanks to everybody who has contributed to this release, in the form of bug reports or patches: Behdad Esfahbod, Bastian Nocera, Alexander Larsson, Jrg Billeter, Murray Cumming, Milosz Derezynski, Tor Lillqvist, Kazuki Iwamoto, Chris Wilson, Michael Natterer, Benjamin Berg, Marko Anastasov, Christian Persch, Masatake Yamamoto, Elijah Newren, John Finlay, Emmanuele Bassi, David Malcolm, John Darrington, Christian Weiske, Yvgen Muntyan, Martyn Russell, Kristian Rietveld June 13, 2006 Matthias Clasen From exe522@hotmail.com Tue Jun 13 09:17:01 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 1FF7B3B000A for ; Tue, 13 Jun 2006 09:17:01 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24109-07 for ; Tue, 13 Jun 2006 09:17:00 -0400 (EDT) Received: from hotmail.com (bay104-f2.bay104.hotmail.com [65.54.175.12]) by menubar.gnome.org (Postfix) with ESMTP id 4C4843B00AF for ; Tue, 13 Jun 2006 09:17:00 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 13 Jun 2006 06:16:02 -0700 Message-ID: Received: from 65.54.175.200 by by104fd.bay104.hotmail.msn.com with HTTP; Tue, 13 Jun 2006 13:15:57 GMT X-Originating-IP: [86.212.127.235] X-Originating-Email: [exe522@hotmail.com] X-Sender: exe522@hotmail.com In-Reply-To: <2672cf4d0606050752o12a6d0d2gcb4c355cc0f35d79@mail.gmail.com> From: "Malik NakaMura" To: domlachowicz@gmail.com Date: Tue, 13 Jun 2006 13:15:57 +0000 Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed X-OriginalArrivalTime: 13 Jun 2006 13:16:02.0831 (UTC) FILETIME=[851C21F0:01C68EEB] X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-0.736 tagged_above=-999 required=2 tests=[AWL=-1.532, BAYES_05=-1.11, DNS_FROM_RFC_ABUSE=0.2, DNS_FROM_RFC_POST=1.708, MSGID_FROM_MTA_HEADER=0, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -0.736 X-Spam-Level: Cc: gtk-devel-list@gnome.org Subject: Re: GTK+ >> Cocoa Native Port X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2006 13:17:01 -0000 This is my first version of _gdk_quartz_copy_to_image. The only problem is that I didnt succeed in getting the color map from "drawable"... so the image is displayed without its original colors GdkImage * _gdk_quartz_copy_to_image (GdkDrawable *drawable, GdkImage *image, gint src_x, gint src_y, gint dest_x, gint dest_y, gint width, gint height) { GdkPixbuf *pixbuf; //printf("_gdk_quartz_copy_to_image : To Implement\n"); pixbuf = NULL; image = g_object_new (gdk_image_get_type (), NULL); image->type = GDK_TYPE_IMAGE; image->width = width; image->height = height; image->byte_order = (G_BYTE_ORDER == G_LITTLE_ENDIAN) ? GDK_LSB_FIRST : GDK_MSB_FIRST; image->bpp = 4; image->bpl = image->width * image->bpp; image->bits_per_pixel = image->bpp * 8; image->colormap = (GdkColormap *)g_malloc(sizeof(GdkColormap)); memcpy(image->colormap, GDK_DRAWABLE_IMPL_QUARTZ (&(GDK_PIXMAP_IMPL_QUARTZ (drawable)->parent_instance))->colormap, sizeof(GdkColormap)); if(image->colormap != NULL) { image->visual = (GdkVisual *)g_malloc(sizeof(GdkVisual)); memcpy(image->visual, gdk_colormap_get_visual (image->colormap), sizeof(GdkVisual)); if (image->visual) { void *data; int x, y; guint32 *pix, *pixels; image->depth = image->visual->depth; image->mem = g_malloc (image->bpl * image->height); memset (image->mem, 0x00, image->bpl * image->height); data = GDK_PIXMAP_IMPL_QUARTZ (drawable)->data; pixels = (guint32 *)data; for (y = 0; y < image->height; y++) { pix = pixels+((image->height - 1 - y)*width); for (x = 0; xwidth; x++) { gdk_image_put_pixel (image, x, y, *pix); pix++; } } return image; } } g_free(image); image = NULL; return NULL; } From kloczek@rudy.mif.pg.gda.pl Tue Jun 13 09:41:41 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 2C9B33B008F for ; Tue, 13 Jun 2006 09:41:41 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24974-03 for ; Tue, 13 Jun 2006 09:41:37 -0400 (EDT) Received: from rudy.mif.pg.gda.pl (rudy.mif.pg.gda.pl [153.19.42.16]) by menubar.gnome.org (Postfix) with ESMTP id 59FF13B000C for ; Tue, 13 Jun 2006 09:41:37 -0400 (EDT) X-Virus-Scanned: at rudy.mif.pg.gda.pl Received: by rudy.mif.pg.gda.pl (plum, from userid 2732) id 39ED2233B7; Tue, 13 Jun 2006 15:40:54 +0200 (CEST) Date: Tue, 13 Jun 2006 15:40:53 +0200 (CEST) From: =?ISO-8859-2?Q?Tomasz_K=B3oczko?= To: gtk-devel-list@gnome.org Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1270146782-1150206053=:31655" X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.579 tagged_above=-999 required=2 tests=[AWL=0.022, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.579 X-Spam-Level: Subject: gtk+ 2.9.3 compilation fail X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2006 13:41:41 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1270146782-1150206053=:31655 Content-Type: TEXT/PLAIN; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 8BIT gcc -DG_DISABLE_DEPRECATED -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -o .libs/gtk-query-immodules-2.0 queryimmodules.o ./.libs/libgtk-x11-2.0.so -L/lib64 /home/users/prac/nd/kloczek/rpm/BUILD/gtk+-2.9.3/gdk/.libs/libgdk-x11-2.0.so -latk-1.0 ../gdk-pixbuf/.libs/libgdk_pixbuf-2.0.so ../gdk/.libs/libgdk-x11-2.0.so -lpangocairo-1.0 -lpango-1.0 -lcairo -lfontconfig -lXext -lXrender -lX11 -lXinerama -lXi -lXrandr -lXcursor -lXfixes /home/users/prac/nd/kloczek/rpm/BUILD/gtk+-2.9.3/gdk-pixbuf/.libs/libgdk_pixbuf-2.0.so -lgmodule-2.0 -ldl -lgobject-2.0 -lglib-2.0 -lm ./.libs/libgtk-x11-2.0.so: undefined reference to `cairo_surface_set_fallback_resolution' collect2: ld returned 1 exit status make[4]: *** [gtk-query-immodules-2.0] Error 1 make[4]: Leaving directory `/home/users/prac/nd/kloczek/rpm/BUILD/gtk+-2.9.3/gtk' $ rpm -q cairo cairo-1.1.6-6 kloczek -- ----------------------------------------------------------- *Ludzie nie maj problemw, tylko sobie sami je stwarzaj* ----------------------------------------------------------- Tomasz Koczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek@rudy.mif.pg.gda.pl* --0-1270146782-1150206053=:31655-- From federico@ximian.com Tue Jun 13 12:13:42 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 31B0B3B0071 for ; Tue, 13 Jun 2006 12:13:42 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29632-05 for ; Tue, 13 Jun 2006 12:13:41 -0400 (EDT) Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) by menubar.gnome.org (Postfix) with ESMTP id 9C36B3B000A for ; Tue, 13 Jun 2006 12:13:40 -0400 (EDT) Received: (qmail 22968 invoked from network); 13 Jun 2006 16:11:48 -0000 Received: from localhost (HELO 164-99-120-90.boston.ximian.com) (127.0.0.1) by localhost with SMTP; 13 Jun 2006 16:11:48 -0000 From: Federico Mena Quintero To: Michael Natterer In-Reply-To: <1149849193.3010.23.camel@localhost> References: <1149608483.14088.54.camel@cacharro.xalalinux.org> <1149849193.3010.23.camel@localhost> Content-Type: text/plain Date: Tue, 13 Jun 2006 11:07:30 -0500 Message-Id: <1150214850.17566.118.camel@cacharro.xalalinux.org> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.574 tagged_above=-999 required=2 tests=[AWL=0.025, BAYES_00=-2.599] X-Spam-Score: -2.574 X-Spam-Level: Cc: GTK+ development mailing list , Michael.meeks@novell.com Subject: Re: Default timeouts X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2006 16:13:42 -0000 On Fri, 2006-06-09 at 12:33 +0200, Michael Natterer wrote: > However in some places I introduced a factor of 5 so all existing > timeouts could be done with the two values from GtkSettings. > > See comment #10 of http://bugzilla.gnome.org/show_bug.cgi?id=142582 > > Actually, it may make sense to simply use the user's configured > key repeat and delay for these two setting values. What do you > think? Yeah, it makes perfect sense to make it the same as the key repeat rate. You'll then get the same rate of change whether you use the mouse or the keyboard. Federico From stefan@space.twc.de Tue Jun 13 14:33:13 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id A37933B02D9 for ; Tue, 13 Jun 2006 14:33:13 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01854-06 for ; Tue, 13 Jun 2006 14:33:08 -0400 (EDT) Received: from space.twc.de (port-83-236-178-131.static.qsc.de [83.236.178.131]) by menubar.gnome.org (Postfix) with ESMTP id 1C3EE3B00C9 for ; Tue, 13 Jun 2006 14:33:07 -0400 (EDT) Received: from stefan by space.twc.de with local (Exim 4.50) id 1FqEOs-0007KV-NR; Tue, 13 Jun 2006 21:18:06 +0200 Date: Tue, 13 Jun 2006 21:18:06 +0200 To: Tim Janik Message-ID: <20060613191806.GA28032@space.twc.de> References: <20060609152646.GE20719@space.twc.de> <200606091630.k59GUaES013244@caipclassic.rutgers.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i From: Stefan Westerfeld X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.305 tagged_above=-999 required=2 tests=[AWL=0.159, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.305 X-Spam-Level: Cc: "Kaveh R. Ghazi" , Gtk+ Developers , gcc@gcc.gnu.org Subject: Re: Problem with type safety and the "sentinel" attribute X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2006 18:33:13 -0000 Hi! On Fri, Jun 09, 2006 at 07:30:25PM +0200, Tim Janik wrote: > On Fri, 9 Jun 2006, Kaveh R. Ghazi wrote: > >> void print_string_array (const char *array_name, > >> const char *string, ...) __attribute__ > >> ((__sentinel__)); > >> > >> print_string_array ("empty_array", NULL); /* gcc warns, but shouldn't > >*/ > >> > >> The only way out for keeping the sentinel attribute and avoiding the > >> warning is using > >> > >> static void print_string_array (const char *array_name, ...) > >> __attribute__ ((__sentinel__)); > > > >I think you could maintain typesafety and silence the warning by > >keeping the more specific prototype and adding an extra NULL, e.g.: > > > >print_string_array ("empty_array", NULL, NULL); > > > >Doesn't seem elegant, but it does the job. > > this is an option for a limited set of callers, yes. For the statistics, by adding the __sentinel__ attribute to the beast codebase, I have about 50 of those sentinel warnings that I don't need. So the double NULL termination would make quite some code more messy than it should be. > >> By the way, there is already an existing gcc bug, which is about the > >> same thing (NULL passed within named args), but wants to have it the > >> way it works now: > >> > >> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21911 > > > >Correct, the feature as I envisioned it expected the sentinel to > >appear in the variable arguments only. This PR reflects when I found > >out it didn't do that and got around to fixing it. Note the "buggy" > >behavior wasn't exactly what you wanted either because GCC got fooled > >by a sentinel in *any* of the named arguments, not just the last one. Ah, I see. > >> so if it gets changed, then gcc might need to support both > >> - NULL termination within the last named parameter allowed > >> - NULL termination only allowed within varargs parameters (like it is > >> now) > > > >I'm not against this enhancement, but you need to specify a syntax > >that allows the old behavior but also allows doing it your way. > > > >Hmm, perhaps we could check for attribute "nonnull" on the last named > >argument, if it exists then that can't be the sentinel, if it's not > >there then it does what you want. This is not completely backwards > >compatible because anyone wanting the existing behavior has to add the > >attribute nonnull. But there's precedent for this when attribute > >printf split out whether the format specifier could be null... > > > >We could also create a new attribute name for the new behavior. This > >would preserve backwards compatibility. I like this idea better. > > i agree here. as far as the majority of the GLib and Gtk+ APIs are > concerned, > we don't really need the flexibility of the sentinel attribute but rather > a compiler check on whether the last argument used in a function call > is NULL or 0 (regardless of whether it's the last named arg or already part > of the varargs list). > that's also why the actual sentinel wrapper in GLib looks like this: > > #define G_GNUC_NULL_TERMINATED __attribute__((__sentinel__)) > > so, if i was to make a call on this issue, i'd either introduce > __attribute__((__null_terminated__)) with the described semantics, > or have __attribute__((__sentinel__(-1))) work essentially like > __attribute__((__sentinel__(0))) while also accepting 0 in the position > of the last named argument. I also like the backwards compatible way better than trying to somehow modifying the attribute; it may break something now, or - which would also be bad - it may make something that somebody will want to check with the sentinel attribute in some future program impossible. The only case that I ever needed was NULL termination, so I think implementing one of the two proposals Tim made would be sufficient. Personally I like __attribute__((__null_terminated__)) better, because a -1 sentinel may be less intuitive to read in the source code. So this would be my suggestion for a "syntax specification". > >Next you need to recruit someone to implement this enhancement, or > >submit a patch. :-) Although given that you can silence the warning by > >adding an extra NULL at the call site, I'm not sure it's worth it. > > i would say this is definitely worth it, because the issue also shows up in > other code that is widely used: > gpointer g_object_new (GType object_type, > const gchar *first_property_name, > ...); > that's for instance a function which is called in many projects. > putting the burden on the caller is clearly the wrong trade off here. > > so please take this as a vote for the worthiness of a fix ;) Good. Of course I would be happy if somebody with knowledge of the compiler source could implement it. I never hacked gcc code before. But since you suggested sending a patch, I'll at least try to implement a new __null_terminated__ attribute, and ask for help if I can't figure out what to do. Cu... Stefan -- Stefan Westerfeld, Hamburg/Germany, http://space.twc.de/~stefan From easy-b@freesurf.ch Tue Jun 13 16:37:46 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 1FEC53B03CF for ; Tue, 13 Jun 2006 16:37:46 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05861-06 for ; Tue, 13 Jun 2006 16:37:45 -0400 (EDT) Received: from mail-fs.sunrise.ch (mta-fs-be-01.sunrise.ch [194.158.229.16]) by menubar.gnome.org (Postfix) with ESMTP id B948D3B00C8 for ; Tue, 13 Jun 2006 16:37:44 -0400 (EDT) Received: from [10.0.1.2] (84.226.131.17) by mail-fs.sunrise.ch (7.2.073) id 44795C850064786C; Tue, 13 Jun 2006 22:36:45 +0200 In-Reply-To: <89C1D6F0-EDC8-495C-B76B-9909E6388E62@freesurf.ch> References: <20060522160033.F1A8E3B1CE4@menubar.gnome.org> <772588ED-500A-4A11-8829-DA80B9A35D1F@freesurf.ch> <44720B8C.3080903@imendio.com> <0A34FCC9-6650-4737-B86D-1B503D8A9072@freesurf.ch> <7D6367DC-8689-453B-8FD7-217632BC1DAE@freesurf.ch> <89C1D6F0-EDC8-495C-B76B-9909E6388E62@freesurf.ch> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2B5653F8-341D-440C-9D5C-F166B296F94E@freesurf.ch> Content-Transfer-Encoding: 7bit From: Easy B Date: Tue, 13 Jun 2006 22:36:44 +0200 To: Gregor Riepl X-Mailer: Apple Mail (2.749.3) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-0.997 tagged_above=-999 required=2 tests=[AWL=-0.549, BAYES_00=-2.599, DNS_FROM_RFC_POST=1.708, FORGED_RCVD_HELO=0.135, TW_BG=0.077, TW_GD=0.077, TW_GT=0.077, TW_PK=0.077] X-Spam-Score: -0.997 X-Spam-Level: Cc: gtk-devel-list@gnome.org Subject: Re: Mac OS X Framework X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2006 20:37:46 -0000 Hi So i understand that we only need to link against one library that is linked to all the other ones, right? If I look at libgtk-quartz-2.0.dylib I see following: libgtk-quartz-2.0.dylib: /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libgtk-quartz-2.0.0.dylib (compatibility version 902.0.0, current version 902.0.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libgdk_pixbuf-2.0.0.dylib (compatibility version 902.0.0, current version 902.0.0) /usr/lib/libiconv.2.dylib (compatibility version 5.0.0, current version 5.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.1.5) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libgdk-quartz-2.0.0.dylib (compatibility version 902.0.0, current version 902.0.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libpangoft2-1.0.0.dylib (compatibility version 1301.0.0, current version 1301.1.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libpng12.0.dylib (compatibility version 11.0.0, current version 11.0.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libfontconfig.1.dylib (compatibility version 2.0.0, current version 2.4.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libfreetype.6.dylib (compatibility version 10.0.0, current version 10.8.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libxml2.2.dylib (compatibility version 9.0.0, current version 9.24.0) /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.3) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libpangocairo-1.0.0.dylib (compatibility version 1301.0.0, current version 1301.1.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libpango-1.0.0.dylib (compatibility version 1301.0.0, current version 1301.1.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libatk-1.0.0.dylib (compatibility version 1115.0.0, current version 1115.0.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libgobject-2.0.0.dylib (compatibility version 1102.0.0, current version 1102.0.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libgmodule-2.0.0.dylib (compatibility version 1102.0.0, current version 1102.0.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libglib-2.0.0.dylib (compatibility version 1102.0.0, current version 1102.0.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libcairo.2.dylib (compatibility version 9.0.0, current version 9.0.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libintl.3.dylib (compatibility version 8.0.0, current version 8.3.0) So I guess everything what we need is there. But I don't really get how to satisfy configure of a gtk app so that it only uses "- framework Gtk+". Sorry for my ignorance I'm pretty much a newbe on these things. Cheers, Ezra. On 12.06.2006, at 08:47, Gregor Riepl wrote: >> Thanx for the Tips. This would make the Framework more like one. >> The ability to include it into the application bundle would be >> very handy. >> >> If I look at other Frameworks I always find a single library in >> the top directory, for example: >> >> /System/Library/Frameworks/ApplicationServices.framework/Versions/ >> A/Frameworks/ImageIO.framework/ImageIO > that's right, this is the dynamic library itself. it doesn't have > the dylib suffix, but you may specify one if you like. > executables need to be linked against that, then, just -framework X > doesn't work. on the other hand, it's a good idea to either make > the "main" library (like libgtk-2.0.0.dylib) the framework (and > include all dependent libraries as either frameworks on their own > or dylibs) or just create an empty stub library that links against > those libraries or frameworks. to do that, make an empty .c source, > compile and link it against all the dylibs/frameworks you need. but > i can't tell if that's a good idea. > >> If I do "otool -L /System/Library/Frameworks/ >> ApplicationServices.framework/Versions/A/Frameworks/ >> ImageIO.framework/ImageIO", I get references to many other >> libraries that are located inside the framework bundle: > i guess that would be such a stub library, but maybe there's other > functionality contained? > otool can help you getting the symbols from mach-o binaries, much > like objdump. > >> In my Gtk+.framework I have tons of libraries. Would it be >> possible to create something like the above for gtk? Would it make >> sense? Right now I just use pkg-config to find the libraries and >> the result looks like this: >> >> /Applications/Shity Apps/Gtk-Demo.app/Contents/MacOS/gtk-demo: >> /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ >> libgdk_pixbuf-2.0.0.dylib (compatibility version 902.0.0, current >> version 902.0.0) >> ....... >> /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ >> libintl.3.dylib (compatibility version 8.0.0, current version 8.3.0) >> >> What do you think? > you should use /Library/Frameworks/Gtk+.framework/Versions/2.9.1/Gtk > + as the main library. it doesn't matter if that's just a stub or > the last library in the build chain (yes, i don't see > libgtk-2.0.0.dylib anywhere?). binaries then wouldn't require to be > linked against all those libs mentioned above. > this way you can also link gtk software with -framework Gtk+ and > nothing else, which you could even move into the pkconfig file and > thus facilitate porting. > i did something similar with the readily-available SDL framework > fpr mac os x, but it doesn't work very well because of the missing > startup code. with gtk it's easier i guess. > > have a nice day > gregor > > p.s.: on second thought, there could be a problem. afaik if a > binary loads a dylib, only that dylib's symbols become available > for it. the dependent symbols from libs that dylib's linked against > stay local for that dylib... maybe there's a workaround for this or > you come up with a better idea? From ntd@users.sourceforge.net Thu Jun 15 04:25:32 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 382C53B0324 for ; Thu, 15 Jun 2006 04:25:32 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22415-07 for ; Thu, 15 Jun 2006 04:25:29 -0400 (EDT) Received: from mailout01.albacom.net (mailout01.albacom.net [217.220.34.13]) by menubar.gnome.org (Postfix) with SMTP id 0694D3B0311 for ; Thu, 15 Jun 2006 04:25:28 -0400 (EDT) Received: (qmail 13668 invoked by uid 508); 15 Jun 2006 08:25:00 -0000 Received: from ntd@users.sourceforge.net by mailout01.albacom.net with qmail-scanner (spamassassin: ???. Clear:RC:1(217.221.76.9):SA:0(0.0/15.0):. Processed in 0.697195 secs); 15 Jun 2006 08:25:00 -0000 Received: from unknown (HELO sviluppo.internet.local) (postmaster@effe-gi.it@217.221.76.9) by mailout01.albacom.net with SMTP; 15 Jun 2006 08:24:59 -0000 Content-Disposition: inline From: Fontana Nicola Organization: Elettronica EFFE-GI s.n.c. To: gtk-devel-list@gnome.org Subject: GObject extension propose (GContainer) Date: Thu, 15 Jun 2006 11:01:12 +0000 User-Agent: KMail/1.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200606151101.12868.ntd@users.sourceforge.net> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.599 tagged_above=-999 required=2 tests=[BAYES_00=-2.599] X-Spam-Score: -2.599 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 08:25:32 -0000 Hi all, I'm a GObject based libraries (for UI purpose and not) user and I often need a generic container to derive my own types. In my opinion, I think this generic container must be included inside the GObject library ... it could be used by a lot of derived libraries providing a common approach. I published my solution - that is, what I am currently using - on sourceforge. http://sourceforge.net/projects/gcontainer/ Is it a good idea? Is something planned in this direction? Am I totally wrong? I need feedbacks ... Nicola From mclasen@redhat.com Thu Jun 15 09:54:37 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 88F2B3B00F3 for ; Thu, 15 Jun 2006 09:54:37 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14500-10 for ; Thu, 15 Jun 2006 09:54:36 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id 12BF23B0261 for ; Thu, 15 Jun 2006 09:54:36 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5FDsZ1W022208 for ; Thu, 15 Jun 2006 09:54:35 -0400 Received: from lacrosse.corp.redhat.com (lacrosse.corp.redhat.com [172.16.52.154]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5FDsZa4019641 for ; Thu, 15 Jun 2006 09:54:35 -0400 Received: from [172.16.83.98] (dhcp83-98.boston.redhat.com [172.16.83.98]) by lacrosse.corp.redhat.com (8.12.11.20060308/8.11.6) with ESMTP id k5FDsZL7008811 for ; Thu, 15 Jun 2006 09:54:35 -0400 Subject: GTK+ 2.10, the endgame From: Matthias Clasen To: gtk-devel-list@gnome.org Content-Type: text/plain Organization: Red Hat Date: Thu, 15 Jun 2006 09:56:26 -0400 Message-Id: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> Mime-Version: 1.0 X-Mailer: Evolution 2.7.3 (2.7.3-2) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.542 tagged_above=-999 required=2 tests=[AWL=0.059, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.542 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 13:54:37 -0000 I want to have GTK+ 2.10 ready at or immediately after GUADEC. I did not declare 2.9.3 api frozen in the release announcement, because we were still holding the door open for Kris' work on the new tooltips api. But he has run into some difficulties with the implementation which will take some time to overcome, so we have decided to punt this feature and try to get it into 2.12 early. Therefore, I want to consider 2.9.3 api frozen, and take a look at what still needs to happen before 2.10. Here are some things I personally would like get worked on (not sure how much time I can free to look into these myself): - I think the async filechooser conversion has caused some regressions, I noticed that .hidden support seems broken and autocompletion also behaved badly for me recently. - There is a number of FIXMEs and unimplemented bits in the print code. - The print backends need a careful look wrt to memory leaks and error reporting. Are there other important bugs or regressions that need attention before 2.10 ? Another thing I have slacked off about is organizing a GTK+ team meeting at GUADEC. So, who of the GTK+ team is there and at what times ? Should we try to find a free hour during the core days, or does everybody stay for the after hours ? If so, it may be easier to do a team meeting on Thursday... Matthias From timj@gtk.org Thu Jun 15 10:53:17 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id BBF963B04EA for ; Thu, 15 Jun 2006 10:53:17 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17592-10 for ; Thu, 15 Jun 2006 10:53:16 -0400 (EDT) Received: from holken.mikan.net (holken.mikan.net [83.145.56.183]) by menubar.gnome.org (Postfix) with ESMTP id 035EF3B04E7 for ; Thu, 15 Jun 2006 10:53:15 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by holken.mikan.net (Postfix) with ESMTP id C0DB83352B4; Thu, 15 Jun 2006 16:52:21 +0200 (CEST) Received: from holken.mikan.net ([127.0.0.1]) by localhost (holken.mikan.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16765-03; Thu, 15 Jun 2006 16:52:18 +0200 (CEST) Received: from birnet.org (c152167.adsl.hansenet.de [213.39.152.167]) by holken.mikan.net (Postfix) with ESMTP id E3B0433529D; Thu, 15 Jun 2006 16:52:17 +0200 (CEST) Received: from master.birnet.private (localhost.localdomain [127.0.0.1]) by birnet.org (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k5FEqH2d008152 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 15 Jun 2006 16:52:18 +0200 Received: (from timj@localhost) by master.birnet.private (8.13.4/8.13.4/Submit) id k5FEqHpN008151; Thu, 15 Jun 2006 16:52:17 +0200 Date: Thu, 15 Jun 2006 16:52:17 +0200 (CEST) From: Tim Janik X-X-Sender: timj@master.birnet.private To: Fontana Nicola Subject: Re: GObject extension propose (GContainer) In-Reply-To: <200606151101.12868.ntd@users.sourceforge.net> Message-ID: References: <200606151101.12868.ntd@users.sourceforge.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at holken.mikan.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.38 tagged_above=-999 required=2 tests=[AWL=0.084, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.38 X-Spam-Level: Cc: Gtk+ Developers X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 14:53:17 -0000 On Thu, 15 Jun 2006, Fontana Nicola wrote: > Hi all, > > I'm a GObject based libraries (for UI purpose and not) user and I often need > a generic container to derive my own types. In my opinion, I think this > generic container must be included inside the GObject library ... it could > be used by a lot of derived libraries providing a common approach. > > I published my solution - that is, what I am currently using - on > sourceforge. > > http://sourceforge.net/projects/gcontainer/ > > Is it a good idea? Is something planned in this direction? Am I totally > wrong? > > I need feedbacks ... hi. your gcontainer-1.0.0 looks like an interesting approach to me, but i'm not sure it's generally good to put that into stock libgobject. the main reason is that container needs are probably pretty variable out there (i've come across at least 4 different gobject container implementations in free software projects i'm woorking on) and that both, making too little assumptions in the child/container interface isn't going to be very helpful, albeit making too many has the same problem. i guess we could add a link to your project from the libgobject docs (it should probably have a Contrib section), for people possibly looking for a GObject container implementation. that way, gcontainer-1.0.0 gets a chance of being reused and maybe extended to something generally usefull for GObject applications out there. > Nicola --- ciaoTJ From timj@gtk.org Thu Jun 15 11:31:19 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 642E33B02ED for ; Thu, 15 Jun 2006 11:31:19 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19431-03 for ; Thu, 15 Jun 2006 11:31:18 -0400 (EDT) Received: from holken.mikan.net (holken.mikan.net [83.145.56.183]) by menubar.gnome.org (Postfix) with ESMTP id 2E9543B0155 for ; Thu, 15 Jun 2006 11:31:18 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by holken.mikan.net (Postfix) with ESMTP id B5DB533524B; Thu, 15 Jun 2006 16:32:01 +0200 (CEST) Received: from holken.mikan.net ([127.0.0.1]) by localhost (holken.mikan.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16412-10; Thu, 15 Jun 2006 16:31:58 +0200 (CEST) Received: from birnet.org (c152167.adsl.hansenet.de [213.39.152.167]) by holken.mikan.net (Postfix) with ESMTP id D5D7E335256; Thu, 15 Jun 2006 16:31:57 +0200 (CEST) Received: from master.birnet.private (localhost.localdomain [127.0.0.1]) by birnet.org (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k5FEVrL1007682 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 15 Jun 2006 16:31:53 +0200 Received: (from timj@localhost) by master.birnet.private (8.13.4/8.13.4/Submit) id k5FEVis7007681; Thu, 15 Jun 2006 16:31:45 +0200 Date: Thu, 15 Jun 2006 16:31:44 +0200 (CEST) From: Tim Janik X-X-Sender: timj@master.birnet.private To: Matthias Clasen Subject: GTK+ meeting at GUADEC (Re: GTK+ 2.10, the endgame) In-Reply-To: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> Message-ID: References: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at holken.mikan.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.381 tagged_above=-999 required=2 tests=[AWL=0.083, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.381 X-Spam-Level: Cc: Gtk+ Developers X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 15:31:19 -0000 On Thu, 15 Jun 2006, Matthias Clasen wrote: > I want to have GTK+ 2.10 ready at or immediately after GUADEC. > Another thing I have slacked off about is organizing a GTK+ > team meeting at GUADEC. So, who of the GTK+ team is there > and at what times ? Should we try to find a free hour during > the core days, or does everybody stay for the after hours ? > If so, it may be easier to do a team meeting on Thursday... i think i volounteered to take on arrangement of that to some extend. at least, we intended to have a meeting on GTK+ linking issues, and could probably merge that with the GTK+ team meeting during guadec. the plan for that was to send out en email next friday/saturday (i.e right at the guadec start) to figure/suggest dates suitable for everyone to attend. > Matthias --- ciaoTJ From hfiguiere@teaser.fr Thu Jun 15 11:52:14 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C00CA3B0261 for ; Thu, 15 Jun 2006 11:52:14 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20706-05 for ; Thu, 15 Jun 2006 11:52:13 -0400 (EDT) Received: from xandros.com (smtp1.xandros.com [209.87.238.70]) by menubar.gnome.org (Postfix) with ESMTP id 6D7663B053A for ; Thu, 15 Jun 2006 11:52:13 -0400 (EDT) Received: from [172.16.1.95] (unknown [209.87.238.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by xandros.com (Postfix) with ESMTP id 4B02239025; Thu, 15 Jun 2006 11:51:30 -0400 (EDT) Message-ID: <44918201.6010605@teaser.fr> Date: Thu, 15 Jun 2006 11:51:29 -0400 From: Hubert Figuiere User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: Matthias Clasen Subject: Re: GTK+ 2.10, the endgame References: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> In-Reply-To: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.54 tagged_above=-999 required=2 tests=[AWL=0.059, BAYES_00=-2.599] X-Spam-Score: -2.54 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 15:52:14 -0000 Matthias Clasen wrote: > I want to have GTK+ 2.10 ready at or immediately after GUADEC. Can somebody summarize the Mac port status? Hub From tristan.van.berkom@gmail.com Thu Jun 15 12:44:57 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 0A0273B05DC for ; Thu, 15 Jun 2006 12:44:57 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23203-02 for ; Thu, 15 Jun 2006 12:44:56 -0400 (EDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.200]) by menubar.gnome.org (Postfix) with ESMTP id 0AD9C3B007F for ; Thu, 15 Jun 2006 12:44:55 -0400 (EDT) Received: by wx-out-0102.google.com with SMTP id i30so312681wxd for ; Thu, 15 Jun 2006 09:44:14 -0700 (PDT) Received: by 10.70.100.8 with SMTP id x8mr2494520wxb; Thu, 15 Jun 2006 09:44:14 -0700 (PDT) Received: from ?66.48.170.37? ( [66.48.170.37]) by mx.gmail.com with ESMTP id i39sm1649326wxd.2006.06.15.09.44.12; Thu, 15 Jun 2006 09:44:14 -0700 (PDT) Message-ID: <44919246.8060301@gnome.org> Date: Thu, 15 Jun 2006 13:00:54 -0400 User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Janik Subject: Re: GObject extension propose (GContainer) References: <200606151101.12868.ntd@users.sourceforge.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit From: Tristan Van Berkom X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.481 tagged_above=-999 required=2 tests=[AWL=-0.414, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=1.456, SPF_PASS=-0.001, TW_GT=0.077] X-Spam-Score: -1.481 X-Spam-Level: Cc: Gtk+ Developers X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 16:44:57 -0000 Tim Janik wrote: >On Thu, 15 Jun 2006, Fontana Nicola wrote: > > > >>Hi all, >> >>I'm a GObject based libraries (for UI purpose and not) user and I often need >>a generic container to derive my own types. In my opinion, I think this >>generic container must be included inside the GObject library ... it could >>be used by a lot of derived libraries providing a common approach. >> >>I published my solution - that is, what I am currently using - on >>sourceforge. >> >>http://sourceforge.net/projects/gcontainer/ >> >>Is it a good idea? Is something planned in this direction? Am I totally >>wrong? >> >>I need feedbacks ... >> >> As a side note... I've been working on container --> child relationships and honing them down inside the glade builder... objects may for example have object delagates that are "owned" and in turn may "own" other delagates... this is all functional with libglade facilities and the future gtk builder also (from the design as of yet...)... this concept of "types of container relationships" is also usefull for GtkMenuShell --> GtkMenu for example (not just any GtkWidget can be added to a menushell). All of that just to say... I cannot count the times I've thought to myself that GtkContainer should really just be GContainerIface, and implemented by whatever interested objects that want to parent other objects... I think that what we need is not really "yet another container api", but a container api that is a unified front for generic handling of the GTK object hierarchy at runtime. Cheers, -Tristan From federico@ximian.com Thu Jun 15 12:56:13 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 0DAD63B03FF for ; Thu, 15 Jun 2006 12:56:13 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23665-06 for ; Thu, 15 Jun 2006 12:56:06 -0400 (EDT) Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) by menubar.gnome.org (Postfix) with ESMTP id 688823B0613 for ; Thu, 15 Jun 2006 12:56:05 -0400 (EDT) Received: (qmail 25104 invoked from network); 15 Jun 2006 16:54:53 -0000 Received: from localhost (HELO 164-99-120-38.boston.ximian.com) (127.0.0.1) by localhost with SMTP; 15 Jun 2006 16:54:53 -0000 Subject: Re: GTK+ 2.10, the endgame From: Federico Mena Quintero To: Matthias Clasen In-Reply-To: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> References: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> Content-Type: text/plain Date: Thu, 15 Jun 2006 11:50:29 -0500 Message-Id: <1150390229.17566.191.camel@cacharro.xalalinux.org> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.575 tagged_above=-999 required=2 tests=[AWL=0.024, BAYES_00=-2.599] X-Spam-Score: -2.575 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 16:56:13 -0000 On Thu, 2006-06-15 at 09:56 -0400, Matthias Clasen wrote: > Therefore, I want to consider 2.9.3 api frozen, and take a > look at what still needs to happen before 2.10. Here are some > things I personally would like get worked on (not sure > how much time I can free to look into these myself): > > - I think the async filechooser conversion has caused some > regressions, I noticed that .hidden support seems broken > and autocompletion also behaved badly for me recently. Yes, it's quite broken at the moment. I don't think we can do any more productive debugging (fixing something breaks something else) until we have a good set of automated tests for the basic behaviors. > - There is a number of FIXMEs and unimplemented bits in > the print code. > > - The print backends need a careful look wrt to memory leaks > and error reporting. I'm rather worried of declaring the printing API as stable and just unleashing it to the world. Is any software *really* using it? Does it contemplate things like - sites with thousands of printers - sites which want to lock-down certain printers - color management for apps that need it > Another thing I have slacked off about is organizing a GTK+ > team meeting at GUADEC. So, who of the GTK+ team is there > and at what times ? Should we try to find a free hour during > the core days, or does everybody stay for the after hours ? > If so, it may be easier to do a team meeting on Thursday... I'll be there since Sunday morning. Thursday is the Advisory Board meeting, so I'm afraid I won't have that day free for the GTK+ meeeting. Federico From mclasen@redhat.com Thu Jun 15 13:15:33 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id BC2163B0187 for ; Thu, 15 Jun 2006 13:15:33 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24531-03 for ; Thu, 15 Jun 2006 13:15:29 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id DCC933B0227 for ; Thu, 15 Jun 2006 13:15:28 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5FHDjVa014384; Thu, 15 Jun 2006 13:13:45 -0400 Received: from lacrosse.corp.redhat.com (lacrosse.corp.redhat.com [172.16.52.154]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5FHDjmo017834; Thu, 15 Jun 2006 13:13:45 -0400 Received: from [172.16.83.98] (dhcp83-98.boston.redhat.com [172.16.83.98]) by lacrosse.corp.redhat.com (8.12.11.20060308/8.11.6) with ESMTP id k5FHDjGC025752; Thu, 15 Jun 2006 13:13:45 -0400 Subject: Re: GTK+ 2.10, the endgame From: Matthias Clasen To: Federico Mena Quintero In-Reply-To: <1150390229.17566.191.camel@cacharro.xalalinux.org> References: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> <1150390229.17566.191.camel@cacharro.xalalinux.org> Content-Type: text/plain Organization: Red Hat Date: Thu, 15 Jun 2006 13:15:37 -0400 Message-Id: <1150391737.3187.33.camel@dhcp83-98.boston.redhat.com> Mime-Version: 1.0 X-Mailer: Evolution 2.7.3 (2.7.3-2) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.542 tagged_above=-999 required=2 tests=[AWL=0.059, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.542 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 17:15:33 -0000 On Thu, 2006-06-15 at 11:50 -0500, Federico Mena Quintero wrote: > On Thu, 2006-06-15 at 09:56 -0400, Matthias Clasen wrote: > > > Therefore, I want to consider 2.9.3 api frozen, and take a > > look at what still needs to happen before 2.10. Here are some > > things I personally would like get worked on (not sure > > how much time I can free to look into these myself): > > > > - I think the async filechooser conversion has caused some > > regressions, I noticed that .hidden support seems broken > > and autocompletion also behaved badly for me recently. > > Yes, it's quite broken at the moment. I don't think we can do any more > productive debugging (fixing something breaks something else) until we > have a good set of automated tests for the basic behaviors. Quite unfortunate. We spent too much time working on finetuning the filechooser behaviour to leave it broken now... > > - There is a number of FIXMEs and unimplemented bits in > > the print code. > > > > - The print backends need a careful look wrt to memory leaks > > and error reporting. > > I'm rather worried of declaring the printing API as stable and just > unleashing it to the world. Is any software *really* using it? Does it > contemplate things like Typical chicken and egg problem that won't be solved by keeping it unreleased for another year. There is no way to get any software _really_ using it without releasing it first. We got quite a bit of feedback from people looking at porting real apps to it (e.g gedit, OOo and epiphany), so it is not as if we release it straight from the whiteboard. > - sites with thousands of printers > > - sites which want to lock-down certain printers > > - color management for apps that need it No doubt that we may have to add new api in 2.12 to accomodate things like this, but all of these are special cases. From muntyan@tamu.edu Thu Jun 15 15:05:44 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 9364F3B0605 for ; Thu, 15 Jun 2006 15:05:44 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28754-04 for ; Thu, 15 Jun 2006 15:05:41 -0400 (EDT) Received: from smtp103.vzn.mail.mud.yahoo.com (smtp103.vzn.mail.mud.yahoo.com [68.142.203.47]) by menubar.gnome.org (Postfix) with SMTP id 568873B05C3 for ; Thu, 15 Jun 2006 15:05:40 -0400 (EDT) Received: (qmail 34334 invoked from network); 15 Jun 2006 19:05:00 -0000 Received: from unknown (HELO ?192.168.3.9?) (muntyan@verizon.net@71.113.224.59 with plain) by smtp103.vzn.mail.mud.yahoo.com with SMTP; 15 Jun 2006 19:04:59 -0000 Message-ID: <4491AF5A.2050702@tamu.edu> Date: Thu, 15 Jun 2006 14:04:58 -0500 From: Yevgen Muntyan User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20060216 Debian/1.7.12-1.1ubuntu2 X-Accept-Language: en MIME-Version: 1.0 To: GTK Devel List Subject: Printing and blocking ui Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.552 tagged_above=-999 required=2 tests=[AWL=0.047, BAYES_00=-2.599] X-Spam-Score: -2.552 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 19:05:44 -0000 Hi there, I print a text document from GtkTextView here. There is a problem with pagination: pagination is potentially slow, so some sort of progress dialog should be shown during it. From the other hand, the text buffer must not be modified during pagination. How to solve it? Should I show my own modal dialog and make sure user doesn't modify the buffer, or GtkPrintOperation can take care of it? Actually, it would be good to ensure printing blocks the text widget too, since in this case it wouldn't be necessary to calculate and store all the pango layouts in begin-print. Maybe just show a modal dialog between begin-print and end-print. Thanks, Yevgen From richard@imendio.com Thu Jun 15 15:08:15 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C90B13B02BF for ; Thu, 15 Jun 2006 15:08:15 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28754-07 for ; Thu, 15 Jun 2006 15:08:14 -0400 (EDT) Received: from holken.mikan.net (holken.mikan.net [83.145.56.183]) by menubar.gnome.org (Postfix) with ESMTP id 47EFB3B018C for ; Thu, 15 Jun 2006 15:08:14 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by holken.mikan.net (Postfix) with ESMTP id 418C111EB4; Thu, 15 Jun 2006 21:07:02 +0200 (CEST) Received: from holken.mikan.net ([127.0.0.1]) by localhost (holken.mikan.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04160-07; Thu, 15 Jun 2006 21:06:58 +0200 (CEST) Received: from [192.168.100.5] (c83-248-134-21.bredband.comhem.se [83.248.134.21]) by holken.mikan.net (Postfix) with ESMTP id E679E1459D; Thu, 15 Jun 2006 21:06:57 +0200 (CEST) Message-ID: <4491AFD0.5000408@imendio.com> Date: Thu, 15 Jun 2006 21:06:56 +0200 From: Richard Hult Organization: Imendio AB User-Agent: Thunderbird 1.5.0.4 (Macintosh/20060530) MIME-Version: 1.0 To: Hubert Figuiere Subject: Re: GTK+ 2.10, the endgame References: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> <44918201.6010605@teaser.fr> In-Reply-To: <44918201.6010605@teaser.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at holken.mikan.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.543 tagged_above=-999 required=2 tests=[AWL=0.056, BAYES_00=-2.599] X-Spam-Score: -2.543 X-Spam-Level: Cc: gtk-devel-list@gnome.org, Matthias Clasen X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 19:08:16 -0000 Hubert Figuiere skrev: > Matthias Clasen wrote: >> I want to have GTK+ 2.10 ready at or immediately after GUADEC. > > Can somebody summarize the Mac port status? The basic functionality is implemented and what's next in the pipeline is bug fixing, and after that looking into tighter integration with the platform in various areas. /Richard From muntyan@tamu.edu Thu Jun 15 15:12:58 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 9FC7E3B063D for ; Thu, 15 Jun 2006 15:12:58 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29079-06 for ; Thu, 15 Jun 2006 15:12:57 -0400 (EDT) Received: from smtp101.vzn.mail.mud.yahoo.com (smtp101.vzn.mail.mud.yahoo.com [68.142.203.45]) by menubar.gnome.org (Postfix) with SMTP id E72693B0613 for ; Thu, 15 Jun 2006 15:12:56 -0400 (EDT) Received: (qmail 97288 invoked from network); 15 Jun 2006 19:11:44 -0000 Received: from unknown (HELO ?192.168.3.9?) (muntyan@verizon.net@71.113.224.59 with plain) by smtp101.vzn.mail.mud.yahoo.com with SMTP; 15 Jun 2006 19:11:43 -0000 Message-ID: <4491B0EE.3040900@tamu.edu> Date: Thu, 15 Jun 2006 14:11:42 -0500 From: Yevgen Muntyan User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20060216 Debian/1.7.12-1.1ubuntu2 X-Accept-Language: en MIME-Version: 1.0 To: gtk-devel-list@gnome.org Subject: Re: GTK+ 2.10, the endgame References: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> <1150390229.17566.191.camel@cacharro.xalalinux.org> In-Reply-To: <1150390229.17566.191.camel@cacharro.xalalinux.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.514 tagged_above=-999 required=2 tests=[AWL=0.008, BAYES_00=-2.599, TW_GT=0.077] X-Spam-Score: -2.514 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 19:12:58 -0000 Federico Mena Quintero wrote: >On Thu, 2006-06-15 at 09:56 -0400, Matthias Clasen wrote: > > >>- The print backends need a careful look wrt to memory leaks >> and error reporting. >> >> > >I'm rather worried of declaring the printing API as stable and just >unleashing it to the world. Is any software *really* using it? > > Yes, there is software which is going to use gtk printing as soon as gtk-2.10 is released. And there will be much more when gtk has printing. Just think for a moment about gtk-but-not-gnome applications (win32 comes to mind too). > - sites with thousands of printers > > - sites which want to lock-down certain printers > > - color management for apps that need it > > If gtk can print to a single user's printer, it's already worth releasing. Again, there are applications which do not have printing, because they can't use gnomeprint, and developers don't feel like implement their own printing while gtk is going to get it. IMHO, etc., you know. Best regards, Yevgen From gnome-gtk-devel-list@m.gmane.org Thu Jun 15 16:40:15 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 2360D3B00D0 for ; Thu, 15 Jun 2006 16:40:15 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32360-05 for ; Thu, 15 Jun 2006 16:40:13 -0400 (EDT) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by menubar.gnome.org (Postfix) with ESMTP id 3B9113B0237 for ; Thu, 15 Jun 2006 16:40:13 -0400 (EDT) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1FqydG-0004Vk-6i for gtk-devel-list@gnome.org; Thu, 15 Jun 2006 22:40:02 +0200 Received: from cpe0004e2d9f884-cm0013718690da.cpe.net.cable.rogers.com ([70.24.212.140]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 15 Jun 2006 22:40:02 +0200 Received: from jasonspiro4+news by cpe0004e2d9f884-cm0013718690da.cpe.net.cable.rogers.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 15 Jun 2006 22:40:02 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gtk-devel-list@gnome.org From: Jason Spiro Subject: Imagine: what if points in Bugzilla had a significant effect? Date: Thu, 15 Jun 2006 19:15:34 +0000 (UTC) Lines: 15 Message-ID: X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cpe0004e2d9f884-cm0013718690da.cpe.net.cable.rogers.com User-Agent: slrn/0.9.8.1pl1 (Debian) Sender: news X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.601 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.601 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 20:40:15 -0000 Imagine: what if points did something in Bugzilla, like, the more points you have, the more votes you get? I think this would encourage people to file more bug reports, both good bug reports and not-so-good ones. Would that be a net gain or a net loss for GTK+? Regards, Jason Spiro -- Jason Spiro: computer consulting with a smile. Specializing in Linux: Red Hat AS / ES, Debian, and others. Serving homes and companies globally via remote access tools. Fair rates. Just email jasonspiro4@gmail.com or call Skype ID jasonspiro. From murrayc@murrayc.com Fri Jun 16 04:53:13 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id D68413B0007 for ; Fri, 16 Jun 2006 04:53:12 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23115-03 for ; Fri, 16 Jun 2006 04:53:08 -0400 (EDT) Received: from swarthymail-a5.dreamhost.com (sd-green-bigip-176.dreamhost.com [208.97.132.176]) by menubar.gnome.org (Postfix) with ESMTP id 7FA303B006C for ; Fri, 16 Jun 2006 04:53:08 -0400 (EDT) Received: from noname (p5497E1BF.dip.t-dialin.net [84.151.225.191]) by swarthymail-a5.dreamhost.com (Postfix) with ESMTP id 69FE4109E8B; Fri, 16 Jun 2006 01:52:14 -0700 (PDT) Subject: Re: GTK+ 2.10, the endgame From: Murray Cumming To: Matthias Clasen In-Reply-To: <1150391737.3187.33.camel@dhcp83-98.boston.redhat.com> References: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> <1150390229.17566.191.camel@cacharro.xalalinux.org> <1150391737.3187.33.camel@dhcp83-98.boston.redhat.com> Content-Type: text/plain Date: Fri, 16 Jun 2006 10:52:10 +0200 Message-Id: <1150447930.5806.4.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.481 tagged_above=-999 required=2 tests=[AWL=0.118, BAYES_00=-2.599] X-Spam-Score: -2.481 X-Spam-Level: Cc: Federico Mena Quintero , gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2006 08:53:13 -0000 I'm also concerned about the recent files stuff. Do we now have UIManager integration of that? -- Murray Cumming murrayc@murrayc.com www.murrayc.com www.openismus.com From murrayc@murrayc.com Fri Jun 16 05:06:58 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id A76AC3B0076 for ; Fri, 16 Jun 2006 05:06:58 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23550-01 for ; Fri, 16 Jun 2006 05:06:57 -0400 (EDT) Received: from kungfu.dreamhost.com (kungfu.dreamhost.com [66.33.216.126]) by menubar.gnome.org (Postfix) with ESMTP id D099D3B006B for ; Fri, 16 Jun 2006 05:06:57 -0400 (EDT) Received: from swarthymail-a4.dreamhost.com (sd-green-bigip-62.dreamhost.com [208.97.132.62]) by kungfu.dreamhost.com (Postfix) with ESMTP id 708B51F0265 for ; Fri, 16 Jun 2006 01:28:47 -0700 (PDT) Received: from noname (p5497E1BF.dip.t-dialin.net [84.151.225.191]) by swarthymail-a4.dreamhost.com (Postfix) with ESMTP id 0D51A129A83; Fri, 16 Jun 2006 01:28:10 -0700 (PDT) Subject: Re: GTK+ 2.10, the endgame From: Murray Cumming To: Matthias Clasen In-Reply-To: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> References: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> Content-Type: text/plain Date: Thu, 15 Jun 2006 23:20:27 +0200 Message-Id: <1150406427.30234.1.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.068 tagged_above=-999 required=2 tests=[AWL=-0.296, BAYES_00=-2.599, DATE_IN_PAST_06_12=0.827] X-Spam-Score: -2.068 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2006 09:06:58 -0000 On Thu, 2006-06-15 at 09:56 -0400, Matthias Clasen wrote: > I want to have GTK+ 2.10 ready at or immediately after GUADEC. [snip] I'd rather it was after rather than before. That gives us just a little more time to get everything wrapped quickly for gtkmm, which might show some small problems that need fixing. Maybe I haven't been paying attention, but I'm surprised (again) by the freeze announcement. -- Murray Cumming murrayc@murrayc.com www.murrayc.com www.openismus.com From mgiannakidis@gmail.com Thu Jun 15 11:24:35 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id B7BE73B0211 for ; Thu, 15 Jun 2006 11:24:35 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19150-09 for ; Thu, 15 Jun 2006 11:24:34 -0400 (EDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.188]) by menubar.gnome.org (Postfix) with ESMTP id AAD863B04FC for ; Thu, 15 Jun 2006 11:24:33 -0400 (EDT) Received: by nf-out-0910.google.com with SMTP id c2so90382nfe for ; Thu, 15 Jun 2006 08:23:41 -0700 (PDT) Received: by 10.48.47.15 with SMTP id u15mr674329nfu; Thu, 15 Jun 2006 08:23:39 -0700 (PDT) Received: from ?213.140.137.120? ( [213.140.137.120]) by mx.gmail.com with ESMTP id n22sm2029009nfc.2006.06.15.08.23.38; Thu, 15 Jun 2006 08:23:39 -0700 (PDT) From: Michalis Giannakidis To: gtk-devel-list@gnome.org Subject: gslice allocator: general impresions. Date: Thu, 15 Jun 2006 18:27:45 +0300 User-Agent: KMail/1.8.3 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200606151827.45477.mgiannakidis@gmail.com> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.6 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.6 X-Spam-Level: X-Mailman-Approved-At: Fri, 16 Jun 2006 05:29:57 -0400 X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 15:24:35 -0000 Dear Glib team, I have recently used the glib-glice allocator in a very malloc intensive application, and I would like to share a few observations I made, with you. The typical size I send to g_slice_alloc is 20 and 76 bytes (32 bit build). The total memory consumed by my application has decreased - which is great! However it `seems' to me, that this decrease in size is larger for the 64bit build compared to the 32bit build. (I have modified gslice to align a chunk to its own size so that I don't have unused memory between chunks eg: request 20 and get 24...) In my application now I use both g_slice_alloc and malloc.Testing the new allocator in linux I came accross the following: After using g_slice_alloc to alloc a great amount of data (eg 1500mb), each of them being 20 or 76 bytes in size, subsequent calls to malloc(8*1024) or similar sizes take much longer (the allocation does _not_ got to the swap). Also if I chage the min_page_size from 128 to 4096, then the subsequent calls to malloc(8*1024) or similar sizes take even longer. It takes for ever in the 64 bit build! Moreover, even with min_page_size set to 128, the calls to malloc take for ever on a Linux 2.4.20 glibc-2.2.4(glibc up to 2.2.5 has a broken posix_memalign so I fallback to memalign). In all of the cases above, malloc responds much faster when the gslice allocator is turned off. I know I should be providing sample code and test programms here to back up my observations. I also understand that I should provide execution times instead of just stating that the calls to malloc take for ever. I would like to ask you, if there are any known issues in mixing gslice and malloc calls in malloc intensive applications. Any suggested readings would be most welcome. Regards Michalis -- Michalis Giannakidis From timj@gtk.org Fri Jun 16 07:30:05 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id EEDE23B0011 for ; Fri, 16 Jun 2006 07:30:04 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26976-06 for ; Fri, 16 Jun 2006 07:30:04 -0400 (EDT) Received: from holken.mikan.net (holken.mikan.net [83.145.56.183]) by menubar.gnome.org (Postfix) with ESMTP id DA78D3B0007 for ; Fri, 16 Jun 2006 07:30:03 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by holken.mikan.net (Postfix) with ESMTP id BDFA43352B0; Fri, 16 Jun 2006 13:28:54 +0200 (CEST) Received: from holken.mikan.net ([127.0.0.1]) by localhost (holken.mikan.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29662-08; Fri, 16 Jun 2006 13:28:48 +0200 (CEST) Received: from birnet.org (d003098.adsl.hansenet.de [80.171.3.98]) by holken.mikan.net (Postfix) with ESMTP id DFB2633525A; Fri, 16 Jun 2006 13:28:47 +0200 (CEST) Received: from master.birnet.private (localhost.localdomain [127.0.0.1]) by birnet.org (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k5GBSi9S008066 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 16 Jun 2006 13:28:44 +0200 Received: (from timj@localhost) by master.birnet.private (8.13.4/8.13.4/Submit) id k5GBSZMj008064; Fri, 16 Jun 2006 13:28:35 +0200 Date: Fri, 16 Jun 2006 13:28:35 +0200 (CEST) From: Tim Janik X-X-Sender: timj@master.birnet.private To: "Gustavo J. A. M. Carneiro" Subject: Re: GObject extension propose (GContainer) In-Reply-To: <1150456522.5305.12.camel@localhost.localdomain> Message-ID: References: <200606151101.12868.ntd@users.sourceforge.net> <44919246.8060301@gnome.org> <1150456522.5305.12.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="656239-2144330416-1150457315=:7955" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at holken.mikan.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.677 tagged_above=-999 required=2 tests=[AWL=-0.669, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, RCVD_IN_SORBS_WEB=1.456] X-Spam-Score: -1.677 X-Spam-Level: Cc: Gtk+ Developers X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2006 11:30:05 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --656239-2144330416-1150457315=:7955 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Fri, 16 Jun 2006, Gustavo J. A. M. Carneiro wrote: > Qui, 2006-06-15 =E0s 13:00 -0400, Tristan Van Berkom escreveu: >> All of that just to say... I cannot count the times I've thought to >> myself that >> GtkContainer should really just be GContainerIface, and implemented by >> whatever interested objects that want to parent other objects... > > That's interesting, but I wonder what is the runtime penalty of > interface lookup compared to normal class structure lookup? Is it > really OK to use an interface for this, or is it better just to add a > new virtual methods to the GObject class? the lookup penalties are negligible. type node/class lookups and is_a checks are O(1); interface class lookups and conforms_to checks are O(ld(N)), where N is the number of interfaces a type node conforms to. > Gustavo J. A. M. Carneiro --- ciaoTJ --656239-2144330416-1150457315=:7955-- From gjc@inescporto.pt Fri Jun 16 07:34:21 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 74BCC3B000B for ; Fri, 16 Jun 2006 07:34:21 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26977-07 for ; Fri, 16 Jun 2006 07:34:20 -0400 (EDT) Received: from animal.inescn.pt (correio.inescn.pt [194.117.24.9]) by menubar.gnome.org (Postfix) with ESMTP id 5B7183B0011 for ; Fri, 16 Jun 2006 07:34:19 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by animal.inescn.pt (8.13.6/8.13.6/7) with ESMTP id k5GBFdIJ028014; Fri, 16 Jun 2006 12:15:39 +0100 (WEST) Received: from pong.inescporto.pt (pong.inescn.pt [194.117.26.74]) by animal.inescn.pt (8.13.6/8.13.6/5) with ESMTP id k5GBFT0a027999; Fri, 16 Jun 2006 12:15:29 +0100 (WEST) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by pong.inescporto.pt (Postfix) with ESMTP id AE13A39D8; Fri, 16 Jun 2006 12:12:16 +0100 (WEST) Subject: Re: GObject extension propose (GContainer) From: "Gustavo J. A. M. Carneiro" To: Tristan Van Berkom In-Reply-To: <44919246.8060301@gnome.org> References: <200606151101.12868.ntd@users.sourceforge.net> <44919246.8060301@gnome.org> Content-Type: text/plain; charset=UTF-8 Date: Fri, 16 Jun 2006 12:15:21 +0100 Message-Id: <1150456522.5305.12.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at inescporto.pt X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.39 tagged_above=-999 required=2 tests=[AWL=-0.002, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, SPF_PASS=-0.001, TW_GT=0.077] X-Spam-Score: -2.39 X-Spam-Level: Cc: Gtk+ Developers , Tim Janik X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2006 11:34:21 -0000 Qui, 2006-06-15 s 13:00 -0400, Tristan Van Berkom escreveu: > Tim Janik wrote: > > >On Thu, 15 Jun 2006, Fontana Nicola wrote: > > > > > > > >>Hi all, > >> > >>I'm a GObject based libraries (for UI purpose and not) user and I often need > >>a generic container to derive my own types. In my opinion, I think this > >>generic container must be included inside the GObject library ... it could > >>be used by a lot of derived libraries providing a common approach. > >> > >>I published my solution - that is, what I am currently using - on > >>sourceforge. > >> > >>http://sourceforge.net/projects/gcontainer/ > >> > >>Is it a good idea? Is something planned in this direction? Am I totally > >>wrong? > >> > >>I need feedbacks ... > >> > >> > As a side note... I've been working on container --> child relationships and > honing them down inside the glade builder... objects may for example have > object delagates that are "owned" and in turn may "own" other delagates... > this is all functional with libglade facilities and the future gtk > builder also > (from the design as of yet...)... this concept of "types of container > relationships" > is also usefull for GtkMenuShell --> GtkMenu for example (not just any > GtkWidget > can be added to a menushell). > > All of that just to say... I cannot count the times I've thought to > myself that > GtkContainer should really just be GContainerIface, and implemented by > whatever interested objects that want to parent other objects... That's interesting, but I wonder what is the runtime penalty of interface lookup compared to normal class structure lookup? Is it really OK to use an interface for this, or is it better just to add a new virtual methods to the GObject class? > I think > that what we need is not really "yet another container api", but a container > api that is a unified front for generic handling of the GTK object > hierarchy at runtime. Actually, for the python language bindings we could use a generic GObject container interface. See http://bugzilla.gnome.org/show_bug.cgi?id=303266 Regards. -- Gustavo J. A. M. Carneiro The universe is always one step beyond logic From alan@clueserver.org Fri Jun 16 12:57:14 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 502C63B0336 for ; Fri, 16 Jun 2006 12:57:14 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06317-07 for ; Fri, 16 Jun 2006 12:57:08 -0400 (EDT) Received: from clueserver.org (216-99-213-120.dsl.aracnet.com [216.99.213.120]) by menubar.gnome.org (Postfix) with ESMTP id 7529F3B041B for ; Fri, 16 Jun 2006 12:54:18 -0400 (EDT) Received: by clueserver.org (Postfix, from userid 500) id 2985BF50BE2; Fri, 16 Jun 2006 09:53:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by clueserver.org (Postfix) with ESMTP id 26461F50BE1; Fri, 16 Jun 2006 09:53:44 -0700 (PDT) Date: Fri, 16 Jun 2006 09:53:44 -0700 (PDT) From: alan X-X-Sender: alan@blackbox.fnordora.org To: Jason Spiro Subject: Re: Imagine: what if points in Bugzilla had a significant effect? In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.45 tagged_above=-999 required=2 tests=[AWL=0.014, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.45 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2006 16:57:14 -0000 On Thu, 15 Jun 2006, Jason Spiro wrote: > Imagine: what if points did something in Bugzilla, like, the more points > you have, the more votes you get? Slashzilla? -- "Waiter! This lambchop tastes like an old sock!" - Sheri Lewis From ntd@users.sourceforge.net Fri Jun 16 14:08:36 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 39BE13B03E1 for ; Fri, 16 Jun 2006 14:08:36 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11017-04 for ; Fri, 16 Jun 2006 14:08:34 -0400 (EDT) Received: from mailout02.albacom.net (mailout02.albacom.net [217.220.34.14]) by menubar.gnome.org (Postfix) with SMTP id E2E913B00E4 for ; Fri, 16 Jun 2006 14:08:33 -0400 (EDT) Received: (qmail 21669 invoked by uid 507); 16 Jun 2006 18:08:08 -0000 Received: from ntd@users.sourceforge.net by mailout02.albacom.net with qmail-scanner (spamassassin: ???. Clear:RC:1(217.221.76.9):SA:0(0.0/15.0):. Processed in 0.841774 secs); 16 Jun 2006 18:08:08 -0000 Received: from unknown (HELO sviluppo.internet.local) (postmaster@effe-gi.it@217.221.76.9) by mailout02.albacom.net with SMTP; 16 Jun 2006 18:08:07 -0000 From: Fontana Nicola Organization: Elettronica EFFE-GI s.n.c. To: Tim Janik Subject: Re: GObject extension propose (GContainer) Date: Fri, 16 Jun 2006 20:44:11 +0000 User-Agent: KMail/1.9.1 References: <200606151101.12868.ntd@users.sourceforge.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200606162044.11716.ntd@users.sourceforge.net> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.526 tagged_above=-999 required=2 tests=[AWL=-0.004, BAYES_00=-2.599, TW_GT=0.077] X-Spam-Score: -2.526 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2006 18:08:36 -0000 > On Thu, 15 Jun 2006, Fontana Nicola wrote: > > Hi all, > > > > I'm a GObject based libraries (for UI purpose and not) user and I often > > need a generic container to derive my own types. In my opinion, I think > > this generic container must be included inside the GObject library ... it > > could be used by a lot of derived libraries providing a common approach. > > > > I published my solution - that is, what I am currently using - on > > sourceforge. > > > > http://sourceforge.net/projects/gcontainer/ > > > > Is it a good idea? Is something planned in this direction? Am I totally > > wrong? > > > > I need feedbacks ... > > hi. your gcontainer-1.0.0 looks like an interesting approach to me, but > i'm not sure it's generally good to put that into stock libgobject. > the main reason is that container needs are probably pretty variable > out there (i've come across at least 4 different gobject container > implementations in free software projects i'm woorking on) and that > both, making too little assumptions in the child/container interface > isn't going to be very helpful, albeit making too many has the > same problem. Some time ago I've started a communication library based on libgobject and I feeled the need of two things: a base object with floating reference and a container. After some time, I started an experimental cairo canvas and I had the same needs. In both cases, no gtk dependency was requested. Briefly, I'm not talking about a container that cover all needs and tastes but instead about "moving the GtkContainer logic and complexity" from gtk to gobject, something similar to what was done for GtkObject and its floating reference. I wrote gcontainer with this in mind (the GContainerable interface is "compatible" with GtkContainer and GChildable with GtkWidget). Anyway, my solution presents some serious problems: I'm misusing the interface to hide as much technical details as possible to the implementing objects. I know it is a huge task but consider this as an idea or a looooong term project: I don't think to be the only one with these needs. > > i guess we could add a link to your project from the libgobject docs > (it should probably have a Contrib section), for people possibly looking > for a GObject container implementation. that way, gcontainer-1.0.0 gets > a chance of being reused and maybe extended to something generally > usefull for GObject applications out there. > > > Nicola > > --- > ciaoTJ Of course I'll be glad to have a link in the gobject documentation. Thank you for your availability. Nicola From tristan.van.berkom@gmail.com Fri Jun 16 14:26:50 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id E38F43B0139 for ; Fri, 16 Jun 2006 14:26:49 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12245-08 for ; Fri, 16 Jun 2006 14:26:49 -0400 (EDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.197]) by menubar.gnome.org (Postfix) with ESMTP id DB55F3B0179 for ; Fri, 16 Jun 2006 14:26:48 -0400 (EDT) Received: by wx-out-0102.google.com with SMTP id i30so517779wxd for ; Fri, 16 Jun 2006 11:26:15 -0700 (PDT) Received: by 10.70.83.9 with SMTP id g9mr4369121wxb; Fri, 16 Jun 2006 11:20:03 -0700 (PDT) Received: from ?66.48.170.68? ( [66.48.170.68]) by mx.gmail.com with ESMTP id h39sm2692858wxd.2006.06.16.11.20.01; Fri, 16 Jun 2006 11:20:03 -0700 (PDT) Message-ID: <4492FA3C.5060106@gmail.com> Date: Fri, 16 Jun 2006 14:36:44 -0400 From: Tristan Van Berkom User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Fontana Nicola Subject: Re: GObject extension propose (GContainer) References: <200606151101.12868.ntd@users.sourceforge.net> <200606162044.11716.ntd@users.sourceforge.net> In-Reply-To: <200606162044.11716.ntd@users.sourceforge.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.497 tagged_above=-999 required=2 tests=[AWL=-0.353, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=1.456, SPF_PASS=-0.001] X-Spam-Score: -1.497 X-Spam-Level: Cc: gtk-devel-list@gnome.org, Tim Janik X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2006 18:26:50 -0000 Fontana Nicola wrote: [...] >I wrote gcontainer with this in mind (the GContainerable interface is >"compatible" with GtkContainer and GChildable with GtkWidget). Anyway, my >solution presents some serious problems: I'm misusing the interface to hide >as much technical details as possible to the implementing objects. > >I know it is a huge task but consider this as an idea or a looooong term >project: I don't think to be the only one with these needs. > > I think you may be overcomplicating things, if for example; the GContainerable or GContainerIface were implemented by GtkContainer; then nothing in GtkContainer derivatives would really have to change (unless the api was drasticly different... but I doubt that). Then this could be extended to other object sets and other needs without having to rewrite large pieces of code. Cheers, -Tristan From behdad.esfahbod@gmail.com Fri Jun 16 15:04:20 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 611EA3B00F8 for ; Fri, 16 Jun 2006 15:04:20 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15384-03 for ; Fri, 16 Jun 2006 15:04:18 -0400 (EDT) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.228]) by menubar.gnome.org (Postfix) with ESMTP id 566D33B007C for ; Fri, 16 Jun 2006 15:04:18 -0400 (EDT) Received: by wr-out-0506.google.com with SMTP id i4so618991wra for ; Fri, 16 Jun 2006 12:03:42 -0700 (PDT) Received: by 10.54.142.9 with SMTP id p9mr3126451wrd; Fri, 16 Jun 2006 11:57:25 -0700 (PDT) Received: from ?192.168.190.5? ( [72.136.156.47]) by mx.gmail.com with ESMTP id 10sm2200187wrl.2006.06.16.11.57.23; Fri, 16 Jun 2006 11:57:24 -0700 (PDT) Subject: Re: Imagine: what if points in Bugzilla had a significant effect? From: Behdad Esfahbod To: gtk-devel-list@gnome.org In-Reply-To: References: Content-Type: text/plain Date: Fri, 16 Jun 2006 14:57:22 -0400 Message-Id: <1150484242.15469.17.camel@home> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 (2.6.1-1.fc5.2) Content-Transfer-Encoding: 7bit Sender: Behdad Esfahbod X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.561 tagged_above=-999 required=2 tests=[AWL=-0.038, BAYES_00=-2.599, SPF_PASS=-0.001, TW_GT=0.077] X-Spam-Score: -2.561 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2006 19:04:20 -0000 On Thu, 2006-06-15 at 15:15 -0400, Jason Spiro wrote: > Imagine: what if points did something in Bugzilla, like, the more points > you have, the more votes you get? > > I think this would encourage people to file more bug reports, both good > bug reports and not-so-good ones. Would that be a net gain or a net loss > for GTK+? It has evolved to be like that already. The more points one has, the more he (or she, in the near future) respects bugs/comments from high-point others. Or at least that's been my experience. behdad > Regards, > Jason Spiro > > -- > Jason Spiro: computer consulting with a smile. > Specializing in Linux: Red Hat AS / ES, Debian, and others. > Serving homes and companies globally via remote access tools. Fair rates. > Just email jasonspiro4@gmail.com or call Skype ID jasonspiro. > > _______________________________________________ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-devel-list -- behdad http://behdad.org/ "Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill" -- Dan Bern, "New American Language" From grakic@devbase.net Fri Jun 16 16:12:39 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 7B9EC3B025A for ; Fri, 16 Jun 2006 16:12:39 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19416-03 for ; Fri, 16 Jun 2006 16:12:38 -0400 (EDT) Received: from mxout-04.mxes.net (mxout-04.mxes.net [205.237.194.35]) by menubar.gnome.org (Postfix) with ESMTP id 07A823B02B4 for ; Fri, 16 Jun 2006 16:12:37 -0400 (EDT) Received: from limun.local (unknown [87.116.163.93]) by smtp.mxes.net (Postfix) with ESMTP id C5307A3292; Fri, 16 Jun 2006 16:11:35 -0400 (EDT) Subject: Re: Imagine: what if points in Bugzilla had a significant effect? From: Goran Rakic To: Jason Spiro In-Reply-To: References: Content-Type: text/plain; charset=utf-8 Date: Fri, 16 Jun 2006 22:11:33 +0200 Message-Id: <1150488693.2273.3.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.6 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, SPF_HELO_PASS=-0.001] X-Spam-Score: -2.6 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2006 20:12:39 -0000 Lary Osterman has a nice writing on this topic titled "Measuring testers by test metrics doesn't." У čet, 15. 06 2006. у 19:15 +0000, Jason Spiro пише: > Imagine: what if points did something in Bugzilla, like, the more points > you have, the more votes you get? > > I think this would encourage people to file more bug reports, both good > bug reports and not-so-good ones. Would that be a net gain or a net loss > for GTK+? > > Regards, > Jason Spiro From ame1@extratech.com Fri Jun 16 17:02:33 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 2F9013B018C for ; Fri, 16 Jun 2006 17:02:33 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21327-05 for ; Fri, 16 Jun 2006 17:02:32 -0400 (EDT) Received: from portal2.extratech.com (portal.extratech.com [67.105.201.210]) by menubar.gnome.org (Postfix) with ESMTP id BB3BD3B01C8 for ; Fri, 16 Jun 2006 17:02:31 -0400 (EDT) Received: from zosma.extratech.com (zosma.extratech.com [192.168.0.41]) by portal2.extratech.com (8.12.11/8.12.11) with ESMTP id k5GL1Quq030485 for ; Fri, 16 Jun 2006 14:01:26 -0700 Subject: Re: GObject extension propose (GContainer) From: "Alan M. Evans" To: Gtk+ Developers In-Reply-To: References: <200606151101.12868.ntd@users.sourceforge.net> <44919246.8060301@gnome.org> <1150456522.5305.12.camel@localhost.localdomain> Content-Type: text/plain; charset=UTF-8 Message-Id: <1150491686.19405.355.camel@zosma.extratech.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 16 Jun 2006 14:01:26 -0700 Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV 0.86.1/1544/Fri Jun 16 02:19:15 2006 on portal2.extratech.com X-Virus-Status: Clean X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.556 tagged_above=-999 required=2 tests=[AWL=0.044, BAYES_00=-2.599] X-Spam-Score: -2.556 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2006 21:02:33 -0000 On Fri, 2006-06-16 at 04:28, Tim Janik wrote: > On Fri, 16 Jun 2006, Gustavo J. A. M. Carneiro wrote: > > > Qui, 2006-06-15 s 13:00 -0400, Tristan Van Berkom escreveu: > > >> All of that just to say... I cannot count the times I've thought to > >> myself that > >> GtkContainer should really just be GContainerIface, and implemented by > >> whatever interested objects that want to parent other objects... > > > > That's interesting, but I wonder what is the runtime penalty of > > interface lookup compared to normal class structure lookup? Is it > > really OK to use an interface for this, or is it better just to add a > > new virtual methods to the GObject class? > > the lookup penalties are negligible. > type node/class lookups and is_a checks are O(1); > interface class lookups and conforms_to checks are O(ld(N)), where > N is the number of interfaces a type node conforms to. Your assertion that the penalties are negligable is not really supported by your response, unless the constant is also known for both orders. From ebassi@gmail.com Fri Jun 16 20:14:03 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 3E95D3B069B for ; Fri, 16 Jun 2006 20:14:03 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28883-03 for ; Fri, 16 Jun 2006 20:14:00 -0400 (EDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.185]) by menubar.gnome.org (Postfix) with ESMTP id 969133B015A for ; Fri, 16 Jun 2006 20:13:59 -0400 (EDT) Received: by nf-out-0910.google.com with SMTP id c2so667512nfe for ; Fri, 16 Jun 2006 17:13:07 -0700 (PDT) Received: by 10.49.72.13 with SMTP id z13mr2277195nfk; Fri, 16 Jun 2006 17:05:51 -0700 (PDT) Received: from ?192.168.1.74? ( [86.136.65.180]) by mx.gmail.com with ESMTP id y23sm3836170nfb.2006.06.16.17.05.51; Fri, 16 Jun 2006 17:05:51 -0700 (PDT) Subject: Re: GTK+ 2.10, the endgame From: Emmanuele Bassi To: gtk-devel-list@gnome.org In-Reply-To: <1150447930.5806.4.camel@localhost.localdomain> References: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> <1150390229.17566.191.camel@cacharro.xalalinux.org> <1150391737.3187.33.camel@dhcp83-98.boston.redhat.com> <1150447930.5806.4.camel@localhost.localdomain> Content-Type: text/plain Date: Sat, 17 Jun 2006 01:05:50 +0100 Message-Id: <1150502750.2668.12.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.34 tagged_above=-999 required=2 tests=[AWL=0.260, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.34 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2006 00:14:03 -0000 Hi Murray, On Fri, 2006-06-16 at 10:52 +0200, Murray Cumming wrote: > I'm also concerned about the recent files stuff. Do we now have > UIManager integration of that? No, and I am to blame because I had less time to spend on fixing this issue. Mostly, I've been stuck on how to implement an action for both the menu and toolbars using the same tag. In the meantime, a nice and clean way to integrate the GtkRecentChooserMenu inside a GtkUIManager is to subclass GtkAction into a custom action that automatically adds a recent chooser menu to the menu item it creates, and use a placeholder in the UI definition (most applications using EggRecentViewUIManager already have that placeholder present). A working example is available here: http://www.gnome.org/~ebassi/test-uimanager.c The action code itself is one hundred lines long and can easily be hidden inside an helper file; it's approximately how GtkRecentAction would be implemented, anyway. I hereby give permission to do whatever you want to do with it. I understand that it's sub-optimal, and hopefully this should really go away once there's an action inside GTK. Ciao, Emmanuele. -- Emmanuele Bassi, E: ebassi@gmail.com W: http://www.emmanuelebassi.net B: http://log.emmanuelebassi.net From behdad.esfahbod@gmail.com Mon Jun 12 17:52:45 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 162C73B02CD for ; Mon, 12 Jun 2006 17:52:45 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00303-05 for ; Mon, 12 Jun 2006 17:52:43 -0400 (EDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.206]) by menubar.gnome.org (Postfix) with ESMTP id 643023B0010 for ; Mon, 12 Jun 2006 17:52:43 -0400 (EDT) Received: by wx-out-0102.google.com with SMTP id h26so956965wxd for ; Mon, 12 Jun 2006 14:51:27 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:subject:from:to:content-type:date:message-id:mime-version:x-mailer:sender; b=HkVpdki0/g3XkGcHUm613LiH99RNWp83QpOiB04twtI9/oyY5QJs7xgUW9ugXUYWTW0FQESua3SiFes9GpwcHFnulMB+jmu6Frg1gjSTz94Z0WNKazKYJCx/0yCrKVvi+sIhO9793kd+R7hBbKFWLBqlIyo5yetvED1gx6HIjnc= Received: by 10.70.36.1 with SMTP id j1mr6891335wxj; Mon, 12 Jun 2006 14:44:52 -0700 (PDT) Received: from to-dhcp26.toronto.redhat.com ( [63.250.163.171]) by mx.gmail.com with ESMTP id h18sm3879342wxd.2006.06.12.14.44.50; Mon, 12 Jun 2006 14:44:51 -0700 (PDT) Subject: Pango-1.13.2 released [unstable] From: Behdad Esfahbod To: Pango Release Lists , gtk-app-devel-list@gnome.org, gtk-devel-list@gnome.org, gtk-i18n-list@gnome.org, gtk-list@gnome.org Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-HZBsNn3KdPR3jVVwB9gO" Date: Mon, 12 Jun 2006 17:44:37 -0400 Message-Id: <1150148678.10765.8.camel@home> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 (2.6.1-1.fc5.2) Sender: Behdad Esfahbod X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.6 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.6 X-Spam-Level: X-Mailman-Approved-At: Fri, 16 Jun 2006 05:27:53 -0400 X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2006 21:52:45 -0000 --=-HZBsNn3KdPR3jVVwB9gO Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Pango-1.13.2 is now available for download at: ftp://ftp.gtk.org/pub/gtk/v2.11/ or http://download.gnome.org/sources/pango/1.13/ 28a6ea9d43c4cd398e7352032f775401 pango-1.13.2.tar.bz2 17d78473c05fece044c6a3b44519b61f pango-1.13.2.tar.gz This is a development release leading up to Pango-1.14.0, which will be released just in time for GNOME-2.16. Notes: * This is unstable development release. While it has had fairly extensive testing, there are likely bugs remaining to be found. This release should not be used in production. * Installing this version will overwrite your existing copy of Pango-1.12. If you have problems, you'll need to reinstall Pango-1.12.x * Bugs should be reported to http://bugzilla.gnome.org. About Pango =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Pango is a library for layout and rendering of text, with an emphasis on internationalization. Pango can be used anywhere that text layout is needed, though most of the work on Pango so far has been done in the context of the GTK+ widget toolkit. Pango forms the core of text and font handling for GTK+-2.x. Pango is designed to be modular; the core Pango layout engine can be used with different font backends. There are three basic backends, with multiple options for rendering with each. - Client side fonts using the FreeType and fontconfig libraries. Rendering can be with with Cairo or Xft libraries, or directly to an in-memory buffer with no additional libraries. - Native fonts on Microsoft Windows. (Optionally using Uniscribe for complex-text handling). Rendering can be done via Cairo or directly using the native Win32 API. - Native fonts on MacOS X, rendering via Cairo. The integration of Pango with Cairo (http://cairographics.org) provides a complete solution with high quality text handling and graphics rendering. Dynamically loaded modules then handle text layout for particular combinations of script and font backend. Pango ships with a wide selection of modules, including modules for Hebrew, Arabic, Hangul, Thai, and a number of Indic scripts. Virtually all of the world's major scripts are supported. As well as the low level layout rendering routines, Pango includes PangoLayout, a high level driver for laying out entire blocks of text, and routines to assist in editing internationalized text. More information about Pango is available from http://www.pango.org/. Pango 1.13.2 depends on version 2.10.0 or newer of the GLib library and version 1.1.2 or newer of the cairo library (if the cairo backend is desired); more information about GLib and cairo can be found at http://www.gtk.org/ and http://cairographics.org/ respectively. Overview of changes between 1.13.1 and 1.13.2 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D * Improved hexbox drawing, and font metrics calculations. * Synthesize italic variants on win32 [Hans Breuer] * New public API: - pango_cairo_show_error_underline - pango_cairo_error_underline_path - pango_font_describe_with_absolute_size * Misc fixes. * Bugs fixed in this release: Bug 326960 =E2=80=93 hex box drawing for win32 and atsui backends of cairo Bug 343717 =E2=80=93 License information in unclear. Bug 343355 =E2=80=93 Add pango_cairo_show_error_underline & pango_cairo_error_underline_path Bug 343966 =E2=80=93 pango Cygwin build fixes Patch from Cygwin Ports maintainer. Bug 343796 =E2=80=93 Italic Chinese character can't be show correctly in Win32. Bug 314114 =E2=80=93 max_x_advance not appropriate for approximate_(char|digit)_width Bug 341138 =E2=80=93 Using TTC font, Gtk2 programs begin to eating big mem= ory and have many cpu usage. Patch from Yong Li. Bug 336153 =E2=80=93 Mark to mark positioning (Lookup Type 6) isn't correc= t when using MarkAttchmentType Patch from Tin Myo Htet. Bug 333984 =E2=80=93 pango_language_from_string improvements Bug 125378 =E2=80=93 Better underline thickness handling Bug 339730 =E2=80=93 Pango needlessly falls back away from a Type 1 font i= nto a TTF font Bug 342562 =E2=80=93 Support absolute sizes in pango_font_description_to/from_string Bug 341922 =E2=80=93 pango should handle more characters as zero width Patch from Roozbeh Pournader Bug 342525 =E2=80=93 With PangoFc and PangoWin32, approximate digit width = is not what it says Bug 342079 =E2=80=93 pangoatsui-private.h missing from release Behdad Esfahbod 12 June 2006 --=-HZBsNn3KdPR3jVVwB9gO Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQBEjeBFn+4E5dNTERURApTwAJ9OvqbaG1xnQYzGPC9u0WPi30b6ggCfXNvZ oFfMwctzkAaKRETc/0aDRj0= =Wl7j -----END PGP SIGNATURE----- --=-HZBsNn3KdPR3jVVwB9gO-- From Klaus.Stengel@asamnet.de Tue Jun 13 06:57:05 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 1BD1E3B008F for ; Tue, 13 Jun 2006 06:57:05 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20572-03 for ; Tue, 13 Jun 2006 06:57:03 -0400 (EDT) Received: from mail.asamnet.de (mail.asamnet.de [194.25.81.18]) by menubar.gnome.org (Postfix) with ESMTP id A52473B000C for ; Tue, 13 Jun 2006 06:57:03 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.asamnet.de (Asamnet e.V. Mailserver) with ESMTP id D01E8A7076 for ; Tue, 13 Jun 2006 12:56:24 +0200 (CEST) Received: from mail.asamnet.de ([127.0.0.1]) by localhost (mail.asamnet.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00951-06 for ; Tue, 13 Jun 2006 12:56:24 +0200 (CEST) Received: from aquarian.nathanet.lan (p5492D6A6.dip.t-dialin.net [84.146.214.166]) by mail.asamnet.de (Asamnet e.V. Mailserver) with ESMTP id 6350FA7066 for ; Tue, 13 Jun 2006 12:56:24 +0200 (CEST) Subject: Pango memory leak in get_ruleset() in modules/basic/basic-fc.c From: Klaus Stengel To: gtk-devel-list@gnome.org Content-Type: text/plain Date: Tue, 13 Jun 2006 12:56:34 +0200 Message-Id: <1150196194.9594.16.camel@aquarian.nathanet.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at asamnet.de X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.464 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.464 X-Spam-Level: X-Mailman-Approved-At: Fri, 16 Jun 2006 05:27:53 -0400 X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2006 10:57:05 -0000 Hi, while working with the diagram editor "dia" I noticed a major memory leak when editing text objects. I tracked this down to a problem in the above function. From what I understand the function looks for an ruleset associated with the given font face and in case there is none, the ruleset is created with pango_ot_ruleset_new() and finally attached to the font face. The g_object_unref() is given as "notification callback" so that the ruleset is destroyed when the font face is finalized. In theory this should work, but unfortunately it doesn't in practice, because pango_ot_ruleset_new() internally references "info" itself, thus creating a circular dependency that keeps the objects alive indefinitely. Unfortunately I don't see an simple solution, except to drop that kind of caching again... Bye, Klaus. P.S.: Please reply to my email address as well, as I'm not subscribed to the list. From newren@gmail.com Sat Jun 17 01:54:29 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 7F2843B066E for ; Sat, 17 Jun 2006 01:54:29 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08609-05 for ; Sat, 17 Jun 2006 01:54:28 -0400 (EDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.198]) by menubar.gnome.org (Postfix) with ESMTP id 354E43B050E for ; Sat, 17 Jun 2006 01:54:28 -0400 (EDT) Received: by wx-out-0102.google.com with SMTP id h26so603851wxd for ; Fri, 16 Jun 2006 22:53:32 -0700 (PDT) Received: by 10.70.24.3 with SMTP id 3mr5192323wxx; Fri, 16 Jun 2006 22:53:32 -0700 (PDT) Received: by 10.70.102.9 with HTTP; Fri, 16 Jun 2006 22:53:32 -0700 (PDT) Message-ID: <51419b2c0606162253pfe0e7edsba8af3f8a1573477@mail.gmail.com> Date: Fri, 16 Jun 2006 23:53:32 -0600 From: "Elijah Newren" To: "Jason Spiro" Subject: Re: Imagine: what if points in Bugzilla had a significant effect? In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.572 tagged_above=-999 required=2 tests=[AWL=0.028, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.572 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2006 05:54:29 -0000 On 6/15/06, Jason Spiro wrote: > Imagine: what if points did something in Bugzilla, like, the more points > you have, the more votes you get? > > I think this would encourage people to file more bug reports, both good > bug reports and not-so-good ones. Would that be a net gain or a net loss > for GTK+? This isn't the right list for this email; bugzilla-devel or filed in bugzilla (against the bugzilla.gnome.org module) would be much better. Thanks, Elijah From timj@gtk.org Sat Jun 17 10:12:11 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id CD5003B00A6 for ; Sat, 17 Jun 2006 10:12:11 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23968-01 for ; Sat, 17 Jun 2006 10:12:08 -0400 (EDT) Received: from holken.mikan.net (holken.mikan.net [83.145.56.183]) by menubar.gnome.org (Postfix) with ESMTP id 34EA13B00D5 for ; Sat, 17 Jun 2006 10:12:07 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by holken.mikan.net (Postfix) with ESMTP id AC6413352A5; Sat, 17 Jun 2006 13:44:21 +0200 (CEST) Received: from holken.mikan.net ([127.0.0.1]) by localhost (holken.mikan.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07456-06; Sat, 17 Jun 2006 13:44:16 +0200 (CEST) Received: from birnet.org (d003096.adsl.hansenet.de [80.171.3.96]) by holken.mikan.net (Postfix) with ESMTP id 7CD8233524F; Sat, 17 Jun 2006 13:44:16 +0200 (CEST) Received: from master.birnet.private (localhost.localdomain [127.0.0.1]) by birnet.org (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k5HBiART015834 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 17 Jun 2006 13:44:11 +0200 Received: (from timj@localhost) by master.birnet.private (8.13.4/8.13.4/Submit) id k5HBhvjK015833; Sat, 17 Jun 2006 13:43:57 +0200 Date: Sat, 17 Jun 2006 13:43:57 +0200 (CEST) From: Tim Janik X-X-Sender: timj@master.birnet.private To: Michalis Giannakidis Subject: Re: gslice allocator: general impresions. In-Reply-To: <200606151827.45477.mgiannakidis@gmail.com> Message-ID: References: <200606151827.45477.mgiannakidis@gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at holken.mikan.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.339 tagged_above=-999 required=2 tests=[AWL=0.048, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, TW_TX=0.077] X-Spam-Score: -2.339 X-Spam-Level: Cc: Gtk+ Developers X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2006 14:12:12 -0000 On Thu, 15 Jun 2006, Michalis Giannakidis wrote: > Dear Glib team, > > I have recently used the glib-glice allocator in a very malloc intensive > application, and I would like to share a few observations I made, with you. > > The typical size I send to g_slice_alloc is 20 and 76 bytes (32 bit build). > The total memory consumed by my application has decreased - which is great! > However it `seems' to me, that this decrease in size is larger for the 64bit > build compared to the 32bit build. (I have modified gslice to align a chunk > to its own size so that I don't have unused memory between chunks eg: request > 20 and get 24...) you mean you've set P2ALIGNMENT to 1 * sizeof(void*) to get better granularity of the slices? have you left NATIVE_MALLOC_PADDING at 2*sizeof(void*) at least? (if not, memory fragmentation on some glibc systems and on all 64bit systems can become etxremely bad). > In my application now I use both g_slice_alloc and malloc.Testing the new > allocator in linux I came accross the following: > After using g_slice_alloc to alloc a great amount of data (eg 1500mb), each of > them being 20 or 76 bytes in size, subsequent calls to malloc(8*1024) or > similar sizes take much longer (the allocation does _not_ got to the swap). this is a magnitude of memory allocations where gslice hasn't been well tested. (my machine only has 1GB of memory for instance). while gslice should perform well even much beyond 1GB, i'd suspect that malloc()/memalign() don't, and thus could result in *some* GSlice slowdown as well. > Also if I chage the min_page_size from 128 to 4096, then the subsequent calls > to malloc(8*1024) or similar sizes take even longer. It takes for ever in the > 64 bit build! maybe due to your alignment tweaks. but maybe also because some malloc() buckets will have even longer lists that way. > Moreover, even with min_page_size set to 128, the calls to malloc take for > ever on a Linux 2.4.20 glibc-2.2.4(glibc up to 2.2.5 has a broken > posix_memalign so I fallback to memalign). broken in what way? > In all of the cases above, malloc responds much faster when the gslice > allocator is turned off. aparently some malloc implementations aren't too good at handling large numbers of page allocations. if modifying GSlice is an option for you, you could try to work around this at the expense of read-only allocation of the memory used by GSlice. to do that, you need to disable the HAVE_COMPLIANT_POSIX_MEMALIGN, HAVE_MEMALIGN and HAVE_VALLOC branches in allocator_memalign() and allocator_memfree() so the read-only malloc()-based fallback allocator is enabled. on 32bit systems, that'll by default allocate 16*4096=64k areas to allocate pages from. by doing: - const guint n_pages = 16; + const guint n_pages = 2560; you'll instead allocate 10MB areas, which should put far less stress on the system malloc() (that way, to fill 1GB, a maximum of 100 allocations are required). > I know I should be providing sample code and test programms here to back up > my observations. I also understand that I should provide execution times > instead of just stating that the calls to malloc take for ever. test programs would be great. allthough this kind of stress test can only be run and examined on a limited set of machines. e.g. the development machines i use have just 1GB and normally have only 30%-40% of free memory to spare for tests during runs like make check -C glib/test ;) > I would like to ask you, if there are any known issues in mixing gslice and > malloc calls in malloc intensive applications. > Any suggested readings would be most welcome. you've already seen the two papers cited in the big comment block at the start of gslice.c? it links to: http://citeseer.ist.psu.edu/bonwick94slab.html http://citeseer.ist.psu.edu/bonwick01magazines.html the first of which describes a kernel page allocator which isn't implemented by GSlice. we use memalign() instead, on the assumption that this is good enough for the vast majority of applications out there. if malloc is too stressed out by the aligned allocations gslice makes in your scenario, implementing this page allocator on top of mmap() and using that as a base allocator for gslice may be another option. > Regards > Michalis --- ciaoTJ From tristan.van.berkom@gmail.com Sat Jun 17 12:09:06 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 2E2D13B013A for ; Sat, 17 Jun 2006 12:09:06 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26133-07 for ; Sat, 17 Jun 2006 12:09:03 -0400 (EDT) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.239]) by menubar.gnome.org (Postfix) with ESMTP id DEE4F3B0061 for ; Sat, 17 Jun 2006 12:09:02 -0400 (EDT) Received: by wr-out-0506.google.com with SMTP id 57so940143wri for ; Sat, 17 Jun 2006 09:07:30 -0700 (PDT) Received: by 10.54.116.7 with SMTP id o7mr3977729wrc; Sat, 17 Jun 2006 09:00:41 -0700 (PDT) Received: from ?66.48.170.156? ( [66.48.170.156]) by mx.gmail.com with ESMTP id 44sm2844499wri.2006.06.17.09.02.05; Sat, 17 Jun 2006 09:02:06 -0700 (PDT) Message-ID: <44942B5F.2090903@gnome.org> Date: Sat, 17 Jun 2006 12:18:39 -0400 User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Alan M. Evans" Subject: Re: GObject extension propose (GContainer) References: <200606151101.12868.ntd@users.sourceforge.net> <44919246.8060301@gnome.org> <1150456522.5305.12.camel@localhost.localdomain> <1150491686.19405.355.camel@zosma.extratech.com> In-Reply-To: <1150491686.19405.355.camel@zosma.extratech.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit From: Tristan Van Berkom X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.208 tagged_above=-999 required=2 tests=[AWL=0.392, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.208 X-Spam-Level: Cc: Gtk+ Developers X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2006 16:09:06 -0000 Alan M. Evans wrote: [...] >>the lookup penalties are negligible. >>type node/class lookups and is_a checks are O(1); >>interface class lookups and conforms_to checks are O(ld(N)), where >>N is the number of interfaces a type node conforms to. >> >> > >Your assertion that the penalties are negligable is not really supported >by your response, unless the constant is also known for both orders. > > From my swift glance at gtype.c, it seems that in the case of an interface, the implementing interface is searched on that class's list of implementing interfaces... so when classes implement hundreds of interfaces it might be a performance hit. I dont think we've yet reached the day that we have to ditch good design and avoid using interfaces because of performance woes, that would be sorry day indeed... (I also dont think GTK+ code will be the only OO code needing major refactoring in those areas too... if these interface lookups weren't negligable) Cheers, -Tristan From chris@gnome-de.org Sat Jun 17 12:59:38 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 89E3F3B00A7 for ; Sat, 17 Jun 2006 12:59:38 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27929-06 for ; Sat, 17 Jun 2006 12:59:35 -0400 (EDT) Received: from mail.bytecamp.net (mail.bytecamp.net [212.204.60.9]) by menubar.gnome.org (Postfix) with SMTP id DF0E93B000D for ; Sat, 17 Jun 2006 12:59:34 -0400 (EDT) Received: (qmail 40076 invoked by uid 85); 17 Jun 2006 16:58:00 -0000 Received: from chris@gnome-de.org by mail.bytecamp.net by uid 88 with qmail-scanner-1.20 (clamscan: 0.88.1 Clear:RC:0(84.150.174.158):. Processed in 0.431315 secs); 17 Jun 2006 16:58:00 -0000 Received: from p5496ae9e.dip0.t-ipconnect.de (HELO ?192.168.123.112?) (chris@gnome-de.org@84.150.174.158) by mail.bytecamp.net with RC4-MD5 encrypted SMTP; 17 Jun 2006 16:57:59 -0000 Subject: GtkFileChooser/GnomeVFS backend still messing up authentication manager? (was: GTK+ 2.10, the endgame) From: Christian Neumair To: Matthias Clasen In-Reply-To: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> References: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> Content-Type: text/plain Date: Sat, 17 Jun 2006 18:57:54 +0200 Message-Id: <1150563475.24534.12.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.586 tagged_above=-999 required=2 tests=[AWL=0.013, BAYES_00=-2.599] X-Spam-Score: -2.586 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2006 16:59:38 -0000 Am Donnerstag, den 15.06.2006, 09:56 -0400 schrieb Matthias Clasen: > I want to have GTK+ 2.10 ready at or immediately after GUADEC. > > I did not declare 2.9.3 api frozen in the release announcement, > because we were still holding the door open for Kris' work on > the new tooltips api. But he has run into some difficulties > with the implementation which will take some time to overcome, > so we have decided to punt this feature and try to get it > into 2.12 early. > > Therefore, I want to consider 2.9.3 api frozen, and take a > look at what still needs to happen before 2.10. Here are some > things I personally would like get worked on (not sure > how much time I can free to look into these myself): > > - I think the async filechooser conversion has caused some > regressions, I noticed that .hidden support seems broken > and autocompletion also behaved badly for me recently. > > - There is a number of FIXMEs and unimplemented bits in > the print code. > > - The print backends need a careful look wrt to memory leaks > and error reporting. > > Are there other important bugs or regressions that need > attention before 2.10 ? Some months ago I investigated an issue where the GtkFileChooser requested file info for all shortcuts and caused mass login requests for all bookmarked remote locations on startup that require login with the GnomeVFS backend. I think the issue was that the file chooser has no way of requesting file info, but signalling at the same time that failure due to unavailability of resources or access constraints isn't fatal, allowing the GnomeVFS backend to not request login data when it is invoked through gtkfilechooserdefault.c:shortcuts_reload_icons. In that case, we may want to fall back to a folder icon. >From reading the GTK+ HEAD source code, the shortcut code still doesn't seem to pass any special flags, so it still seems to be relevant. -- Christian Neumair From gcottenc@gmail.com Sat Jun 17 13:23:55 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 81FC83B000D for ; Sat, 17 Jun 2006 13:23:55 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30389-08 for ; Sat, 17 Jun 2006 13:23:54 -0400 (EDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.197]) by menubar.gnome.org (Postfix) with ESMTP id 01A153B010F for ; Sat, 17 Jun 2006 13:23:53 -0400 (EDT) Received: by wx-out-0102.google.com with SMTP id h26so659270wxd for ; Sat, 17 Jun 2006 10:22:54 -0700 (PDT) Received: by 10.70.116.8 with SMTP id o8mr5867050wxc; Sat, 17 Jun 2006 10:22:54 -0700 (PDT) Received: by 10.70.19.4 with HTTP; Sat, 17 Jun 2006 10:22:54 -0700 (PDT) Message-ID: Date: Sat, 17 Jun 2006 19:22:54 +0200 From: "Guillaume Cottenceau" To: "Matthias Clasen" Subject: Re: GTK+ 2.10, the endgame In-Reply-To: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.6 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.6 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2006 17:23:55 -0000 On 6/15/06, Matthias Clasen wrote: > Therefore, I want to consider 2.9.3 api frozen, and take a Does this mean that http://developer.gnome.org/doc/API/2.0/gtk/ix07.html (and equivalents for gdk, pango, atk) is now a fully stable source for bindings which want to support new features of 2.10? -- Guillaume Cottenceau - http://zarb.org/~gc/ From timj@gtk.org Sun Jun 18 07:31:59 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id D384A3B0316 for ; Sun, 18 Jun 2006 07:31:59 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21403-07 for ; Sun, 18 Jun 2006 07:31:57 -0400 (EDT) Received: from holken.mikan.net (holken.mikan.net [83.145.56.183]) by menubar.gnome.org (Postfix) with ESMTP id 5988B3B09AB for ; Sun, 18 Jun 2006 07:31:57 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by holken.mikan.net (Postfix) with ESMTP id D1B0818461; Sun, 18 Jun 2006 13:31:12 +0200 (CEST) Received: from holken.mikan.net ([127.0.0.1]) by localhost (holken.mikan.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16166-04; Sun, 18 Jun 2006 13:31:09 +0200 (CEST) Received: from birnet.org (d003096.adsl.hansenet.de [80.171.3.96]) by holken.mikan.net (Postfix) with ESMTP id DE31E14571; Sun, 18 Jun 2006 13:31:08 +0200 (CEST) Received: from master.birnet.private (localhost.localdomain [127.0.0.1]) by birnet.org (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k5IBV5n9025330 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 18 Jun 2006 13:31:05 +0200 Received: (from timj@localhost) by master.birnet.private (8.13.4/8.13.4/Submit) id k5IBUuX0025320; Sun, 18 Jun 2006 13:30:56 +0200 Date: Sun, 18 Jun 2006 13:30:56 +0200 (CEST) From: Tim Janik X-X-Sender: timj@master.birnet.private To: Tristan Van Berkom Subject: Re: GObject extension propose (GContainer) In-Reply-To: <44942B5F.2090903@gnome.org> Message-ID: References: <200606151101.12868.ntd@users.sourceforge.net> <44919246.8060301@gnome.org> <1150456522.5305.12.camel@localhost.localdomain> <1150491686.19405.355.camel@zosma.extratech.com> <44942B5F.2090903@gnome.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at holken.mikan.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.378 tagged_above=-999 required=2 tests=[AWL=0.086, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.378 X-Spam-Level: Cc: Gtk+ Developers X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jun 2006 11:32:00 -0000 On Sat, 17 Jun 2006, Tristan Van Berkom wrote: > Alan M. Evans wrote: > [...] > >>> the lookup penalties are negligible. >>> type node/class lookups and is_a checks are O(1); >>> interface class lookups and conforms_to checks are O(ld(N)), where >>> N is the number of interfaces a type node conforms to. >>> >>> >> >> Your assertion that the penalties are negligable is not really supported >> by your response, unless the constant is also known for both orders. >> >> > From my swift glance at gtype.c, it seems that in the case of > an interface, the implementing interface is searched on that class's > list of implementing interfaces... so when classes implement > hundreds of interfaces it might be a performance hit. no there won't be a performance hit. that's because gtype.c uses a binary search for the lookups (as indicated in my last email by the O(ld(N)) complexity). the function used for frequent interface lookups is: gpointer g_type_interface_peek (gpointer instance_class, GType iface_type); and in a nutshell, it does: { TypeNode *node = lookup_type_node_I (class->g_type); // O(1) TypeNode *iface = lookup_type_node_I (iface_type); // O(1) IFaceEntry *entry = type_lookup_iface_entry_L (node, iface); // O(ld(N)) return entry->vtable; } take a look at gtype.c and type_lookup_iface_entry_L() to confirm. using a binary lookup in type_lookup_iface_entry_L() means, lookups in terms of number of interfaces and node visits during the search relate like this: interfaces-per-node | visits-per-lookup 1 | 1.0 2 | 2.0 3 | 2.6 4 | 3.0 5 | 3.3 6 | 3.6 8 | 4.0 16 | 5.0 32 | 6.0 64 | 7.0 128 | 8.0 256 | 9.0 512 | 10.0 1024 | 11.0 65536 | 17.0 262144 | 19.0 1048576 | 21.0 67108864 | 27.0 268435456 | 29.0 2147483648 | 32.0 that is, for all practical purposes, interface lookups are negligible even for many thausands of interfaces implemented per node. and now, please show me the OO system that gets into the hundreds at least... > Cheers, > -Tristan --- ciaoTJ From nicola@effe-gi.it Wed Jun 14 13:42:30 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id D182C3B0003 for ; Wed, 14 Jun 2006 13:42:30 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20727-04 for ; Wed, 14 Jun 2006 13:42:29 -0400 (EDT) Received: from mailout01.albacom.net (mailout01.albacom.net [217.220.34.13]) by menubar.gnome.org (Postfix) with SMTP id 968DC3B0081 for ; Wed, 14 Jun 2006 13:42:28 -0400 (EDT) Received: (qmail 15057 invoked by uid 508); 14 Jun 2006 17:41:43 -0000 Received: from nicola@effe-gi.it by mailout01.albacom.net with qmail-scanner (spamassassin: ???. Clear:RC:1(217.221.76.9):SA:0(0.0/15.0):. Processed in 2.56365 secs); 14 Jun 2006 17:41:43 -0000 Received: from unknown (HELO sviluppo.internet.local) (postmaster@effe-gi.it@217.221.76.9) by mailout01.albacom.net with SMTP; 14 Jun 2006 17:41:40 -0000 From: Fontana Nicola Organization: Elettronica EFFE-GI s.n.c. To: gtk-devel-list@gnome.org Subject: GObject extension propose (GContainer) Date: Wed, 14 Jun 2006 20:17:53 +0000 User-Agent: KMail/1.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200606142017.53525.nicola@effe-gi.it> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.599 tagged_above=-999 required=2 tests=[BAYES_00=-2.599] X-Spam-Score: -2.599 X-Spam-Level: X-Mailman-Approved-At: Sun, 18 Jun 2006 10:56:05 -0400 X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2006 17:42:31 -0000 Hi all, I'm a GObject based libraries (for UI purpose and not) user and I often need a generic container to derive my own types. In my opinion, I think this generic container must be included inside the GObject library ... it could be used by a lot of derived libraries providing a common approach. I published my solution - that is, what I am currently using - on sourceforge. http://sourceforge.net/projects/gcontainer/ Is it a good idea? Is something planned in this direction? Am I totally wrong? I need feedbacks ... Nicola From tristan.van.berkom@gmail.com Sun Jun 18 12:43:27 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 15A9A3B0BF9 for ; Sun, 18 Jun 2006 12:43:27 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03626-01 for ; Sun, 18 Jun 2006 12:43:26 -0400 (EDT) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.225]) by menubar.gnome.org (Postfix) with ESMTP id 1D9F83B0C2D for ; Sun, 18 Jun 2006 12:43:26 -0400 (EDT) Received: by wr-out-0506.google.com with SMTP id 37so824607wra for ; Sun, 18 Jun 2006 09:42:28 -0700 (PDT) Received: by 10.54.153.8 with SMTP id a8mr5030935wre; Sun, 18 Jun 2006 09:42:28 -0700 (PDT) Received: from ?66.48.170.160? ( [66.48.170.160]) by mx.gmail.com with ESMTP id 25sm98918wra.2006.06.18.09.42.26; Sun, 18 Jun 2006 09:42:27 -0700 (PDT) Message-ID: <44958664.4050704@gmail.com> Date: Sun, 18 Jun 2006 12:59:16 -0400 From: Tristan Van Berkom User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Janik Subject: Re: GObject extension propose (GContainer) References: <200606151101.12868.ntd@users.sourceforge.net> <44919246.8060301@gnome.org> <1150456522.5305.12.camel@localhost.localdomain> <1150491686.19405.355.camel@zosma.extratech.com> <44942B5F.2090903@gnome.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.495 tagged_above=-999 required=2 tests=[AWL=-0.351, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=1.456, SPF_PASS=-0.001] X-Spam-Score: -1.495 X-Spam-Level: Cc: Gtk+ Developers X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jun 2006 16:43:27 -0000 Tim Janik wrote: [...] > no there won't be a performance hit. [...] > 268435456 | 29.0 > 2147483648 | 32.0 > > that is, for all practical purposes, interface lookups are negligible > even > for many thausands of interfaces implemented per node. > Those stats look great Tim, sorry for any confusion I may have unwillingly caused in this thread, I think its of great importance that people not fear the GInterface. Cheers, -Tristan From jnoreiko@yahoo.com Sun Jun 18 15:19:51 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id E64063B0114 for ; Sun, 18 Jun 2006 15:19:50 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08166-08 for ; Sun, 18 Jun 2006 15:19:48 -0400 (EDT) Received: from web32405.mail.mud.yahoo.com (web32405.mail.mud.yahoo.com [68.142.207.198]) by menubar.gnome.org (Postfix) with SMTP id 24E153B00E5 for ; Sun, 18 Jun 2006 15:19:47 -0400 (EDT) Received: (qmail 1542 invoked by uid 60001); 18 Jun 2006 19:19:02 -0000 Message-ID: <20060618191902.1540.qmail@web32405.mail.mud.yahoo.com> Received: from [172.213.179.4] by web32405.mail.mud.yahoo.com via HTTP; Sun, 18 Jun 2006 20:19:02 BST Date: Sun, 18 Jun 2006 20:19:02 +0100 (BST) From: Joachim Noreiko Subject: Re: GtkFileChooser/GnomeVFS backend still messing up authentication manager? (was: GTK+ 2.10, the endgame) To: gtk-devel-list@gnome.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.64 tagged_above=-999 required=2 tests=[AWL=-0.688, BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2, DNS_FROM_RFC_WHOIS=1.447] X-Spam-Score: -1.64 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jun 2006 19:19:51 -0000 > Date: Sat, 17 Jun 2006 18:57:54 +0200 > From: Christian Neumair > Subject: GtkFileChooser/GnomeVFS backend still > > Are there other important bugs or regressions that > need > > attention before 2.10 ? Yes! Please could you implement a help button in the filechooser. The documentation is already written and is ready to be linked to. ___________________________________________________________ All new Yahoo! Mail "The new Interface is stunning in its simplicity and ease of use." - PC Magazine http://uk.docs.yahoo.com/nowyoucan.html From alexl@redhat.com Mon Jun 19 05:47:41 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id AB66D3B00A4 for ; Mon, 19 Jun 2006 05:47:41 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02513-02 for ; Mon, 19 Jun 2006 05:47:40 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id 4A6763B0014 for ; Mon, 19 Jun 2006 05:47:40 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5J9Aqqj029011; Mon, 19 Jun 2006 05:10:52 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5J9AqpA029834; Mon, 19 Jun 2006 05:10:52 -0400 Received: from [127.0.0.1] (sebastian-int.corp.redhat.com [172.16.52.221]) by devserv.devel.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5J9Ap4k026344; Mon, 19 Jun 2006 05:10:51 -0400 Subject: Re: Printing and blocking ui From: Alexander Larsson To: Yevgen Muntyan In-Reply-To: <4491AF5A.2050702@tamu.edu> References: <4491AF5A.2050702@tamu.edu> Content-Type: text/plain Date: Mon, 19 Jun 2006 11:10:51 +0200 Message-Id: <1150708251.1962.23.camel@greebo> Mime-Version: 1.0 X-Mailer: Evolution 2.7.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.588 tagged_above=-999 required=2 tests=[AWL=0.013, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.588 X-Spam-Level: Cc: GTK Devel List X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2006 09:47:41 -0000 On Thu, 2006-06-15 at 14:04 -0500, Yevgen Muntyan wrote: > Hi there, > > I print a text document from GtkTextView here. There is a problem > with pagination: pagination is potentially slow, so some sort of progress > dialog should be shown during it. From the other hand, the text buffer > must not be modified during pagination. > How to solve it? Should I show my own modal dialog and make sure user > doesn't modify the buffer, or GtkPrintOperation can take care of it? This is supported now with the Gtkprintoperation::paginate signal and gtk_print_operation_set_show_progress(). > Actually, it would be good to ensure printing blocks the text widget too, > since in this case it wouldn't be necessary to calculate and store all > the pango > layouts in begin-print. Maybe just show a modal dialog between begin-print > and end-print. Locking the editing widget is probably something you have to do yourself. You could also do a snapshot of the data at print time. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl@redhat.com alla@lysator.liu.se He's an otherworldly guerilla ex-con with a secret. She's a scantily clad belly-dancing widow who can talk to animals. They fight crime! From muntyan@tamu.edu Mon Jun 19 06:17:07 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 591293B00FB for ; Mon, 19 Jun 2006 06:17:07 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04050-03 for ; Mon, 19 Jun 2006 06:17:05 -0400 (EDT) Received: from smtp101.vzn.mail.mud.yahoo.com (smtp101.vzn.mail.mud.yahoo.com [68.142.203.45]) by menubar.gnome.org (Postfix) with SMTP id 64EE03B00C8 for ; Mon, 19 Jun 2006 06:17:05 -0400 (EDT) Received: (qmail 1322 invoked from network); 19 Jun 2006 10:16:02 -0000 Received: from unknown (HELO ?192.168.3.9?) (muntyan@verizon.net@71.113.224.59 with plain) by smtp101.vzn.mail.mud.yahoo.com with SMTP; 19 Jun 2006 10:16:01 -0000 Message-ID: <44967960.3060609@tamu.edu> Date: Mon, 19 Jun 2006 05:16:00 -0500 From: Yevgen Muntyan User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20060216 Debian/1.7.12-1.1ubuntu2 X-Accept-Language: en MIME-Version: 1.0 To: Alexander Larsson Subject: Re: Printing and blocking ui References: <4491AF5A.2050702@tamu.edu> <1150708251.1962.23.camel@greebo> In-Reply-To: <1150708251.1962.23.camel@greebo> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.553 tagged_above=-999 required=2 tests=[AWL=0.046, BAYES_00=-2.599] X-Spam-Score: -2.553 X-Spam-Level: Cc: GTK Devel List X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2006 10:17:07 -0000 Alexander Larsson wrote: >On Thu, 2006-06-15 at 14:04 -0500, Yevgen Muntyan wrote: > > >>Hi there, >> >>I print a text document from GtkTextView here. There is a problem >>with pagination: pagination is potentially slow, so some sort of progress >>dialog should be shown during it. From the other hand, the text buffer >>must not be modified during pagination. >>How to solve it? Should I show my own modal dialog and make sure user >>doesn't modify the buffer, or GtkPrintOperation can take care of it? >> >> > >This is supported now with the Gtkprintoperation::paginate signal and >gtk_print_operation_set_show_progress(). > > I don't know how paginate works, but the dialog which shows up during printing is not modal, and it appears only after some delay. I can erase text in the buffer between clicking Print button and the time when progress dialog appears. >>Actually, it would be good to ensure printing blocks the text widget too, >>since in this case it wouldn't be necessary to calculate and store all >>the pango >>layouts in begin-print. Maybe just show a modal dialog between begin-print >>and end-print. >> >> > >Locking the editing widget is probably something you have to do >yourself. You could also do a snapshot of the data at print time. > > Well, locking is easy, but I have to tell user about what's happening. So I guess the solution is to have my own modal progress dialog. Regards, Yevgen From mardy@users.sourceforge.net Mon Jun 19 10:20:09 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id B4CCC3B018E for ; Mon, 19 Jun 2006 10:20:09 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14994-07 for ; Mon, 19 Jun 2006 10:20:06 -0400 (EDT) Received: from smtp008.mail.ukl.yahoo.com (smtp008.mail.ukl.yahoo.com [217.12.11.62]) by menubar.gnome.org (Postfix) with SMTP id 190673B0076 for ; Mon, 19 Jun 2006 10:20:05 -0400 (EDT) Received: (qmail 79361 invoked from network); 19 Jun 2006 14:12:00 -0000 Received: from unknown (HELO pupilla) (mardy78@151.38.48.109 with login) by smtp008.mail.ukl.yahoo.com with SMTP; 19 Jun 2006 14:12:00 -0000 Received: by pupilla (Postfix, from userid 1000) id D59DB6B883; Mon, 19 Jun 2006 16:10:17 +0200 (CEST) Date: Mon, 19 Jun 2006 16:10:17 +0200 From: Alberto Mardegan To: gtk-devel-list@gnome.org Subject: GtkLabel as a child of a windowless widget Message-ID: <20060619141017.GA31744@pupilla> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Accept-Language: it,ia,en,bg,es,fr User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.599 tagged_above=-999 required=2 tests=[BAYES_00=-2.599] X-Spam-Score: -2.599 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2006 14:20:09 -0000 Hi all! I'm creating a Widget based on GtkFrame, with little differences: 1) It's not a container 2) It has the GTK_NO_WINDOW flag set. I'm going to use this widget inside a GtkFixed container, with the only goal of having it paint its frame (and draw its label) on the screen. I want it windowless, so that I can insert other widgets which will appear to be inside it, but which will be actually be owned by the GtkFixed. I know this is not really senseful, but I need such a widget for porting lots of applications from Prolific's Panther GUI to Gtk+. The problem I have, is that the frame label isn't drawn. I'm not sure if there are any operation I should do on it... I just create it, and call gtk_widget_set_parent(). On size_allocate, I'm not sure whether the child's x and y members of the size_allocation struct should be relative to (0,0) or to the parent widget's x and y allocation (since the parent is windowless, too). But this won't work in any case... Any hints? I have no clue. -- Saluti, Mardy http://interlingua.altervista.org Chiacchiera con i tuoi amici in tempo reale! http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com From ame1@extratech.com Mon Jun 19 11:13:35 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 1E8293B03A9 for ; Mon, 19 Jun 2006 11:13:35 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16850-05 for ; Mon, 19 Jun 2006 11:13:32 -0400 (EDT) Received: from portal2.extratech.com (portal.extratech.com [67.105.201.210]) by menubar.gnome.org (Postfix) with ESMTP id BF3D93B0076 for ; Mon, 19 Jun 2006 11:13:30 -0400 (EDT) Received: from zosma.extratech.com (zosma.extratech.com [192.168.0.41]) by portal2.extratech.com (8.12.11/8.12.11) with ESMTP id k5JFBMdd004376; Mon, 19 Jun 2006 08:11:22 -0700 Subject: Re: GObject extension propose (GContainer) From: "Alan M. Evans" To: Tristan Van Berkom In-Reply-To: <44942B5F.2090903@gnome.org> References: <200606151101.12868.ntd@users.sourceforge.net> <44919246.8060301@gnome.org> <1150456522.5305.12.camel@localhost.localdomain> <1150491686.19405.355.camel@zosma.extratech.com> <44942B5F.2090903@gnome.org> Content-Type: text/plain Message-Id: <1150729881.19405.420.camel@zosma.extratech.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 19 Jun 2006 08:11:21 -0700 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.86.1/1549/Sat Jun 17 15:20:39 2006 on portal2.extratech.com X-Virus-Status: Clean X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.551 tagged_above=-999 required=2 tests=[AWL=0.048, BAYES_00=-2.599] X-Spam-Score: -2.551 X-Spam-Level: Cc: Gtk+ Developers X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2006 15:13:35 -0000 On Sat, 2006-06-17 at 09:18, Tristan Van Berkom wrote: > Alan M. Evans wrote: > >>the lookup penalties are negligible. > >>type node/class lookups and is_a checks are O(1); > >>interface class lookups and conforms_to checks are O(ld(N)), where > >>N is the number of interfaces a type node conforms to. > > > >Your assertion that the penalties are negligable is not really supported > >by your response, unless the constant is also known for both orders.> > > > From my swift glance at gtype.c, it seems that in the case of > an interface, the implementing interface is searched on that class's > list of implementing interfaces... so when classes implement > hundreds of interfaces it might be a performance hit. My impression from the original question, which I didn't ask, was not so much about access to a large number of members. If a single variable needs to be examined many times then the performance penalty of a generic interface lookup can add up. In any case, I merely observed an assertion, "the lookup penalties are negligible," and the what appeared to be supporting data, the order of the lookups. This doesn't tell us what the penalty is, only that there is a penalty that gets worse as the number of members increases. Maybe the penalty is negligible, but the data presented didn't say so. That's all I was saying. > I dont think we've yet reached the day that we have to ditch good design > and avoid using interfaces because of performance woes, that would > be sorry day indeed... (I also dont think GTK+ code will be the only OO code > needing major refactoring in those areas too... if these interface > lookups weren't negligable) Indeed. I would certainly not advocate dispensing with good design. In fact, I usually advocate the purist design in my own software, and let Moore's Law fix the performance issues. But some cases still call for direct access for essential performance. I, too, would like to know the performance penalty of the generic interface. Being lazy, I suppose I will set up some experiment to discover it pragmatically. From federico@ximian.com Mon Jun 19 13:28:06 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id B62B13B05EF for ; Mon, 19 Jun 2006 13:28:06 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23010-05 for ; Mon, 19 Jun 2006 13:28:05 -0400 (EDT) Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) by menubar.gnome.org (Postfix) with ESMTP id 163BA3B0809 for ; Mon, 19 Jun 2006 13:28:04 -0400 (EDT) Received: (qmail 29558 invoked from network); 19 Jun 2006 17:27:00 -0000 Received: from localhost (HELO 164-99-120-63.boston.ximian.com) (127.0.0.1) by localhost with SMTP; 19 Jun 2006 17:27:00 -0000 Subject: Re: GtkFileChooser/GnomeVFS backend still messing up authentication manager? (was: GTK+ 2.10, the endgame) From: Federico Mena Quintero To: Joachim Noreiko In-Reply-To: <20060618191902.1540.qmail@web32405.mail.mud.yahoo.com> References: <20060618191902.1540.qmail@web32405.mail.mud.yahoo.com> Content-Type: text/plain Date: Mon, 19 Jun 2006 12:22:31 -0500 Message-Id: <1150737751.8452.77.camel@cacharro.xalalinux.org> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.575 tagged_above=-999 required=2 tests=[AWL=0.024, BAYES_00=-2.599] X-Spam-Score: -2.575 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2006 17:28:06 -0000 On Sun, 2006-06-18 at 20:19 +0100, Joachim Noreiko wrote: > Yes! > Please could you implement a help button in the > filechooser. The documentation is already written and > is ready to be linked to. Do we have a mechanism for this? I see that GtkColorSelectionDialog creates a Help button but hides it by default, and it gives GTK_RESPONSE_HELP when pressed. Does that get captured anywhere so that it can take you to the right help page? Federico From tvb@gnome.org Mon Jun 19 14:23:28 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 8657F3B04AC for ; Mon, 19 Jun 2006 14:23:28 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25353-05 for ; Mon, 19 Jun 2006 14:23:26 -0400 (EDT) Received: from mail.touchtunes.com (mail.touchtunes.com [207.96.182.162]) by menubar.gnome.org (Postfix) with ESMTP id 74D063B03C7 for ; Mon, 19 Jun 2006 14:23:26 -0400 (EDT) Received: from [192.168.0.138] (unknown [192.168.0.138]) by mail.touchtunes.com (Postfix) with ESMTP id 1C61615AAA; Mon, 19 Jun 2006 14:22:06 -0400 (EDT) Message-ID: <4496ED9C.3090009@gnome.org> Date: Mon, 19 Jun 2006 14:31:56 -0400 From: Tristan Van Berkom User-Agent: Mozilla Thunderbird 0.8 (X11/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alberto Mardegan Subject: Re: GtkLabel as a child of a windowless widget References: <20060619141017.GA31744@pupilla> In-Reply-To: <20060619141017.GA31744@pupilla> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.517 tagged_above=-999 required=2 tests=[AWL=0.006, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, TW_GT=0.077] X-Spam-Score: -2.517 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2006 18:23:28 -0000 Alberto Mardegan wrote: [...] > > Any hints? I have no clue. This mailing list is for the discussion of GTK+ development itself, for questions related to writing applications in gtk+ please write to gtk-app-devel-list@gnome.org or gtk-list@gnome.org. FYI: Widgets do not overlap in any containers in gtk+ (I've heard that there is z-ordering in gnomecanvas... you might want to check that out). You can: - Draw the frame yourself in the GtkFixed and place a child label where the frames label would be - Add a fixed as the child widget of the frame (probably what you want anyway). Cheers, -Tristan From federico@ximian.com Mon Jun 19 22:53:07 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 955513B044F for ; Mon, 19 Jun 2006 22:53:07 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18923-10 for ; Mon, 19 Jun 2006 22:53:06 -0400 (EDT) Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) by menubar.gnome.org (Postfix) with ESMTP id E23A03B0301 for ; Mon, 19 Jun 2006 22:53:05 -0400 (EDT) Received: (qmail 30485 invoked from network); 20 Jun 2006 02:52:00 -0000 Received: from localhost (HELO 164-99-120-63.boston.ximian.com) (127.0.0.1) by localhost with SMTP; 20 Jun 2006 02:52:00 -0000 Subject: Re: GtkLabel as a child of a windowless widget From: Federico Mena Quintero To: Alberto Mardegan In-Reply-To: <20060619141017.GA31744@pupilla> References: <20060619141017.GA31744@pupilla> Content-Type: text/plain Date: Mon, 19 Jun 2006 21:47:24 -0500 Message-Id: <1150771645.8452.94.camel@cacharro.xalalinux.org> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.575 tagged_above=-999 required=2 tests=[AWL=0.024, BAYES_00=-2.599] X-Spam-Score: -2.575 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2006 02:53:07 -0000 On Mon, 2006-06-19 at 16:10 +0200, Alberto Mardegan wrote: > Hi all! > I'm creating a Widget based on GtkFrame, with little differences: > 1) It's not a container > 2) It has the GTK_NO_WINDOW flag set. > > I'm going to use this widget inside a GtkFixed container, with the only > goal of having it paint its frame (and draw its label) on the screen. > I want it windowless, so that I can insert other widgets which will > appear to be inside it, but which will be actually be owned by the > GtkFixed. First, can you simply use a GtkFrame inside a GtkFixed, and just not put a child inside the frame? > The problem I have, is that the frame label isn't drawn. I'm not sure if > there are any operation I should do on it... I just create it, and call > gtk_widget_set_parent(). > On size_allocate, I'm not sure whether the child's x and y members of > the size_allocation struct should be relative to (0,0) or to the parent > widget's x and y allocation (since the parent is windowless, too). But > this won't work in any case... Allocations are always with respect to the parent window. So if you have a windowed parent, then inside it a no-window container at (10, 20), and a child of that container which is supposed to be offset (3, 4) pixels from the container's top-left corner, then the child's allocation will be at (13, 24). Federico From mclasen@redhat.com Tue Jun 20 09:27:18 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 4C2873B02C2 for ; Tue, 20 Jun 2006 09:27:18 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17744-01 for ; Tue, 20 Jun 2006 09:27:17 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id D5CE13B0184 for ; Tue, 20 Jun 2006 09:27:16 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5KDQgQV017831 for ; Tue, 20 Jun 2006 09:26:42 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5KDQbkk003106 for ; Tue, 20 Jun 2006 09:26:37 -0400 Received: from golem.boston.redhat.com (golem.boston.redhat.com [172.16.80.24]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id k5KDQbdH021200 for ; Tue, 20 Jun 2006 09:26:37 -0400 Subject: GTK+ team meeting From: Matthias Clasen To: gtk-devel-list@gnome.org Content-Type: text/plain Date: Tue, 20 Jun 2006 09:26:36 -0400 Message-Id: <1150809996.15532.50.camel@golem.boston.redhat.com> Mime-Version: 1.0 X-Mailer: Evolution 2.7.1 (2.7.1-1) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.543 tagged_above=-999 required=2 tests=[AWL=0.058, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.543 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2006 13:27:18 -0000 After a few weeks, we should probably have a team meeting today. The meeting is intended for the GTK+ team, but everybody is welcome to come and listen. The meeting logs will be posted on the GTK+ website (http://www.gtk.org/plan/meetings). Place: irc.gnome.org:#gtk-devel Time: 19:30 UTC (15:30 EDT), Tue, Jun 20 Possible agenda items: - GUADEC meeting - 2.10 + when to release + what needs to be on the 2.10 milestone but isn't ? Matthias From mclasen@redhat.com Tue Jun 20 11:22:11 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 3B32C3B043F; Tue, 20 Jun 2006 11:22:11 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22457-09; Tue, 20 Jun 2006 11:22:09 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id 71CF13B00E7; Tue, 20 Jun 2006 11:22:09 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5KFLLnL004523; Tue, 20 Jun 2006 11:21:21 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5KFLLNA016479; Tue, 20 Jun 2006 11:21:21 -0400 Received: from golem.boston.redhat.com (golem.boston.redhat.com [172.16.80.24]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id k5KFLKdH032719; Tue, 20 Jun 2006 11:21:20 -0400 Subject: GLib 2.11.4 released From: Matthias Clasen To: gnome-announce-list@gnome.org, gtk-devel-list@gnome.org, gtk-list@gnome.org, gtk-app-devel-list@gnome.org Content-Type: text/plain Date: Tue, 20 Jun 2006 11:21:20 -0400 Message-Id: <1150816880.15532.58.camel@golem.boston.redhat.com> Mime-Version: 1.0 X-Mailer: Evolution 2.7.1 (2.7.1-1) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.543 tagged_above=-999 required=2 tests=[AWL=0.058, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.543 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: gnome-hackers@gnome.org List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2006 15:22:11 -0000 GLib 2.11.4 is now available for download at: ftp://ftp.gtk.org/pub/gtk/v2.11/ http://ftp.gnome.org/pub/GNOME/sources/glib/2.11/ glib-2.11.4.tar.bz2 md5sum: 9d3a94baa4bfcd9a579b45eea6de3a8c glib-2.11.4.tar.gz md5sum: f7768bc7ed524c6b40cb87daccb6c2b2 This is a development release leading up to GLib 2.12. Notes: * This is unstable development release. While it has had a bit of testing, there are certainly plenty of bugs remaining to be found. This release should not be used in production. * Installing this version will overwrite your existing copy of GLib 2.10. If you have problems, you'll need to reinstall GLib 2.10. * GLib 2.12 will be source and binary compatible with the GLib 2.10.x series (for some caveats, see the README). At this point, the API additions in the 2.11.x series are finished. * Bugs should be reported to http://bugzilla.gnome.org. About GLib ========== GLib is the low-level core library that forms the basis for projects such as GTK+ and GNOME. It provides data structure handling for C, portability wrappers, and interfaces for such runtime functionality as an event loop, threads, dynamic loading, and an object system. More information about GLib is available at: http://www.gtk.org/ An installation guide for the GTK+ libraries, including GLib, can be found at: http://developer.gnome.org/doc/API/2.0/gtk/gtk-building.html Overview of Changes from GLib 2.11.3 to GLib 2.11.4 =================================================== * GBookmarkFile: - g_bookmark_file_remove_item returns a boolean * g_mkstemp accepts the XXXXXX in the middle of the template * Bugs fixed: 344868 g_key_file_to_data should separate groups * Updated translations (de,es,fr,gu,hi,ko,th) A list of all bugs fixed in this release can be found at: http://bugzilla.gnome.org/buglist.cgi?bug_id=344868 Thanks to everybody who has contributed to this release, in the form of bug reports or patches: Emmanuele Bassi, Christian Persch, Federico Mena Quintero Matthias Clasen June 20, 2006 From mgiannakidis@gmail.com Mon Jun 19 08:23:48 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id E62893B0AAF for ; Mon, 19 Jun 2006 08:23:47 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10711-01 for ; Mon, 19 Jun 2006 08:23:44 -0400 (EDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.191]) by menubar.gnome.org (Postfix) with ESMTP id E721A3B089A for ; Mon, 19 Jun 2006 08:23:43 -0400 (EDT) Received: by nf-out-0910.google.com with SMTP id x30so1070652nfb for ; Mon, 19 Jun 2006 05:22:35 -0700 (PDT) Received: by 10.48.14.1 with SMTP id 1mr1206423nfn; Mon, 19 Jun 2006 05:16:27 -0700 (PDT) Received: from ?213.140.137.120? ( [213.140.137.120]) by mx.gmail.com with ESMTP id d2sm4750763nfe.2006.06.19.05.16.26; Mon, 19 Jun 2006 05:16:26 -0700 (PDT) From: Michalis Giannakidis To: gtk-devel-list@gnome.org Subject: Re: gslice allocator: general impresions. Date: Mon, 19 Jun 2006 15:20:48 +0300 User-Agent: KMail/1.8.3 References: <200606151827.45477.mgiannakidis@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200606191520.48220.mgiannakidis@gmail.com> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.526 tagged_above=-999 required=2 tests=[AWL=-0.002, BAYES_00=-2.599, SPF_PASS=-0.001, TW_TX=0.077] X-Spam-Score: -2.526 X-Spam-Level: X-Mailman-Approved-At: Tue, 20 Jun 2006 12:30:13 -0400 X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2006 12:23:48 -0000 Dear Tim > > (I have modified gslice > > to align a chunk to its own size so that I don't have unused memory > > between chunks eg: request 20 and get 24...) > > you mean you've set P2ALIGNMENT to 1 * sizeof(void*) to get better > granularity of the slices? have you left NATIVE_MALLOC_PADDING at > 2*sizeof(void*) at least? (if not, memory fragmentation on some glibc > systems and on all 64bit systems can become etxremely bad). > I didn't change P2ALIGNMENT . I modified SLAB_INDEX to (asize - 1), SLAB_CHUNK_SIZE to (ix + 1) I also modified P2ALIGN to (size) for all occurances of P2ALIGN except for SLAB_INFO_SIZE. I understand that this will create different memory pools for each size I alloc for, but this is accpeted since I only call g_slice_alloc for two sizes. The tweak seem to be OK since I don't get any segfaults. > maybe due to your alignment tweaks. but maybe also because some malloc() > buckets will have even longer lists that way. > The slowdown also occurred without the alignment tweaks. My understanding is that it is a general malloc slowdown that occurres of the many small mallocs done in the application plus the many larger mallocs done by the gslice allocator. I have read the references available in the gslice allocator comments and were very helpful. What I am looking for know is some sort of comparisons in memory usage and speed in applications changing from malloc to gslice. Also, any tweaks in the gslice allocation sizes providing a more responsive malloc would be great! Any suggestions would be very welcome. Thank you very much. Michalis -- Michalis Giannakidis From mclasen@redhat.com Wed Jun 21 09:13:22 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C2BA53B1007 for ; Wed, 21 Jun 2006 09:13:22 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07614-06 for ; Wed, 21 Jun 2006 09:13:21 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id E02C63B0FE5 for ; Wed, 21 Jun 2006 09:13:20 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5LDDKUh027657; Wed, 21 Jun 2006 09:13:20 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5LDDJnE017553; Wed, 21 Jun 2006 09:13:19 -0400 Received: from golem.boston.redhat.com (golem.boston.redhat.com [172.16.80.24]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id k5LDDJdH018065; Wed, 21 Jun 2006 09:13:19 -0400 Subject: Re: Fwd: GTK+ 2.10, the endgame From: Matthias Clasen To: Guillaume Cottenceau In-Reply-To: References: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> Content-Type: text/plain Date: Wed, 21 Jun 2006 09:13:19 -0400 Message-Id: <1150895599.15532.80.camel@golem.boston.redhat.com> Mime-Version: 1.0 X-Mailer: Evolution 2.7.1 (2.7.1-1) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.506 tagged_above=-999 required=2 tests=[AWL=0.018, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, TW_GT=0.077] X-Spam-Score: -2.506 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2006 13:13:23 -0000 On Wed, 2006-06-21 at 08:38 +0200, Guillaume Cottenceau wrote: > Hi Matthias, > > Could you just drop a line on the list about this question? > > Thanks in advance. > > ---------- Forwarded message ---------- > From: Guillaume Cottenceau > Date: Jun 17, 2006 7:22 PM > Subject: Re: GTK+ 2.10, the endgame > To: Matthias Clasen > Cc: gtk-devel-list@gnome.org > > > On 6/15/06, Matthias Clasen wrote: > > Therefore, I want to consider 2.9.3 api frozen, and take a > > Does this mean that > http://developer.gnome.org/doc/API/2.0/gtk/ix07.html (and equivalents > for gdk, pango, atk) is now a fully stable source for bindings which > want to support new features of 2.10? > > -- > Guillaume Cottenceau - http://zarb.org/~gc/ > The online documentation is still at 2.9.2. I hope to find time to update it to 2.9.4 before leaving for GUADEC tomorrow. A small number of API additions turned out to be necessary in the lowlevel printing apis after 2.9.3: gtk_enumerate_printers GTK_PRINT_CAPABILITY_CAN_GENERATE_PS GTK_PRINT_SETTINGS_OUTPUT_FILE_FORMAT GTK_PRINT_SETTINGS_OUTPUT_URI Furthermore, GTK_PRINT_SETTINGS_PRINT_TO_FILE was found to be unused and removed, together with its setter and getter. Matthias From mclasen@redhat.com Wed Jun 21 13:35:58 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id EE5983B046D for ; Wed, 21 Jun 2006 13:35:57 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25325-06 for ; Wed, 21 Jun 2006 13:35:56 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id 7ACFF3B02CE for ; Wed, 21 Jun 2006 13:35:56 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5LHZtpq012200 for ; Wed, 21 Jun 2006 13:35:55 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5LHZthC009595 for ; Wed, 21 Jun 2006 13:35:55 -0400 Received: from golem.boston.redhat.com (golem.boston.redhat.com [172.16.80.24]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id k5LHZtdH019718 for ; Wed, 21 Jun 2006 13:35:55 -0400 Subject: Looking beyond 2.10 From: Matthias Clasen To: gtk-devel-list@gnome.org Content-Type: text/plain Date: Wed, 21 Jun 2006 13:35:55 -0400 Message-Id: <1150911355.15532.100.camel@golem.boston.redhat.com> Mime-Version: 1.0 X-Mailer: Evolution 2.7.1 (2.7.1-1) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.545 tagged_above=-999 required=2 tests=[AWL=0.056, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.545 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2006 17:35:58 -0000 So, with GTK+ 2.10 on the finish line, I tried to make a quick list of things we may want to look at for 2.12, as input to GUADEC discussions. Patches almost ready to go in - libglade integration - new tooltips api Stuff that needs more work - introspection - international calendar support Stuff that we need to figure out - canvas - libsexy cherrypicking ? (Of course, bugzilla has an endless supply of feature requests and bugs that one can work on, these are just the things that came to my mind first) Matthias From hfiguiere@teaser.fr Wed Jun 21 15:04:27 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C0B713B00F6 for ; Wed, 21 Jun 2006 15:04:27 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31064-02 for ; Wed, 21 Jun 2006 15:04:19 -0400 (EDT) Received: from xandros.com (smtp1.xandros.com [209.87.238.70]) by menubar.gnome.org (Postfix) with ESMTP id 873C83B02DA for ; Wed, 21 Jun 2006 15:04:14 -0400 (EDT) Received: from [172.16.1.95] (unknown [209.87.238.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by xandros.com (Postfix) with ESMTP id 09337A030 for ; Wed, 21 Jun 2006 15:04:13 -0400 (EDT) Message-ID: <4499982C.1010004@teaser.fr> Date: Wed, 21 Jun 2006 15:04:12 -0400 From: Hubert Figuiere User-Agent: Thunderbird 1.5.0.4 (X11/20060615) MIME-Version: 1.0 To: gtk-devel-list@gnome.org Subject: Re: Looking beyond 2.10 References: <1150911355.15532.100.camel@golem.boston.redhat.com> In-Reply-To: <1150911355.15532.100.camel@golem.boston.redhat.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.542 tagged_above=-999 required=2 tests=[AWL=0.057, BAYES_00=-2.599] X-Spam-Score: -2.542 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2006 19:04:27 -0000 Matthias Clasen wrote: > Stuff that needs more work > > - introspection > - international calendar support Complete MacOS X support? I'm about to pick Qt as a toolkit for a personal project just because of that. Hub From matthias.clasen@gmail.com Wed Jun 21 18:26:02 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id A5B4E3B006C for ; Wed, 21 Jun 2006 18:26:02 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09882-05 for ; Wed, 21 Jun 2006 18:26:01 -0400 (EDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.177]) by menubar.gnome.org (Postfix) with ESMTP id 477AE3B00F8 for ; Wed, 21 Jun 2006 18:26:01 -0400 (EDT) Received: by py-out-1112.google.com with SMTP id e30so107107pya for ; Wed, 21 Jun 2006 15:26:00 -0700 (PDT) Received: by 10.35.111.14 with SMTP id o14mr363031pym; Wed, 21 Jun 2006 15:26:00 -0700 (PDT) Received: by 10.35.39.16 with HTTP; Wed, 21 Jun 2006 15:26:00 -0700 (PDT) Message-ID: Date: Wed, 21 Jun 2006 18:26:00 -0400 From: "Matthias Clasen" To: "Hubert Figuiere" Subject: Re: Looking beyond 2.10 In-Reply-To: <4499982C.1010004@teaser.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1150911355.15532.100.camel@golem.boston.redhat.com> <4499982C.1010004@teaser.fr> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.51 tagged_above=-999 required=2 tests=[AWL=0.090, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.51 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2006 22:26:02 -0000 On 6/21/06, Hubert Figuiere wrote: > Matthias Clasen wrote: > > > Stuff that needs more work > > > > - introspection > > - international calendar support > > Complete MacOS X support? Sure, if someone with access to a Mac works on it. I don't have a Mac... > I'm about to pick Qt as a toolkit for a personal project just because of > that. Good luck. Matthias From trowbrds@gmail.com Wed Jun 21 18:29:52 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 103073B0011 for ; Wed, 21 Jun 2006 18:29:52 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10124-04 for ; Wed, 21 Jun 2006 18:29:49 -0400 (EDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.185]) by menubar.gnome.org (Postfix) with ESMTP id B842D3B00E4 for ; Wed, 21 Jun 2006 18:29:48 -0400 (EDT) Received: by nf-out-0910.google.com with SMTP id h2so177759nfe for ; Wed, 21 Jun 2006 15:29:47 -0700 (PDT) Received: by 10.49.81.12 with SMTP id i12mr1011269nfl; Wed, 21 Jun 2006 15:29:47 -0700 (PDT) Received: by 10.49.36.8 with HTTP; Wed, 21 Jun 2006 15:29:47 -0700 (PDT) Message-ID: Date: Wed, 21 Jun 2006 16:29:47 -0600 From: "David Trowbridge" To: gtk-devel-list@gnome.org Subject: Re: Looking beyond 2.10 In-Reply-To: <1150911355.15532.100.camel@golem.boston.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1150911355.15532.100.camel@golem.boston.redhat.com> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.538 tagged_above=-999 required=2 tests=[AWL=0.062, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.538 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2006 22:29:52 -0000 On 6/21/06, Matthias Clasen wrote: > - libsexy cherrypicking ? The icon entry and url labels are probably robust enough (and widely useful enough) to go in. For anything else, it will require some work. -David From mclasen@redhat.com Wed Jun 21 23:10:41 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id AA4213B0172; Wed, 21 Jun 2006 23:10:41 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23030-07; Wed, 21 Jun 2006 23:10:39 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id 63BA23B0008; Wed, 21 Jun 2006 23:10:39 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5M3AclX021506; Wed, 21 Jun 2006 23:10:38 -0400 Received: from lacrosse.corp.redhat.com (lacrosse.corp.redhat.com [172.16.52.154]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5M3AcnM019751; Wed, 21 Jun 2006 23:10:38 -0400 Received: from [172.16.83.158] (vpn83-158.boston.redhat.com [172.16.83.158]) by lacrosse.corp.redhat.com (8.12.11.20060308/8.11.6) with ESMTP id k5M3AciB004961; Wed, 21 Jun 2006 23:10:38 -0400 Subject: GTK+ 2.9.4 released From: Matthias Clasen To: gnome-announce-list@gnome.org, gtk-devel-list@gnome.org, gtk-app-devel-list@gnome.org, gtk-list@gnome.org Content-Type: text/plain Organization: Red Hat Date: Wed, 21 Jun 2006 23:12:41 -0400 Message-Id: <1150945961.4457.2.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.7.3 (2.7.3-2) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.507 tagged_above=-999 required=2 tests=[AWL=0.017, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, TW_GT=0.077] X-Spam-Score: -2.507 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: gnome-hackers@gnome.org List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 03:10:42 -0000 GTK+ 2.9.4 is now available for download at: http://ftp.gnome.org/pub/gnome/sources/gtk+/2.9/ gtk+-2.9.4.tar.bz2 md5sum: c06cf2cfa66485600d90789c9e58f27c gtk+-2.9.4.tar.gz md5sum: e3fefedc7f1a89b66c71c9967168a857 This is a development release leading up to GTK+ 2.10. Notes: * This is unstable development release. There are certainly plenty of bugs remaining to be found. This release should not be used in production. * Installing this version will overwrite your existing copy of GTK+ 2.8. If you have problems, you'll need to reinstall GTK+ 2.8. * GTK+ 2.10 will be source compatible with the GTK+ 2.8 series; the new API additions in GTK+ 2.9.0 are finalized by now. * The ABI version has been bumped from 2.4.0 to 2.10.0, since the filechooser backend interface has been changed. Third-party filechooser backends need to be ported to the new interface. Other third-party modules (input methods, image loaders, etc) just need to be reinstalled in the proper location for GTK+ to find them. * Remaining issues for GTK+ 2.10 can be found with following bugzilla query: http://bugzilla.gnome.org/buglist.cgi?product=gtk%2b&target_milestone=2.10+API+Freeze&target_milestone=2.10+Freeze&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED * Bugs should be reported to http://bugzilla.gnome.org. What is GTK+ ============ GTK+ is a multi-platform toolkit for creating graphical user interfaces. Offering a complete set of widgets, GTK+ is suitable for projects ranging from small one-off tools to complete application suites. GTK+ has been designed from the ground up to support a range of languages, not only C/C++. Using GTK+ from languages such as Perl and Python (especially in combination with the Glade GUI builder) provides an effective method of rapid application development. GTK+ is free software and part of the GNU Project. However, the licensing terms for GTK+, the GNU LGPL, allow it to be used by all developers, including those developing proprietary software, without any license fees or royalties. Where to get more information about GTK+ ======================================== Information about GTK+ including links to documentation can be found at: http://www.gtk.org/ An installation guide for GTK+ 2.x is found at: http://developer.gnome.org/doc/API/2.4/gtk/gtk-building.html Common questions: http://developer.gnome.org/doc/API/2.4/gtk/gtk-question-index.html http://www.gtk.org/faq/ Overview of Changes from GTK+ 2.9.3 to 2.9.4 ============================================ * GtkPrintOperation: - UI improvements in the print dialog - Make printing work without a display connection - Replace "Print to PDF" by "Print to file" that can generate PDF or PostScript - Add a function to the low-level API to enumerate all printers * GtkNotebook tab DND has been improved * GtkProgressbar supports text in activity mode * GtkLabel allows to set the wrap mode * GtkStatusIcon supports transparency * Bugs fixed: 344850 Dragging a GtkTreeViewColumn segfaults when using certain GtkTreeViewColumnDropFunc 342458 Stock menu items without icons are broken in recent GTK+ releases. 335873 notebook DND + popup windows 337882 gtk_progress_bar_set_text() does nothing in activity mode 339456 unix print dialogue help button bug 339702 Make sure printing works without a display 341571 tabs too easily reordered 344074 New Feature: get printer list, and get default print 344743 gtk_targets_include_text() should initialize atoms 344838 Allow func to be NULL in gtk_tree_view_set_search_position_func 344891 GtkPrintOperationPreview signal defs correction 345008 Need updated cairo req 345093 print preview temp file issues 345107 Memory leak in gtk_entry_completion_finalize: User data not freed 345194 gdk_window_set_functions() docs need to be updated 345456 grid-lines property is wrongly registered and get/set. 314278 strings in gtk-update-icon-cache are not marked for translation 344707 size group with widgets in hidden container 344897 Entry completion model NULL handling should be documented 345038 gtk_print_job_set_status' status 345106 dialog button box spacings 345176 GtkIconView doc about drag and drop 345275 doc imporovements for gtk_window_move 345320 Two very similiar strings should be made equal 345321 Add meaning of "shortcut" as translator comment 320034 transparency gtkstatusicon 339592 Add print-to-postscript 344867 custom paper file could use keyfile * Updated translations (cs,de,es,fr,gl,gu,hi,ko,ta,th) A list of all bugs fixed in this release can be found at http://bugzilla.gnome.org/buglist.cgi?bug_id=344838,344743,344867,344891,345008,341571,345038,337882,345093,344707,339456,345107,345275,339702,344074,345320,345321,344897,314278,320034,344850,345194,345176,345106,335873,342458,339592,345456 Thanks to everybody who has contributed to this release, in the form of bug reports or patches: Christian Persch, John Finlay, Federico Mena Quintero, Michael Emmel, Marko Anastasov, Bastien Nocera, Carlos Garnacho, Yevgen Muntyan, Tommi Komulainen, Tim Janik, Christian Weiske, Behdad Esfahbod, Alexander Larsson, Felipe Heidrich, Hendrik Richter, Claudio Saavedra, Dan Winship, Callum McKenzie, John Palmieri, Murray Cumming, Kristian Rietveld June 21, 2006 Matthias Clasen From alexl@redhat.com Thu Jun 22 03:30:13 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id F02D73B04C8 for ; Thu, 22 Jun 2006 03:30:12 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04379-10 for ; Thu, 22 Jun 2006 03:30:11 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id 3177C3B021B for ; Thu, 22 Jun 2006 03:30:11 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5M7UAw1025719 for ; Thu, 22 Jun 2006 03:30:10 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5M7UAI5026706; Thu, 22 Jun 2006 03:30:10 -0400 Received: from [127.0.0.1] (sebastian-int.corp.redhat.com [172.16.52.221]) by devserv.devel.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5M7U90l029917; Thu, 22 Jun 2006 03:30:09 -0400 Subject: Re: Looking beyond 2.10 From: Alexander Larsson To: Matthias Clasen In-Reply-To: <1150911355.15532.100.camel@golem.boston.redhat.com> References: <1150911355.15532.100.camel@golem.boston.redhat.com> Content-Type: text/plain Date: Thu, 22 Jun 2006 09:30:09 +0200 Message-Id: <1150961409.16397.101.camel@greebo> Mime-Version: 1.0 X-Mailer: Evolution 2.7.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.588 tagged_above=-999 required=2 tests=[AWL=0.013, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.588 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 07:30:13 -0000 On Wed, 2006-06-21 at 13:35 -0400, Matthias Clasen wrote: > So, with GTK+ 2.10 on the finish line, I tried to make a quick > list of things we may want to look at for 2.12, as input to > GUADEC discussions. The EditableLable stuff would be nice to have in gtk+: http://live.gnome.org/ProjectRidley/EelEditableLabel This would mean i could drop EelEditableLabel, and i'm sure others need something like this too. For instance, GtkIconView would need it to support renaming. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl@redhat.com alla@lysator.liu.se He's a lonely hunchbacked matador on the edge. She's a radical impetuous single mother who don't take no shit from nobody. They fight crime! From mclasen@redhat.com Thu Jun 22 09:23:37 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 8880D3B0667 for ; Thu, 22 Jun 2006 09:23:37 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30015-09 for ; Thu, 22 Jun 2006 09:23:23 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id 58F4B3B03E5 for ; Thu, 22 Jun 2006 09:23:04 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5MDN3ca016505 for ; Thu, 22 Jun 2006 09:23:03 -0400 Received: from lacrosse.corp.redhat.com (lacrosse.corp.redhat.com [172.16.52.154]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5MDN3dV000789; Thu, 22 Jun 2006 09:23:03 -0400 Received: from [172.16.83.176] (vpn83-176.boston.redhat.com [172.16.83.176]) by lacrosse.corp.redhat.com (8.12.11.20060308/8.11.6) with ESMTP id k5MDN2MM012188; Thu, 22 Jun 2006 09:23:03 -0400 Subject: Re: Looking beyond 2.10 From: Matthias Clasen To: Alexander Larsson In-Reply-To: <1150961409.16397.101.camel@greebo> References: <1150911355.15532.100.camel@golem.boston.redhat.com> <1150961409.16397.101.camel@greebo> Content-Type: text/plain Organization: Red Hat Date: Thu, 22 Jun 2006 09:25:07 -0400 Message-Id: <1150982707.2966.6.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.7.3 (2.7.3-2) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.546 tagged_above=-999 required=2 tests=[AWL=0.055, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.546 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 13:23:37 -0000 On Thu, 2006-06-22 at 09:30 +0200, Alexander Larsson wrote: > On Wed, 2006-06-21 at 13:35 -0400, Matthias Clasen wrote: > > So, with GTK+ 2.10 on the finish line, I tried to make a quick > > list of things we may want to look at for 2.12, as input to > > GUADEC discussions. > > The EditableLable stuff would be nice to have in gtk+: > http://live.gnome.org/ProjectRidley/EelEditableLabel > > This would mean i could drop EelEditableLabel, and i'm sure others need > something like this too. For instance, GtkIconView would need it to > support renaming. > Not that it would not be useful, but GtkIconView uses cell renderers, and already supports editing... From alexl@redhat.com Thu Jun 22 09:33:59 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 9529C3B0748 for ; Thu, 22 Jun 2006 09:33:59 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30708-06 for ; Thu, 22 Jun 2006 09:33:54 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id B4FBD3B0559 for ; Thu, 22 Jun 2006 09:33:54 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5MDXsaJ021314 for ; Thu, 22 Jun 2006 09:33:54 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5MDXrtU004254; Thu, 22 Jun 2006 09:33:53 -0400 Received: from [127.0.0.1] (sebastian-int.corp.redhat.com [172.16.52.221]) by devserv.devel.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5MDXqt9025805; Thu, 22 Jun 2006 09:33:53 -0400 Subject: Re: Looking beyond 2.10 From: Alexander Larsson To: Matthias Clasen In-Reply-To: <1150982707.2966.6.camel@localhost.localdomain> References: <1150911355.15532.100.camel@golem.boston.redhat.com> <1150961409.16397.101.camel@greebo> <1150982707.2966.6.camel@localhost.localdomain> Content-Type: text/plain Date: Thu, 22 Jun 2006 15:33:52 +0200 Message-Id: <1150983232.16397.107.camel@greebo> Mime-Version: 1.0 X-Mailer: Evolution 2.7.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.588 tagged_above=-999 required=2 tests=[AWL=0.013, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.588 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 13:33:59 -0000 On Thu, 2006-06-22 at 09:25 -0400, Matthias Clasen wrote: > On Thu, 2006-06-22 at 09:30 +0200, Alexander Larsson wrote: > > On Wed, 2006-06-21 at 13:35 -0400, Matthias Clasen wrote: > > > So, with GTK+ 2.10 on the finish line, I tried to make a quick > > > list of things we may want to look at for 2.12, as input to > > > GUADEC discussions. > > > > The EditableLable stuff would be nice to have in gtk+: > > http://live.gnome.org/ProjectRidley/EelEditableLabel > > > > This would mean i could drop EelEditableLabel, and i'm sure others need > > something like this too. For instance, GtkIconView would need it to > > support renaming. > > > > Not that it would not be useful, but GtkIconView uses cell renderers, > and already supports editing... How does that handle labels that are several lines long? =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl@redhat.com alla@lysator.liu.se He's a war-weary moralistic waffle chef with nothing left to lose. She's an orphaned red-headed barmaid looking for love in all the wrong places. They fight crime! From mclasen@redhat.com Thu Jun 22 09:48:21 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 98DD03B04F0 for ; Thu, 22 Jun 2006 09:48:21 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31802-05 for ; Thu, 22 Jun 2006 09:48:20 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id DD2613B00DE for ; Thu, 22 Jun 2006 09:48:19 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5MDmJQS027439 for ; Thu, 22 Jun 2006 09:48:19 -0400 Received: from lacrosse.corp.redhat.com (lacrosse.corp.redhat.com [172.16.52.154]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5MDmJB6008537; Thu, 22 Jun 2006 09:48:19 -0400 Received: from [172.16.83.176] (vpn83-176.boston.redhat.com [172.16.83.176]) by lacrosse.corp.redhat.com (8.12.11.20060308/8.11.6) with ESMTP id k5MDmIjF015592; Thu, 22 Jun 2006 09:48:18 -0400 Subject: Re: Looking beyond 2.10 From: Matthias Clasen To: Alexander Larsson In-Reply-To: <1150983232.16397.107.camel@greebo> References: <1150911355.15532.100.camel@golem.boston.redhat.com> <1150961409.16397.101.camel@greebo> <1150982707.2966.6.camel@localhost.localdomain> <1150983232.16397.107.camel@greebo> Content-Type: text/plain Organization: Red Hat Date: Thu, 22 Jun 2006 09:50:23 -0400 Message-Id: <1150984223.2966.10.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.7.3 (2.7.3-2) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.546 tagged_above=-999 required=2 tests=[AWL=0.055, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.546 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 13:48:21 -0000 On Thu, 2006-06-22 at 15:33 +0200, Alexander Larsson wrote: > On Thu, 2006-06-22 at 09:25 -0400, Matthias Clasen wrote: > > On Thu, 2006-06-22 at 09:30 +0200, Alexander Larsson wrote: > > > On Wed, 2006-06-21 at 13:35 -0400, Matthias Clasen wrote: > > > > So, with GTK+ 2.10 on the finish line, I tried to make a quick > > > > list of things we may want to look at for 2.12, as input to > > > > GUADEC discussions. > > > > > > The EditableLable stuff would be nice to have in gtk+: > > > http://live.gnome.org/ProjectRidley/EelEditableLabel > > > > > > This would mean i could drop EelEditableLabel, and i'm sure others need > > > something like this too. For instance, GtkIconView would need it to > > > support renaming. > > > > > > > Not that it would not be useful, but GtkIconView uses cell renderers, > > and already supports editing... > > How does that handle labels that are several lines long? > As well as the treeview does... eventually we'll have to sit down and add multline to GtkEntry... From alexl@redhat.com Thu Jun 22 09:52:23 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 292473B081B for ; Thu, 22 Jun 2006 09:52:23 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32031-08 for ; Thu, 22 Jun 2006 09:52:21 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id 83E8E3B0811 for ; Thu, 22 Jun 2006 09:52:21 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5MDqKud029180 for ; Thu, 22 Jun 2006 09:52:21 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5MDqFg0009757; Thu, 22 Jun 2006 09:52:15 -0400 Received: from [127.0.0.1] (sebastian-int.corp.redhat.com [172.16.52.221]) by devserv.devel.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5MDqE6x027583; Thu, 22 Jun 2006 09:52:14 -0400 Subject: Re: Looking beyond 2.10 From: Alexander Larsson To: Matthias Clasen In-Reply-To: <1150984223.2966.10.camel@localhost.localdomain> References: <1150911355.15532.100.camel@golem.boston.redhat.com> <1150961409.16397.101.camel@greebo> <1150982707.2966.6.camel@localhost.localdomain> <1150983232.16397.107.camel@greebo> <1150984223.2966.10.camel@localhost.localdomain> Content-Type: text/plain Date: Thu, 22 Jun 2006 15:52:14 +0200 Message-Id: <1150984334.16397.110.camel@greebo> Mime-Version: 1.0 X-Mailer: Evolution 2.7.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.588 tagged_above=-999 required=2 tests=[AWL=0.013, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.588 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 13:52:23 -0000 On Thu, 2006-06-22 at 09:50 -0400, Matthias Clasen wrote: > On Thu, 2006-06-22 at 15:33 +0200, Alexander Larsson wrote: > > > How does that handle labels that are several lines long? > > As well as the treeview does... eventually we'll have to sit down > and add multline to GtkEntry... Thats basically what EelEditableLabel is. I'm not sure its better to combine the two into one than having a separate widget for it. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl@redhat.com alla@lysator.liu.se He's a sword-wielding Catholic gangster fleeing from a secret government programme. She's a beautiful mute snake charmer with the power to bend men's minds. They fight crime! From Bill.Haneman@Sun.COM Thu Jun 22 09:59:01 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id A04A33B06B5 for ; Thu, 22 Jun 2006 09:59:01 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32611-04 for ; Thu, 22 Jun 2006 09:58:59 -0400 (EDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by menubar.gnome.org (Postfix) with ESMTP id EC16D3B0487 for ; Thu, 22 Jun 2006 09:58:52 -0400 (EDT) Received: from phys-gadget-1 ([129.156.85.171]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k5MDwpH2016279 for ; Thu, 22 Jun 2006 07:58:52 -0600 (MDT) Received: from conversion-daemon.gadget-mail1.uk.sun.com by gadget-mail1.uk.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0J1900F01LG3TK@gadget-mail1.uk.sun.com> (original mail from Bill.Haneman@Sun.COM) for gtk-devel-list@gnome.org; Thu, 22 Jun 2006 14:58:51 +0100 (BST) Received: from [192.168.1.120] (vpn-129-150-116-130.UK.Sun.COM [129.150.116.130]) by gadget-mail1.uk.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0J1900AYWLI2KV@gadget-mail1.uk.sun.com> for gtk-devel-list@gnome.org; Thu, 22 Jun 2006 14:58:51 +0100 (BST) Date: Thu, 22 Jun 2006 15:00:03 +0100 From: Bill Haneman Subject: GtkTextBuffer serialization formats: why no "text/plain" ? To: gtk-devel-list@gnome.org Message-id: <1150984802.7100.4.camel@linux.site> MIME-version: 1.0 X-Mailer: Ximian Evolution 1.4.6.338 Content-type: text/plain Content-transfer-encoding: 7BIT X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.538 tagged_above=-999 required=2 tests=[AWL=-0.017, BAYES_00=-2.599, TW_GT=0.077, UNPARSEABLE_RELAY=0.001] X-Spam-Score: -2.538 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 13:59:01 -0000 Hi; The new serialize/deserialize API for GtkTextBuffer looks to be very useful to accessibility among other things. I am currently using it to implement AtkStreamableContent, an interface which allows objects with streamable backing data (for instance images, HTML widgets, text containers...) to advertise that fact and stream the data to remote clients such as assistive technologies. However I am somewhat surprised to see in gtk-demo's Hypertext widget that, although there's a serialization format called "application/x-gtk-rich-text", there's no "text/plain". Of course serialization via plain text would not be lossless, but why isn't there a plain text serialization available for all GtkTextBuffer instances? We certainly need it for the accessibility case - otherwise we'll have to fake one in gail, necessitating multiple code paths or at least some odd concatenation of "text/plain" if it is not among those returned by gtk_text_buffer_get_serialize_formats... regards, Bill From ebassi@gmail.com Thu Jun 22 10:02:56 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id D0CCE3B074F for ; Thu, 22 Jun 2006 10:02:56 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00339-10 for ; Thu, 22 Jun 2006 10:02:55 -0400 (EDT) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.171]) by menubar.gnome.org (Postfix) with ESMTP id CC4073B0634 for ; Thu, 22 Jun 2006 10:02:54 -0400 (EDT) Received: by ug-out-1314.google.com with SMTP id o2so482915uge for ; Thu, 22 Jun 2006 07:02:53 -0700 (PDT) Received: by 10.78.151.3 with SMTP id y3mr507751hud; Thu, 22 Jun 2006 07:02:53 -0700 (PDT) Received: from ?192.168.1.70? ( [86.136.65.180]) by mx.gmail.com with ESMTP id 8sm364730hug.2006.06.22.07.02.53; Thu, 22 Jun 2006 07:02:53 -0700 (PDT) Subject: Re: Looking beyond 2.10 From: Emmanuele Bassi To: gtk-devel-list@gnome.org In-Reply-To: <1150911355.15532.100.camel@golem.boston.redhat.com> References: <1150911355.15532.100.camel@golem.boston.redhat.com> Content-Type: text/plain Date: Thu, 22 Jun 2006 15:02:51 +0100 Message-Id: <1150984971.5346.12.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.362 tagged_above=-999 required=2 tests=[AWL=0.238, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.362 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 14:02:57 -0000 Hi; On Wed, 2006-06-21 at 13:35 -0400, Matthias Clasen wrote: > So, with GTK+ 2.10 on the finish line, I tried to make a quick > list of things we may want to look at for 2.12, as input to > GUADEC discussions. > Stuff that needs more work > > - introspection > - international calendar support - use GBookmarkFile inside GtkFileSystem and add recent files inside GtkFileChooser. > Stuff that we need to figure out > > - canvas > - libsexy cherrypicking ? - EggIconChooser. AFAIR there were issues but I can't find any pointer to those. Also, I'd like to see the thumbnailing code added to GTK, and the thumbnail helpers changed from using GConf to a lower level position in the stack. Ciao, Emmanuele. -- Emmanuele Bassi, E: ebassi@gmail.com W: http://www.emmanuelebassi.net B: http://log.emmanuelebassi.net From kris@babi-pangang.org Thu Jun 22 10:07:12 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 9474E3B07EB for ; Thu, 22 Jun 2006 10:07:12 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00887-04 for ; Thu, 22 Jun 2006 10:07:09 -0400 (EDT) Received: from nasi-goreng.babi-pangang.org (nasi-goreng.babi-pangang.org [83.166.137.20]) by menubar.gnome.org (Postfix) with ESMTP id ECDDC3B07F0 for ; Thu, 22 Jun 2006 10:07:08 -0400 (EDT) Received: by nasi-goreng.babi-pangang.org (Postfix, from userid 1000) id 5DB383DCA0; Thu, 22 Jun 2006 16:07:04 +0200 (CEST) Date: Thu, 22 Jun 2006 16:07:04 +0200 From: Kristian Rietveld To: Matthias Clasen Subject: Re: Looking beyond 2.10 Message-ID: <20060622140703.GA15275@babi-pangang.org> References: <1150911355.15532.100.camel@golem.boston.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1150911355.15532.100.camel@golem.boston.redhat.com> User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.565 tagged_above=-999 required=2 tests=[AWL=0.034, BAYES_00=-2.599] X-Spam-Score: -2.565 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 14:07:12 -0000 On Wed, Jun 21, 2006 at 01:35:55PM -0400, Matthias Clasen wrote: > Stuff that needs more work > > - introspection > - international calendar support (I want to try to do multiple row DnD in GtkTreeView for real now. But I won't promise anything :) -kris. From jnoreiko@yahoo.com Thu Jun 22 10:28:15 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id CEBD43B0110 for ; Thu, 22 Jun 2006 10:28:15 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01906-05 for ; Thu, 22 Jun 2006 10:28:15 -0400 (EDT) Received: from web32406.mail.mud.yahoo.com (web32406.mail.mud.yahoo.com [68.142.207.199]) by menubar.gnome.org (Postfix) with SMTP id DCE8B3B0251 for ; Thu, 22 Jun 2006 10:28:14 -0400 (EDT) Received: (qmail 59923 invoked by uid 60001); 22 Jun 2006 14:28:14 -0000 Message-ID: <20060622142814.59921.qmail@web32406.mail.mud.yahoo.com> Received: from [172.203.129.193] by web32406.mail.mud.yahoo.com via HTTP; Thu, 22 Jun 2006 15:28:14 BST Date: Thu, 22 Jun 2006 15:28:14 +0100 (BST) From: Joachim Noreiko Subject: Re: Looking beyond 2.10 To: gtk-devel-list@gnome.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-0.405 tagged_above=-999 required=2 tests=[AWL=-1.612, BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2, DNS_FROM_RFC_WHOIS=1.447, RCVD_IN_SORBS_SOCKS=2.159] X-Spam-Score: -0.405 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 14:28:16 -0000 > Date: Wed, 21 Jun 2006 13:35:55 -0400 > From: Matthias Clasen > Subject: Looking beyond 2.10 > So, with GTK+ 2.10 on the finish line, I tried to > make a quick > list of things we may want to look at for 2.12, as > input to > GUADEC discussions. > > (Of course, bugzilla has an endless supply of > feature requests > and bugs that one can work on, these are just the > things that > came to my mind first) > I feel like I'm talking to myself here, but please could someone look at adding a help button to the fileselector. ___________________________________________________________ Inbox full of spam? Get leading spam protection and 1GB storage with All New Yahoo! Mail. http://uk.docs.yahoo.com/nowyoucan.html From tristan.van.berkom@gmail.com Thu Jun 22 13:10:30 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id A0DBC3B0690 for ; Thu, 22 Jun 2006 13:10:30 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12156-06 for ; Thu, 22 Jun 2006 13:10:28 -0400 (EDT) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.225]) by menubar.gnome.org (Postfix) with ESMTP id 215163B0137 for ; Thu, 22 Jun 2006 13:10:28 -0400 (EDT) Received: by wr-out-0506.google.com with SMTP id i12so437125wra for ; Thu, 22 Jun 2006 10:10:27 -0700 (PDT) Received: by 10.54.153.18 with SMTP id a18mr2404093wre; Thu, 22 Jun 2006 10:10:27 -0700 (PDT) Received: from ?66.48.170.242? ( [66.48.170.242]) by mx.gmail.com with ESMTP id 7sm1704382wrl.2006.06.22.10.10.22; Thu, 22 Jun 2006 10:10:27 -0700 (PDT) Message-ID: <449AD300.3030809@gnome.org> Date: Thu, 22 Jun 2006 13:27:28 -0400 User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mclasen@redhat.com Subject: Re: Looking beyond 2.10 References: <1150911355.15532.100.camel@golem.boston.redhat.com> <1150984971.5346.12.camel@localhost> In-Reply-To: <1150984971.5346.12.camel@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit From: Tristan Van Berkom X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.216 tagged_above=-999 required=2 tests=[AWL=0.384, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.216 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 17:10:30 -0000 Emmanuele Bassi wrote: >Hi; > >On Wed, 2006-06-21 at 13:35 -0400, Matthias Clasen wrote: > > >>So, with GTK+ 2.10 on the finish line, I tried to make a quick >>list of things we may want to look at for 2.12, as input to >>GUADEC discussions. >> >> Heh, unfortunately I wont be at GAUDEC to discuss any of this (which I am sure would be a great experience), so I'll do my best from the mailing lists and irc to tag along :) In light of the new Gtk Builder code getting in, I would like to propose that we depricate UIManager completely in favour of the Gtk Builder and provide a unified front for the creation of GObjects parsed from ui descriptions (or whatever the new "glade file" is to be called). My proposals to address issues of UI merging and handling of GtkActions are described in detail in these to emails: http://mail.gnome.org/archives/gtk-devel-list/2006-May/msg00157.html http://mail.gnome.org/archives/gtk-devel-list/2006-May/msg00166.html Please let me know your thoughts on the proposition and design, if accepted; I am sure I can get all this "ui merging/action subscription" stuff working properly inside of one month... hopefully leaving time enough for it to mature before 2.12. Cheers, -Tristan From sven@gimp.org Thu Jun 22 14:23:14 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C09883B062A for ; Thu, 22 Jun 2006 14:23:14 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16777-05 for ; Thu, 22 Jun 2006 14:23:11 -0400 (EDT) Received: from buzzloop.caiaq.de (buzzloop.caiaq.de [212.112.241.133]) by menubar.gnome.org (Postfix) with ESMTP id 26D1A3B05BF for ; Thu, 22 Jun 2006 14:23:08 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by buzzloop.caiaq.de (Postfix) with ESMTP id 194427F402E; Thu, 22 Jun 2006 20:23:10 +0200 (CEST) Received: from buzzloop.caiaq.de ([127.0.0.1]) by localhost (buzzloop [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11007-03; Thu, 22 Jun 2006 20:23:09 +0200 (CEST) Received: from [192.168.3.158] (i577B6734.versanet.de [87.123.103.52]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by buzzloop.caiaq.de (Postfix) with ESMTP id A11AD7F4024; Thu, 22 Jun 2006 20:23:09 +0200 (CEST) Subject: Re: Looking beyond 2.10 From: Sven Neumann To: Joachim Noreiko In-Reply-To: <20060622142814.59921.qmail@web32406.mail.mud.yahoo.com> References: <20060622142814.59921.qmail@web32406.mail.mud.yahoo.com> Content-Type: text/plain Date: Thu, 22 Jun 2006 20:22:49 +0200 Message-Id: <1151000569.12681.22.camel@bender> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.692 tagged_above=-999 required=2 tests=[AWL=0.907, BAYES_00=-2.599] X-Spam-Score: -1.692 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 18:23:15 -0000 Hi, On Thu, 2006-06-22 at 15:28 +0100, Joachim Noreiko wrote: > I feel like I'm talking to myself here, but please > could someone look at adding a help button to the fileselector. GIMP has done that for quite a while already, so there's nothing that would keep an application from adding a Help button to the file-chooser. What's the point of adding one by default? By default it won't be connected to anything useful and what good is a help button that does nothing when the user clicks it? Sven From murrayc@murrayc.com Thu Jun 22 14:45:17 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 2C2CB3B0649 for ; Thu, 22 Jun 2006 14:45:17 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18110-06 for ; Thu, 22 Jun 2006 14:45:13 -0400 (EDT) Received: from swarthymail-a1.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by menubar.gnome.org (Postfix) with ESMTP id A79253B083A for ; Thu, 22 Jun 2006 14:45:12 -0400 (EDT) Received: from noname (p5497EA12.dip.t-dialin.net [84.151.234.18]) by swarthymail-a1.dreamhost.com (Postfix) with ESMTP id 71BF690FA6; Thu, 22 Jun 2006 11:45:00 -0700 (PDT) Subject: Re: GTK+ 2.10, the endgame From: Murray Cumming To: Emmanuele Bassi In-Reply-To: <1150502750.2668.12.camel@localhost> References: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> <1150390229.17566.191.camel@cacharro.xalalinux.org> <1150391737.3187.33.camel@dhcp83-98.boston.redhat.com> <1150447930.5806.4.camel@localhost.localdomain> <1150502750.2668.12.camel@localhost> Content-Type: text/plain Date: Thu, 22 Jun 2006 20:44:54 +0200 Message-Id: <1151001894.5804.33.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.477 tagged_above=-999 required=2 tests=[AWL=0.122, BAYES_00=-2.599] X-Spam-Score: -2.477 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 18:45:17 -0000 On Sat, 2006-06-17 at 01:05 +0100, Emmanuele Bassi wrote: > Hi Murray, > > On Fri, 2006-06-16 at 10:52 +0200, Murray Cumming wrote: > > I'm also concerned about the recent files stuff. Do we now have > > UIManager integration of that? > > No, and I am to blame because I had less time to spend on fixing this > issue. > > Mostly, I've been stuck on how to implement an action for both the menu > and toolbars using the same tag. In the meantime, a nice and clean way > to integrate the GtkRecentChooserMenu inside a GtkUIManager is to > subclass GtkAction into a custom action that automatically adds a recent > chooser menu to the menu item it creates, and use a placeholder in the > UI definition (most applications using EggRecentViewUIManager already > have that placeholder present). > > A working example is available here: > > http://www.gnome.org/~ebassi/test-uimanager.c > > The action code itself is one hundred lines long and can easily be > hidden inside an helper file; it's approximately how GtkRecentAction > would be implemented, anyway. I hereby give permission to do whatever > you want to do with it. > > I understand that it's sub-optimal, and hopefully this should really go > away once there's an action inside GTK. Do you feel that the existing API might need to be changed to add this to a future version of GTK+? For instance, would it need need existing classes to implement new interfaces, or add new signals? -- Murray Cumming murrayc@murrayc.com www.murrayc.com www.openismus.com From ebassi@gmail.com Thu Jun 22 15:19:39 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id F26233B077F for ; Thu, 22 Jun 2006 15:19:38 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20426-04 for ; Thu, 22 Jun 2006 15:19:35 -0400 (EDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.186]) by menubar.gnome.org (Postfix) with ESMTP id 2A7653B062A for ; Thu, 22 Jun 2006 15:19:35 -0400 (EDT) Received: by nf-out-0910.google.com with SMTP id h2so304101nfe for ; Thu, 22 Jun 2006 12:19:34 -0700 (PDT) Received: by 10.48.242.3 with SMTP id p3mr1697803nfh; Thu, 22 Jun 2006 12:19:34 -0700 (PDT) Received: from ?192.168.1.70? ( [86.136.65.180]) by mx.gmail.com with ESMTP id z73sm2097413nfb.2006.06.22.12.19.33; Thu, 22 Jun 2006 12:19:33 -0700 (PDT) Subject: Re: GTK+ 2.10, the endgame From: Emmanuele Bassi To: Murray Cumming In-Reply-To: <1151001894.5804.33.camel@localhost.localdomain> References: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> <1150390229.17566.191.camel@cacharro.xalalinux.org> <1150391737.3187.33.camel@dhcp83-98.boston.redhat.com> <1150447930.5806.4.camel@localhost.localdomain> <1150502750.2668.12.camel@localhost> <1151001894.5804.33.camel@localhost.localdomain> Content-Type: text/plain Date: Thu, 22 Jun 2006 20:19:32 +0100 Message-Id: <1151003972.5346.29.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.371 tagged_above=-999 required=2 tests=[AWL=0.229, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.371 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 19:19:39 -0000 Hi Murray; On Thu, 2006-06-22 at 20:44 +0200, Murray Cumming wrote: > > The action code itself is one hundred lines long and can easily be > > hidden inside an helper file; it's approximately how GtkRecentAction > > would be implemented, anyway. I hereby give permission to do whatever > > you want to do with it. > > > > I understand that it's sub-optimal, and hopefully this should really go > > away once there's an action inside GTK. > > Do you feel that the existing API might need to be changed to add this > to a future version of GTK+? For instance, would it need need existing > classes to implement new interfaces, or add new signals? The point is: I don't know. :-) The currently unresolved issue is that I can't find a way to use this UI definition:

which is the "right" way to offer a submenu and a menu inside a toolbar item. The only case where I know for sure would require adding API is the case where you want an inlined recent files list - as it would require the ability to create a list of menu items instead of a single widget with the same GtkAction. At this point, I'd like a UIManager author/guru to step in and see if I'm doing something wrong. The bug is #338843 [1]. +++ http://bugzilla.gnome.org/show_bug.cgi?id=338843 -- Emmanuele Bassi, E: ebassi@gmail.com W: http://www.emmanuelebassi.net B: http://log.emmanuelebassi.net From jnoreiko@yahoo.com Thu Jun 22 17:19:57 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 48DC33B07DC for ; Thu, 22 Jun 2006 17:19:57 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27254-05 for ; Thu, 22 Jun 2006 17:19:56 -0400 (EDT) Received: from web32404.mail.mud.yahoo.com (web32404.mail.mud.yahoo.com [68.142.207.197]) by menubar.gnome.org (Postfix) with SMTP id 6C40C3B0601 for ; Thu, 22 Jun 2006 17:19:56 -0400 (EDT) Received: (qmail 9697 invoked by uid 60001); 22 Jun 2006 21:19:55 -0000 Message-ID: <20060622211955.9695.qmail@web32404.mail.mud.yahoo.com> Received: from [172.216.98.138] by web32404.mail.mud.yahoo.com via HTTP; Thu, 22 Jun 2006 22:19:55 BST Date: Thu, 22 Jun 2006 22:19:55 +0100 (BST) From: Joachim Noreiko Subject: Re: Looking beyond 2.10 To: Sven Neumann In-Reply-To: <1151000569.12681.22.camel@bender> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.693 tagged_above=-999 required=2 tests=[AWL=-0.741, BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2, DNS_FROM_RFC_WHOIS=1.447] X-Spam-Score: -1.693 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 21:19:57 -0000 --- Sven Neumann wrote: > Hi, > > On Thu, 2006-06-22 at 15:28 +0100, Joachim Noreiko > wrote: > > > I feel like I'm talking to myself here, but please > > could someone look at adding a help button to the > fileselector. > > GIMP has done that for quite a while already, so > there's nothing that > would keep an application from adding a Help button > to the file-chooser. > What's the point of adding one by default? By > default it won't be > connected to anything useful and what good is a help > button that does > nothing when the user clicks it? The documentation for the fileselector has been in the GNOME Desktop User Guide since 2.14. I'm sure I posted on this list when I wrote it. ___________________________________________________________ All new Yahoo! Mail "The new Interface is stunning in its simplicity and ease of use." - PC Magazine http://uk.docs.yahoo.com/nowyoucan.html From scott@asofyet.org Thu Jun 22 22:52:08 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 046A73B05F9 for ; Thu, 22 Jun 2006 22:52:08 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09189-02 for ; Thu, 22 Jun 2006 22:52:06 -0400 (EDT) Received: from looneymail-a2.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by menubar.gnome.org (Postfix) with ESMTP id 39B703B071C for ; Thu, 22 Jun 2006 22:52:06 -0400 (EDT) Received: from [192.168.0.100] (unknown [74.131.115.107]) by looneymail-a2.dreamhost.com (Postfix) with ESMTP id 2C0F016E8CD for ; Thu, 22 Jun 2006 19:52:05 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v750) In-Reply-To: <20060622211955.9695.qmail@web32404.mail.mud.yahoo.com> References: <20060622211955.9695.qmail@web32404.mail.mud.yahoo.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: muppet Subject: Re: Looking beyond 2.10 Date: Thu, 22 Jun 2006 22:51:48 -0400 To: GTK+ development mailing list X-Mailer: Apple Mail (2.750) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.558 tagged_above=-999 required=2 tests=[AWL=0.041, BAYES_00=-2.599] X-Spam-Score: -2.558 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2006 02:52:08 -0000 On Jun 22, 2006, at 5:19 PM, Joachim Noreiko wrote: > > --- Sven Neumann wrote: > >> GIMP has done that for quite a while already, so there's nothing >> that would keep an application from adding a Help button to the >> file-chooser. What's the point of adding one by default? By >> default it won't be connected to anything useful and what good is >> a help button that does nothing when the user clicks it? > > The documentation for the fileselector has been in the GNOME > Desktop User Guide since 2.14. I'm sure I posted on this list when > I wrote it. That doesn't do much good for gtk+ environments that don't involve GNOME. -- Jolt is my co-pilot. -- Slogan on a giant paper airplane hung in Lobby 7 at MIT. http://hacks.mit.edu/ From magnusbe@algonet.se Fri Jun 23 05:33:19 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 0D0353B0591 for ; Fri, 23 Jun 2006 05:33:19 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31880-05 for ; Fri, 23 Jun 2006 05:33:17 -0400 (EDT) Received: from pne-smtpout2-sn2.hy.skanova.net (pne-smtpout2-sn2.hy.skanova.net [81.228.8.164]) by menubar.gnome.org (Postfix) with ESMTP id 294473B041F for ; Fri, 23 Jun 2006 05:33:16 -0400 (EDT) Received: from feathers (83.252.145.175) by pne-smtpout2-sn2.hy.skanova.net (7.2.072.1) (authenticated as u73906364) id 449A811D0002C366 for gtk-devel-list@gnome.org; Fri, 23 Jun 2006 11:33:15 +0200 Date: Fri, 23 Jun 2006 12:31:05 +0200 From: Magnus Bergman To: GTK+ devel list Subject: Problems making loaders for header-less images Message-ID: <20060623123105.1589fed8@feathers> X-Mailer: Sylpheed-Claws 2.3.0 (GTK+ 2.8.16; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.522 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, TW_GD=0.077] X-Spam-Score: -2.522 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2006 09:33:19 -0000 I've made a couple of gdk-pixbuf loaders for formats that cannot be finger printed using a pattern, because they totaly lack some kind of header or that information is located at the end of the file. This has causes me the following problems: * If one loader handles several (similar) formats that cannot be distinguished from each other by looking at the first bytes. Then gdk-pixbuf uses other means to distinguish between them (extension or mime-type) but the information about what the match was based on is unavailable to loader (or am I missing something). Can this be solved is some way (except by making a different loader for each variant)? Example: There is an image format called pi1 (the most common format on the Atari ST). It consists of one word telling about the resolution, the palette and a copy of the screen memory. A variant of the format is called pc1 and has the only difference that the screen memory image is compressed. It is easy to distinguish between them using the extension or by looking at the file size (pi1 has a fixed size of 32066 bytes while pc1 is always smaller). * If a loader doesn't provide any fingerprinting pattern gdk-pixbuf causes a segfault at runtime then trying to load a picture in any format. Is the loader required to provide at least one pattern or is this a bug? * If the only thing that is known about the format is that it starts with one or more zeros, then gdk-pixbuf-query-loaders will refuse to register the loader because it considers the pattern to be empty. This could be avoided to checking the length of the mask field instead to the prefix field. A bug? From gcottenc@gmail.com Fri Jun 23 07:57:54 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id DA1E43B0678 for ; Fri, 23 Jun 2006 07:57:54 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08025-10 for ; Fri, 23 Jun 2006 07:57:53 -0400 (EDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.192]) by menubar.gnome.org (Postfix) with ESMTP id 7D8543B01A4 for ; Fri, 23 Jun 2006 07:57:53 -0400 (EDT) Received: by wx-out-0102.google.com with SMTP id s6so466104wxc for ; Fri, 23 Jun 2006 04:57:53 -0700 (PDT) Received: by 10.70.103.17 with SMTP id a17mr4494204wxc; Fri, 23 Jun 2006 04:57:52 -0700 (PDT) Received: by 10.70.46.6 with HTTP; Fri, 23 Jun 2006 04:57:52 -0700 (PDT) Message-ID: Date: Fri, 23 Jun 2006 13:57:52 +0200 From: "Guillaume Cottenceau" To: "Matthias Clasen" Subject: Re: Fwd: GTK+ 2.10, the endgame In-Reply-To: <1150895599.15532.80.camel@golem.boston.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> <1150895599.15532.80.camel@golem.boston.redhat.com> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.564 tagged_above=-999 required=2 tests=[AWL=0.036, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.564 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2006 11:57:55 -0000 Hi Matthias, > The online documentation is still at 2.9.2. I hope to find time > to update it to 2.9.4 before leaving for GUADEC tomorrow. Please warn us when the online API documentation regarding new symbols is fully freezed for 2.10 so that we can start working on adding the new symbols in bindings. Thanks! -- Guillaume Cottenceau - http://zarb.org/~gc/ From hfiguiere@teaser.fr Fri Jun 23 11:50:42 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 100083B04A7 for ; Fri, 23 Jun 2006 11:50:42 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21632-05 for ; Fri, 23 Jun 2006 11:50:39 -0400 (EDT) Received: from xandros.com (smtp1.xandros.com [209.87.238.70]) by menubar.gnome.org (Postfix) with ESMTP id 83AC63B0907 for ; Fri, 23 Jun 2006 11:50:33 -0400 (EDT) Received: from [172.16.1.95] (unknown [209.87.238.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by xandros.com (Postfix) with ESMTP id 6A6F223033 for ; Fri, 23 Jun 2006 11:50:32 -0400 (EDT) Message-ID: <449C0DC7.60502@teaser.fr> Date: Fri, 23 Jun 2006 11:50:31 -0400 From: Hubert Figuiere User-Agent: Thunderbird 1.5.0.4 (X11/20060615) MIME-Version: 1.0 To: gtk-devel-list@gnome.org Subject: Re: Looking beyond 2.10 References: <20060622142814.59921.qmail@web32406.mail.mud.yahoo.com> <1151000569.12681.22.camel@bender> In-Reply-To: <1151000569.12681.22.camel@bender> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.544 tagged_above=-999 required=2 tests=[AWL=0.055, BAYES_00=-2.599] X-Spam-Score: -2.544 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2006 15:50:42 -0000 Sven Neumann wrote: > GIMP has done that for quite a while already, so there's nothing that > would keep an application from adding a Help button to the file-chooser. > What's the point of adding one by default? By default it won't be > connected to anything useful and what good is a help button that does > nothing when the user clicks it? Why not putting it in only if the signal is connected ? (a signal like "help_requested"). Hub From gjc@inescporto.pt Fri Jun 23 18:23:20 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 9B8D83B0847 for ; Fri, 23 Jun 2006 18:23:20 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08741-04 for ; Fri, 23 Jun 2006 18:23:19 -0400 (EDT) Received: from animal.inescn.pt (animal.inescn.pt [194.117.24.9]) by menubar.gnome.org (Postfix) with ESMTP id AC38C3B0971 for ; Fri, 23 Jun 2006 18:23:18 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by animal.inescn.pt (8.13.6/8.13.6/7) with ESMTP id k5NMNG4Z018417; Fri, 23 Jun 2006 23:23:17 +0100 (WEST) Received: from pong.inescporto.pt (pong.inescn.pt [194.117.26.74]) by animal.inescn.pt (8.13.6/8.13.6/5) with ESMTP id k5NMN5ql018402; Fri, 23 Jun 2006 23:23:05 +0100 (WEST) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by pong.inescporto.pt (Postfix) with ESMTP id 31501155721; Fri, 23 Jun 2006 23:19:37 +0100 (WEST) Subject: Re: Looking beyond 2.10 From: "Gustavo J. A. M. Carneiro" To: Matthias Clasen In-Reply-To: <1150911355.15532.100.camel@golem.boston.redhat.com> References: <1150911355.15532.100.camel@golem.boston.redhat.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-2prtuoBhNnmmz3lcPkNU" Date: Fri, 23 Jun 2006 23:22:59 +0100 Message-Id: <1151101379.5189.5.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 X-Virus-Scanned: by amavisd-new at inescporto.pt X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.428 tagged_above=-999 required=2 tests=[AWL=0.038, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.428 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2006 22:23:20 -0000 --=-2prtuoBhNnmmz3lcPkNU Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Qua, 2006-06-21 =C3=A0s 13:35 -0400, Matthias Clasen escreveu: > So, with GTK+ 2.10 on the finish line, I tried to make a quick > list of things we may want to look at for 2.12, as input to > GUADEC discussions. >=20 > Patches almost ready to go in >=20 > - libglade integration > - new tooltips api >=20 >=20 > Stuff that needs more work >=20 > - introspection I'm willing to do some work in introspection. However, if you say it needs more work then I think you should identify precisely what work needs to be done. I could try guessing, but that usually leads to patches sitting in bugzilla for whole release cycles (e.g. #313268). Regards. --=20 Gustavo J. A. M. Carneiro The universe is always one step beyond logic --=-2prtuoBhNnmmz3lcPkNU Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta =?ISO-8859-1?Q?=E9?= uma parte de mensagem assinada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQBEnGnD2XoHyMdS6TARAk0JAJ95rFWntIs1xJ0hPTYMBwXdg26PgACeJo0x DrkoftT0jbf/hSym/poi0Uo= =WVRK -----END PGP SIGNATURE----- --=-2prtuoBhNnmmz3lcPkNU-- From jnoreiko@yahoo.com Sat Jun 24 03:40:19 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id EBA9B3B00F5 for ; Sat, 24 Jun 2006 03:40:18 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30651-07 for ; Sat, 24 Jun 2006 03:40:17 -0400 (EDT) Received: from web32401.mail.mud.yahoo.com (web32401.mail.mud.yahoo.com [68.142.207.194]) by menubar.gnome.org (Postfix) with SMTP id BD1E03B0194 for ; Sat, 24 Jun 2006 03:40:16 -0400 (EDT) Received: (qmail 229 invoked by uid 60001); 24 Jun 2006 07:40:15 -0000 Message-ID: <20060624074015.227.qmail@web32401.mail.mud.yahoo.com> Received: from [172.212.40.3] by web32401.mail.mud.yahoo.com via HTTP; Sat, 24 Jun 2006 08:40:15 BST Date: Sat, 24 Jun 2006 08:40:15 +0100 (BST) From: Joachim Noreiko Subject: Re: Looking beyond 2.10 To: gtk-devel-list@gnome.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.681 tagged_above=-999 required=2 tests=[AWL=-0.729, BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2, DNS_FROM_RFC_WHOIS=1.447] X-Spam-Score: -1.681 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2006 07:40:19 -0000 Message: 6 Date: Thu, 22 Jun 2006 22:51:48 -0400 From: muppet Subject: Re: Looking beyond 2.10 > The documentation for the fileselector has been in the GNOME > Desktop User Guide since 2.14. I'm sure I posted on this list when > I wrote it. That doesn't do much good for gtk+ environments that don't involve GNOME. -------------- Then figure out some way for it to detect whether it's on GNOME or not, maybe? Dialog boxes used in GNOME required help buttons, especially ones with as many features as the fileselector. Please could somebody look into this? I put a lot of work into writing the docs, and that's not a huge amount of use until it's linked to. ___________________________________________________________ Inbox full of spam? Get leading spam protection and 1GB storage with All New Yahoo! Mail. http://uk.docs.yahoo.com/nowyoucan.html From macfreesoft@free.fr Sat Jun 24 05:56:35 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C31133B02D5 for ; Sat, 24 Jun 2006 05:56:35 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05338-06 for ; Sat, 24 Jun 2006 05:56:33 -0400 (EDT) Received: from smtp010.mail.ukl.yahoo.com (smtp010.mail.ukl.yahoo.com [217.12.11.79]) by menubar.gnome.org (Postfix) with SMTP id 3D48E3B02B2 for ; Sat, 24 Jun 2006 05:56:33 -0400 (EDT) Received: (qmail 6982 invoked from network); 24 Jun 2006 09:56:32 -0000 Received: from unknown (HELO ?192.168.1.10?) (a?gillaizeau@217.66.126.141 with plain) by smtp010.mail.ukl.yahoo.com with SMTP; 24 Jun 2006 09:56:32 -0000 Message-ID: <449D0C4E.504@free.fr> Date: Sat, 24 Jun 2006 11:56:30 +0200 From: Aymeric GILLAIZEAU User-Agent: Thunderbird 1.5 (Macintosh/20051201) MIME-Version: 1.0 To: Easy B Subject: Gtk+.framework snapshot Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.033 tagged_above=-999 required=2 tests=[BAYES_05=-1.11, TW_GT=0.077] X-Spam-Score: -1.033 X-Spam-Level: X-Mailman-Approved-At: Sat, 24 Jun 2006 06:24:14 -0400 Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2006 09:56:36 -0000 > Hi guys > > Well I wasn't that happy with the result I got from the mono scripts > so I pretty much rewrote them. I now install everything into one > framework. I still don't have libtiff and jpeg support though. How is > the best way to make the gtk configure look for libtiff 3.8.2? I saw > that it looks for 3.4. Do I have to patch configure? > > Anyway, who's interested can give my installer a try. It installs the > framework into /Library/Frameworks and Gtk-Demo into /Applications. I > managed to compile one of my small apps by setting PKG_CONFIG_PATH to > /Library/Frameworks/Gtk+.framework/Libraries/pkgconfig/ and > ./configure, make. > > To make an application bundles I use this script: > http://www.easyb.ch/files/bundleApp.sh > > The Installer you can download here: > http://www.easyb.ch/files/Gtk%2B-2.9.1%20Framework%20snapshot.pkg.zip > > Cheers, > Ezra. Why to not use the already built Frameworks used by Scribus ? Instead of having many times the same things, it is present once and used by anyone. The problem with OpenSource is that everyone makes his cooking in his place without never taking consideration in the work others has already done. It could save time, also use less space on the drive, and so save room. http://www.scribus.net/index.php?name=Sections&req=viewarticle&artid=3&page=1 > ome support libraries, which should be moved to /Library/Frameworks : > Qt.framework > Freetype.framework > Fontconfig2.framework > libart.framework > libexpat.framework > libjpeg.framework > liblcms.framework > libpng.framework > libtiff.framework ___________________________________________________________________________ Yahoo! Mail rinvente le mail ! Dcouvrez le nouveau Yahoo! Mail et son interface rvolutionnaire. http://fr.mail.yahoo.com From alex@halogen-dg.com Sat Jun 24 08:41:32 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 92B9B3B013A for ; Sat, 24 Jun 2006 08:41:32 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13862-09 for ; Sat, 24 Jun 2006 08:41:31 -0400 (EDT) Received: from appserver.halogen.kharkov.ua (appserver.halogen.kharkov.ua [217.144.70.65]) by menubar.gnome.org (Postfix) with ESMTP id 256C33B00FB for ; Sat, 24 Jun 2006 08:41:31 -0400 (EDT) Received: (qmail 29949 invoked from network); 24 Jun 2006 15:41:32 +0300 Received: from dom.koval.kharkov.ua (217.144.70.182) by alex.halogen.kharkov.ua with AES256-SHA encrypted SMTP; 24 Jun 2006 15:41:32 +0300 Date: Sat, 24 Jun 2006 15:45:30 +0300 (EEST) From: alex@halogen-dg.com X-X-Sender: alex@dom.koval.kharkov.ua To: gtk-devel-list@gnome.org Subject: gtk file open dialog usability. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-0.858 tagged_above=-999 required=2 tests=[AWL=-0.709, BAYES_05=-1.11, NO_REAL_NAME=0.961] X-Spam-Score: -0.858 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2006 12:41:32 -0000 Anyone except me also disappointed by it? Any way how we can have old file open dialog back? I really find it very frustating and explained why, with some images here: http://www.halogen-dg.com/alex/file_selection_dialog/GtkFileOpenBadUsability -- Alex V. Koval http://www.halogen-dg.com/ http://www.zwarehouse.org/ From gnome-gtk-devel-list@m.gmane.org Sat Jun 24 08:49:58 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id F15263B00A8 for ; Sat, 24 Jun 2006 08:49:57 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14302-05 for ; Sat, 24 Jun 2006 08:49:55 -0400 (EDT) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by menubar.gnome.org (Postfix) with ESMTP id 402703B00FB for ; Sat, 24 Jun 2006 08:49:55 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Fu7a8-0004yS-Mc for gtk-devel-list@gnome.org; Sat, 24 Jun 2006 14:49:48 +0200 Received: from 84.52.165.220 ([84.52.165.220]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 24 Jun 2006 14:49:48 +0200 Received: from jernej.listsonly by 84.52.165.220 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 24 Jun 2006 14:49:48 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gtk-devel-list@gnome.org From: Jernej =?utf-7?Q?Simon+AQ0-i+AQ0-?= Subject: Re: gtk file open dialog usability. Date: Sat, 24 Jun 2006 14:49:37 +0200 Lines: 9 Message-ID: <10umqokepyu8y.10vhe4alqj04.dlg@40tude.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset="utf-7" Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 84.52.165.220 User-Agent: 40tude_Dialog/2.0.15.84 (cfc06cd9.460.419) X-Face: BOCQpf4)pfW>6Ya?'@oBT]=LBF; <6`_r[6pwqLggP!RG:*D)^Fz; O(I'n(FwJ{]5lo>g.H. _,Z:_`nLsfz]]8V'&9OmX)o-bXd?(P|CO=@5}[y\0rH9!AN&Qt:GXC(r!1}$q@@C]x`](7+#C]WRzw L|0W}vdFR/b@AFWIw~ X-Ultimate-Answer: 42 Sender: news X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.008 tagged_above=-999 required=2 tests=[AWL=0.016, BAYES_00=-2.599, FROM_EXCESS_QP=0, RCVD_NUMERIC_HELO=1.5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, TW_GT=0.077] X-Spam-Score: -1.008 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2006 12:49:58 -0000 On Sat, 24 Jun 2006 15:45:30 +-0300 (EEST), alex@halogen-dg.com wrote: > Anyone except me also disappointed by it? Search the archives, you're far from being the only one. -- < Jernej Simon+AQ0-i+AQ0- >< http://deepthought.ena.si/ > < Contact address: >< jernej simoncic at isg si > From alex@halogen-dg.com Sat Jun 24 09:01:55 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id F3A283B00A8 for ; Sat, 24 Jun 2006 09:01:54 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15013-06 for ; Sat, 24 Jun 2006 09:01:54 -0400 (EDT) Received: from appserver.halogen.kharkov.ua (appserver.halogen.kharkov.ua [217.144.70.65]) by menubar.gnome.org (Postfix) with ESMTP id 388713B0490 for ; Sat, 24 Jun 2006 09:01:53 -0400 (EDT) Received: (qmail 32296 invoked from network); 24 Jun 2006 16:01:54 +0300 Received: from dom.koval.kharkov.ua (217.144.70.182) by alex.halogen.kharkov.ua with AES256-SHA encrypted SMTP; 24 Jun 2006 16:01:54 +0300 Date: Sat, 24 Jun 2006 16:05:52 +0300 (EEST) From: alex@halogen-dg.com X-X-Sender: alex@dom.koval.kharkov.ua To: gtk-devel-list@gnome.org Subject: Re: gtk file open dialog usability. In-Reply-To: <10umqokepyu8y.10vhe4alqj04.dlg@40tude.net> Message-ID: References: <10umqokepyu8y.10vhe4alqj04.dlg@40tude.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.533 tagged_above=-999 required=2 tests=[AWL=0.028, BAYES_00=-2.599, NO_REAL_NAME=0.961, TW_GT=0.077] X-Spam-Score: -1.533 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2006 13:01:55 -0000 Hi Jernej On Sat, 24 Jun 2006, Jernej Simon+AQ0-i+AQ0- wrote: > On Sat, 24 Jun 2006 15:45:30 +-0300 (EEST), alex@halogen-dg.com wrote: > >> Anyone except me also disappointed by it? I am happy that people noticed that, too. The question is what can we do to fix this? My feeling is that at least 2 things could be done: 1. Make automatic selection of file optional (like its being done in KDE, in grey) 2. Do not display additional file open dialog when I *already* typed file name. > > Search the archives, you're far from being the only one. > BTW, before doing this post I've tried to search for "file dialog usability GTK". To my regret mail.gnome.org mailman search is not working ("The requested URL /mailman/search was not found on this server."),so I searched google a little, did not found any good results and posted here... Althrough this search returns more results: http://www.google.com.ua/search?q=gtk+file+open+usability&start=0&ie=utf-8&oe=utf-8&client=firefox-a&rls=org.mozilla:en-US:official Alex From g.tagliaretti@gmail.com Sat Jun 24 09:53:34 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 2C1C83B02E0 for ; Sat, 24 Jun 2006 09:53:34 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17447-04 for ; Sat, 24 Jun 2006 09:53:33 -0400 (EDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.178]) by menubar.gnome.org (Postfix) with ESMTP id 054D13B0228 for ; Sat, 24 Jun 2006 09:53:32 -0400 (EDT) Received: by py-out-1112.google.com with SMTP id i49so1099450pyi for ; Sat, 24 Jun 2006 06:52:59 -0700 (PDT) Received: by 10.35.99.14 with SMTP id b14mr3541165pym; Sat, 24 Jun 2006 06:52:56 -0700 (PDT) Received: by 10.35.132.18 with HTTP; Sat, 24 Jun 2006 06:52:56 -0700 (PDT) Message-ID: <35bf41160606240652s3da0fe6brd3915cd84c601114@mail.gmail.com> Date: Sat, 24 Jun 2006 15:52:56 +0200 From: "Gian Mario Tagliaretti" To: "alex@halogen-dg.com" Subject: Re: gtk file open dialog usability. In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.257 tagged_above=-999 required=2 tests=[AWL=0.066, BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2, SPF_PASS=-0.001, TW_GT=0.077] X-Spam-Score: -2.257 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2006 13:53:34 -0000 2006/6/24, alex@halogen-dg.com : > > Anyone except me also disappointed by it? > Any way how we can have old file open dialog back? code not complain :) > I really find it very frustating and explained > why, with some images here: > http://www.halogen-dg.com/alex/file_selection_dialog/GtkFileOpenBadUsability are you using gtk+ 2.9.x ? ciao -- Gian Mario Tagliaretti http://www.parafernalia.org/pygtk/ http://pygstdocs.berlios.de From timj@gtk.org Sat Jun 24 13:36:49 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 6B4403B006E; Sat, 24 Jun 2006 13:36:49 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27591-06; Sat, 24 Jun 2006 13:36:45 -0400 (EDT) Received: from holken.mikan.net (holken.mikan.net [83.145.56.183]) by menubar.gnome.org (Postfix) with ESMTP id C28AD3B06ED; Sat, 24 Jun 2006 13:36:44 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by holken.mikan.net (Postfix) with ESMTP id 59BF93352A5; Sat, 24 Jun 2006 19:36:26 +0200 (CEST) Received: from holken.mikan.net ([127.0.0.1]) by localhost (holken.mikan.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27952-05; Sat, 24 Jun 2006 19:36:22 +0200 (CEST) Received: from birnet.org (c135173.adsl.hansenet.de [213.39.135.173]) by holken.mikan.net (Postfix) with ESMTP id E12711844A; Sat, 24 Jun 2006 19:36:21 +0200 (CEST) Received: from master.birnet.private (localhost.localdomain [127.0.0.1]) by birnet.org (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k5OHaLjt023300 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 24 Jun 2006 19:36:21 +0200 Received: (from timj@localhost) by master.birnet.private (8.13.4/8.13.4/Submit) id k5OHZcXs023295; Sat, 24 Jun 2006 19:35:38 +0200 Date: Sat, 24 Jun 2006 19:35:38 +0200 (CEST) From: Tim Janik X-X-Sender: timj@master.birnet.private To: Gtk+ Developers Subject: Re: GTK+ meeting at GUADEC (Re: GTK+ 2.10, the endgame) In-Reply-To: Message-ID: References: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at holken.mikan.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.637 tagged_above=-999 required=2 tests=[AWL=-0.662, BAYES_05=-1.11, FORGED_RCVD_HELO=0.135] X-Spam-Score: -1.637 X-Spam-Level: X-Mailman-Approved-At: Sat, 24 Jun 2006 13:47:30 -0400 Cc: Federico Mena Quintero , Jonathan Blandford , Tim Janik , sandmann@daimi.au.dk, cworth@cworth.org, Komulainen Tommi , Alex Larsson , Michael Natterer , Kristian Rietveld , Matthias Clasen , Richard Hult , johan@gnome.org, michael meeks X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2006 17:36:49 -0000 On Thu, 15 Jun 2006, Tim Janik wrote: > the plan for that was to send out en email next friday/saturday (i.e > right at the guadec start) to figure/suggest dates suitable for > everyone to attend. we have gotten a room for the Gtk+ meeting now. it's on Sunday the 25th from 16:00-18:00 in the blue room (at the conference facility, second floor). --- ciaoTJ From torriem@chem.byu.edu Sun Jun 25 01:08:26 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id EA0E73B0079 for ; Sun, 25 Jun 2006 01:08:25 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17289-04 for ; Sun, 25 Jun 2006 01:08:22 -0400 (EDT) Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [63.240.77.83]) by menubar.gnome.org (Postfix) with ESMTP id ACB1F3B00A6 for ; Sun, 25 Jun 2006 01:08:22 -0400 (EDT) Received: from enterprise.local.lan (c-24-2-75-5.hsd1.ut.comcast.net[24.2.75.5]) by comcast.net (sccrmhc13) with ESMTP id <2006062505073001300me7qte>; Sun, 25 Jun 2006 05:07:31 +0000 Received: from enterprise.local.lan (enterprise.local.lan [127.0.0.1]) by enterprise.local.lan (8.13.1/8.12.8) with ESMTP id k5P57TFs002388 for ; Sat, 24 Jun 2006 23:07:29 -0600 Received: (from torriem@localhost) by enterprise.local.lan (8.13.1/8.13.1/Submit) id k5P57T1Z002387 for gtk-devel-list@gnome.org; Sat, 24 Jun 2006 23:07:29 -0600 X-Authentication-Warning: enterprise.local.lan: torriem set sender to torriem@chem.byu.edu using -f Subject: Re: Looking beyond 2.10 From: Michael Torrie To: gtk-devel-list@gnome.org In-Reply-To: References: <1150911355.15532.100.camel@golem.boston.redhat.com> <4499982C.1010004@teaser.fr> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Sat, 24 Jun 2006 23:07:29 -0600 Message-Id: <1151212049.32440.11.camel@enterprise.local.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-7) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.377 tagged_above=-999 required=2 tests=[AWL=0.010, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, TW_GT=0.077] X-Spam-Score: -2.377 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jun 2006 05:08:26 -0000 On Wed, 2006-06-21 at 18:26 -0400, Matthias Clasen wrote: > > I'm about to pick Qt as a toolkit for a personal project just because of > > that. > > Good luck. I was in the same boat as Hubert. I also ended up picking Qt. Although I like GTK much better, Qt was the best choice given the circumstances. I have not regretted it. But, as soon as GTK is fully supported on OS X, I will abandon Qt entirely, as GTK is cleaner, a little easier to work with, and, ironically, has better C++ bindings than Qt. > > Matthias > _______________________________________________ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-devel-list > From torriem@chem.byu.edu Sun Jun 25 01:21:50 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 36FD43B01F4 for ; Sun, 25 Jun 2006 01:21:50 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18141-02 for ; Sun, 25 Jun 2006 01:21:47 -0400 (EDT) Received: from sccrmhc14.comcast.net (sccrmhc14.comcast.net [204.127.200.84]) by menubar.gnome.org (Postfix) with ESMTP id DD6353B02BD for ; Sun, 25 Jun 2006 01:21:46 -0400 (EDT) Received: from enterprise.local.lan (c-24-2-75-5.hsd1.ut.comcast.net[24.2.75.5]) by comcast.net (sccrmhc14) with ESMTP id <2006062505211801400apa3je>; Sun, 25 Jun 2006 05:21:19 +0000 Received: from enterprise.local.lan (enterprise.local.lan [127.0.0.1]) by enterprise.local.lan (8.13.1/8.12.8) with ESMTP id k5P5LHWa002930; Sat, 24 Jun 2006 23:21:17 -0600 Received: (from torriem@localhost) by enterprise.local.lan (8.13.1/8.13.1/Submit) id k5P5LH4T002929; Sat, 24 Jun 2006 23:21:17 -0600 X-Authentication-Warning: enterprise.local.lan: torriem set sender to torriem@chem.byu.edu using -f Subject: Re: gtk file open dialog usability. From: Michael Torrie To: Gian Mario Tagliaretti In-Reply-To: <35bf41160606240652s3da0fe6brd3915cd84c601114@mail.gmail.com> References: <35bf41160606240652s3da0fe6brd3915cd84c601114@mail.gmail.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Sat, 24 Jun 2006 23:21:16 -0600 Message-Id: <1151212877.32440.24.camel@enterprise.local.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-7) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.378 tagged_above=-999 required=2 tests=[AWL=0.009, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, TW_GT=0.077] X-Spam-Score: -2.378 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jun 2006 05:21:50 -0000 On Sat, 2006-06-24 at 15:52 +0200, Gian Mario Tagliaretti wrote: > 2006/6/24, alex@halogen-dg.com : > > > > Anyone except me also disappointed by it? > > Any way how we can have old file open dialog back? > > code not complain :) BS. Before anyone can code anything, especially in the framework of GTK, the design has to be worked out. You can't just willy-nilly code up some pseudo-compatible widget. The problem is that every time this is discussed there is never any consensus on what the problems are, why they are problems, and how to fix them. And without this, we cannot convince developers to do anything about the problem. Now having said that, if someone wants to prototype a better widget (one that is API compatible with the current one), maybe that would jump- start the process. Myself, I fear that inertia guarantees we're stuck with this bad design for the duration. > > > I really find it very frustating and explained > > why, with some images here: > > http://www.halogen-dg.com/alex/file_selection_dialog/GtkFileOpenBadUsability > > are you using gtk+ 2.9.x ? > > ciao From dan@entropy.homelinux.org Mon Jun 26 21:13:46 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id D7F733B029A for ; Mon, 26 Jun 2006 21:13:46 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27746-05 for ; Mon, 26 Jun 2006 21:13:44 -0400 (EDT) Received: from screamer.nusconsulting.com.au (mail.nusconsulting.com.au [203.191.186.114]) by menubar.gnome.org (Postfix) with ESMTP id 5E0173B00FE for ; Mon, 26 Jun 2006 21:13:43 -0400 (EDT) Received: from [10.146.1.25] (dkasak.nusconsulting.com.au [10.146.1.25]) by screamer.nusconsulting.com.au (8.13.6/8.13.6) with ESMTP id k5R1FSwU022408 for ; Tue, 27 Jun 2006 11:15:28 +1000 Message-ID: <44A08654.1090208@entropy.homelinux.org> Date: Tue, 27 Jun 2006 11:13:56 +1000 From: Daniel Kasak User-Agent: Thunderbird 1.5.0.2 (X11/20060531) MIME-Version: 1.0 To: gtk-devel-list@gnome.org Subject: Custom Cell Renderers in a TreeView that requires scrolling broken in gtk+-2.8.18 and 2.8.19 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Canit-Stats-ID: 464197 - 7afdf0e072d5 X-Antispam-Training: Train as spam: http://screamer.nusconsulting.com.au/internal/canit/b.php?c=s&i=464197&m=7afdf0e072d5 X-Antispam-Training: Train as non-spam: http://screamer.nusconsulting.com.au/internal/canit/b.php?c=n&i=464197&m=7afdf0e072d5 X-Antispam-Training: Cancel training: http://screamer.nusconsulting.com.au/internal/canit/b.php?c=f&i=464197&m=7afdf0e072d5 X-Scanned-By: CanIt (www . roaringpenguin . com) on 10.146.0.254 X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.564 tagged_above=-999 required=2 tests=[AWL=0.035, BAYES_00=-2.599] X-Spam-Score: -2.564 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2006 01:13:47 -0000 Hi all. I've just noticed a very strange bug in my TreeViews since updating gtk. I have some apps that use a custom cell renderer to provide a pop-up GtkCalender. When I insert a row in the model, the custom cell renderer pops up ( begins editing ) as it's the 1st column. After I select a date and accept changes AND IF THERE ARE MORE ROWS THAN WILL FIT IN THE TREEVIEW WITHOUT SCROLLING, the new row DISAPPEARS from the TreeView. I scroll right from top to bottom - the new row certainly *looks* like it's gone. However if I insert *another* row, my previous missing row appears ( momentarily ) at the bottom again ... until I accept changes from the custom cell renderer on the newest row, and then they both ( or ALL, if I've inserted a number of rows ) disappear. For completeness ( partial anyway - it's a pretty complicated beast, but I can post an entire working example if required - please reply and request this if necessary, but note that it will be in Perl ), I'm pasting the entire CellRendererDate.pm module that provides the custom cell renderer at the bottom, however I note again that everything has worked properly for every version of gtk+ prior to 2.8.18. I initially updated from 2.8.17 to 2.8.19, and then when I found the bug, reverted to 2.8.17 ... tested some more ( no such bug here ), and then updated to 2.8.18 and did some more testing. It definitely arrived in 2.8.18. Has anyone noticed this behaviour with custom cell renderers? I have tested many other TreeViews that *don't* have a custom cell renderer, and have also tried moving the custom cell renderer to another position ( column ). I am almost positive that something is broken with displaying rows with a custom cell renderer when scrolling is required. I would greatly appreciate some help / suggests / confirmations / etc. Dan --- use strict; use Gtk2 -init; package Gtk2::Ex::Datasheet::DBI::CellRendererDate; use Glib::Object::Subclass "Gtk2::CellRenderer", signals => { edited => { flags => [qw(run-last)], param_types => [qw(Glib::String Glib::Scalar)], }, }, properties => [ Glib::ParamSpec -> boolean("editable", "Editable", "Can I change that?", 0, [qw(readable writable)]), Glib::ParamSpec -> string("date", "Date", "What's the date again?", "", [qw(readable writable)]), ] ; use constant x_padding => 2; use constant y_padding => 3; use constant arrow_width => 15; use constant arrow_height => 15; sub hide_popup { my ($cell) = @_; Gtk2 -> grab_remove($cell -> { _popup }); $cell -> { _popup } -> hide(); } sub get_today { my ($cell) = @_; my ($day, $month, $year) = (localtime())[3, 4, 5]; $year += 1900; $month += 1; return ($year, $month, $day); } sub get_date { my ($cell) = @_; my $text = $cell -> get("date"); my ($year, $month, $day) = $text ? split(/[\/-]/, $text) : $cell -> get_today(); return ($year, $month, $day); } sub add_padding { my ($cell, $year, $month, $day) = @_; return ($year, sprintf("%02d", $month), sprintf("%02d", $day)); } sub INIT_INSTANCE { my ($cell) = @_; my $popup = Gtk2::Window -> new ('popup'); my $vbox = Gtk2::VBox -> new(0, 0); my $calendar = Gtk2::Calendar -> new(); my $hbox = Gtk2::HBox -> new(0, 0); my $today = Gtk2::Button -> new('Today'); my $none = Gtk2::Button -> new('None'); $cell -> {_arrow} = Gtk2::Arrow -> new("down", "none"); # We can't just provide the callbacks now because they might need access to # cell-specific variables. And we can't just connect the signals in # START_EDITING because we'd be connecting many signal handlers to the same # widgets. $today -> signal_connect(clicked => sub { $cell -> { _today_clicked_callback } -> (@_) if (exists($cell -> { _today_clicked_callback })); }); $none -> signal_connect(clicked => sub { $cell -> { _none_clicked_callback } -> (@_) if (exists($cell -> { _none_clicked_callback })); }); $calendar -> signal_connect(day_selected_double_click => sub { $cell -> { _day_selected_double_click_callback } -> (@_) if (exists($cell -> { _day_selected_double_click_callback })); }); $calendar -> signal_connect(month_changed => sub { $cell -> { _month_changed } -> (@_) if (exists($cell -> { _month_changed })); }); $hbox -> pack_start($today, 1, 1, 0); $hbox -> pack_start($none, 1, 1, 0); $vbox -> pack_start($calendar, 1, 1, 0); $vbox -> pack_start($hbox, 0, 0, 0); # Find out if the click happended outside of our window. If so, hide it. # Largely copied from Planner (the former MrProject). # Implement via Gtk2::get_event_widget? $popup -> signal_connect(button_press_event => sub { my ($popup, $event) = @_; if ($event -> button() == 1) { my ($x, $y) = ($event -> x_root(), $event -> y_root()); my ($xoffset, $yoffset) = $popup -> window() -> get_root_origin(); my $allocation = $popup -> allocation(); my $x1 = $xoffset + 2 * $allocation -> x(); my $y1 = $yoffset + 2 * $allocation -> y(); my $x2 = $x1 + $allocation -> width(); my $y2 = $y1 + $allocation -> height(); unless ($x > $x1 && $x < $x2 && $y > $y1 && $y < $y2) { $cell -> hide_popup(); return 1; } } return 0; }); $popup -> add($vbox); $cell -> { _popup } = $popup; $cell -> { _calendar } = $calendar; } sub START_EDITING { my ($cell, $event, $view, $path, $background_area, $cell_area, $flags) = @_; my $popup = $cell -> { _popup }; my $calendar = $cell -> { _calendar }; # Specify the callbacks. Will be called by the signal handlers set up in # INIT_INSTANCE. $cell -> { _today_clicked_callback } = sub { my ($button) = @_; my ($year, $month, $day) = $cell -> get_today(); $cell -> signal_emit(edited => $path, join("-", $cell -> add_padding($year, $month, $day))); $cell -> hide_popup(); }; $cell -> { _none_clicked_callback } = sub { my ($button) = @_; $cell -> signal_emit(edited => $path, ""); $cell -> hide_popup(); }; $cell -> { _day_selected_double_click_callback } = sub { my ($calendar) = @_; my ($year, $month, $day) = $calendar -> get_date(); $cell -> signal_emit(edited => $path, join("-", $cell -> add_padding($year, ++$month, $day))); $cell -> hide_popup(); }; $cell -> { _month_changed } = sub { my ($calendar) = @_; my ($selected_year, $selected_month) = $calendar -> get_date(); my ($current_year, $current_month, $current_day) = $cell -> get_today(); if ($selected_year == $current_year && ++$selected_month == $current_month) { $calendar -> mark_day($current_day); } else { $calendar -> unmark_day($current_day); } }; my ($year, $month, $day) = $cell -> get_date(); $calendar -> select_month($month - 1, $year); $calendar -> select_day($day); # Necessary to get the correct allocation of the popup. $popup -> move(-500, -500); $popup -> show_all(); # Figure out where to put the popup - ie don't put it offscreen, # as it's not movable ( by the user ) my $screen_height = $popup->get_screen->get_height; my $requisition = $popup->size_request(); my $popup_width = $requisition->width; my $popup_height = $requisition->height; my ($x_origin, $y_origin) = $view -> get_bin_window() -> get_origin(); my ($popup_x, $popup_y); $popup_x = $x_origin + $cell_area->x() + $cell_area->width() - $popup_width; $popup_x = 0 if $popup_x < 0; $popup_y = $y_origin + $cell_area -> y() + $cell_area -> height(); if ( $popup_y + $popup_height > $screen_height ) { $popup_y = $y_origin + $cell_area -> y() - $popup_height; } $popup -> move( $popup_x, $popup_y ); # Grab the focus and the pointer. Gtk2 -> grab_add($popup); $popup -> grab_focus(); Gtk2::Gdk -> pointer_grab($popup -> window(), 1, [qw(button-press-mask button-release-mask pointer-motion-mask)], undef, undef, 0); return; } sub get_date_string { my $cell = shift; return $cell->get ('date'); } sub calc_size { my ($cell, $layout) = @_; my ($width, $height) = $layout -> get_pixel_size(); return (0, 0, $width + x_padding * 2 + arrow_width, $height + y_padding * 2); } sub GET_SIZE { my ($cell, $widget, $cell_area) = @_; my $layout = $cell -> get_layout($widget); $layout -> set_text( $cell -> get_date_string() || '' ); return $cell -> calc_size($layout); } sub get_layout { my ($cell, $widget) = @_; return $widget -> create_pango_layout(""); } sub RENDER { my ($cell, $window, $widget, $background_area, $cell_area, $expose_area, $flags) = @_; my $state; if ($flags & 'selected') { $state = $widget -> has_focus() ? 'selected' : 'active'; } else { $state = $widget -> state() eq 'insensitive' ? 'insensitive' : 'normal'; } my $layout = $cell -> get_layout($widget); $layout -> set_text( $cell -> get_date_string() || '' ); my ($x_offset, $y_offset, $width, $height) = $cell -> calc_size($layout); $widget -> get_style -> paint_layout($window, $state, 1, $cell_area, $widget, "cellrenderertext", $cell_area -> x() + $x_offset + x_padding, $cell_area -> y() + $y_offset + y_padding, $layout); $widget -> get_style -> paint_arrow ($window, $widget->state, 'none', $cell_area, $cell -> { _arrow }, "", "down", 1, $cell_area -> x + $cell_area -> width - arrow_width, $cell_area -> y + $cell_area -> height - arrow_height - 2, arrow_width - 3, arrow_height); } 1; From mail2karuna@hotmail.com Tue Jun 27 05:53:25 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 0ECA43B00E4 for ; Tue, 27 Jun 2006 05:53:25 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21270-07 for ; Tue, 27 Jun 2006 05:53:11 -0400 (EDT) Received: from hotmail.com (bay123-f24.bay123.hotmail.com [207.46.11.104]) by menubar.gnome.org (Postfix) with ESMTP id 2C7C03B0104 for ; Tue, 27 Jun 2006 05:53:11 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 27 Jun 2006 02:53:10 -0700 Message-ID: Received: from 207.46.11.123 by by123fd.bay123.hotmail.msn.com with HTTP; Tue, 27 Jun 2006 09:53:09 GMT X-Originating-IP: [62.193.236.100] X-Originating-Email: [mail2karuna@hotmail.com] X-Sender: mail2karuna@hotmail.com From: "karuna karan" To: gtk-devel-list@gnome.org Subject: Re: Failed building GTK with the DFB backend Date: Tue, 27 Jun 2006 09:53:09 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 27 Jun 2006 09:53:10.0427 (UTC) FILETIME=[7F932EB0:01C699CF] X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-0.958 tagged_above=-999 required=2 tests=[BAYES_05=-1.11, MSGID_FROM_MTA_HEADER=0, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, TW_BG=0.077, TW_GT=0.077] X-Spam-Score: -0.958 X-Spam-Level: Cc: skar@tataelxsi.co.in X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2006 09:53:25 -0000 Hi all, I tried to build gtk 2.9.1 with directFB backend with following dependencies, glib 2.11.1 atk 1.10.1 cairo 1.1.6 pango 1.13.1 directfb 0.9.25.1 while building gtk with, 1 ./configure --prefix=/opt/gtkdfb/ --without-x --with-gdktarget=directfb --enable-debug=no 2 make the buld fails and throws the error as, queryimmodules.c: In function `query_module': queryimmodules.c:116: warning: dereferencing type-punned pointer will break strict-aliasing rules queryimmodules.c:117: warning: dereferencing type-punned pointer will break strict-aliasing rules queryimmodules.c:118: warning: dereferencing type-punned pointer will break strict-aliasing rules queryimmodules.c:119: warning: dereferencing type-punned pointer will break strict-aliasing rules /bin/sh ../libtool --mode=link gcc -g -O2 -Wall -o gtk-query-immodules-2.0 queryimmodules.o libgtk-directfb-2.0.la .../gdk-pixbuf/libgdk_pixbuf-2.0.la ../gdk/libgdk-directfb-2.0.la gcc -g -O2 -Wall -o .libs/gtk-query-immodules-2.0 queryimmodules.o ../.libs/libgtk-directfb-2.0.so -L/opt/gtkdfb/lib /root/gtk+-2.9.1/gdk/.libs/libgdk-directfb-2.0.so /opt/gtkdfb/lib/libatk-1.0.so ../gdk-pixbuf/.libs/libgdk_pixbuf-2.0.so .../gdk/.libs/libgdk-directfb-2.0.so /opt/gtkdfb/lib/libpangocairo-1.0.so /opt/gtkdfb/lib/libpangoft2-1.0.so /opt/gtkdfb/lib/libpango-1.0.so /opt/gtkdfb/lib/libcairo.so -lpng12 /opt/gtkdfb/lib/libdirectfb.so /opt/gtkdfb/lib/libfusion.so /opt/gtkdfb/lib/libdirect.so -lfontconfig /usr/lib/libfreetype.so /usr/lib/libxml2.so -lpthread -lz /root/gtk+-2.9.1/gdk-pixbuf/.libs/libgdk_pixbuf-2.0.so /opt/gtkdfb/lib/libgmodule-2.0.so -ldl /opt/gtkdfb/lib/libgobject-2.0.so /opt/gtkdfb/lib/libglib-2.0.so -lm -Wl,--rpath -Wl,/opt/gtkdfb/lib ../.libs/libgtk-directfb-2.0.so: undefined reference to `gdk_screen_is_composited' /root/gtk+-2.9.1/gdk/.libs/libgdk-directfb-2.0.so: undefined reference to `IA__gdk_screen_is_composited' collect2: ld returned 1 exit status make[4]: *** [gtk-query-immodules-2.0] Error 1 make[4]: Leaving directory `/root/gtk+-2.9.1/gtk' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/root/gtk+-2.9.1/gtk' make[2]: *** [all] Error 2 make[2]: Leaving directory `/root/gtk+-2.9.1/gtk' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/root/gtk+-2.9.1' make: *** [all] Error 2 help me out in this.. Thanks, Karunakaran A. _________________________________________________________________ Dont just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/ From fiandro@tiscali.it Tue Jun 27 06:05:04 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C52653B0010 for ; Tue, 27 Jun 2006 06:05:04 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22230-02 for ; Tue, 27 Jun 2006 06:05:02 -0400 (EDT) Received: from polito.it (anacreon.polito.it [130.192.3.82]) by menubar.gnome.org (Postfix) with ESMTP id 1B1113B0088 for ; Tue, 27 Jun 2006 06:05:00 -0400 (EDT) X-ExtScanner: Niversoft's FindAttachments (free) Received: from [130.192.31.127] (HELO [130.192.31.127]) by anacreon.polito.it (CommuniGate Pro SMTP 5.0.9) with ESMTP id 39350329; Tue, 27 Jun 2006 12:04:58 +0200 Message-ID: <44A103E0.8000000@tiscali.it> Date: Tue, 27 Jun 2006 12:09:36 +0200 From: Attilio Fiandrotti User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.13) Gecko/20060620 Debian/1.7.13-0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: karuna karan Subject: Re: Failed building GTK with the DFB backend References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.224 tagged_above=-999 required=2 tests=[AWL=-0.337, BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2, FORGED_RCVD_HELO=0.135, SPF_NEUTRAL=1.069, TW_DF=0.077, TW_GT=0.077, TW_KD=0.077, TW_TK=0.077] X-Spam-Score: -1.224 X-Spam-Level: Cc: gtk-devel-list@gnome.org, skar@tataelxsi.co.in X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2006 10:05:05 -0000 karuna karan wrote: > Hi all, > > I tried to build gtk 2.9.1 with directFB backend with following > dependencies, DFB support in was broken: you should try 2.9.4 or follow instructions in the wiki page to build from sratch. If you're a debian user, you can also use precompiled i386 official packages that were built this week http://download.dajobe.org/debian/experimental/ <-cairodfb http://people.debian.org/~joss/packages/ <-gtkdfb Attilio From kris@babi-pangang.org Tue Jun 27 08:43:52 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 623A53B00AE for ; Tue, 27 Jun 2006 08:43:52 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29028-04 for ; Tue, 27 Jun 2006 08:43:48 -0400 (EDT) Received: from nasi-goreng.babi-pangang.org (nasi-goreng.babi-pangang.org [83.166.137.20]) by menubar.gnome.org (Postfix) with ESMTP id 5BA363B008D for ; Tue, 27 Jun 2006 08:43:48 -0400 (EDT) Received: by nasi-goreng.babi-pangang.org (Postfix, from userid 1000) id C52593DCA0; Tue, 27 Jun 2006 14:42:09 +0200 (CEST) Date: Tue, 27 Jun 2006 14:42:09 +0200 From: Kristian Rietveld To: gtk-devel-list@gnome.org Subject: Minutes of the GTK+ meeting at GUADEC Message-ID: <20060627124209.GA23474@babi-pangang.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.564 tagged_above=-999 required=2 tests=[AWL=0.035, BAYES_00=-2.599] X-Spam-Score: -2.564 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2006 12:43:52 -0000 Hey, We had a GTK+ meeting in person at GUADEC last Sunday. Below are the minutes (or really just the notes I took). -kris. ---- GTK+ Meeting, 25 June 2006, GUADEC7 ----------------------------------- * 2.10 is basically done, we are aiming for a release next week. * Tommi asks whether the GTK+ development/maintainer team is big enough. Matthias and Tim both answer that the team has been too small for the last few years, everybody else seems to agree. * Planning 2.12, possible new features: - Canvas, and we need off-screen rendering for that. # At least 3 different candidate canvases around. # Some ideas from Soeren; immediate mode, callbacks. He will write up his ideas and send it to the list for discussion. # Defining the feature set for a canvas is really difficult, though most people agreed that GnomeCanvas does cover most of the features needed by general applications. # Might want to look at the new canvas in Qt 4.1. - Introspection - GtkBuilder, the libglade integration into GTK+. - The new tooltips API. - Maemo.org patches # Menu patches, # Input method, # Tap and hold. - International calendar support # GLib patch is about ready, # After that the GTK+ widget (GtkCalendar) needs some fixing up. - Support for editable multi-line labels, probably by extending GtkEntry. - libsexy cherrypicking # Support having an icon in the entry. # Input masks. - Recent file code updates # GtkRecentAction. # GtkFileChooser integration. * Matthias continues on Tommi's previous question on maintenance, mentioning the OS X backend. Micke and Richard explain that the backend is mostly working, but does need some bug fixing. It's marked as still experimental. * The file chooser API does have some issues. For example the backend API is private, and getting the model from the file chooser dialog is impossible. Also the code for supporting the pluggability of the UI does not work/has not been tested at all. * We decided to target the GTK+ 2.12 release on January '07. This should give us enough time to put all new features in. If we decide to include a canvas with GTK+ 2.12, we might have to depend on a new release of Cairo. According to Carl Worth the next releases of Cairo are pretty much "open". They will probably focus on performance for the next release. Making a new release for supporting some special canvas features should be feasible. * We get interrupted by some guys of the board. Jeff speaks about having the GTK+ project join the GNOME foundation. The foundation can provide help to the GTK+ project with financial and administrative tasks. It has been doing this for the GIMP project already, which has been working fine so far. The foundation does not get any influence on the technical decisions made by the GTK+ team. Also, the plan is to get a press release out on this. * The board leaves and the core team pretty much decides that doing this is not bad at all, and the only thing that needs work is the wording in the press release. Nobody appears to be against. * The topic of GTK+ 3.0 was brought up after this. 3.0 would be an API and ABI breaking release. The team decided that we would like to avoid breaking API since a lot of companies invested into GTK+ 2.x and expect that it'll be supported for some more years. Most of the team seems to agree that we want to get rid of the cruft in the 2.x series, some of which is still sticking around from the 1.x series. Matthias mentions that FC6 will not ship with GTK+ 1.x. (People cheered and Tim complained about he won't be able to run xmms then). The idea of introducing compiling subsets was brought up. We could set up a make system where the full library or only a subset is built, for example omitting all the old stuff and the printing support. The people using GTK+ on embedded devices would be really happy if we implemented something like this. If we want the compiling subsets to work, we need to make sure that none of the internal code is using deprecated widgets. Breaking API is not really something we really want to do soon. If we ever do it, we want to do it right so it can last for at least a couple of years. Also, we would prefer the development on 3.0 to happen in parallel with 2.x development. Alex brought up the idea of creating a bug which we can use to track all issues which require breaking the API, so we get a formalized list of stuff which needs API breakage. According to Tim breaking the ABI is not a real problem, since distributions and also for example the Maemo.org platform can just be recompiled. * Tim also mentioned that Michael Meeks has been working on optimizing shared library loading optimization in OpenOffice.org. We wondered if there's anything we can do to improve GTK+'s performance in this area. As Michael was unable to attend Tim and/or Matthias will try to have a talk with Michael about this. As there was nothing left discuss, we decided to close the meeting. From skar@tataelxsi.co.in Tue Jun 27 07:22:44 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 665AF3B0072 for ; Tue, 27 Jun 2006 07:22:44 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25789-03 for ; Tue, 27 Jun 2006 07:22:43 -0400 (EDT) Received: from mail.tataelxsi.co.in (mail.tataelxsi.co.in [203.200.1.48]) by menubar.gnome.org (Postfix) with ESMTP id 1DFEF3B0011 for ; Tue, 27 Jun 2006 07:22:41 -0400 (EDT) Received: from skar (tataelxsi.co.in [203.197.169.80] (may be forged)) by mail.tataelxsi.co.in (MOS 3.7.4b-GA) with ESMTP id BRG33699 (AUTH skar); Tue, 27 Jun 2006 16:52:16 +0530 (IST) From: Suman Kar To: "'Attilio Fiandrotti'" , "'karuna karan'" Subject: RE: Failed building GTK with the DFB backend Date: Tue, 27 Jun 2006 16:51:13 +0530 Message-ID: <002301c699db$cd352ea0$381b320a@telxsi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal In-Reply-To: <44A103E0.8000000@tiscali.it> X-Junkmail: Blacklisted X-Mirapoint-Sig: mail.tataelxsi.co.in X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=0.386 tagged_above=-999 required=2 tests=[BAYES_50=0.001, TW_DF=0.077, TW_GD=0.077, TW_GT=0.077, TW_KD=0.077, TW_TK=0.077] X-Spam-Score: 0.386 X-Spam-Level: X-Mailman-Approved-At: Tue, 27 Jun 2006 10:07:05 -0400 Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: Suman Kar List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2006 11:22:44 -0000 Hello Attilio, Thanks for the quick update. However, the problem goes away when we added the following: gboolean gdk_screen_is_composited (GdkScreen *screen) { g_return_val_if_fail (GDK_IS_SCREEN (screen), NULL); return FALSE; } is added to gdkscreen-directfb.c (from http://mail.gnome.org/archives/gtk-devel-list/2006-May/msg00210.html ). We will definitely try building gtk+2.9.4 and will get back in case there are any issues. One more thing: we would be really interested in gtk+-2.10. Any idea when this will be out? Regards, Suman. -----Original Message----- From: Attilio Fiandrotti [mailto:fiandro@tiscali.it] Sent: Tuesday, June 27, 2006 3:40 PM To: karuna karan Cc: gtk-devel-list@gnome.org; skar@tataelxsi.co.in Subject: Re: Failed building GTK with the DFB backend karuna karan wrote: > Hi all, > > I tried to build gtk 2.9.1 with directFB backend with following > dependencies, DFB support in was broken: you should try 2.9.4 or follow instructions in the wiki page to build from sratch. If you're a debian user, you can also use precompiled i386 official packages that were built this week http://download.dajobe.org/debian/experimental/ <-cairodfb http://people.debian.org/~joss/packages/ <-gtkdfb Attilio The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s)and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender or administrator@tataelxsi.co.in From mail2karuna@hotmail.com Wed Jun 28 01:21:49 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 761EF3B002A for ; Wed, 28 Jun 2006 01:21:49 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27811-08 for ; Wed, 28 Jun 2006 01:21:48 -0400 (EDT) Received: from hotmail.com (bay123-f28.bay123.hotmail.com [207.46.11.108]) by menubar.gnome.org (Postfix) with ESMTP id 40EF13B000F for ; Wed, 28 Jun 2006 01:21:48 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 27 Jun 2006 22:19:26 -0700 Message-ID: Received: from 207.46.11.123 by by123fd.bay123.hotmail.msn.com with HTTP; Wed, 28 Jun 2006 05:19:23 GMT X-Originating-IP: [62.193.236.96] X-Originating-Email: [mail2karuna@hotmail.com] X-Sender: mail2karuna@hotmail.com In-Reply-To: <002301c699db$cd352ea0$381b320a@telxsi.com> From: "karuna karan" To: fiandro@tiscali.it, skar@tataelxsi.co.in, amirthakaruna@tataelxsi.co.in Subject: RE: Failed building GTK with the DFB backend Date: Wed, 28 Jun 2006 05:19:23 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 28 Jun 2006 05:19:26.0977 (UTC) FILETIME=[6CD95710:01C69A72] X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-0.502 tagged_above=-999 required=2 tests=[AWL=-1.829, BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2, DNS_FROM_RFC_POST=1.708, MSGID_FROM_MTA_HEADER=0, RCVD_IN_BL_SPAMCOP_NET=1.558, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, TW_DF=0.077, TW_DK=0.077, TW_GD=0.077, TW_GT=0.077, TW_KD=0.077, TW_TK=0.077] X-Spam-Score: -0.502 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2006 05:21:49 -0000 Hi, we have tried to build gtk+ 2.9.4 with backend dfb. we got the follwing error while building, gdkwindow-directfb.c: In function `gdk_directfb_create_child_window': gdkwindow-directfb.c:2508: error: structure has no member named `GetPosition' make[4]: *** [gdkwindow-directfb.lo] Error 1 make[4]: Leaving directory `/root/new/gtk+-2.9.4/gdk/directfb' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/root/new/gtk+-2.9.4/gdk' make[2]: *** [all] Error 2 make[2]: Leaving directory `/root/new/gtk+-2.9.4/gdk' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/root/new/gtk+-2.9.4' make: *** [all] Error 2 so kindly give feedback on this issue.. Thanks, Karunakaran A. >From: Suman Kar >Reply-To: Suman Kar >To: "'Attilio Fiandrotti'" , "'karuna karan'" > >CC: >Subject: RE: Failed building GTK with the DFB backend >Date: Tue, 27 Jun 2006 16:51:13 +0530 > >Hello Attilio, > >Thanks for the quick update. However, the problem goes away when we added >the following: > >gboolean >gdk_screen_is_composited (GdkScreen *screen) >{ > g_return_val_if_fail (GDK_IS_SCREEN (screen), NULL); > return FALSE; >} > > >is added to gdkscreen-directfb.c (from >http://mail.gnome.org/archives/gtk-devel-list/2006-May/msg00210.html ). > >We will definitely try building gtk+2.9.4 and will get back in case there >are any issues. > >One more thing: we would be really interested in gtk+-2.10. Any idea when >this will be out? > >Regards, >Suman. > >-----Original Message----- >From: Attilio Fiandrotti [mailto:fiandro@tiscali.it] >Sent: Tuesday, June 27, 2006 3:40 PM >To: karuna karan >Cc: gtk-devel-list@gnome.org; skar@tataelxsi.co.in >Subject: Re: Failed building GTK with the DFB backend > > >karuna karan wrote: > > Hi all, > > > > I tried to build gtk 2.9.1 with directFB backend with following > > dependencies, > >DFB support in was broken: you should try 2.9.4 or follow instructions >in the wiki page to build from sratch. >If you're a debian user, you can also use precompiled i386 official >packages that were built this week > >http://download.dajobe.org/debian/experimental/ <-cairodfb >http://people.debian.org/~joss/packages/ <-gtkdfb > >Attilio > >The information contained in this electronic message and any attachments to >this message are intended for the exclusive use of the addressee(s)and may >contain confidential or privileged information. If you are not the intended >recipient, please notify the sender or administrator@tataelxsi.co.in _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today - it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ From matthias.clasen@gmail.com Wed Jun 28 03:10:14 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 5BEF93B002C for ; Wed, 28 Jun 2006 03:10:14 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30060-02 for ; Wed, 28 Jun 2006 03:10:12 -0400 (EDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.183]) by menubar.gnome.org (Postfix) with ESMTP id 603903B009C for ; Wed, 28 Jun 2006 03:10:12 -0400 (EDT) Received: by py-out-1112.google.com with SMTP id c30so2171621pyc for ; Wed, 28 Jun 2006 00:09:17 -0700 (PDT) Received: by 10.35.83.6 with SMTP id k6mr338054pyl; Wed, 28 Jun 2006 00:09:17 -0700 (PDT) Received: by 10.35.39.16 with HTTP; Wed, 28 Jun 2006 00:09:17 -0700 (PDT) Message-ID: Date: Wed, 28 Jun 2006 03:09:17 -0400 From: "Matthias Clasen" To: "Suman Kar" Subject: Re: Failed building GTK with the DFB backend In-Reply-To: <002301c699db$cd352ea0$381b320a@telxsi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <44A103E0.8000000@tiscali.it> <002301c699db$cd352ea0$381b320a@telxsi.com> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.41 tagged_above=-999 required=2 tests=[AWL=-0.010, BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2, SPF_PASS=-0.001] X-Spam-Score: -2.41 X-Spam-Level: Cc: gtk-devel-list@gnome.org, karuna karan X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2006 07:10:14 -0000 On 6/27/06, Suman Kar wrote: > One more thing: we would be really interested in gtk+-2.10. Any idea when > this will be out? > I'll start working on the release when I'm back from Guadec next week. From fiandro@tiscali.it Wed Jun 28 03:57:13 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 3E6E73B0002 for ; Wed, 28 Jun 2006 03:57:13 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31177-01 for ; Wed, 28 Jun 2006 03:57:10 -0400 (EDT) Received: from aa003msr.fastwebnet.it (aa003msr.fastwebnet.it [85.18.95.66]) by menubar.gnome.org (Postfix) with ESMTP id 4417B3B0005 for ; Wed, 28 Jun 2006 03:57:10 -0400 (EDT) Received: from [192.168.2.2] (41.255.136.50) by aa003msr.fastwebnet.it (7.2.070.1) id 44965DC20058C56D; Wed, 28 Jun 2006 09:55:45 +0200 Message-ID: <44A23718.3020008@tiscali.it> Date: Wed, 28 Jun 2006 10:00:24 +0200 From: Attilio Fiandrotti User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.13) Gecko/20060620 Debian/1.7.13-0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: karuna karan Subject: Re: Failed building GTK with the DFB backend References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=1.347 tagged_above=-999 required=2 tests=[AWL=-0.215, BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2, RCVD_IN_WHOIS_BOGONS=2.43, SPF_NEUTRAL=1.069, TW_DF=0.077, TW_DK=0.077, TW_GD=0.077, TW_GT=0.077, TW_KD=0.077, TW_TK=0.077] X-Spam-Score: 1.347 X-Spam-Level: * Cc: gtk-devel-list@gnome.org, skar@tataelxsi.co.in, amirthakaruna@tataelxsi.co.in X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2006 07:57:13 -0000 A couple of days ago mike checked in the patch that excludes from compilation some extra code that requires DFB 0.9.25 in the case DFN 0.9.24 is used. Use CVS sources or apply to GTK 2.9.4 gdkdirectfb.h and gdkwindow-directfb.c from current SVN. If you're a Debian user and run on i386, simply install cairodfb and gtkdfb packages [1] which were made recently available (other archs will follow soon). Attilio [1] http://mail.directfb.org/pipermail/directfb-dev/2006-June/001973.html karuna karan wrote: > Hi, > > we have tried to build gtk+ 2.9.4 with backend dfb. > we got the follwing error while building, > > gdkwindow-directfb.c: In function `gdk_directfb_create_child_window': > gdkwindow-directfb.c:2508: error: structure has no member named > `GetPosition' > make[4]: *** [gdkwindow-directfb.lo] Error 1 > make[4]: Leaving directory `/root/new/gtk+-2.9.4/gdk/directfb' > make[3]: *** [all-recursive] Error 1 > make[3]: Leaving directory `/root/new/gtk+-2.9.4/gdk' > make[2]: *** [all] Error 2 > make[2]: Leaving directory `/root/new/gtk+-2.9.4/gdk' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/root/new/gtk+-2.9.4' > make: *** [all] Error 2 > > so kindly give feedback on this issue.. > > Thanks, > Karunakaran A. > > > > >> From: Suman Kar >> Reply-To: Suman Kar >> To: "'Attilio Fiandrotti'" , "'karuna >> karan'" >> CC: >> Subject: RE: Failed building GTK with the DFB backend >> Date: Tue, 27 Jun 2006 16:51:13 +0530 >> >> Hello Attilio, >> >> Thanks for the quick update. However, the problem goes away when we added >> the following: >> >> gboolean >> gdk_screen_is_composited (GdkScreen *screen) >> { >> g_return_val_if_fail (GDK_IS_SCREEN (screen), NULL); >> return FALSE; >> } >> >> >> is added to gdkscreen-directfb.c (from >> http://mail.gnome.org/archives/gtk-devel-list/2006-May/msg00210.html ). >> >> We will definitely try building gtk+2.9.4 and will get back in case there >> are any issues. >> >> One more thing: we would be really interested in gtk+-2.10. Any idea when >> this will be out? >> >> Regards, >> Suman. >> >> -----Original Message----- >> From: Attilio Fiandrotti [mailto:fiandro@tiscali.it] >> Sent: Tuesday, June 27, 2006 3:40 PM >> To: karuna karan >> Cc: gtk-devel-list@gnome.org; skar@tataelxsi.co.in >> Subject: Re: Failed building GTK with the DFB backend >> >> >> karuna karan wrote: >> > Hi all, >> > >> > I tried to build gtk 2.9.1 with directFB backend with following >> > dependencies, >> >> DFB support in was broken: you should try 2.9.4 or follow instructions >> in the wiki page to build from sratch. >> If you're a debian user, you can also use precompiled i386 official >> packages that were built this week >> >> http://download.dajobe.org/debian/experimental/ <-cairodfb >> http://people.debian.org/~joss/packages/ <-gtkdfb >> >> Attilio >> >> The information contained in this electronic message and any >> attachments to this message are intended for the exclusive use of the >> addressee(s)and may contain confidential or privileged information. If >> you are not the intended recipient, please notify the sender or >> administrator@tataelxsi.co.in > > > _________________________________________________________________ > Express yourself instantly with MSN Messenger! Download today - it's > FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ > > From mail2karuna@hotmail.com Wed Jun 28 04:51:51 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 8EFB63B0079 for ; Wed, 28 Jun 2006 04:51:51 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00776-08 for ; Wed, 28 Jun 2006 04:51:50 -0400 (EDT) Received: from hotmail.com (bay123-f31.bay123.hotmail.com [207.46.11.111]) by menubar.gnome.org (Postfix) with ESMTP id 2CB433B0005 for ; Wed, 28 Jun 2006 04:51:50 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 28 Jun 2006 01:50:10 -0700 Message-ID: Received: from 207.46.11.123 by by123fd.bay123.hotmail.msn.com with HTTP; Wed, 28 Jun 2006 08:50:07 GMT X-Originating-IP: [62.193.226.74] X-Originating-Email: [mail2karuna@hotmail.com] X-Sender: mail2karuna@hotmail.com In-Reply-To: <44A23718.3020008@tiscali.it> From: "karuna karan" To: fiandro@tiscali.it Subject: Re: Failed building GTK with the DFB backend Date: Wed, 28 Jun 2006 08:50:07 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 28 Jun 2006 08:50:10.0376 (UTC) FILETIME=[DCE6EC80:01C69A8F] X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=1.17 tagged_above=-999 required=2 tests=[AWL=-3.240, BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2, DNS_FROM_RFC_POST=1.708, MSGID_FROM_MTA_HEADER=0, RCVD_IN_BL_SPAMCOP_NET=1.558, RCVD_IN_SBL=3.16, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, TW_DF=0.077, TW_GD=0.077, TW_GT=0.077, TW_KD=0.077, TW_TK=0.077] X-Spam-Score: 1.17 X-Spam-Level: * Cc: gtk-devel-list@gnome.org, skar@tataelxsi.co.in, amirthakaruna@tataelxsi.co.in X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2006 08:51:51 -0000 hi, we are already working with DirectFB 0.9.25.1 and GTK 2.9.4(released) we will start work with GTK 2.9.4 from CVS as suggested by you. we will get back if any issue arises. Thanks, Karunakaran A. >From: Attilio Fiandrotti >A couple of days ago mike checked in the patch that excludes from >compilation some extra code that requires DFB 0.9.25 in the case DFN 0.9.24 >is used. >Use CVS sources or apply to GTK 2.9.4 gdkdirectfb.h and >gdkwindow-directfb.c from current SVN. >If you're a Debian user and run on i386, simply install cairodfb and gtkdfb >packages [1] which were made recently available (other archs will follow >soon). > >Attilio > >[1] http://mail.directfb.org/pipermail/directfb-dev/2006-June/001973.html > >karuna karan wrote: >>Hi, >> >>we have tried to build gtk+ 2.9.4 with backend dfb. >>we got the follwing error while building, >> >>gdkwindow-directfb.c: In function `gdk_directfb_create_child_window': >>gdkwindow-directfb.c:2508: error: structure has no member named >>`GetPosition' >>make[4]: *** [gdkwindow-directfb.lo] Error 1 >>make[4]: Leaving directory `/root/new/gtk+-2.9.4/gdk/directfb' >>make[3]: *** [all-recursive] Error 1 >>make[3]: Leaving directory `/root/new/gtk+-2.9.4/gdk' >>make[2]: *** [all] Error 2 >>make[2]: Leaving directory `/root/new/gtk+-2.9.4/gdk' >>make[1]: *** [all-recursive] Error 1 >>make[1]: Leaving directory `/root/new/gtk+-2.9.4' >>make: *** [all] Error 2 >> >>so kindly give feedback on this issue.. >> >>Thanks, >>Karunakaran A. >> >> >> >> >>>From: Suman Kar >>>Reply-To: Suman Kar >>>To: "'Attilio Fiandrotti'" , "'karuna karan'" >>> >>>CC: >>>Subject: RE: Failed building GTK with the DFB backend >>>Date: Tue, 27 Jun 2006 16:51:13 +0530 >>> >>>Hello Attilio, >>> >>>Thanks for the quick update. However, the problem goes away when we added >>>the following: >>> >>>gboolean >>>gdk_screen_is_composited (GdkScreen *screen) >>>{ >>> g_return_val_if_fail (GDK_IS_SCREEN (screen), NULL); >>> return FALSE; >>>} >>> >>> >>>is added to gdkscreen-directfb.c (from >>>http://mail.gnome.org/archives/gtk-devel-list/2006-May/msg00210.html ). >>> >>>We will definitely try building gtk+2.9.4 and will get back in case there >>>are any issues. >>> >>>One more thing: we would be really interested in gtk+-2.10. Any idea when >>>this will be out? >>> >>>Regards, >>>Suman. >>> >>>-----Original Message----- >>>From: Attilio Fiandrotti [mailto:fiandro@tiscali.it] >>>Sent: Tuesday, June 27, 2006 3:40 PM >>>To: karuna karan >>>Cc: gtk-devel-list@gnome.org; skar@tataelxsi.co.in >>>Subject: Re: Failed building GTK with the DFB backend >>> >>> >>>karuna karan wrote: >>> > Hi all, >>> > >>> > I tried to build gtk 2.9.1 with directFB backend with following >>> > dependencies, >>> >>>DFB support in was broken: you should try 2.9.4 or follow instructions >>>in the wiki page to build from sratch. >>>If you're a debian user, you can also use precompiled i386 official >>>packages that were built this week >>> >>>http://download.dajobe.org/debian/experimental/ <-cairodfb >>>http://people.debian.org/~joss/packages/ <-gtkdfb >>> >>>Attilio >>> >>>The information contained in this electronic message and any attachments >>>to this message are intended for the exclusive use of the addressee(s)and >>>may contain confidential or privileged information. If you are not the >>>intended recipient, please notify the sender or >>>administrator@tataelxsi.co.in >> >> >>_________________________________________________________________ >>Express yourself instantly with MSN Messenger! Download today - it's FREE! >>http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ >> >> > _________________________________________________________________ Dont just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/ From mail2karuna@hotmail.com Wed Jun 28 04:57:44 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id EB6A23B00A2 for ; Wed, 28 Jun 2006 04:57:43 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01098-06 for ; Wed, 28 Jun 2006 04:57:42 -0400 (EDT) Received: from bay0-omc3-s25.bay0.hotmail.com (bay0-omc3-s25.bay0.hotmail.com [65.54.246.225]) by menubar.gnome.org (Postfix) with ESMTP id 8E64F3B0002 for ; Wed, 28 Jun 2006 04:57:42 -0400 (EDT) Received: from hotmail.com ([207.46.11.110]) by bay0-omc3-s25.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Jun 2006 01:57:15 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 28 Jun 2006 01:57:15 -0700 Message-ID: Received: from 207.46.11.123 by by123fd.bay123.hotmail.msn.com with HTTP; Wed, 28 Jun 2006 08:57:12 GMT X-Originating-IP: [62.193.235.46] X-Originating-Email: [mail2karuna@hotmail.com] X-Sender: mail2karuna@hotmail.com In-Reply-To: <006101c69a90$871e5d00$361b320a@telxsi.com> From: "karuna karan" To: gtk-devel-list@gnome.org Subject: RE: Failed building GTK with the DFB backend Date: Wed, 28 Jun 2006 08:57:12 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 28 Jun 2006 08:57:15.0331 (UTC) FILETIME=[DA31E930:01C69A90] X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-0.194 tagged_above=-999 required=2 tests=[AWL=-1.445, BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2, DNS_FROM_RFC_POST=1.708, MSGID_FROM_MTA_HEADER=0, RCVD_IN_BL_SPAMCOP_NET=1.558, SPF_PASS=-0.001, TW_DF=0.077, TW_GD=0.077, TW_GT=0.077, TW_KD=0.077, TW_TK=0.077] X-Spam-Score: -0.194 X-Spam-Level: Cc: amirthakaruna@tataelxsi.co.in, skar@tataelxsi.co.in X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2006 08:57:44 -0000 hi, we are already working with DirectFB 0.9.25.1 and GTK 2.9.4(released) we will start work with GTK 2.9.4 from CVS as suggested by you. we will get back if any issue arises. Thanks, Karunakaran A. >From: Attilio Fiandrotti >A couple of days ago mike checked in the patch that excludes from >compilation some extra code that requires DFB 0.9.25 in the case DFN 0.9.24 >is used. >Use CVS sources or apply to GTK 2.9.4 gdkdirectfb.h and >gdkwindow-directfb.c from current SVN. >If you're a Debian user and run on i386, simply install cairodfb and gtkdfb >packages [1] which were made recently available (other archs will follow >soon). > >Attilio > >[1] http://mail.directfb.org/pipermail/directfb-dev/2006-June/001973.html > >karuna karan wrote: >>Hi, >> >>we have tried to build gtk+ 2.9.4 with backend dfb. >>we got the follwing error while building, >> >>gdkwindow-directfb.c: In function `gdk_directfb_create_child_window': >>gdkwindow-directfb.c:2508: error: structure has no member named >>`GetPosition' >>make[4]: *** [gdkwindow-directfb.lo] Error 1 >>make[4]: Leaving directory `/root/new/gtk+-2.9.4/gdk/directfb' >>make[3]: *** [all-recursive] Error 1 >>make[3]: Leaving directory `/root/new/gtk+-2.9.4/gdk' >>make[2]: *** [all] Error 2 >>make[2]: Leaving directory `/root/new/gtk+-2.9.4/gdk' >>make[1]: *** [all-recursive] Error 1 >>make[1]: Leaving directory `/root/new/gtk+-2.9.4' >>make: *** [all] Error 2 >> >>so kindly give feedback on this issue.. >> >>Thanks, >>Karunakaran A. >> >> >> >> >>>From: Suman Kar >>>Reply-To: Suman Kar >>>To: "'Attilio Fiandrotti'" , "'karuna karan'" >>> >>>CC: >>>Subject: RE: Failed building GTK with the DFB backend >>>Date: Tue, 27 Jun 2006 16:51:13 +0530 >>> >>>Hello Attilio, >>> >>>Thanks for the quick update. However, the problem goes away when we added >>>the following: >>> >>>gboolean >>>gdk_screen_is_composited (GdkScreen *screen) >>>{ >>> g_return_val_if_fail (GDK_IS_SCREEN (screen), NULL); >>> return FALSE; >>>} >>> >>> >>>is added to gdkscreen-directfb.c (from >>>http://mail.gnome.org/archives/gtk-devel-list/2006-May/msg00210.html ). >>> >>>We will definitely try building gtk+2.9.4 and will get back in case there > >>>are any issues. > >>> > >>>One more thing: we would be really interested in gtk+-2.10. Any idea >when > >>>this will be out? > >>> > >>>Regards, > >>>Suman. > >>> > >>>-----Original Message----- > >>>From: Attilio Fiandrotti [mailto:fiandro@tiscali.it] > >>>Sent: Tuesday, June 27, 2006 3:40 PM > >>>To: karuna karan > >>>Cc: gtk-devel-list@gnome.org; skar@tataelxsi.co.in > >>>Subject: Re: Failed building GTK with the DFB backend > >>> > >>> > >>>karuna karan wrote: > >>> > Hi all, > >>> > > >>> > I tried to build gtk 2.9.1 with directFB backend with following > >>> > dependencies, > >>> > >>>DFB support in was broken: you should try 2.9.4 or follow instructions > >>>in the wiki page to build from sratch. > >>>If you're a debian user, you can also use precompiled i386 official > >>>packages that were built this week > >>> > >>>http://download.dajobe.org/debian/experimental/ <-cairodfb > >>>http://people.debian.org/~joss/packages/ <-gtkdfb > >>> > >>>Attilio > >>> > >>>The information contained in this electronic message and any >attachments > >>>to this message are intended for the exclusive use of the >addressee(s)and > >>>may contain confidential or privileged information. If you are not the > >>>intended recipient, please notify the sender or > >>>administrator@tataelxsi.co.in > >> > >> > >>_________________________________________________________________ > >>Express yourself instantly with MSN Messenger! Download today - it's >FREE! > >>http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ > >> > >> > > > >_________________________________________________________________ >Dont just search. Find. Check out the new MSN Search! >http://search.msn.click-url.com/go/onm00200636ave/direct/01/ > >The information contained in this electronic message and any attachments to >this message are intended for the exclusive use of the addressee(s)and may >contain confidential or privileged information. If you are not the intended >recipient, please notify the sender or administrator@tataelxsi.co.in _________________________________________________________________ Dont just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/ From dave.foster@gmail.com Tue Jun 27 23:09:46 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id A42223B0010 for ; Tue, 27 Jun 2006 23:09:46 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25505-01 for ; Tue, 27 Jun 2006 23:09:45 -0400 (EDT) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.225]) by menubar.gnome.org (Postfix) with ESMTP id CEB183B0005 for ; Tue, 27 Jun 2006 23:09:44 -0400 (EDT) Received: by wr-out-0506.google.com with SMTP id i4so303425wra for ; Tue, 27 Jun 2006 20:08:24 -0700 (PDT) Received: by 10.54.80.7 with SMTP id d7mr394957wrb; Tue, 27 Jun 2006 20:08:24 -0700 (PDT) Received: from ?192.168.1.107? ( [68.0.246.8]) by mx.gmail.com with ESMTP id 64sm2194346wra.2006.06.27.20.08.24; Tue, 27 Jun 2006 20:08:24 -0700 (PDT) Subject: gdk_display_close segfault? From: Dave Foster To: gtk-devel-list@gnome.org Content-Type: text/plain Date: Wed, 28 Jun 2006 01:01:55 -0400 Message-Id: <1151470915.4791.3.camel@neptune.minuslab.net> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.6 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.6 X-Spam-Level: X-Mailman-Approved-At: Wed, 28 Jun 2006 07:11:10 -0400 X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2006 03:09:46 -0000 Hi, I've been trying to write a small section of code in my program which makes a second connection to the X display, using gtkmm.. I kept having problems, after rewriting it about 5 or 6 times, I tried writing it in straight gdk, and STILL got the problems. I seem to get a segfault whenever I call gdk_display_close(). Here is a rediculously simple example that gives the problem: Glib::ustring disp = ":0.0"; GdkDisplay* gdisp = gdk_display_open(disp.c_str()); if (!gdisp) ... gdk_display_close(gdisp); /* Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1224202560 (LWP 5689)] 0xb7b413d0 in gdk_display_x11_dispose () from /usr/lib/libgdk-x11-2.0.so.0 (gdb) bt #0 0xb7b413d0 in gdk_display_x11_dispose () from /usr/lib/libgdk-x11-2.0.so.0 #1 0xb7a11f2b in g_object_unref () from /usr/lib/libgobject-2.0.so.0 #2 0xb7b20c04 in gdk_display_close () from /usr/lib/libgdk-x11-2.0.so.0 #3 0x080571d5 in SetBG::set_bg (disp=@0xbfe1b2b0, file=@0xbfe1b2ac, mode=SetBG::SET_SCALE, bgcolor=@0xbfe1b2a8) at SetBG.cc:67 ... */ The display is opening fine. I'm running: gtk: 2.8.17-1 glib: 2.10.2-1 (hmm, didn't notice that before,t he 2.8 vs 2.10 thing, could that be it?) Anyway, I've spent all night trying to debug this and weeks trying to sort this problem out in my program. What is up with this, what can I do? thanks all. dave From fiandro@tiscali.it Wed Jun 28 07:47:12 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id EF7893B0087 for ; Wed, 28 Jun 2006 07:47:11 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08611-03 for ; Wed, 28 Jun 2006 07:47:10 -0400 (EDT) Received: from polito.it (anacreon.polito.it [130.192.3.82]) by menubar.gnome.org (Postfix) with ESMTP id AEB163B00A0 for ; Wed, 28 Jun 2006 07:47:09 -0400 (EDT) X-ExtScanner: Niversoft's FindAttachments (free) Received: from [130.192.31.127] (HELO [130.192.31.127]) by anacreon.polito.it (CommuniGate Pro SMTP 5.0.9) with ESMTP id 39386694; Wed, 28 Jun 2006 13:46:14 +0200 Message-ID: <44A26D1D.9090905@tiscali.it> Date: Wed, 28 Jun 2006 13:50:53 +0200 From: Attilio Fiandrotti User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.13) Gecko/20060620 Debian/1.7.13-0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Suman Kar Subject: Re: Failed building GTK with the DFB backend References: <000101c69aa6$6547c9d0$381b320a@telxsi.com> In-Reply-To: <000101c69aa6$6547c9d0$381b320a@telxsi.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.35 tagged_above=-999 required=2 tests=[AWL=-0.540, BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2, FORGED_RCVD_HELO=0.135, SPF_NEUTRAL=1.069, TW_DF=0.077, TW_GD=0.077, TW_GT=0.077, TW_KD=0.077, TW_TK=0.077] X-Spam-Score: -1.35 X-Spam-Level: Cc: gtk-devel-list@gnome.org, amirthakaruna@tataelxsi.co.in X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2006 11:47:12 -0000 I apologize for my mistake: only now i realize taht getposition() and getsize() were introduced *after* DFB 0.9.25 was released! Yesterday mike checked in a patch ("Added ifdef to compile with 0.9.24 removes creating a child GdkWindow since it u...") that allows GTK+ to be compiled against DFB >= 0.9.24 (so, also 0.9.25 will do) The correct recipe is: DFB >= 0.9.24 GTK+ HEAD from CVS Attilio Suman Kar wrote: > Hello Attilio, > > Let me try to explain Karuna's problem: we are using the > downloadable source tarball from > http://directfb.org/index.php?path=Main%2FDownloads: > DirectFB-0.9.25.1.tar.gz > > Also, this was released on 03-May-2006. Mike's checkin has happened > on 11-June-2006. Moreover, we could not find the GetPosition() > member in either the http://directfb.org/index.php?path=Main%2FNews > page or in the source files Mike has mentioned in the mail to > the directFB list. > > These indicates to me that this is not really an issue with some path > variable as you suggested. Your inputs are awaited. > > Regards, > Suman. > > -----Original Message----- > From: Attilio Fiandrotti [mailto:fiandro@tiscali.it] > Sent: Wednesday, June 28, 2006 3:03 PM > To: karuna karan > Cc: skar@tataelxsi.co.in; amirthakaruna@tataelxsi.co.in > Subject: Re: Failed building GTK with the DFB backend > > > the symbol GetPosition (and getsize, too) were introduced in DFB 0.9.25 > : if you're trying to compile GTKDFB against DFB 0.9.25, then you must > have provided wrong pkg_config_path or ld_library_path > > Attilio > > karuna karan wrote: > >>hi, >> >>we are already working with DirectFB 0.9.25.1 and GTK 2.9.4(released) >> >>we will start work with GTK 2.9.4 from CVS as suggested by you. >> >>we will get back if any issue arises. >> >>Thanks, >>Karunakaran A. >> >> >> >> >From: Attilio Fiandrotti >> >> >A couple of days ago mike checked in the patch that excludes from >> >compilation some extra code that requires DFB 0.9.25 in the case DFN >>0.9.24 >> >is used. >> >Use CVS sources or apply to GTK 2.9.4 gdkdirectfb.h and >> >gdkwindow-directfb.c from current SVN. >> >If you're a Debian user and run on i386, simply install cairodfb and >>gtkdfb >> >packages [1] which were made recently available (other archs will follow >> >soon). >> > >> >Attilio >> > >> >[1] > > http://mail.directfb.org/pipermail/directfb-dev/2006-June/001973.html > >> > >> >karuna karan wrote: >> >>Hi, >> >> >> >>we have tried to build gtk+ 2.9.4 with backend dfb. >> >>we got the follwing error while building, >> >> >> >>gdkwindow-directfb.c: In function `gdk_directfb_create_child_window': >> >>gdkwindow-directfb.c:2508: error: structure has no member named >> >>`GetPosition' >> >>make[4]: *** [gdkwindow-directfb.lo] Error 1 >> >>make[4]: Leaving directory `/root/new/gtk+-2.9.4/gdk/directfb' >> >>make[3]: *** [all-recursive] Error 1 >> >>make[3]: Leaving directory `/root/new/gtk+-2.9.4/gdk' >> >>make[2]: *** [all] Error 2 >> >>make[2]: Leaving directory `/root/new/gtk+-2.9.4/gdk' >> >>make[1]: *** [all-recursive] Error 1 >> >>make[1]: Leaving directory `/root/new/gtk+-2.9.4' >> >>make: *** [all] Error 2 >> >> >> >>so kindly give feedback on this issue.. >> >> >> >>Thanks, >> >>Karunakaran A. >> >> >> >> >> >> >> >> >> >>>From: Suman Kar >> >>>Reply-To: Suman Kar >> >>>To: "'Attilio Fiandrotti'" , "'karuna >>karan'" >> >>> >> >>>CC: >> >>>Subject: RE: Failed building GTK with the DFB backend >> >>>Date: Tue, 27 Jun 2006 16:51:13 +0530 >> >>> >> >>>Hello Attilio, >> >>> >> >>>Thanks for the quick update. However, the problem goes away when we >>added >> >>>the following: >> >>> >> >>>gboolean >> >>>gdk_screen_is_composited (GdkScreen *screen) >> >>>{ >> >>> g_return_val_if_fail (GDK_IS_SCREEN (screen), NULL); >> >>> return FALSE; >> >>>} >> >>> >> >>> >> >>>is added to gdkscreen-directfb.c (from >> >> >>>>>http://mail.gnome.org/archives/gtk-devel-list/2006-May/msg00210.html ). >> >> >>> >> >>>We will definitely try building gtk+2.9.4 and will get back in case >>there >> >> >>>>>>are any issues. >>>>>> >>>>>>One more thing: we would be really interested in gtk+-2.10. Any >>> >>>idea when >>> >>>>>>this will be out? >>>>>> >>>>>>Regards, >>>>>>Suman. >>>>>> >>>>>>-----Original Message----- >>>>>>From: Attilio Fiandrotti [mailto:fiandro@tiscali.it] >>>>>>Sent: Tuesday, June 27, 2006 3:40 PM >>>>>>To: karuna karan >>>>>>Cc: gtk-devel-list@gnome.org; skar@tataelxsi.co.in >>>>>>Subject: Re: Failed building GTK with the DFB backend >>>>>> >>>>>> >>>>>>karuna karan wrote: >>>>>> >>>>>>>Hi all, >>>>>>> >>>>>>>I tried to build gtk 2.9.1 with directFB backend with following >>>>>>>dependencies, >>>>>> >>>>>>DFB support in was broken: you should try 2.9.4 or follow instructions >>>>>>in the wiki page to build from sratch. >>>>>>If you're a debian user, you can also use precompiled i386 official >>>>>>packages that were built this week >>>>>> >>>>>>http://download.dajobe.org/debian/experimental/ <-cairodfb >>>>>>http://people.debian.org/~joss/packages/ <-gtkdfb >>>>>> >>>>>>Attilio >>>>>> >>>>>>The information contained in this electronic message and any >>> >>>attachments >>> >>>>>>to this message are intended for the exclusive use of the >>> >>>addressee(s)and >>> >>>>>>may contain confidential or privileged information. If you are not the >>>>>>intended recipient, please notify the sender or >>>>>>administrator@tataelxsi.co.in >>>>> >>>>> >>>>>_________________________________________________________________ >>>>>Express yourself instantly with MSN Messenger! Download today - it's >>> >>>FREE! >>> >>>>>http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ >>>>> >>>>> >>>> >>>_________________________________________________________________ >>>Dont just search. Find. Check out the new MSN Search! >>>http://search.msn.click-url.com/go/onm00200636ave/direct/01/ >>> >>>The information contained in this electronic message and any >>>attachments to this message are intended for the exclusive use of the >>>addressee(s)and may contain confidential or privileged information. If >>>you are not the intended recipient, please notify the sender or >>>administrator@tataelxsi.co.in >> >> >>_________________________________________________________________ >>Dont just search. Find. Check out the new MSN Search! >>http://search.msn.click-url.com/go/onm00200636ave/direct/01/ >> >> >> >> >>------------------------------------------------------------------------ >> >>The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s)and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender or administrator@tataelxsi.co.in From skar@tataelxsi.co.in Wed Jun 28 07:31:56 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id B3F193B006C for ; Wed, 28 Jun 2006 07:31:56 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07955-07 for ; Wed, 28 Jun 2006 07:31:55 -0400 (EDT) Received: from mail.tataelxsi.co.in (mail.tataelxsi.co.in [203.200.1.48]) by menubar.gnome.org (Postfix) with ESMTP id 0CA9D3B00F3 for ; Wed, 28 Jun 2006 07:31:53 -0400 (EDT) Received: from skar (tataelxsi.co.in [203.197.169.80] (may be forged)) by mail.tataelxsi.co.in (MOS 3.7.4b-GA) with ESMTP id BRJ72122 (AUTH skar); Wed, 28 Jun 2006 17:02:27 +0530 (IST) From: Suman Kar To: "'Attilio Fiandrotti'" , Subject: RE: Failed building GTK with the DFB backend Date: Wed, 28 Jun 2006 17:01:26 +0530 Message-ID: <000101c69aa6$6547c9d0$381b320a@telxsi.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <44A24CDC.4070707@tiscali.it> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Junkmail: Blacklisted Content-Type: multipart/mixed; boundary="MIRAPOINT_PART1_44a268cc" X-Mirapoint-Sig: mail.tataelxsi.co.in X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.291 tagged_above=-999 required=2 tests=[AWL=-0.635, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.558, TW_DF=0.077, TW_GD=0.077, TW_GT=0.077, TW_KD=0.077, TW_TK=0.077] X-Spam-Score: -1.291 X-Spam-Level: X-Mailman-Approved-At: Wed, 28 Jun 2006 08:28:51 -0400 Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: Suman Kar List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2006 11:31:56 -0000 --MIRAPOINT_PART1_44a268cc Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 8bit Hello Attilio, Let me try to explain Karuna's problem: we are using the downloadable source tarball from http://directfb.org/index.php?path=Main%2FDownloads: DirectFB-0.9.25.1.tar.gz Also, this was released on 03-May-2006. Mike's checkin has happened on 11-June-2006. Moreover, we could not find the GetPosition() member in either the http://directfb.org/index.php?path=Main%2FNews page or in the source files Mike has mentioned in the mail to the directFB list. These indicates to me that this is not really an issue with some path variable as you suggested. Your inputs are awaited. Regards, Suman. -----Original Message----- From: Attilio Fiandrotti [mailto:fiandro@tiscali.it] Sent: Wednesday, June 28, 2006 3:03 PM To: karuna karan Cc: skar@tataelxsi.co.in; amirthakaruna@tataelxsi.co.in Subject: Re: Failed building GTK with the DFB backend the symbol GetPosition (and getsize, too) were introduced in DFB 0.9.25 : if you're trying to compile GTKDFB against DFB 0.9.25, then you must have provided wrong pkg_config_path or ld_library_path Attilio karuna karan wrote: > hi, > > we are already working with DirectFB 0.9.25.1 and GTK 2.9.4(released) > > we will start work with GTK 2.9.4 from CVS as suggested by you. > > we will get back if any issue arises. > > Thanks, > Karunakaran A. > > > > >From: Attilio Fiandrotti > > >A couple of days ago mike checked in the patch that excludes from > >compilation some extra code that requires DFB 0.9.25 in the case DFN > 0.9.24 > >is used. > >Use CVS sources or apply to GTK 2.9.4 gdkdirectfb.h and > >gdkwindow-directfb.c from current SVN. > >If you're a Debian user and run on i386, simply install cairodfb and > gtkdfb > >packages [1] which were made recently available (other archs will follow > >soon). > > > >Attilio > > > >[1] http://mail.directfb.org/pipermail/directfb-dev/2006-June/001973.html > > > >karuna karan wrote: > >>Hi, > >> > >>we have tried to build gtk+ 2.9.4 with backend dfb. > >>we got the follwing error while building, > >> > >>gdkwindow-directfb.c: In function `gdk_directfb_create_child_window': > >>gdkwindow-directfb.c:2508: error: structure has no member named > >>`GetPosition' > >>make[4]: *** [gdkwindow-directfb.lo] Error 1 > >>make[4]: Leaving directory `/root/new/gtk+-2.9.4/gdk/directfb' > >>make[3]: *** [all-recursive] Error 1 > >>make[3]: Leaving directory `/root/new/gtk+-2.9.4/gdk' > >>make[2]: *** [all] Error 2 > >>make[2]: Leaving directory `/root/new/gtk+-2.9.4/gdk' > >>make[1]: *** [all-recursive] Error 1 > >>make[1]: Leaving directory `/root/new/gtk+-2.9.4' > >>make: *** [all] Error 2 > >> > >>so kindly give feedback on this issue.. > >> > >>Thanks, > >>Karunakaran A. > >> > >> > >> > >> > >>>From: Suman Kar > >>>Reply-To: Suman Kar > >>>To: "'Attilio Fiandrotti'" , "'karuna > karan'" > >>> > >>>CC: > >>>Subject: RE: Failed building GTK with the DFB backend > >>>Date: Tue, 27 Jun 2006 16:51:13 +0530 > >>> > >>>Hello Attilio, > >>> > >>>Thanks for the quick update. However, the problem goes away when we > added > >>>the following: > >>> > >>>gboolean > >>>gdk_screen_is_composited (GdkScreen *screen) > >>>{ > >>> g_return_val_if_fail (GDK_IS_SCREEN (screen), NULL); > >>> return FALSE; > >>>} > >>> > >>> > >>>is added to gdkscreen-directfb.c (from > >>>> http://mail.gnome.org/archives/gtk-devel-list/2006-May/msg00210.html ). > > >>> > >>>We will definitely try building gtk+2.9.4 and will get back in case > there > >> >>>are any issues. >> >>> >> >>>One more thing: we would be really interested in gtk+-2.10. Any >> idea when >> >>>this will be out? >> >>> >> >>>Regards, >> >>>Suman. >> >>> >> >>>-----Original Message----- >> >>>From: Attilio Fiandrotti [mailto:fiandro@tiscali.it] >> >>>Sent: Tuesday, June 27, 2006 3:40 PM >> >>>To: karuna karan >> >>>Cc: gtk-devel-list@gnome.org; skar@tataelxsi.co.in >> >>>Subject: Re: Failed building GTK with the DFB backend >> >>> >> >>> >> >>>karuna karan wrote: >> >>> > Hi all, >> >>> > >> >>> > I tried to build gtk 2.9.1 with directFB backend with following >> >>> > dependencies, >> >>> >> >>>DFB support in was broken: you should try 2.9.4 or follow instructions >> >>>in the wiki page to build from sratch. >> >>>If you're a debian user, you can also use precompiled i386 official >> >>>packages that were built this week >> >>> >> >>>http://download.dajobe.org/debian/experimental/ <-cairodfb >> >>>http://people.debian.org/~joss/packages/ <-gtkdfb >> >>> >> >>>Attilio >> >>> >> >>>The information contained in this electronic message and any >> attachments >> >>>to this message are intended for the exclusive use of the >> addressee(s)and >> >>>may contain confidential or privileged information. If you are not the >> >>>intended recipient, please notify the sender or >> >>>administrator@tataelxsi.co.in >> >> >> >> >> >>_________________________________________________________________ >> >>Express yourself instantly with MSN Messenger! Download today - it's >> FREE! >> >>http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ >> >> >> >> >> > >> >> _________________________________________________________________ >> Dont just search. Find. Check out the new MSN Search! >> http://search.msn.click-url.com/go/onm00200636ave/direct/01/ >> >> The information contained in this electronic message and any >> attachments to this message are intended for the exclusive use of the >> addressee(s)and may contain confidential or privileged information. If >> you are not the intended recipient, please notify the sender or >> administrator@tataelxsi.co.in > > > _________________________________________________________________ > Dont just search. Find. Check out the new MSN Search! > http://search.msn.click-url.com/go/onm00200636ave/direct/01/ > > --MIRAPOINT_PART1_44a268cc Content-Disposition: inline The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s)and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender or administrator@tataelxsi.co.in --MIRAPOINT_PART1_44a268cc-- From skar@tataelxsi.co.in Wed Jun 28 08:09:32 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id B55753B016E for ; Wed, 28 Jun 2006 08:09:32 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09711-02 for ; Wed, 28 Jun 2006 08:09:31 -0400 (EDT) Received: from mail.tataelxsi.co.in (mail.tataelxsi.co.in [203.200.1.48]) by menubar.gnome.org (Postfix) with ESMTP id B45AB3B01C1 for ; Wed, 28 Jun 2006 08:09:29 -0400 (EDT) Received: from skar (tataelxsi.co.in [203.197.169.80] (may be forged)) by mail.tataelxsi.co.in (MOS 3.7.4b-GA) with ESMTP id BRJ80256 (AUTH skar); Wed, 28 Jun 2006 17:40:28 +0530 (IST) From: Suman Kar To: "'Attilio Fiandrotti'" Subject: RE: Failed building GTK with the DFB backend Date: Wed, 28 Jun 2006 17:39:28 +0530 Message-ID: <000801c69aab$b5138bc0$381b320a@telxsi.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <44A26D1D.9090905@tiscali.it> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Junkmail: Blacklisted Content-Type: multipart/mixed; boundary="MIRAPOINT_PART1_44a271b6" X-Mirapoint-Sig: mail.tataelxsi.co.in X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.227 tagged_above=-999 required=2 tests=[AWL=-0.571, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.558, TW_DF=0.077, TW_GD=0.077, TW_GT=0.077, TW_KD=0.077, TW_TK=0.077] X-Spam-Score: -1.227 X-Spam-Level: X-Mailman-Approved-At: Wed, 28 Jun 2006 08:29:04 -0400 Cc: gtk-devel-list@gnome.org, amirthakaruna@tataelxsi.co.in X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: Suman Kar List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2006 12:09:32 -0000 --MIRAPOINT_PART1_44a271b6 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 8bit Can you please post a link to Mike's change? URL to the CVS will do. I am a little confused as the GNOME cvs did not show any results when searching for entries by memmel and the directFB CVS did not throw up a check-in in the last two days. Regards, Suman. -----Original Message----- From: Attilio Fiandrotti [mailto:fiandro@tiscali.it] Sent: Wednesday, June 28, 2006 5:21 PM To: Suman Kar Cc: amirthakaruna@tataelxsi.co.in; gtk-devel-list@gnome.org Subject: Re: Failed building GTK with the DFB backend I apologize for my mistake: only now i realize taht getposition() and getsize() were introduced *after* DFB 0.9.25 was released! Yesterday mike checked in a patch ("Added ifdef to compile with 0.9.24 removes creating a child GdkWindow since it u...") that allows GTK+ to be compiled against DFB >= 0.9.24 (so, also 0.9.25 will do) The correct recipe is: DFB >= 0.9.24 GTK+ HEAD from CVS Attilio Suman Kar wrote: > Hello Attilio, > > Let me try to explain Karuna's problem: we are using the > downloadable source tarball from > http://directfb.org/index.php?path=Main%2FDownloads: > DirectFB-0.9.25.1.tar.gz > > Also, this was released on 03-May-2006. Mike's checkin has happened > on 11-June-2006. Moreover, we could not find the GetPosition() > member in either the http://directfb.org/index.php?path=Main%2FNews > page or in the source files Mike has mentioned in the mail to > the directFB list. > > These indicates to me that this is not really an issue with some path > variable as you suggested. Your inputs are awaited. > > Regards, > Suman. > > -----Original Message----- > From: Attilio Fiandrotti [mailto:fiandro@tiscali.it] > Sent: Wednesday, June 28, 2006 3:03 PM > To: karuna karan > Cc: skar@tataelxsi.co.in; amirthakaruna@tataelxsi.co.in > Subject: Re: Failed building GTK with the DFB backend > > > the symbol GetPosition (and getsize, too) were introduced in DFB 0.9.25 > : if you're trying to compile GTKDFB against DFB 0.9.25, then you must > have provided wrong pkg_config_path or ld_library_path > > Attilio > > karuna karan wrote: > >>hi, >> >>we are already working with DirectFB 0.9.25.1 and GTK 2.9.4(released) >> >>we will start work with GTK 2.9.4 from CVS as suggested by you. >> >>we will get back if any issue arises. >> >>Thanks, >>Karunakaran A. >> >> >> >> >From: Attilio Fiandrotti >> >> >A couple of days ago mike checked in the patch that excludes from >> >compilation some extra code that requires DFB 0.9.25 in the case DFN >>0.9.24 >> >is used. >> >Use CVS sources or apply to GTK 2.9.4 gdkdirectfb.h and >> >gdkwindow-directfb.c from current SVN. >> >If you're a Debian user and run on i386, simply install cairodfb and >>gtkdfb >> >packages [1] which were made recently available (other archs will follow >> >soon). >> > >> >Attilio >> > >> >[1] > > http://mail.directfb.org/pipermail/directfb-dev/2006-June/001973.html > >> > >> >karuna karan wrote: >> >>Hi, >> >> >> >>we have tried to build gtk+ 2.9.4 with backend dfb. >> >>we got the follwing error while building, >> >> >> >>gdkwindow-directfb.c: In function `gdk_directfb_create_child_window': >> >>gdkwindow-directfb.c:2508: error: structure has no member named >> >>`GetPosition' >> >>make[4]: *** [gdkwindow-directfb.lo] Error 1 >> >>make[4]: Leaving directory `/root/new/gtk+-2.9.4/gdk/directfb' >> >>make[3]: *** [all-recursive] Error 1 >> >>make[3]: Leaving directory `/root/new/gtk+-2.9.4/gdk' >> >>make[2]: *** [all] Error 2 >> >>make[2]: Leaving directory `/root/new/gtk+-2.9.4/gdk' >> >>make[1]: *** [all-recursive] Error 1 >> >>make[1]: Leaving directory `/root/new/gtk+-2.9.4' >> >>make: *** [all] Error 2 >> >> >> >>so kindly give feedback on this issue.. >> >> >> >>Thanks, >> >>Karunakaran A. >> >> >> >> >> >> >> >> >> >>>From: Suman Kar >> >>>Reply-To: Suman Kar >> >>>To: "'Attilio Fiandrotti'" , "'karuna >>karan'" >> >>> >> >>>CC: >> >>>Subject: RE: Failed building GTK with the DFB backend >> >>>Date: Tue, 27 Jun 2006 16:51:13 +0530 >> >>> >> >>>Hello Attilio, >> >>> >> >>>Thanks for the quick update. However, the problem goes away when we >>added >> >>>the following: >> >>> >> >>>gboolean >> >>>gdk_screen_is_composited (GdkScreen *screen) >> >>>{ >> >>> g_return_val_if_fail (GDK_IS_SCREEN (screen), NULL); >> >>> return FALSE; >> >>>} >> >>> >> >>> >> >>>is added to gdkscreen-directfb.c (from >> >> >>>>>http://mail.gnome.org/archives/gtk-devel-list/2006-May/msg00210.html ). >> >> >>> >> >>>We will definitely try building gtk+2.9.4 and will get back in case >>there >> >> >>>>>>are any issues. >>>>>> >>>>>>One more thing: we would be really interested in gtk+-2.10. Any >>> >>>idea when >>> >>>>>>this will be out? >>>>>> >>>>>>Regards, >>>>>>Suman. >>>>>> >>>>>>-----Original Message----- >>>>>>From: Attilio Fiandrotti [mailto:fiandro@tiscali.it] >>>>>>Sent: Tuesday, June 27, 2006 3:40 PM >>>>>>To: karuna karan >>>>>>Cc: gtk-devel-list@gnome.org; skar@tataelxsi.co.in >>>>>>Subject: Re: Failed building GTK with the DFB backend >>>>>> >>>>>> >>>>>>karuna karan wrote: >>>>>> >>>>>>>Hi all, >>>>>>> >>>>>>>I tried to build gtk 2.9.1 with directFB backend with following >>>>>>>dependencies, >>>>>> >>>>>>DFB support in was broken: you should try 2.9.4 or follow instructions >>>>>>in the wiki page to build from sratch. >>>>>>If you're a debian user, you can also use precompiled i386 official >>>>>>packages that were built this week >>>>>> >>>>>>http://download.dajobe.org/debian/experimental/ <-cairodfb >>>>>>http://people.debian.org/~joss/packages/ <-gtkdfb >>>>>> >>>>>>Attilio >>>>>> >>>>>>The information contained in this electronic message and any >>> >>>attachments >>> >>>>>>to this message are intended for the exclusive use of the >>> >>>addressee(s)and >>> >>>>>>may contain confidential or privileged information. If you are not the >>>>>>intended recipient, please notify the sender or >>>>>>administrator@tataelxsi.co.in >>>>> >>>>> >>>>>_________________________________________________________________ >>>>>Express yourself instantly with MSN Messenger! Download today - it's >>> >>>FREE! >>> >>>>>http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ >>>>> >>>>> >>>> >>>_________________________________________________________________ >>>Dont just search. Find. Check out the new MSN Search! >>>http://search.msn.click-url.com/go/onm00200636ave/direct/01/ >>> >>>The information contained in this electronic message and any >>>attachments to this message are intended for the exclusive use of the >>>addressee(s)and may contain confidential or privileged information. If >>>you are not the intended recipient, please notify the sender or >>>administrator@tataelxsi.co.in >> >> >>_________________________________________________________________ >>Dont just search. Find. Check out the new MSN Search! >>http://search.msn.click-url.com/go/onm00200636ave/direct/01/ >> >> >> >> >>------------------------------------------------------------------------ >> >>The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s)and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender or administrator@tataelxsi.co.in --MIRAPOINT_PART1_44a271b6 Content-Disposition: inline The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s)and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender or administrator@tataelxsi.co.in --MIRAPOINT_PART1_44a271b6-- From skar@tataelxsi.co.in Wed Jun 28 08:23:02 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 0B3E43B00B1 for ; Wed, 28 Jun 2006 08:23:02 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10159-01 for ; Wed, 28 Jun 2006 08:23:01 -0400 (EDT) Received: from mail.tataelxsi.co.in (mail.tataelxsi.co.in [203.200.1.48]) by menubar.gnome.org (Postfix) with ESMTP id 8F3FE3B006C for ; Wed, 28 Jun 2006 08:23:00 -0400 (EDT) Received: from skar (tataelxsi.co.in [203.197.169.80] (may be forged)) by mail.tataelxsi.co.in (MOS 3.7.4b-GA) with ESMTP id BRJ83266 (AUTH skar); Wed, 28 Jun 2006 17:53:15 +0530 (IST) From: Suman Kar To: "'Matthias Clasen'" Subject: RE: Failed building GTK with the DFB backend Date: Wed, 28 Jun 2006 17:52:15 +0530 Message-ID: <000a01c69aad$7e2b6270$381b320a@telxsi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Junkmail: Blacklisted X-Mirapoint-Sig: mail.tataelxsi.co.in X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-0.029 tagged_above=-999 required=2 tests=[AWL=-1.665, BAYES_50=0.001, RCVD_IN_BL_SPAMCOP_NET=1.558, TW_GT=0.077] X-Spam-Score: -0.029 X-Spam-Level: X-Mailman-Approved-At: Wed, 28 Jun 2006 08:29:19 -0400 Cc: gtk-devel-list@gnome.org, Karunakaran A X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: Suman Kar List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2006 12:23:02 -0000 Matthias, Thanks for the update! Regards, Suman. -----Original Message----- From: Matthias Clasen [mailto:matthias.clasen@gmail.com] Sent: Wednesday, June 28, 2006 12:39 PM To: Suman Kar Cc: Attilio Fiandrotti; karuna karan; gtk-devel-list@gnome.org Subject: Re: Failed building GTK with the DFB backend On 6/27/06, Suman Kar wrote: > One more thing: we would be really interested in gtk+-2.10. Any idea when > this will be out? > I'll start working on the release when I'm back from Guadec next week. The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s)and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender or administrator@tataelxsi.co.in From matthias.clasen@gmail.com Wed Jun 28 09:56:21 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id A02133B0238 for ; Wed, 28 Jun 2006 09:56:21 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14093-02 for ; Wed, 28 Jun 2006 09:56:20 -0400 (EDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.183]) by menubar.gnome.org (Postfix) with ESMTP id 9B78C3B017A for ; Wed, 28 Jun 2006 09:56:20 -0400 (EDT) Received: by py-out-1112.google.com with SMTP id c30so2229313pyc for ; Wed, 28 Jun 2006 06:55:43 -0700 (PDT) Received: by 10.35.63.2 with SMTP id q2mr140094pyk; Wed, 28 Jun 2006 06:55:43 -0700 (PDT) Received: by 10.35.39.16 with HTTP; Wed, 28 Jun 2006 06:55:43 -0700 (PDT) Message-ID: Date: Wed, 28 Jun 2006 09:55:43 -0400 From: "Matthias Clasen" To: "Dave Foster" Subject: Re: gdk_display_close segfault? In-Reply-To: <1151470915.4791.3.camel@neptune.minuslab.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1151470915.4791.3.camel@neptune.minuslab.net> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.41 tagged_above=-999 required=2 tests=[AWL=-0.010, BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2, SPF_PASS=-0.001] X-Spam-Score: -2.41 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2006 13:56:21 -0000 On 6/28/06, Dave Foster wrote: > Hi, > > I've been trying to write a small section of code in my program which > makes a second connection to the X display, using gtkmm.. I kept having > problems, after rewriting it about 5 or 6 times, I tried writing it in > straight gdk, and STILL got the problems. > > I seem to get a segfault whenever I call gdk_display_close(). Here is a > rediculously simple example that gives the problem: > > Glib::ustring disp = ":0.0"; > GdkDisplay* gdisp = gdk_display_open(disp.c_str()); > if (!gdisp) ... > gdk_display_close(gdisp); > > /* > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread -1224202560 (LWP 5689)] > 0xb7b413d0 in gdk_display_x11_dispose () from /usr/lib/libgdk-x11-2.0.so.0 > (gdb) bt > #0 0xb7b413d0 in gdk_display_x11_dispose () from /usr/lib/libgdk-x11-2.0.so.0 > #1 0xb7a11f2b in g_object_unref () from /usr/lib/libgobject-2.0.so.0 > #2 0xb7b20c04 in gdk_display_close () from /usr/lib/libgdk-x11-2.0.so.0 > #3 0x080571d5 in SetBG::set_bg (disp=@0xbfe1b2b0, file=@0xbfe1b2ac, > mode=SetBG::SET_SCALE, bgcolor=@0xbfe1b2a8) at SetBG.cc:67 > ... > */ > > The display is opening fine. I'm running: > > gtk: 2.8.17-1 > glib: 2.10.2-1 > > (hmm, didn't notice that before,t he 2.8 vs 2.10 thing, could that be it?) > > Anyway, I've spent all night trying to debug this and weeks trying to > sort this problem out in my program. What is up with this, what can I > do? gdk_display_close has been fixed in GTK+ 2.10, which should be available soon. From dave.foster@gmail.com Wed Jun 28 10:19:15 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 006DC3B02CA for ; Wed, 28 Jun 2006 10:19:15 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15554-01 for ; Wed, 28 Jun 2006 10:19:14 -0400 (EDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.193]) by menubar.gnome.org (Postfix) with ESMTP id 907993B02D3 for ; Wed, 28 Jun 2006 10:19:13 -0400 (EDT) Received: by wx-out-0102.google.com with SMTP id s15so69257wxc for ; Wed, 28 Jun 2006 07:18:46 -0700 (PDT) Received: by 10.70.49.13 with SMTP id w13mr1383280wxw; Wed, 28 Jun 2006 07:18:46 -0700 (PDT) Received: by 10.70.6.9 with HTTP; Wed, 28 Jun 2006 07:18:46 -0700 (PDT) Message-ID: Date: Wed, 28 Jun 2006 10:18:46 -0400 From: "Dave Foster" To: "Matthias Clasen" Subject: Re: gdk_display_close segfault? In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_68848_11799959.1151504326383" References: <1151470915.4791.3.camel@neptune.minuslab.net> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.399 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2, HTML_MESSAGE=0.001, SPF_PASS=-0.001] X-Spam-Score: -2.399 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2006 14:19:15 -0000 ------=_Part_68848_11799959.1151504326383 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline ok, thank you Matthias. dave On 6/28/06, Matthias Clasen wrote: > > On 6/28/06, Dave Foster wrote: > > Hi, > > > > I've been trying to write a small section of code in my program which > > makes a second connection to the X display, using gtkmm.. I kept having > > problems, after rewriting it about 5 or 6 times, I tried writing it in > > straight gdk, and STILL got the problems. > > > > I seem to get a segfault whenever I call gdk_display_close(). Here is a > > rediculously simple example that gives the problem: > > > > Glib::ustring disp = ":0.0"; > > GdkDisplay* gdisp = gdk_display_open(disp.c_str()); > > if (!gdisp) ... > > gdk_display_close(gdisp); > > > > /* > > Program received signal SIGSEGV, Segmentation fault. > > [Switching to Thread -1224202560 (LWP 5689)] > > 0xb7b413d0 in gdk_display_x11_dispose () from /usr/lib/libgdk- > x11-2.0.so.0 > > (gdb) bt > > #0 0xb7b413d0 in gdk_display_x11_dispose () from /usr/lib/libgdk- > x11-2.0.so.0 > > #1 0xb7a11f2b in g_object_unref () from /usr/lib/libgobject-2.0.so.0 > > #2 0xb7b20c04 in gdk_display_close () from /usr/lib/libgdk-x11-2.0.so.0 > > #3 0x080571d5 in SetBG::set_bg (disp=@0xbfe1b2b0, file=@0xbfe1b2ac, > > mode=SetBG::SET_SCALE, bgcolor=@0xbfe1b2a8) at SetBG.cc:67 > > ... > > */ > > > > The display is opening fine. I'm running: > > > > gtk: 2.8.17-1 > > glib: 2.10.2-1 > > > > (hmm, didn't notice that before,t he 2.8 vs 2.10 thing, could that be > it?) > > > > Anyway, I've spent all night trying to debug this and weeks trying to > > sort this problem out in my program. What is up with this, what can I > > do? > > gdk_display_close has been fixed in GTK+ 2.10, which should be > available soon. > ------=_Part_68848_11799959.1151504326383 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline ok, thank you Matthias.

dave

On 6/28/06, Matthias Clasen <matthias.clasen@gmail.com> wrote:
On 6/28/06, Dave Foster <dave.foster@gmail.com > wrote:
> Hi,
>
> I've been trying to write a small section of code in my program which
> makes a second connection to the X display, using gtkmm.. I kept having
> problems, after rewriting it about 5 or 6 times, I tried writing it in
> straight gdk, and STILL got the problems.
>
> I seem to get a segfault whenever I call gdk_display_close().  Here is a
> rediculously simple example that gives the problem:
>
> Glib::ustring disp = ": 0.0";
> GdkDisplay* gdisp = gdk_display_open(disp.c_str());
> if (!gdisp) ...
> gdk_display_close(gdisp);
>
> /*
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread -1224202560 (LWP 5689)]
> 0xb7b413d0 in gdk_display_x11_dispose () from /usr/lib/libgdk-x11-2.0.so.0
> (gdb) bt
> #0  0xb7b413d0 in gdk_display_x11_dispose () from /usr/lib/libgdk-x11-2.0.so.0
> #1  0xb7a11f2b in g_object_unref () from /usr/lib/libgobject- 2.0.so.0
> #2  0xb7b20c04 in gdk_display_close () from /usr/lib/libgdk-x11-2.0.so.0
> #3  0x080571d5 in SetBG::set_bg (disp=@0xbfe1b2b0, file=@0xbfe1b2ac,
>     mode=SetBG::SET_SCALE, bgcolor=@0xbfe1b2a8) at SetBG.cc:67
> ...
> */
>
> The display is opening fine.  I'm running:
>
> gtk: 2.8.17-1
> glib: 2.10.2-1
>
> (hmm, didn't notice that before,t he 2.8 vs 2.10 thing, could that be it?)
>
> Anyway, I've spent all night trying to debug this and weeks trying to
> sort this problem out in my program.  What is up with this, what can I
> do?

gdk_display_close has been fixed in GTK+ 2.10, which should  be
available soon.

------=_Part_68848_11799959.1151504326383-- From amirthakaruna@tataelxsi.co.in Wed Jun 28 10:30:48 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 6BE0F3B00A7 for ; Wed, 28 Jun 2006 10:30:48 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15942-08 for ; Wed, 28 Jun 2006 10:30:47 -0400 (EDT) Received: from mail.tataelxsi.co.in (mail.tataelxsi.co.in [203.200.1.48]) by menubar.gnome.org (Postfix) with ESMTP id 2C7823B00B0 for ; Wed, 28 Jun 2006 10:30:46 -0400 (EDT) Received: from amirthakaruna (tataelxsi.co.in [203.197.169.80] (may be forged)) by mail.tataelxsi.co.in (MOS 3.7.4b-GA) with ESMTP id BRK15473 (AUTH amirthakaruna); Wed, 28 Jun 2006 20:00:59 +0530 (IST) From: Karunakaran A To: "'Attilio Fiandrotti'" , "'Suman Kar'" Subject: RE: Failed building GTK with the DFB backend Date: Wed, 28 Jun 2006 20:00:01 +0530 Message-ID: <000601c69abf$5747eb80$361b320a@telxsi.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <44A26D1D.9090905@tiscali.it> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Junkmail: Blacklisted Content-Type: multipart/mixed; boundary="MIRAPOINT_PART1_44a292a6" X-Mirapoint-Sig: mail.tataelxsi.co.in X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-0.656 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.558, TW_DF=0.077, TW_GD=0.077, TW_GT=0.077, TW_KD=0.077, TW_TK=0.077] X-Spam-Score: -0.656 X-Spam-Level: X-Mailman-Approved-At: Thu, 29 Jun 2006 03:02:46 -0400 Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2006 14:30:48 -0000 --MIRAPOINT_PART1_44a292a6 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 8bit Hi all, We also tried to build gtk 2.8.18 with patch( gtk+-directfb.patch downloaded from https://debian.polito.it/downloads/gtk+-directfb.tar.bzip ) with DFB as a backend on a different machine. In that, the patch file alters only configure.in file, not the Makefile.in. so while building,it throws error in the directory `/root/gtkdfb/gtk+-2.8.18/gdk' as, make[4]: *** No rule to make target `libgdk-directfb-2.0.la',needed by `all-am'. help me out in this. Karunakaran A. -----Original Message----- From: Attilio Fiandrotti [mailto:fiandro@tiscali.it] Sent: Wednesday, June 28, 2006 5:21 PM To: Suman Kar Cc: amirthakaruna@tataelxsi.co.in; gtk-devel-list@gnome.org Subject: Re: Failed building GTK with the DFB backend I apologize for my mistake: only now i realize taht getposition() and getsize() were introduced *after* DFB 0.9.25 was released! Yesterday mike checked in a patch ("Added ifdef to compile with 0.9.24 removes creating a child GdkWindow since it u...") that allows GTK+ to be compiled against DFB >= 0.9.24 (so, also 0.9.25 will do) The correct recipe is: DFB >= 0.9.24 GTK+ HEAD from CVS Attilio Suman Kar wrote: > Hello Attilio, > > Let me try to explain Karuna's problem: we are using the > downloadable source tarball from > http://directfb.org/index.php?path=Main%2FDownloads: > DirectFB-0.9.25.1.tar.gz > > Also, this was released on 03-May-2006. Mike's checkin has happened > on 11-June-2006. Moreover, we could not find the GetPosition() > member in either the http://directfb.org/index.php?path=Main%2FNews > page or in the source files Mike has mentioned in the mail to > the directFB list. > > These indicates to me that this is not really an issue with some path > variable as you suggested. Your inputs are awaited. > > Regards, > Suman. > > -----Original Message----- > From: Attilio Fiandrotti [mailto:fiandro@tiscali.it] > Sent: Wednesday, June 28, 2006 3:03 PM > To: karuna karan > Cc: skar@tataelxsi.co.in; amirthakaruna@tataelxsi.co.in > Subject: Re: Failed building GTK with the DFB backend > > > the symbol GetPosition (and getsize, too) were introduced in DFB 0.9.25 > : if you're trying to compile GTKDFB against DFB 0.9.25, then you must > have provided wrong pkg_config_path or ld_library_path > > Attilio > > karuna karan wrote: > >>hi, >> >>we are already working with DirectFB 0.9.25.1 and GTK 2.9.4(released) >> >>we will start work with GTK 2.9.4 from CVS as suggested by you. >> >>we will get back if any issue arises. >> >>Thanks, >>Karunakaran A. >> >> >> >> >From: Attilio Fiandrotti >> >> >A couple of days ago mike checked in the patch that excludes from >> >compilation some extra code that requires DFB 0.9.25 in the case DFN >>0.9.24 >> >is used. >> >Use CVS sources or apply to GTK 2.9.4 gdkdirectfb.h and >> >gdkwindow-directfb.c from current SVN. >> >If you're a Debian user and run on i386, simply install cairodfb and >>gtkdfb >> >packages [1] which were made recently available (other archs will follow >> >soon). >> > >> >Attilio >> > >> >[1] > > http://mail.directfb.org/pipermail/directfb-dev/2006-June/001973.html > >> > >> >karuna karan wrote: >> >>Hi, >> >> >> >>we have tried to build gtk+ 2.9.4 with backend dfb. >> >>we got the follwing error while building, >> >> >> >>gdkwindow-directfb.c: In function `gdk_directfb_create_child_window': >> >>gdkwindow-directfb.c:2508: error: structure has no member named >> >>`GetPosition' >> >>make[4]: *** [gdkwindow-directfb.lo] Error 1 >> >>make[4]: Leaving directory `/root/new/gtk+-2.9.4/gdk/directfb' >> >>make[3]: *** [all-recursive] Error 1 >> >>make[3]: Leaving directory `/root/new/gtk+-2.9.4/gdk' >> >>make[2]: *** [all] Error 2 >> >>make[2]: Leaving directory `/root/new/gtk+-2.9.4/gdk' >> >>make[1]: *** [all-recursive] Error 1 >> >>make[1]: Leaving directory `/root/new/gtk+-2.9.4' >> >>make: *** [all] Error 2 >> >> >> >>so kindly give feedback on this issue.. >> >> >> >>Thanks, >> >>Karunakaran A. >> >> >> >> >> >> >> >> >> >>>From: Suman Kar >> >>>Reply-To: Suman Kar >> >>>To: "'Attilio Fiandrotti'" , "'karuna >>karan'" >> >>> >> >>>CC: >> >>>Subject: RE: Failed building GTK with the DFB backend >> >>>Date: Tue, 27 Jun 2006 16:51:13 +0530 >> >>> >> >>>Hello Attilio, >> >>> >> >>>Thanks for the quick update. However, the problem goes away when we >>added >> >>>the following: >> >>> >> >>>gboolean >> >>>gdk_screen_is_composited (GdkScreen *screen) >> >>>{ >> >>> g_return_val_if_fail (GDK_IS_SCREEN (screen), NULL); >> >>> return FALSE; >> >>>} >> >>> >> >>> >> >>>is added to gdkscreen-directfb.c (from >> >> >>>>>http://mail.gnome.org/archives/gtk-devel-list/2006-May/msg00210.html ). >> >> >>> >> >>>We will definitely try building gtk+2.9.4 and will get back in case >>there >> >> >>>>>>are any issues. >>>>>> >>>>>>One more thing: we would be really interested in gtk+-2.10. Any >>> >>>idea when >>> >>>>>>this will be out? >>>>>> >>>>>>Regards, >>>>>>Suman. >>>>>> >>>>>>-----Original Message----- >>>>>>From: Attilio Fiandrotti [mailto:fiandro@tiscali.it] >>>>>>Sent: Tuesday, June 27, 2006 3:40 PM >>>>>>To: karuna karan >>>>>>Cc: gtk-devel-list@gnome.org; skar@tataelxsi.co.in >>>>>>Subject: Re: Failed building GTK with the DFB backend >>>>>> >>>>>> >>>>>>karuna karan wrote: >>>>>> >>>>>>>Hi all, >>>>>>> >>>>>>>I tried to build gtk 2.9.1 with directFB backend with following >>>>>>>dependencies, >>>>>> >>>>>>DFB support in was broken: you should try 2.9.4 or follow instructions >>>>>>in the wiki page to build from sratch. >>>>>>If you're a debian user, you can also use precompiled i386 official >>>>>>packages that were built this week >>>>>> >>>>>>http://download.dajobe.org/debian/experimental/ <-cairodfb >>>>>>http://people.debian.org/~joss/packages/ <-gtkdfb >>>>>> >>>>>>Attilio >>>>>> >>>>>>The information contained in this electronic message and any >>> >>>attachments >>> >>>>>>to this message are intended for the exclusive use of the >>> >>>addressee(s)and >>> >>>>>>may contain confidential or privileged information. If you are not the >>>>>>intended recipient, please notify the sender or >>>>>>administrator@tataelxsi.co.in >>>>> >>>>> >>>>>_________________________________________________________________ >>>>>Express yourself instantly with MSN Messenger! Download today - it's >>> >>>FREE! >>> >>>>>http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ >>>>> >>>>> >>>> >>>_________________________________________________________________ >>>Dont just search. Find. Check out the new MSN Search! >>>http://search.msn.click-url.com/go/onm00200636ave/direct/01/ >>> >>>The information contained in this electronic message and any >>>attachments to this message are intended for the exclusive use of the >>>addressee(s)and may contain confidential or privileged information. If >>>you are not the intended recipient, please notify the sender or >>>administrator@tataelxsi.co.in >> >> >>_________________________________________________________________ >>Dont just search. Find. Check out the new MSN Search! >>http://search.msn.click-url.com/go/onm00200636ave/direct/01/ >> >> >> >> >>------------------------------------------------------------------------ >> >>The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s)and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender or administrator@tataelxsi.co.in --MIRAPOINT_PART1_44a292a6 Content-Disposition: inline The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s)and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender or administrator@tataelxsi.co.in --MIRAPOINT_PART1_44a292a6-- From jalaganapathy@tataelxsi.co.in Thu Jun 29 03:08:28 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 62B543B03EF for ; Thu, 29 Jun 2006 03:08:28 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24602-01 for ; Thu, 29 Jun 2006 03:08:26 -0400 (EDT) Received: from mail.tataelxsi.co.in (mail.tataelxsi.co.in [203.200.1.48]) by menubar.gnome.org (Postfix) with ESMTP id 1B5DF3B03B2 for ; Thu, 29 Jun 2006 03:08:25 -0400 (EDT) Received: (from mail.tataelxsi.co.in [203.197.169.20]) by mail.tataelxsi.co.in (MOS 3.7.4b-GA) with HTTP/1.1 id BRM16267 (AUTH jalaganapathy); Thu, 29 Jun 2006 12:39:37 +0530 (IST) From: Jalagandeswari G Subject: Installing GTK+2.9.1 in Fedora core2 To: gtk-devel-list@gnome.org X-Mailer: Mirapoint Webmail Direct 3.7.4b-GA MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20060629123937.BRM16267@mail.tataelxsi.co.in> Date: Thu, 29 Jun 2006 12:39:37 +0530 (IST) X-Junkmail: Blacklisted X-Mirapoint-Sig: mail.tataelxsi.co.in X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.599 tagged_above=-999 required=2 tests=[BAYES_00=-2.599] X-Spam-Score: -2.599 X-Spam-Level: X-Mailman-Approved-At: Thu, 29 Jun 2006 07:31:44 -0400 X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2006 07:08:28 -0000 Hello All, Iam trying to install gtk+2.9.1 in fedora core2. i am using glib-1.10.1, cairo-1.1.6,atk-1.0.1 and pango-1.13.1 my configure options are ./configure --prefix=/exp/ffox Confugure works fine. While running make i am getting the following errors. gcc -DHAVE_CONFIG_H -I. -I. -I.. -DG_LOG_DOMAIN=\"Gtk\" -DGTK_LIBDIR=\"/exp/ffox/lib\" -DGTK_DATADIR=\"/exp/ffox/share\" -DGTK_DATA_PREFIX=\"/exp/ffox\" -DGTK_SYSCONFDIR=\"/exp/ffox/etc\" -DGTK_VERSION=\"2.9.1\" -DGTK_BINARY_VERSION=\"2.10.0\" -DGTK_HOST=\"i686-pc-linux-gnu\" -DGTK_COMPILATION -DGTK_PRINT_BACKENDS=\"pdf,cups\" -I../gtk -I.. -I../gdk -I../gdk -I../gdk-pixbuf -I../gdk-pixbuf -DGDK_PIXBUF_DISABLE_DEPRECATED -DGDK_DISABLE_DEPRECATED -DGTK_DISABLE_DEPRECATED -DGTK_FILE_SYSTEM_ENABLE_UNSUPPORTED -DGTK_PRINT_BACKEND_ENABLE_UNSUPPORTED -DG_ENABLE_DEBUG -pthread -I/exp/ffox//include/glib-2.0 -I/exp/ffox//lib/glib-2.0/include -I/exp/ffox//include/pango-1.0 -I/exp/ffox//include/cairo -I/exp/ffox//include/atk-1.0 -I/exp/ffox/include -I/usr/X11R6/include -DG_DISABLE_DEPRECATED -g -O2 -g -Wall -MT gtkrecentmanager.lo -MD -MP -MF .deps/gtkrecentmanager.Tpo -c gtkrecentmanager.c -fPIC -DPIC -o .libs/gtkrecentmanager.o gtkrecentmanager.c:109: error: syntax error before "GBookmarkFile" gtkrecentmanager.c:109: warning: no semicolon at end of struct or union gtkrecentmanager.c:113: error: syntax error before '}' token gtkrecentmanager.c: In function `gtk_recent_manager_class_init': gtkrecentmanager.c:274: error: invalid application of `sizeof' to an incomplete type gtkrecentmanager.c: In function `gtk_recent_manager_init': gtkrecentmanager.c:286: error: dereferencing pointer to incomplete type gtkrecentmanager.c:290: error: dereferencing pointer to incomplete type gtkrecentmanager.c:291: error: dereferencing pointer to incomplete type gtkrecentmanager.c:293: error: dereferencing pointer to incomplete type gtkrecentmanager.c:294: error: dereferencing pointer to incomplete type gtkrecentmanager.c:295: error: dereferencing pointer to incomplete type gtkrecentmanager.c:296: error: dereferencing pointer to incomplete type gtkrecentmanager.c:298: error: dereferencing pointer to incomplete type gtkrecentmanager.c: In function `gtk_recent_manager_get_property': gtkrecentmanager.c:336: error: dereferencing pointer to incomplete type gtkrecentmanager.c:339: error: dereferencing pointer to incomplete type gtkrecentmanager.c:342: error: dereferencing pointer to incomplete type gtkrecentmanager.c: In function `gtk_recent_manager_finalize': gtkrecentmanager.c:357: error: dereferencing pointer to incomplete type gtkrecentmanager.c:358: error: dereferencing pointer to incomplete type gtkrecentmanager.c:360: error: dereferencing pointer to incomplete type gtkrecentmanager.c:361: error: dereferencing pointer to incomplete type gtkrecentmanager.c:363: error: dereferencing pointer to incomplete type gtkrecentmanager.c:364: warning: implicit declaration of function `g_bookmark_file_free' gtkrecentmanager.c:364: error: dereferencing pointer to incomplete type gtkrecentmanager.c: In function `gtk_recent_manager_real_changed': gtkrecentmanager.c:377: error: dereferencing pointer to incomplete type gtkrecentmanager.c:385: error: dereferencing pointer to incomplete type gtkrecentmanager.c:387: error: dereferencing pointer to incomplete type gtkrecentmanager.c:392: error: dereferencing pointer to incomplete type gtkrecentmanager.c:394: error: dereferencing pointer to incomplete type gtkrecentmanager.c:394: warning: implicit declaration of function `g_bookmark_file_new' gtkrecentmanager.c:395: error: dereferencing pointer to incomplete type gtkrecentmanager.c:399: warning: implicit declaration of function `g_bookmark_file_to_file' gtkrecentmanager.c:399: error: dereferencing pointer to incomplete type gtkrecentmanager.c:400: error: dereferencing pointer to incomplete type gtkrecentmanager.c:406: error: dereferencing pointer to incomplete type gtkrecentmanager.c:415: error: dereferencing pointer to incomplete type gtkrecentmanager.c:419: error: dereferencing pointer to incomplete type gtkrecentmanager.c:422: error: dereferencing pointer to incomplete type gtkrecentmanager.c:429: error: dereferencing pointer to incomplete type gtkrecentmanager.c:432: error: dereferencing pointer to incomplete type gtkrecentmanager.c: In function `gtk_recent_manager_poll_timeout': gtkrecentmanager.c:458: error: dereferencing pointer to incomplete type gtkrecentmanager.c:458: error: dereferencing pointer to incomplete type gtkrecentmanager.c:461: error: dereferencing pointer to incomplete type gtkrecentmanager.c:470: error: dereferencing pointer to incomplete type gtkrecentmanager.c:477: error: dereferencing pointer to incomplete type gtkrecentmanager.c: In function `gtk_recent_manager_set_filename': gtkrecentmanager.c:498: error: dereferencing pointer to incomplete type gtkrecentmanager.c:500: error: dereferencing pointer to incomplete type gtkrecentmanager.c:502: error: dereferencing pointer to incomplete type gtkrecentmanager.c:503: error: dereferencing pointer to incomplete type gtkrecentmanager.c:506: error: dereferencing pointer to incomplete type gtkrecentmanager.c:507: error: dereferencing pointer to incomplete type gtkrecentmanager.c:514: error: dereferencing pointer to incomplete type gtkrecentmanager.c: In function `build_recent_items_list': gtkrecentmanager.c:534: error: dereferencing pointer to incomplete type gtkrecentmanager.c:536: error: dereferencing pointer to incomplete type gtkrecentmanager.c:538: error: dereferencing pointer to incomplete type gtkrecentmanager.c:539: error: dereferencing pointer to incomplete type gtkrecentmanager.c:542: error: dereferencing pointer to incomplete type gtkrecentmanager.c:555: error: dereferencing pointer to incomplete type gtkrecentmanager.c:563: error: dereferencing pointer to incomplete type gtkrecentmanager.c:565: error: dereferencing pointer to incomplete type gtkrecentmanager.c:571: warning: implicit declaration of function `g_bookmark_file_load_from_file' gtkrecentmanager.c:571: error: dereferencing pointer to incomplete type gtkrecentmanager.c:572: error: dereferencing pointer to incomplete type gtkrecentmanager.c:578: error: dereferencing pointer to incomplete type gtkrecentmanager.c:581: error: dereferencing pointer to incomplete type gtkrecentmanager.c:582: error: dereferencing pointer to incomplete type gtkrecentmanager.c:587: warning: implicit declaration of function `g_bookmark_file_get_size' gtkrecentmanager.c:587: error: dereferencing pointer to incomplete type gtkrecentmanager.c:588: error: dereferencing pointer to incomplete type gtkrecentmanager.c:590: error: dereferencing pointer to incomplete type gtkrecentmanager.c:595: error: dereferencing pointer to incomplete type gtkrecentmanager.c:596: error: dereferencing pointer to incomplete type gtkrecentmanager.c: In function `IA__gtk_recent_manager_get_for_screen': gtkrecentmanager.c:683: error: dereferencing pointer to incomplete type gtkrecentmanager.c: In function `display_closed': gtkrecentmanager.c:697: error: dereferencing pointer to incomplete type gtkrecentmanager.c:698: error: dereferencing pointer to incomplete type gtkrecentmanager.c:703: error: dereferencing pointer to incomplete type gtkrecentmanager.c: In function `unset_screen': gtkrecentmanager.c:718: error: dereferencing pointer to incomplete type gtkrecentmanager.c:720: error: dereferencing pointer to incomplete type gtkrecentmanager.c:726: error: dereferencing pointer to incomplete type gtkrecentmanager.c: In function `IA__gtk_recent_manager_set_screen': gtkrecentmanager.c:759: error: dereferencing pointer to incomplete type gtkrecentmanager.c: In function `IA__gtk_recent_manager_set_limit': gtkrecentmanager.c:786: error: dereferencing pointer to incomplete type gtkrecentmanager.c: In function `IA__gtk_recent_manager_get_limit': gtkrecentmanager.c:808: error: dereferencing pointer to incomplete type gtkrecentmanager.c: In function `IA__gtk_recent_manager_add_full': gtkrecentmanager.c:977: error: dereferencing pointer to incomplete type gtkrecentmanager.c:979: error: dereferencing pointer to incomplete type gtkrecentmanager.c:980: error: dereferencing pointer to incomplete type gtkrecentmanager.c:984: warning: implicit declaration of function `g_bookmark_file_set_title' gtkrecentmanager.c:984: error: dereferencing pointer to incomplete type gtkrecentmanager.c:987: warning: implicit declaration of function `g_bookmark_file_set_description' gtkrecentmanager.c:987: error: dereferencing pointer to incomplete type gtkrecentmanager.c:989: warning: implicit declaration of function `g_bookmark_file_set_mime_type' gtkrecentmanager.c:989: error: dereferencing pointer to incomplete type gtkrecentmanager.c:996: warning: implicit declaration of function `g_bookmark_file_add_group' gtkrecentmanager.c:996: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1003: warning: implicit declaration of function `g_bookmark_file_add_application' gtkrecentmanager.c:1003: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1007: warning: implicit declaration of function `g_bookmark_file_set_is_private' gtkrecentmanager.c:1007: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1013: error: dereferencing pointer to incomplete type gtkrecentmanager.c: In function `IA__gtk_recent_manager_remove_item': gtkrecentmanager.c:1048: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1050: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1051: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1061: warning: implicit declaration of function `g_bookmark_file_remove_item' gtkrecentmanager.c:1061: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1069: error: dereferencing pointer to incomplete type gtkrecentmanager.c: In function `IA__gtk_recent_manager_has_item': gtkrecentmanager.c:1098: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1100: warning: implicit declaration of function `g_bookmark_file_has_item' gtkrecentmanager.c:1100: error: dereferencing pointer to incomplete type gtkrecentmanager.c: At top level: gtkrecentmanager.c:1104: error: syntax error before '*' token gtkrecentmanager.c: In function `build_recent_info': gtkrecentmanager.c:1110: error: `bookmarks' undeclared (first use in this function) gtkrecentmanager.c:1110: error: (Each undeclared identifier is reported only once gtkrecentmanager.c:1110: error: for each function it appears in.) gtkrecentmanager.c:1111: error: `info' undeclared (first use in this function) gtkrecentmanager.c:1113: warning: implicit declaration of function `g_bookmark_file_get_title' gtkrecentmanager.c:1114: warning: implicit declaration of function `g_bookmark_file_get_description' gtkrecentmanager.c:1115: warning: implicit declaration of function `g_bookmark_file_get_mime_type' gtkrecentmanager.c:1117: warning: implicit declaration of function `g_bookmark_file_get_is_private' gtkrecentmanager.c:1119: warning: implicit declaration of function `g_bookmark_file_get_added' gtkrecentmanager.c:1120: warning: implicit declaration of function `g_bookmark_file_get_modified' gtkrecentmanager.c:1121: warning: implicit declaration of function `g_bookmark_file_get_visited' gtkrecentmanager.c:1123: warning: implicit declaration of function `g_bookmark_file_get_groups' gtkrecentmanager.c:1123: warning: assignment makes pointer from integer without a cast gtkrecentmanager.c:1133: warning: implicit declaration of function `g_bookmark_file_get_applications' gtkrecentmanager.c:1133: warning: assignment makes pointer from integer without a cast gtkrecentmanager.c:1144: warning: implicit declaration of function `g_bookmark_file_get_app_info' gtkrecentmanager.c: In function `IA__gtk_recent_manager_lookup_item': gtkrecentmanager.c:1196: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1198: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1199: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1209: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1224: error: dereferencing pointer to incomplete type gtkrecentmanager.c: In function `IA__gtk_recent_manager_move_item': gtkrecentmanager.c:1268: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1278: warning: implicit declaration of function `g_bookmark_file_move_item' gtkrecentmanager.c:1278: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1287: error: dereferencing pointer to incomplete type gtkrecentmanager.c: In function `IA__gtk_recent_manager_get_items': gtkrecentmanager.c:1317: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1320: warning: implicit declaration of function `g_bookmark_file_get_uris' gtkrecentmanager.c:1320: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1320: warning: assignment makes pointer from integer without a cast gtkrecentmanager.c:1327: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1344: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1345: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1349: error: dereferencing pointer to incomplete type gtkrecentmanager.c: In function `purge_recent_items_list': gtkrecentmanager.c:1370: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1373: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1374: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1376: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1377: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1378: error: dereferencing pointer to incomplete type gtkrecentmanager.c: In function `IA__gtk_recent_manager_purge_items': gtkrecentmanager.c:1406: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1409: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1415: error: dereferencing pointer to incomplete type make[4]: *** [gtkrecentmanager.lo] Error 1 make[4]: Leaving directory `/exp/ffox/gtk+-2.9.1/gtk' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/exp/ffox/gtk+-2.9.1/gtk' make[2]: *** [all] Error 2 make[2]: Leaving directory `/exp/ffox/gtk+-2.9.1/gtk' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/exp/ffox/gtk+-2.9.1' make: *** [all] Error 2 Pls help me out to find a solution. regards, Jala The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s)and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender or administrator@tataelxsi.co.in From mitch@gimp.org Fri Jun 30 13:17:37 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 4D29A3B00D8 for ; Fri, 30 Jun 2006 13:17:37 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02485-01 for ; Fri, 30 Jun 2006 13:17:35 -0400 (EDT) Received: from mitch.gimp.org (unknown [88.134.98.187]) by menubar.gnome.org (Postfix) with ESMTP id 96E4C3B00FF for ; Fri, 30 Jun 2006 13:17:35 -0400 (EDT) Received: from mitch by mitch.gimp.org with local (Exim 3.36 #1 (Debian)) id 1FvZfn-00022M-00; Wed, 28 Jun 2006 15:01:39 +0200 Subject: Re: gdk_display_close segfault? From: Michael Natterer To: Dave Foster In-Reply-To: <1151470915.4791.3.camel@neptune.minuslab.net> References: <1151470915.4791.3.camel@neptune.minuslab.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Wed, 28 Jun 2006 15:01:39 +0200 Message-Id: <1151499699.4451.0.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-0.219 tagged_above=-999 required=2 tests=[AWL=-2.068, BAYES_00=-2.599, DATE_IN_PAST_48_96=0.379, RCVD_IN_NJABL_DUL=1.946, RCVD_IN_SORBS_DUL=2.046, TW_GT=0.077] X-Spam-Score: -0.219 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jun 2006 17:17:37 -0000 Hi, you can stop debugging right away. Display closing *only* works in GTK+ 2.9.x (upcoming 2.10). No way of making this work in any earlier version. ciao, --mitch On Wed, 2006-06-28 at 01:01 -0400, Dave Foster wrote: > Hi, > > I've been trying to write a small section of code in my program which > makes a second connection to the X display, using gtkmm.. I kept having > problems, after rewriting it about 5 or 6 times, I tried writing it in > straight gdk, and STILL got the problems. > > I seem to get a segfault whenever I call gdk_display_close(). Here is a > rediculously simple example that gives the problem: > > Glib::ustring disp = ":0.0"; > GdkDisplay* gdisp = gdk_display_open(disp.c_str()); > if (!gdisp) ... > gdk_display_close(gdisp); > > /* > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread -1224202560 (LWP 5689)] > 0xb7b413d0 in gdk_display_x11_dispose () from /usr/lib/libgdk-x11-2.0.so.0 > (gdb) bt > #0 0xb7b413d0 in gdk_display_x11_dispose () from /usr/lib/libgdk-x11-2.0.so.0 > #1 0xb7a11f2b in g_object_unref () from /usr/lib/libgobject-2.0.so.0 > #2 0xb7b20c04 in gdk_display_close () from /usr/lib/libgdk-x11-2.0.so.0 > #3 0x080571d5 in SetBG::set_bg (disp=@0xbfe1b2b0, file=@0xbfe1b2ac, > mode=SetBG::SET_SCALE, bgcolor=@0xbfe1b2a8) at SetBG.cc:67 > ... > */ > > The display is opening fine. I'm running: > > gtk: 2.8.17-1 > glib: 2.10.2-1 > > (hmm, didn't notice that before,t he 2.8 vs 2.10 thing, could that be it?) > > Anyway, I've spent all night trying to debug this and weeks trying to > sort this problem out in my program. What is up with this, what can I > do? > > thanks all. > dave > > > > _______________________________________________ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-devel-list From jalaganapathy@tataelxsi.co.in Fri Jun 30 02:45:45 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id DF5083B0105 for ; Fri, 30 Jun 2006 02:45:44 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30527-07 for ; Fri, 30 Jun 2006 02:45:41 -0400 (EDT) Received: from mail.tataelxsi.co.in (mail.tataelxsi.co.in [203.200.1.48]) by menubar.gnome.org (Postfix) with ESMTP id 39FF93B00B8 for ; Fri, 30 Jun 2006 02:45:39 -0400 (EDT) Received: from jalaganapathy (tataelxsi.co.in [203.197.169.80] (may be forged)) by mail.tataelxsi.co.in (MOS 3.7.4b-GA) with ESMTP id BRR48672 (AUTH jalaganapathy); Fri, 30 Jun 2006 12:17:02 +0530 (IST) From: Jalagandeswari G To: Subject: Installing Cairo1.1.6 Date: Fri, 30 Jun 2006 12:16:06 +0530 Message-ID: <006301c69c10$ddbbf3d0$321b320a@telxsi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal X-Junkmail: Blacklisted X-Mirapoint-Sig: mail.tataelxsi.co.in X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-0.964 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.558, TW_BP=0.077] X-Spam-Score: -0.964 X-Spam-Level: X-Mailman-Approved-At: Fri, 30 Jun 2006 18:07:05 -0400 X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jun 2006 06:45:45 -0000 Hello All, While installing cairo-1.1.6 on FC3 i am getting following errors during configure I am using glib-2.11.1 $./configure checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking whether to enable maintainer-specific portions of Makefiles... no checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for style of include used by make... GNU checking dependency style of gcc... gcc3 checking how to run the C preprocessor... gcc -E checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking for a sed that does not truncate output... /bin/sed checking for egrep... grep -E checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking dependency style of g++... gcc3 checking how to run the C++ preprocessor... g++ -E checking for g77... g77 checking whether we are using the GNU Fortran 77 compiler... yes checking whether g77 accepts -g... yes checking the maximum length of command line arguments... 32768 checking command to parse /usr/bin/nm -B output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc supports -fno-rtti -fno-exceptions... no checking for gcc option to produce PIC... -fPIC checking if gcc PIC flag -fPIC works... yes checking if gcc static flag -static works... yes checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by g++... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking for g++ option to produce PIC... -fPIC checking if g++ PIC flag -fPIC works... yes checking if g++ static flag -static works... yes checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate appending configuration tag "F77" to libtool checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes checking for g77 option to produce PIC... -fPIC checking if g77 PIC flag -fPIC works... yes checking if g77 static flag -static works... yes checking if g77 supports -c -o file.o... yes checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking for ANSI C header files... (cached) yes checking whether byte ordering is bigendian... no checking for vasnprintf... no checking for cos in -lm... yes checking for pkg-config... /usr/bin/pkg-config checking pkg-config is at least version 0.9.0... yes checking for cairo's xlib backend... checking for XRENDER... Package xrender was not found in the pkg-config search path. Perhaps you should add the directory containing `xrender.pc' to the PKG_CONFIG_PATH environment variable No package 'xrender' found checking X11/extensions/Xrender.h usability... no checking X11/extensions/Xrender.h presence... no checking for X11/extensions/Xrender.h... no checking for XrmFinalize... no checking whether cairo's xlib backend could be enabled... no (requires Xrender http://freedesktop.org/Software/xlibs) checking for cairo's win32 backend... checking whether cairo's win32 backend could be enabled... no (the Microsoft Windows backend requires a Win32 platform) checking for cairo's png backend... configure: WARNING: Could not find libpng in the pkg-config Can any one please post a solution for this. regards, Jala The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s)and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender or administrator@tataelxsi.co.in From the introduction of 2396: This document updates and merges "Uniform Resource Locators" [RFC1738] and "Relative Uniform Resource Locators" [RFC1808] in order to define a single, generic syntax for all URI. It excludes those portions of RFC 1738 that defined the specific syntax of individual URL schemes ... Seems you missed the second sentence. That's why 2396 is not obsoleting 1738 in a formal sense, it only update a part of 1738 and this part doesn't include the definition of the FILE scheme. > from a usability standpoint, i really enjoy not having to type 3 /s in a row > (even though konqi does let you do that too) It's a completely different problem, you should even be able to enter /usr/local and have the software expand/remap to a valid URL. I don't use Konqueror but I'm pretty sure Netscape does this, the goal is that once entered the user is exposed to a valid URL. This should also include escaping of reserved or forbiden characters, the goal is to provide something correct for selection or drag and drop as well as teaching the user. Daniel -- Daniel Veillard | Red Hat Network http://redhat.com/products/network/ veillard@redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From my quick look at the RFC (1459), IRC should be able to support SJIS, UTF-8 and most of the Latin encodings -- the control stream is ASCII. But there is no indication of the encoding in use, making it necessary to use some OOB information to set the right encoding. Nor is there any indication of the language, making selection of an appropriate Han glyph set rather difficult. Pretty primitive protocol. I guess there are sufficient per-channel conventions to resolves these issues. > You may well be well right that we should have worked on making > GdkFont still work; it's certainly a bit of a API hole that there > isn't a conventional character-by-character text drawing API > available. If this is a reasonable course, then perhaps the right idea is to create a new function that returns an Xft font for use by the rendering routines; that way legacy applications would continue to see only GDK_FONT_FONT and GDK_FONT_FONTSET but minor source modifications could switch applications to Xft fonts instead. That would make porting existing Gtk+ apps to use Xft would require few changes rather than a wholesale conversion to Pango. > But considering that we are releasing this weekend, it's not something > we can go back and revisit at this point. > > (While adding a 3rd type of font may seem like a small API compatible, > change, it's actually something that can easily crash applications > that aren't expecting it.) Adding new APIs after the release that preserve source and binary compatibility for existing applications would probably be a better way than whacking gdk_font_load to return a new kind of object; the key is to require applications call a new function to get the new kind of gdk_font object. Keith Packard XFree86 Core Team Compaq Cambridge Research Lab From mardy@users.sourceforge.net Thu Jun 1 07:04:29 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 633423B0C7E for ; Thu, 1 Jun 2006 07:04:29 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28962-04 for ; Thu, 1 Jun 2006 07:04:28 -0400 (EDT) Received: from smtp010.mail.ukl.yahoo.com (smtp010.mail.ukl.yahoo.com [217.12.11.79]) by menubar.gnome.org (Postfix) with SMTP id 690073B013F for ; Thu, 1 Jun 2006 07:04:27 -0400 (EDT) Received: (qmail 61490 invoked from network); 1 Jun 2006 11:04:26 -0000 Received: from unknown (HELO pupilla) (mardy78@151.42.226.237 with login) by smtp010.mail.ukl.yahoo.com with SMTP; 1 Jun 2006 11:04:26 -0000 Received: by pupilla (Postfix, from userid 1000) id 038336B7FF; Thu, 1 Jun 2006 13:03:17 +0200 (CEST) Date: Thu, 1 Jun 2006 13:03:17 +0200 From: Alberto Mardegan To: gtk-devel-list@gnome.org Message-ID: <20060601110317.GA23802@pupilla> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Accept-Language: it,ia,en,bg,es,fr User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.599 tagged_above=-999 required=2 tests=[BAYES_00=-2.599] X-Spam-Score: -2.599 X-Spam-Level: Subject: Histogram widget X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2006 11:04:29 -0000 Hi all! I'm going to write a widget for displaying histograms. Would it be elegant/smart/useful if it were to fetch the data from a GtkTreeModel, or would it be an unneeded complexity and just some GArrays are better? I'm thinking of a GtkTreeModel, in which every row is a histogram bar; hence we would/could have a double field for the value, a string field for the label in the X axis, maybe a GdkColor for the color and whatever can come to mind. Many thanks in advance to all those who will share their thoughts on the matter. -- Saluti, Mardy http://www.interlingua.com ___________________________________ Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB http://mail.yahoo.it From matthias.clasen@gmail.com Thu Jun 1 09:35:39 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 44D6D3B0213 for ; Thu, 1 Jun 2006 09:35:39 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06492-04 for ; Thu, 1 Jun 2006 09:35:37 -0400 (EDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.190]) by menubar.gnome.org (Postfix) with ESMTP id 2B1463B019C for ; Thu, 1 Jun 2006 09:35:37 -0400 (EDT) Received: by nf-out-0910.google.com with SMTP id l37so564726nfc for ; Thu, 01 Jun 2006 06:35:36 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=AXg4pkieJhFwK/fsPTG5BVq6Sv29H8f6t8wbUeiehWS8QFuJL4sEqqu5dTplyA7vdRrz50uICadI8ZT1y2rp+BasRLmOBacUSSXY1blUEAIWfvb1udC+bqhsXFVhdU6V4+2wZCjIuaczx07TxLq1x+v9zHm4YPkA8kydW+5SycA= Received: by 10.48.31.10 with SMTP id e10mr779574nfe; Thu, 01 Jun 2006 06:33:48 -0700 (PDT) Received: by 10.48.215.7 with HTTP; Thu, 1 Jun 2006 06:33:48 -0700 (PDT) Message-ID: Date: Thu, 1 Jun 2006 09:33:48 -0400 From: "Matthias Clasen" To: "Kristian Rietveld" In-Reply-To: <20060531200823.GA7846@babi-pangang.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20060531200823.GA7846@babi-pangang.org> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.742 tagged_above=-999 required=2 tests=[AWL=-0.700, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.558, SPF_PASS=-0.001] X-Spam-Score: -1.742 X-Spam-Level: Cc: gtk-devel-list@gnome.org, timj@imendio.com Subject: Re: Tooltips progress X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2006 13:35:39 -0000 > Attached is some sample code using the new API. Opinions, comments, > suggestions are appreciated. > I don't remember too much of the original proposal, so I'll just go by what I see in the examples... What is the relation between the tooltip-markup and has-tooltip properties ? Is has-tooltip automatically set when setting tooltip-markup ? Or do you only need to set has-tooltip if you want to connect to query-tooltip ? Is the tooltip window available as a property too ? (The example uses a dedicated setter for it). The example doesn't show tooltips constructed using the old tooltips api, but I assume those will continue to work as before, right ? Using x == -1 to indicate a keyboard-triggered tooltip looks a bit odd to me; how about adding a boolean parameter for this ? Regarding dedicated treeview api, I think we can do without it (at least initially), if we have a good example in the docs. Though lots of people will forget the selection_changed thing for keyboard tooltips... Could you enhance your demo with an example of text view tooltips on a tag ? Matthias From jean.brefort@normalesup.org Thu Jun 1 09:58:21 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 479CD3B0171 for ; Thu, 1 Jun 2006 09:58:03 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08512-08 for ; Thu, 1 Jun 2006 09:58:01 -0400 (EDT) Received: from smtp4-g19.free.fr (smtp4-g19.free.fr [212.27.42.30]) by menubar.gnome.org (Postfix) with ESMTP id 84A533B0CBB for ; Thu, 1 Jun 2006 09:57:52 -0400 (EDT) Received: from che21-1-82-239-125-56.fbx.proxad.net (che21-1-82-239-125-56.fbx.proxad.net [82.239.125.56]) by smtp4-g19.free.fr (Postfix) with ESMTP id DE3EA54C0D; Thu, 1 Jun 2006 15:57:50 +0200 (CEST) From: Jean =?ISO-8859-1?Q?Br=E9fort?= To: Alberto Mardegan In-Reply-To: <20060601110317.GA23802@pupilla> References: <20060601110317.GA23802@pupilla> Content-Type: text/plain; charset=utf-8 Date: Thu, 01 Jun 2006 16:00:49 +0200 Message-Id: <1149170449.11316.1.camel@athlon.brefort.fr> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.884 tagged_above=-999 required=2 tests=[AWL=-0.354, BAYES_00=-2.599, SPF_NEUTRAL=1.069] X-Spam-Score: -1.884 X-Spam-Level: Cc: gtk-devel-list@gnome.org Subject: Re: Histogram widget X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2006 13:58:21 -0000 Le jeudi 01 juin 2006 à 13:03 +0200, Alberto Mardegan a écrit : > Hi all! > I'm going to write a widget for displaying histograms. Would it be > elegant/smart/useful if it were to fetch the data from a GtkTreeModel, > or would it be an unneeded complexity and just some GArrays are better? > > I'm thinking of a GtkTreeModel, in which every row is a histogram bar; > hence we would/could have a double field for the value, a string field > for the label in the X axis, maybe a GdkColor for the color and whatever > can come to mind. > > Many thanks in advance to all those who will share their thoughts on the > matter. Do you want histograms or column charts? Anyway both already exist in goffice and we have the GOGraphWidget widget to display a large variety of 2D charts. Regards, Jean Bréfort From mitch@gimp.org Thu Jun 1 10:37:41 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 9C8673B0253 for ; Thu, 1 Jun 2006 10:37:41 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12026-06 for ; Thu, 1 Jun 2006 10:37:40 -0400 (EDT) Received: from mitch.gimp.org (p549C9506.dip0.t-ipconnect.de [84.156.149.6]) by menubar.gnome.org (Postfix) with ESMTP id 630D53B0171 for ; Thu, 1 Jun 2006 10:37:40 -0400 (EDT) Received: from mitch by mitch.gimp.org with local (Exim 3.36 #1 (Debian)) id 1FloKa-0005tI-00; Thu, 01 Jun 2006 16:39:24 +0200 From: Michael Natterer To: Kristian Rietveld In-Reply-To: <20060531200823.GA7846@babi-pangang.org> References: <20060531200823.GA7846@babi-pangang.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Thu, 01 Jun 2006 16:39:24 +0200 Message-Id: <1149172764.5721.13.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-0.468 tagged_above=-999 required=2 tests=[AWL=-1.996, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, RCVD_IN_NJABL_DUL=1.946, RCVD_IN_SORBS_DUL=2.046] X-Spam-Score: -0.468 X-Spam-Level: Cc: gtk-devel-list@gnome.org, timj@imendio.com Subject: Re: Tooltips progress X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2006 14:37:41 -0000 On Wed, 2006-05-31 at 22:08 +0200, Kristian Rietveld wrote: > Currently, we are using the following query-tooltips signal: > > gboolean (*query_tooltip) (GtkWidget *widget, > gint x, > gint y, > GtkTooltip *tooltip); > > But if a user sets a custom using gtk_widget_set_custom_window(), we don't > have to pass a GtkTooltip around. So currently I just set the tooltip > field to NULL, so the user knows he has to use his own custom tooltip > window (and we assume he has a reference to that). Is this okay or do > we want to change this? We could also move the _set_custom_window() > functions into GtkTooltip for example. I would very much appreciate if the GtkTooltip object also kept track of the custom window. IMHO it makes no sense to handle this differently. gtk_tooltip_set_markup() vs. gtk_tooltip_set_window() simply feels much better than the asymmetry in gtk_tooltip_set_markup() vs. gtk_widget_set_tooltip_window() The current approach even limits the new tooltip system's use cases, since you have to set the custom window *outside* the callback. There is no way to decide *in* the callback if a standard tooltip is sufficient, or if a custom window is needed. Another problem is the assymetry in getting the relevant data to the callback. With markup, the GtkTooltip can be queried for the markup, if it's a custom window, you have to get it to the callback somehow. In your example code it's passed as user_data, but user_data is often not available since it's needed for other things, so you have to add a "GtkWidget *tooltip_window" to the "other thing". If "other thing" is e.g. the application toplevel window, which of the sub-widget's tooltips should it keep? All of them? People will in many cases end up attaching the tooltip window to the widget. I also fail to see why the "has-tooltip" property has to be set to TRUE, even tho a tooltip window was set on the widget. ciao, --mitch From islewind@gmail.com Thu Jun 1 11:16:53 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id CCF0F3B027D for ; Thu, 1 Jun 2006 11:16:53 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15167-10 for ; Thu, 1 Jun 2006 11:16:52 -0400 (EDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.181]) by menubar.gnome.org (Postfix) with ESMTP id EBDF73B02A2 for ; Thu, 1 Jun 2006 11:16:51 -0400 (EDT) Received: by py-out-1112.google.com with SMTP id x31so492875pye for ; Thu, 01 Jun 2006 08:16:51 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=TJcxirCpCUc11Q5e90yGryvZPvt6/4y9oixknOJbU9D0ul2vMJTRqtCSsnJU4SxRLn9lAKaOyN+GZ5nbxOOcf0T99ZPfjnqzOA3KseyOVQ4Ap+A8c67skU0CG6t40az7MwaWe4KCKIFXgrpOCN10KzuNVCisW4dtldpMgxlx5bQ= Received: by 10.35.36.13 with SMTP id o13mr1010511pyj; Thu, 01 Jun 2006 08:16:51 -0700 (PDT) Received: by 10.35.10.17 with HTTP; Thu, 1 Jun 2006 08:16:50 -0700 (PDT) Message-ID: <7bf6f2dc0606010816q15d512aejc30a6c93bc165e6@mail.gmail.com> Date: Thu, 1 Jun 2006 17:16:50 +0200 From: "=?ISO-8859-1?Q?=D8yvind_Kol=E5s?=" Sender: islewind@gmail.com To: "=?ISO-8859-1?Q?Carlos_Eduardo_Rodrigues_Di=F3genes?=" In-Reply-To: <1149104973.27709.4.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <1149104973.27709.4.camel@localhost.localdomain> X-Google-Sender-Auth: aee248fb7aae0f83 X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.571 tagged_above=-999 required=2 tests=[AWL=0.029, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.571 X-Spam-Level: Cc: gtk-devel-list@gnome.org Subject: Re: Color space transformations in GTK X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2006 15:16:54 -0000 On 5/31/06, Carlos Eduardo Rodrigues Di=F3genes = wrote: > Hi, > > There is any plan to add color spaces conversions in GTK+ (GDK or > Gdk-Pixbuf)? If the answear is no, why not? Pixel format conversions is not a small piece of code and the needed pixel formats varies from scenario to scenario. Most programs will not need such a large general infrastructure and the ones that really need it would probably not be satisfied with a simpler solution. What functionality is it you miss that you think fits into a GUI toolkit? (color management is a seperate issue to color space(pixel format) conversions according to my interpretation of your question). /=D8yvind K. --=20 =ABThe future is already here. It's just not very evenly distributed=BB -- William Gibson http://pippin.gimp.org/ http://ffii.org/ From timj@gtk.org Thu Jun 1 11:17:09 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 565CF3B0DC9 for ; Thu, 1 Jun 2006 11:17:09 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15377-03 for ; Thu, 1 Jun 2006 11:17:02 -0400 (EDT) Received: from webmail.hansenet.de (mail01.hansenet.de [213.191.73.61]) by menubar.gnome.org (Postfix) with ESMTP id 8AFEE3B0DB5 for ; Thu, 1 Jun 2006 11:17:00 -0400 (EDT) Received: from birnet.org (213.39.195.111) by webmail.hansenet.de (7.2.059) id 447D3FB2000502B1; Thu, 1 Jun 2006 17:16:59 +0200 Received: from master.birnet.private (localhost [127.0.0.1]) by birnet.org (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k51FGvIU003186 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 1 Jun 2006 17:16:57 +0200 Received: (from timj@localhost) by master.birnet.private (8.13.4/8.13.4/Submit) id k51FGpl3003183; Thu, 1 Jun 2006 17:16:51 +0200 Date: Thu, 1 Jun 2006 17:16:51 +0200 (CEST) From: Tim Janik X-X-Sender: timj@master.birnet.private To: Kristian Rietveld In-Reply-To: <20060531183045.GA7564@babi-pangang.org> Message-ID: References: <20060314132538.GA3526@babi-pangang.org> <443B4A8A.8000302@imendio.com> <20060425103017.GA15762@babi-pangang.org> <20060531183045.GA7564@babi-pangang.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.431 tagged_above=-999 required=2 tests=[AWL=0.168, BAYES_00=-2.599] X-Spam-Score: -2.431 X-Spam-Level: Cc: Gtk+ Developers , Soeren Sandmann Subject: Re: Callback based tooltips (Re: New tooltips API, continued) X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2006 15:17:10 -0000 On Wed, 31 May 2006, Kristian Rietveld wrote: > On Tue, Apr 25, 2006 at 03:08:12PM +0200, Soeren Sandmann wrote: >> I once wrote down how tooltips should behave: > > I mostly like the behaviour you described below. > >> - Tooltips are too intrusive. The text should be smaller, and not sure if this has been raised already... the font size of the tooltips should be exactly as large as the default font size (module tooltip markup of course) to avoid reducing usability of the tooltips in contrast to normal text (labels). >> they should to the right of the cursor, and a little below >> the cursor's center. --- ciaoTJ From timj@gtk.org Thu Jun 1 12:12:43 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id E5C0F3B0171 for ; Thu, 1 Jun 2006 12:12:42 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19272-05 for ; Thu, 1 Jun 2006 12:12:40 -0400 (EDT) Received: from webmail.hansenet.de (mail03.hansenet.de [213.191.73.10]) by menubar.gnome.org (Postfix) with ESMTP id 9C9433B015C for ; Thu, 1 Jun 2006 12:12:39 -0400 (EDT) Received: from birnet.org (213.39.195.111) by webmail.hansenet.de (7.2.059) id 447C08450012767E; Thu, 1 Jun 2006 18:12:37 +0200 Received: from master.birnet.private (localhost [127.0.0.1]) by birnet.org (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k51GCZTL005312 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 1 Jun 2006 18:12:35 +0200 Received: (from timj@localhost) by master.birnet.private (8.13.4/8.13.4/Submit) id k51GCY4h005311; Thu, 1 Jun 2006 18:12:34 +0200 Date: Thu, 1 Jun 2006 18:12:34 +0200 (CEST) From: Tim Janik X-X-Sender: timj@master.birnet.private To: Kristian Rietveld In-Reply-To: <20060531200823.GA7846@babi-pangang.org> Message-ID: References: <20060531200823.GA7846@babi-pangang.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.434 tagged_above=-999 required=2 tests=[AWL=0.165, BAYES_00=-2.599] X-Spam-Score: -2.434 X-Spam-Level: Cc: Gtk+ Developers , Matthias Clasen Subject: Re: Tooltips progress X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2006 16:12:43 -0000 On Wed, 31 May 2006, Kristian Rietveld wrote: > Last week I've been working on the tooltips implementation, using the > callback-based approach/interface discussed earlier on this mailing list. > The basics are working already including keyboard support and custom > windows. Before I can finalize a patch for reviewal, I have some comments > and questions. > > > In a follow up to his original mail, Tim is talking about adding the > following function: > > gdk_display_force_query_display (GdkDisplay *); > > I am not sure if this really belongs in GdkDisplay. Currently I have a: > > gtk_widget_force_query_tooltip (GtkWidget *widget); > > which works just fine for forcably updating a tooltip, in both keyboard > and mouse mode. I guess most people will usually know which widget's > tooltip to update. Opinions? yes, in most cases the widget will be known, but not in all. the trivial example is changing per-display settings like ::display-tooltips = off or the timeout. also, since we support nesting/overlaying of widgets. even the display might not be clear, which is why i actually proposed: void gtk_display_force_tooltip_query (GdkDisplay*); /* display may be NULL */ /* because of nesting/overlapping tooltips, widget is not always known * http://mail.gnome.org/archives/gtk-devel-list/2006-April/msg00030.html */ but you have a point here, since in most cases the widget will indeed be known, it'll be most convenient to also provide: void gtk_widget_force_query_tooltip (GtkWidget *widget) { gtk_display_force_tooltip_query (gtk_widget_get_display (widget)); } > Currently, we are using the following query-tooltips signal: > > gboolean (*query_tooltip) (GtkWidget *widget, > gint x, > gint y, > GtkTooltip *tooltip); > > But if a user sets a custom using gtk_widget_set_custom_window(), we don't > have to pass a GtkTooltip around. So currently I just set the tooltip > field to NULL, so the user knows he has to use his own custom tooltip > window (and we assume he has a reference to that). my original proposal http://mail.gnome.org/archives/gtk-devel-list/2006-April/msg00010.html included: GtkWindow* gtk_widget_get_tooltip_window (GtkWidget *widget); so the user doesn't need to duplicate tracking of this window. > Is this okay or do > we want to change this? We could also move the _set_custom_window() > functions into GtkTooltip for example. no, i intentionally didn't put it there. the reasoning for this was: - the setter should go along with a getter - the user should get at the custom window but *not* the tooltips window used by gtk. the latter is violated with a getter on GtkTooltip. > Implementing GtkTreeView tooltips in your application is now pretty easy, > just set up a query_tooltip callback and call gtk_tree_view_get_path_at_pos() > with the coordinates which are provided to you (but if x == -1, the keyboard > mode is enabled and then you should really call gtk_tree_view_get_cursor()). using x==-1&&y==-1 for keyboard mode was a bit of an aftermath patchup to my original proposal. Matthias Clasen now pointed out: > Using x == -1 to indicate a keyboard-triggered tooltip looks a bit > odd to me; how about adding a boolean parameter for this ? and i thnk he is right. another indication that we'd not want (-1,-1) is that you already talk about querying the cursor yourself. so it's probably better to adapt the signal to: gboolean (*query_tooltip) (GtkWidget *widget, gint x, gint y, gboolean keyboard_tip, GtkTooltip *tooltip); and preserve the x,y position. > Would this be sufficient, or do we want to add some special API for supporting > tooltips in the tree view, like having GtkTreeView implement the query > tooltip callback and have tooltip-markup properties on cell renderers. > Personally I think implementing the query-tooltip yourself is easy enough > for people to do and also really flexible, so there's no need for more API. i'd say let's first nail the basic tooltip API. GtkWidget already comes with a default handler. we can still add treeview convenience API later on if that is required. (and for that, i think it'd be easiest to forward the query_tooltip() signal to signals on the columns and cell renderers). > Since we re-query for a tooltip on mouse motion, I was wondering what we > should do in keyboard mode if a key is pressed in, for example, GtkTreeView. > A key press there might change the cursor and we might want to update the > tooltip contents. Do we want stock GTK+ to take care of this, or should the > user do this himself? (For example by calling gtk_widget_force_tooltip_query > from the GtkTreeSelection::changed callback). i think i'd handle key press events like mouse motion and scroll events, i.e. re-query. that eases things on the user side and is consistent with movement. (the basic idea behind my proposal was that gtk+ takes care of the required granularity whenever possible, so gtk_display_force_tooltip_query() needs to allmost never be used). > thanks, > > -kris. > --- ciaoTJ From timj@gtk.org Thu Jun 1 12:21:35 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 96AD53B0E27 for ; Thu, 1 Jun 2006 12:21:35 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19725-05 for ; Thu, 1 Jun 2006 12:21:33 -0400 (EDT) Received: from webmail.hansenet.de (mail02.hansenet.de [213.191.73.62]) by menubar.gnome.org (Postfix) with ESMTP id AE4893B0115 for ; Thu, 1 Jun 2006 12:21:33 -0400 (EDT) Received: from birnet.org (213.39.195.111) by webmail.hansenet.de (7.2.059) id 447C276B001342DD; Thu, 1 Jun 2006 18:21:31 +0200 Received: from master.birnet.private (localhost [127.0.0.1]) by birnet.org (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k51GLTmR005587 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 1 Jun 2006 18:21:29 +0200 Received: (from timj@localhost) by master.birnet.private (8.13.4/8.13.4/Submit) id k51GLTBN005586; Thu, 1 Jun 2006 18:21:29 +0200 Date: Thu, 1 Jun 2006 18:21:29 +0200 (CEST) From: Tim Janik X-X-Sender: timj@master.birnet.private To: Matthias Clasen In-Reply-To: Message-ID: References: <20060531200823.GA7846@babi-pangang.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.436 tagged_above=-999 required=2 tests=[AWL=0.163, BAYES_00=-2.599] X-Spam-Score: -2.436 X-Spam-Level: Cc: Gtk+ Developers , Kristian Rietveld Subject: Re: Tooltips progress X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2006 16:21:35 -0000 On Thu, 1 Jun 2006, Matthias Clasen wrote: >> Attached is some sample code using the new API. Opinions, comments, >> suggestions are appreciated. >> > > I don't remember too much of the original proposal, so I'll just go > by what I see in the examples... > > What is the relation between the tooltip-markup and has-tooltip > properties ? setting ::tooltip-markup should automatically set ::has-tooltip=TRUE; as mentioned in the original proposal: http://mail.gnome.org/archives/gtk-devel-list/2006-April/msg00010.html > Is has-tooltip automatically set when setting tooltip-markup ? > Or do you only need to set has-tooltip if you want to connect to > query-tooltip ? the idea behind ::has-tooltip is to reduce the number of required signal emissions to figure a tooltip. e.g. by adding a PRIVATE_GTK_* flag that indicates if the ::query-tooltips() emission is neccessary. maybe it'd helpt to rename that property to ::can-tooltip? > Is the tooltip window available as a property too ? (The example uses > a dedicated setter for it). i don't quite see a need for that. the custom window is only useful if you implement your own ::query-tooltip() handler anyway and there you could simply use the getter. (if you want to argue consistency with other things settable/gettable on widgets though, then yes, you have a point for also exporting it as a property) > The example doesn't show tooltips constructed using the old tooltips > api, but I assume those will continue to work as before, right ? that was the plan, i.e. you'd basically just do: void gtk_tooltips_set_tip (GtkTooltips *tooltips, GtkWidget *widget, const gchar *tip_text, const gchar *tip_private) { g_object_set (widget, "tooltip-markup", tip_text, NULL); } > Matthias --- ciaoTJ From timj@gtk.org Thu Jun 1 12:37:26 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 777F13B0DE5 for ; Thu, 1 Jun 2006 12:37:26 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20777-08 for ; Thu, 1 Jun 2006 12:37:17 -0400 (EDT) Received: from webmail.hansenet.de (mail03.hansenet.de [213.191.73.10]) by menubar.gnome.org (Postfix) with ESMTP id DD7453B0E15 for ; Thu, 1 Jun 2006 12:37:16 -0400 (EDT) Received: from birnet.org (213.39.195.111) by webmail.hansenet.de (7.2.059) id 447C084500128D01; Thu, 1 Jun 2006 18:36:53 +0200 Received: from master.birnet.private (localhost [127.0.0.1]) by birnet.org (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k51Gaj8T006024 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 1 Jun 2006 18:36:45 +0200 Received: (from timj@localhost) by master.birnet.private (8.13.4/8.13.4/Submit) id k51Gaj0d006023; Thu, 1 Jun 2006 18:36:45 +0200 Date: Thu, 1 Jun 2006 18:36:45 +0200 (CEST) From: Tim Janik X-X-Sender: timj@master.birnet.private To: Michael Natterer In-Reply-To: <1149172764.5721.13.camel@localhost> Message-ID: References: <20060531200823.GA7846@babi-pangang.org> <1149172764.5721.13.camel@localhost> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.439 tagged_above=-999 required=2 tests=[AWL=0.160, BAYES_00=-2.599] X-Spam-Score: -2.439 X-Spam-Level: Cc: Gtk+ Developers , Kristian Rietveld Subject: Re: Tooltips progress X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2006 16:37:26 -0000 On Thu, 1 Jun 2006, Michael Natterer wrote: > On Wed, 2006-05-31 at 22:08 +0200, Kristian Rietveld wrote: > >> Currently, we are using the following query-tooltips signal: >> >> gboolean (*query_tooltip) (GtkWidget *widget, >> gint x, >> gint y, >> GtkTooltip *tooltip); >> >> But if a user sets a custom using gtk_widget_set_custom_window(), we don't >> have to pass a GtkTooltip around. So currently I just set the tooltip >> field to NULL, so the user knows he has to use his own custom tooltip >> window (and we assume he has a reference to that). Is this okay or do >> we want to change this? We could also move the _set_custom_window() >> functions into GtkTooltip for example. > > I would very much appreciate if the GtkTooltip object also kept track > of the custom window. IMHO it makes no sense to handle this differently. the widget is meant to do that: void gtk_widget_set_tooltip_window (GtkWidget *widget, GtkWindow *custom_window); GtkWindow* gtk_widget_get_tooltip_window (GtkWidget *widget); for reasons outlined in a previous reply from me to kris. > gtk_tooltip_set_markup() vs. gtk_tooltip_set_window() > > simply feels much better than the asymmetry in > > gtk_tooltip_set_markup() vs. gtk_widget_set_tooltip_window() well, you'd not use GtkTooltip at all if you used gtk_widget_set_tooltip_window() before. in that way, the "asymmetry" simply reflects your usage. > The current approach even limits the new tooltip system's use cases, > since you have to set the custom window *outside* the callback. There > is no way to decide *in* the callback if a standard tooltip is > sufficient, or if a custom window is needed. i don't think it'd be clear that/if the custom window will be available in the GtkTooltip object again upon the next ::query-tooltip() emission. especially since users are not supposed to access GtkTooltip objects/structures in anyway *outside* of ::query-tooltip(), as outlined originally: http://mail.gnome.org/archives/gtk-devel-list/2006-April/msg00010.html also, passing GtkTooltip as NULL is meant to be as a clear indication that the user has to tinker with gtk_widget_get_tooltip_window() instead of the tooltip object. this avoids ambiguities like: static gboolean query_tooltip (GtkWidget *widget, gint x, gint y, GtkTooltip *tooltip) { gtk_tooltip_set_markup (tooltip, "See Me?"); g_object_new (GTK_TYPE_BUTTON, "parent", gtk_widget_get_tooltip_window(), "label", "Can You Click Me?", NULL); gtk_tooltip_set_icon (tooltip, messup_pixbuf); } what's the tooltip code supposed to do here? and yes, the API basically enforces that you decide per widget if an own tooltip window is needed or not. but i don't think that is a strong limitation, we have been discussing usage cases quite some in thise thread and nothing required to defer this decision into the callback (and no existing tooltip code i know of requires this either). so giving the benefits in API (and implementation) this provides, i think it is a reasonable limitation to make. > Another problem is the assymetry in getting the relevant data to the > callback. With markup, the GtkTooltip can be queried for the markup, > if it's a custom window, you have to get it to the callback somehow. Kris just forgot the getter for the custom window on the widget, so signal handler user_data is left alone. > In your example code it's passed as user_data, but user_data is > often not available since it's needed for other things, so you > have to add a "GtkWidget *tooltip_window" to the "other thing". > If "other thing" is e.g. the application toplevel window, which > of the sub-widget's tooltips should it keep? All of them? People > will in many cases end up attaching the tooltip window to the > widget. > > I also fail to see why the "has-tooltip" property has to be > set to TRUE, even tho a tooltip window was set on the widget. > i think this can be come by if we implement: - gtk_widget_set_tooltip_window() should automatically set: GtkWidget::has-tooltip = (custom_window != NULL || GtkWidget::tooltip-markup != ""); - setting GtkWidget::tooltip-markup should automatically set: GtkWidget::has-tooltip = (custom_window != NULL || GtkWidget::tooltip-markup != ""); right? > ciao, > --mitch > --- ciaoTJ From tkomulai@gmail.com Thu Jun 1 15:14:41 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 5A7023B0D70 for ; Thu, 1 Jun 2006 15:14:41 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31172-10 for ; Thu, 1 Jun 2006 15:14:40 -0400 (EDT) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.174]) by menubar.gnome.org (Postfix) with ESMTP id D35083B0CA3 for ; Thu, 1 Jun 2006 15:14:39 -0400 (EDT) Received: by ug-out-1314.google.com with SMTP id o2so222332uge for ; Thu, 01 Jun 2006 12:14:38 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=pkJ9GUF7tBRSDYTFZk62hCunrEDWh/ETW5JoJhlQx7UdB4QeOLJv/qztCngXO4Co/DiXf7ruqlpPxLBRYMp1hjNHoS2y4j0YEr7klSoN2TI6/rPnna1ZG+sfsuFqJaUK0lPq+fzd8NFeO3Vaf+6D8oJI9g3JXpXVTm3KfKENqYU= Received: by 10.78.47.15 with SMTP id u15mr181197huu; Thu, 01 Jun 2006 12:14:38 -0700 (PDT) Received: by 10.78.41.17 with HTTP; Thu, 1 Jun 2006 12:14:38 -0700 (PDT) Message-ID: <68bd3e050606011214i6c36109chff11c7242268b84@mail.gmail.com> Date: Thu, 1 Jun 2006 22:14:38 +0300 From: "Tommi Komulainen" Sender: tkomulai@gmail.com To: gtk-devel-list@gnome.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20060314132538.GA3526@babi-pangang.org> <443B4A8A.8000302@imendio.com> <20060425103017.GA15762@babi-pangang.org> <20060531183045.GA7564@babi-pangang.org> X-Google-Sender-Auth: 6188435c8e783fb2 X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.792 tagged_above=-999 required=2 tests=[AWL=-0.750, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.558, SPF_PASS=-0.001] X-Spam-Score: -1.792 X-Spam-Level: Subject: Re: Callback based tooltips (Re: New tooltips API, continued) X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2006 19:14:41 -0000 On 6/1/06, Tim Janik wrote: > On Wed, 31 May 2006, Kristian Rietveld wrote: > > > On Tue, Apr 25, 2006 at 03:08:12PM +0200, Soeren Sandmann wrote: > >> I once wrote down how tooltips should behave: > > > > I mostly like the behaviour you described below. > > > >> - Tooltips are too intrusive. The text should be smaller, and > > not sure if this has been raised already... > the font size of the tooltips should be exactly as large as the default > font size (module tooltip markup of course) to avoid reducing usability > of the tooltips in contrast to normal text (labels). As long as the font (and other things) are easily themable, the default values are not as important. And as gtk+ doesn't currently have any kind of design for using different font sizes in different contexts, I'd say the default font is a good default. Until someone comes up with a plan that looks at the bigger picture. -- Tommi Komulainen tommi.komulainen@iki.fi From mclasen@redhat.com Thu Jun 1 19:12:39 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id B0B143B0135 for ; Thu, 1 Jun 2006 19:12:39 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12736-06 for ; Thu, 1 Jun 2006 19:12:36 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id 567E43B0061 for ; Thu, 1 Jun 2006 19:12:36 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k51NCZWS017685 for ; Thu, 1 Jun 2006 19:12:35 -0400 Received: from lacrosse.corp.redhat.com (lacrosse.corp.redhat.com [172.16.52.154]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k51NCZpf020363 for ; Thu, 1 Jun 2006 19:12:35 -0400 Received: from [172.16.83.142] (vpn83-142.boston.redhat.com [172.16.83.142]) by lacrosse.corp.redhat.com (8.12.11.20060308/8.11.6) with ESMTP id k51NCXoG026214 for ; Thu, 1 Jun 2006 19:12:33 -0400 From: Matthias Clasen To: gtk-devel-list@gnome.org Content-Type: multipart/mixed; boundary="=-xjDvOKJb0tdB52kmWdgp" Organization: Red Hat Date: Thu, 01 Jun 2006 19:13:59 -0400 Message-Id: <1149203639.27455.9.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.7.2.1 (2.7.2.1-4) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.466 tagged_above=-999 required=2 tests=[AWL=-0.019, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, TW_GT=0.077, TW_XD=0.077] X-Spam-Score: -2.466 X-Spam-Level: Subject: Print preview api X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2006 23:12:39 -0000 --=-xjDvOKJb0tdB52kmWdgp Content-Type: text/plain Content-Transfer-Encoding: 7bit Ok, after a lot of work (mostly by John and Alex), we finally have a proposal for a print preview api that will allow us to use an external viewer by default, but also support internal preview. It consists of the following pieces: 1) GtkPrintOperation gets a new signal gboolean (*preview) (GtkPrintOperation *operation, GtkPrintOperationPreview *preview, GtkPrintContext *context, GtkWindow *parent); This signal is emitted when the user clicks the preview button. It the application does not handle it, the default handler will arrange for the external viewer to be spawned. An application that handles the preview internally should return TRUE from the signal handler. The GtkPrintOperationPreview that is passed to the signal handler lets the application control the preview. 2) The GtkPrintOperationPreview interface has a number of signals: void (*ready) (GtkPrintOperationPreview *preview, GtkPrintContext *context); The ready signal is emitted when pagination is done. The GtkPrintOperation::preview handler should connect to this signal to know when it is safe to start displaying pages. void (*got_page_size) (GtkPrintOperationPreview *preview, GtkPrintContext *context, GtkPageSetup *page_setup); The got-page-size signal is emitted for every rendered page, when the page setup for the page is know. This signal can be used to adjust the cairo context used for rendering the page (e.g. for resizing the preview window). And methods: void gtk_print_operation_preview_render_page (GtkPrintOperationPreview *preview, gint page_nr) Renders the requested page to the cairo context currently set on the print context for the preview. void gtk_print_operation_preview_end_preview (GtkPrintOperationPreview *preview) Must be called to clean up when the preview is finished. 3) A new way of handling the cairo context associated with a GtkPrintContext. A print context is no longer directly associated with a cairo surface. Instead, a cairo context is set with void gtk_print_context_set_cairo_context (GtkPrintContext *context, cairo_t *cr, double dpi_x, double dpi_y); And this can be repeated, typically in a got-page-size handler. The attached patch against current cvs has a very basic preview implementation in print-editor.c that demonstrates this api. Comments appreciated, Matthias --=-xjDvOKJb0tdB52kmWdgp Content-Disposition: attachment; filename=gtk-print-preview-7.diff Content-Type: text/x-patch; name=gtk-print-preview-7.diff; charset=UTF-8 Content-Transfer-Encoding: 7bit Index: gtk/Makefile.am =================================================================== RCS file: /cvs/gnome/gtk+/gtk/Makefile.am,v retrieving revision 1.308 diff -u -p -r1.308 Makefile.am --- gtk/Makefile.am 22 May 2006 17:19:09 -0000 1.308 +++ gtk/Makefile.am 1 Jun 2006 20:34:39 -0000 @@ -4,6 +4,7 @@ SUBDIRS=theme-bits if OS_UNIX SUBDIRS += xdgmime +GTK_PRINT_PREVIEW_COMMAND="evince %f" endif DIST_SUBDIRS=theme-bits xdgmime @@ -25,6 +26,7 @@ INCLUDES = \ -DGTK_HOST=\"$(host)\" \ -DGTK_COMPILATION \ -DGTK_PRINT_BACKENDS=\"$(GTK_PRINT_BACKENDS)\" \ + -DGTK_PRINT_PREVIEW_COMMAND=\"$(GTK_PRINT_PREVIEW_COMMAND)\" \ -I$(top_builddir)/gtk \ -I$(top_srcdir) -I../gdk \ -I$(top_srcdir)/gdk \ @@ -231,6 +233,7 @@ gtk_public_h_sources = \ gtkpreview.h \ gtkprintcontext.h \ gtkprintoperation.h \ + gtkprintoperationpreview.h \ gtkprintsettings.h \ gtkprivate.h \ gtkprogress.h \ @@ -487,6 +490,7 @@ gtk_c_sources = \ gtkpreview.c \ gtkprintcontext.c \ gtkprintoperation.c \ + gtkprintoperationpreview.c \ gtkprintsettings.c \ gtkprintutils.c \ gtkprogress.c \ Index: gtk/gtkmarshalers.list =================================================================== RCS file: /cvs/gnome/gtk+/gtk/gtkmarshalers.list,v retrieving revision 1.67 diff -u -p -r1.67 gtkmarshalers.list --- gtk/gtkmarshalers.list 22 May 2006 17:19:09 -0000 1.67 +++ gtk/gtkmarshalers.list 1 Jun 2006 20:34:39 -0000 @@ -32,6 +32,7 @@ BOOLEAN:OBJECT,INT,INT,UINT BOOLEAN:OBJECT,STRING,STRING,BOXED BOOLEAN:OBJECT,BOXED BOOLEAN:OBJECT,BOXED,BOXED +BOOLEAN:OBJECT,OBJECT,OBJECT BOOLEAN:OBJECT,STRING,STRING BOOLEAN:INT BOOLEAN:INT,INT Index: gtk/gtkprintbackend.c =================================================================== RCS file: /cvs/gnome/gtk+/gtk/gtkprintbackend.c,v retrieving revision 1.7 diff -u -p -r1.7 gtkprintbackend.c --- gtk/gtkprintbackend.c 1 Jun 2006 05:02:56 -0000 1.7 +++ gtk/gtkprintbackend.c 1 Jun 2006 20:34:39 -0000 @@ -200,7 +200,6 @@ _gtk_print_backend_create (const char *b GtkPrintBackendModule *pb_module; GtkPrintBackend *pb; - /* TODO: make module loading code work */ for (l = loaded_backends; l != NULL; l = l->next) { pb_module = l->data; @@ -255,6 +254,11 @@ gtk_print_backend_initialize (void) GTK_PRINT_BACKENDS, GTK_PARAM_READWRITE)); + gtk_settings_install_property (g_param_spec_string ("gtk-print-preview-command", + P_("Default command to run when displaying a print preview"), + P_("Command to run when displaying a print preview"), + GTK_PRINT_PREVIEW_COMMAND, + GTK_PARAM_READWRITE)); initialized = TRUE; } } Index: gtk/gtkprintbackend.h =================================================================== RCS file: /cvs/gnome/gtk+/gtk/gtkprintbackend.h,v retrieving revision 1.8 diff -u -p -r1.8 gtkprintbackend.h --- gtk/gtkprintbackend.h 24 May 2006 10:50:56 -0000 1.8 +++ gtk/gtkprintbackend.h 1 Jun 2006 20:34:39 -0000 @@ -140,6 +140,9 @@ void gtk_print_backend_print_stre GList * gtk_print_backend_load_modules (void); void gtk_print_backend_destroy (GtkPrintBackend *print_backend); +/* Methods private to gtk */ +GtkPrintBackend * _gtk_print_backend_create (const char *backend_name); + /* Backend-only functions for GtkPrintBackend */ void gtk_print_backend_add_printer (GtkPrintBackend *print_backend, Index: gtk/gtkprintcontext.c =================================================================== RCS file: /cvs/gnome/gtk+/gtk/gtkprintcontext.c,v retrieving revision 1.4 diff -u -p -r1.4 gtkprintcontext.c --- gtk/gtkprintcontext.c 31 May 2006 13:38:10 -0000 1.4 +++ gtk/gtkprintcontext.c 1 Jun 2006 20:34:39 -0000 @@ -40,6 +40,9 @@ struct _GtkPrintContext GtkPageSetup *page_setup; PangoFontMap *fontmap; + gdouble surface_dpi_x; + gdouble surface_dpi_y; + gdouble pixels_per_unit_x; gdouble pixels_per_unit_y; }; @@ -60,8 +63,8 @@ gtk_print_context_finalize (GObject *obj if (context->page_setup) g_object_unref (context->page_setup); - cairo_destroy (context->cr); - + if (context->cr) + cairo_destroy (context->cr); G_OBJECT_CLASS (gtk_print_context_parent_class)->finalize (object); } @@ -83,15 +86,31 @@ gtk_print_context_class_init (GtkPrintCo GtkPrintContext * _gtk_print_context_new (GtkPrintOperation *op) { - GtkPrintOperationPrivate *priv = op->priv; GtkPrintContext *context; context = g_object_new (GTK_TYPE_PRINT_CONTEXT, NULL); context->op = op; - context->cr = cairo_create (priv->surface); + context->cr = NULL; + context->fontmap = pango_cairo_font_map_new (); + + return context; +} + +void +gtk_print_context_set_cairo_context (GtkPrintContext *context, + cairo_t *cr, + double dpi_x, + double dpi_y) +{ + if (context->cr) + cairo_destroy (context->cr); + + context->cr = cairo_reference (cr); + context->surface_dpi_x = dpi_x; + context->surface_dpi_y = dpi_y; - switch (priv->unit) + switch (context->op->priv->unit) { default: case GTK_UNIT_PIXEL: @@ -100,34 +119,31 @@ _gtk_print_context_new (GtkPrintOperatio context->pixels_per_unit_y = 1.0; break; case GTK_UNIT_POINTS: - context->pixels_per_unit_x = priv->dpi_x / POINTS_PER_INCH; - context->pixels_per_unit_y = priv->dpi_y / POINTS_PER_INCH; + context->pixels_per_unit_x = dpi_x / POINTS_PER_INCH; + context->pixels_per_unit_y = dpi_y / POINTS_PER_INCH; break; case GTK_UNIT_INCH: - context->pixels_per_unit_x = priv->dpi_x; - context->pixels_per_unit_y = priv->dpi_y; + context->pixels_per_unit_x = dpi_x; + context->pixels_per_unit_y = dpi_y; break; case GTK_UNIT_MM: - context->pixels_per_unit_x = priv->dpi_x / MM_PER_INCH; - context->pixels_per_unit_y = priv->dpi_y / MM_PER_INCH; + context->pixels_per_unit_x = dpi_x / MM_PER_INCH; + context->pixels_per_unit_y = dpi_y / MM_PER_INCH; break; } cairo_scale (context->cr, context->pixels_per_unit_x, context->pixels_per_unit_y); - context->fontmap = pango_cairo_font_map_new (); /* We use the unit-scaled resolution, as we still want fonts given in points to work */ pango_cairo_font_map_set_resolution (PANGO_CAIRO_FONT_MAP (context->fontmap), - priv->dpi_y / context->pixels_per_unit_y); - - return context; + dpi_y / context->pixels_per_unit_y); } + void _gtk_print_context_rotate_according_to_orientation (GtkPrintContext *context) { - GtkPrintOperationPrivate *priv = context->op->priv; cairo_t *cr = context->cr; cairo_matrix_t matrix; GtkPaperSize *paper_size; @@ -136,9 +152,9 @@ _gtk_print_context_rotate_according_to_o paper_size = gtk_page_setup_get_paper_size (context->page_setup); width = gtk_paper_size_get_width (paper_size, GTK_UNIT_INCH); - width = width * priv->dpi_x / context->pixels_per_unit_x; + width = width * context->surface_dpi_x / context->pixels_per_unit_x; height = gtk_paper_size_get_height (paper_size, GTK_UNIT_INCH); - height = height * priv->dpi_y / context->pixels_per_unit_y; + height = height * context->surface_dpi_y / context->pixels_per_unit_y; switch (gtk_page_setup_get_orientation (context->page_setup)) { @@ -188,8 +204,8 @@ _gtk_print_context_translate_into_margin top = gtk_page_setup_get_top_margin (context->page_setup, GTK_UNIT_INCH); cairo_translate (context->cr, - left * priv->dpi_x / context->pixels_per_unit_x, - top * priv->dpi_y / context->pixels_per_unit_y); + left * context->surface_dpi_x / context->pixels_per_unit_x, + top * context->surface_dpi_y / context->pixels_per_unit_y); } void @@ -272,7 +288,7 @@ gtk_print_context_get_width (GtkPrintCon width = gtk_page_setup_get_page_width (context->page_setup, GTK_UNIT_INCH); /* Really dpi_x? What about landscape? what does dpi_x mean in that case? */ - return width * priv->dpi_x / context->pixels_per_unit_x; + return width * context->surface_dpi_x / context->pixels_per_unit_x; } /** @@ -300,8 +316,8 @@ gtk_print_context_get_height (GtkPrintCo else height = gtk_page_setup_get_page_height (context->page_setup, GTK_UNIT_INCH); - /* Really dpi_x? What about landscape? what does dpi_x mean in that case? */ - return height * priv->dpi_y / context->pixels_per_unit_y; + /* Really dpi_y? What about landscape? what does dpi_y mean in that case? */ + return height * context->surface_dpi_y / context->pixels_per_unit_y; } /** @@ -320,7 +336,7 @@ gtk_print_context_get_dpi_x (GtkPrintCon { g_return_val_if_fail (GTK_IS_PRINT_CONTEXT (context), 0); - return context->op->priv->dpi_x; + return context->surface_dpi_x; } /** @@ -339,7 +355,7 @@ gtk_print_context_get_dpi_y (GtkPrintCon { g_return_val_if_fail (GTK_IS_PRINT_CONTEXT (context), 0); - return context->op->priv->dpi_y; + return context->surface_dpi_y; } /** @@ -376,10 +392,16 @@ PangoContext * gtk_print_context_create_pango_context (GtkPrintContext *context) { PangoContext *pango_context; + cairo_font_options_t *options; g_return_val_if_fail (GTK_IS_PRINT_CONTEXT (context), NULL); pango_context = pango_cairo_font_map_create_context (PANGO_CAIRO_FONT_MAP (context->fontmap)); + + options = cairo_font_options_create (); + cairo_font_options_set_hint_metrics (options, CAIRO_HINT_METRICS_OFF); + pango_cairo_context_set_font_options (pango_context, options); + cairo_font_options_destroy (options); return pango_context; } Index: gtk/gtkprintcontext.h =================================================================== RCS file: /cvs/gnome/gtk+/gtk/gtkprintcontext.h,v retrieving revision 1.3 diff -u -p -r1.3 gtkprintcontext.h --- gtk/gtkprintcontext.h 31 May 2006 13:38:10 -0000 1.3 +++ gtk/gtkprintcontext.h 1 Jun 2006 20:34:39 -0000 @@ -51,6 +51,11 @@ PangoFontMap *gtk_print_context_get_pang PangoContext *gtk_print_context_create_pango_context (GtkPrintContext *context); PangoLayout *gtk_print_context_create_pango_layout (GtkPrintContext *context); +/* Needed for preview implementations */ +void gtk_print_context_set_cairo_context (GtkPrintContext *context, + cairo_t *cr, + double dpi_x, + double dpi_y); G_END_DECLS Index: gtk/gtkprintjob.c =================================================================== RCS file: /cvs/gnome/gtk+/gtk/gtkprintjob.c,v retrieving revision 1.8 diff -u -p -r1.8 gtkprintjob.c --- gtk/gtkprintjob.c 16 May 2006 16:13:48 -0000 1.8 +++ gtk/gtkprintjob.c 1 Jun 2006 20:34:39 -0000 @@ -212,14 +212,14 @@ gtk_print_job_constructor (GType job = GTK_PRINT_JOB (object); priv = job->priv; - g_assert (priv->printer_set && - priv->settings_set && + g_assert (priv->settings_set && priv->page_setup_set); - - _gtk_printer_prepare_for_print (priv->printer, - job, - priv->settings, - priv->page_setup); + + if (priv->printer) + _gtk_printer_prepare_for_print (priv->printer, + job, + priv->settings, + priv->page_setup); return object; } @@ -545,8 +545,12 @@ gtk_print_job_set_property (GObject case GTK_PRINT_JOB_PROP_PRINTER: priv->printer = GTK_PRINTER (g_value_dup_object (value)); - priv->printer_set = TRUE; - priv->backend = g_object_ref (gtk_printer_get_backend (priv->printer)); + + if (priv->printer != NULL) + { + priv->printer_set = TRUE; + priv->backend = g_object_ref (gtk_printer_get_backend (priv->printer)); + } break; case GTK_PRINT_JOB_PROP_PAGE_SETUP: Index: gtk/gtkprintoperation-private.h =================================================================== RCS file: /cvs/gnome/gtk+/gtk/gtkprintoperation-private.h,v retrieving revision 1.11 diff -u -p -r1.11 gtkprintoperation-private.h --- gtk/gtkprintoperation-private.h 1 Jun 2006 12:38:07 -0000 1.11 +++ gtk/gtkprintoperation-private.h 1 Jun 2006 20:34:39 -0000 @@ -46,9 +46,11 @@ struct _GtkPrintOperationPrivate guint print_pages_idle_id; guint show_progress_timeout_id; + GtkPrintContext *print_context; + /* Data for the print job: */ - cairo_surface_t *surface; - gdouble dpi_x, dpi_y; + /* cairo_surface_t *surface; */ + /* gdouble dpi_x, dpi_y; */ GtkPrintPages print_pages; GtkPageRange *page_ranges; @@ -84,11 +86,23 @@ GtkPrintOperationResult _gtk_print_opera GError **error); typedef void (* GtkPrintOperationPrintFunc) (GtkPrintOperation *op, - GtkWindow *parent); + GtkWindow *parent, + gboolean is_preview); void _gtk_print_operation_platform_backend_run_dialog_async (GtkPrintOperation *op, GtkWindow *parent, GtkPrintOperationPrintFunc print_cb); + +void _gtk_print_operation_platform_backend_launch_preview (GtkPrintOperation *op, + GtkWindow *parent, + const char *filename); + +cairo_surface_t *_gtk_print_operation_platform_backend_create_preview_surface (GtkPrintOperation *operation, + gdouble width, + gdouble heigh, + gdouble *dpi_x, + gdouble *dpi_y, + const gchar *target); void _gtk_print_operation_set_status (GtkPrintOperation *op, GtkPrintStatus status, Index: gtk/gtkprintoperation-unix.c =================================================================== RCS file: /cvs/gnome/gtk+/gtk/gtkprintoperation-unix.c,v retrieving revision 1.19 diff -u -p -r1.19 gtkprintoperation-unix.c --- gtk/gtkprintoperation-unix.c 1 Jun 2006 12:38:07 -0000 1.19 +++ gtk/gtkprintoperation-unix.c 1 Jun 2006 20:34:39 -0000 @@ -25,6 +25,9 @@ #include #include #include +#include +#include +#include #include "gtkprintoperation-private.h" #include "gtkmarshal.h" @@ -41,13 +44,17 @@ #include "gtkalias.h" #include "gtkintl.h" - typedef struct { - GtkPrintJob *job; /* the job we are sending to the printer */ - gulong job_status_changed_tag; GtkWindow *parent; /* just in case we need to throw error dialogs */ GMainLoop *loop; gboolean data_sent; + + /* Real printing (not preview: */ + GtkPrintJob *job; /* the job we are sending to the printer */ + cairo_surface_t *surface; + gulong job_status_changed_tag; + + } GtkPrintOperationUnix; typedef struct _PrinterFinder PrinterFinder; @@ -62,21 +69,24 @@ unix_start_page (GtkPrintOperation *op, GtkPrintContext *print_context, GtkPageSetup *page_setup) { + GtkPrintOperationUnix *op_unix; GtkPaperSize *paper_size; cairo_surface_type_t type; double w, h; + op_unix = op->priv->platform_data; + paper_size = gtk_page_setup_get_paper_size (page_setup); w = gtk_paper_size_get_width (paper_size, GTK_UNIT_POINTS); h = gtk_paper_size_get_height (paper_size, GTK_UNIT_POINTS); - type = cairo_surface_get_type (op->priv->surface); + type = cairo_surface_get_type (op_unix->surface); if (type == CAIRO_SURFACE_TYPE_PS) - cairo_ps_surface_set_size (op->priv->surface, w, h); + cairo_ps_surface_set_size (op_unix->surface, w, h); else if (type == CAIRO_SURFACE_TYPE_PDF) - cairo_pdf_surface_set_size (op->priv->surface, w, h); + cairo_pdf_surface_set_size (op_unix->surface, w, h); } static void @@ -102,6 +112,112 @@ op_unix_free (GtkPrintOperationUnix *op_ g_free (op_unix); } +static char * +shell_command_substitute_file (const gchar *cmd, + const gchar *filename) +{ + const char *inptr, *start; + char *result; + GString *final; + + g_return_val_if_fail (cmd != NULL, NULL); + g_return_val_if_fail (filename != NULL, NULL); + + result = NULL; + final = g_string_new (NULL); + + start = inptr = cmd; + + while ((inptr = strchr (inptr, '%')) != NULL) + { + g_string_append_len (final, start, inptr - start); + inptr++; + switch (*inptr) + { + case 'f': + g_string_append (final, filename ? filename : ""); + break; + + case '%': + g_string_append_c (final, '%'); + break; + + default: + g_string_append_c (final, '%'); + if (*inptr) + g_string_append_c (final, *inptr); + break; + } + if (*inptr) + inptr++; + start = inptr; + } + g_string_append (final, start); + + result = final->str; + + g_string_free (final, FALSE); + + return result; +} + +void +_gtk_print_operation_platform_backend_launch_preview (GtkPrintOperation *op, + GtkWindow *parent, + const char *filename) +{ + int argc; + gchar **argv; + gchar *cmd; + gchar *preview_cmd; + GtkSettings *settings; + gchar *quoted_filename; + GdkScreen *screen; + GError *error = NULL; + + settings = gtk_settings_get_default (); + g_object_get (settings, "gtk-print-preview-command", &preview_cmd, NULL); + + quoted_filename = g_shell_quote (filename); + cmd = shell_command_substitute_file (preview_cmd, quoted_filename); + g_shell_parse_argv (cmd, &argc, &argv, &error); + + if (error !=NULL) + goto out; + + if (parent) + screen = gtk_window_get_screen (parent); + else + screen = gdk_screen_get_default (); + + gdk_spawn_on_screen (screen, NULL, argv, NULL, G_SPAWN_SEARCH_PATH, NULL, NULL, NULL, &error); + + out: + if (error != NULL) + { + GtkWidget *edialog; + edialog = gtk_message_dialog_new (parent, + GTK_DIALOG_DESTROY_WITH_PARENT, + GTK_MESSAGE_ERROR, + GTK_BUTTONS_CLOSE, + _("Error launching preview") /* FIXME better text */); + gtk_message_dialog_format_secondary_text (GTK_MESSAGE_DIALOG (edialog), + "%s", error->message); + gtk_window_set_modal (GTK_WINDOW (edialog), TRUE); + g_signal_connect (edialog, "response", + G_CALLBACK (gtk_widget_destroy), NULL); + + gtk_window_present (GTK_WINDOW (edialog)); + + g_error_free (error); + } + + g_free (cmd); + g_free (quoted_filename); + g_free (preview_cmd); + g_strfreev (argv); +} + static void unix_finish_send (GtkPrintJob *job, void *user_data, @@ -129,6 +245,7 @@ unix_finish_send (GtkPrintJob *job, } op_unix->data_sent = TRUE; + if (op_unix->loop) g_main_loop_quit (op_unix->loop); } @@ -140,6 +257,8 @@ unix_end_run (GtkPrintOperation *op, { GtkPrintOperationUnix *op_unix = op->priv->platform_data; + cairo_surface_finish (op_unix->surface); + if (cancelled) return; @@ -147,10 +266,11 @@ unix_end_run (GtkPrintOperation *op, op_unix->loop = g_main_loop_new (NULL, FALSE); /* TODO: Check for error */ - gtk_print_job_send (op_unix->job, - unix_finish_send, - op_unix, NULL, - NULL); + if (op_unix->job != NULL) + gtk_print_job_send (op_unix->job, + unix_finish_send, + op_unix, NULL, + NULL); if (wait) { @@ -253,64 +373,66 @@ finish_print (PrintResponseData *rdata, { GtkPrintOperation *op = rdata->op; GtkPrintOperationPrivate *priv = op->priv; + gboolean is_preview; - priv->start_page = unix_start_page; - priv->end_page = unix_end_page; - priv->end_run = unix_end_run; + g_print ("finish_print\n"); + + is_preview = rdata->result == GTK_PRINT_OPERATION_RESULT_PREVIEW; if (rdata->do_print) { - GtkPrintOperationUnix *op_unix; - gtk_print_operation_set_print_settings (op, settings); - - op_unix = g_new0 (GtkPrintOperationUnix, 1); - op_unix->job = gtk_print_job_new (priv->job_name, - printer, - settings, - page_setup); + op->priv->print_context = _gtk_print_context_new (op); - gtk_print_job_set_track_print_status (op_unix->job, priv->track_print_status); - - rdata->op->priv->surface = gtk_print_job_get_surface (op_unix->job, rdata->error); - if (op->priv->surface == NULL) + if (!is_preview) { - rdata->do_print = FALSE; - op_unix_free (op_unix); - rdata->result = GTK_PRINT_OPERATION_RESULT_ERROR; - goto out; - } - - _gtk_print_operation_set_status (op, gtk_print_job_get_status (op_unix->job), NULL); - op_unix->job_status_changed_tag = - g_signal_connect (op_unix->job, "status-changed", - G_CALLBACK (job_status_changed_cb), op); - - op_unix->parent = rdata->parent; - - priv->dpi_x = 72; - priv->dpi_y = 72; - - priv->platform_data = op_unix; - priv->free_platform_data = (GDestroyNotify) op_unix_free; - - priv->print_pages = op_unix->job->print_pages; - priv->page_ranges = op_unix->job->page_ranges; - priv->num_page_ranges = op_unix->job->num_page_ranges; - - priv->manual_num_copies = op_unix->job->num_copies; - priv->manual_collation = op_unix->job->collate; - priv->manual_reverse = op_unix->job->reverse; - priv->manual_page_set = op_unix->job->page_set; - priv->manual_scale = op_unix->job->scale; - priv->manual_orientation = op_unix->job->rotate_to_orientation; + GtkPrintOperationUnix *op_unix; + cairo_t *cr; + + op_unix = g_new0 (GtkPrintOperationUnix, 1); + priv->platform_data = op_unix; + priv->free_platform_data = (GDestroyNotify) op_unix_free; + op_unix->parent = rdata->parent; + + priv->start_page = unix_start_page; + priv->end_page = unix_end_page; + priv->end_run = unix_end_run; + + op_unix->job = gtk_print_job_new (priv->job_name, + printer, + settings, + page_setup); + gtk_print_job_set_track_print_status (op_unix->job, priv->track_print_status); + /* TODO: handle error */ + op_unix->surface = gtk_print_job_get_surface (op_unix->job, rdata->error); + cr = cairo_create (op_unix->surface); + gtk_print_context_set_cairo_context (op->priv->print_context, + cr, 72, 72); + cairo_destroy (cr); + + _gtk_print_operation_set_status (op, gtk_print_job_get_status (op_unix->job), NULL); + + op_unix->job_status_changed_tag = + g_signal_connect (op_unix->job, "status-changed", + G_CALLBACK (job_status_changed_cb), op); + + priv->print_pages = op_unix->job->print_pages; + priv->page_ranges = op_unix->job->page_ranges; + priv->num_page_ranges = op_unix->job->num_page_ranges; + + priv->manual_num_copies = op_unix->job->num_copies; + priv->manual_collation = op_unix->job->collate; + priv->manual_reverse = op_unix->job->reverse; + priv->manual_page_set = op_unix->job->page_set; + priv->manual_scale = op_unix->job->scale; + priv->manual_orientation = op_unix->job->rotate_to_orientation; + } } - - out: + if (rdata->print_cb) { if (rdata->do_print) - rdata->print_cb (op, rdata->parent); + rdata->print_cb (op, rdata->parent, is_preview); else _gtk_print_operation_set_status (op, GTK_PRINT_STATUS_FINISHED_ABORTED, NULL); } @@ -319,7 +441,7 @@ finish_print (PrintResponseData *rdata, rdata->destroy (rdata); } -static void +static void handle_print_response (GtkWidget *dialog, gint response, gpointer data) @@ -330,6 +452,8 @@ handle_print_response (GtkWidget *dialog GtkPageSetup *page_setup = NULL; GtkPrinter *printer = NULL; + g_print ("handle_print_response\n"); + if (response == GTK_RESPONSE_OK) { rdata->result = GTK_PRINT_OPERATION_RESULT_APPLY; @@ -345,14 +469,24 @@ handle_print_response (GtkWidget *dialog g_signal_emit_by_name (rdata->op, "custom-widget-apply", rdata->op->priv->custom_widget); } + else if (response == GTK_RESPONSE_APPLY) + { + /* print preview */ + rdata->result = GTK_PRINT_OPERATION_RESULT_PREVIEW; + rdata->do_print = TRUE; + settings = gtk_print_unix_dialog_get_settings (GTK_PRINT_UNIX_DIALOG (pd)); + page_setup = gtk_print_unix_dialog_get_page_setup (GTK_PRINT_UNIX_DIALOG (pd)); + } + out: finish_print (rdata, printer, page_setup, settings); if (settings) g_object_unref (settings); - + gtk_widget_destroy (GTK_WIDGET (pd)); + } @@ -436,6 +570,19 @@ _gtk_print_operation_platform_backend_ru } } +cairo_surface_t * +_gtk_print_operation_platform_backend_create_preview_surface (GtkPrintOperation *op, + gdouble width, + gdouble height, + gdouble *dpi_x, + gdouble *dpi_y, + const gchar *target) +{ + g_print ("pdf surface size: %f x %f\n", width, height); + *dpi_x = *dpi_y = 72; + return cairo_pdf_surface_create (target, width, height); +} + GtkPrintOperationResult _gtk_print_operation_platform_backend_run_dialog (GtkPrintOperation *op, GtkWindow *parent, @@ -459,6 +606,7 @@ _gtk_print_operation_platform_backend_ru if (op->priv->show_dialog) { pd = get_print_dialog (op, parent); + response = gtk_dialog_run (GTK_DIALOG (pd)); handle_print_response (pd, response, &rdata); } Index: gtk/gtkprintoperation-win32.c =================================================================== RCS file: /cvs/gnome/gtk+/gtk/gtkprintoperation-win32.c,v retrieving revision 1.9 diff -u -p -r1.9 gtkprintoperation-win32.c --- gtk/gtkprintoperation-win32.c 23 May 2006 16:30:45 -0000 1.9 +++ gtk/gtkprintoperation-win32.c 1 Jun 2006 20:34:39 -0000 @@ -492,6 +492,7 @@ win32_end_run (GtkPrintOperation *op, GlobalFree(op_win32->devmode); GlobalFree(op_win32->devnames); + cairo_surface_finish (op->priv->surface); cairo_surface_destroy (op->priv->surface); op->priv->surface = NULL; Index: gtk/gtkprintoperation.c =================================================================== RCS file: /cvs/gnome/gtk+/gtk/gtkprintoperation.c,v retrieving revision 1.24 diff -u -p -r1.24 gtkprintoperation.c --- gtk/gtkprintoperation.c 1 Jun 2006 12:38:07 -0000 1.24 +++ gtk/gtkprintoperation.c 1 Jun 2006 20:34:39 -0000 @@ -19,6 +19,10 @@ */ #include "config.h" + +#include +#include + #include #include "gtkprintoperation-private.h" #include "gtkmarshalers.h" @@ -41,6 +45,7 @@ enum { STATUS_CHANGED, CREATE_CUSTOM_WIDGET, CUSTOM_WIDGET_APPLY, + PREVIEW, LAST_SIGNAL }; @@ -65,7 +70,15 @@ enum { static guint signals[LAST_SIGNAL] = { 0 }; static int job_nr = 0; -G_DEFINE_TYPE (GtkPrintOperation, gtk_print_operation, G_TYPE_OBJECT) +static void preview_iface_init (GtkPrintOperationPreviewIface *iface); +static GtkPageSetup *create_page_setup (GtkPrintOperation *op); +static void common_render_page (GtkPrintOperation *op, + gint page_nr); + + +G_DEFINE_TYPE_WITH_CODE (GtkPrintOperation, gtk_print_operation, G_TYPE_OBJECT, + G_IMPLEMENT_INTERFACE (GTK_TYPE_PRINT_OPERATION_PREVIEW, + preview_iface_init)) /** * gtk_print_error_quark: @@ -146,6 +159,60 @@ gtk_print_operation_init (GtkPrintOperat } static void +preview_iface_render_page (GtkPrintOperationPreview *preview, + gint page_nr) +{ + GtkPrintOperation *op; + + op = GTK_PRINT_OPERATION (preview); + common_render_page (op, page_nr); +} + +static void +preview_iface_end_preview (GtkPrintOperationPreview *preview) +{ + GtkPrintOperation *op; + + op = GTK_PRINT_OPERATION (preview); + + g_signal_emit (op, signals[END_PRINT], 0, op->priv->print_context); + + if (op->priv->rloop) + g_main_loop_quit (op->priv->rloop); + + op->priv->end_run (op, op->priv->is_sync, TRUE); +} + +static void +preview_iface_init (GtkPrintOperationPreviewIface *iface) +{ + iface->render_page = preview_iface_render_page; + iface->end_preview = preview_iface_end_preview; +} + +static void +preview_start_page (GtkPrintOperation *op, + GtkPrintContext *print_context, + GtkPageSetup *page_setup) +{ + g_signal_emit_by_name (op, "got-page-size",print_context, page_setup); +} + +static void +preview_end_page (GtkPrintOperation *op, + GtkPrintContext *print_context) +{ +} + +static void +preview_end_run (GtkPrintOperation *op, + gboolean wait, + gboolean cancelled) +{ +} + + +static void gtk_print_operation_set_property (GObject *object, guint prop_id, const GValue *value, @@ -256,6 +323,158 @@ gtk_print_operation_get_property (GObjec } } +typedef struct +{ + GtkPrintOperationPreview *preview; + GtkPrintContext *print_context; + GtkWindow *parent; + cairo_surface_t *surface; + gchar *filename; + guint page_nr; + gboolean wait; +} PreviewOp; + +static void +preview_print_idle_done (gpointer data) +{ + GtkPrintOperation *op; + PreviewOp *pop = (PreviewOp *) data; + + op = GTK_PRINT_OPERATION (pop->preview); + + _gtk_print_operation_platform_backend_launch_preview (op, + pop->parent, + pop->filename); + + g_free (pop->filename); + cairo_surface_finish (pop->surface); + cairo_surface_destroy (pop->surface); + + gtk_print_operation_preview_end_preview (pop->preview); + g_free (pop); +} + +static gboolean +preview_print_idle (gpointer data) +{ + PreviewOp *pop; + GtkPrintOperation *op; + gboolean retval = TRUE; + cairo_t *cr; + + GDK_THREADS_ENTER (); + + pop = (PreviewOp *) data; + op = GTK_PRINT_OPERATION (pop->preview); + + gtk_print_operation_preview_render_page (pop->preview, pop->page_nr); + + cr = gtk_print_context_get_cairo_context (pop->print_context); + cairo_show_page (cr); + + /* TODO: print out sheets not pages and follow ranges */ + pop->page_nr++; + if (op->priv->nr_of_pages <= pop->page_nr) + retval = FALSE; + + GDK_THREADS_LEAVE (); + + return retval; +} + +static void +preview_got_page_size (GtkPrintOperationPreview *preview, + GtkPrintContext *context, + GtkPageSetup *page_setup, + PreviewOp *pop) +{ + GtkPrintOperation *op = GTK_PRINT_OPERATION (preview); + GtkPaperSize *paper_size; + double w, h; + + paper_size = gtk_page_setup_get_paper_size (page_setup); + + w = gtk_paper_size_get_width (paper_size, GTK_UNIT_POINTS); + h = gtk_paper_size_get_height (paper_size, GTK_UNIT_POINTS); + + /* TODO: don't hardcode pdf */ + cairo_pdf_surface_set_size (pop->surface, w, h); +} + +static void +preview_ready (GtkPrintOperationPreview *preview, + GtkPrintContext *context, + PreviewOp *pop) +{ + + pop->page_nr = 0; + pop->print_context = context; + + g_idle_add_full (G_PRIORITY_DEFAULT_IDLE, + preview_print_idle, + pop, + preview_print_idle_done); + +} + +/** + * gtk_print_operation_preview_handler: + * + * Default handler for preview operations + **/ +static gboolean +gtk_print_operation_preview_handler (GtkPrintOperation *op, + GtkPrintOperationPreview *preview, + GtkPrintContext *context, + GtkWindow *parent) +{ + gdouble width, height, dpi_x, dpi_y; + gchar *tmp_dir; + gchar *dir_template; + gchar *preview_filename; + PreviewOp *pop; + GtkPrintSettings *settings; + cairo_t *cr; + + dir_template = g_build_filename (g_get_tmp_dir (), "print-preview-XXXXXX", NULL); + + /* use temp dirs because apps like evince need to have extentions + to determine the mine type */ + tmp_dir = mkdtemp(dir_template); + + preview_filename = g_build_filename (tmp_dir, + "Print Preview.pdf", + NULL); + + g_free (dir_template); + + pop = g_new0 (PreviewOp, 1); + pop->filename = preview_filename; + pop->preview = preview; + pop->parent = parent; + + settings = op->priv->print_settings; + + width = gtk_print_settings_get_paper_width (settings, GTK_UNIT_POINTS); + height = gtk_print_settings_get_paper_height (settings, GTK_UNIT_POINTS); + + pop->surface = + _gtk_print_operation_platform_backend_create_preview_surface (op, + width, height, + &dpi_x, &dpi_y, + pop->filename); + + cr = cairo_create (pop->surface); + gtk_print_context_set_cairo_context (op->priv->print_context, cr, + dpi_x, dpi_y); + cairo_destroy (cr); + + g_signal_connect (preview, "ready", (GCallback) preview_ready, pop); + g_signal_connect (preview, "got-page-size", (GCallback) preview_got_page_size, pop); + + return TRUE; +} + static GtkWidget * gtk_print_operation_create_custom_widget (GtkPrintOperation *operation) { @@ -287,7 +506,8 @@ gtk_print_operation_class_init (GtkPrint gobject_class->set_property = gtk_print_operation_set_property; gobject_class->get_property = gtk_print_operation_get_property; gobject_class->finalize = gtk_print_operation_finalize; - + + class->preview = gtk_print_operation_preview_handler; class->create_custom_widget = gtk_print_operation_create_custom_widget; g_type_class_add_private (gobject_class, sizeof (GtkPrintOperationPrivate)); @@ -530,6 +750,33 @@ gtk_print_operation_class_init (GtkPrint g_cclosure_marshal_VOID__OBJECT, G_TYPE_NONE, 1, GTK_TYPE_WIDGET); + /** + * GtkPrintOperation::preview: + * @operation: the #GtkPrintOperation on which the signal was emitted + * @preview: the #GtkPrintPreviewOperation for the current operation + * @context: the #GtkPrintContext that will be used + * @parent: the #GtkWindow to use as window parent, or NULL + * + * Gets emitted when a preview is requested from the native dialog. + * If you handle this you must set the cairo_context on the printing context. + * + * Returns: #TRUE if the listener wants to take over control of the preview + * + * Since: 2.10 + */ + signals[PREVIEW] = + g_signal_new (I_("preview"), + G_TYPE_FROM_CLASS (gobject_class), + G_SIGNAL_RUN_LAST, + G_STRUCT_OFFSET (GtkPrintOperationClass, preview), + _gtk_boolean_handled_accumulator, NULL, + _gtk_marshal_BOOLEAN__OBJECT_OBJECT_OBJECT, + G_TYPE_BOOLEAN, 3, + GTK_TYPE_PRINT_OPERATION_PREVIEW, + GTK_TYPE_PRINT_CONTEXT, + GTK_TYPE_WINDOW); + + /** * GtkPrintOperation:default-page-setup: * @@ -1436,6 +1683,7 @@ pdf_start_page (GtkPrintOperation *op, GtkPageSetup *page_setup) { GtkPaperSize *paper_size; + cairo_surface_t *surface = op->priv->platform_data; double w, h; paper_size = gtk_page_setup_get_paper_size (page_setup); @@ -1443,7 +1691,7 @@ pdf_start_page (GtkPrintOperation *op, w = gtk_paper_size_get_width (paper_size, GTK_UNIT_POINTS); h = gtk_paper_size_get_height (paper_size, GTK_UNIT_POINTS); - cairo_pdf_surface_set_size (op->priv->surface, w, h); + cairo_pdf_surface_set_size (surface, w, h); } static void @@ -1462,9 +1710,10 @@ pdf_end_run (GtkPrintOperation *op, gboolean cancelled) { GtkPrintOperationPrivate *priv = op->priv; + cairo_surface_t *surface = priv->platform_data; - cairo_surface_destroy (priv->surface); - priv->surface = NULL; + cairo_surface_finish (surface); + cairo_surface_destroy (surface); } static GtkPrintOperationResult @@ -1475,6 +1724,8 @@ run_pdf (GtkPrintOperation *op, { GtkPrintOperationPrivate *priv = op->priv; GtkPageSetup *page_setup; + cairo_surface_t *surface; + cairo_t *cr; double width, height; /* This will be overwritten later by the non-default size, but we need to pass some size: */ @@ -1484,13 +1735,19 @@ run_pdf (GtkPrintOperation *op, height = gtk_page_setup_get_paper_height (page_setup, GTK_UNIT_POINTS); g_object_unref (page_setup); - priv->surface = cairo_pdf_surface_create (priv->pdf_target, + surface = cairo_pdf_surface_create (priv->pdf_target, width, height); - cairo_pdf_surface_set_dpi (priv->surface, 300, 300); - - priv->dpi_x = 72; - priv->dpi_y = 72; + cairo_pdf_surface_set_dpi (surface, 300, 300); + + priv->platform_data = surface; + priv->free_platform_data = (GDestroyNotify) cairo_surface_destroy; + cr = cairo_create (surface); + gtk_print_context_set_cairo_context (op->priv->print_context, + cr, 72, 72); + cairo_destroy (cr); + + priv->print_pages = GTK_PRINT_PAGES_ALL; priv->page_ranges = NULL; priv->num_page_ranges = 0; @@ -1524,10 +1781,11 @@ typedef struct gint page, start, end, inc; - GtkPageSetup *initial_page_setup; - GtkPrintContext *print_context; + gboolean initialized; GtkWidget *progress; + + gboolean is_preview; } PrintPagesData; static void @@ -1599,12 +1857,9 @@ print_pages_idle_done (gpointer user_dat if (data->progress) gtk_widget_destroy (data->progress); - g_object_unref (data->print_context); - g_object_unref (data->initial_page_setup); - g_object_unref (data->op); - if (priv->rloop) + if (priv->rloop && !data->is_preview) g_main_loop_quit (priv->rloop); g_free (data); @@ -1640,15 +1895,62 @@ update_progress (PrintPagesData *data) } } +static void +common_render_page (GtkPrintOperation *op, + gint page_nr) +{ + GtkPrintOperationPrivate *priv = op->priv; + GtkPageSetup *page_setup; + GtkPrintContext *print_context; + cairo_t *cr; + + print_context = priv->print_context; + + page_setup = create_page_setup (op); + + g_signal_emit (op, signals[REQUEST_PAGE_SETUP], 0, + print_context, page_nr, page_setup); + + _gtk_print_context_set_page_setup (print_context, page_setup); + + /* TODO: override for preview */ + priv->start_page (op, print_context, page_setup); + + cr = gtk_print_context_get_cairo_context (print_context); + + cairo_save (cr); + if (priv->manual_scale != 1.0) + cairo_scale (cr, + priv->manual_scale, + priv->manual_scale); + + if (priv->manual_orientation) + _gtk_print_context_rotate_according_to_orientation (print_context); + + if (!priv->use_full_page) + _gtk_print_context_translate_into_margin (print_context); + + g_signal_emit (op, signals[DRAW_PAGE], 0, + print_context, page_nr); + + /* TODO: override for preview */ + priv->end_page (op, print_context); + + cairo_restore (cr); + + g_object_unref (page_setup); +} + static gboolean print_pages_idle (gpointer user_data) { PrintPagesData *data; GtkPrintOperationPrivate *priv; GtkPageSetup *page_setup; - cairo_t *cr; gboolean done = FALSE; + g_print ("print_pages_idle\n"); + GDK_THREADS_ENTER (); data = (PrintPagesData*)user_data; @@ -1656,15 +1958,15 @@ print_pages_idle (gpointer user_data) if (priv->status == GTK_PRINT_STATUS_PREPARING) { - if (!data->print_context) + if (!data->initialized) { - data->print_context = _gtk_print_context_new (data->op); - data->initial_page_setup = create_page_setup (data->op); - - _gtk_print_context_set_page_setup (data->print_context, - data->initial_page_setup); + data->initialized = TRUE; + page_setup = create_page_setup (data->op); + _gtk_print_context_set_page_setup (priv->print_context, + page_setup); + g_object_unref (page_setup); - g_signal_emit (data->op, signals[BEGIN_PRINT], 0, data->print_context); + g_signal_emit (data->op, signals[BEGIN_PRINT], 0, priv->print_context); if (priv->manual_collation) { @@ -1684,7 +1986,7 @@ print_pages_idle (gpointer user_data) { gboolean paginated = FALSE; - g_signal_emit (data->op, signals[PAGINATE], 0, data->print_context, &paginated); + g_signal_emit (data->op, signals[PAGINATE], 0, priv->print_context, &paginated); if (!paginated) goto out; } @@ -1751,36 +2053,18 @@ print_pages_idle (gpointer user_data) goto out; } } + + if (data->is_preview) + { + done = TRUE; - page_setup = gtk_page_setup_copy (data->initial_page_setup); - g_signal_emit (data->op, signals[REQUEST_PAGE_SETUP], 0, - data->print_context, data->page, page_setup); - - _gtk_print_context_set_page_setup (data->print_context, page_setup); - priv->start_page (data->op, data->print_context, page_setup); - - cr = gtk_print_context_get_cairo_context (data->print_context); - - cairo_save (cr); - if (priv->manual_scale != 1.0) - cairo_scale (cr, - priv->manual_scale, - priv->manual_scale); - - if (priv->manual_orientation) - _gtk_print_context_rotate_according_to_orientation (data->print_context); - - if (!priv->use_full_page) - _gtk_print_context_translate_into_margin (data->print_context); - - g_signal_emit (data->op, signals[DRAW_PAGE], 0, - data->print_context, data->page); - - priv->end_page (data->op, data->print_context); - - cairo_restore (cr); - - g_object_unref (page_setup); + g_object_ref (data->op); + + g_signal_emit_by_name (data->op, "ready", priv->print_context); + goto out; + } + + common_render_page (data->op, data->page); out: @@ -1791,11 +2075,9 @@ print_pages_idle (gpointer user_data) done = TRUE; } - if (done) + if (done && !data->is_preview) { - g_signal_emit (data->op, signals[END_PRINT], 0, data->print_context); - - cairo_surface_finish (priv->surface); + g_signal_emit (data->op, signals[END_PRINT], 0, priv->print_context); priv->end_run (data->op, priv->is_sync, priv->cancelled); } @@ -1833,15 +2115,19 @@ show_progress_timeout (PrintPagesData *d static void print_pages (GtkPrintOperation *op, - GtkWindow *parent) + GtkWindow *parent, + gboolean is_preview) { GtkPrintOperationPrivate *priv = op->priv; PrintPagesData *data; - + + g_print ("print_pages\n"); + _gtk_print_operation_set_status (op, GTK_PRINT_STATUS_PREPARING, NULL); data = g_new0 (PrintPagesData, 1); data->op = g_object_ref (op); + data->is_preview = is_preview; if (priv->show_progress) { @@ -1862,6 +2148,37 @@ print_pages (GtkPrintOperation *op, data->progress = progress; } + if (is_preview) + { + gboolean handled; + + g_signal_emit_by_name (op, "preview", + GTK_PRINT_OPERATION_PREVIEW (op), + op->priv->print_context, + parent, + &handled); + + if (!handled || + gtk_print_context_get_cairo_context (priv->print_context) == NULL) { + /* TODO: handle error */ + } + + priv->start_page = preview_start_page; + priv->end_page = preview_end_page; + priv->end_run = preview_end_run; + + /* TODO: Do we really need to set these? */ + priv->print_pages = GTK_PRINT_PAGES_ALL; + priv->page_ranges = NULL; + priv->num_page_ranges = 0; + priv->manual_num_copies = 1; + priv->manual_collation = FALSE; + priv->manual_reverse = FALSE; + priv->manual_page_set = GTK_PAGE_SET_ALL; + priv->manual_scale = 1.0; + priv->manual_orientation = TRUE; + } + priv->print_pages_idle_id = g_idle_add_full (G_PRIORITY_DEFAULT_IDLE, print_pages_idle, data, @@ -1877,9 +2194,10 @@ print_pages (GtkPrintOperation *op, GDK_THREADS_LEAVE (); g_main_loop_run (priv->rloop); GDK_THREADS_ENTER (); + + g_main_loop_unref (priv->rloop); + priv->rloop = NULL; } - g_main_loop_unref (priv->rloop); - priv->rloop = NULL; } /** @@ -1964,7 +2282,7 @@ gtk_print_operation_run (GtkPrintOperati &do_print, error); if (do_print) - print_pages (op, parent); + print_pages (op, parent, result == GTK_PRINT_OPERATION_RESULT_PREVIEW); else _gtk_print_operation_set_status (op, GTK_PRINT_STATUS_FINISHED_ABORTED, NULL); @@ -2006,7 +2324,7 @@ gtk_print_operation_run_async (GtkPrintO { run_pdf (op, parent, &do_print, NULL); if (do_print) - print_pages (op, parent); + print_pages (op, parent, FALSE); else _gtk_print_operation_set_status (op, GTK_PRINT_STATUS_FINISHED_ABORTED, NULL); } Index: gtk/gtkprintoperation.h =================================================================== RCS file: /cvs/gnome/gtk+/gtk/gtkprintoperation.h,v retrieving revision 1.10 diff -u -p -r1.10 gtkprintoperation.h --- gtk/gtkprintoperation.h 24 May 2006 16:15:14 -0000 1.10 +++ gtk/gtkprintoperation.h 1 Jun 2006 20:34:39 -0000 @@ -29,6 +29,7 @@ #include "gtkpagesetup.h" #include "gtkprintsettings.h" #include "gtkprintcontext.h" +#include "gtkprintoperationpreview.h" G_BEGIN_DECLS @@ -84,7 +85,13 @@ struct _GtkPrintOperationClass GtkWidget *(*create_custom_widget) (GtkPrintOperation *operation); void (*custom_widget_apply) (GtkPrintOperation *operation, GtkWidget *widget); + + gboolean (*preview) (GtkPrintOperation *operation, + GtkPrintOperationPreview *preview, + GtkPrintContext *context, + GtkWindow *parent); + /* Padding for future expansion */ void (*_gtk_reserved1) (void); void (*_gtk_reserved2) (void); @@ -98,7 +105,8 @@ struct _GtkPrintOperationClass typedef enum { GTK_PRINT_OPERATION_RESULT_ERROR, GTK_PRINT_OPERATION_RESULT_APPLY, - GTK_PRINT_OPERATION_RESULT_CANCEL + GTK_PRINT_OPERATION_RESULT_CANCEL, + GTK_PRINT_OPERATION_RESULT_PREVIEW } GtkPrintOperationResult; #define GTK_PRINT_ERROR gtk_print_error_quark () Index: gtk/gtkprintoperationpreview.c =================================================================== RCS file: gtk/gtkprintoperationpreview.c diff -N gtk/gtkprintoperationpreview.c --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ gtk/gtkprintoperationpreview.c 1 Jun 2006 20:34:39 -0000 @@ -0,0 +1,107 @@ +/* GTK - The GIMP Toolkit + * gtkprintoperationpreview.c: Abstract print preview interface + * Copyright (C) 2006, Red Hat, Inc. + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2 of the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library; if not, write to the + * Free Software Foundation, Inc., 59 Temple Place - Suite 330, + * Boston, MA 02111-1307, USA. + */ + +#include "config.h" + +#include "gtkprintoperationpreview.h" +#include "gtkmarshalers.h" +#include "gtkintl.h" + +static void gtk_print_operation_preview_base_init (gpointer g_iface); + +GType +gtk_print_operation_preview_get_type (void) +{ + static GType print_operation_preview_type = 0; + + if (!print_operation_preview_type) + { + static const GTypeInfo print_operation_preview_info = + { + sizeof (GtkPrintOperationPreviewIface), /* class_size */ + gtk_print_operation_preview_base_init, /* base_init */ + NULL, /* base_finalize */ + NULL, + NULL, /* class_finalize */ + NULL, /* class_data */ + 0, + 0, /* n_preallocs */ + NULL + }; + + print_operation_preview_type = + g_type_register_static (G_TYPE_INTERFACE, I_("GtkPrintOperationPreview"), + &print_operation_preview_info, 0); + + g_type_interface_add_prerequisite (print_operation_preview_type, G_TYPE_OBJECT); + } + + return print_operation_preview_type; +} + +static void +gtk_print_operation_preview_base_init (gpointer g_iface) +{ + static gboolean initialized = FALSE; + + if (!initialized) + { + g_signal_new (I_("ready"), + GTK_TYPE_PRINT_OPERATION_PREVIEW, + G_SIGNAL_RUN_LAST, + G_STRUCT_OFFSET (GtkPrintOperationPreviewIface, ready), + NULL, NULL, + g_cclosure_marshal_VOID__OBJECT, + G_TYPE_NONE, 1, + G_TYPE_OBJECT); + + g_signal_new (I_("got-page-size"), + GTK_TYPE_PRINT_OPERATION_PREVIEW, + G_SIGNAL_RUN_LAST, + G_STRUCT_OFFSET (GtkPrintOperationPreviewIface, ready), + NULL, NULL, + _gtk_marshal_VOID__OBJECT_OBJECT, + G_TYPE_NONE, 2, + GTK_TYPE_PRINT_CONTEXT, + GTK_TYPE_PAGE_SETUP); + + initialized = TRUE; + } +} + + +void +gtk_print_operation_preview_render_page (GtkPrintOperationPreview *preview, + gint page_nr) +{ + g_return_if_fail (GTK_IS_PRINT_OPERATION_PREVIEW (preview)); + + GTK_PRINT_OPERATION_PREVIEW_GET_IFACE (preview)->render_page (preview, + page_nr); +} + +void +gtk_print_operation_preview_end_preview (GtkPrintOperationPreview *preview) +{ + g_return_if_fail (GTK_IS_PRINT_OPERATION_PREVIEW (preview)); + + GTK_PRINT_OPERATION_PREVIEW_GET_IFACE (preview)->end_preview (preview); +} + Index: gtk/gtkprintoperationpreview.h =================================================================== RCS file: gtk/gtkprintoperationpreview.h diff -N gtk/gtkprintoperationpreview.h --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ gtk/gtkprintoperationpreview.h 1 Jun 2006 20:34:39 -0000 @@ -0,0 +1,75 @@ +/* GTK - The GIMP Toolkit + * gtkprintoperationpreview.h: Abstract print preview interface + * Copyright (C) 2006, Red Hat, Inc. + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2 of the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library; if not, write to the + * Free Software Foundation, Inc., 59 Temple Place - Suite 330, + * Boston, MA 02111-1307, USA. + */ + +#ifndef __GTK_PRINT_OPERATION_PREVIEW_H__ +#define __GTK_PRINT_OPERATION_PREVIEW_H__ + +#include +#include + +#include "gtkprintcontext.h" + +G_BEGIN_DECLS + +#define GTK_TYPE_PRINT_OPERATION_PREVIEW (gtk_print_operation_preview_get_type ()) +#define GTK_PRINT_OPERATION_PREVIEW(obj) (G_TYPE_CHECK_INSTANCE_CAST ((obj), GTK_TYPE_PRINT_OPERATION_PREVIEW, GtkPrintOperationPreview)) +#define GTK_IS_PRINT_OPERATION_PREVIEW(obj) (G_TYPE_CHECK_INSTANCE_TYPE ((obj), GTK_TYPE_PRINT_OPERATION_PREVIEW)) +#define GTK_PRINT_OPERATION_PREVIEW_GET_IFACE(obj) (G_TYPE_INSTANCE_GET_INTERFACE ((obj), GTK_TYPE_PRINT_OPERATION_PREVIEW, GtkPrintOperationPreviewIface)) + +typedef struct _GtkPrintOperationPreview GtkPrintOperationPreview; /*dummy typedef */ +typedef struct _GtkPrintOperationPreviewIface GtkPrintOperationPreviewIface; + + +struct _GtkPrintOperationPreviewIface +{ + GTypeInterface g_iface; + + /* signals */ + void (*ready) (GtkPrintOperationPreview *preview, + GtkPrintContext *context); + void (*got_page_size) (GtkPrintOperationPreview *preview, + GtkPrintContext *context, + GtkPageSetup *page_setup); + + /* methods */ + void (*render_page) (GtkPrintOperationPreview *preview, + gint page_nr); + void (*end_preview) (GtkPrintOperationPreview *preview); + + /* Padding for future expansion */ + void (*_gtk_reserved1) (void); + void (*_gtk_reserved2) (void); + void (*_gtk_reserved3) (void); + void (*_gtk_reserved4) (void); + void (*_gtk_reserved5) (void); + void (*_gtk_reserved6) (void); + void (*_gtk_reserved7) (void); +}; + +GType gtk_print_operation_preview_get_type (void) G_GNUC_CONST; + +void gtk_print_operation_preview_render_page (GtkPrintOperationPreview *preview, + gint page_nr); +void gtk_print_operation_preview_render_sheet (GtkPrintOperationPreview *preview, + gint page_nr); +void gtk_print_operation_preview_end_preview (GtkPrintOperationPreview *preview); + + +#endif /* __GTK_PRINT_OPERATION_PREVIEW_H__ */ Index: gtk/gtkprintunixdialog.c =================================================================== RCS file: /cvs/gnome/gtk+/gtk/gtkprintunixdialog.c,v retrieving revision 1.22 diff -u -p -r1.22 gtkprintunixdialog.c --- gtk/gtkprintunixdialog.c 1 Jun 2006 04:58:18 -0000 1.22 +++ gtk/gtkprintunixdialog.c 1 Jun 2006 20:34:39 -0000 @@ -275,7 +275,8 @@ gtk_print_unix_dialog_init (GtkPrintUnix (GCallback) gtk_print_unix_dialog_destroy, NULL); - gtk_dialog_add_buttons (GTK_DIALOG (dialog), + gtk_dialog_add_buttons (GTK_DIALOG (dialog), + GTK_STOCK_PRINT_PREVIEW, GTK_RESPONSE_APPLY, GTK_STOCK_CANCEL, GTK_RESPONSE_CANCEL, GTK_STOCK_PRINT, GTK_RESPONSE_OK, NULL); Index: tests/print-editor.c =================================================================== RCS file: /cvs/gnome/gtk+/tests/print-editor.c,v retrieving revision 1.7 diff -u -p -r1.7 print-editor.c --- tests/print-editor.c 31 May 2006 14:06:02 -0000 1.7 +++ tests/print-editor.c 1 Jun 2006 20:34:39 -0000 @@ -262,6 +262,7 @@ begin_print (GtkPrintOperation *operatio int num_lines; int line; + g_print ("begin-print\n"); width = gtk_print_context_get_width (context); height = gtk_print_context_get_height (context); @@ -304,6 +305,7 @@ begin_print (GtkPrintOperation *operatio print_data->page_breaks = page_breaks; + g_print ("found %d pages\n", g_list_length (page_breaks)); } static void @@ -317,6 +319,9 @@ draw_page (GtkPrintOperation *operation, int start, end, i; PangoLayoutIter *iter; double start_pos; + + g_print ("draw-page %d\n", page_nr); + if (page_nr == 0) start = 0; else @@ -430,17 +435,205 @@ custom_widget_apply (GtkPrintOperation * data->font = g_strdup (selected_font); } +typedef struct +{ + GtkPrintOperation *op; + GtkPrintOperationPreview *preview; + GtkWidget *spin; + GtkWidget *area; + gint page; + PrintData *data; + gdouble dpi_x, dpi_y; +} PreviewOp; + +static gboolean +preview_expose (GtkWidget *widget, + GdkEventExpose *event, + gpointer data) +{ + PreviewOp *pop = data; + + gdk_window_clear (pop->area->window); + gtk_print_operation_preview_render_page (pop->preview, + pop->page - 1); + + return TRUE; +} + +static void +preview_ready (GtkPrintOperationPreview *preview, + GtkPrintContext *context, + gpointer data) +{ + PreviewOp *pop = data; + gint n_pages; + + g_object_get (pop->op, "n-pages", &n_pages, NULL); + g_print ("ready to preview %d pages\n", n_pages); + + gtk_spin_button_set_range (GTK_SPIN_BUTTON (pop->spin), + 1.0, n_pages); + + g_signal_connect (pop->area, "expose_event", + G_CALLBACK (preview_expose), + pop); + + gtk_widget_queue_draw (pop->area); +} + +static void +preview_got_page_size (GtkPrintOperationPreview *preview, + GtkPrintContext *context, + GtkPageSetup *page_setup, + gpointer data) +{ + PreviewOp *pop = data; + GtkPaperSize *paper_size; + double w, h; + cairo_t *cr; + gdouble dpi_x, dpi_y; + + paper_size = gtk_page_setup_get_paper_size (page_setup); + + w = gtk_paper_size_get_width (paper_size, GTK_UNIT_INCH); + h = gtk_paper_size_get_height (paper_size, GTK_UNIT_INCH); + + cr = gdk_cairo_create (pop->area->window); + + dpi_x = pop->area->allocation.width/w; + dpi_y = pop->area->allocation.height/h; + + g_print ("new dpi: %f, %f\n", dpi_x, dpi_y); + if (fabs (dpi_x - pop->dpi_x) > 0.001 || + fabs (dpi_y - pop->dpi_y) > 0.001) + { + gtk_print_context_set_cairo_context (context, cr, dpi_x, dpi_y); + pop->dpi_x = dpi_x; + pop->dpi_y = dpi_y; + } + + pango_cairo_update_layout (cr, pop->data->layout); + cairo_destroy (cr); +} + +static void +update_page (GtkSpinButton *widget, + gpointer data) +{ + PreviewOp *pop = data; + + pop->page = gtk_spin_button_get_value_as_int (widget); + g_print ("go to page %d\n", pop->page); + gtk_widget_queue_draw (pop->area); +} + +static void +preview_destroy (GtkWindow *window, + PreviewOp *pop) +{ + gtk_print_operation_preview_end_preview (pop->preview); + g_object_unref (pop->op); + + g_free (pop); +} + +static gboolean +do_preview (GtkPrintOperation *op, + GtkPrintOperationPreview *preview, + GtkPrintContext *context, + GtkWindow *parent, + gpointer data) +{ + GtkPrintSettings *settings; + GtkWidget *window, *close, *page, *hbox, *vbox, *da; + gdouble width, height; + cairo_t *cr; + PreviewOp *pop; + PrintData *print_data = data; + + pop = g_new0 (PreviewOp, 1); + + pop->data = print_data; + settings = gtk_print_operation_get_print_settings (op); + +#if 0 + /* FIXME need to figure out the size */ + width = gtk_print_settings_get_paper_width (settings, GTK_UNIT_PIXEL); + height = gtk_print_settings_get_paper_height (settings, GTK_UNIT_PIXEL); + + g_print ("%f x %f\n", width, height); +#endif + width = 200; + height = 300; + window = gtk_window_new (GTK_WINDOW_TOPLEVEL); + gtk_window_set_transient_for (GTK_WINDOW (window), + GTK_WINDOW (main_window)); + vbox = gtk_vbox_new (FALSE, 0); + gtk_container_add (GTK_CONTAINER (window), vbox); + hbox = gtk_hbox_new (FALSE, 0); + gtk_box_pack_start (GTK_BOX (vbox), hbox, + FALSE, FALSE, 0); + page = gtk_spin_button_new_with_range (1, 100, 1); + gtk_box_pack_start (GTK_BOX (hbox), page, FALSE, FALSE, 0); + + close = gtk_button_new_from_stock (GTK_STOCK_CLOSE); + gtk_box_pack_start (GTK_BOX (hbox), close, FALSE, FALSE, 0); + + da = gtk_drawing_area_new (); + gtk_widget_set_size_request (GTK_WIDGET (da), width, height); + gtk_box_pack_start (GTK_BOX (vbox), da, TRUE, TRUE, 0); + + gtk_widget_set_double_buffered (da, FALSE); + + gtk_widget_realize (da); + + cr = gdk_cairo_create (da->window); + + /* TODO: What dpi to use here? This will be used for pagination.. */ + gtk_print_context_set_cairo_context (context, cr, 72, 72); + cairo_destroy (cr); + + pop->op = op; + pop->preview = preview; + pop->spin = page; + pop->area = da; + pop->page = 1; + + g_signal_connect (page, "value-changed", + G_CALLBACK (update_page), pop); + g_signal_connect_swapped (close, "clicked", + G_CALLBACK (gtk_widget_destroy), window); + + g_signal_connect (preview, "ready", + G_CALLBACK (preview_ready), pop); + g_signal_connect (preview, "got-page-size", + G_CALLBACK (preview_got_page_size), pop); + + g_signal_connect (window, "destroy", + G_CALLBACK (preview_destroy), pop); + + gtk_widget_show_all (window); + + return TRUE; +} + +/* FIXME had to move this to the heap, since previewing + * returns too early from the sync api + */ +PrintData *print_data; + static void do_print (GtkAction *action) { GtkWidget *error_dialog; GtkPrintOperation *print; - PrintData print_data; GtkPrintOperationResult res; GError *error; - print_data.text = get_text (); - print_data.font = g_strdup ("Sans 12"); + print_data = g_new0 (PrintData, 1); + + print_data->text = get_text (); + print_data->font = g_strdup ("Sans 12"); print = gtk_print_operation_new (); @@ -452,12 +645,15 @@ do_print (GtkAction *action) if (page_setup != NULL) gtk_print_operation_set_default_page_setup (print, page_setup); - g_signal_connect (print, "begin_print", G_CALLBACK (begin_print), &print_data); - g_signal_connect (print, "draw_page", G_CALLBACK (draw_page), &print_data); - g_signal_connect (print, "create_custom_widget", G_CALLBACK (create_custom_widget), &print_data); - g_signal_connect (print, "custom_widget_apply", G_CALLBACK (custom_widget_apply), &print_data); - + g_signal_connect (print, "begin_print", G_CALLBACK (begin_print), print_data); + g_signal_connect (print, "draw_page", G_CALLBACK (draw_page), print_data); + g_signal_connect (print, "create_custom_widget", G_CALLBACK (create_custom_widget), print_data); + g_signal_connect (print, "custom_widget_apply", G_CALLBACK (custom_widget_apply), print_data); + g_signal_connect (print, "preview", G_CALLBACK (do_preview), print_data); + error = NULL; + +#if 1 res = gtk_print_operation_run (print, GTK_WINDOW (main_window), &error); if (res == GTK_PRINT_OPERATION_RESULT_ERROR) @@ -467,7 +663,7 @@ do_print (GtkAction *action) GTK_MESSAGE_ERROR, GTK_BUTTONS_CLOSE, "Error printing file:\n%s", - error->message); + error ? error->message : "no details"); g_signal_connect (error_dialog, "response", G_CALLBACK (gtk_widget_destroy), NULL); gtk_widget_show (error_dialog); g_error_free (error); @@ -489,10 +685,15 @@ do_print (GtkAction *action) g_signal_connect (print, "status_changed", G_CALLBACK (status_changed_cb), NULL); } +#else + gtk_print_operation_run_async (print, GTK_WINDOW (main_window)); +#endif g_object_unref (print); +#if 0 g_free (print_data.text); g_free (print_data.font); +#endif } static void --=-xjDvOKJb0tdB52kmWdgp-- From tomasek@ebed.etf.cuni.cz Fri Jun 2 03:11:55 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 2F96F3B01C7 for ; Fri, 2 Jun 2006 03:11:55 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05061-05 for ; Fri, 2 Jun 2006 03:11:53 -0400 (EDT) Received: from ebed.etf.cuni.cz (ebed.etf.cuni.cz [195.113.5.3]) by menubar.gnome.org (Postfix) with ESMTP id 3EDBD3B011A for ; Fri, 2 Jun 2006 03:11:53 -0400 (EDT) Received: from ebed.etf.cuni.cz (localhost.localdomain [127.0.0.1]) by ebed.etf.cuni.cz (8.12.11.20060308/8.12.11) with ESMTP id k5270gLE004827 for ; Fri, 2 Jun 2006 09:00:42 +0200 Received: (from tomasek@localhost) by ebed.etf.cuni.cz (8.12.11.20060308/8.12.11/Submit) id k5270gdU004825 for gtk-devel-list@gnome.org; Fri, 2 Jun 2006 09:00:42 +0200 Date: Fri, 2 Jun 2006 09:00:42 +0200 From: Petr Tomasek To: gtk-devel-list@gnome.org Message-ID: <20060602070042.GA3470@ebed.etf.cuni.cz> References: <1149203639.27455.9.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1149203639.27455.9.camel@localhost.localdomain> User-Agent: Mutt/1.4.1i X-Homepage: http://www.etf.cuni.cz/~tomasek/ X-Echelon: bomb Arafat Intifada bus kach drugs mafia boss heroin spy Semtex Saddam Al-Qaida Usama bin Ladin Bush Sharon X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.534 tagged_above=-999 required=2 tests=[AWL=0.065, BAYES_00=-2.599] X-Spam-Score: -2.534 X-Spam-Level: Subject: Re: Print preview api X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 07:11:55 -0000 On Thu, Jun 01, 2006 at 07:13:59PM -0400, Matthias Clasen wrote: > Ok, after a lot of work (mostly by John and Alex), > we finally have a proposal for a print preview > api that will allow us to use an external viewer > by default, but also support internal preview. Hi! I think, this is very unfortunate. Many people will not want to use the external viewer (for reasons discused earlier), so everyone will write his own preview widget? Why not just have official internal preview widget like gnome-print has and support it by deafult? P.T. -- Petr Tomasek From shree_poroly@yahoo.com Fri Jun 2 06:49:17 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id DD9063B03E7 for ; Fri, 2 Jun 2006 06:49:10 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19278-08 for ; Fri, 2 Jun 2006 06:49:06 -0400 (EDT) Received: from web53308.mail.yahoo.com (web53308.mail.yahoo.com [206.190.49.98]) by menubar.gnome.org (Postfix) with SMTP id 574673B110A for ; Fri, 2 Jun 2006 06:48:56 -0400 (EDT) Received: (qmail 1625 invoked by uid 60001); 2 Jun 2006 10:48:55 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=opsX4ZJJjJ3RSp61u8057G5DaMkib9ROhHy+AzeYX+l7J8HSwJa+UppJPxFDKOjVDg5ivFj+xumB8simRH1oUSf2tMk9h8YEuyY6OEPoTApYincgsxe7YmLfJe3+jDCaLeD7TV1kXmnpIstEupgel4fQt9kXW1CGDMkwXy+xReA= ; Message-ID: <20060602104855.1623.qmail@web53308.mail.yahoo.com> Received: from [61.246.61.209] by web53308.mail.yahoo.com via HTTP; Fri, 02 Jun 2006 03:48:55 PDT Date: Fri, 2 Jun 2006 03:48:55 -0700 (PDT) From: shree nidhi To: gtk dev MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-596188450-1149245335=:1049" Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=1.399 tagged_above=-999 required=2 tests=[AWL=-3.076, BAYES_50=0.001, DNS_FROM_RFC_ABUSE=0.2, DNS_FROM_RFC_WHOIS=1.447, HTML_40_50=0.496, HTML_IMAGE_ONLY_12=1.867, HTML_IMAGE_RATIO_02=0.463, HTML_MESSAGE=0.001] X-Spam-Score: 1.399 X-Spam-Level: * Subject: Fwd: test X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 10:49:17 -0000 --0-596188450-1149245335=:1049 Content-Type: multipart/alternative; boundary="0-601274911-1149245335=:1049" --0-601274911-1149245335=:1049 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Note: forwarded message attached. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --0-601274911-1149245335=:1049 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit

Note: forwarded message attached.

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com --0-601274911-1149245335=:1049-- --0-596188450-1149245335=:1049 Content-Type: message/rfc822 X-Apparently-To: shree_poroly@yahoo.com via 206.190.49.100; Thu, 01 Jun 2006 21:38:26 -0700 X-Originating-IP: [202.71.129.68] Authentication-Results: mta129.mail.mud.yahoo.com from=galieosoft.com; domainkeys=neutral (no sig) Received: from 202.71.129.68 (EHLO smx1.net4india.com) (202.71.129.68) by mta129.mail.mud.yahoo.com with SMTP; Thu, 01 Jun 2006 21:38:26 -0700 Received: from [125.22.33.12] by smx1.net4india.com with smtp (Exim 4.51) id 1Fm1a8-00025h-AB; Fri, 02 Jun 2006 10:18:21 +0530 OM-Header: origin=omniqube Received: from unknown (192.168.0.89) by SMTP-Receiver; Fri, 2 Jun 2006 10:07:06 +0530 Subject: test From: Nidhi To: nidhi@galieosoft.com, shree_poroly@yahoo.com Content-Type: multipart/mixed; boundary="=-k0bJJnk7Qaq1V0+G97NB" Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-1) Date: Fri, 02 Jun 2006 10:12:00 +0530 Content-Length: 21206 --=-k0bJJnk7Qaq1V0+G97NB Content-Type: multipart/alternative; boundary="=-rVG5rqf50PHPN/AXL0Ln" --=-rVG5rqf50PHPN/AXL0Ln Content-Type: text/plain Content-Transfer-Encoding: 7bit I have developed an application for an handheld device, the initial window will look like this : But the device is having rectangular display if i place the window as it is my drawing area will look compressed, so i dont want to compress my drawing area. If i can tilt the window and display i hope my drawing area will look like enlarged. Is there any way to tilt an application window as shown please help me out. --=-rVG5rqf50PHPN/AXL0Ln Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
I have developed an application for an handheld device, the initial window will look like this :









But the device is having rectangular display if i place the window as it is my drawing area will look compressed, so i dont want to compress my drawing area. If i can tilt the window and display i hope my drawing area will look like enlarged.







Is there any way to tilt an application window as shown please help me out.


--=-rVG5rqf50PHPN/AXL0Ln-- --=-k0bJJnk7Qaq1V0+G97NB Content-Disposition: attachment; filename=test1.map Content-Type: application/octet-stream; name=test1.map Content-Transfer-Encoding: 7bit --=-k0bJJnk7Qaq1V0+G97NB Content-Disposition: attachment; filename=test2.map Content-Type: application/octet-stream; name=test2.map Content-Transfer-Encoding: 7bit --=-k0bJJnk7Qaq1V0+G97NB Content-Disposition: attachment; filename=wintilt.sxw Content-Type: application/vnd.sun.xml.writer; name=wintilt.sxw Content-Transfer-Encoding: base64 UEsDBBQAAAAAAJZQwTSAkGt+mxsAAJsbAAAtAAAAUGljdHVyZXMvMTAwMDAyMDEwMDAwMDEzNzAw MDAwMTM0REUzMjdBMTMucG5niVBORw0KGgoAAAANSUhEUgAAATcAAAE0CAYAAABJtnScAAAABHNC SVQICAgIfAhkiAAAABV0RVh0U29mdHdhcmUARXllIG9mIEdub21lCx+PrwAAGzFJREFUeJzt3X1w XOVh7/Hfvmglr23ZMS/BAWNbmBcrYPOSmCQ0kUMgwYQyIS+9uDdphyZtYzFzk6bJVWZaT5JbXXqH zjT3TlM70Et7XQ+95OIggkOhxAnrtBjiYBAGS7Zky/KLkLEl68162Zdzzv1jdY53VytZu9rVrh5/ PzMaafe8PUe757fPeZ7nnPVJcoQ5o2phtQLBoIb7zqY97/f7S1QioPzYtq2gJLUeP65jp8+oZ2BA I9FYqcuFHLR3dWn3rl165I+/qurqas2bN08VFRWEHS5Kw8PDuu222yQpGW7HTp/RL99sLmmhkJ+9 e/cqeu6cBgcHFQ6HFQwGVVlZqWAwmHX+eDw+5fp8Pp/3t9/v9x47jiPbtuU4U1f0Z7p8IaSWYap5 UuebbBm3vJP9Lib2Y6LJyu++1/r6+7zHQUk609+ffPM5jvzTKAjKh+M4io+NanR0VJZlye/3q7Ky UhUVFZLST1dt21ZVVZUcx5HjOGlvKPfNMZ03IlBuotGogsGgomNR77mgJA2NjimWSMhxHAXGD4Zd zzbJTiRkJRJy3E9cx5HcN3/G3z6/Xz6/Xxse3Di7e3URsx1HtmUpOjysnp4eLViwQBUVFXIcR6FQ SBUVFV7ISclaWzwel2VZXrgFAgFvvmAwmFbbAqbrBz/4gWKxmOLxuBKJxJS1dJ/Pl6xZBYN69NFH C7L82NiYqqqqNDY25s0XlKR4IqGEZcm2HVl+W5KUiMX01P/+Bx1+t1vv9fVraHR0yp07fvq0Xvjn bYolEjn+WzAjjqPoyIh+9PQOVS2sVmU4rGBlpQIVFfrhw5tUVVWlYDCoh//u72UnEkrEYrIty/tw 8gcC+uHDmzR//nxvXtrrkKvh4WE9/vjj055/3759euSRR3Tu3LmCLH/69GktXLhQI8PD3jxBSUpY luIJS5ZtezU3Kx7XoZNdemnfmxNOVbOdvr75H/+u6MiI4glr2gXMxcZP1mk0GtWze14ryvoLvb3N //lBLZo/X99+/IkClyzd6rU364H77kt77uCJk3o98rK6urq0ePFiVVRUKDYyoi3f26yO7lN6r69f w2Njajl+Qm/sjqirq0uXXHKJFi5cqKqqKgUCgaKWGeYZHa/8dHZ2Tmv+nTt3qr+/31tupsufPXtW Pp9PwyMj3jxBSYolEorG40pYloLjb2w7kdDx02cUz1ITc09pUtmWpUR0TNGMButt3/mWJKntZJf+ +//9iff81++7Vx9dfYOOnz6jzdu2X3BnPrl2jfrOndNPdv/7tHY+1Z9/8QGtWblS3/mHf9Tp/n5J 0lc+dafuuvVm/d3Pdur1tnZJ0t233qIvfvwOPfyjrTPaniQtmDdP1eHwhP9HMbzVcTTtcfv+tzQ6 OKCenh75fD5VVVUpEY2q7WSXdr62N+t8qaems9HIDLO4HVUX6rBKNTIyosR4vmQuf91116mtrS1t /sznUpcfGRnRggULstfcYu6p6fgb27Ys9Z87p2g8ntbj5fP50t787jTbtmUnEpOell575QdUWVGh odFRBQMBra1ZmVynnGmdym7860cvOM9k9nd0as3Klbph2VU62dMjSfrgiqu9cu1paZUk3bRyhfYf 7dRINDqj7UnJsz5Js3Kanvl6OLat2MiIBgYGFA6HZdu2ErGYTvb0euVxxtvr3Pmqq6sVDofT2unc Dgba4HAhlpU8Y0vk8H6PxWKybXvC8rW1tZKSYdbS0iJJWZ9LXd5tSx5JaT7zam5j420xCbfmZlmK xuNT1jz8Pt/5MEwkZFuWxmITx8n1DA7q0upq3bhiuV5+a7/W1tQoFo8rXFkpx3E0Fovp0upq/ZcH 7tc1S5dqXiikd3vP6p9e+oX2tR+WJDV97y/VOzSkr/3t/0p7/I8vvqSv3vNphSsr9c+7fqUXfvv6 hO2/3tauL3/qk/rg8qv189/s1WWLFmnpkiWSpBuWXaWxWEyVFRWqXX61Hnv+BY3FYjlvryIQ0B/d 82l94qYbFa6s9LY9FovJJ+l3P3K77l33IV26aJF6Bgb0r3tf187f7JXjOPq9uo9r4/o6ffvxJ3Sk u1t/9vnP6RM33aiGJ/5JbSe79J0vfUFDIyP68fMvTPo6uNxOhkQ06oVbNBpVIhrV2aGhtNfHGQ+9 oaEhDQ4OKhQKeZ0RwWDQq8kRcLgQ9wM2l3CzbdsLp9Tl9+/frzVr1kg6H2qu/fv3e9tIXd6yLNm2 PbFDQUq2sdmWJcfdmG0rlkjImiLcUlvXbCvZ25pt/n2H2nT3bbfqtmtXadfr+7TuulV6rfWg7vnw h7xlApLeaGvXthdfUlUopL/88u/r4fvv0x/+j785v6KM9S8Kh7VxfZ1+vf9tfe6Oj2nj+k/o53te nbD9o+++q75z53TTyhWSZemm5VdraGRER0+9p5tWrtC8YFA3LLtKFYGAXm89eH4bOWxvY90ndM+H btPOV1/TL99o1l899AdaGA7Lisd1/8c+qoc+c7d+03pQf/OTHfpi3cf10GfulmPbevaVPXrnSIe0 vk6rr7pS7SdO6IPLx2uVS5fqYOcx3bhiubb+bGfW/21qE4H7t21ZSsRievKlXygUDisQDMq2LDW3 tav70MHMFejJX+xSKBxWRdU8BUMhBSoq9N8e+kOFw2FvzBydDJiKG065nJZK52tsmcvv27fPG4zr 2rdv34T1u8vbti3LsjQWzRgK4krEYvK7NTfbTvaiZqmJZWOPDy/INv/g8LDeOdqpW69dJb9t6/Yb btD/3PFTL9wSsZiOd3frxKlTWrpkiRYtWKC+oSEtveSS9PU5SnscTyT07S0/1uDwsNavXaPFCxZM Wt4329p15623aOXll+vmmpV6s/2wjp16T2tqVuq6DyzVrauu0ZGud3W6tzev7a1fm/yk+ZeXdmlg eFixeML7n957+4clSY/9bKdOnT2rH/ed1UdW36B7b1+nHS9HdKDjqBKWpdrlV+vVt9/RwnBYPQMD uu7KD2jZkiWqDof1Zlv7tF+Ly1bWaP2nP5323IH2w3r7317wPsAc25bP79fTTz2lA8eOqaunV4Mj IzrQflhdB95RT0+PlozXbiXRyYAp5VNzcxxnQrhNtXzmtNTl3RpcIiX80sLNisckhdwllbDs5LAB yTsYvBVneazxU6IJO2E7eu1Ai9ZcU6MHPv47CldVqnm8EV9OMhhXXXWl/uIPvqIlCxfqxOnTuqS6 OlnotPWlr39kbEz9g4PJsrs7mWX7kvTGoTbdeestuvXaVVq7apWeeP5f1XXmjL7ymbt148oV+vD1 1+tX+97Ie3uXLkqWt39oaPyFOt92edmiRZKkU729sm1b7/Umrwu9bPGi5Km8ZantxEl9cMUKralZ qdbOY+o/d06rl1+tNdfUqOPdbm+7U3Fr3ZK0f7wd0XW644jsREIbbl+nyspK+f1+Pffqa3qr46ie +eWvzs935LDGhgbV29vrnZYGAgE6GTAlL1zGA+iOO+7IOt8rr7zi/e04Ttop5oWWv/322ydd3v2d 2nySHm7jA3ndjcUSCSViUU3H+ZrbxPltK6FXmpv1J/ffp4133ak9b7+j0ZHh8QLaSsSiemjDPVp6 yRJ9+Xs/0KmzZ/XYd/+rrrnyyrT1OY4mfewee5OV97cHDkiS7vvYR1Q9P6zfvvOO+oaGFIvH9anb btX7Fi7Uq2/vz3t7o9Go5s+bp4WVIQ2PjqoqFPKmn+7r15WXXapLFoTV3dOrK8ZrRGf6+rzl97e3 q3bFcn32ox/RK2+/reHRUdXdvFbrb1mrNw4enPbrMBnHtmUlEgoGg1qwYEGyXS0UUkd3d9q63UHB fX193nWqktI6Gc7/P85fApN5xQOdEReX1Ib9qaROdxxHsfGzkdTl169f780TiUQkyXvujjvu8J5L XT5bjS8t3Bzblp3yd8KyZMXjaTW0bNzTnElrbo6jE6dO6fip93T1Fe/XfzQ3n59vvObmNorX3XKz zo2O6qrLL5ckfej667V3vHcksyaV/vh8TSmbM2fPqrO7WyuWLtWJ997TqfFe05ajnbr5ums1NDyi lo6j3j851+292dau31m7Rn/24O8pVBFS5Xi42ZalZyMRPfylL+rrD3xOT774b/r98VPGZ3f/2lu+ ua1ND959l6656kr9/Y6fKuZ2iS9bpv+z8/lJasTJsrqvj1ubzvwtSXYinrzixLK8Ed7y+dQzOOSd qvr8fq+9bnBwUPPnz5ff71c8HlcoFFIgEPA6GNxPTbch1w03v9/vXfUQCAQIuItEZm/prl27ss6X GkK2bXvhlLr8rl27dNddd2nXrl1p68t8LnX5bDJOS+Nem5scR/HxS6/s8QMis/FaShkK4p6mZRsX Nz5M5IdP/ouWXfF+7Wl+K2U+R3YiocefadJffPUh/dH9v6vd+97QE8/+TH/8wOf0n+7+lF7bv//8 PyRj/Rd6nOr1Ay1asXSpXm9p9eZrPnRIN193rX5z4J2sbVrT3d6Pn96hZZdfrjXXXqutT+/Q8ive r0sXL5adSGjHrl/KL58+f+cn9aNv/7neO3tWW3f8VE//YpfX2/x2W3uyp9O21XL4sKzxNs+A36+3 Dh70tpM5xtBxHCkl+Hxu0GT8dod+PP/qawrNmyd/ICDbttXeckC9x48ll3VfW9vWT3f/WqGqKgUr KxUMheQPVuhbX/qCd0r76P/b4V2el7ziwZZ8fvkDAX3rS1/QvHnzvF5Xws18maeV0xUd7wDIXP7F F1+csK5sz7nLZ7tRhE+Ss3nbdjW3tevsyRPeJ/3hPa9o1cfuUHdry4SFJtNzrFM33XPvtOdHAbjn xz5f+vW+Wea7+vob0p463nZIR3+793wnw3hwPvnUU3rj8BEdPXVK/eeGdbztkM50HNHX7vusFixY oGAwqB89+5z+tvGv0uc7dFBnjnboa/d9VosWLVI4HPZqfDDbY489pkceeUQ7d+6c9jLPPPOMvv/9 7xdk+Wg0qiuuuEKRSESNjY2SspyWpjYcH9r9cvJaxPELWeVM0qg8fjriHx9ygPLUmfFB1XfyhKx4 XB9fc5NCoZD8fr9ebn5L+9oP69mf/zxtvrGhIfX29sqyLIVCIcWjY1POJ52/zRHhZj7HcfTNb35T IyMjyXGVKe33mXw+n3drLndc2kyXr15UPWG4Ulq42Zbl1dxWfnhdfjuZ1maFcpZsckh2MsyfPz/Z ThYK6dDJrrTX0bFtxUZHNTAwoIqKiuSdG2KxKeerqqryApNwM9/GjfndDcg9rZzp8u9bvESZNxWf UHPD3DDV0Ixs7aKpl865v5N/+71PwVAoJH8goJ6BgbQauHepVizmvZkcy7rgfGNjY4QbZsWSJe/T 0NBQ2nMTWuHOnjwxawVC6dl2MoxGR0eT99FKJNR9sFX93e+mz2clNDw87PWExsbGppyvv79fiUTC 64AAimlRdbV3hxDXhHBr+/XuWSsQysNPjhxJe3zsjX1Z53sqc759E6/jzTYfUGzf+MY3JvTKp4Vb YHygZilHo7e2tl54JgAYV1tbm/UO0tm/RUSlCZna2lrvdiYAMBNl0xjiXlIBAIVQNuEGAIVEuAEw 0qRtbuUq8/Q19Q4Cc5WJ+wSU2pwJNzcA6uvrJ0zbsmXLnAwEE/cJKBc5hVvm/cxdqV/ikO3vmYpE Il4AZBum4vP58gqDfMpYqP0q5D5dqEyl7IWmBxylknObW0tLy4Sf1GnFNNn4u3zG5bkH3WSBPVsK tU+T7Uep9w8olYJ2KEx1INXW1no/uXBrOBc62Ddt2qRIJKLVq1fntP5sMsvoPs787f6d636VYp9S TVbm1P2bbNpUj/N5fYFimZXeUreW5P6U+gBIPVXKpTypy6Supxz2K9v2s50SXqjMqdOnuz/l9H8A XDl3KGS+cWlPmVsu9Hrl83ryHkA5yjnc8n0jl9unebmVpxDcWlPq72yKse8m/j8xt83aUJB8Q3G6 PaBbt27Vpk2bLnhN7GQH/Wz26hV6n3KRuZ+FCKVirBOYqZJcoZDrm3/Lli0l+5KRYh2oxdqnC9Xa CoHwwlwwKzW3zEbmXA+89evXa8uWLV5NJtXWrVslqaA1nNTy5tLonst+zfY+pZYxs8zTCcOp/if5 rhMoprRvv+o9fkx7tm+T4zizfssjd3jEhQ6IzEuV3GCYy/eBM3GfgNlSW1urvr4+dXZ2qqmpKfu3 X80FmbUcEwLAxH0CSm3OhZuJB76J+wSUGrc8AmAkwg2AkQg3AEaass2N7zUAMFdNGm4M1AQwl2UN t9bW1oIMwCz0rXoAmKdYowWKPhSEYQ4AJlPMK1noUABQEsVu0y9quJXqYneUL9pyMVvm3BUKMMtM bqgATIVwQ8lkuw8cAYdCoc0NgJEINwBGItwAGIlwA2Akwg2AkegtRdFMNqaNXlHMBsINRTPZt8+7 wTbTLw4CpkK4oagmC7jU6UAx0OaGokutqQGzhXDDrCDYMNtm5bSUi6WRivcDZkNRw81xHO4MAqAk soZb6h108w0nx3G0fv161dXV5VcyABeF5557rijrnbTm5t5BN9+2Ep/PR7ABmJaGhoa8lrNtW9/9 7nezTivKaSltKgByletXEtTW1sqyrEmn01sKYM6Zzi3KCTcARiLcAJStmTRxEW4AypIbbPkGHOEG oOxkBlo+AUe4ASgrU90qKxfcFQRAWSnUdcjU3AAYiXADYCTCDYCRaHMDUDamc+XBdBFuAMpCoa9J J9wAlAXHcXJexrbtSacRbgDKAncFAXDR464gAC5ahBsAIxFuAIxEuAEwEuEGwEiEGwAjEW4AjES4 ATAS4QbASIQbACMRbgCMRLgBMBLhBsBIhBsAIxFuAIxEuAEwEuEGwEiEGwAjFfU7FGrW1aQ97tjb wXSmM53pWacXmk+Ss3nbdjW3tav3+DHt2b5NjuPk/GUNqdyv6KqrqytQMQGYasOGDWpoaMgpcyKR iOrr62VZlgKBgPr6+tTZ2ammpiY1NjZK4rQUgKEINwBGItwAGIlwA2Akwg2AkQg3AEYi3AAYiXAD YCTCDYCRCDcARiLcABiJcANgJMINgJEINwBGItwAGIlwA2Akwg2AkQg3AEYi3AAYiXADYCTCDYCR CDcARiLcABiJcANgJMINgJEINwBGItwAGIlwA2Akwg2AkQg3AEYi3AAYiXADYCTCDYCRCDcARiLc ABgpWMyV16yrSXvcsbeD6UxnOtOzTi80nyRn87btam5rV+/xY9qzfZscx1Fra2veK62trZUk1dXV FaiYAEy1YcMGNTQ05JQ5kUhE9fX1sixLgUBAfX196uzsVFNTkxobGyVxWgrAUIQbACMRbgCMRLgB MBLhBsBIhBsAIxFuAIxEuAEwEuEGwEiEGwAjEW4AjES4ATAS4QbASIQbACMRbgCMRLgBMBLhBsBI hBsAIxFuAIxEuAEwEuEGwEiEGwAjEW4AjES4ATAS4QbASIQbACMRbgCMRLgBMBLhBsBIhBsAIxFu AIxEuAEwEuEGwEiEGwAjBUtdAFw8Irt3e3+vr6srYUlwMbhguNXW1ua98pp1NWmPO/Z2MP0inq6U cCvH8jG9xO+PAvNJcjZv267mtnb1Hj+mPdu3yXEctba25r1SNxDr+HRGCmpuyGbDhg1qaGjIKXMi kYjq6+tlWZYCgYD6+vrU2dmppqYmNTY2SsrhtDS1BtfS0pJD0YEkAg2zaVrhVltbmxZomY8BoNzQ WwrASIQbACMRbgCMRLgBMBLhBsBIhBsAI01rKEhLSwvj3ADMKdMexEugAZhLOC0FYCTCDYCRCDcA RiLcABiJcANgpBmH20xuZgkAxVKQmhsBB6DcFOy0lIADUE4K2uZGwAEoFwUNN65iAFAuChZuBBuA clKQcCPYAJSbGYcbwQagHDGIF4CRCDcARiLcABiJcANgJMINgJEINwBGItwAGIlwA2Akwg2AkQg3 AEYi3AAYadpfypyPmnU1aY879nYwnelMZ3rW6YXmk+Rs3rZdzW3t6j1+THu2b5PjOGptbc17pe5N K+vq6gpUTACm2rBhgxoaGnLKnEgkovr6elmWpUAgoL6+PnV2dqqpqUmNjY2SOC0FYCjCDYCRCDcA RiLcABiJcANgJMINgJEINwBGItwAGIlwA2Akwg2AkQg3AEYi3AAYiXADYCTCDYCRCDcARiLcABiJ cANgJMINgJEINwBGItwAGIlwA2Akwg2AkQg3AEYi3AAYiXADYCTCDYCRCDcARiLcABiJcANgJMIN gJEINwBGItwAGIlwA2Akwg2AkQg3AEYKFnPlNetq0h537O1gOtOZzvSs0wvNJ8nZvG27mtva1Xv8 mPZs3ybHcdTa2pr3SmtrayVJdXV1BSomAFNt2LBBDQ0NOWVOJBJRfX29LMtSIBBQX1+fOjs71dTU pMbGRkmclgIwFOEGwEiEGwAjEW4AjES4ATAS4QbASIQbACMRbgCMRLgBMBLhBsBIhBsAIxFuAIxE uAEwEuEGwEiEGwAjEW4AjES4ATAS4QbASEX9DgUAyEUkEinYugg3AGXB/e6VQiHcAJQFx3FyXsa2 7UmnEW4AykKu37hXW1sry7ImnU6HAoA5Zzptc4QbACMRbgCMRJsbgLIyVa9pS0vLtNdDzQ1AWZks wHIJNolwA1CGMoMs12CTCDcAZcoNtHyCTSLcAJSxfINNItwAGIpwA2AkhoIAKBuzdleQQm4IAKYy a3cFKfSGAGAytm1PeRF8PrKGW2tr64x6KVzPPffcjNcBwGz333+/Dh06VPD1Fr3NraGhodibADBH 2bZdlGCTZqlDIZ/7NDmOk/NyAGZfvsfrhe7HNlNlNxSETgxg7sj3eJ2N47yk4UanBWCuUh/fJQu3 Uu84gOIr5XFeknAj2ICLR6mO91kPN4INuPiU4rif9XArxPg5AHNLKY77kpyWEnDAxaNUx3vJOhQI OMB8pTzOSzoUhIADzFXq47vsBvECQCHM2v3cynkkM4DCKKfjdVbCLd9uYIaNAHNHuR2vRQ+3fO/T VIz7OwEojnI8XrOGW6GqltXV1XrssccKsi4AyEXWcNu0adNslwMA8lJfX5/1+bRws+JxSZLP5yt+ iQCgCGzblpQRbpdfs0qbt20vSYEAFEZzW7sORn6lTV/4vFavXq1ly5bpgT/9uh78kz/Ne/rixYtV WVmpQCAwZyo/E05Lm9vaS1EOAAVy+shhxcbG1Nvbq+7ubklSbGxMUvL4zmf6wMCAKisr5ff751a4 uTsEwAznes6oublZXV1dWrx4cfJxynGe6/SqqioFg0H5/XNn3L9PklPqQgBAoc2dGAaAHPx/YMnV s9b8aj0AAAAASUVORK5CYIJQSwMEFAAAAAAAllDBNLasV216HwAAeh8AAC0AAABQaWN0dXJlcy8x MDAwMDIwMTAwMDAwMTM0MDAwMDAxMzdBQjUxQTdGMS5wbmeJUE5HDQoaCgAAAA1JSERSAAABNAAA ATcIBgAAACQVvTEAAAAEc0JJVAgICAh8CGSIAAAAFXRFWHRTb2Z0d2FyZQBFeWUgb2YgR25vbWUL H4+vAAAfEElEQVR4nO3de3hc5WEm8PecGd1tSb6C8QUsbNcShRAMsg2bWoBJIFwCXdJC+zRZIKGR S7fbbGG7adNsku4fLm36bLtIlDalSdjCEggEtgmlEMZJHYIxxBgs2QZ8wYCNbUmj0Whmzn3/kM7x jOZyzpyZo/nm6P09jx+kkWbmNbZef+c73/mOBMACAFmWQURUD0zTLPh4lEVGRGERBYDXXnsNqqZC ySjIZDJITU5iMpVCanISqXQamUwGGUWBrmmQJKnWmYmIcnzjG98AMF1obW1tWNS8CK2trdB1HWNj Y0gmk1AUBYZhwDRNGIZR8IVkWYYsy4hGo2hoaEA0GoUkSSw+IpoVTz31lPNx1P7Asizouo5MJoOJ iQmMjo4ilUpB0zSn1EzThK7r0HV96snRKJqbmzG/fT4WdC7E/Pnz0dHejuaWFs7JEVHgjhw5kvO5 U2imaaKpqQlNTU2IRCLo7OyErutOkRmGAcMwoOs6VFWFqqpQlKlD1MR4AqdOnkImk8GJEyec4R8R UVDGxsbyHosW+L6qGBoaCuqlq+qZZ57BvffeW+sYRHPCgQMHKnp+LBZDf39/0Sktp9Dsb7jvvvsw MjKCeDyOVCoFVVWdU6SWZTm/7MdkWUZDQwPuueeeioLWkizLvub8LMviXCHNOX7/3hebh6+mvBGa ruv4yle+gmeffdbzizzxxBNVDVULQ0NDiMVinr9/27Ztvp5HVM/8/r23nxe0vBGaaZrYsGEDFi1a BE3TnJMAxT5++eWXnZME9a6vr8/T9838g/T6PKJ65vfv/Wz+g593KtKyrJzPe3p68p408zcy8zlE RLXgFFqhY+J169YBAC666CLnsSuuuAIAsHXr1qCzCaFQoRNRLlF+TkouFjt48KDz8YYNG7Bx40bn 8xdeeCG4VIIQ5Q+JqB6I8PPiuvq10PKLuTAJLsIfDlG9qfXPDZfzF1DrPxSielbLnx/XQvNyUiBs 6mVRMJGIavnzk1do2ScH7JMCwNSOHK+88orzefZJgTAuLmWpEZWv1j83TqHZSy+yLyq3Twrs3bvX eWznzp0Ack8KRKOBXUFVU7X+wyGqJyL8vOSN0GaWk5eTAk1NTdVNJRAR/pCIRCfKz0ne0KqhoQEA cN5553l6gcWLF+PFF1+saijRhX0OkagQv3/vZ/PnJWc/NABobGzE3XffjXQ67eyFNvOidHs7Ifvj lpaWWQsclO7u7rK+3/7/Ve7ziOqZ37/32RtaBCmv0L72ta8hmUwinU573g8tk8lAUZTAwwZl+/bt tY5ANCfcdNNNgb5+3c7md3d3V+Xs6pYtW6qQpnq6ertwaNehWsfIwUzuRMsDiJkJQEX7D7ot6s8r tHraD62SrXtmazsTIsrld/9BL/up1f1+aGGboBfxX1RmcidaHkDMTLag9lPLK7S5vB8aEc2eIPZT c90PzQvuh0ZEIij74vQrrrgidId5RBQO3G1DMF29XbWOkIeZ3ImWBxAzUynV2KWDhUZENWeXWaWl lndxOhHRbJpZYpWUGkdoRFQzxcrLb6nlLdvws+AtjPuh1YqIa4eYyZ1oeQAxM81U7V068gotez+0 Qnbu3OmsQ3NeJKT7oRFRfXHdD82LMO+HRkT1g/uhEZHQyln3mldoc3U/NFGIuEMCM7kTLQ8gZiZb UPup5RXaXNwPjYhm16zttkFEFLRZ222DiGg2zMpuG1RbIs55MJM70fIAYmYKGguNiEKDhUZEdcle eZGNhUZEdSl76ZiNhSYYEfewYiZ3ouUBxMxUTYqiQFGUnMswWWhEVJfi8TgSiQQymYzzGAuNiOrS sWPHcPz4ccTjcecxrkMjoro0PDyMkZERnDp1ynmMhSYYEdcOMZM70fIAYmaqpsEnfwA1k0HyNAuN iOrc+r6rcPLdd4C16zBy9CgAzqERUZ26eN1aLD1/Tc5jHKERUd26eN1a7Mn6nCM0wYi4doiZ3ImW BxAzUzU99tDf4bt/87/w80e+4zzGQiOiuvTU3z2IB//8m/idW25xHmOhEVFdKrkOjbeiI6J6wnVo dUDEtUPM5E60PICYmaqp5Do0jtCIqJ5wHRoRhUbJdWgcoRFRveE6NMGJuHaImdyJlgcQM1M1lVyH xhEaEdUTrkMjotDgfmhEFBpch1YHRFw7xEzuRMsDiJmpmrgfGhGFBtehEVFoFFqH5hTazBt2EhHV G47QBCPi2iFmcidaHkDMTEFjoRFRaPCQk4hCg4VGRKHBQ07BiLh2iJnciZYHEDNT0FhoRBQaLDQi Cg0WGhGFBgtNMCKuHWImd6LlAcTMFDQWGhGFBguNiEKDhUZEocGFtYIRce0QM7kTLQ8gZqagcYRG RKHBQiOi0GChEVFosNAEI+LaIWZyJ1oeQMxMQWOhEVFosNCIKDRYaEQUGiw0wYi4doiZ3ImWBxAz U9BYaEQUGiw0IgoNFhoRhQYLTTAirh1iJnei5QHEzBQ0FhoRhQYLjYhCg4VGRKHBQhOMiGuHmMmd aHkAMTMFjYVGRKHBQiOi0GChEVFosNAEI+LaIWZyJ1oeQMxMQWOhEVFosNCIKDRYaEQUGiw0wYi4 doiZ3ImWBxAzU9CcQpMkqZY5iIgqxhEaEYUGR2hEFBocoQlGxLVDzOROtDyAmJmCxhEaEYUGR2hE FBocoRFRaHCEJhgR1w4xkzvR8gBiZgoaC42IQoOFRkShwUIjotBgoQlGxLVDzOROtDyAmJmC5hSa ZVm1zEFEVDGO0IgoNFhoRBQaPOQUjIhrh5jJnWh5ADEzBY2FRkShwUNOIgoNFhoRhQYLTTAirh1i Jnei5QHEzBQ0FhoRhQYLjYhCg4VGRKHBQhOMiGuHmMmdaHkAMTMFjYVGRKHBhbVEFBocoRFRaLDQ BCPi2iFmcidaHkDMTEFjoRFRaLDQiCg0WGhEFBosNMGIuHaImdyJlgcQM1PQWGhEFBosNCIKDRYa EYUGC00wIq4dYiZ3ouUBxMwUNBYaEYUGC42IQoOFRkShwUITjIhrh5jJnWh5ADEzBY2FRkShwUIj otCI1jpANfX09BT92tDQ0CwmIaJaCE2h9fT0lCwtt6+Loqu3S7i5D2ZyJ1oeQMxMQeMhJxGFBguN iEIjNIecQ0NDnEMjmuNCU2hAOEpLxDkPZnInWh5AzExBC1WhFVMvJwTIm9iOHc7HfVu21DAJiSYU hVbqULOc7yGi+uYUmiRJtcxREbfRV3aZ2d/LgiMKH+cspyzPjROeoheZiHtYiZapb8sW3HnvHUId bor2/wgQM1PQnBar5xFaOTiXRhRevufQLMuCZVkwDCPnl2mars/1MkoKonhYZkTh5hSaZVmen2SX ma7rUFUV6XQamUwGmUwGiqK4Pr8WxcIyIwo/55DTy8jKZo/MVFVFKpVCIpHA2NgY4vE4kslkxaGq Pc9VT2Um4tohZnInWh5AzExB83XIaVkWNE1DOp3G+Pg4RkZGMD4+DlVVMTk5WdZrFSqveiogIhKH 7zk0wzDwre8/icxEApmJCajpNEzDgGnonl8je8FrsY+JiLzyPYdmmiZMw8CS1V0Yee8oWtrbnbm1 U+++G0hYIqJSfC0+s4sLlolVv7IeC1asxIIVK9F5zvJq55tzRFw7xEzuRMsDiJkpaL4KTZKkqXVr kozOeW2+3zx7hwz7Yx5uEpFfvubQJEmCLMuQIxGsPvts7KkgQHZ5sciIqBK+TwpEIhFEolFcsuZ8 WDfcgAPvf4DT4+Owylj+QURUTb5HaNFoFHI0ii//6VehKRnoqgrLMKBmMp5fhxsy5hNx7RAzuRMt DyBmpqD5HqFJkoT7fuNWjI+PY2JiApOTk1BVFaOjo3jgtd2eXqNQaXEOjYj88r3Fhr10w778SVVV KIoCTdMqCuS2lTYRUTG+9kOzr+NUFAXJZBLxeNz3lQJERNXiFFq5+6FV60qBQubyIaeI91JkJnei 5QHEzBQ0TyM0+/DS3iJI0zSoqgpT17Ck63yMHD3i60qBuVxcRFR9ricFsrcKUhQFmUwGyWQSExMT 0FUVq9b9CkzDgDV9KdTYB+/PRm4iojyu13LOnC+bmJjA+Pg4xsfHoStKRVcKADzsJKLqcQqt2H5o 9lZBqVQKo6OjGBkZwdjYGBKJBNRMpqIrBbhEI5+Icx7M5E60PICYmYLmaR2aruv4s4e/g8zEBDIT CSiTk1MLaU2TVwoQkTDyCq3YCQBD07D8gl/FiYMH0NLROT1vZuC3b7sN0cZGRBobIUciMHXvZznt NWccpRFRNeTMoWUvlrXvEZBOp5FIJKCrKi5YuwamYUBXFZiGgVOH3oVlWbjy4o+hvb0dzc3NSKVS GHz9NU9vbs+fcddaIqqGnBGafQIgk8lgYmICiUQCk5OTSCQS0DJptLe2nvle04RlWZAkCaZpQtM0 yLJc1pUCLK18Iq4dYiZ3ouUBxMwUtJxCs4tpcnISIyMjOH36tHOtpppKYfniRc73StMLcSVZnlqT ZppIp9NQVbXiUDwMJSI/8ubQNE3DHz4wiFQ8jnRiHGoqBV1VAcvCBeeei1+/+iocOn4cpxMTMDQN 8Q8/xM/2vgnT0CFJMkzTKCsADzeJqFryDjkNw4BpGLhkSx+GXn8tZ9HsZ2+7DQ3NzYg2NgKSBEPT sPqyXowcPeIcgpZzpQBvkkJE1ZRXaFP3CrDQs2olNF2HomlQNA3vv/UmLNPETZs3obOzE7Is43v/ +jyvFKgyEec8mMmdaHkAMTMFLafQztwrQEJbc7PzmPN1WYZpmlBVdepkgJF7eFnOjh1ERNWWV2iR SARyJIKzFnTmfbMky1AUxVmjpqbTOV8v51Z4QO46tJk3TCEiKpdTaA0NDc5/o42N6Fp2Nm7c1Iv3 T49gdGLqBMDpI4fx41d2wdB1mLpelREab5JCRNWSM0KTZRkNDQ2Qo1Fs+/o3oSsKdFWFrihQ0yl0 X3k1jh/YPzVfpmuwLAvvHdjvPL/cERrlE3HtEDO5Ey0PIGamoBW8lvOB3/89jI6OIplMIpVKIR6P 468efQwXrF0DQ9Ng6BpMw4ChaTmjNK8jNC9bbHO0RkTlKlhouq5D0zTn0qdMJgOjwDWaMwvM6wiN 82VEFISCVwpkMhnE43HnSoHx8akFttnsdWd+Za85y/6ciMgvb1cKTM+lZZNkGdKMrYIqOSnAYpsi 4pwHM7kTLQ8gZqagRQE4O2xkbxV0ad+VeOu13c6CWdMwsO/td5wnVjpCm4nFRkSVigJTozLLsqCq KuLxOHRFwfqVK6BoGlRdR2a65LJHaYVGaJUUHIuMiCoVBYB0Og1d12EYBkZHR6FkzZdZlgVZkqDP KCtnhFbhKI1FRkTVIgNAIpHAiRMn8N577+HIkSPITCTyvtGeH8veNmj6C77euKenJ+cqAZrS1dtV 6wh5mMmdaHkAMTMFLWqaJr7y99+GkkxCy6ShTE7mjNBc+RihZa9D412fiKhaogCwZetW7Nq1a2oL bsMALAv7j03tmiFJEkx7F44sldwMhWVFREGIAsDa5cuB3t6pEwO6Dt0woOnu12naO3MQEYlAznvA Y0E5c2hUVSKuHWImd6LlAcTMFDS5bcHCqr0Y90MjolqSC12j6RV31yAikciFlmh4xREZEYnE00TY l66/Dldc0IP2trag88x5Iq4dYiZ3ouUBxMwUtILbB800v7UV/Z+5Ee2trTj04XG8vn8/Xt9/AG/s 349EMun7zbu7u3M+Hx4e9v1aRESeCu3+7z8JU9excuFCXHR+F/o+/jHcetWVME0TW75wt+83Hxwc zPm8v78fAIuNiPzxVGjrVizH2mXLsG75OVi/aiWWLlgAADB8Lq6NxWIAzhSYzS64/v5+lhoRlc1T oW2/6w4AwOnxcew7fARPvhTDvncP4cDhw2W/YSwWw7Zt2wqeIbULbnBwcM6Wmohrh5jJnWh5ADEz Bc3TSYGfvvkWRhIJtLe1oXPePLS1tKCxoQERH4tri5UZEVGlPI3Q/voHT8PUdSyZNw8Xda3G9Zs3 4XPXXQvdMHDlF3/X85vZh5pu+vv75/QojYj88VRo5y9bhu4Vy9Fz7ipccN55aG9rBTB12zsiIlF4 KrS/vPsuAIBuGDh47H3s/fnb2HPwIN48+Hag4eYiEe+lyEzuRMsDiJkpaJ4K7dHYDrz17iHsO3QY mUwGuqpM3WeggsumiIiqzVOhPb7jZ1P3FNC0it6sr68PAwMDkCSp5ImBwcFB9PX1cf6MiMriqdAk ScLNV1yOT2/sxZLODpwaG8PTO36Kx//1eRjuTy/6moVKTZIkDAwM+HxVIprLPBXajRt7ccenrnE+ P3vRInzp12+BZZr45x/9uKw3tEdpQOGL2wcGBtDX11fWa4aJiHMezOROtDyAmJmC5qnQPt17KX4x vB8PPv1DfDQyikVtrfjSLTfj5r4tZRcaAKewZo7E5nKREVHlPBXa4o4O3P9/n8DJsTgsy8KJ0VH8 8/PP43//0X+t6M1ZYERUTZ4Wkp0eH8dnt3wCZy9cCFmWsWzxIvz2tZ/CqbF40PmIiDzzNEL70a7d uONT12Bj9/qcxwe//2QgoeYyEdcOMZM70fIAYmYKmqdCe/YXr8AwDHx642VY0tGBk2NxPB2L4YkX Xgw6HxGRZ54KzQLwzM9fxg9iO2AahrOwlheZE5FIihbaX959F9pbW11f4BN3fqGqgYiI/CpaaOOT kzBME5YFLJw/DxOpFFRNB2ChubERTY2NiE9MzGLUuUHEOQ9mcidaHkDMTEErWmjf/D+PQdE0qLqO R//7ffjqw9/FwaNHYRoGIpaJb9z9Rbz06quzmZWIqCRPyzZSioKrL7kYHW1tkCQJbS0tUDUV/Z+9 Neh8RESeeTop8NM338KNmzfhxs2bch4/evxExQF6enryHhsaGqr4dYlo7vE0QvvH557H47Gf4uRY HKZpYjKdxr+/sRd/8kBlF5H39PRgaGgo71ehkpsrRLyXIjO5Ey0PIGamoHkaoWmGgUdeeBH/9KMf 5yzb4H5oRCQS7qFNRKHhaYR23WWX4va+X8P8AuvSKlmHVuzwknNoROSHp0L73Nar0NzYiHgyCcMw MHWBQHWuEmB55RJx7RAzuRMtDyBmpqB5KrSUouC5V3fjoR8+W9U5NPukgNfHiYhK8VRo337uedze twWPtbUhnkhU/KbZh5lz+YwmEVWXp0K789pPoqO1FQ//8b1IZTI5h5y3fPmPyn5Te/TFkRgRVZOn s5yL5s9HNBJBS1MTFnV0YHFnBxZ3dmJxZ2dFb84yyyfi2iFmcidaHkDMTEHzNEK75et/PnUbO1Wt +hxaMSw7IiqXp0ILCk8IEFE1FS20my/fhM093dj2twP4hy//AWBZ09NmVsVzaKXYa9NYakRUrqKF 1tLUhAXz5gGYmkOj2SHi2iFmcidaHkDMTEErWmiPvrQDj7z4EoDZn0Pj6IyI/Cg5h/bAPf3Ye/gI dh04iN3D+3FyZKSqb87iIqJqKlloT/xsJy5cfR5+9/rrcM9NN+DdDz7ErqFhvPzmXgwdOgxzlkIS EXlRstD+7fVf4l92vQrLstCzcgUuWXM+rtpwCW6/5mpMTKbwyr638PUHH6pamOxD0Lk6ehPxXorM 5E60PICYmYLmadmGomnY/94xmLqOjKLg6g2XYMH8+dja21txobHEiKhaShbapevWYu3yc7B+5Qqc u3QpJEkCAKiahj0H38aeAwd8v7FdZNmXQRERVaJkof3+Z250Pt576DDeePsdvPHOO9j3zjtQFMX3 WU6uMyOiIJS8lvOF1/fg+OgoAGD12Wfh3LPPwvIlS7CgwnVp9uJZjsryiTjnwUzuRMsDiJkpaCVH aN978SdQdR3zW1pw4bmrcHHXatx1/afxh79xK4599BF2Dw3jW997xNcb81CTiKrN00mBU+Pj+Mkv 9+DwBx/i6ImPcMPlm7DyrLOw8qyzfBeaLfvQkycIiKgSJQttaWcn1q9cgQvOXYULV5+HtuZm52tH jh/H7n3VLR2WGBFVomSh3f/FO52Px5JJvPL6L/H6gYN4dd8+nBod5W3sAiDi2iFmcidaHkDMTEEr WWh7Dx/G3kNHsPvg2zj84YfQFMW5lpOISDQlC+2vnngKqq4jo6qwrOrc5YmIKCi80TARhQYLTTAi znkwkzvR8gBiZgoaC42IQqOm9xTo7u7O+Xx4eLhGSYgoDDwV2nWXXYrb+34N81tb8772iTu/4PvN BwcHcz7v7+8HwGIjIn88Fdrntl6F5sZGxJNJGIaRc5MUP2KxGIAzBWazC66/v3/OlpqIa4eYyZ1o eQAxMwXNU6GlFAXPvbobD/3w2YrvKRCLxbBt27aCy0DsghscHJzTpUZE/ng6KfDt557HpevWob2t reI3LFZmRESV8jRCu/PaT6KjtRUP//G9SGUyvu/LaR9quunv7+cojYjK5qnQ7PtyRiMRtDQ1BRpo rhNxzoOZ3ImWBxAzU9A8FVpQ9+UkIqomLqwlotAoOkK7+fJN2NzTjW1/O4B/+PIfAJY1PW1m+Z5D 6+vrw8DAACRJKnliYHBwEH19fZw/I6KyFB2htTQ1YcG8eQCm5tAWtbdjUUc7FnV0YHFnBxZ3dmJx Z6fvN7bvIOX18bmiq7er1hHyMJM70fIAYmYKWtER2qMv7cA/Pf8CgOrOodmjNKBweQ0MDKCvr6/s 1yUi8n0tZ29PD37zmqvxn7ffX/Zz7cKyi23m40REfngqtA1r1+D3brrBOQS1aRWe5WSBEZGbcnrC U6Hd8clr0NLYiOMjI1jU3o5jJ09ixdKl+PbTP/SbkYoQce0QM7kTLQ8gZibbzJ123FiWBdM0Xb/P U6Gds2ghvvrwd5BOZ9D/mRvxpe1/gesv34yPrVlTVigiIsDfyT/DMFy/x1OhpVUVGVXFeDKJlUuX 4uyFCzGvpQVbNlxSdigioqGhIc+XQgJT14B74anQ3j1+HBd2rcbjL76E0YkJPPL1rwEA3j95suhz uru7A12CwQvcieqb17mxcorPU6H9zVPPIIKpEvmf3/0e7rjuWsiShId+8FTJ55Xbwl55bet6JOIe VszkTrQ8gJiZguap0E4nEjA0DQDwzvsf4L89MOB5HVq1z2QGUZBEFA4lC+2bn/8dWLBgWWd+wQIs y3Qug/pPf/Y/ZiUoEZGbkoW2aumS2cpBRHNQT09P0a8NDQ2V/XolC+3l4f34WNdqqJqGXwzvx869 b2LPwbeRTk1y+6CAiDjnwUzuRMsDiJlppqGhoYKl5qfMAJdCe/D//QimZeH8ZcvQu24N/sut/xGt zU14Zd8Q/n3PHvx8zxuYSCZ9vbEt+zdj/+b8/maIqP7MLLVKfv5d90PTDQNvHDqEB5/9F9y1/X48 /pMYLr/wV/Gnd96BrRt7fb8xAKe8sn8DxRqbiMLL7oBKBzOuZznnt7Rgc/d6bFi7BpesXYOWxkYA wHsnPsKxEx9V9OZERLZqHJmVLLQ/uf03sXb5OZAkCaZp4q3DR/CLfUPYuWcPjp04wTm0AIi4doiZ 3ImWBxAzU9BKFtq6FcsBTK1De+3AQSQmJ9E5bx6u27xpahmHaWLw8e/7fvOZh5f2x5xDIyJb1Xfb WNzejk9ddmnBr1VSaEDtyotzdUS1U5PdNj5//7eg6joyqirkXZ/s/yl+rxm1LIt7shHNsu3bt/t+ bnt7e8mv+96xthJeRkZuI7fsG6j4HeUNDw8jFosJdR+DHTt21DpCHmZyJ1oeQMxMg4ODFT3f7dLH mhSaSHNkkiTx8JMoJGpSaCISqWTJHRdg15dYLDYru+TkFdqPH3sUaioFJZWCrmRg6jpMw8i6OP3M fwEAkgQ5EsH6vqs8v6n9l7Ha13ER+cWCDIe8QrNME9d97vPYFYtNTfyb5nSpTRebaeb99/SRw2W9 abVWBRNVg/0PK0ut/hUstFVLl0L7D5+AomlFz3IamgbLNPH+m3s9nU4lEtHMowSWWn3Lv5bT4xk/ Sc56apnbYXMCnkRQ7O8h/37WL9eTApZlQZYkFLrfSrX29ee/ilQL/DsXPvkjtAIlZWY9ZvHwkogE lT9Cmz7kNO2zmTO/nHWoKdKCVJq7eLacbEUPOWVJgjT9i0hUbtMVnM6YW/ILbcaorNQ8WSVzaIXO LmXjX0IiKlfRQ84zn+Z+nj2H5nytzFEcy4qIgpBXaJIkYX5LS9EnZM+h2SM0WXbdyZsoELzihLLl F5os46wFnc6ZzWKHlZZpOiM0OcpLQql2WFpky2uiSDSKNecswyc3fBzvnTyFeDLpXDGg6Tp0w4Sq 69ANA5quw9B1JE7W770FLMvK2YqI6gNLjArJKzQ5GsVtX/giDE1zLkx3rt00TWB650hr+mPLshBp aJy1wNyQkaj+zNbPbV6hbb35lunRmFHyWk57x1pDP3PR+kzlbrPrVbVHVUHlJKIzZuNoKLDJL65f I6IglNpXLQoArU1Th4ymZcEwTZjm1H91w4A+fchp/zI0NW/7IEzfAcoyTSw4Zzk23vZbiDQ0zM7v jojmHEPTsOfg23mPRwFgcUcHgDNXB8iyhIgsIxqJwLQs6JEILNNEY0sLUGJJBxFRLUUB4NylS3D1 xy/GqXgcE+nM9NlMwzmbqfKGwkQkqD1ZH0sAqrMHEBFRjf1/WwoQUouhLCMAAAAASUVORK5CYIJQ SwMEFAAIAAgAllDBNAAAAAAAAAAAAAAAAAsAAABjb250ZW50LnhtbMVXbVPjNhD+3l+xdaedduYc JwSGIyW5gQtc6YSXKTDTflQkxdYgS64kJ+R+fVfySxIg4a50rh+wo9WzL9p9di2OPzzmEubcWKHV MOp1uhFwRTUTKh1G93fn8fvow+i74+/H1x/v/ro5Az2bCcoHTNMy58rFVCuHb7i5P51cfIQoTpLr gqvrAOtokybJ+G4M1XpcawH6SZKzqwiiyl6HORaNjrcZxxiVHVS7wyhzrhgkiUY3euVmr9vtJtU6 qhWsW8rd+IBo4I4/up1oD2jBZPqK7YBo4MyQxU60B2DOG/xMt+jFYtFZ9AOyd3R0lPx5O0nOtclJ G8ujFOphKz7sNlBV5lNudkdCHNnIi52nLxmvEjhvQ6YZMbvzFxCrjPTZKxnpswaMh822HPB9comb 4XE5WaXP5DuNe0B7PmpEsTvyChI17KeSWDuMKj7Uso0eaqlcKSbteoaMjhmn0o6OQ5JXEqjWiuTI qxMjiIR7JbAVOVzeRjDTFXRGciGXw+gnUmj761NcJY1gzXYhHMXkzQlCPSOT3Z5/+wSXQtFMw0Sk mYPft7l+Bny77yuRT0sLf+icKLjSRzDZ5vw58gXvlUqccsWNoMPIePRr8SUvVKoWkdKhBSdoHEy0 JQzPjYPc9Vo3ddiBK41CYZBkxglu2+MtuE/iMJpqyUIYa6a3+5mZZ45SQ4pMUNvIC2L8KA2LuNL6 1EBeiKcSZNqIzxgWkTFmdRhRNMFN9HzXcDmM0AUJbhtALozROGWUVjxUkEpRYP45dT93aQ5rf79E 4EffQJa5UET5+d79sZb58W9wFq2JDGdrq9RwrtbWU1mu66ckzwk2ZGtOahML1XbqjEjL6010pGzI FcUkxr3uWhReLcf+GkbWEcWIeaFCyVaO1BtTzZajY0+DgeV/l+iHN/R6LoQgYsIWkixjXTqc4TyW fO7TjZ/osF0V80LK0mL0Do/kw3qTsbumC95mxXP9rUbG9QfRZ3p71opKZZ3dt02NRheQkTkH5s0j wRngrCBFIQUN2UJiGi/KEJ9xyTwQK/UOXMahDj4ZCSWcn7EYDNMLfEkJUusHkOKBI1RYGNQRFl8Q VPINMaPjQGCRk5RXXF6HhdkRpBtToVdXgfjRbmK3LPhmh8/TwUIw/z0+7Bzs9WleybJ6gB129g96 XhhMf8Z+Y/wxFDdcRAaZ4bNh9MONoK403CbYad3uXje8ur3+Yf3eH5/19w5Pev1OEW5FQbcKxoq8 CLeTILOZxpsVx2sNa0QETROHSK0mmrAVhf6rAo1OSxdYUjEGkAPINGQr+BFHVFpKYqCmOYgZCMBf lAedmkjEgnBeM19CffkDHD9kjWFU5wWmyHL2DqxGIwwHIiwIPpxud58a6MCFd0iR2U5It+FTsVVU kGFP7PAe+M0VniTlrAP/A8f/FX/3voa/NVU3+VuTepO/vS/k737D45PTg97J4XnvW/O3GbuFr/9T FN5LRhfWU8JwZMMSybT0XApEeTIdVzz1ISpkMCeWA07KAnIOOLw7zWRGX1/ZYsnGVzHZ8o/f6B9Q SwcIVrL7yYQEAACfDgAAUEsDBBQACAAIAJZQwTQAAAAAAAAAAAAAAAAKAAAAc3R5bGVzLnhtbO1Y S2/jNhC+91eoLNqbLNmJmziNsmg3+2iRx6JJgPZIS5TFViIFkrKT/fUdkqJk2ZSTwkBPzSGION88 9XFmlMt3z1UZrImQlLMETScxCghLeUbZKkFPjx/Dc/Tu6pvLb6/v3z/++eVDwPOcpuQi42lTEaZC qV5KIoMvT7/c/Po+QGEU3deE3RvUhItVFF0/Xgf2+bpVCsBNFH24QwGy5iaZytDV5YhtiJDJCytM UKFUfRFFHLzw3sssjuPIPqNWwWgfxBuEgyvyrA6iNaAD4+Urtg3CwTOBNwfRGgAVd/icd+jNZjPZ nBjkdLFYRH883EQfuahwF8tzSdnfo3gjdVDWVEsiDkeCFR7URa5XPuO2gOsu5LTA4nD9DKKvyEn2 SkVOMgeGZIuRBM+jWxCaX7c3fflEddC4BnT5pYLWhyO3EOS4P7gtHWtzDozNSFrKq0tTwP4ksM8M V8CZnwXFZfDEKFwyEtw+oCDnFprjipYvCfoB11z+tIuzpyjYsl1TlUJh1higmm3RYc+fPwW3lKUF D27oqlDBb2Ou94DH+76j1bKRwe+8wiy444vgZsz5PtLj3aqEK8KIoGmChEa/Fl/keVPtke00LoWM 5Lgp2/7jjLZBrgSuC5pK5MC1AMoIRaFR6VsMpoDmIdw6Esoap3Crw4IL+hWc4jJB8WR2fpIC+8bA a20s3YcSlr3V6h7UYxOKn/KSQzP4LjY/g+q9/tIk/QqI6UzfCzgrMVs1eAVHhLXGG6YEFOzpYc9y iCXFzEvILaT24JDWjxU6V07GOCNO1nr1iXrvKa/qkjz7ruKu+w7qDaCT+kLwCvUMCXGjuH4zUCya EW4YFeKyLrCD1Q1LVYMVdJlwA+IESaqtdRHol7sUBEPflwpugOroCHMHeMtrqQm/y9DuaMDwt9C+ xgKbQH28/59L/y2XoCTFS10QhhUUKcelHB5q2ghSYcpCPXRDYyZBsz1Q3cjiFUiJs4x0csahsVRU Hc3nAvI2C88ooYMhn8OMQrNk2slsMovnuodZxEZQpZtcBYVPUClCtUTRYaZvM9zS8wFsZ1hkaJT3 7pWUWMoEmWUwGrf3yY2JfzE+tM0LrDkMObzUZOh9vboAAsQmb/j7xf3d1kAXdZs6ruWHMDshXF7v CQQpPfn1U8VqprCIE+GR7qj3FW8rbbLhjbKDyHNWkjUp22ZjBOYArodzBttqmJtVN0Ha/pu0Z0dp nxylfXqU9vwo7R+P0j47Svv8KO3FUdrTeEw9GmVgzrliXBEJbY3ldNUI05o8doCLRsPuaWtcNnAr 4/awNwM3hSrzSVBDLx/o2E8u3Z+0Pfdp26UHq9rbIqH+SJwdnWPvamjMAKzQrIWymxm2QnkuidKr 4eli0bcUXxlaI326JclVK4PhCzOH6Ckx39623WrdPuphATZpGg53bl24sIJPTyIGjbSupiMrh9HY 0Ex/G86mk/miXWvNeUH0FgCCs8nidDQpZ5bCjIbOBsHj9jVyoQSmdh+psIBZFUIP1bNnftr6aY+X XEFGPokuDrSUyfRsPhQIG1sncZuCpRNU4bmLX/f4/suqBUhSu75v048n8fS8t+RGZbgkkKzBa8w0 nnowOIeSeyE4+6uRyr5S+6LtOXT+ru7z7/tdZbAB+tfPdooQrHcK8xBtZ7d1GO3RoqfUPodagQXu MKs91JYOjvwtV2HPvS0m71iP/P+uuvoHUEsHCFT8PRwABQAAUxMAAFBLAwQUAAAAAACWUME0gbtD aWIEAABiBAAACAAAAG1ldGEueG1sPD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgi Pz4KPCFET0NUWVBFIG9mZmljZTpkb2N1bWVudC1tZXRhIFBVQkxJQyAiLS8vT3Blbk9mZmljZS5v cmcvL0RURCBPZmZpY2VEb2N1bWVudCAxLjAvL0VOIiAib2ZmaWNlLmR0ZCI+PG9mZmljZTpkb2N1 bWVudC1tZXRhIHhtbG5zOm9mZmljZT0iaHR0cDovL29wZW5vZmZpY2Uub3JnLzIwMDAvb2ZmaWNl IiB4bWxuczp4bGluaz0iaHR0cDovL3d3dy53My5vcmcvMTk5OS94bGluayIgeG1sbnM6ZGM9Imh0 dHA6Ly9wdXJsLm9yZy9kYy9lbGVtZW50cy8xLjEvIiB4bWxuczptZXRhPSJodHRwOi8vb3Blbm9m ZmljZS5vcmcvMjAwMC9tZXRhIiBvZmZpY2U6dmVyc2lvbj0iMS4wIj48b2ZmaWNlOm1ldGE+PG1l dGE6Z2VuZXJhdG9yPk9wZW5PZmZpY2Uub3JnIDEuMC4yIChMaW51eCk8L21ldGE6Z2VuZXJhdG9y PjwhLS1TUkM2NDFfWzc2NjNdX0xJTlVYX0lOVEVMX19zeWx2ZXN0ZXIuZGV2ZWwucmVkaGF0LmNv bV9hdF8yLzIwLzAzXzEyOjMzOjQ1LS0+PG1ldGE6Y3JlYXRpb24tZGF0ZT4yMDA2LTA2LTAxVDEw OjQ1OjU1PC9tZXRhOmNyZWF0aW9uLWRhdGU+PGRjOmRhdGU+MjAwNi0wNi0wMVQxMTowNDo0NDwv ZGM6ZGF0ZT48ZGM6bGFuZ3VhZ2U+ZW4tVVM8L2RjOmxhbmd1YWdlPjxtZXRhOmVkaXRpbmctY3lj bGVzPjI8L21ldGE6ZWRpdGluZy1jeWNsZXM+PG1ldGE6ZWRpdGluZy1kdXJhdGlvbj5QVDE4TTQ5 UzwvbWV0YTplZGl0aW5nLWR1cmF0aW9uPjxtZXRhOnVzZXItZGVmaW5lZCBtZXRhOm5hbWU9Iklu Zm8gMSIvPjxtZXRhOnVzZXItZGVmaW5lZCBtZXRhOm5hbWU9IkluZm8gMiIvPjxtZXRhOnVzZXIt ZGVmaW5lZCBtZXRhOm5hbWU9IkluZm8gMyIvPjxtZXRhOnVzZXItZGVmaW5lZCBtZXRhOm5hbWU9 IkluZm8gNCIvPjxtZXRhOmRvY3VtZW50LXN0YXRpc3RpYyBtZXRhOnRhYmxlLWNvdW50PSIwIiBt ZXRhOmltYWdlLWNvdW50PSIyIiBtZXRhOm9iamVjdC1jb3VudD0iMCIgbWV0YTpwYWdlLWNvdW50 PSIxIiBtZXRhOnBhcmFncmFwaC1jb3VudD0iMTIiIG1ldGE6d29yZC1jb3VudD0iNzkiIG1ldGE6 Y2hhcmFjdGVyLWNvdW50PSI0MTUiLz48L29mZmljZTptZXRhPjwvb2ZmaWNlOmRvY3VtZW50LW1l dGE+UEsDBBQACAAIAJZQwTQAAAAAAAAAAAAAAAAMAAAAc2V0dGluZ3MueG1s7Vjdd6I4FH/fv8Ll dY8F7Uxbe1rngAq1H9YKYutbJLdKJyRsCKLz129AbacVZrsqe/ZhOceDITe/e3NzP3PxbRGQyhx4 5DN6qdSONKUC1GPYp9NLZeiY1TPlW/O3i9/b9y3nqd+psOdn34NzzLw4ACqqEQghaaNKf2jcdlsV paqq9yHQ+4zuiPGpqraddmU1bq+XVSQjVe30lIqyAjzCAivNi0J0KSWNzlfTl8pMiPBcVZnkw974 1DVNU1djZb1gQXz6/ZU+SZKj5DijrTUaDTWb3ZB6jD77019g19QVibLRwTutvcq+Ebl5sSJfA1d9 AUG6n8r6M0WB3Mnch+R1l0remvf0rqTXOSCHhcpmRixDOeNToTTrF+o2wudRb+FZ5MFq+8GOfCxm ueIe1xun+2FfgT+d5QpdO67VjncDt2csGQCW5gGtGaJTiD4wmDBGAFGlKXgMu/O4AoSBj2Y+AYOz JJJGUMToGZFoD04mY6J8Tl2agcMdw3AQ+GqAwqpPMSwAb59/vsNka2Tw4MvPWVEXfxA1EjxVTzP1 zT0cqsiZvtRO97D5Isf/enK6s5dG/oTAwX0/Qz10nMpAB0Uun8aTk72gDSYECw4cTsaMBY5E+mhn M8Z3V3AKaiJPMJ4PW9N2BO5GNhDwBGCTyw87+HHOx5+dsmh67ef5BDJHfi6jrgYxR0Lm5n+SWnWM +4gjB0kzsEPklRMi+zK2iAGktQN8DDyHwL+VJc0wxEjkBeGNaewGLVMhlwYHvMWCkEOUFj8HN+tM P7bUPYFrNinMu/ueQB+FwE3OAhtE/DFEHYxLGlP7qJTyIcPPbLUE8PSkhR4LtrKkkqRvMRkPGClL OcBzzxZFcPLF8CniS6UZT2//UDVMJoG7RKO76fDqOpzQAfGm+n/yGWrYdIhhu39POtL1O/nqZgNV PTN1yxjqevtsIsd20PAHlqk92fqiRQ2596/a+LHbGNTdePx4HT4tjQcvIDG23GUraMh5V/43NTRq xH3XmHt0sHwaEa0V9OaeRYj3Q5M4vZen0YL0nc7NZGQux3USjy3zT/zY0ybp+rYm7uzk7fcQvkzq i7kXSH1fDVjf6WpSlh8Ty62PR0njTn+bxwF5GTta0iLGw6DTm6dnBJ3BDFudm6Fl0rHbCyEYnjiW q6Uyl3oI/z//5nO5RwjQKWUiKwSKk+GOeUoPQ7IcRsDbSKDDRzDTB4LLjMA2moO7usC4py3CosM0 bNtMLMImiGwuftLypIyk3o1ugFM98hHtx9QTcXbqJTDSiT+lMu/agoV9FvklsWnFnEt1pcaVZqz0 bbOYe1tGvOpV1U/nxN52Sb/pdy2gwH2vsqbcw+9MtCjm81lZsy6vpOopp9bXhS1k1VNawclZFMqu qix8i6Nw5ntlFIPvTVEW/wGiOKfw3+e6YF2UT8FA3vcpZzEtbI4OvZP9rLTNUZI1mOUUsQaR+jBl obxL0Czso9Wtu2q16Oa9+RdQSwcIYIjI8FgEAAAiGAAAUEsDBBQACAAIAJZQwTQAAAAAAAAAAAAA AAAVAAAATUVUQS1JTkYvbWFuaWZlc3QueG1svZNRa8IwEMff9ymyvDfXqMMhVlGrMNimD/qwx9Be a6BNQ3M6/faLY1VBYThkeblcuPv9/+G4/nBXFmyLtdOVibgUIWdokirVJo/4ajkLnvlw8NB/jOeT 5cdiykpldIaOes2FLVbj15cJ4wHA3KKZZ5lOUFR1DhAvY/bW1Hk2wPSdM948iZRS7uGXTG/KuGMa 8TWR7QFUnl+d+K0wlNAUeRA7kTJdYICG6v2ZY0y1CmhvMeLK2kInivyvYWtS4TZGeFHxWWvCmp+a sk1RBFbROuLA4SYNXaocwZr8Om6hE9rU6ECG/rTC7xDKdvcnduJpu9UdybY4IP5FutNYGI2f5Kg7 k3+Q/kXxRhrhjsAP5jo1qQz55sPk7sp1tC/Q3R1bIqn7e0Uiv6xHt324WKfBF1BLBwhaFbNOMAEA AOYDAABQSwECFAAUAAAAAACWUME0gJBrfpsbAACbGwAALQAAAAAAAAAAAAAAAAAAAAAAUGljdHVy ZXMvMTAwMDAyMDEwMDAwMDEzNzAwMDAwMTM0REUzMjdBMTMucG5nUEsBAhQAFAAAAAAAllDBNLas V216HwAAeh8AAC0AAAAAAAAAAAAAAAAA5hsAAFBpY3R1cmVzLzEwMDAwMjAxMDAwMDAxMzQwMDAw MDEzN0FCNTFBN0YxLnBuZ1BLAQIUABQACAAIAJZQwTRWsvvJhAQAAJ8OAAALAAAAAAAAAAAAAAAA AKs7AABjb250ZW50LnhtbFBLAQIUABQACAAIAJZQwTRU/D0cAAUAAFMTAAAKAAAAAAAAAAAAAAAA AGhAAABzdHlsZXMueG1sUEsBAhQAFAAAAAAAllDBNIG7Q2liBAAAYgQAAAgAAAAAAAAAAAAAAAAA oEUAAG1ldGEueG1sUEsBAhQAFAAIAAgAllDBNGCIyPBYBAAAIhgAAAwAAAAAAAAAAAAAAAAAKEoA AHNldHRpbmdzLnhtbFBLAQIUABQACAAIAJZQwTRaFbNOMAEAAOYDAAAVAAAAAAAAAAAAAAAAALpO AABNRVRBLUlORi9tYW5pZmVzdC54bWxQSwUGAAAAAAcABwDaAQAALVAAAAAA --=-k0bJJnk7Qaq1V0+G97NB-- --0-596188450-1149245335=:1049-- From kris@babi-pangang.org Fri Jun 2 07:03:22 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 7783B3B03DE for ; Fri, 2 Jun 2006 07:03:22 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20299-05 for ; Fri, 2 Jun 2006 07:03:21 -0400 (EDT) Received: from nasi-goreng.babi-pangang.org (nasi-goreng.babi-pangang.org [83.166.137.20]) by menubar.gnome.org (Postfix) with ESMTP id 0CC793B0196 for ; Fri, 2 Jun 2006 07:03:20 -0400 (EDT) Received: by nasi-goreng.babi-pangang.org (Postfix, from userid 1000) id 417E73DCA0; Fri, 2 Jun 2006 13:03:18 +0200 (CEST) Date: Fri, 2 Jun 2006 13:03:17 +0200 From: Kristian Rietveld To: Tim Janik Message-ID: <20060602110317.GA10757@babi-pangang.org> References: <20060314132538.GA3526@babi-pangang.org> <443B4A8A.8000302@imendio.com> <20060425103017.GA15762@babi-pangang.org> <20060531183045.GA7564@babi-pangang.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.563 tagged_above=-999 required=2 tests=[AWL=0.036, BAYES_00=-2.599] X-Spam-Score: -2.563 X-Spam-Level: Cc: Gtk+ Developers , Soeren Sandmann Subject: Re: Callback based tooltips (Re: New tooltips API, continued) X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 11:03:22 -0000 On Thu, Jun 01, 2006 at 05:16:51PM +0200, Tim Janik wrote: > On Wed, 31 May 2006, Kristian Rietveld wrote: > > >On Tue, Apr 25, 2006 at 03:08:12PM +0200, Soeren Sandmann wrote: > >>I once wrote down how tooltips should behave: > > > >I mostly like the behaviour you described below. > > > >> - Tooltips are too intrusive. The text should be smaller, and > > not sure if this has been raised already... > the font size of the tooltips should be exactly as large as the default > font size (module tooltip markup of course) to avoid reducing usability > of the tooltips in contrast to normal text (labels). The text for default/simple tooltips using toolip-markup are drawn using the default GTK+ font at this point. FireFox does this too, it seems. -kris. From lists@nabble.com Fri Jun 2 07:11:06 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 15ADC3B10CE for ; Fri, 2 Jun 2006 07:11:06 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20935-09 for ; Fri, 2 Jun 2006 07:11:04 -0400 (EDT) Received: from talk.nabble.com (www.nabble.com [72.21.53.35]) by menubar.gnome.org (Postfix) with ESMTP id 7B8A53B0E85 for ; Fri, 2 Jun 2006 07:11:04 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=talk.nabble.com) by talk.nabble.com with esmtp (Exim 4.50) id 1Fm7YV-00067i-S9 for gtk-devel-list@gnome.org; Fri, 02 Jun 2006 04:11:03 -0700 Message-ID: <4677819.post@talk.nabble.com> Date: Fri, 2 Jun 2006 04:11:03 -0700 (PDT) From: heavenscape To: gtk-devel-list@gnome.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-Sender: masonduan1@sina.com X-Nabble-From: heavenscape X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.564 tagged_above=-999 required=2 tests=[AWL=0.037, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.564 X-Spam-Level: Subject: strange trouble in displaying a 8bit monochromy grey scale image X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 11:11:06 -0000 I need to display a 8 bit monochromy image with size of 2048x2048 pixels, all the image data are already loaded into memory, and out of which I created a 24 bit RGB buffer for the GdkPixbuf (please see code below) Well, the result is: The GtkImage widget was expanded to size of 2048x2048 pixels, THREE exactly same images tile in a row in the top of the GtkImage widget, each with size shrinked to 684x684 pixels, and all the lower 2/3 space is left blank.(see the attached image below) Can anyone please look at my code and give me some suggestion on this problem? I have been debugging is problem for almost one week time! Or I wonder if there is any other alternative mean to display a grey scale monochromy image. Any help is highly appriciated! following is my code: ...... char* pDisplayBuf = malloc(sizeX*sizeY*3); for(i=0;i X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 129D43B0401 for ; Fri, 2 Jun 2006 07:42:43 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22729-02 for ; Fri, 2 Jun 2006 07:42:41 -0400 (EDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.204]) by menubar.gnome.org (Postfix) with ESMTP id AACEB3B03DC for ; Fri, 2 Jun 2006 07:42:41 -0400 (EDT) Received: by wx-out-0102.google.com with SMTP id i30so488730wxd for ; Fri, 02 Jun 2006 04:42:41 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=gT1j5ejSD/b/CcxQn0QQsSvUHhFufm/g+0pbZR2i/XzGfNpGoCbQpb21JCQ8031mkn0Ki6u8pLPOMj7RR8l3DAglKtDDYSYHma6DaM5dCPwAcVKD9bRfW3lU8+yvbKvGFEapsCpgbG/Y1Pe5Z3GQWmSp7m88CvcAjjuc1aYqX10= Received: by 10.70.62.1 with SMTP id k1mr2290069wxa; Fri, 02 Jun 2006 04:42:41 -0700 (PDT) Received: by 10.70.96.6 with HTTP; Fri, 2 Jun 2006 04:42:40 -0700 (PDT) Message-ID: <522c6460606020442q5704285jefadb260aa5ceda1@mail.gmail.com> Date: Fri, 2 Jun 2006 12:42:40 +0100 From: "John Cupitt" To: heavenscape In-Reply-To: <4677819.post@talk.nabble.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4677819.post@talk.nabble.com> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.554 tagged_above=-999 required=2 tests=[AWL=0.046, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.554 X-Spam-Level: Cc: gtk-devel-list@gnome.org Subject: Re: strange trouble in displaying a 8bit monochromy grey scale image X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 11:42:43 -0000 On 6/2/06, heavenscape wrote: > char* pDisplayBuf = malloc(sizeX*sizeY*3); > for(i=0;i { > //create a gray scale img in the display buffer > pDisplayBuf[i+1]=pDisplayBuf[i+1]=pDisplayBuf[i+2] = pixel_value; > } This isn't going to work. You're only filling the first third of the memory area. How about (untested): // malloc() can return NULL: you need to test the result // g_malloc() cannot fail char *p = g_malloc(sizeX * sizeY * 3); char *q; int i; // i loops for number of pixels // q loops pointing at each RGB triplet in turn for (q = p, i = 0; i < sizeX * sizeY; i++, q += 3) q[0] = q[1] = q[2] = pixel_value; // or alternatively in this special case memset( p, sizeX * sizeY * 3, pixel_value ) From jcupitt@gmail.com Fri Jun 2 07:44:31 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C18CD3B0402 for ; Fri, 2 Jun 2006 07:44:31 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22729-06 for ; Fri, 2 Jun 2006 07:44:30 -0400 (EDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.202]) by menubar.gnome.org (Postfix) with ESMTP id 8F0073B0413 for ; Fri, 2 Jun 2006 07:44:30 -0400 (EDT) Received: by wx-out-0102.google.com with SMTP id i30so489124wxd for ; Fri, 02 Jun 2006 04:44:29 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=EMOfucJIundQbGeCrVxW4fD6Iz3tUALWFaW8hgWFjuzmGzy3HlOTtgzn8QGVrywRA62j6kzikELTcAJL+GvTNGqGag3vtyJIcBhy5nQKUdv8v5Gm6dzT8SPDVoRKsWY874GU5fTfTuEc6cSK5TYAaWH6Ezj7csUQ73y/uo1NF/8= Received: by 10.70.128.5 with SMTP id a5mr2255574wxd; Fri, 02 Jun 2006 04:44:29 -0700 (PDT) Received: by 10.70.96.6 with HTTP; Fri, 2 Jun 2006 04:44:29 -0700 (PDT) Message-ID: <522c6460606020444q6963f934g8d7b671fb87905b0@mail.gmail.com> Date: Fri, 2 Jun 2006 12:44:29 +0100 From: "John Cupitt" To: heavenscape In-Reply-To: <522c6460606020442q5704285jefadb260aa5ceda1@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4677819.post@talk.nabble.com> <522c6460606020442q5704285jefadb260aa5ceda1@mail.gmail.com> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.555 tagged_above=-999 required=2 tests=[AWL=0.045, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.555 X-Spam-Level: Cc: gtk-devel-list@gnome.org Subject: Re: strange trouble in displaying a 8bit monochromy grey scale image X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 11:44:31 -0000 On 6/2/06, John Cupitt wrote: > memset( p, sizeX * sizeY * 3, pixel_value ) Ahem, of course that should be memset (p, pixel_value, sizeX * sizeY * 3); From cerdiogenes@yahoo.com.br Fri Jun 2 09:09:23 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id BD1CF3B03D8 for ; Fri, 2 Jun 2006 09:09:23 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27976-05 for ; Fri, 2 Jun 2006 09:09:21 -0400 (EDT) Received: from cac-bdc03.unioeste.br (pop3.unioeste.br [200.201.8.21]) by menubar.gnome.org (Postfix) with ESMTP id 8FFCD3B0351 for ; Fri, 2 Jun 2006 09:09:20 -0400 (EDT) Received: from [200.201.81.39] (200.201.81.39 [200.201.81.39]) by cac-bdc03.unioeste.br with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id L71GDA45; Fri, 2 Jun 2006 10:07:46 -0300 From: Carlos Eduardo Rodrigues =?ISO-8859-1?Q?Di=F3genes?= To: =?ISO-8859-1?Q?=D8yvind_Kol=E5s?= In-Reply-To: <7bf6f2dc0606010816q15d512aejc30a6c93bc165e6@mail.gmail.com> References: <1149104973.27709.4.camel@localhost.localdomain> <7bf6f2dc0606010816q15d512aejc30a6c93bc165e6@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Date: Fri, 02 Jun 2006 10:01:52 -0300 Message-Id: <1149253312.4847.21.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.221 tagged_above=-999 required=2 tests=[AWL=0.043, BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.221 X-Spam-Level: Cc: gtk-devel-list@gnome.org Subject: Re: Color space transformations in GTK X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 13:09:23 -0000 On Thu, 2006-06-01 at 17:16 +0200, =D8yvind Kol=E5s wrote: > On 5/31/06, Carlos Eduardo Rodrigues Di=F3genes wrote: > > Hi, > > > > There is any plan to add color spaces conversions in GTK+ (GDK or > > Gdk-Pixbuf)? If the answear is no, why not? >=20 > Pixel format conversions is not a small piece of code and the needed > pixel formats varies from scenario to scenario. Most programs will not > need such a large general infrastructure and the ones that really need > it would probably not be satisfied with a simpler solution. I think that I understand your last argument. And what I really have in mind is a simple solution, more below... >=20 > What functionality is it you miss that you think fits into a GUI > toolkit? (color management is a seperate issue to color space(pixel > format) conversions according to my interpretation of your question). I had to make RGB <-> HSL conversions, because it's more intuitive change some color properties in the HSL color space. I thinked that we could have something like GdkColor for other color spaces and functions to convert between GdkColor and the other color spaces. I think that it will help who want to play with colors in a quick way. I don't find this in any other library, and I thinked that GTK+ could be a good place for this, because it will become easiest to work with other colors representations in GTK+ applications. >=20 > /=D8yvind K. --=20 Carlos Eduardo Rodrigues Di=F3genes Projeto xLupa - http://www.unioeste.br/projetos/xlupa From murrayc@murrayc.com Fri Jun 2 09:28:59 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id A768B3B112B for ; Fri, 2 Jun 2006 09:28:59 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28843-09 for ; Fri, 2 Jun 2006 09:28:58 -0400 (EDT) Received: from webmail1.sd.dreamhost.com (webmail1.sd.dreamhost.com [66.33.201.159]) by menubar.gnome.org (Postfix) with ESMTP id 953E83B111A for ; Fri, 2 Jun 2006 09:28:58 -0400 (EDT) Received: from webmail.murrayc.com (localhost [127.0.0.1]) by webmail1.sd.dreamhost.com (Postfix) with ESMTP id 9A66F2CAF2; Fri, 2 Jun 2006 06:23:41 -0700 (PDT) Received: from 194.138.18.132 (proxying for unknown) (SquirrelMail authenticated user murrayc@murrayc.com) by webmail.murrayc.com with HTTP; Fri, 2 Jun 2006 15:23:41 +0200 (CEST) Message-ID: <1464.194.138.18.132.1149254621.squirrel@webmail.murrayc.com> In-Reply-To: <1149253312.4847.21.camel@localhost.localdomain> References: <1149104973.27709.4.camel@localhost.localdomain> <7bf6f2dc0606010816q15d512aejc30a6c93bc165e6@mail.gmail.com> <1149253312.4847.21.camel@localhost.localdomain> Date: Fri, 2 Jun 2006 15:23:41 +0200 (CEST) From: "Murray Cumming" To: Carlos Eduardo Rodrigues =?iso-8859-1?Q?Di=F3genes?= User-Agent: SquirrelMail/1.4.6 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.481 tagged_above=-999 required=2 tests=[AWL=-0.036, BAYES_00=-2.599, TW_GT=0.077, TW_TK=0.077] X-Spam-Score: -2.481 X-Spam-Level: Cc: gtk-devel-list@gnome.org, =?iso-8859-1?Q?=D8yvind_Kol=E5s?= Subject: Re: Color space transformations in GTK X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 13:28:59 -0000 > On Thu, 2006-06-01 at 17:16 +0200, yvind Kols wrote: >> On 5/31/06, Carlos Eduardo Rodrigues Digenes >> wrote: >> > Hi, >> > >> > There is any plan to add color spaces conversions in GTK+ (GDK or >> > Gdk-Pixbuf)? If the answear is no, why not? >> >> Pixel format conversions is not a small piece of code and the needed >> pixel formats varies from scenario to scenario. Most programs will not >> need such a large general infrastructure and the ones that really need >> it would probably not be satisfied with a simpler solution. > > I think that I understand your last argument. And what I really have in > mind is a simple solution, more below... > >> >> What functionality is it you miss that you think fits into a GUI >> toolkit? (color management is a seperate issue to color space(pixel >> format) conversions according to my interpretation of your question). > > I had to make RGB <-> HSL conversions, because it's more intuitive > change some color properties in the HSL color space. I thinked that we > could have something like GdkColor for other color spaces and functions > to convert between GdkColor and the other color spaces. > > I think that it will help who want to play with colors in a quick way. I > don't find this in any other library, and I thinked that GTK+ could be a > good place for this, because it will become easiest to work with other > colors representations in GTK+ applications. In case it's useful, we have some old undocumented RGB <-> HSL color value conversion code in gtkmm here: http://cvs.gnome.org/viewcvs/gtkmm/gdk/src/color.ccg?view=markup (See set_hsl(), for instance) Murray Cumming murrayc@murrayc.com www.murrayc.com www.openismus.com From timj@gtk.org Fri Jun 2 10:28:42 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 270163B043C for ; Fri, 2 Jun 2006 10:28:42 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32586-01 for ; Fri, 2 Jun 2006 10:28:40 -0400 (EDT) Received: from webmail.hansenet.de (mail04.hansenet.de [213.191.73.12]) by menubar.gnome.org (Postfix) with ESMTP id 4C4283B0272 for ; Fri, 2 Jun 2006 10:28:40 -0400 (EDT) Received: from birnet.org (213.39.189.161) by webmail.hansenet.de (7.2.059) id 447C34F100154F1E; Fri, 2 Jun 2006 16:28:37 +0200 Received: from master.birnet.private (localhost [127.0.0.1]) by birnet.org (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k52ESaZY028846 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 2 Jun 2006 16:28:36 +0200 Received: (from timj@localhost) by master.birnet.private (8.13.4/8.13.4/Submit) id k52ESPMh028844; Fri, 2 Jun 2006 16:28:25 +0200 Date: Fri, 2 Jun 2006 16:28:25 +0200 (CEST) From: Tim Janik X-X-Sender: timj@master.birnet.private To: Stefan Kost In-Reply-To: <1148567274.9054.4.camel@fluffy.local> Message-ID: References: <1148567274.9054.4.camel@fluffy.local> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.442 tagged_above=-999 required=2 tests=[AWL=0.157, BAYES_00=-2.599] X-Spam-Score: -2.442 X-Spam-Level: Cc: Gtk+ Developers Subject: Re: Serialization in libgobject X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 14:28:42 -0000 On Thu, 25 May 2006, Stefan Kost wrote: > Hi Tim, > > thanks for the extensive comments and detailed concerns. Don't you think > it would be good to keep the buzzgilla issue open. Its an enhancement > request after all and there seems to be several people wanting to have > it. well, my concern is that most of them want/think different things about serialization which was the main point of my last email. i.e. if you want to cover beast's serialization need, you already need 2 different serializers. if you then also want to cover GStreamer needs, and maybe properly human digestible config files, you can easily end up with 3 or 4 sets of mutually exclusive requirements. so without precise definition of the usage cases: - the exact required behaviour of a GLib serializer isn't clear; - we'll end up with lots of projects still rolling their own serializer because the glib one doesn't cover their needs; - the serializer will be used in scenarios that it's unplanned and suboptimal for. i'm not saying the technical issues i raised are unsolvable, in fact each one has been adressed in one way or the other in beast's serializers. rather, i'm asking: 1) what exactly do we want in glib? (i.e. which use cases should be covered) 2) which use cases should be rejected by the glib implementation(s)? 3) do the answers to (1) and (2) really cover a broad range of serialization applications out there? and i think one of the best way to be sure and positively answer (3) could be the independent development of a serialization lib outside of glib. such a library could be included into glib at a later point, once its mature enough and has an adequate track record of applications. > The bugzilla issue could serve as a tracker item. And now maybe some > more people know about thsi and add their thoughts and ideas. if you still think this should be tracked in glib bugzilla as an enhancement, you can always reopen the report. > @Andrew: is you implementation public? If so where can I find the > sources, if not can you make the serialisation part public? > > Maybe we can find a SoC student for the next summer to look at the > solutions used in our application as come up with a good proposal that > suites most apps. > > Stefan > --- ciaoTJ From timj@gtk.org Fri Jun 2 12:59:30 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id AFEC23B0140 for ; Fri, 2 Jun 2006 12:59:30 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09573-08 for ; Fri, 2 Jun 2006 12:59:29 -0400 (EDT) Received: from webmail.hansenet.de (mail01.hansenet.de [213.191.73.61]) by menubar.gnome.org (Postfix) with ESMTP id 53B8C3B00A5 for ; Fri, 2 Jun 2006 12:59:29 -0400 (EDT) Received: from birnet.org (213.39.189.161) by webmail.hansenet.de (7.2.059) id 447D3FB2000A3052; Fri, 2 Jun 2006 18:59:16 +0200 Received: from master.birnet.private (localhost [127.0.0.1]) by birnet.org (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k52GxEAY001423 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 2 Jun 2006 18:59:14 +0200 Received: (from timj@localhost) by master.birnet.private (8.13.4/8.13.4/Submit) id k52GxETr001415; Fri, 2 Jun 2006 18:59:14 +0200 Date: Fri, 2 Jun 2006 18:59:13 +0200 (CEST) From: Tim Janik X-X-Sender: timj@master.birnet.private To: Owen Taylor Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.445 tagged_above=-999 required=2 tests=[AWL=0.154, BAYES_00=-2.599] X-Spam-Score: -2.445 X-Spam-Level: Cc: Gtk+ Developers Subject: locking around source_funcs->finalize X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 16:59:30 -0000 hi Owen. reading up on g_source_unref() again, i notice that the GMainContext lock is removed and re-acquired around callback_funcs->unref(), but not around source_funcs->finalize(); supposing you're unlocking around unref() so that the handler may do things like adding a new idle handler to the context, shouldnt the same semantics be provided for source_funcs->finalize() as well? > static void > g_source_unref_internal (GSource *source, > GMainContext *context, > gboolean have_lock) > { > gpointer old_cb_data = NULL; > GSourceCallbackFuncs *old_cb_funcs = NULL; > > g_return_if_fail (source != NULL); > > if (!have_lock && context) > LOCK_CONTEXT (context); > > source->ref_count--; > if (source->ref_count == 0) > { > old_cb_data = source->callback_data; > old_cb_funcs = source->callback_funcs; > > source->callback_data = NULL; > source->callback_funcs = NULL; > > if (context && !SOURCE_DESTROYED (source)) > { > g_warning (G_STRLOC ": ref_count == 0, but source is still attached to a context!"); > source->ref_count++; > } > else if (context) > g_source_list_remove (source, context); > > if (source->source_funcs->finalize) > source->source_funcs->finalize (source); lock is being held if have_lock || context. > > g_slist_free (source->poll_fds); > source->poll_fds = NULL; > g_free (source); > } > > if (!have_lock && context) > UNLOCK_CONTEXT (context); > > if (old_cb_funcs) > { > if (have_lock) > UNLOCK_CONTEXT (context); > > old_cb_funcs->unref (old_cb_data); no lock is being held. > > if (have_lock) > LOCK_CONTEXT (context); > } > } --- ciaoTJ From matthias.clasen@gmail.com Fri Jun 2 13:14:22 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 181063B0178 for ; Fri, 2 Jun 2006 13:14:22 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10341-10 for ; Fri, 2 Jun 2006 13:14:21 -0400 (EDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.188]) by menubar.gnome.org (Postfix) with ESMTP id A84F33B0115 for ; Fri, 2 Jun 2006 13:14:20 -0400 (EDT) Received: by nf-out-0910.google.com with SMTP id l37so1131753nfc for ; Fri, 02 Jun 2006 10:14:19 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=IIiw0EjBJce9nDArNbjwYFffpCUCNPuYeqI8uOIN+ycf/KtiNjAY9VtWweGXWApORefDRcNkzdsGRROn1FJvCDC494mL9vZcz0WpDA5tNFO1IZSXHXsfZPz+YqQUJ6orpi6MA7hmCcT7pTYK8vEfd8Pic7cApyoegcqYqJXL1U8= Received: by 10.49.1.9 with SMTP id d9mr941927nfi; Fri, 02 Jun 2006 10:14:19 -0700 (PDT) Received: by 10.48.215.7 with HTTP; Fri, 2 Jun 2006 10:14:19 -0700 (PDT) Message-ID: Date: Fri, 2 Jun 2006 13:14:19 -0400 From: "Matthias Clasen" To: "Tim Janik" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.699 tagged_above=-999 required=2 tests=[AWL=-0.734, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.558, SPF_PASS=-0.001, TW_GT=0.077] X-Spam-Score: -1.699 X-Spam-Level: Cc: Owen Taylor , Gtk+ Developers Subject: Re: locking around source_funcs->finalize X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 17:14:22 -0000 On 6/2/06, Tim Janik wrote: > hi Owen. > > reading up on g_source_unref() again, i notice that the > GMainContext lock is removed and re-acquired around > callback_funcs->unref(), but not around source_funcs->finalize(); > supposing you're unlocking around unref() so that the > handler may do things like adding a new idle handler > to the context, shouldnt the same semantics be provided > for source_funcs->finalize() as well? > Interesting observation Tim. We actually ran into a deadlock in the gtk print module code where a source finalize function was trying to add another idle... So fixing this would help GTK+; it would allow us to unload the print backends. Matthias From matthias.clasen@gmail.com Fri Jun 2 13:22:11 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id B05EA3B01BA for ; Fri, 2 Jun 2006 13:22:11 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10854-10 for ; Fri, 2 Jun 2006 13:22:10 -0400 (EDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.186]) by menubar.gnome.org (Postfix) with ESMTP id 691F63B007B for ; Fri, 2 Jun 2006 13:22:10 -0400 (EDT) Received: by nf-out-0910.google.com with SMTP id l37so1137364nfc for ; Fri, 02 Jun 2006 10:22:09 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=WQtzpP4N8ZyKSiiDfpj/VtLI/AxhPsWp029H1Nvd+SG7mq6Rf64PWWm4vH8TCDmIyieOgUdMr0+Y64igzWX+Liq5FKe/p14IvHTVc7Jf8A3g/lkQrbeGGqzHTAEGhQsu+lwlvRhqNYJVH8XXuOcmjrJxkEXrBrcqWzQyQ9CuNTg= Received: by 10.48.14.19 with SMTP id 19mr950281nfn; Fri, 02 Jun 2006 10:22:09 -0700 (PDT) Received: by 10.48.215.7 with HTTP; Fri, 2 Jun 2006 10:22:09 -0700 (PDT) Message-ID: Date: Fri, 2 Jun 2006 13:22:09 -0400 From: "Matthias Clasen" To: "Petr Tomasek" In-Reply-To: <20060602070042.GA3470@ebed.etf.cuni.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1149203639.27455.9.camel@localhost.localdomain> <20060602070042.GA3470@ebed.etf.cuni.cz> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.733 tagged_above=-999 required=2 tests=[AWL=-0.691, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.558, SPF_PASS=-0.001] X-Spam-Score: -1.733 X-Spam-Level: Cc: gtk-devel-list@gnome.org Subject: Re: Print preview api X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 17:22:11 -0000 On 6/2/06, Petr Tomasek wrote: > On Thu, Jun 01, 2006 at 07:13:59PM -0400, Matthias Clasen wrote: > > Ok, after a lot of work (mostly by John and Alex), > > we finally have a proposal for a print preview > > api that will allow us to use an external viewer > > by default, but also support internal preview. > > Hi! > > I think, this is very unfortunate. Many people will > not want to use the external viewer (for reasons discused > earlier), so everyone will write his own preview > widget? Why not just have official internal > preview widget like gnome-print has and support > it by deafult? You are more than welcome to on a high-quality print preview widget and propse it for inclusion; it is a considerable amount of work though (duplicating things that are already in evince), and we are not going to hold the 2.10 release for it. Defaulting to external preview allows us to release 2.10 with preview support, which seems better than no preview support at all. In other news, Alex has just committed the preview patch with some fixes. Matthias From kris@babi-pangang.org Fri Jun 2 19:04:03 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 6F8D73B051E for ; Fri, 2 Jun 2006 19:04:03 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29568-08 for ; Fri, 2 Jun 2006 19:04:02 -0400 (EDT) Received: from nasi-goreng.babi-pangang.org (nasi-goreng.babi-pangang.org [83.166.137.20]) by menubar.gnome.org (Postfix) with ESMTP id 2B5243B04C8 for ; Fri, 2 Jun 2006 19:04:01 -0400 (EDT) Received: by nasi-goreng.babi-pangang.org (Postfix, from userid 1000) id BC1643DCA0; Sat, 3 Jun 2006 01:03:59 +0200 (CEST) Date: Sat, 3 Jun 2006 01:03:59 +0200 From: Kristian Rietveld To: Matthias Clasen Message-ID: <20060602230359.GB10757@babi-pangang.org> References: <20060531200823.GA7846@babi-pangang.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.525 tagged_above=-999 required=2 tests=[AWL=-0.003, BAYES_00=-2.599, TW_GT=0.077] X-Spam-Score: -2.525 X-Spam-Level: Cc: gtk-devel-list@gnome.org, timj@imendio.com Subject: Re: Tooltips progress X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 23:04:03 -0000 On Thu, Jun 01, 2006 at 09:33:48AM -0400, Matthias Clasen wrote: > Using x == -1 to indicate a keyboard-triggered tooltip looks a bit > odd to me; how about adding a boolean parameter for this ? Good idea, fixed this. > Regarding dedicated treeview api, I think we can do without it > (at least initially), if we have a good example in the docs. Though > lots of people will forget the selection_changed thing for keyboard > tooltips... I'll make sure some nice example code will appear in gtk-demo, where we can point people at. > Could you enhance your demo with an example of text view > tooltips on a tag ? Will do. -kris. From kris@babi-pangang.org Fri Jun 2 19:08:42 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 1CF883B11C6 for ; Fri, 2 Jun 2006 19:08:42 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29930-06 for ; Fri, 2 Jun 2006 19:08:40 -0400 (EDT) Received: from nasi-goreng.babi-pangang.org (nasi-goreng.babi-pangang.org [83.166.137.20]) by menubar.gnome.org (Postfix) with ESMTP id 89C933B11CD for ; Fri, 2 Jun 2006 19:08:40 -0400 (EDT) Received: by nasi-goreng.babi-pangang.org (Postfix, from userid 1000) id 411F73DCA0; Sat, 3 Jun 2006 01:08:37 +0200 (CEST) Date: Sat, 3 Jun 2006 01:08:37 +0200 From: Kristian Rietveld To: Tim Janik Message-ID: <20060602230837.GC10757@babi-pangang.org> References: <20060531200823.GA7846@babi-pangang.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.563 tagged_above=-999 required=2 tests=[AWL=0.036, BAYES_00=-2.599] X-Spam-Score: -2.563 X-Spam-Level: Cc: Gtk+ Developers Subject: Re: Tooltips progress X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 23:08:42 -0000 On Thu, Jun 01, 2006 at 06:21:29PM +0200, Tim Janik wrote: > On Thu, 1 Jun 2006, Matthias Clasen wrote: > the idea behind ::has-tooltip is to reduce the number of required signal > emissions to figure a tooltip. e.g. by adding a PRIVATE_GTK_* flag that > indicates if the ::query-tooltips() emission is neccessary. > maybe it'd helpt to rename that property to ::can-tooltip? Or maybe ::enable-query-tooltip? > (if you want to argue consistency with other things settable/gettable > on widgets though, then yes, you have a point for also exporting it > as a property) I would tend to add the property just for consistency. > >The example doesn't show tooltips constructed using the old tooltips > >api, but I assume those will continue to work as before, right ? > > that was the plan, i.e. you'd basically just do: I am not 100% if we can implement the complete old API using the new one, for example the public fields in the old structures and GtkTipsQuery come to mind ... I'll investigate once I get a first patch out. -kris. From exe522@hotmail.com Mon Jun 5 10:30:49 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id E7BDF3B0420 for ; Mon, 5 Jun 2006 10:30:48 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06214-09 for ; Mon, 5 Jun 2006 10:30:45 -0400 (EDT) Received: from hotmail.com (bay104-f19.bay104.hotmail.com [65.54.175.29]) by menubar.gnome.org (Postfix) with ESMTP id 81AC13B030D for ; Mon, 5 Jun 2006 10:30:44 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 5 Jun 2006 07:30:43 -0700 Message-ID: Received: from 65.54.175.200 by by104fd.bay104.hotmail.msn.com with HTTP; Mon, 05 Jun 2006 14:30:41 GMT X-Originating-IP: [83.202.13.252] X-Originating-Email: [exe522@hotmail.com] X-Sender: exe522@hotmail.com In-Reply-To: <44747D3E.8020902@imendio.com> From: "Malik NakaMura" To: richard@imendio.com Date: Mon, 05 Jun 2006 14:30:41 +0000 Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed X-OriginalArrivalTime: 05 Jun 2006 14:30:43.0753 (UTC) FILETIME=[A0A49190:01C688AC] X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-0.739 tagged_above=-999 required=2 tests=[AWL=-1.535, BAYES_05=-1.11, DNS_FROM_RFC_ABUSE=0.2, DNS_FROM_RFC_POST=1.708, MSGID_FROM_MTA_HEADER=0, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -0.739 X-Spam-Level: Cc: otaylor@redhat.com, ben2004uk@googlemail.com, scott@asofyet.org, gtk-devel-list@gnome.org Subject: Re: GTK+ >> Cocoa Native Port X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2006 14:30:49 -0000 Hi, I'm trying to implement this function : _gdk_quartz_copy_to_image (gdkimage-quartz.c) I would like to know if it is possible to get the pixels table from a GdkPixmap structure ? this is the code : GdkImage * _gdk_quartz_copy_to_image (GdkDrawable *drawable, GdkImage *image, gint src_x, gint src_y, gint dest_x, gint dest_y, gint width, gint height) { /* FIXME: Implement */ // Image Creation image = g_object_new (gdk_image_get_type (), NULL); image->width = width; image->height = height; image->byte_order = (G_BYTE_ORDER == G_LITTLE_ENDIAN) ? GDK_LSB_FIRST : GDK_MSB_FIRST; image->bpp = 4; image->bpl = image->width * image->bpp; image->bits_per_pixel = image->bpp * 8; // Get the Visual GdkColormap *colormap = gdk_drawable_get_colormap (drawable); if(colormap != NULL) { image->visual = gdk_colormap_get_visual (colormap); } // Get the depth image->depth = GDK_PIXMAP_OBJECT (drawable)->depth; // Get the pixels ??? image->mem = g_malloc (image->bpl * image->height); memset (image->mem, 0x00, image->bpl * image->height); image->mem = gdk_pixbuf_get_pixels (GDK_PIXBUF (drawable)); return image; } I think that drawable is a GdkPixmap structure, so I cant do GDK_PIXBUF (drawable), but is there a function to get the pixbuf from a pixmap ? From domlachowicz@gmail.com Mon Jun 5 10:52:51 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id B05E13B0543 for ; Mon, 5 Jun 2006 10:52:51 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08008-05 for ; Mon, 5 Jun 2006 10:52:48 -0400 (EDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.205]) by menubar.gnome.org (Postfix) with ESMTP id 0DD8B3B03E7 for ; Mon, 5 Jun 2006 10:52:47 -0400 (EDT) Received: by wx-out-0102.google.com with SMTP id i30so1182797wxd for ; Mon, 05 Jun 2006 07:52:47 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=mBHtGZClxJk0twUjUBnjIyhM/WAD6Uo9my7i+D5hoC4J+tCoUbUHFxNQxrI4rHUN+ozS7wnRgFO+uMkkEg6Pg2xZje4D8Xja5Bt7lmKFvCh6pSZMS6uV+5TpBquvMmVoaoFkNDoZEDJjdLqt3Wj9IaLQ/ggRMyfDTkEaz5x0TcU= Received: by 10.70.49.6 with SMTP id w6mr6127550wxw; Mon, 05 Jun 2006 07:52:44 -0700 (PDT) Received: by 10.70.116.12 with HTTP; Mon, 5 Jun 2006 07:52:44 -0700 (PDT) Message-ID: <2672cf4d0606050752o12a6d0d2gcb4c355cc0f35d79@mail.gmail.com> Date: Mon, 5 Jun 2006 10:52:44 -0400 From: "Dominic Lachowicz" To: "Malik NakaMura" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <44747D3E.8020902@imendio.com> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.457 tagged_above=-999 required=2 tests=[AWL=0.143, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.457 X-Spam-Level: Cc: gtk-devel-list@gnome.org Subject: Re: GTK+ >> Cocoa Native Port X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2006 14:52:51 -0000 > I think that drawable is a GdkPixmap structure, so I cant do GDK_PIXBUF > (drawable), but is there a function to get the pixbuf from a pixmap ? You might want to look at gdk_pixbuf_get_from_drawable(). Best, Dom -- Counting bodies like sheep to the rhythm of the war drums. From mclasen@redhat.com Mon Jun 5 14:15:03 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 744343B09D3; Mon, 5 Jun 2006 14:15:03 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20278-06; Mon, 5 Jun 2006 14:15:01 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id D637E3B0988; Mon, 5 Jun 2006 14:15:00 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k55IF08I024331; Mon, 5 Jun 2006 14:15:00 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k55IF0I9021827; Mon, 5 Jun 2006 14:15:00 -0400 Received: from golem.boston.redhat.com (golem.boston.redhat.com [172.16.80.24]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id k55IExAV012588; Mon, 5 Jun 2006 14:14:59 -0400 From: Matthias Clasen To: gnome-announce-list@gnome.org, gtk-devel-list@gnome.org, gtk-app-devel-list@gnome.org, gtk-list@gnome.org Content-Type: text/plain; charset=UTF-8 Date: Mon, 05 Jun 2006 14:14:59 -0400 Message-Id: <1149531299.4071.35.camel@golem.boston.redhat.com> Mime-Version: 1.0 X-Mailer: Evolution 2.7.1 (2.7.1-1) Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.543 tagged_above=-999 required=2 tests=[AWL=0.058, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.543 X-Spam-Level: Cc: Subject: GLib 2.11.2 released X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gnome-hackers@gnome.org List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2006 18:15:03 -0000 GLib 2.11.2 is now available for download at: ftp://ftp.gtk.org/pub/gtk/v2.11/ http://ftp.gnome.org/pub/GNOME/sources/glib/2.11/ glib-2.11.2.tar.bz2 md5sum: 18464b85bfd589f83897623c637a1553 glib-2.11.2.tar.gz md5sum: f728cd295ac98d4b95d850fe91c05fd5 This is a development release leading up to GLib 2.12. Notes: * This is unstable development release. While it has had a bit of testing, there are certainly plenty of bugs remaining to be found. This release should not be used in production. * Installing this version will overwrite your existing copy of GLib 2.10. If you have problems, you'll need to reinstall GLib 2.10. * GLib 2.12 will be source and binary compatible with the GLib 2.10.x series (for some caveats, see the README). At this point, the API additions in the 2.11.x series are almost finished. * Bugs should be reported to http://bugzilla.gnome.org. About GLib ========== GLib is the low-level core library that forms the basis for projects such as GTK+ and GNOME. It provides data structure handling for C, portability wrappers, and interfaces for such runtime functionality as an event loop, threads, dynamic loading, and an object system. More information about GLib is available at: http://www.gtk.org/ An installation guide for the GTK+ libraries, including GLib, can be found at: http://developer.gnome.org/doc/API/2.0/gtk/gtk-building.html Overview of Changes from GLib 2.11.1 to GLib 2.11.2 =================================================== * Add g_ascii_stroll to parse signed 64bit integers * GMarkup: add a flag to treat CDATA as text * GHashTable: add functions to remove all entries * GMainLoop: add functions to find the currently running source, and determine if it is destroyed * Bug fixes: 342563 g_atomic_thread_init() needs to be called before other _g_*_thread_init() functions 343548 Potential use after free in callers of g_string_free() 168538 Wish: Clearing contents of GHashTables 321886 GTK+ cannot be reliably used in multi-threaded applications 341826 goption.c: 'strtoll' is C99's function 343899 g_ascii_formatd dosn't work as expected for all format strings 317793 Make GEnumValue strings const 337129 Compile warnings in G_IMPLEMENT_INTERFACE 303622 What is G_TYPE_CHAR? * Updated translations (bg,dz,eu,gl,ja,nl,th,vi) A list of all bugs fixed in this release can be found at: http://bugzilla.gnome.org/buglist.cgi?bug_id=341826,342563,343548,168538,168538,321886,343899,321886,317793,337129,303622 Thanks to everybody who has contributed to this release, in the form of bug reports or patches: Peter Kjellerstedt, Kazuki Iwamoto Leonard den Ottolander, Chris Wilson, Behdad Esfahbod, Matt Barnes, Øystein Johansen, Tim Janik Morten Welinder Matthias Clasen June 5, 2006 From mclasen@redhat.com Mon Jun 5 16:21:34 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 09B113B0543; Mon, 5 Jun 2006 16:21:34 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28553-01; Mon, 5 Jun 2006 16:21:32 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id 0F8903B0012; Mon, 5 Jun 2006 16:21:31 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k55KLVn7006951; Mon, 5 Jun 2006 16:21:31 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k55KLUBq020469; Mon, 5 Jun 2006 16:21:31 -0400 Received: from golem.boston.redhat.com (golem.boston.redhat.com [172.16.80.24]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id k55KLUAV025318; Mon, 5 Jun 2006 16:21:30 -0400 From: Matthias Clasen To: gnome-announce-list@gnome.org, gtk-devel-list@gnome.org, gtk-app-devel-list@gnome.org, gtk-list@gnome.org Content-Type: text/plain Date: Mon, 05 Jun 2006 16:21:30 -0400 Message-Id: <1149538890.4071.40.camel@golem.boston.redhat.com> Mime-Version: 1.0 X-Mailer: Evolution 2.7.1 (2.7.1-1) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.429 tagged_above=-999 required=2 tests=[AWL=-0.059, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, TW_GD=0.077, TW_GT=0.077, TW_XI=0.077] X-Spam-Score: -2.429 X-Spam-Level: Cc: Subject: GTK+ 2.9.2 released X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gnome-hackers@gnome.org List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2006 20:21:34 -0000 GTK+ 2.9.2 is now available for download at: http://ftp.gnome.org/pub/gnome/sources/gtk+/2.9/ gtk+-2.9.2.tar.gz md5sum: c63e7d0cf7c4e983206c3088a0fb8862 gtk+-2.9.2.tar.bz2 md5sum: 17629437af44fce03485101371c8f041 This is a development release leading up to GTK+ 2.10. Notes: * This is unstable development release. There are certainly plenty of bugs remaining to be found. This release should not be used in production. * Installing this version will overwrite your existing copy of GTK+ 2.8. If you have problems, you'll need to reinstall GTK+ 2.8. * GTK+ 2.10 will be source compatible with the GTK+ 2.8 series; the new API additions in GTK+ 2.9.0 are not yet completely finalized, so there are likely incompatibilies between this release and the final 2.10 release. * The ABI version has been bumped from 2.4.0 to 2.10.0, since the filechooser backend interface has been changed. Third-party filechooser backends need to be ported to the new interface. Other third-party modules (input methods, image loaders, etc) just need to be reinstalled in the proper location for GTK+ to find them. * Remaining issues for GTK+ 2.10 can be found with following bugzilla query: http://bugzilla.gnome.org/buglist.cgi?product=gtk%2b&target_milestone=2.10+API+Freeze&target_milestone=2.10+Freeze&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED * Bugs should be reported to http://bugzilla.gnome.org. What is GTK+ ============ GTK+ is a multi-platform toolkit for creating graphical user interfaces. Offering a complete set of widgets, GTK+ is suitable for projects ranging from small one-off tools to complete application suites. GTK+ has been designed from the ground up to support a range of languages, not only C/C++. Using GTK+ from languages such as Perl and Python (especially in combination with the Glade GUI builder) provides an effective method of rapid application development. GTK+ is free software and part of the GNU Project. However, the licensing terms for GTK+, the GNU LGPL, allow it to be used by all developers, including those developing proprietary software, without any license fees or royalties. Where to get more information about GTK+ ======================================== Information about GTK+ including links to documentation can be found at: http://www.gtk.org/ An installation guide for GTK+ 2.x is found at: http://developer.gnome.org/doc/API/2.4/gtk/gtk-building.html Common questions: http://developer.gnome.org/doc/API/2.4/gtk/gtk-question-index.html http://www.gtk.org/faq/ Overview of Changes from GTK+ 2.9.1 to 2.9.2 ============================================ * GtkPrintOperation - Support asynchronous pagination with the ::paginate signal - Add gtk_print_operation_cancel - Support application-specific widgets - Allow disabling features based on application capabilities - Optionally show progress - Change some function names in GtkPrintContext to be longer and better - Support preview, the default implementation spawns evince, but the api allows for an internal preview implementation * GtkCellView - Add a model property * GtkStatusIcon - Allow to obtain screen geometry * GtkTreeView - Many bug fixes, in particular for RTL handling - Separate sensitive and selectable properties of rows - Optionally allow rubberband selection * GtkButton - Add image-spacing style property - Add image-position property * GtkToolButton - Add icon-spacing style property * Make GTK+ work as an untrused X client * Bugs fixed: 343838 gtkprintoperationpreview.h guards 305530 Crashes while creating source code w/GtkFontSelection 341327 Memory corruption inside glib 341734 cursor blocked to dnd mode after using shift and dnd on a GtkCalendar 343453 G_DEFINE_TYPE messes up internal typenames of GdkWindow and GdkPixmap 136571 Problems running as untrusted client 168105 the right edge tab does not appear when switching tab 172535 Add support for UI builders in gtk+ 302556 GtkTreeView widget signals are badly documented 324480 Selecting first item with keyboard is difficult 340428 small cleanup 340444 don't run the custom page size dialogue 340839 Critical warnings in GtkTreeModelFilter 341898 gtk_tree_view_insert_column_with_attributes doesn't work with fixed_height_mode 342003 DnD: Conditional jump or move depends on uninitialised value 342072 Wrong drop location in GtkEntry 342096 GtkImage animation CRITICALS on switching themes 342513 widget class style property with type module 342529 gdk should set resolution on PangoCairoFontmap, not PangoCairoContext 342535 Add documentation for new GtkWidget style properties (including Since tags) 342543 can't compile gtk+ on opensolaris using sun cc 342569 Typo in decl of gdk_color_parse 342752 Need a way to specify custom tab label for custom page in Print dialog 342754 print-editor: font button dialog doesn't get focus if main window has a window group 342781 GtkPrintUnixDialog: Collate should be insensitive unless Copies is > 1 342783 GtkPrintUnixDialog: Range textinput area should be insensitive unless range radiobutton is selected 342894 Use after free inside gtk_text_view_set_buffer 342930 GtkButton should offer a way to position the image relative to the text 343088 Some typos in the PO file 343425 "grab-notify"-signal is not correctly propagated for internal children 343438 gtk_color_button_set_color() doesn't emit "color-set" signal 343475 page setup unix dialog confusion 343625 allow to get only some info from gtk_status_icon_get_geometry 343677 GtkWindow chains key-release to key-press 320431 Text too close when using East/West in a GtkToolButton 321523 GtkTreeView's test_expand_row signal emitting impractical on row expand all 342007 Warning in gtk_paned_compute_position 343233 gdk_rectangle_intersect doc 333284 expander animation not working in RTL mode 343444 change color of gtk-demo source-buffer comment color from red to DodgerBlue 343630 Small inconsistence in migration documentation 80127 Rubberbanding for GtkTreeView 341450 status icon + libnotify 341679 Allow absolute filenames in the options entries * Updated translations (bg,cy,de,el,es,et,eu,gl,gu,it,ja, nb,nl,pt_BR,th,vi) Thanks to everybody who has contributed to this release, in the form of bug reports or patches: Alexander Larsson, Behdad Esfahbod, Benjamin Berg, Caolan McNamara, Carlos Garnacho Parro, Carol Spears, Christian Persch, Chris Wilson, Claudio Saavedra, Clytie Siddall, Damon Chaplin, Daniel Lindenaar, Dan Winship, Diana Fong, Ed Catmur, Emmanuele Bassi, Havoc Pennington, Henrique Romano, Hiroyuki Ikezoe, James Moger, Johan Dahlin, Kouhei Sutou, Kristian Rietveld, Markku Vire, Mart Raudsepp, Masatake Yamato, Michael Emmel, Michael Natterer, Murray Cumming, Olexiy Avramchenko, Paolo Borelli, Patrick Monnerat, Richard Hult, Sampo Savolainen, Sebastien Bacher, Srirama Sharma, Stefan Kost, Tim Janik, Tommi Komulainen, Tor Lillqvist, Yevgen Muntyan A list of all bugs fixed in this release can be found at: http://bugzilla.gnome.org/buglist.cgi?bug_id=342072,342096,342003,341734,305530,168105,342007,342529,342535,342543,342569,341679,342752,172535,342513,342781,342783,342754,136571,341450,333284,340428,340839,341898,321523,343088,343233,324480,342894,320431,342930,343453,343425,343438,343444,340444,343475,302556,343677,343625,80127,343838,341327,168105,343630 Matthias Clasen June 5, 2006 From otaylor@redhat.com Mon Jun 5 18:10:18 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 606843B039F for ; Mon, 5 Jun 2006 18:10:18 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03967-08 for ; Mon, 5 Jun 2006 18:10:17 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id CAF5C3B0389 for ; Mon, 5 Jun 2006 18:10:16 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k55MAGwn013331; Mon, 5 Jun 2006 18:10:16 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k55MAGNr013297; Mon, 5 Jun 2006 18:10:16 -0400 Received: from localhost.localdomain (sebastian-int.corp.redhat.com [172.16.52.221]) by devserv.devel.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k55MAFJC021457; Mon, 5 Jun 2006 18:10:15 -0400 From: Owen Taylor In-Reply-To: <2672cf4d0606050752o12a6d0d2gcb4c355cc0f35d79@mail.gmail.com> References: <44747D3E.8020902@imendio.com> <2672cf4d0606050752o12a6d0d2gcb4c355cc0f35d79@mail.gmail.com> Content-Type: text/plain Date: Mon, 05 Jun 2006 15:10:09 -0400 Message-Id: <1149534609.2441.107.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 (2.6.1-1.fc5.2) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.187 tagged_above=-999 required=2 tests=[AWL=-0.199, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.478, FORGED_RCVD_HELO=0.135, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.187 X-Spam-Level: Cc: gtk-devel-list@gnome.org Subject: Re: GTK+ >> Cocoa Native Port X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2006 22:10:18 -0000 On Mon, 2006-06-05 at 10:52 -0400, Dominic Lachowicz wrote: > > I think that drawable is a GdkPixmap structure, so I cant do GDK_PIXBUF > > (drawable), but is there a function to get the pixbuf from a pixmap ? > > You might want to look at gdk_pixbuf_get_from_drawable(). Not going to help here, I think .. copy_to_image() is the backend function used to implement gdk_pixbuf_get_from_drawable(). :-) This is the point in the code where you need to figure out how to copy pixels from a native drawable into an image buffer, which is going to involve native graphics system calls. If you can find docs on how to take a screenshot of a window in OS X, that will be similar code to what is needed here. Owen From rpmcruz@clix.pt Mon Jun 5 21:41:34 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id B9E363B03FB for ; Mon, 5 Jun 2006 21:41:34 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15260-05 for ; Mon, 5 Jun 2006 21:41:33 -0400 (EDT) Received: from mailrly02.isp.novis.pt (mailrly02.isp.novis.pt [195.23.133.212]) by menubar.gnome.org (Postfix) with ESMTP id 84DA33B0076 for ; Mon, 5 Jun 2006 21:41:32 -0400 (EDT) Received: (qmail 21302 invoked from network); 6 Jun 2006 01:41:30 -0000 Received: from unknown (HELO mailfrt04.isp.novis.pt) ([195.23.133.196]) (envelope-sender ) by mailrly02.isp.novis.pt with compressed SMTP; 6 Jun 2006 01:41:30 -0000 Received: (qmail 17342 invoked from network); 6 Jun 2006 01:41:29 -0000 Received: from unknown (HELO [10.0.0.2]) (Sent_by_authenticated_user_x2476431@[87.196.74.232]) (envelope-sender ) by mailfrt04.isp.novis.pt with SMTP; 6 Jun 2006 01:41:29 -0000 From: Ricardo Cruz To: gtk-devel-list@gnome.org Date: Tue, 6 Jun 2006 02:48:21 +0100 User-Agent: KMail/1.9.1 X-Face: $29d{(U~(^/X.rR|7i6syM3jeJ}N+*%U-#Bzl5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200606060248.21205.rpmcruz@clix.pt> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.657 tagged_above=-999 required=2 tests=[AWL=-0.917, BAYES_20=-0.74] X-Spam-Score: -1.657 X-Spam-Level: Subject: GtkComboBoxEntry -- changing entry line value X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2006 01:41:34 -0000 Hi there, Is there a way to set a value for a GtkComboBoxEntry line entry? I am currently just adding an entry, set it as selected and remove it, which is a pretty nasty work-around. By the way, is it planned to add a GtkEditable interface for it? That would be really sweet and, if affirmitive, I could work on making a patch. Cheers, Ricardo -- Fourth Law of Thermodynamics: If the probability of success is not almost one, it is damn near zero. -- David Ellis From markku.vire@kolumbus.fi Tue Jun 6 04:39:15 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 5E3DD3B0C57 for ; Tue, 6 Jun 2006 04:39:15 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23318-01 for ; Tue, 6 Jun 2006 04:39:13 -0400 (EDT) Received: from fep02-app.kolumbus.fi (fep02-0.kolumbus.fi [193.229.0.44]) by menubar.gnome.org (Postfix) with ESMTP id C21BF3B0A19 for ; Tue, 6 Jun 2006 04:37:26 -0400 (EDT) Received: from smtp.kolumbus.fi ([193.229.55.124]) by fep02-app.kolumbus.fi with ESMTP id <20060606083725.NGAZ5174.fep02-app.kolumbus.fi@smtp.kolumbus.fi>; Tue, 6 Jun 2006 11:37:25 +0300 X-Mailer: Openwave WebEngine, version 2.8.12 (webedge20-101-197-20030912) X-Originating-IP: [62.236.91.3] From: To: Ricardo Cruz , Date: Tue, 6 Jun 2006 11:37:24 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <20060606083725.NGAZ5174.fep02-app.kolumbus.fi@smtp.kolumbus.fi> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.504 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, NO_REAL_NAME=0.961, SPF_PASS=-0.001] X-Spam-Score: -1.504 X-Spam-Level: X-Mailman-Approved-At: Tue, 06 Jun 2006 07:05:18 -0400 Cc: Subject: Re: GtkComboBoxEntry -- changing entry line value X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2006 08:39:15 -0000 Hi, You can get the entry by calling gtk_bin_get_child(box); and then using any methods of GtkEntry to manipulate the text. > Is there a way to set a value for a GtkComboBoxEntry line entry? I am > currently just adding an entry, set it as selected and remove it, which is a > pretty nasty work-around. -Markku- From markku.vire@kolumbus.fi Tue Jun 6 04:39:55 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 544743B0B78 for ; Tue, 6 Jun 2006 04:39:55 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23288-09 for ; Tue, 6 Jun 2006 04:39:52 -0400 (EDT) Received: from fep02-app.kolumbus.fi (fep02-0.kolumbus.fi [193.229.0.44]) by menubar.gnome.org (Postfix) with ESMTP id BD56C3B0A19 for ; Tue, 6 Jun 2006 04:39:51 -0400 (EDT) Received: from smtp.kolumbus.fi ([193.229.55.124]) by fep02-app.kolumbus.fi with ESMTP id <20060606083950.NHYK5174.fep02-app.kolumbus.fi@smtp.kolumbus.fi>; Tue, 6 Jun 2006 11:39:50 +0300 X-Mailer: Openwave WebEngine, version 2.8.12 (webedge20-101-197-20030912) X-Originating-IP: [62.236.91.3] From: To: Ricardo Cruz , Date: Tue, 6 Jun 2006 11:39:50 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <20060606083950.NHYK5174.fep02-app.kolumbus.fi@smtp.kolumbus.fi> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.504 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, NO_REAL_NAME=0.961, SPF_PASS=-0.001] X-Spam-Score: -1.504 X-Spam-Level: X-Mailman-Approved-At: Tue, 06 Jun 2006 07:05:18 -0400 Cc: Subject: Re: GtkComboBoxEntry -- changing entry line value X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2006 08:39:55 -0000 Hi, You can get the entry by calling gtk_bin_get_child(box); and then using any methods of GtkEntry to manipulate the text. > Is there a way to set a value for a GtkComboBoxEntry line entry? I am > currently just adding an entry, set it as selected and remove it, which is a > pretty nasty work-around. -Markku- From federico@ximian.com Tue Jun 6 11:45:51 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id A23E83B00FF for ; Tue, 6 Jun 2006 11:45:51 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01904-10 for ; Tue, 6 Jun 2006 11:45:35 -0400 (EDT) Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) by menubar.gnome.org (Postfix) with ESMTP id 6D4083B0ADD for ; Tue, 6 Jun 2006 11:45:33 -0400 (EDT) Received: (qmail 15590 invoked from network); 6 Jun 2006 15:45:31 -0000 Received: from localhost (HELO ?164.99.120.162?) (127.0.0.1) by localhost with SMTP; 6 Jun 2006 15:45:31 -0000 From: Federico Mena Quintero To: GTK+ development mailing list Content-Type: text/plain Date: Tue, 06 Jun 2006 10:41:22 -0500 Message-Id: <1149608483.14088.54.camel@cacharro.xalalinux.org> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.574 tagged_above=-999 required=2 tests=[AWL=0.025, BAYES_00=-2.599] X-Spam-Score: -2.574 X-Spam-Level: Cc: Michael.meeks@novell.com Subject: Default timeouts X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2006 15:45:51 -0000 In gtksettings.c we have #define DEFAULT_TIMEOUT_INITIAL 200 #define DEFAULT_TIMEOUT_REPEAT 20 for the "gtk-timeout-initial" and "gtk-timeout-repeat" settings, respectively. This means we wait for a fifth of a second before we start repeating, but then we try to repeat 50 times per second. Isn't the repeat timeout way too short? This is why clicking on a calendar arrow takes you back tens of months in no time, and also makes it hard to use spin buttons. Also, Michael Meeks has the following words of wisdom in a Novell bug about the calendar in gnome-panel's clock: > In essence the timeout is way too short for switching days; also - > in the panel applet the timeout has a higher priority than the > queued resize of the display (and hence the redraw) - so in > essence we skip days even faster since we never have to render > them. > > Lowering the priority there, and lengthening the timeouts gives > a far more reasonable, usable experience without getting rid > of the whole auto-repeat principle [...] I.e. instead of using g_timeout_add() in gtkcalendar, we would use g_timeout_add_full (G_PRIORITY_DEFAULT_IDLE, ...), or perhaps (GDK_PRIORITY_REDRAW + positive_constant): both are lower priority than GTK_PRIORITY_RESIZE. Federico From michael.meeks@novell.com Tue Jun 6 12:33:58 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 74B9F3B0197 for ; Tue, 6 Jun 2006 12:33:58 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05177-09 for ; Tue, 6 Jun 2006 12:33:57 -0400 (EDT) Received: from gwia-smtp.id2.novell.com (public.id2-vpn.continvity.gns.novell.com [195.33.99.129]) by menubar.gnome.org (Postfix) with ESMTP id 3714E3B014F for ; Tue, 6 Jun 2006 12:33:57 -0400 (EDT) Received: from [192.168.0.8] (l4-client.id2.novell.com [::ffff:149.44.117.251]) by gwia-smtp.id2.novell.com with ESMTP (TLS encrypted); Tue, 06 Jun 2006 17:33:30 +0100 From: Michael Meeks To: Federico Mena Quintero In-Reply-To: <1149608483.14088.54.camel@cacharro.xalalinux.org> References: <1149608483.14088.54.camel@cacharro.xalalinux.org> Content-Type: text/plain Organization: Novell, Inc. Date: Tue, 06 Jun 2006 17:37:54 +0100 Message-Id: <1149611874.2202.2.camel@t60p.site> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.427 tagged_above=-999 required=2 tests=[AWL=-0.028, BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2] X-Spam-Score: -2.427 X-Spam-Level: Cc: GTK+ development mailing list Subject: Re: Default timeouts X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: michael.meeks@novell.com List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2006 16:33:58 -0000 On Tue, 2006-06-06 at 10:41 -0500, Federico Mena Quintero wrote: > > In essence the timeout is way too short for switching days; also - > > in the panel applet the timeout has a higher priority than the > > queued resize of the display (and hence the redraw) - so in > > essence we skip days even faster since we never have to render > > them. Of course - this is particularly applicable for the calendar where it really makes sense to actually see the month rendered each time you switch to a different month or year. Of course with a spin-button I guess throttling the spin rate to that of the refresh rate would (perhaps) be problematic. Then again re-rendering a spin-button is presumably an extremely fast operation. HTH, Michael. -- michael.meeks@novell.com <><, Pseudo Engineer, itinerant idiot From carlosgc@gnome.org Wed Jun 7 07:48:25 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id BACA33B0C6A for ; Wed, 7 Jun 2006 07:48:25 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08136-01 for ; Wed, 7 Jun 2006 07:48:23 -0400 (EDT) Received: from localhost.localdomain (gsyc090.dat.escet.urjc.es [193.147.71.90]) by menubar.gnome.org (Postfix) with ESMTP id D0D083B01EA for ; Wed, 7 Jun 2006 07:48:22 -0400 (EDT) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 945E110F28E for ; Wed, 7 Jun 2006 13:48:19 +0200 (CEST) From: Carlos Garcia Campos To: GTK+ development mailing list Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-hBJf7M2jws0KBkd4rYip" Date: Wed, 07 Jun 2006 13:48:17 +0200 Message-Id: <1149680898.3302.9.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.285 tagged_above=-999 required=2 tests=[AWL=0.179, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.285 X-Spam-Level: Subject: Evince preview mode X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 11:48:25 -0000 --=-hBJf7M2jws0KBkd4rYip Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi,=20 since gtk+ is using evince as an external printing previewer, I'm implementing a preview mode in evince, available through the command line (--preview). It's based on the ephy printing previewer where the menubar is hidden and the toolbar contains navigation items and a close button. Here is an screenshot: http://carlosgc.linups.org/files/evince-preview-mode.png Any other thing expected by a previewer? --=20 Carlos Garcia Campos (KaL) elkalmail@yahoo.es carlosgc@gnome.org http://carlosgc.linups.org PGP key: http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0x523E6462 --=-hBJf7M2jws0KBkd4rYip Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQBEhr0BjxBOalI+ZGIRAmSgAJ9Ksy9L8QqVxpvNQCtbejp/0HRZXACeNcmq O8LT0nzkGzw+qcPFuVqZ3y8= =xZYn -----END PGP SIGNATURE----- --=-hBJf7M2jws0KBkd4rYip-- From hfiguiere@teaser.fr Wed Jun 7 08:28:18 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id AC8923B0CE2; Wed, 7 Jun 2006 08:28:18 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11220-01; Wed, 7 Jun 2006 08:28:15 -0400 (EDT) Received: from xandros.com (smtp1.xandros.com [209.87.238.70]) by menubar.gnome.org (Postfix) with ESMTP id EC3713B0CD7; Wed, 7 Jun 2006 08:28:14 -0400 (EDT) Received: from [172.18.1.132] (toronto-hs-216-138-231-194.s-ip.magma.ca [216.138.231.194]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by xandros.com (Postfix) with ESMTP id E7D80C028; Wed, 7 Jun 2006 08:28:12 -0400 (EDT) Message-ID: <4486C65A.5060800@teaser.fr> Date: Wed, 07 Jun 2006 08:28:10 -0400 From: Hubert Figuiere User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: Carlos Garcia Campos References: <1149680898.3302.9.camel@localhost.localdomain> In-Reply-To: <1149680898.3302.9.camel@localhost.localdomain> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.499 tagged_above=-999 required=2 tests=[AWL=0.100, BAYES_00=-2.599] X-Spam-Score: -2.499 X-Spam-Level: Cc: GTK+ development mailing list Subject: Re: Evince preview mode X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 12:28:19 -0000 Carlos Garcia Campos wrote: > Hi, > > since gtk+ is using evince as an external printing previewer, I'm > implementing a preview mode in evince, available through the command > line (--preview). It's based on the ephy printing previewer where the > menubar is hidden and the toolbar contains navigation items and a close > button. Here is an screenshot: > > http://carlosgc.linups.org/files/evince-preview-mode.png > > Any other thing expected by a previewer? It think it should have a menu bar, even if it is way simplier than Evince, and the button to close in the toolbar should be removed because it is "uncommon" and in fact confuse the user on what to do. Closing the window should be all that needed, or doing a file->close in the menu, Also, zoom in and zoom out are very useful. Hub From paolo.maggi@gmail.com Wed Jun 7 08:15:10 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 9C3E63B08CC for ; Wed, 7 Jun 2006 08:15:10 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10407-05 for ; Wed, 7 Jun 2006 08:15:09 -0400 (EDT) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.172]) by menubar.gnome.org (Postfix) with ESMTP id 8B7343B0303 for ; Wed, 7 Jun 2006 08:15:08 -0400 (EDT) Received: by ug-out-1314.google.com with SMTP id c2so258875ugf for ; Wed, 07 Jun 2006 05:15:07 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:subject:from:to:cc:content-type:date:message-id:mime-version:x-mailer:content-transfer-encoding; b=K90OlbUivfHjc3p7Mf7NxXYQ7dM8ZBxC+0BsgOJcKZJuB7jHCl0ZAGBW4g8105rAzePSP5EyfdcA7LlHJh+VEWxuXvCS7dbrv6RMBVJzQ/vwIPq71eGzz8nn2EwMpB2LP+LFhmJsovQOwZfLUn1MKDz4iRRATWR1zOQleW/WqEg= Received: by 10.67.105.19 with SMTP id h19mr435594ugm; Wed, 07 Jun 2006 05:15:06 -0700 (PDT) Received: from elilix.polito.it ( [130.192.16.224]) by mx.gmail.com with ESMTP id q1sm888781uge.2006.06.07.05.15.05; Wed, 07 Jun 2006 05:15:06 -0700 (PDT) From: Paolo Maggi To: carlosgc@gnome.org Content-Type: text/plain Date: Wed, 07 Jun 2006 14:15:04 +0200 Message-Id: <1149682504.5804.33.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.6 tagged_above=-999 required=2 tests=[AWL=0.000, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.6 X-Spam-Level: X-Mailman-Approved-At: Wed, 07 Jun 2006 09:03:01 -0400 Cc: gtk-devel-list@gnome.org Subject: Re: Evince preview mode X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 12:15:10 -0000 Hi, cia > since gtk+ is using evince as an external printing previewer, I'm > implementing a preview mode in evince, available through the command > line (--preview). It's based on the ephy printing previewer where the > menubar is hidden and the toolbar contains navigation items and a close > button. Here is an screenshot: > > http://carlosgc.linups.org/files/evince-preview-mode.png > > Any other thing expected by a previewer? - Zoom - Direct jump to a given page Please, look also at the gedit 2.14.x print previewer. Probably we also need a way to specify paper orientation on the command line (or is orientation already specified in the PDF file?) Ciao, Paolo From matthias.clasen@gmail.com Wed Jun 7 09:13:05 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id E24273B0D07 for ; Wed, 7 Jun 2006 09:13:04 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14781-07 for ; Wed, 7 Jun 2006 09:13:02 -0400 (EDT) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.202]) by menubar.gnome.org (Postfix) with ESMTP id 00C823B0B41 for ; Wed, 7 Jun 2006 09:13:01 -0400 (EDT) Received: by nz-out-0102.google.com with SMTP id 9so196545nzo for ; Wed, 07 Jun 2006 06:13:01 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=saqMihVje8FYa9UdpyLa1+dlefvQoIGQxKH7/1Zo60aYxymeM8Pd6GyFWAgY0o+p1vKDz7amMyAC6pjntEQBEcP8uj0rJL3yYZX1hequAVkJsd5sQslhyn8T44EZjEA/hsuQz0+1EdqmPuNMRK0Lseu0seEU88n8Ei5Ii1IMFBQ= Received: by 10.37.13.40 with SMTP id q40mr711105nzi; Wed, 07 Jun 2006 06:13:00 -0700 (PDT) Received: by 10.37.21.14 with HTTP; Wed, 7 Jun 2006 06:13:00 -0700 (PDT) Message-ID: Date: Wed, 7 Jun 2006 09:13:00 -0400 From: "Matthias Clasen" To: "Carlos Garcia Campos" In-Reply-To: <1149680898.3302.9.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1149680898.3302.9.camel@localhost.localdomain> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.508 tagged_above=-999 required=2 tests=[AWL=0.092, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.508 X-Spam-Level: Cc: GTK+ development mailing list Subject: Re: Evince preview mode X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 13:13:05 -0000 On 6/7/06, Carlos Garcia Campos wrote: > Hi, > > since gtk+ is using evince as an external printing previewer, I'm > implementing a preview mode in evince, available through the command > line (--preview). It's based on the ephy printing previewer where the > menubar is hidden and the toolbar contains navigation items and a close > button. Here is an screenshot: > > http://carlosgc.linups.org/files/evince-preview-mode.png > > Any other thing expected by a previewer? A print button. From n1huq@hotmail.com Wed Jun 7 13:11:51 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 04F873B04FC for ; Wed, 7 Jun 2006 13:11:51 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32024-05 for ; Wed, 7 Jun 2006 13:11:49 -0400 (EDT) Received: from hotmail.com (bay114-dav5.bay114.hotmail.com [65.54.169.77]) by menubar.gnome.org (Postfix) with ESMTP id 192433B00F5 for ; Wed, 7 Jun 2006 13:11:49 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 7 Jun 2006 10:11:48 -0700 Message-ID: Received: from 68.0.250.43 by BAY114-DAV5.phx.gbl with DAV; Wed, 07 Jun 2006 17:11:46 +0000 X-Originating-IP: [68.0.250.43] X-Originating-Email: [n1huq@hotmail.com] X-Sender: n1huq@hotmail.com From: "Sydney Faria" To: Date: Wed, 7 Jun 2006 13:15:56 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-OriginalArrivalTime: 07 Jun 2006 17:11:48.0135 (UTC) FILETIME=[75E3BB70:01C68A55] X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=1.984 tagged_above=-999 required=2 tests=[BAYES_50=0.001, DNS_FROM_RFC_ABUSE=0.2, DNS_FROM_RFC_POST=1.708, MSGID_FROM_MTA_HEADER=0, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, TW_GT=0.077] X-Spam-Score: 1.984 X-Spam-Level: * Subject: combo box problem X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 17:11:51 -0000 The following simple example of a gtk_combo_box compiles and works OK it the select_cb() is empty. The line marked gives a compiler error: undefined reference to gtk_combo_box_get_active_text. I am befuddled! sydney #include #include GtkWidget *window, *combo; static gboolean delete_event(GtkWidget *widget, GdkEvent *event, gpointer data) { return FALSE; } static void destroy(GtkWidget *widget, gpointer data) { gtk_main_quit(); } static void select_cb(GtkWidget *widget, gpointer data) { /* comment out following 2 lines and program compiles and works OK */ gchar *str = gtk_combo_box_get_active_text(GTK_COMBO_BOX(combo)); /* compile error */ g_print("active text: %s\n", str); } int main( int argc, char *argv[] ) { GtkWidget *button, *hbox; gtk_init (&argc, &argv); /* init gtk */ window = gtk_window_new (GTK_WINDOW_TOPLEVEL); gtk_container_set_border_width(GTK_CONTAINER(window), 10); g_signal_connect(G_OBJECT(window), "delete_event", G_CALLBACK(delete_event), NULL); g_signal_connect(G_OBJECT(window), "destroy", G_CALLBACK(destroy), NULL); hbox = gtk_hbox_new(TRUE, 20); gtk_container_add(GTK_CONTAINER(window), hbox); button = gtk_button_new_with_label("Select text"); g_signal_connect(G_OBJECT(button), "clicked", G_CALLBACK(select_cb), NULL); gtk_box_pack_start(GTK_BOX(hbox), button, FALSE, FALSE, 0); combo = gtk_combo_box_new_text(); gtk_box_pack_start(GTK_BOX(hbox), combo, FALSE, FALSE, 0); gtk_combo_box_insert_text(GTK_COMBO_BOX(combo), 0, "Astring"); gtk_combo_box_append_text(GTK_COMBO_BOX(combo), "Bstring"); gtk_combo_box_append_text(GTK_COMBO_BOX(combo), "Cstring"); gtk_combo_box_append_text(GTK_COMBO_BOX(combo), "Dstring"); gtk_combo_box_append_text(GTK_COMBO_BOX(combo), "Estring"); gtk_combo_box_insert_text(GTK_COMBO_BOX(combo), 3, "xxxxx"); gtk_widget_show_all(window); gtk_main(); return 0; } From ali@avrc.city.ac.uk Wed Jun 7 13:20:43 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id B9C6A3B0D3D for ; Wed, 7 Jun 2006 13:20:43 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32493-04 for ; Wed, 7 Jun 2006 13:20:42 -0400 (EDT) Received: from firewall.avrc.city.ac.uk (optosun2.city.ac.uk [138.40.167.2]) by menubar.gnome.org (Postfix) with ESMTP id ACA3B3B0BDC for ; Wed, 7 Jun 2006 13:20:40 -0400 (EDT) Received: from tom.avrc.city.ac.uk (IDENT:U2FsdGVkX1/zwWSA4Vc+XKbUWVXUavCLm3rPqXMMlDg@tom [192.168.137.104]) by firewall.avrc.city.ac.uk (8.9.3/8.9.3) with ESMTP id SAA27971; Wed, 7 Jun 2006 18:10:27 +0100 Received: from tom.avrc.city.ac.uk (localhost.localdomain [127.0.0.1]) by tom.avrc.city.ac.uk (8.13.1/8.13.1) with ESMTP id k57HTT2Y031243; Wed, 7 Jun 2006 18:29:29 +0100 Date: Wed, 07 Jun 2006 17:29:28 +0000 From: "J. Ali Harlow" To: Sydney Faria References: In-Reply-To: (from n1huq@hotmail.com on Wed Jun 7 18:15:56 2006) X-Mailer: Balsa 2.2.6 Message-Id: <1149701368l.5713l.3l@tom.avrc.city.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; DelSp=Yes; Format=Flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.525 tagged_above=-999 required=2 tests=[AWL=-0.003, BAYES_00=-2.599, TW_GT=0.077] X-Spam-Score: -2.525 X-Spam-Level: Cc: gtk-devel-list@gnome.org Subject: Re: combo box problem X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 17:20:43 -0000 On 07/06/06 18:15:56, Sydney Faria wrote: > The following simple example of a gtk_combo_box compiles and works OK > it the select_cb() is empty. The line marked gives a compiler error: =20 > undefined reference to gtk_combo_box_get_active_text. gtk_combo_box_get_active_text was added in Gtk+ v2.6 Ali. From carlosgc@gnome.org Wed Jun 7 14:37:47 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id D45D43B0546 for ; Wed, 7 Jun 2006 14:37:47 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05339-08 for ; Wed, 7 Jun 2006 14:37:46 -0400 (EDT) Received: from localhost.localdomain (gsyc090.dat.escet.urjc.es [193.147.71.90]) by menubar.gnome.org (Postfix) with ESMTP id 3EC7D3B03F7 for ; Wed, 7 Jun 2006 14:37:46 -0400 (EDT) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 0ABE610F28E for ; Wed, 7 Jun 2006 20:37:40 +0200 (CEST) From: Carlos Garcia Campos To: gtk-devel-list@gnome.org In-Reply-To: References: <1149680898.3302.9.camel@localhost.localdomain> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-WdU94ldj/PvL1mhYRti9" Date: Wed, 07 Jun 2006 20:37:39 +0200 Message-Id: <1149705460.3302.25.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.354 tagged_above=-999 required=2 tests=[AWL=0.110, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.354 X-Spam-Level: Subject: Re: Evince preview mode X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 18:37:48 -0000 --=-WdU94ldj/PvL1mhYRti9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable El mi=C3=A9, 07-06-2006 a las 09:13 -0400, Matthias Clasen escribi=C3=B3: > On 6/7/06, Carlos Garcia Campos wrote: > > Hi, > > > > since gtk+ is using evince as an external printing previewer, I'm > > implementing a preview mode in evince, available through the command > > line (--preview). It's based on the ephy printing previewer where the > > menubar is hidden and the toolbar contains navigation items and a close > > button. Here is an screenshot: > > > > http://carlosgc.linups.org/files/evince-preview-mode.png > > > > Any other thing expected by a previewer? >=20 > A print button. >=20 hmm, when the user selects preview from the print dialog, the dialog disappears and evince is launched, so that if evince has a print button we should print the document directly without showing the print dialog again. I see several problems in this approach. First of all we can't know the print settings selected by the user from evince. And, should we close evince or keep it opened after clicking on print? Is it possible to print a pdf file with the new gtk+ api without showing any dialog?=20 I think it's very confused. The best solution would be not to hide the dialog when the previewer is launched, so that once the user is happy with the results showed in evince, he simply clicks on print button.=20 --=20 Carlos Garcia Campos (KaL) elkalmail@yahoo.es carlosgc@gnome.org http://carlosgc.linups.org PGP key: http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0x523E6462 --=-WdU94ldj/PvL1mhYRti9 Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQBEhxzzjxBOalI+ZGIRAsatAJ4+rfTQPQwp9+YtbRKpPmVlDuEG9ACfclx7 9c9NhlEvkjGZjMS42o6vmHM= =TbYL -----END PGP SIGNATURE----- --=-WdU94ldj/PvL1mhYRti9-- From matthias.clasen@gmail.com Wed Jun 7 19:34:00 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 62A323B036A for ; Wed, 7 Jun 2006 19:34:00 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23001-06 for ; Wed, 7 Jun 2006 19:33:56 -0400 (EDT) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.203]) by menubar.gnome.org (Postfix) with ESMTP id A86BE3B0E6E for ; Wed, 7 Jun 2006 19:33:56 -0400 (EDT) Received: by nz-out-0102.google.com with SMTP id o37so261498nzf for ; Wed, 07 Jun 2006 16:33:55 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=LpgZtLrjc9Sc3giRUzuWDX2naMTMsbgrizT1aggkQjCN27Pm9kFPU1c5Bra0LikmJaw1sDQO0paAD7N3OQwY1+3Y9JTdMwkT9YBnlgCbMohSYLzhRt6yPFasRtdkLK24rM8sI5l8EdJ/+dpxDSU/+GFlNbztpO8kky973RVbTmY= Received: by 10.36.103.6 with SMTP id a6mr1426226nzc; Wed, 07 Jun 2006 16:33:53 -0700 (PDT) Received: by 10.37.21.14 with HTTP; Wed, 7 Jun 2006 16:33:52 -0700 (PDT) Message-ID: Date: Wed, 7 Jun 2006 19:33:52 -0400 From: "Matthias Clasen" To: "Carlos Garcia Campos" In-Reply-To: <1149705460.3302.25.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1149680898.3302.9.camel@localhost.localdomain> <1149705460.3302.25.camel@localhost.localdomain> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.509 tagged_above=-999 required=2 tests=[AWL=0.091, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.509 X-Spam-Level: Cc: gtk-devel-list@gnome.org Subject: Re: Evince preview mode X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 23:34:00 -0000 On 6/7/06, Carlos Garcia Campos wrote: > hmm, when the user selects preview from the print dialog, the dialog > disappears and evince is launched, so that if evince has a print button > we should print the document directly without showing the print dialog > again. I see several problems in this approach. First of all we can't > know the print settings selected by the user from evince. And, should we > close evince or keep it opened after clicking on print? Is it possible > to print a pdf file with the new gtk+ api without showing any dialog? Sure, figuring out the best way to transfer the print settings to evince is part of this. And yes, printing preformatted pdf is supported. > > I think it's very confused. The best solution would be not to hide the > dialog when the previewer is launched, so that once the user is happy > with the results showed in evince, he simply clicks on print button. > Apple does it too, so it can't be all bad... Matthias From hfiguiere@teaser.fr Wed Jun 7 21:05:56 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 3CAD23B051D for ; Wed, 7 Jun 2006 21:05:56 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27783-02 for ; Wed, 7 Jun 2006 21:05:53 -0400 (EDT) Received: from xandros.com (smtp1.xandros.com [209.87.238.70]) by menubar.gnome.org (Postfix) with ESMTP id 31DC43B0414 for ; Wed, 7 Jun 2006 21:05:53 -0400 (EDT) Received: from [172.18.1.132] (toronto-hs-216-138-231-194.s-ip.magma.ca [216.138.231.194]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by xandros.com (Postfix) with ESMTP id A37413E02E; Wed, 7 Jun 2006 21:05:51 -0400 (EDT) Message-ID: <448777ED.1020804@teaser.fr> Date: Wed, 07 Jun 2006 21:05:49 -0400 From: Hubert Figuiere User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: Matthias Clasen References: <1149680898.3302.9.camel@localhost.localdomain> <1149705460.3302.25.camel@localhost.localdomain> In-Reply-To: X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.506 tagged_above=-999 required=2 tests=[AWL=0.093, BAYES_00=-2.599] X-Spam-Score: -2.506 X-Spam-Level: Cc: gtk-devel-list@gnome.org Subject: Re: Evince preview mode X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 01:05:56 -0000 >> I think it's very confused. The best solution would be not to hide the >> dialog when the previewer is launched, so that once the user is happy >> with the results showed in evince, he simply clicks on print button. >> > > Apple does it too, so it can't be all bad... That is the kind of blind thinking that lead to nowhere. Remember just one thing: if it does not please Steve Jobs, it does not goes. That how it works at Apple. Bottom line: wrong argument. Hub From alexl@redhat.com Thu Jun 8 08:09:59 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 5B8C83B0EF5; Thu, 8 Jun 2006 08:09:59 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32659-09; Thu, 8 Jun 2006 08:09:58 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id B35BC3B075A; Thu, 8 Jun 2006 08:09:57 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k58C9u9M020757; Thu, 8 Jun 2006 08:09:56 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k58C9u0T021240; Thu, 8 Jun 2006 08:09:56 -0400 Received: from [127.0.0.1] (sebastian-int.corp.redhat.com [172.16.52.221]) by devserv.devel.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k58C9tGO011054; Thu, 8 Jun 2006 08:09:56 -0400 From: Alexander Larsson To: Matthias Clasen In-Reply-To: References: <1149680898.3302.9.camel@localhost.localdomain> <1149705460.3302.25.camel@localhost.localdomain> Content-Type: text/plain Date: Thu, 08 Jun 2006 14:09:55 +0200 Message-Id: <1149768596.3023.11.camel@greebo> Mime-Version: 1.0 X-Mailer: Evolution 2.7.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.587 tagged_above=-999 required=2 tests=[AWL=0.014, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.587 X-Spam-Level: Cc: gtk-devel-list@gnome.org Subject: Re: Evince preview mode X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 12:09:59 -0000 On Wed, 2006-06-07 at 19:33 -0400, Matthias Clasen wrote: > On 6/7/06, Carlos Garcia Campos wrote: > > > hmm, when the user selects preview from the print dialog, the dialog > > disappears and evince is launched, so that if evince has a print button > > we should print the document directly without showing the print dialog > > again. I see several problems in this approach. First of all we can't > > know the print settings selected by the user from evince. And, should we > > close evince or keep it opened after clicking on print? Is it possible > > to print a pdf file with the new gtk+ api without showing any dialog? > > Sure, figuring out the best way to transfer the print settings to evince > is part of this. And yes, printing preformatted pdf is supported. This is tricky. What if the preview was launched without even showing the dialog, or if the user hadn't picked the right printer yet when clicking on preview. Also, it will print differently by generating pdf and then converting that to postscript, instead of generating postscript directly. Ideally this should produce as-good output, but thats not really guaranteed. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl@redhat.com alla@lysator.liu.se He's an immortal umbrella-wielding cyborg with no name. She's a tortured green-skinned Hell's Angel from a different time and place. They fight crime! From lists@nabble.com Thu Jun 8 21:35:27 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id BFE263B0E9B for ; Thu, 8 Jun 2006 21:35:27 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18339-04 for ; Thu, 8 Jun 2006 21:35:26 -0400 (EDT) Received: from talk.nabble.com (www.nabble.com [72.21.53.35]) by menubar.gnome.org (Postfix) with ESMTP id 602DC3B05AC for ; Thu, 8 Jun 2006 21:35:26 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=talk.nabble.com) by talk.nabble.com with esmtp (Exim 4.50) id 1FoVuE-0000rb-3p for gtk-devel-list@gnome.org; Thu, 08 Jun 2006 18:35:24 -0700 Message-ID: <4785900.post@talk.nabble.com> Date: Thu, 8 Jun 2006 18:35:22 -0700 (PDT) From: darknecro To: gtk-devel-list@gnome.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-Sender: darknecromancer@dodgeit.com X-Nabble-From: darknecro X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-0.316 tagged_above=-999 required=2 tests=[AWL=2.285, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -0.316 X-Spam-Level: Subject: GTK Masks X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2006 01:35:27 -0000 I am attempting to create a single mask that would cover several items with in the GUI. There will by 16 circles created with gdk_pixmap_create_from_xpm_d, and I can currently do this, but only one item would be 'created' in the mask, so when i apply the mask to the window, only one of the items will be visible. I have done a lot of searching, and I have only been able to come up with that you can xor 2 masks together somehow and create one that contains both. Any help that anyone could shed on this would be greatly appreciated. -- View this message in context: http://www.nabble.com/GTK-Masks-t1759366.html#a4785900 Sent from the Gtk+ - Dev - General forum at Nabble.com. From mitch@gimp.org Fri Jun 9 06:31:35 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id D2D0C3B0216 for ; Fri, 9 Jun 2006 06:31:34 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14877-07 for ; Fri, 9 Jun 2006 06:31:33 -0400 (EDT) Received: from mitch.gimp.org (p549C9439.dip0.t-ipconnect.de [84.156.148.57]) by menubar.gnome.org (Postfix) with ESMTP id EB4033B01DA for ; Fri, 9 Jun 2006 06:31:30 -0400 (EDT) Received: from mitch by mitch.gimp.org with local (Exim 3.36 #1 (Debian)) id 1FoeIj-0003cx-00; Fri, 09 Jun 2006 12:33:13 +0200 From: Michael Natterer To: Federico Mena Quintero In-Reply-To: <1149608483.14088.54.camel@cacharro.xalalinux.org> References: <1149608483.14088.54.camel@cacharro.xalalinux.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Fri, 09 Jun 2006 12:33:12 +0200 Message-Id: <1149849193.3010.23.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=1.06 tagged_above=-999 required=2 tests=[AWL=-0.545, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, RCVD_IN_NJABL_DUL=1.946, RCVD_IN_SORBS_DUL=2.046, TW_GT=0.077] X-Spam-Score: 1.06 X-Spam-Level: * Cc: GTK+ development mailing list , Michael.meeks@novell.com Subject: Re: Default timeouts X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2006 10:31:35 -0000 On Tue, 2006-06-06 at 10:41 -0500, Federico Mena Quintero wrote: > In gtksettings.c we have > > #define DEFAULT_TIMEOUT_INITIAL 200 > #define DEFAULT_TIMEOUT_REPEAT 20 > > for the "gtk-timeout-initial" and "gtk-timeout-repeat" settings, > respectively. This means we wait for a fifth of a second before we > start repeating, but then we try to repeat 50 times per second. > > Isn't the repeat timeout way too short? This is why clicking on a > calendar arrow takes you back tens of months in no time, and also makes > it hard to use spin buttons. Yes, that's way too short. When doing the settings patch, I unified timeouts without actually changing them (the 20 ms was there before). However in some places I introduced a factor of 5 so all existing timeouts could be done with the two values from GtkSettings. See comment #10 of http://bugzilla.gnome.org/show_bug.cgi?id=142582 Actually, it may make sense to simply use the user's configured key repeat and delay for these two setting values. What do you think? ciao, --mitch > Also, Michael Meeks has the following words of wisdom in a Novell bug > about the calendar in gnome-panel's clock: > > > In essence the timeout is way too short for switching days; also - > > in the panel applet the timeout has a higher priority than the > > queued resize of the display (and hence the redraw) - so in > > essence we skip days even faster since we never have to render > > them. > > > > Lowering the priority there, and lengthening the timeouts gives > > a far more reasonable, usable experience without getting rid > > of the whole auto-repeat principle [...] > > I.e. instead of using g_timeout_add() in gtkcalendar, we would use > g_timeout_add_full (G_PRIORITY_DEFAULT_IDLE, ...), or perhaps > (GDK_PRIORITY_REDRAW + positive_constant): both are lower priority than > GTK_PRIORITY_RESIZE. > > Federico > > _______________________________________________ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-devel-list From ross@burtonini.com Fri Jun 9 07:15:10 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 1192B3B0099 for ; Fri, 9 Jun 2006 07:15:10 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18418-03 for ; Fri, 9 Jun 2006 07:15:08 -0400 (EDT) Received: from smtp.nildram.co.uk (smtp.nildram.co.uk [195.112.4.54]) by menubar.gnome.org (Postfix) with ESMTP id 279213B0081 for ; Fri, 9 Jun 2006 07:15:07 -0400 (EDT) Received: from burtonini.com (althur.gotadsl.co.uk [84.12.135.175]) by smtp.nildram.co.uk (Postfix) with ESMTP id 1DDA833C3F2; Fri, 9 Jun 2006 12:11:26 +0100 (BST) Received: from 127.0.0.1 (ident=unknown) by burtonini.com with esmtp (masqmail 0.2.21) id 1Foetj-17d-00; Fri, 09 Jun 2006 12:11:27 +0100 From: Ross Burton To: Michael Natterer In-Reply-To: <1149849193.3010.23.camel@localhost> References: <1149608483.14088.54.camel@cacharro.xalalinux.org> <1149849193.3010.23.camel@localhost> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-DKvhrUfzvCjsapgkUotZ" Date: Fri, 09 Jun 2006 12:11:27 +0100 Message-Id: <1149851487.2333.2.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.456 tagged_above=-999 required=2 tests=[AWL=0.008, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.456 X-Spam-Level: Cc: Federico Mena Quintero , GTK+ development mailing list , Michael.meeks@novell.com Subject: Re: Default timeouts X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2006 11:15:10 -0000 --=-DKvhrUfzvCjsapgkUotZ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2006-06-09 at 12:33 +0200, Michael Natterer wrote: > Actually, it may make sense to simply use the user's configured > key repeat and delay for these two setting values. What do you > think? That's probably a very good idea, on the grounds that people set the keyboard delay/repeat to values they can handle (i.e. my Dad has slowed them down as he isn't as fast as he used to be). What are the system defaults for the keyboard delay/repeat? Ross --=20 Ross Burton mail: ross@burtonini.com jabber: ross@burtonini.com www: http://www.burtonini.com./ PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF --=-DKvhrUfzvCjsapgkUotZ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQBEiVdeLQnkR9C0M98RAp+DAJ9s9H2qD2A4AQ6kXwgB+B6ka0ve8QCfZcQL IPi9sLP/fY2zOVLCX+eSrvo= =LNZu -----END PGP SIGNATURE----- --=-DKvhrUfzvCjsapgkUotZ-- From timj@gtk.org Fri Jun 9 13:30:55 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 1CAD23B00E9 for ; Fri, 9 Jun 2006 13:30:55 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10186-10 for ; Fri, 9 Jun 2006 13:30:52 -0400 (EDT) Received: from webmail.hansenet.de (mail03.hansenet.de [213.191.73.10]) by menubar.gnome.org (Postfix) with ESMTP id E3A183B011B for ; Fri, 9 Jun 2006 13:30:51 -0400 (EDT) Received: from birnet.org (80.171.4.161) by webmail.hansenet.de (7.2.059) id 4487A06D0006D98F; Fri, 9 Jun 2006 19:30:40 +0200 Received: from master.birnet.private (localhost [127.0.0.1]) by birnet.org (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k59HUdVg010604 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 9 Jun 2006 19:30:39 +0200 Received: (from timj@localhost) by master.birnet.private (8.13.4/8.13.4/Submit) id k59HUPEO010599; Fri, 9 Jun 2006 19:30:25 +0200 Date: Fri, 9 Jun 2006 19:30:25 +0200 (CEST) From: Tim Janik X-X-Sender: timj@master.birnet.private To: "Kaveh R. Ghazi" In-Reply-To: <200606091630.k59GUaES013244@caipclassic.rutgers.edu> Message-ID: References: <20060609152646.GE20719@space.twc.de> <200606091630.k59GUaES013244@caipclassic.rutgers.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.469 tagged_above=-999 required=2 tests=[AWL=0.130, BAYES_00=-2.599] X-Spam-Score: -2.469 X-Spam-Level: Cc: gcc@gcc.gnu.org, Gtk+ Developers Subject: Re: Problem with type safety and the "sentinel" attribute X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2006 17:30:55 -0000 thanks for the quick response Kaveh. On Fri, 9 Jun 2006, Kaveh R. Ghazi wrote: > > > void print_string_array (const char *array_name, > > const char *string, ...) __attribute__ > > ((__sentinel__)); > > > > print_string_array ("empty_array", NULL); /* gcc warns, but shouldn't */ > > > > The only way out for keeping the sentinel attribute and avoiding the > > warning is using > > > > static void print_string_array (const char *array_name, ...) > > __attribute__ ((__sentinel__)); > > I think you could maintain typesafety and silence the warning by > keeping the more specific prototype and adding an extra NULL, e.g.: > > print_string_array ("empty_array", NULL, NULL); > > Doesn't seem elegant, but it does the job. this is an option for a limited set of callers, yes. > > By the way, there is already an existing gcc bug, which is about the > > same thing (NULL passed within named args), but wants to have it the > > way it works now: > > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21911 > > Correct, the feature as I envisioned it expected the sentinel to > appear in the variable arguments only. This PR reflects when I found > out it didn't do that and got around to fixing it. Note the "buggy" > behavior wasn't exactly what you wanted either because GCC got fooled > by a sentinel in *any* of the named arguments, not just the last one. > > > > so if it gets changed, then gcc might need to support both > > - NULL termination within the last named parameter allowed > > - NULL termination only allowed within varargs parameters (like it is > > now) > > I'm not against this enhancement, but you need to specify a syntax > that allows the old behavior but also allows doing it your way. > > Hmm, perhaps we could check for attribute "nonnull" on the last named > argument, if it exists then that can't be the sentinel, if it's not > there then it does what you want. This is not completely backwards > compatible because anyone wanting the existing behavior has to add the > attribute nonnull. But there's precedent for this when attribute > printf split out whether the format specifier could be null... > > We could also create a new attribute name for the new behavior. This > would preserve backwards compatibility. I like this idea better. i agree here. as far as the majority of the GLib and Gtk+ APIs are concerned, we don't really need the flexibility of the sentinel attribute but rather a compiler check on whether the last argument used in a function call is NULL or 0 (regardless of whether it's the last named arg or already part of the varargs list). that's also why the actual sentinel wrapper in GLib looks like this: #define G_GNUC_NULL_TERMINATED __attribute__((__sentinel__)) so, if i was to make a call on this issue, i'd either introduce __attribute__((__null_terminated__)) with the described semantics, or have __attribute__((__sentinel__(-1))) work essentially like __attribute__((__sentinel__(0))) while also accepting 0 in the position of the last named argument. > Next you need to recruit someone to implement this enhancement, or > submit a patch. :-) Although given that you can silence the warning by > adding an extra NULL at the call site, I'm not sure it's worth it. i would say this is definitely worth it, because the issue also shows up in other code that is widely used: gpointer g_object_new (GType object_type, const gchar *first_property_name, ...); that's for instance a function which is called in many projects. putting the burden on the caller is clearly the wrong trade off here. so please take this as a vote for the worthiness of a fix ;) > --Kaveh > -- > Kaveh R. Ghazi ghazi@caip.rutgers.edu --- ciaoTJ From nshmyrev@yandex.ru Sat Jun 10 02:06:32 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 347973B00D0 for ; Sat, 10 Jun 2006 02:06:32 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12492-03 for ; Sat, 10 Jun 2006 02:06:28 -0400 (EDT) Received: from chen.mtu.ru (chen.mtu.ru [195.34.34.232]) by menubar.gnome.org (Postfix) with ESMTP id 78AC43B0126 for ; Sat, 10 Jun 2006 02:06:28 -0400 (EDT) Received: from gnome.local (ppp83-237-50-138.pppoe.mtu-net.ru [83.237.50.138]) by smtp.MTU.RU (Postfix) with ESMTP id D51B453DA7E; Sat, 10 Jun 2006 10:06:25 +0400 (MSD) (envelope-from nshmyrev@yandex.ru) From: "Nickolay V. Shmyrev" To: gtk-devel-list@gnome.org, gnome-i18n@gnome.org Content-Type: text/plain Date: Sat, 10 Jun 2006 10:06:30 +0400 Message-Id: <1149919590.2305.18.camel@gnome.local> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 (2.6.2-1.fc5.3) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.758 tagged_above=-999 required=2 tests=[AWL=-0.440, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, SPF_NEUTRAL=1.069, TW_GT=0.077] X-Spam-Score: -1.758 X-Spam-Level: Cc: Subject: Translation of gtk tuturial X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2006 06:06:32 -0000 Hello all. I now there was done quite amazing work about translation of gtk tutorial and I know there were some other translations http://linfoline.homedns.org/gtk/book1.html http://kldp.org/KoreanDoc/html/GtkTutorial/GtkTutorial.html What about making gtk tutorial translatable with docutils like all user documentation and merging those translations upstream? I don't ask about reference manual translation but it's also interesting, although not realistic. Probably it's not sensible to distribute tutorial with gtk package itself but use something like a web-based Rosetta. From matthias.clasen@gmail.com Sat Jun 10 10:02:35 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id A74883B0280 for ; Sat, 10 Jun 2006 10:02:35 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06778-09 for ; Sat, 10 Jun 2006 10:02:33 -0400 (EDT) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.200]) by menubar.gnome.org (Postfix) with ESMTP id 1C56D3B01C3 for ; Sat, 10 Jun 2006 10:02:33 -0400 (EDT) Received: by nz-out-0102.google.com with SMTP id z3so947001nzf for ; Sat, 10 Jun 2006 07:02:32 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=jUGG9w5BYrTkFmK4uobvwaXzJ1w3H4k8DuZIFGIHoBjFn1kgtf//lWo+engDAz0ImbOYOsKrWjvA9YAXvpwCcamcXXpE51E09vtpA8lmZKxAt+RA6AWeMX4blO5srWeestsf+E6dRd0OwZUmD3OCksEXAdLAjQcGBJBiKLVKPnQ= Received: by 10.37.15.76 with SMTP id s76mr5772218nzi; Sat, 10 Jun 2006 07:02:32 -0700 (PDT) Received: by 10.37.21.6 with HTTP; Sat, 10 Jun 2006 07:02:32 -0700 (PDT) Message-ID: Date: Sat, 10 Jun 2006 10:02:32 -0400 From: "Matthias Clasen" To: "Nickolay V. Shmyrev" In-Reply-To: <1149919590.2305.18.camel@gnome.local> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1149919590.2305.18.camel@gnome.local> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.471 tagged_above=-999 required=2 tests=[AWL=0.052, BAYES_00=-2.599, SPF_PASS=-0.001, TW_GT=0.077] X-Spam-Score: -2.471 X-Spam-Level: Cc: gnome-i18n@gnome.org, gtk-devel-list@gnome.org Subject: Re: Translation of gtk tuturial X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2006 14:02:35 -0000 On 6/10/06, Nickolay V. Shmyrev wrote: > Hello all. > > I now there was done quite amazing work about translation of gtk > tutorial and I know there were some other translations > > http://linfoline.homedns.org/gtk/book1.html > > http://kldp.org/KoreanDoc/html/GtkTutorial/GtkTutorial.html > > What about making gtk tutorial translatable with docutils like all > user documentation and merging those translations upstream? > > I don't ask about reference manual translation but it's also interesting, > although not realistic. Probably it's not sensible to distribute tutorial > with gtk package itself but use something like a web-based Rosetta. > The first step towards making the tutorial more useful would be updating its 2.0 era content, remove deprecated apis, and cover at least some of the important new apis. From lists@nabble.com Sat Jun 10 13:20:05 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id BB53E3B01B8 for ; Sat, 10 Jun 2006 13:20:05 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16672-08 for ; Sat, 10 Jun 2006 13:20:04 -0400 (EDT) Received: from talk.nabble.com (www.nabble.com [72.21.53.35]) by menubar.gnome.org (Postfix) with ESMTP id 2730A3B01D7 for ; Sat, 10 Jun 2006 13:20:04 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=talk.nabble.com) by talk.nabble.com with esmtp (Exim 4.50) id 1Fp77z-0000O0-FG for gtk-devel-list@gnome.org; Sat, 10 Jun 2006 10:20:03 -0700 Message-ID: <4809607.post@talk.nabble.com> Date: Sat, 10 Jun 2006 10:20:03 -0700 (PDT) From: mikecorn To: gtk-devel-list@gnome.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-Sender: mikecorn@t-online.de X-Nabble-From: mikecorn X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.565 tagged_above=-999 required=2 tests=[AWL=0.036, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.565 X-Spam-Level: Subject: GTK window edge detection sensitivity X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2006 17:20:05 -0000 To: GTK developers The resizable windows in Gnome are slick, but I often have a minor problem: After the mouse cursor changes form, indicating that the window edge is in-range for dragging, I often find myself dragging across the window behind, because the edge range was lost shortly after it was found. I ask you to consider possible improvements to make this work more reliably and with less precision required (which also means faster for the user). 1. increase the edge-detection threshold by 2x or more, or make it user-adjustable. 2. once the edge is detected, increase the threshold for losing it (time or distance). regards Mike C. -- View this message in context: http://www.nabble.com/GTK-window-edge-detection-sensitivity-t1767067.html#a4809607 Sent from the Gtk+ - Dev - General forum at Nabble.com. From marcel@telka.sk Sat Jun 10 23:05:18 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 2D8C03B05D2 for ; Sat, 10 Jun 2006 23:05:18 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06780-08 for ; Sat, 10 Jun 2006 23:05:16 -0400 (EDT) Received: from tortuga.telka.sk (unknown [193.86.173.20]) by menubar.gnome.org (Postfix) with SMTP id 7D8283B0543 for ; Sat, 10 Jun 2006 23:05:15 -0400 (EDT) Received: (qmail 14272 invoked by uid 0); 11 Jun 2006 02:57:43 -0000 Date: 11 Jun 2006 02:57:43 -0000 Message-ID: <20060611025743.14269.qmail@tortuga.telka.sk> To: From: Marcel Telka X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.443 tagged_above=-999 required=2 tests=[AWL=0.156, BAYES_00=-2.599] X-Spam-Score: -2.443 X-Spam-Level: Subject: gtk+: Missing translatable files X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jun 2006 03:05:18 -0000 Hi. I have tested module gtk+ (CVS branch HEAD) which lives in GNOME CVS for missing translatable files with `intltool-update -m` command. Here is a content of the 'missing' file: gtk/gtkfilechoosersettings.c gtk/gtkprintoperationpreview.c Please put these files into POTFILES.in or POTFILES.skip files. Thanks. Note: This report is generated automatically and you are not required to reply to this mail. If you are not maintainer of the 'gtk+' module or this CVS branch is obsolete or you don't want similar report in future, tell me and I will stop this report generation. Regards. -- +-------------------------------------------+ | Marcel Telka e-mail: marcel@telka.sk | | homepage: http://telka.sk/ | | jabber: marcel@jabber.sk | +-------------------------------------------+ From easy-b@freesurf.ch Sun Jun 11 16:22:48 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id ABE753B0159 for ; Sun, 11 Jun 2006 16:22:48 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32516-10 for ; Sun, 11 Jun 2006 16:22:46 -0400 (EDT) Received: from mail-fs.sunrise.ch (mta-fs-be-04.sunrise.ch [194.158.229.33]) by menubar.gnome.org (Postfix) with ESMTP id A306E3B00CA for ; Sun, 11 Jun 2006 16:22:45 -0400 (EDT) Received: from [10.0.1.2] (84.227.173.50) by mail-fs.sunrise.ch (7.2.073) id 44858C490024803A; Sun, 11 Jun 2006 22:21:55 +0200 In-Reply-To: References: <20060522160033.F1A8E3B1CE4@menubar.gnome.org> <772588ED-500A-4A11-8829-DA80B9A35D1F@freesurf.ch> <44720B8C.3080903@imendio.com> <0A34FCC9-6650-4737-B86D-1B503D8A9072@freesurf.ch> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7D6367DC-8689-453B-8FD7-217632BC1DAE@freesurf.ch> Content-Transfer-Encoding: 7bit From: Easy B Date: Sun, 11 Jun 2006 22:21:54 +0200 To: Gregor Riepl X-Mailer: Apple Mail (2.749.3) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.312 tagged_above=-999 required=2 tests=[AWL=-0.787, BAYES_00=-2.599, DNS_FROM_RFC_POST=1.708, FORGED_RCVD_HELO=0.135, TW_BG=0.077, TW_GD=0.077, TW_GT=0.077] X-Spam-Score: -1.312 X-Spam-Level: Cc: gtk-devel-list@gnome.org Subject: Mac OS X Framework X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jun 2006 20:22:48 -0000 Hoi Gregor Thanx for the Tips. This would make the Framework more like one. The ability to include it into the application bundle would be very handy. If I look at other Frameworks I always find a single library in the top directory, for example: /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ Frameworks/ImageIO.framework/ImageIO If I do "otool -L /System/Library/Frameworks/ ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/ ImageIO", I get references to many other libraries that are located inside the framework bundle: /System/Library/Frameworks/ApplicationServices.framework/ Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/ libJPEG.dylib (compatibility version 1.0.0, current version 1.0.0) /System/Library/Frameworks/ApplicationServices.framework/ Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/ libJP2.dylib (compatibility version 1.0.0, current version 1.0.0) /System/Library/Frameworks/ApplicationServices.framework/ Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/ libGIF.dylib (compatibility version 1.0.0, current version 1.0.0) /System/Library/Frameworks/ApplicationServices.framework/ Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/ libRaw.dylib (compatibility version 1.0.0, current version 1.0.0) /System/Library/Frameworks/ApplicationServices.framework/ Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/ libTIFF.dylib (compatibility version 1.0.0, current version 1.0.0) /System/Library/Frameworks/ApplicationServices.framework/ Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/ libPng.dylib (compatibility version 1.0.0, current version 1.0.0) /System/Library/Frameworks/ApplicationServices.framework/ Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/ libRadiance.dylib (compatibility version 1.0.0, current version 1.0.0) In my Gtk+.framework I have tons of libraries. Would it be possible to create something like the above for gtk? Would it make sense? Right now I just use pkg-config to find the libraries and the result looks like this: /Applications/Shity Apps/Gtk-Demo.app/Contents/MacOS/gtk-demo: /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libgdk_pixbuf-2.0.0.dylib (compatibility version 902.0.0, current version 902.0.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libgdk-quartz-2.0.0.dylib (compatibility version 902.0.0, current version 902.0.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libgtk-quartz-2.0.0.dylib (compatibility version 902.0.0, current version 902.0.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libpangocairo-1.0.0.dylib (compatibility version 1301.0.0, current version 1301.1.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libpangoft2-1.0.0.dylib (compatibility version 1301.0.0, current version 1301.1.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libpango-1.0.0.dylib (compatibility version 1301.0.0, current version 1301.1.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libatk-1.0.0.dylib (compatibility version 1115.0.0, current version 1115.0.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libgobject-2.0.0.dylib (compatibility version 1102.0.0, current version 1102.0.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libgmodule-2.0.0.dylib (compatibility version 1102.0.0, current version 1102.0.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libglib-2.0.0.dylib (compatibility version 1102.0.0, current version 1102.0.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libcairo.2.dylib (compatibility version 9.0.0, current version 9.0.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libpng12.0.dylib (compatibility version 11.0.0, current version 11.0.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libfontconfig.1.dylib (compatibility version 2.0.0, current version 2.4.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libfreetype.6.dylib (compatibility version 10.0.0, current version 10.8.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libxml2.2.dylib (compatibility version 9.0.0, current version 9.24.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libintl.3.dylib (compatibility version 8.0.0, current version 8.3.0) What do you think? Cheers, Ezra. On 11.06.2006, at 10:22, Gregor Riepl wrote: > Hi Ezra > >> Well it's looking better now. I even ended up with ready to use >> Installers. I still got my pkg-config/headers problem though so >> the script still has some ugly hard links in it., besides all the >> other debugging ugliness. I'm also not sure if the framework is >> usable the way it's now. I will first have to try to compile some >> apps against it. I'll definitely come with more problems soon. > > To make a framework fully usable, it's dynamic library paths need > to be adapted with install_name_tool. > For example, its the self-reference should be > @executable_path/../Frameworks/.framework/ > Versions/A/ > This makes the library includable in application bundles, instead > of having to install it. > But you may of course also use /Library/Frameworks/ framework>.framework/Versions/A/ > Have a look at the output of otool -L for some system and user- > installed libraries, i.e. > > $ otool -L /System/Library/Frameworks/Cocoa.framework/Cocoa > /System/Library/Frameworks/Cocoa.framework/Cocoa: > /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa > (compatibility version 1.0.0, current version 11.0.0) > /System/Library/Frameworks/AppKit.framework/Versions/C/ > AppKit (compatibility version 45.0.0, current version 822.0.0) > /System/Library/Frameworks/CoreData.framework/Versions/A/ > CoreData (compatibility version 1.0.0, current version 46.0.0) > /System/Library/Frameworks/Foundation.framework/Versions/C/ > Foundation (compatibility version 300.0.0, current version 566.0.0) > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, > current version 88.0.0) > > or > > $ otool -L /Library/Frameworks/SDL_image.framework/SDL_image > /Library/Frameworks/SDL_image.framework/SDL_image: > @executable_path/../Frameworks/SDL_image.framework/Versions/ > A/SDL_image (compatibility version 1.0.0, current version 1.0.0) > @executable_path/../Frameworks/SDL.framework/Versions/A/SDL > (compatibility version 1.0.0, current version 1.0.0) > /usr/lib/libz.1.dylib (compatibility version 1.0.0, current > version 1.0.0) > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, > current version 71.1.1) > > If a library has a lot of dependencies, you may run into a problem > here: The Mach-O header's area for library references isn't of > variable size, and install_name_tool may refuse to change all > paths. There's afaik no other way then to relink the binary with > the option -headerpad_max_install_names (see man ld). > From mclasen@redhat.com Mon Jun 12 12:04:32 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 41C3B3B000C; Mon, 12 Jun 2006 12:04:32 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09149-04; Mon, 12 Jun 2006 12:04:29 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id 7270D3B009D; Mon, 12 Jun 2006 12:04:29 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5CG3bc9030255; Mon, 12 Jun 2006 12:03:37 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5CG3bc3007778; Mon, 12 Jun 2006 12:03:37 -0400 Received: from golem.boston.redhat.com (golem.boston.redhat.com [172.16.80.24]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id k5CG3blQ018463; Mon, 12 Jun 2006 12:03:37 -0400 From: Matthias Clasen To: gnome-announce-list@gnome.org, gtk-devel-list@gnome.org, gtk-app-devel-list@gnome.org, gtk-list@gnome.org Content-Type: text/plain Date: Mon, 12 Jun 2006 12:03:36 -0400 Message-Id: <1150128216.15532.14.camel@golem.boston.redhat.com> Mime-Version: 1.0 X-Mailer: Evolution 2.7.1 (2.7.1-1) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.426 tagged_above=-999 required=2 tests=[AWL=-0.056, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, TW_LQ=0.077, TW_RX=0.077, TW_TR=0.077] X-Spam-Score: -2.426 X-Spam-Level: Cc: Subject: GLib 2.11.3 released X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gome-hackers@gnome.org List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2006 16:04:32 -0000 GLib 2.11.3 is now available for download at: ftp://ftp.gtk.org/pub/gtk/v2.11/ http://ftp.gnome.org/pub/GNOME/sources/glib/2.11/ glib-2.11.3.tar.bz2 md5sum: 41931c4965f7e1848f81b800914905cd glib-2.11.3.tar.gz md5sum: cd78ebc535e29cdef0fed9487aa21dac This is a development release leading up to GLib 2.12. Notes: * This is unstable development release. While it has had a bit of testing, there are certainly plenty of bugs remaining to be found. This release should not be used in production. * Installing this version will overwrite your existing copy of GLib 2.10. If you have problems, you'll need to reinstall GLib 2.10. * GLib 2.12 will be source and binary compatible with the GLib 2.10.x series (for some caveats, see the README). At this point, the API additions in the 2.11.x series are almost finished. * Bugs should be reported to http://bugzilla.gnome.org. About GLib ========== GLib is the low-level core library that forms the basis for projects such as GTK+ and GNOME. It provides data structure handling for C, portability wrappers, and interfaces for such runtime functionality as an event loop, threads, dynamic loading, and an object system. More information about GLib is available at: http://www.gtk.org/ An installation guide for the GTK+ libraries, including GLib, can be found at: http://developer.gnome.org/doc/API/2.0/gtk/gtk-building.html Overview of Changes from GLib 2.11.2 to GLib 2.11.3 =================================================== * GBookmarkFile: - g_bookmark_file_move_item: Return TRUE in case of an empty target * Bugs fixed: 343919 gunicollate.c: strxfrm bug on VC8 * Updated translations (fi) A list of all bugs fixed in this release can be found at: http://bugzilla.gnome.org/buglist.cgi?bug_id=343919 Thanks to everybody who has contributed to this release, in the form of bug reports or patches: Emmanuele Bassi, Kazuki Iwamoto, Tor Lillqvist Matthias Clasen June 12, 2006 From mclasen@redhat.com Mon Jun 12 15:43:04 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 851123B00E5; Mon, 12 Jun 2006 15:43:04 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27729-06; Mon, 12 Jun 2006 15:43:02 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id 5B16F3B0010; Mon, 12 Jun 2006 15:43:02 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5CJZWav007572; Mon, 12 Jun 2006 15:35:32 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5CJZWUd001833; Mon, 12 Jun 2006 15:35:32 -0400 Received: from golem.boston.redhat.com (golem.boston.redhat.com [172.16.80.24]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id k5CJZWlQ009694; Mon, 12 Jun 2006 15:35:32 -0400 From: Matthias Clasen To: gnome-announce-list@gnome.org, gtk-devel-list@gnome.org, gtk-app-devel-list@gnome.org, gtk-list@gnome.org Content-Type: text/plain Date: Mon, 12 Jun 2006 15:35:31 -0400 Message-Id: <1150140931.15532.18.camel@golem.boston.redhat.com> Mime-Version: 1.0 X-Mailer: Evolution 2.7.1 (2.7.1-1) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.541 tagged_above=-999 required=2 tests=[AWL=0.060, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.541 X-Spam-Level: Cc: Subject: GTK+ 2.8.19 released X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gnome-hackers@gnome.org List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2006 19:43:04 -0000 GTK+ 2.8.19 is now available for download at: ftp://ftp.gtk.org/pub/gtk/v2.8/ http://ftp.gnome.org/pub/GNOME/sources/gtk+/2.8/ gtk+-2.8.19.tar.bz2 md5sum: 1a03dbed4b794194a610e9d7eb175b06 gtk+-2.8.19.tar.gz md5sum: 604d3263498994c58af378f0ec076e6f This is a bugfix release in the 2.8.x series. It fixes a rare memory corruption issue when using the deprecated GdkFont API. What is GTK+ ============ GTK+ is a multi-platform toolkit for creating graphical user interfaces. Offering a complete set of widgets, GTK+ is suitable for projects ranging from small one-off tools to complete application suites. GTK+ has been designed from the ground up to support a range of languages, not only C/C++. Using GTK+ from languages such as Perl and Python (especially in combination with the Glade GUI builder) provides an effective method of rapid application development. GTK+ is free software and part of the GNU Project. However, the licensing terms for GTK+, the GNU LGPL, allow it to be used by all developers, including those developing proprietary software, without any license fees or royalties. Where to get more information about GTK+ ======================================== Information about GTK+ including links to documentation can be found at: http://www.gtk.org/ An installation guide for GTK+ 2.8 is found at: http://developer.gnome.org/doc/API/2.0/gtk/gtk-building.html Common questions: http://developer.gnome.org/doc/API/2.0/gtk/gtk-question-index.html http://www.gtk.org/faq/ Overview of Changes from GTK+ 2.8.18 to GTK+ 2.8.19 =================================================== Bugs fixed: 341327 Memory corruption inside glib 337491 _gdk_win32_drawable_release_dc: DeleteDC() called on a GetDC() handle 343425 "grab-notify"-signal is not correctly propagated for internal children 344244 Window resizing not working when keeping the aspect fixed 344496 CRLF converting via Clipboard Updated translations (ne) A list of all bugs fixed in this release can be found at: http://bugzilla.gnome.org/buglist.cgi?bug_id=343425,341327,344244,337491,344496 Thanks to everybody who has contributed to this release, in the form of bug reports or patches: Markku Vire, Sampo Savolainen, Tim Janik, Tor Lillqvist, Chris Wilson June 12, 2006 Matthias Clasen From mclasen@redhat.com Tue Jun 13 02:09:16 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 72FE93B00AF; Tue, 13 Jun 2006 02:09:16 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12183-04; Tue, 13 Jun 2006 02:09:13 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id B2F773B000C; Tue, 13 Jun 2006 02:09:13 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5D681s3022181; Tue, 13 Jun 2006 02:08:01 -0400 Received: from lacrosse.corp.redhat.com (lacrosse.corp.redhat.com [172.16.52.154]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5D67uRP017686; Tue, 13 Jun 2006 02:07:56 -0400 Received: from [172.16.83.145] (vpn83-145.boston.redhat.com [172.16.83.145]) by lacrosse.corp.redhat.com (8.12.11.20060308/8.11.6) with ESMTP id k5D67tQC015619; Tue, 13 Jun 2006 02:07:56 -0400 From: Matthias Clasen To: gnome-announce-list@gnome.org, gtk-devel-list@gnome.org, gtk-app-devel-list@gnome.org, gtk-list@gnome.org Content-Type: text/plain; charset=UTF-8 Organization: Red Hat Date: Tue, 13 Jun 2006 02:09:42 -0400 Message-Id: <1150178982.4081.13.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.7.2.1 (2.7.2.1-4) Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.426 tagged_above=-999 required=2 tests=[AWL=-0.056, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, TW_GD=0.077, TW_GT=0.077, TW_KB=0.077] X-Spam-Score: -2.426 X-Spam-Level: Cc: Subject: GTK+ 2.9.3 released X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gnome-hackers@gnome.org List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2006 06:09:16 -0000 GTK+ 2.9.3 is now available for download at: ftp://ftp.gtk.org/pub/gtk/v2.9/ http://ftp.gnome.org/pub/gnome/sources/gtk+/2.9/ gtk+-2.9.3.tar.bz2 md5sum: d73039a3b5847c352f5740ac908be7d2 gtk+-2.9.3.tar.gz md5sum: 0156eef91d2bbb23f1b6ccb49335fae5 This is a development release leading up to GTK+ 2.10. Notes: * This is unstable development release. There are certainly plenty of bugs remaining to be found. This release should not be used in production. * Installing this version will overwrite your existing copy of GTK+ 2.8. If you have problems, you'll need to reinstall GTK+ 2.8. * GTK+ 2.10 will be source compatible with the GTK+ 2.8 series; the new API additions in GTK+ 2.9.0 are not yet completely finalized, so there are likely incompatibilies between this release and the final 2.10 release. * The ABI version has been bumped from 2.4.0 to 2.10.0, since the filechooser backend interface has been changed. Third-party filechooser backends need to be ported to the new interface. Other third-party modules (input methods, image loaders, etc) just need to be reinstalled in the proper location for GTK+ to find them. * Remaining issues for GTK+ 2.10 can be found with following bugzilla query: http://bugzilla.gnome.org/buglist.cgi?product=gtk%2b&target_milestone=2.10+API+Freeze&target_milestone=2.10+Freeze&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED * Bugs should be reported to http://bugzilla.gnome.org. What is GTK+ ============ GTK+ is a multi-platform toolkit for creating graphical user interfaces. Offering a complete set of widgets, GTK+ is suitable for projects ranging from small one-off tools to complete application suites. GTK+ has been designed from the ground up to support a range of languages, not only C/C++. Using GTK+ from languages such as Perl and Python (especially in combination with the Glade GUI builder) provides an effective method of rapid application development. GTK+ is free software and part of the GNU Project. However, the licensing terms for GTK+, the GNU LGPL, allow it to be used by all developers, including those developing proprietary software, without any license fees or royalties. Where to get more information about GTK+ ======================================== Information about GTK+ including links to documentation can be found at: http://www.gtk.org/ An installation guide for GTK+ 2.x is found at: http://developer.gnome.org/doc/API/2.4/gtk/gtk-building.html Common questions: http://developer.gnome.org/doc/API/2.4/gtk/gtk-question-index.html http://www.gtk.org/faq/ Overview of Changes from GTK+ 2.9.2 to 2.9.3 ============================================ * GtkPrintOperation: - Introduce an allow-async property - Introduce a GtkPrintOperationAction enumeration - Rename pdf_target to export_filename - Allow to hide "Print to PDF" in the low-level API * GtkNotebook: - Add a destroy notify to gtk_notebook_set_window_creation_hook. * GtkTreeView: - Support grid lines * GtkRange: - Add a number of new stle properties which allow more fexible stepper theming * Bugs fixed: 153212 Have the Paste kbd shortcut jump to the location in the buffer 337491 _gdk_win32_drawable_release_dc: DeleteDC() called on a GetDC() handle 339739 gtk/gtkprintoperation-win32.c: 3 compile error 342339 GtkRange::stepper-spacing style property not implemented correctly 343945 Buttons of a GtkAssistant are not accessible 344148 Wrong reqs for ATK 344209 gtk_notebook_set_window_creation_hook() has no destroy func. 344232 GtkEntry's "Delete" context menu item is sensitive on a non-editable GtkEntry 344244 Window resizing not working when keeping the aspect fixed 344288 gtk_print_operation_preview_is_selected must return a value 344386 gdk-2.0-uninstalled.pc.in and gdkconfig.h 344496 CRLF converting via Clipboard 344504 GtkPrintCapabilities not in gtktypebuiltins.h 344505 Wrong signal registration for create_custom_widget 344512 cvs build issue 344513 pdf print module's print_stream not calling destroy notify 344518 NULL unref in page setup dialogue 344543 gtk_progress_bar_pulse calls gtk_progress_bar_paint directly 344560 gtk_print_settings_[sg]et_scale shouldn't be in percent 344607 memory leaks in gtkrecentchooserdefault.c and gtkrecentchoosermenu.c 344624 Memory leak in gtk_tree_model_filter_finalize: User data not freed 337603 Possible off-by-one in gdk_pango_layout_line_get_clip_region 344239 Wrong filename for gtk-find stock item. 344528 comma at end of GtkPrintOperationAction enum causes mozilla compilation error 344290 horizontal-padding not take into account when placing submenus 344558 document print dialogue response codes 339592 Add print-to-postscript 342249 Allow to draw upper and lower sides of GtkRange's trough differently 344530 gtk_recent_chooser_widget_new_for_manager and gtk_recent_chooser_menu_new_for_manager should allow NULL manager arg * Updated translations (es,fi,gu,ko,th,wa) A list of all bugs fixed in this release can be found at: http://bugzilla.gnome.org/buglist.cgi?bug_id=153212,337491,339739,342339,343945,344148,344209,344232,344244,344288,344386,344496,344504,344505,344512,344513,344518,344543,344560,344607,344624,337603,344239,344528,344290,344558,339592,342249,344530 Thanks to everybody who has contributed to this release, in the form of bug reports or patches: Behdad Esfahbod, Bastian Nocera, Alexander Larsson, Jürg Billeter, Murray Cumming, Milosz Derezynski, Tor Lillqvist, Kazuki Iwamoto, Chris Wilson, Michael Natterer, Benjamin Berg, Marko Anastasov, Christian Persch, Masatake Yamamoto, Elijah Newren, John Finlay, Emmanuele Bassi, David Malcolm, John Darrington, Christian Weiske, Yvgen Muntyan, Martyn Russell, Kristian Rietveld June 13, 2006 Matthias Clasen From exe522@hotmail.com Tue Jun 13 09:17:01 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 1FF7B3B000A for ; Tue, 13 Jun 2006 09:17:01 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24109-07 for ; Tue, 13 Jun 2006 09:17:00 -0400 (EDT) Received: from hotmail.com (bay104-f2.bay104.hotmail.com [65.54.175.12]) by menubar.gnome.org (Postfix) with ESMTP id 4C4843B00AF for ; Tue, 13 Jun 2006 09:17:00 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 13 Jun 2006 06:16:02 -0700 Message-ID: Received: from 65.54.175.200 by by104fd.bay104.hotmail.msn.com with HTTP; Tue, 13 Jun 2006 13:15:57 GMT X-Originating-IP: [86.212.127.235] X-Originating-Email: [exe522@hotmail.com] X-Sender: exe522@hotmail.com In-Reply-To: <2672cf4d0606050752o12a6d0d2gcb4c355cc0f35d79@mail.gmail.com> From: "Malik NakaMura" To: domlachowicz@gmail.com Date: Tue, 13 Jun 2006 13:15:57 +0000 Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed X-OriginalArrivalTime: 13 Jun 2006 13:16:02.0831 (UTC) FILETIME=[851C21F0:01C68EEB] X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-0.736 tagged_above=-999 required=2 tests=[AWL=-1.532, BAYES_05=-1.11, DNS_FROM_RFC_ABUSE=0.2, DNS_FROM_RFC_POST=1.708, MSGID_FROM_MTA_HEADER=0, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -0.736 X-Spam-Level: Cc: gtk-devel-list@gnome.org Subject: Re: GTK+ >> Cocoa Native Port X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2006 13:17:01 -0000 This is my first version of _gdk_quartz_copy_to_image. The only problem is that I didnt succeed in getting the color map from "drawable"... so the image is displayed without its original colors GdkImage * _gdk_quartz_copy_to_image (GdkDrawable *drawable, GdkImage *image, gint src_x, gint src_y, gint dest_x, gint dest_y, gint width, gint height) { GdkPixbuf *pixbuf; //printf("_gdk_quartz_copy_to_image : To Implement\n"); pixbuf = NULL; image = g_object_new (gdk_image_get_type (), NULL); image->type = GDK_TYPE_IMAGE; image->width = width; image->height = height; image->byte_order = (G_BYTE_ORDER == G_LITTLE_ENDIAN) ? GDK_LSB_FIRST : GDK_MSB_FIRST; image->bpp = 4; image->bpl = image->width * image->bpp; image->bits_per_pixel = image->bpp * 8; image->colormap = (GdkColormap *)g_malloc(sizeof(GdkColormap)); memcpy(image->colormap, GDK_DRAWABLE_IMPL_QUARTZ (&(GDK_PIXMAP_IMPL_QUARTZ (drawable)->parent_instance))->colormap, sizeof(GdkColormap)); if(image->colormap != NULL) { image->visual = (GdkVisual *)g_malloc(sizeof(GdkVisual)); memcpy(image->visual, gdk_colormap_get_visual (image->colormap), sizeof(GdkVisual)); if (image->visual) { void *data; int x, y; guint32 *pix, *pixels; image->depth = image->visual->depth; image->mem = g_malloc (image->bpl * image->height); memset (image->mem, 0x00, image->bpl * image->height); data = GDK_PIXMAP_IMPL_QUARTZ (drawable)->data; pixels = (guint32 *)data; for (y = 0; y < image->height; y++) { pix = pixels+((image->height - 1 - y)*width); for (x = 0; xwidth; x++) { gdk_image_put_pixel (image, x, y, *pix); pix++; } } return image; } } g_free(image); image = NULL; return NULL; } From kloczek@rudy.mif.pg.gda.pl Tue Jun 13 09:41:41 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 2C9B33B008F for ; Tue, 13 Jun 2006 09:41:41 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24974-03 for ; Tue, 13 Jun 2006 09:41:37 -0400 (EDT) Received: from rudy.mif.pg.gda.pl (rudy.mif.pg.gda.pl [153.19.42.16]) by menubar.gnome.org (Postfix) with ESMTP id 59FF13B000C for ; Tue, 13 Jun 2006 09:41:37 -0400 (EDT) X-Virus-Scanned: at rudy.mif.pg.gda.pl Received: by rudy.mif.pg.gda.pl (plum, from userid 2732) id 39ED2233B7; Tue, 13 Jun 2006 15:40:54 +0200 (CEST) Date: Tue, 13 Jun 2006 15:40:53 +0200 (CEST) From: =?ISO-8859-2?Q?Tomasz_K=B3oczko?= To: gtk-devel-list@gnome.org Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1270146782-1150206053=:31655" X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.579 tagged_above=-999 required=2 tests=[AWL=0.022, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.579 X-Spam-Level: Subject: gtk+ 2.9.3 compilation fail X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2006 13:41:41 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1270146782-1150206053=:31655 Content-Type: TEXT/PLAIN; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 8BIT gcc -DG_DISABLE_DEPRECATED -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -o .libs/gtk-query-immodules-2.0 queryimmodules.o ./.libs/libgtk-x11-2.0.so -L/lib64 /home/users/prac/nd/kloczek/rpm/BUILD/gtk+-2.9.3/gdk/.libs/libgdk-x11-2.0.so -latk-1.0 ../gdk-pixbuf/.libs/libgdk_pixbuf-2.0.so ../gdk/.libs/libgdk-x11-2.0.so -lpangocairo-1.0 -lpango-1.0 -lcairo -lfontconfig -lXext -lXrender -lX11 -lXinerama -lXi -lXrandr -lXcursor -lXfixes /home/users/prac/nd/kloczek/rpm/BUILD/gtk+-2.9.3/gdk-pixbuf/.libs/libgdk_pixbuf-2.0.so -lgmodule-2.0 -ldl -lgobject-2.0 -lglib-2.0 -lm ./.libs/libgtk-x11-2.0.so: undefined reference to `cairo_surface_set_fallback_resolution' collect2: ld returned 1 exit status make[4]: *** [gtk-query-immodules-2.0] Error 1 make[4]: Leaving directory `/home/users/prac/nd/kloczek/rpm/BUILD/gtk+-2.9.3/gtk' $ rpm -q cairo cairo-1.1.6-6 kloczek -- ----------------------------------------------------------- *Ludzie nie maj problemw, tylko sobie sami je stwarzaj* ----------------------------------------------------------- Tomasz Koczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek@rudy.mif.pg.gda.pl* --0-1270146782-1150206053=:31655-- From federico@ximian.com Tue Jun 13 12:13:42 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 31B0B3B0071 for ; Tue, 13 Jun 2006 12:13:42 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29632-05 for ; Tue, 13 Jun 2006 12:13:41 -0400 (EDT) Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) by menubar.gnome.org (Postfix) with ESMTP id 9C36B3B000A for ; Tue, 13 Jun 2006 12:13:40 -0400 (EDT) Received: (qmail 22968 invoked from network); 13 Jun 2006 16:11:48 -0000 Received: from localhost (HELO 164-99-120-90.boston.ximian.com) (127.0.0.1) by localhost with SMTP; 13 Jun 2006 16:11:48 -0000 From: Federico Mena Quintero To: Michael Natterer In-Reply-To: <1149849193.3010.23.camel@localhost> References: <1149608483.14088.54.camel@cacharro.xalalinux.org> <1149849193.3010.23.camel@localhost> Content-Type: text/plain Date: Tue, 13 Jun 2006 11:07:30 -0500 Message-Id: <1150214850.17566.118.camel@cacharro.xalalinux.org> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.574 tagged_above=-999 required=2 tests=[AWL=0.025, BAYES_00=-2.599] X-Spam-Score: -2.574 X-Spam-Level: Cc: GTK+ development mailing list , Michael.meeks@novell.com Subject: Re: Default timeouts X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2006 16:13:42 -0000 On Fri, 2006-06-09 at 12:33 +0200, Michael Natterer wrote: > However in some places I introduced a factor of 5 so all existing > timeouts could be done with the two values from GtkSettings. > > See comment #10 of http://bugzilla.gnome.org/show_bug.cgi?id=142582 > > Actually, it may make sense to simply use the user's configured > key repeat and delay for these two setting values. What do you > think? Yeah, it makes perfect sense to make it the same as the key repeat rate. You'll then get the same rate of change whether you use the mouse or the keyboard. Federico From stefan@space.twc.de Tue Jun 13 14:33:13 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id A37933B02D9 for ; Tue, 13 Jun 2006 14:33:13 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01854-06 for ; Tue, 13 Jun 2006 14:33:08 -0400 (EDT) Received: from space.twc.de (port-83-236-178-131.static.qsc.de [83.236.178.131]) by menubar.gnome.org (Postfix) with ESMTP id 1C3EE3B00C9 for ; Tue, 13 Jun 2006 14:33:07 -0400 (EDT) Received: from stefan by space.twc.de with local (Exim 4.50) id 1FqEOs-0007KV-NR; Tue, 13 Jun 2006 21:18:06 +0200 Date: Tue, 13 Jun 2006 21:18:06 +0200 To: Tim Janik Message-ID: <20060613191806.GA28032@space.twc.de> References: <20060609152646.GE20719@space.twc.de> <200606091630.k59GUaES013244@caipclassic.rutgers.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i From: Stefan Westerfeld X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.305 tagged_above=-999 required=2 tests=[AWL=0.159, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.305 X-Spam-Level: Cc: "Kaveh R. Ghazi" , Gtk+ Developers , gcc@gcc.gnu.org Subject: Re: Problem with type safety and the "sentinel" attribute X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2006 18:33:13 -0000 Hi! On Fri, Jun 09, 2006 at 07:30:25PM +0200, Tim Janik wrote: > On Fri, 9 Jun 2006, Kaveh R. Ghazi wrote: > >> void print_string_array (const char *array_name, > >> const char *string, ...) __attribute__ > >> ((__sentinel__)); > >> > >> print_string_array ("empty_array", NULL); /* gcc warns, but shouldn't > >*/ > >> > >> The only way out for keeping the sentinel attribute and avoiding the > >> warning is using > >> > >> static void print_string_array (const char *array_name, ...) > >> __attribute__ ((__sentinel__)); > > > >I think you could maintain typesafety and silence the warning by > >keeping the more specific prototype and adding an extra NULL, e.g.: > > > >print_string_array ("empty_array", NULL, NULL); > > > >Doesn't seem elegant, but it does the job. > > this is an option for a limited set of callers, yes. For the statistics, by adding the __sentinel__ attribute to the beast codebase, I have about 50 of those sentinel warnings that I don't need. So the double NULL termination would make quite some code more messy than it should be. > >> By the way, there is already an existing gcc bug, which is about the > >> same thing (NULL passed within named args), but wants to have it the > >> way it works now: > >> > >> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21911 > > > >Correct, the feature as I envisioned it expected the sentinel to > >appear in the variable arguments only. This PR reflects when I found > >out it didn't do that and got around to fixing it. Note the "buggy" > >behavior wasn't exactly what you wanted either because GCC got fooled > >by a sentinel in *any* of the named arguments, not just the last one. Ah, I see. > >> so if it gets changed, then gcc might need to support both > >> - NULL termination within the last named parameter allowed > >> - NULL termination only allowed within varargs parameters (like it is > >> now) > > > >I'm not against this enhancement, but you need to specify a syntax > >that allows the old behavior but also allows doing it your way. > > > >Hmm, perhaps we could check for attribute "nonnull" on the last named > >argument, if it exists then that can't be the sentinel, if it's not > >there then it does what you want. This is not completely backwards > >compatible because anyone wanting the existing behavior has to add the > >attribute nonnull. But there's precedent for this when attribute > >printf split out whether the format specifier could be null... > > > >We could also create a new attribute name for the new behavior. This > >would preserve backwards compatibility. I like this idea better. > > i agree here. as far as the majority of the GLib and Gtk+ APIs are > concerned, > we don't really need the flexibility of the sentinel attribute but rather > a compiler check on whether the last argument used in a function call > is NULL or 0 (regardless of whether it's the last named arg or already part > of the varargs list). > that's also why the actual sentinel wrapper in GLib looks like this: > > #define G_GNUC_NULL_TERMINATED __attribute__((__sentinel__)) > > so, if i was to make a call on this issue, i'd either introduce > __attribute__((__null_terminated__)) with the described semantics, > or have __attribute__((__sentinel__(-1))) work essentially like > __attribute__((__sentinel__(0))) while also accepting 0 in the position > of the last named argument. I also like the backwards compatible way better than trying to somehow modifying the attribute; it may break something now, or - which would also be bad - it may make something that somebody will want to check with the sentinel attribute in some future program impossible. The only case that I ever needed was NULL termination, so I think implementing one of the two proposals Tim made would be sufficient. Personally I like __attribute__((__null_terminated__)) better, because a -1 sentinel may be less intuitive to read in the source code. So this would be my suggestion for a "syntax specification". > >Next you need to recruit someone to implement this enhancement, or > >submit a patch. :-) Although given that you can silence the warning by > >adding an extra NULL at the call site, I'm not sure it's worth it. > > i would say this is definitely worth it, because the issue also shows up in > other code that is widely used: > gpointer g_object_new (GType object_type, > const gchar *first_property_name, > ...); > that's for instance a function which is called in many projects. > putting the burden on the caller is clearly the wrong trade off here. > > so please take this as a vote for the worthiness of a fix ;) Good. Of course I would be happy if somebody with knowledge of the compiler source could implement it. I never hacked gcc code before. But since you suggested sending a patch, I'll at least try to implement a new __null_terminated__ attribute, and ask for help if I can't figure out what to do. Cu... Stefan -- Stefan Westerfeld, Hamburg/Germany, http://space.twc.de/~stefan From easy-b@freesurf.ch Tue Jun 13 16:37:46 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 1FEC53B03CF for ; Tue, 13 Jun 2006 16:37:46 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05861-06 for ; Tue, 13 Jun 2006 16:37:45 -0400 (EDT) Received: from mail-fs.sunrise.ch (mta-fs-be-01.sunrise.ch [194.158.229.16]) by menubar.gnome.org (Postfix) with ESMTP id B948D3B00C8 for ; Tue, 13 Jun 2006 16:37:44 -0400 (EDT) Received: from [10.0.1.2] (84.226.131.17) by mail-fs.sunrise.ch (7.2.073) id 44795C850064786C; Tue, 13 Jun 2006 22:36:45 +0200 In-Reply-To: <89C1D6F0-EDC8-495C-B76B-9909E6388E62@freesurf.ch> References: <20060522160033.F1A8E3B1CE4@menubar.gnome.org> <772588ED-500A-4A11-8829-DA80B9A35D1F@freesurf.ch> <44720B8C.3080903@imendio.com> <0A34FCC9-6650-4737-B86D-1B503D8A9072@freesurf.ch> <7D6367DC-8689-453B-8FD7-217632BC1DAE@freesurf.ch> <89C1D6F0-EDC8-495C-B76B-9909E6388E62@freesurf.ch> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2B5653F8-341D-440C-9D5C-F166B296F94E@freesurf.ch> Content-Transfer-Encoding: 7bit From: Easy B Date: Tue, 13 Jun 2006 22:36:44 +0200 To: Gregor Riepl X-Mailer: Apple Mail (2.749.3) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-0.997 tagged_above=-999 required=2 tests=[AWL=-0.549, BAYES_00=-2.599, DNS_FROM_RFC_POST=1.708, FORGED_RCVD_HELO=0.135, TW_BG=0.077, TW_GD=0.077, TW_GT=0.077, TW_PK=0.077] X-Spam-Score: -0.997 X-Spam-Level: Cc: gtk-devel-list@gnome.org Subject: Re: Mac OS X Framework X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2006 20:37:46 -0000 Hi So i understand that we only need to link against one library that is linked to all the other ones, right? If I look at libgtk-quartz-2.0.dylib I see following: libgtk-quartz-2.0.dylib: /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libgtk-quartz-2.0.0.dylib (compatibility version 902.0.0, current version 902.0.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libgdk_pixbuf-2.0.0.dylib (compatibility version 902.0.0, current version 902.0.0) /usr/lib/libiconv.2.dylib (compatibility version 5.0.0, current version 5.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.1.5) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libgdk-quartz-2.0.0.dylib (compatibility version 902.0.0, current version 902.0.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libpangoft2-1.0.0.dylib (compatibility version 1301.0.0, current version 1301.1.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libpng12.0.dylib (compatibility version 11.0.0, current version 11.0.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libfontconfig.1.dylib (compatibility version 2.0.0, current version 2.4.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libfreetype.6.dylib (compatibility version 10.0.0, current version 10.8.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libxml2.2.dylib (compatibility version 9.0.0, current version 9.24.0) /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.3) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libpangocairo-1.0.0.dylib (compatibility version 1301.0.0, current version 1301.1.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libpango-1.0.0.dylib (compatibility version 1301.0.0, current version 1301.1.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libatk-1.0.0.dylib (compatibility version 1115.0.0, current version 1115.0.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libgobject-2.0.0.dylib (compatibility version 1102.0.0, current version 1102.0.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libgmodule-2.0.0.dylib (compatibility version 1102.0.0, current version 1102.0.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libglib-2.0.0.dylib (compatibility version 1102.0.0, current version 1102.0.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libcairo.2.dylib (compatibility version 9.0.0, current version 9.0.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libintl.3.dylib (compatibility version 8.0.0, current version 8.3.0) So I guess everything what we need is there. But I don't really get how to satisfy configure of a gtk app so that it only uses "- framework Gtk+". Sorry for my ignorance I'm pretty much a newbe on these things. Cheers, Ezra. On 12.06.2006, at 08:47, Gregor Riepl wrote: >> Thanx for the Tips. This would make the Framework more like one. >> The ability to include it into the application bundle would be >> very handy. >> >> If I look at other Frameworks I always find a single library in >> the top directory, for example: >> >> /System/Library/Frameworks/ApplicationServices.framework/Versions/ >> A/Frameworks/ImageIO.framework/ImageIO > that's right, this is the dynamic library itself. it doesn't have > the dylib suffix, but you may specify one if you like. > executables need to be linked against that, then, just -framework X > doesn't work. on the other hand, it's a good idea to either make > the "main" library (like libgtk-2.0.0.dylib) the framework (and > include all dependent libraries as either frameworks on their own > or dylibs) or just create an empty stub library that links against > those libraries or frameworks. to do that, make an empty .c source, > compile and link it against all the dylibs/frameworks you need. but > i can't tell if that's a good idea. > >> If I do "otool -L /System/Library/Frameworks/ >> ApplicationServices.framework/Versions/A/Frameworks/ >> ImageIO.framework/ImageIO", I get references to many other >> libraries that are located inside the framework bundle: > i guess that would be such a stub library, but maybe there's other > functionality contained? > otool can help you getting the symbols from mach-o binaries, much > like objdump. > >> In my Gtk+.framework I have tons of libraries. Would it be >> possible to create something like the above for gtk? Would it make >> sense? Right now I just use pkg-config to find the libraries and >> the result looks like this: >> >> /Applications/Shity Apps/Gtk-Demo.app/Contents/MacOS/gtk-demo: >> /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ >> libgdk_pixbuf-2.0.0.dylib (compatibility version 902.0.0, current >> version 902.0.0) >> ....... >> /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ >> libintl.3.dylib (compatibility version 8.0.0, current version 8.3.0) >> >> What do you think? > you should use /Library/Frameworks/Gtk+.framework/Versions/2.9.1/Gtk > + as the main library. it doesn't matter if that's just a stub or > the last library in the build chain (yes, i don't see > libgtk-2.0.0.dylib anywhere?). binaries then wouldn't require to be > linked against all those libs mentioned above. > this way you can also link gtk software with -framework Gtk+ and > nothing else, which you could even move into the pkconfig file and > thus facilitate porting. > i did something similar with the readily-available SDL framework > fpr mac os x, but it doesn't work very well because of the missing > startup code. with gtk it's easier i guess. > > have a nice day > gregor > > p.s.: on second thought, there could be a problem. afaik if a > binary loads a dylib, only that dylib's symbols become available > for it. the dependent symbols from libs that dylib's linked against > stay local for that dylib... maybe there's a workaround for this or > you come up with a better idea? From ntd@users.sourceforge.net Thu Jun 15 04:25:32 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 382C53B0324 for ; Thu, 15 Jun 2006 04:25:32 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22415-07 for ; Thu, 15 Jun 2006 04:25:29 -0400 (EDT) Received: from mailout01.albacom.net (mailout01.albacom.net [217.220.34.13]) by menubar.gnome.org (Postfix) with SMTP id 0694D3B0311 for ; Thu, 15 Jun 2006 04:25:28 -0400 (EDT) Received: (qmail 13668 invoked by uid 508); 15 Jun 2006 08:25:00 -0000 Received: from ntd@users.sourceforge.net by mailout01.albacom.net with qmail-scanner (spamassassin: ???. Clear:RC:1(217.221.76.9):SA:0(0.0/15.0):. Processed in 0.697195 secs); 15 Jun 2006 08:25:00 -0000 Received: from unknown (HELO sviluppo.internet.local) (postmaster@effe-gi.it@217.221.76.9) by mailout01.albacom.net with SMTP; 15 Jun 2006 08:24:59 -0000 Content-Disposition: inline From: Fontana Nicola Organization: Elettronica EFFE-GI s.n.c. To: gtk-devel-list@gnome.org Subject: GObject extension propose (GContainer) Date: Thu, 15 Jun 2006 11:01:12 +0000 User-Agent: KMail/1.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200606151101.12868.ntd@users.sourceforge.net> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.599 tagged_above=-999 required=2 tests=[BAYES_00=-2.599] X-Spam-Score: -2.599 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 08:25:32 -0000 Hi all, I'm a GObject based libraries (for UI purpose and not) user and I often need a generic container to derive my own types. In my opinion, I think this generic container must be included inside the GObject library ... it could be used by a lot of derived libraries providing a common approach. I published my solution - that is, what I am currently using - on sourceforge. http://sourceforge.net/projects/gcontainer/ Is it a good idea? Is something planned in this direction? Am I totally wrong? I need feedbacks ... Nicola From mclasen@redhat.com Thu Jun 15 09:54:37 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 88F2B3B00F3 for ; Thu, 15 Jun 2006 09:54:37 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14500-10 for ; Thu, 15 Jun 2006 09:54:36 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id 12BF23B0261 for ; Thu, 15 Jun 2006 09:54:36 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5FDsZ1W022208 for ; Thu, 15 Jun 2006 09:54:35 -0400 Received: from lacrosse.corp.redhat.com (lacrosse.corp.redhat.com [172.16.52.154]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5FDsZa4019641 for ; Thu, 15 Jun 2006 09:54:35 -0400 Received: from [172.16.83.98] (dhcp83-98.boston.redhat.com [172.16.83.98]) by lacrosse.corp.redhat.com (8.12.11.20060308/8.11.6) with ESMTP id k5FDsZL7008811 for ; Thu, 15 Jun 2006 09:54:35 -0400 Subject: GTK+ 2.10, the endgame From: Matthias Clasen To: gtk-devel-list@gnome.org Content-Type: text/plain Organization: Red Hat Date: Thu, 15 Jun 2006 09:56:26 -0400 Message-Id: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> Mime-Version: 1.0 X-Mailer: Evolution 2.7.3 (2.7.3-2) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.542 tagged_above=-999 required=2 tests=[AWL=0.059, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.542 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 13:54:37 -0000 I want to have GTK+ 2.10 ready at or immediately after GUADEC. I did not declare 2.9.3 api frozen in the release announcement, because we were still holding the door open for Kris' work on the new tooltips api. But he has run into some difficulties with the implementation which will take some time to overcome, so we have decided to punt this feature and try to get it into 2.12 early. Therefore, I want to consider 2.9.3 api frozen, and take a look at what still needs to happen before 2.10. Here are some things I personally would like get worked on (not sure how much time I can free to look into these myself): - I think the async filechooser conversion has caused some regressions, I noticed that .hidden support seems broken and autocompletion also behaved badly for me recently. - There is a number of FIXMEs and unimplemented bits in the print code. - The print backends need a careful look wrt to memory leaks and error reporting. Are there other important bugs or regressions that need attention before 2.10 ? Another thing I have slacked off about is organizing a GTK+ team meeting at GUADEC. So, who of the GTK+ team is there and at what times ? Should we try to find a free hour during the core days, or does everybody stay for the after hours ? If so, it may be easier to do a team meeting on Thursday... Matthias From timj@gtk.org Thu Jun 15 10:53:17 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id BBF963B04EA for ; Thu, 15 Jun 2006 10:53:17 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17592-10 for ; Thu, 15 Jun 2006 10:53:16 -0400 (EDT) Received: from holken.mikan.net (holken.mikan.net [83.145.56.183]) by menubar.gnome.org (Postfix) with ESMTP id 035EF3B04E7 for ; Thu, 15 Jun 2006 10:53:15 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by holken.mikan.net (Postfix) with ESMTP id C0DB83352B4; Thu, 15 Jun 2006 16:52:21 +0200 (CEST) Received: from holken.mikan.net ([127.0.0.1]) by localhost (holken.mikan.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16765-03; Thu, 15 Jun 2006 16:52:18 +0200 (CEST) Received: from birnet.org (c152167.adsl.hansenet.de [213.39.152.167]) by holken.mikan.net (Postfix) with ESMTP id E3B0433529D; Thu, 15 Jun 2006 16:52:17 +0200 (CEST) Received: from master.birnet.private (localhost.localdomain [127.0.0.1]) by birnet.org (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k5FEqH2d008152 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 15 Jun 2006 16:52:18 +0200 Received: (from timj@localhost) by master.birnet.private (8.13.4/8.13.4/Submit) id k5FEqHpN008151; Thu, 15 Jun 2006 16:52:17 +0200 Date: Thu, 15 Jun 2006 16:52:17 +0200 (CEST) From: Tim Janik X-X-Sender: timj@master.birnet.private To: Fontana Nicola Subject: Re: GObject extension propose (GContainer) In-Reply-To: <200606151101.12868.ntd@users.sourceforge.net> Message-ID: References: <200606151101.12868.ntd@users.sourceforge.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at holken.mikan.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.38 tagged_above=-999 required=2 tests=[AWL=0.084, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.38 X-Spam-Level: Cc: Gtk+ Developers X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 14:53:17 -0000 On Thu, 15 Jun 2006, Fontana Nicola wrote: > Hi all, > > I'm a GObject based libraries (for UI purpose and not) user and I often need > a generic container to derive my own types. In my opinion, I think this > generic container must be included inside the GObject library ... it could > be used by a lot of derived libraries providing a common approach. > > I published my solution - that is, what I am currently using - on > sourceforge. > > http://sourceforge.net/projects/gcontainer/ > > Is it a good idea? Is something planned in this direction? Am I totally > wrong? > > I need feedbacks ... hi. your gcontainer-1.0.0 looks like an interesting approach to me, but i'm not sure it's generally good to put that into stock libgobject. the main reason is that container needs are probably pretty variable out there (i've come across at least 4 different gobject container implementations in free software projects i'm woorking on) and that both, making too little assumptions in the child/container interface isn't going to be very helpful, albeit making too many has the same problem. i guess we could add a link to your project from the libgobject docs (it should probably have a Contrib section), for people possibly looking for a GObject container implementation. that way, gcontainer-1.0.0 gets a chance of being reused and maybe extended to something generally usefull for GObject applications out there. > Nicola --- ciaoTJ From timj@gtk.org Thu Jun 15 11:31:19 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 642E33B02ED for ; Thu, 15 Jun 2006 11:31:19 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19431-03 for ; Thu, 15 Jun 2006 11:31:18 -0400 (EDT) Received: from holken.mikan.net (holken.mikan.net [83.145.56.183]) by menubar.gnome.org (Postfix) with ESMTP id 2E9543B0155 for ; Thu, 15 Jun 2006 11:31:18 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by holken.mikan.net (Postfix) with ESMTP id B5DB533524B; Thu, 15 Jun 2006 16:32:01 +0200 (CEST) Received: from holken.mikan.net ([127.0.0.1]) by localhost (holken.mikan.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16412-10; Thu, 15 Jun 2006 16:31:58 +0200 (CEST) Received: from birnet.org (c152167.adsl.hansenet.de [213.39.152.167]) by holken.mikan.net (Postfix) with ESMTP id D5D7E335256; Thu, 15 Jun 2006 16:31:57 +0200 (CEST) Received: from master.birnet.private (localhost.localdomain [127.0.0.1]) by birnet.org (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k5FEVrL1007682 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 15 Jun 2006 16:31:53 +0200 Received: (from timj@localhost) by master.birnet.private (8.13.4/8.13.4/Submit) id k5FEVis7007681; Thu, 15 Jun 2006 16:31:45 +0200 Date: Thu, 15 Jun 2006 16:31:44 +0200 (CEST) From: Tim Janik X-X-Sender: timj@master.birnet.private To: Matthias Clasen Subject: GTK+ meeting at GUADEC (Re: GTK+ 2.10, the endgame) In-Reply-To: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> Message-ID: References: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at holken.mikan.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.381 tagged_above=-999 required=2 tests=[AWL=0.083, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.381 X-Spam-Level: Cc: Gtk+ Developers X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 15:31:19 -0000 On Thu, 15 Jun 2006, Matthias Clasen wrote: > I want to have GTK+ 2.10 ready at or immediately after GUADEC. > Another thing I have slacked off about is organizing a GTK+ > team meeting at GUADEC. So, who of the GTK+ team is there > and at what times ? Should we try to find a free hour during > the core days, or does everybody stay for the after hours ? > If so, it may be easier to do a team meeting on Thursday... i think i volounteered to take on arrangement of that to some extend. at least, we intended to have a meeting on GTK+ linking issues, and could probably merge that with the GTK+ team meeting during guadec. the plan for that was to send out en email next friday/saturday (i.e right at the guadec start) to figure/suggest dates suitable for everyone to attend. > Matthias --- ciaoTJ From hfiguiere@teaser.fr Thu Jun 15 11:52:14 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C00CA3B0261 for ; Thu, 15 Jun 2006 11:52:14 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20706-05 for ; Thu, 15 Jun 2006 11:52:13 -0400 (EDT) Received: from xandros.com (smtp1.xandros.com [209.87.238.70]) by menubar.gnome.org (Postfix) with ESMTP id 6D7663B053A for ; Thu, 15 Jun 2006 11:52:13 -0400 (EDT) Received: from [172.16.1.95] (unknown [209.87.238.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by xandros.com (Postfix) with ESMTP id 4B02239025; Thu, 15 Jun 2006 11:51:30 -0400 (EDT) Message-ID: <44918201.6010605@teaser.fr> Date: Thu, 15 Jun 2006 11:51:29 -0400 From: Hubert Figuiere User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: Matthias Clasen Subject: Re: GTK+ 2.10, the endgame References: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> In-Reply-To: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.54 tagged_above=-999 required=2 tests=[AWL=0.059, BAYES_00=-2.599] X-Spam-Score: -2.54 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 15:52:14 -0000 Matthias Clasen wrote: > I want to have GTK+ 2.10 ready at or immediately after GUADEC. Can somebody summarize the Mac port status? Hub From tristan.van.berkom@gmail.com Thu Jun 15 12:44:57 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 0A0273B05DC for ; Thu, 15 Jun 2006 12:44:57 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23203-02 for ; Thu, 15 Jun 2006 12:44:56 -0400 (EDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.200]) by menubar.gnome.org (Postfix) with ESMTP id 0AD9C3B007F for ; Thu, 15 Jun 2006 12:44:55 -0400 (EDT) Received: by wx-out-0102.google.com with SMTP id i30so312681wxd for ; Thu, 15 Jun 2006 09:44:14 -0700 (PDT) Received: by 10.70.100.8 with SMTP id x8mr2494520wxb; Thu, 15 Jun 2006 09:44:14 -0700 (PDT) Received: from ?66.48.170.37? ( [66.48.170.37]) by mx.gmail.com with ESMTP id i39sm1649326wxd.2006.06.15.09.44.12; Thu, 15 Jun 2006 09:44:14 -0700 (PDT) Message-ID: <44919246.8060301@gnome.org> Date: Thu, 15 Jun 2006 13:00:54 -0400 User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Janik Subject: Re: GObject extension propose (GContainer) References: <200606151101.12868.ntd@users.sourceforge.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit From: Tristan Van Berkom X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.481 tagged_above=-999 required=2 tests=[AWL=-0.414, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=1.456, SPF_PASS=-0.001, TW_GT=0.077] X-Spam-Score: -1.481 X-Spam-Level: Cc: Gtk+ Developers X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 16:44:57 -0000 Tim Janik wrote: >On Thu, 15 Jun 2006, Fontana Nicola wrote: > > > >>Hi all, >> >>I'm a GObject based libraries (for UI purpose and not) user and I often need >>a generic container to derive my own types. In my opinion, I think this >>generic container must be included inside the GObject library ... it could >>be used by a lot of derived libraries providing a common approach. >> >>I published my solution - that is, what I am currently using - on >>sourceforge. >> >>http://sourceforge.net/projects/gcontainer/ >> >>Is it a good idea? Is something planned in this direction? Am I totally >>wrong? >> >>I need feedbacks ... >> >> As a side note... I've been working on container --> child relationships and honing them down inside the glade builder... objects may for example have object delagates that are "owned" and in turn may "own" other delagates... this is all functional with libglade facilities and the future gtk builder also (from the design as of yet...)... this concept of "types of container relationships" is also usefull for GtkMenuShell --> GtkMenu for example (not just any GtkWidget can be added to a menushell). All of that just to say... I cannot count the times I've thought to myself that GtkContainer should really just be GContainerIface, and implemented by whatever interested objects that want to parent other objects... I think that what we need is not really "yet another container api", but a container api that is a unified front for generic handling of the GTK object hierarchy at runtime. Cheers, -Tristan From federico@ximian.com Thu Jun 15 12:56:13 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 0DAD63B03FF for ; Thu, 15 Jun 2006 12:56:13 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23665-06 for ; Thu, 15 Jun 2006 12:56:06 -0400 (EDT) Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) by menubar.gnome.org (Postfix) with ESMTP id 688823B0613 for ; Thu, 15 Jun 2006 12:56:05 -0400 (EDT) Received: (qmail 25104 invoked from network); 15 Jun 2006 16:54:53 -0000 Received: from localhost (HELO 164-99-120-38.boston.ximian.com) (127.0.0.1) by localhost with SMTP; 15 Jun 2006 16:54:53 -0000 Subject: Re: GTK+ 2.10, the endgame From: Federico Mena Quintero To: Matthias Clasen In-Reply-To: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> References: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> Content-Type: text/plain Date: Thu, 15 Jun 2006 11:50:29 -0500 Message-Id: <1150390229.17566.191.camel@cacharro.xalalinux.org> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.575 tagged_above=-999 required=2 tests=[AWL=0.024, BAYES_00=-2.599] X-Spam-Score: -2.575 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 16:56:13 -0000 On Thu, 2006-06-15 at 09:56 -0400, Matthias Clasen wrote: > Therefore, I want to consider 2.9.3 api frozen, and take a > look at what still needs to happen before 2.10. Here are some > things I personally would like get worked on (not sure > how much time I can free to look into these myself): > > - I think the async filechooser conversion has caused some > regressions, I noticed that .hidden support seems broken > and autocompletion also behaved badly for me recently. Yes, it's quite broken at the moment. I don't think we can do any more productive debugging (fixing something breaks something else) until we have a good set of automated tests for the basic behaviors. > - There is a number of FIXMEs and unimplemented bits in > the print code. > > - The print backends need a careful look wrt to memory leaks > and error reporting. I'm rather worried of declaring the printing API as stable and just unleashing it to the world. Is any software *really* using it? Does it contemplate things like - sites with thousands of printers - sites which want to lock-down certain printers - color management for apps that need it > Another thing I have slacked off about is organizing a GTK+ > team meeting at GUADEC. So, who of the GTK+ team is there > and at what times ? Should we try to find a free hour during > the core days, or does everybody stay for the after hours ? > If so, it may be easier to do a team meeting on Thursday... I'll be there since Sunday morning. Thursday is the Advisory Board meeting, so I'm afraid I won't have that day free for the GTK+ meeeting. Federico From mclasen@redhat.com Thu Jun 15 13:15:33 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id BC2163B0187 for ; Thu, 15 Jun 2006 13:15:33 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24531-03 for ; Thu, 15 Jun 2006 13:15:29 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id DCC933B0227 for ; Thu, 15 Jun 2006 13:15:28 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5FHDjVa014384; Thu, 15 Jun 2006 13:13:45 -0400 Received: from lacrosse.corp.redhat.com (lacrosse.corp.redhat.com [172.16.52.154]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5FHDjmo017834; Thu, 15 Jun 2006 13:13:45 -0400 Received: from [172.16.83.98] (dhcp83-98.boston.redhat.com [172.16.83.98]) by lacrosse.corp.redhat.com (8.12.11.20060308/8.11.6) with ESMTP id k5FHDjGC025752; Thu, 15 Jun 2006 13:13:45 -0400 Subject: Re: GTK+ 2.10, the endgame From: Matthias Clasen To: Federico Mena Quintero In-Reply-To: <1150390229.17566.191.camel@cacharro.xalalinux.org> References: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> <1150390229.17566.191.camel@cacharro.xalalinux.org> Content-Type: text/plain Organization: Red Hat Date: Thu, 15 Jun 2006 13:15:37 -0400 Message-Id: <1150391737.3187.33.camel@dhcp83-98.boston.redhat.com> Mime-Version: 1.0 X-Mailer: Evolution 2.7.3 (2.7.3-2) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.542 tagged_above=-999 required=2 tests=[AWL=0.059, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.542 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 17:15:33 -0000 On Thu, 2006-06-15 at 11:50 -0500, Federico Mena Quintero wrote: > On Thu, 2006-06-15 at 09:56 -0400, Matthias Clasen wrote: > > > Therefore, I want to consider 2.9.3 api frozen, and take a > > look at what still needs to happen before 2.10. Here are some > > things I personally would like get worked on (not sure > > how much time I can free to look into these myself): > > > > - I think the async filechooser conversion has caused some > > regressions, I noticed that .hidden support seems broken > > and autocompletion also behaved badly for me recently. > > Yes, it's quite broken at the moment. I don't think we can do any more > productive debugging (fixing something breaks something else) until we > have a good set of automated tests for the basic behaviors. Quite unfortunate. We spent too much time working on finetuning the filechooser behaviour to leave it broken now... > > - There is a number of FIXMEs and unimplemented bits in > > the print code. > > > > - The print backends need a careful look wrt to memory leaks > > and error reporting. > > I'm rather worried of declaring the printing API as stable and just > unleashing it to the world. Is any software *really* using it? Does it > contemplate things like Typical chicken and egg problem that won't be solved by keeping it unreleased for another year. There is no way to get any software _really_ using it without releasing it first. We got quite a bit of feedback from people looking at porting real apps to it (e.g gedit, OOo and epiphany), so it is not as if we release it straight from the whiteboard. > - sites with thousands of printers > > - sites which want to lock-down certain printers > > - color management for apps that need it No doubt that we may have to add new api in 2.12 to accomodate things like this, but all of these are special cases. From muntyan@tamu.edu Thu Jun 15 15:05:44 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 9364F3B0605 for ; Thu, 15 Jun 2006 15:05:44 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28754-04 for ; Thu, 15 Jun 2006 15:05:41 -0400 (EDT) Received: from smtp103.vzn.mail.mud.yahoo.com (smtp103.vzn.mail.mud.yahoo.com [68.142.203.47]) by menubar.gnome.org (Postfix) with SMTP id 568873B05C3 for ; Thu, 15 Jun 2006 15:05:40 -0400 (EDT) Received: (qmail 34334 invoked from network); 15 Jun 2006 19:05:00 -0000 Received: from unknown (HELO ?192.168.3.9?) (muntyan@verizon.net@71.113.224.59 with plain) by smtp103.vzn.mail.mud.yahoo.com with SMTP; 15 Jun 2006 19:04:59 -0000 Message-ID: <4491AF5A.2050702@tamu.edu> Date: Thu, 15 Jun 2006 14:04:58 -0500 From: Yevgen Muntyan User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20060216 Debian/1.7.12-1.1ubuntu2 X-Accept-Language: en MIME-Version: 1.0 To: GTK Devel List Subject: Printing and blocking ui Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.552 tagged_above=-999 required=2 tests=[AWL=0.047, BAYES_00=-2.599] X-Spam-Score: -2.552 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 19:05:44 -0000 Hi there, I print a text document from GtkTextView here. There is a problem with pagination: pagination is potentially slow, so some sort of progress dialog should be shown during it. From the other hand, the text buffer must not be modified during pagination. How to solve it? Should I show my own modal dialog and make sure user doesn't modify the buffer, or GtkPrintOperation can take care of it? Actually, it would be good to ensure printing blocks the text widget too, since in this case it wouldn't be necessary to calculate and store all the pango layouts in begin-print. Maybe just show a modal dialog between begin-print and end-print. Thanks, Yevgen From richard@imendio.com Thu Jun 15 15:08:15 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C90B13B02BF for ; Thu, 15 Jun 2006 15:08:15 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28754-07 for ; Thu, 15 Jun 2006 15:08:14 -0400 (EDT) Received: from holken.mikan.net (holken.mikan.net [83.145.56.183]) by menubar.gnome.org (Postfix) with ESMTP id 47EFB3B018C for ; Thu, 15 Jun 2006 15:08:14 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by holken.mikan.net (Postfix) with ESMTP id 418C111EB4; Thu, 15 Jun 2006 21:07:02 +0200 (CEST) Received: from holken.mikan.net ([127.0.0.1]) by localhost (holken.mikan.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04160-07; Thu, 15 Jun 2006 21:06:58 +0200 (CEST) Received: from [192.168.100.5] (c83-248-134-21.bredband.comhem.se [83.248.134.21]) by holken.mikan.net (Postfix) with ESMTP id E679E1459D; Thu, 15 Jun 2006 21:06:57 +0200 (CEST) Message-ID: <4491AFD0.5000408@imendio.com> Date: Thu, 15 Jun 2006 21:06:56 +0200 From: Richard Hult Organization: Imendio AB User-Agent: Thunderbird 1.5.0.4 (Macintosh/20060530) MIME-Version: 1.0 To: Hubert Figuiere Subject: Re: GTK+ 2.10, the endgame References: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> <44918201.6010605@teaser.fr> In-Reply-To: <44918201.6010605@teaser.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at holken.mikan.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.543 tagged_above=-999 required=2 tests=[AWL=0.056, BAYES_00=-2.599] X-Spam-Score: -2.543 X-Spam-Level: Cc: gtk-devel-list@gnome.org, Matthias Clasen X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 19:08:16 -0000 Hubert Figuiere skrev: > Matthias Clasen wrote: >> I want to have GTK+ 2.10 ready at or immediately after GUADEC. > > Can somebody summarize the Mac port status? The basic functionality is implemented and what's next in the pipeline is bug fixing, and after that looking into tighter integration with the platform in various areas. /Richard From muntyan@tamu.edu Thu Jun 15 15:12:58 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 9FC7E3B063D for ; Thu, 15 Jun 2006 15:12:58 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29079-06 for ; Thu, 15 Jun 2006 15:12:57 -0400 (EDT) Received: from smtp101.vzn.mail.mud.yahoo.com (smtp101.vzn.mail.mud.yahoo.com [68.142.203.45]) by menubar.gnome.org (Postfix) with SMTP id E72693B0613 for ; Thu, 15 Jun 2006 15:12:56 -0400 (EDT) Received: (qmail 97288 invoked from network); 15 Jun 2006 19:11:44 -0000 Received: from unknown (HELO ?192.168.3.9?) (muntyan@verizon.net@71.113.224.59 with plain) by smtp101.vzn.mail.mud.yahoo.com with SMTP; 15 Jun 2006 19:11:43 -0000 Message-ID: <4491B0EE.3040900@tamu.edu> Date: Thu, 15 Jun 2006 14:11:42 -0500 From: Yevgen Muntyan User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20060216 Debian/1.7.12-1.1ubuntu2 X-Accept-Language: en MIME-Version: 1.0 To: gtk-devel-list@gnome.org Subject: Re: GTK+ 2.10, the endgame References: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> <1150390229.17566.191.camel@cacharro.xalalinux.org> In-Reply-To: <1150390229.17566.191.camel@cacharro.xalalinux.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.514 tagged_above=-999 required=2 tests=[AWL=0.008, BAYES_00=-2.599, TW_GT=0.077] X-Spam-Score: -2.514 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 19:12:58 -0000 Federico Mena Quintero wrote: >On Thu, 2006-06-15 at 09:56 -0400, Matthias Clasen wrote: > > >>- The print backends need a careful look wrt to memory leaks >> and error reporting. >> >> > >I'm rather worried of declaring the printing API as stable and just >unleashing it to the world. Is any software *really* using it? > > Yes, there is software which is going to use gtk printing as soon as gtk-2.10 is released. And there will be much more when gtk has printing. Just think for a moment about gtk-but-not-gnome applications (win32 comes to mind too). > - sites with thousands of printers > > - sites which want to lock-down certain printers > > - color management for apps that need it > > If gtk can print to a single user's printer, it's already worth releasing. Again, there are applications which do not have printing, because they can't use gnomeprint, and developers don't feel like implement their own printing while gtk is going to get it. IMHO, etc., you know. Best regards, Yevgen From gnome-gtk-devel-list@m.gmane.org Thu Jun 15 16:40:15 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 2360D3B00D0 for ; Thu, 15 Jun 2006 16:40:15 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32360-05 for ; Thu, 15 Jun 2006 16:40:13 -0400 (EDT) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by menubar.gnome.org (Postfix) with ESMTP id 3B9113B0237 for ; Thu, 15 Jun 2006 16:40:13 -0400 (EDT) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1FqydG-0004Vk-6i for gtk-devel-list@gnome.org; Thu, 15 Jun 2006 22:40:02 +0200 Received: from cpe0004e2d9f884-cm0013718690da.cpe.net.cable.rogers.com ([70.24.212.140]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 15 Jun 2006 22:40:02 +0200 Received: from jasonspiro4+news by cpe0004e2d9f884-cm0013718690da.cpe.net.cable.rogers.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 15 Jun 2006 22:40:02 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gtk-devel-list@gnome.org From: Jason Spiro Subject: Imagine: what if points in Bugzilla had a significant effect? Date: Thu, 15 Jun 2006 19:15:34 +0000 (UTC) Lines: 15 Message-ID: X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cpe0004e2d9f884-cm0013718690da.cpe.net.cable.rogers.com User-Agent: slrn/0.9.8.1pl1 (Debian) Sender: news X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.601 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.601 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 20:40:15 -0000 Imagine: what if points did something in Bugzilla, like, the more points you have, the more votes you get? I think this would encourage people to file more bug reports, both good bug reports and not-so-good ones. Would that be a net gain or a net loss for GTK+? Regards, Jason Spiro -- Jason Spiro: computer consulting with a smile. Specializing in Linux: Red Hat AS / ES, Debian, and others. Serving homes and companies globally via remote access tools. Fair rates. Just email jasonspiro4@gmail.com or call Skype ID jasonspiro. From murrayc@murrayc.com Fri Jun 16 04:53:13 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id D68413B0007 for ; Fri, 16 Jun 2006 04:53:12 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23115-03 for ; Fri, 16 Jun 2006 04:53:08 -0400 (EDT) Received: from swarthymail-a5.dreamhost.com (sd-green-bigip-176.dreamhost.com [208.97.132.176]) by menubar.gnome.org (Postfix) with ESMTP id 7FA303B006C for ; Fri, 16 Jun 2006 04:53:08 -0400 (EDT) Received: from noname (p5497E1BF.dip.t-dialin.net [84.151.225.191]) by swarthymail-a5.dreamhost.com (Postfix) with ESMTP id 69FE4109E8B; Fri, 16 Jun 2006 01:52:14 -0700 (PDT) Subject: Re: GTK+ 2.10, the endgame From: Murray Cumming To: Matthias Clasen In-Reply-To: <1150391737.3187.33.camel@dhcp83-98.boston.redhat.com> References: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> <1150390229.17566.191.camel@cacharro.xalalinux.org> <1150391737.3187.33.camel@dhcp83-98.boston.redhat.com> Content-Type: text/plain Date: Fri, 16 Jun 2006 10:52:10 +0200 Message-Id: <1150447930.5806.4.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.481 tagged_above=-999 required=2 tests=[AWL=0.118, BAYES_00=-2.599] X-Spam-Score: -2.481 X-Spam-Level: Cc: Federico Mena Quintero , gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2006 08:53:13 -0000 I'm also concerned about the recent files stuff. Do we now have UIManager integration of that? -- Murray Cumming murrayc@murrayc.com www.murrayc.com www.openismus.com From murrayc@murrayc.com Fri Jun 16 05:06:58 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id A76AC3B0076 for ; Fri, 16 Jun 2006 05:06:58 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23550-01 for ; Fri, 16 Jun 2006 05:06:57 -0400 (EDT) Received: from kungfu.dreamhost.com (kungfu.dreamhost.com [66.33.216.126]) by menubar.gnome.org (Postfix) with ESMTP id D099D3B006B for ; Fri, 16 Jun 2006 05:06:57 -0400 (EDT) Received: from swarthymail-a4.dreamhost.com (sd-green-bigip-62.dreamhost.com [208.97.132.62]) by kungfu.dreamhost.com (Postfix) with ESMTP id 708B51F0265 for ; Fri, 16 Jun 2006 01:28:47 -0700 (PDT) Received: from noname (p5497E1BF.dip.t-dialin.net [84.151.225.191]) by swarthymail-a4.dreamhost.com (Postfix) with ESMTP id 0D51A129A83; Fri, 16 Jun 2006 01:28:10 -0700 (PDT) Subject: Re: GTK+ 2.10, the endgame From: Murray Cumming To: Matthias Clasen In-Reply-To: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> References: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> Content-Type: text/plain Date: Thu, 15 Jun 2006 23:20:27 +0200 Message-Id: <1150406427.30234.1.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.068 tagged_above=-999 required=2 tests=[AWL=-0.296, BAYES_00=-2.599, DATE_IN_PAST_06_12=0.827] X-Spam-Score: -2.068 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2006 09:06:58 -0000 On Thu, 2006-06-15 at 09:56 -0400, Matthias Clasen wrote: > I want to have GTK+ 2.10 ready at or immediately after GUADEC. [snip] I'd rather it was after rather than before. That gives us just a little more time to get everything wrapped quickly for gtkmm, which might show some small problems that need fixing. Maybe I haven't been paying attention, but I'm surprised (again) by the freeze announcement. -- Murray Cumming murrayc@murrayc.com www.murrayc.com www.openismus.com From mgiannakidis@gmail.com Thu Jun 15 11:24:35 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id B7BE73B0211 for ; Thu, 15 Jun 2006 11:24:35 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19150-09 for ; Thu, 15 Jun 2006 11:24:34 -0400 (EDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.188]) by menubar.gnome.org (Postfix) with ESMTP id AAD863B04FC for ; Thu, 15 Jun 2006 11:24:33 -0400 (EDT) Received: by nf-out-0910.google.com with SMTP id c2so90382nfe for ; Thu, 15 Jun 2006 08:23:41 -0700 (PDT) Received: by 10.48.47.15 with SMTP id u15mr674329nfu; Thu, 15 Jun 2006 08:23:39 -0700 (PDT) Received: from ?213.140.137.120? ( [213.140.137.120]) by mx.gmail.com with ESMTP id n22sm2029009nfc.2006.06.15.08.23.38; Thu, 15 Jun 2006 08:23:39 -0700 (PDT) From: Michalis Giannakidis To: gtk-devel-list@gnome.org Subject: gslice allocator: general impresions. Date: Thu, 15 Jun 2006 18:27:45 +0300 User-Agent: KMail/1.8.3 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200606151827.45477.mgiannakidis@gmail.com> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.6 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.6 X-Spam-Level: X-Mailman-Approved-At: Fri, 16 Jun 2006 05:29:57 -0400 X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 15:24:35 -0000 Dear Glib team, I have recently used the glib-glice allocator in a very malloc intensive application, and I would like to share a few observations I made, with you. The typical size I send to g_slice_alloc is 20 and 76 bytes (32 bit build). The total memory consumed by my application has decreased - which is great! However it `seems' to me, that this decrease in size is larger for the 64bit build compared to the 32bit build. (I have modified gslice to align a chunk to its own size so that I don't have unused memory between chunks eg: request 20 and get 24...) In my application now I use both g_slice_alloc and malloc.Testing the new allocator in linux I came accross the following: After using g_slice_alloc to alloc a great amount of data (eg 1500mb), each of them being 20 or 76 bytes in size, subsequent calls to malloc(8*1024) or similar sizes take much longer (the allocation does _not_ got to the swap). Also if I chage the min_page_size from 128 to 4096, then the subsequent calls to malloc(8*1024) or similar sizes take even longer. It takes for ever in the 64 bit build! Moreover, even with min_page_size set to 128, the calls to malloc take for ever on a Linux 2.4.20 glibc-2.2.4(glibc up to 2.2.5 has a broken posix_memalign so I fallback to memalign). In all of the cases above, malloc responds much faster when the gslice allocator is turned off. I know I should be providing sample code and test programms here to back up my observations. I also understand that I should provide execution times instead of just stating that the calls to malloc take for ever. I would like to ask you, if there are any known issues in mixing gslice and malloc calls in malloc intensive applications. Any suggested readings would be most welcome. Regards Michalis -- Michalis Giannakidis From timj@gtk.org Fri Jun 16 07:30:05 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id EEDE23B0011 for ; Fri, 16 Jun 2006 07:30:04 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26976-06 for ; Fri, 16 Jun 2006 07:30:04 -0400 (EDT) Received: from holken.mikan.net (holken.mikan.net [83.145.56.183]) by menubar.gnome.org (Postfix) with ESMTP id DA78D3B0007 for ; Fri, 16 Jun 2006 07:30:03 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by holken.mikan.net (Postfix) with ESMTP id BDFA43352B0; Fri, 16 Jun 2006 13:28:54 +0200 (CEST) Received: from holken.mikan.net ([127.0.0.1]) by localhost (holken.mikan.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29662-08; Fri, 16 Jun 2006 13:28:48 +0200 (CEST) Received: from birnet.org (d003098.adsl.hansenet.de [80.171.3.98]) by holken.mikan.net (Postfix) with ESMTP id DFB2633525A; Fri, 16 Jun 2006 13:28:47 +0200 (CEST) Received: from master.birnet.private (localhost.localdomain [127.0.0.1]) by birnet.org (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k5GBSi9S008066 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 16 Jun 2006 13:28:44 +0200 Received: (from timj@localhost) by master.birnet.private (8.13.4/8.13.4/Submit) id k5GBSZMj008064; Fri, 16 Jun 2006 13:28:35 +0200 Date: Fri, 16 Jun 2006 13:28:35 +0200 (CEST) From: Tim Janik X-X-Sender: timj@master.birnet.private To: "Gustavo J. A. M. Carneiro" Subject: Re: GObject extension propose (GContainer) In-Reply-To: <1150456522.5305.12.camel@localhost.localdomain> Message-ID: References: <200606151101.12868.ntd@users.sourceforge.net> <44919246.8060301@gnome.org> <1150456522.5305.12.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="656239-2144330416-1150457315=:7955" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at holken.mikan.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.677 tagged_above=-999 required=2 tests=[AWL=-0.669, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, RCVD_IN_SORBS_WEB=1.456] X-Spam-Score: -1.677 X-Spam-Level: Cc: Gtk+ Developers X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2006 11:30:05 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --656239-2144330416-1150457315=:7955 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Fri, 16 Jun 2006, Gustavo J. A. M. Carneiro wrote: > Qui, 2006-06-15 =E0s 13:00 -0400, Tristan Van Berkom escreveu: >> All of that just to say... I cannot count the times I've thought to >> myself that >> GtkContainer should really just be GContainerIface, and implemented by >> whatever interested objects that want to parent other objects... > > That's interesting, but I wonder what is the runtime penalty of > interface lookup compared to normal class structure lookup? Is it > really OK to use an interface for this, or is it better just to add a > new virtual methods to the GObject class? the lookup penalties are negligible. type node/class lookups and is_a checks are O(1); interface class lookups and conforms_to checks are O(ld(N)), where N is the number of interfaces a type node conforms to. > Gustavo J. A. M. Carneiro --- ciaoTJ --656239-2144330416-1150457315=:7955-- From gjc@inescporto.pt Fri Jun 16 07:34:21 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 74BCC3B000B for ; Fri, 16 Jun 2006 07:34:21 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26977-07 for ; Fri, 16 Jun 2006 07:34:20 -0400 (EDT) Received: from animal.inescn.pt (correio.inescn.pt [194.117.24.9]) by menubar.gnome.org (Postfix) with ESMTP id 5B7183B0011 for ; Fri, 16 Jun 2006 07:34:19 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by animal.inescn.pt (8.13.6/8.13.6/7) with ESMTP id k5GBFdIJ028014; Fri, 16 Jun 2006 12:15:39 +0100 (WEST) Received: from pong.inescporto.pt (pong.inescn.pt [194.117.26.74]) by animal.inescn.pt (8.13.6/8.13.6/5) with ESMTP id k5GBFT0a027999; Fri, 16 Jun 2006 12:15:29 +0100 (WEST) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by pong.inescporto.pt (Postfix) with ESMTP id AE13A39D8; Fri, 16 Jun 2006 12:12:16 +0100 (WEST) Subject: Re: GObject extension propose (GContainer) From: "Gustavo J. A. M. Carneiro" To: Tristan Van Berkom In-Reply-To: <44919246.8060301@gnome.org> References: <200606151101.12868.ntd@users.sourceforge.net> <44919246.8060301@gnome.org> Content-Type: text/plain; charset=UTF-8 Date: Fri, 16 Jun 2006 12:15:21 +0100 Message-Id: <1150456522.5305.12.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at inescporto.pt X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.39 tagged_above=-999 required=2 tests=[AWL=-0.002, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, SPF_PASS=-0.001, TW_GT=0.077] X-Spam-Score: -2.39 X-Spam-Level: Cc: Gtk+ Developers , Tim Janik X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2006 11:34:21 -0000 Qui, 2006-06-15 às 13:00 -0400, Tristan Van Berkom escreveu: > Tim Janik wrote: > > >On Thu, 15 Jun 2006, Fontana Nicola wrote: > > > > > > > >>Hi all, > >> > >>I'm a GObject based libraries (for UI purpose and not) user and I often need > >>a generic container to derive my own types. In my opinion, I think this > >>generic container must be included inside the GObject library ... it could > >>be used by a lot of derived libraries providing a common approach. > >> > >>I published my solution - that is, what I am currently using - on > >>sourceforge. > >> > >>http://sourceforge.net/projects/gcontainer/ > >> > >>Is it a good idea? Is something planned in this direction? Am I totally > >>wrong? > >> > >>I need feedbacks ... > >> > >> > As a side note... I've been working on container --> child relationships and > honing them down inside the glade builder... objects may for example have > object delagates that are "owned" and in turn may "own" other delagates... > this is all functional with libglade facilities and the future gtk > builder also > (from the design as of yet...)... this concept of "types of container > relationships" > is also usefull for GtkMenuShell --> GtkMenu for example (not just any > GtkWidget > can be added to a menushell). > > All of that just to say... I cannot count the times I've thought to > myself that > GtkContainer should really just be GContainerIface, and implemented by > whatever interested objects that want to parent other objects... That's interesting, but I wonder what is the runtime penalty of interface lookup compared to normal class structure lookup? Is it really OK to use an interface for this, or is it better just to add a new virtual methods to the GObject class? > I think > that what we need is not really "yet another container api", but a container > api that is a unified front for generic handling of the GTK object > hierarchy at runtime. Actually, for the python language bindings we could use a generic GObject container interface. See http://bugzilla.gnome.org/show_bug.cgi?id=303266 Regards. -- Gustavo J. A. M. Carneiro The universe is always one step beyond logic From alan@clueserver.org Fri Jun 16 12:57:14 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 502C63B0336 for ; Fri, 16 Jun 2006 12:57:14 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06317-07 for ; Fri, 16 Jun 2006 12:57:08 -0400 (EDT) Received: from clueserver.org (216-99-213-120.dsl.aracnet.com [216.99.213.120]) by menubar.gnome.org (Postfix) with ESMTP id 7529F3B041B for ; Fri, 16 Jun 2006 12:54:18 -0400 (EDT) Received: by clueserver.org (Postfix, from userid 500) id 2985BF50BE2; Fri, 16 Jun 2006 09:53:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by clueserver.org (Postfix) with ESMTP id 26461F50BE1; Fri, 16 Jun 2006 09:53:44 -0700 (PDT) Date: Fri, 16 Jun 2006 09:53:44 -0700 (PDT) From: alan X-X-Sender: alan@blackbox.fnordora.org To: Jason Spiro Subject: Re: Imagine: what if points in Bugzilla had a significant effect? In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.45 tagged_above=-999 required=2 tests=[AWL=0.014, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.45 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2006 16:57:14 -0000 On Thu, 15 Jun 2006, Jason Spiro wrote: > Imagine: what if points did something in Bugzilla, like, the more points > you have, the more votes you get? Slashzilla? -- "Waiter! This lambchop tastes like an old sock!" - Sheri Lewis From ntd@users.sourceforge.net Fri Jun 16 14:08:36 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 39BE13B03E1 for ; Fri, 16 Jun 2006 14:08:36 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11017-04 for ; Fri, 16 Jun 2006 14:08:34 -0400 (EDT) Received: from mailout02.albacom.net (mailout02.albacom.net [217.220.34.14]) by menubar.gnome.org (Postfix) with SMTP id E2E913B00E4 for ; Fri, 16 Jun 2006 14:08:33 -0400 (EDT) Received: (qmail 21669 invoked by uid 507); 16 Jun 2006 18:08:08 -0000 Received: from ntd@users.sourceforge.net by mailout02.albacom.net with qmail-scanner (spamassassin: ???. Clear:RC:1(217.221.76.9):SA:0(0.0/15.0):. Processed in 0.841774 secs); 16 Jun 2006 18:08:08 -0000 Received: from unknown (HELO sviluppo.internet.local) (postmaster@effe-gi.it@217.221.76.9) by mailout02.albacom.net with SMTP; 16 Jun 2006 18:08:07 -0000 From: Fontana Nicola Organization: Elettronica EFFE-GI s.n.c. To: Tim Janik Subject: Re: GObject extension propose (GContainer) Date: Fri, 16 Jun 2006 20:44:11 +0000 User-Agent: KMail/1.9.1 References: <200606151101.12868.ntd@users.sourceforge.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200606162044.11716.ntd@users.sourceforge.net> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.526 tagged_above=-999 required=2 tests=[AWL=-0.004, BAYES_00=-2.599, TW_GT=0.077] X-Spam-Score: -2.526 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2006 18:08:36 -0000 > On Thu, 15 Jun 2006, Fontana Nicola wrote: > > Hi all, > > > > I'm a GObject based libraries (for UI purpose and not) user and I often > > need a generic container to derive my own types. In my opinion, I think > > this generic container must be included inside the GObject library ... it > > could be used by a lot of derived libraries providing a common approach. > > > > I published my solution - that is, what I am currently using - on > > sourceforge. > > > > http://sourceforge.net/projects/gcontainer/ > > > > Is it a good idea? Is something planned in this direction? Am I totally > > wrong? > > > > I need feedbacks ... > > hi. your gcontainer-1.0.0 looks like an interesting approach to me, but > i'm not sure it's generally good to put that into stock libgobject. > the main reason is that container needs are probably pretty variable > out there (i've come across at least 4 different gobject container > implementations in free software projects i'm woorking on) and that > both, making too little assumptions in the child/container interface > isn't going to be very helpful, albeit making too many has the > same problem. Some time ago I've started a communication library based on libgobject and I feeled the need of two things: a base object with floating reference and a container. After some time, I started an experimental cairo canvas and I had the same needs. In both cases, no gtk dependency was requested. Briefly, I'm not talking about a container that cover all needs and tastes but instead about "moving the GtkContainer logic and complexity" from gtk to gobject, something similar to what was done for GtkObject and its floating reference. I wrote gcontainer with this in mind (the GContainerable interface is "compatible" with GtkContainer and GChildable with GtkWidget). Anyway, my solution presents some serious problems: I'm misusing the interface to hide as much technical details as possible to the implementing objects. I know it is a huge task but consider this as an idea or a looooong term project: I don't think to be the only one with these needs. > > i guess we could add a link to your project from the libgobject docs > (it should probably have a Contrib section), for people possibly looking > for a GObject container implementation. that way, gcontainer-1.0.0 gets > a chance of being reused and maybe extended to something generally > usefull for GObject applications out there. > > > Nicola > > --- > ciaoTJ Of course I'll be glad to have a link in the gobject documentation. Thank you for your availability. Nicola From tristan.van.berkom@gmail.com Fri Jun 16 14:26:50 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id E38F43B0139 for ; Fri, 16 Jun 2006 14:26:49 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12245-08 for ; Fri, 16 Jun 2006 14:26:49 -0400 (EDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.197]) by menubar.gnome.org (Postfix) with ESMTP id DB55F3B0179 for ; Fri, 16 Jun 2006 14:26:48 -0400 (EDT) Received: by wx-out-0102.google.com with SMTP id i30so517779wxd for ; Fri, 16 Jun 2006 11:26:15 -0700 (PDT) Received: by 10.70.83.9 with SMTP id g9mr4369121wxb; Fri, 16 Jun 2006 11:20:03 -0700 (PDT) Received: from ?66.48.170.68? ( [66.48.170.68]) by mx.gmail.com with ESMTP id h39sm2692858wxd.2006.06.16.11.20.01; Fri, 16 Jun 2006 11:20:03 -0700 (PDT) Message-ID: <4492FA3C.5060106@gmail.com> Date: Fri, 16 Jun 2006 14:36:44 -0400 From: Tristan Van Berkom User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Fontana Nicola Subject: Re: GObject extension propose (GContainer) References: <200606151101.12868.ntd@users.sourceforge.net> <200606162044.11716.ntd@users.sourceforge.net> In-Reply-To: <200606162044.11716.ntd@users.sourceforge.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.497 tagged_above=-999 required=2 tests=[AWL=-0.353, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=1.456, SPF_PASS=-0.001] X-Spam-Score: -1.497 X-Spam-Level: Cc: gtk-devel-list@gnome.org, Tim Janik X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2006 18:26:50 -0000 Fontana Nicola wrote: [...] >I wrote gcontainer with this in mind (the GContainerable interface is >"compatible" with GtkContainer and GChildable with GtkWidget). Anyway, my >solution presents some serious problems: I'm misusing the interface to hide >as much technical details as possible to the implementing objects. > >I know it is a huge task but consider this as an idea or a looooong term >project: I don't think to be the only one with these needs. > > I think you may be overcomplicating things, if for example; the GContainerable or GContainerIface were implemented by GtkContainer; then nothing in GtkContainer derivatives would really have to change (unless the api was drasticly different... but I doubt that). Then this could be extended to other object sets and other needs without having to rewrite large pieces of code. Cheers, -Tristan From behdad.esfahbod@gmail.com Fri Jun 16 15:04:20 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 611EA3B00F8 for ; Fri, 16 Jun 2006 15:04:20 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15384-03 for ; Fri, 16 Jun 2006 15:04:18 -0400 (EDT) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.228]) by menubar.gnome.org (Postfix) with ESMTP id 566D33B007C for ; Fri, 16 Jun 2006 15:04:18 -0400 (EDT) Received: by wr-out-0506.google.com with SMTP id i4so618991wra for ; Fri, 16 Jun 2006 12:03:42 -0700 (PDT) Received: by 10.54.142.9 with SMTP id p9mr3126451wrd; Fri, 16 Jun 2006 11:57:25 -0700 (PDT) Received: from ?192.168.190.5? ( [72.136.156.47]) by mx.gmail.com with ESMTP id 10sm2200187wrl.2006.06.16.11.57.23; Fri, 16 Jun 2006 11:57:24 -0700 (PDT) Subject: Re: Imagine: what if points in Bugzilla had a significant effect? From: Behdad Esfahbod To: gtk-devel-list@gnome.org In-Reply-To: References: Content-Type: text/plain Date: Fri, 16 Jun 2006 14:57:22 -0400 Message-Id: <1150484242.15469.17.camel@home> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 (2.6.1-1.fc5.2) Content-Transfer-Encoding: 7bit Sender: Behdad Esfahbod X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.561 tagged_above=-999 required=2 tests=[AWL=-0.038, BAYES_00=-2.599, SPF_PASS=-0.001, TW_GT=0.077] X-Spam-Score: -2.561 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2006 19:04:20 -0000 On Thu, 2006-06-15 at 15:15 -0400, Jason Spiro wrote: > Imagine: what if points did something in Bugzilla, like, the more points > you have, the more votes you get? > > I think this would encourage people to file more bug reports, both good > bug reports and not-so-good ones. Would that be a net gain or a net loss > for GTK+? It has evolved to be like that already. The more points one has, the more he (or she, in the near future) respects bugs/comments from high-point others. Or at least that's been my experience. behdad > Regards, > Jason Spiro > > -- > Jason Spiro: computer consulting with a smile. > Specializing in Linux: Red Hat AS / ES, Debian, and others. > Serving homes and companies globally via remote access tools. Fair rates. > Just email jasonspiro4@gmail.com or call Skype ID jasonspiro. > > _______________________________________________ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-devel-list -- behdad http://behdad.org/ "Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill" -- Dan Bern, "New American Language" From grakic@devbase.net Fri Jun 16 16:12:39 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 7B9EC3B025A for ; Fri, 16 Jun 2006 16:12:39 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19416-03 for ; Fri, 16 Jun 2006 16:12:38 -0400 (EDT) Received: from mxout-04.mxes.net (mxout-04.mxes.net [205.237.194.35]) by menubar.gnome.org (Postfix) with ESMTP id 07A823B02B4 for ; Fri, 16 Jun 2006 16:12:37 -0400 (EDT) Received: from limun.local (unknown [87.116.163.93]) by smtp.mxes.net (Postfix) with ESMTP id C5307A3292; Fri, 16 Jun 2006 16:11:35 -0400 (EDT) Subject: Re: Imagine: what if points in Bugzilla had a significant effect? From: Goran Rakic To: Jason Spiro In-Reply-To: References: Content-Type: text/plain; charset=utf-8 Date: Fri, 16 Jun 2006 22:11:33 +0200 Message-Id: <1150488693.2273.3.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.6 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, SPF_HELO_PASS=-0.001] X-Spam-Score: -2.6 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2006 20:12:39 -0000 Lary Osterman has a nice writing on this topic titled "Measuring testers by test metrics doesn't." У čet, 15. 06 2006. у 19:15 +0000, Jason Spiro пише: > Imagine: what if points did something in Bugzilla, like, the more points > you have, the more votes you get? > > I think this would encourage people to file more bug reports, both good > bug reports and not-so-good ones. Would that be a net gain or a net loss > for GTK+? > > Regards, > Jason Spiro From ame1@extratech.com Fri Jun 16 17:02:33 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 2F9013B018C for ; Fri, 16 Jun 2006 17:02:33 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21327-05 for ; Fri, 16 Jun 2006 17:02:32 -0400 (EDT) Received: from portal2.extratech.com (portal.extratech.com [67.105.201.210]) by menubar.gnome.org (Postfix) with ESMTP id BB3BD3B01C8 for ; Fri, 16 Jun 2006 17:02:31 -0400 (EDT) Received: from zosma.extratech.com (zosma.extratech.com [192.168.0.41]) by portal2.extratech.com (8.12.11/8.12.11) with ESMTP id k5GL1Quq030485 for ; Fri, 16 Jun 2006 14:01:26 -0700 Subject: Re: GObject extension propose (GContainer) From: "Alan M. Evans" To: Gtk+ Developers In-Reply-To: References: <200606151101.12868.ntd@users.sourceforge.net> <44919246.8060301@gnome.org> <1150456522.5305.12.camel@localhost.localdomain> Content-Type: text/plain; charset=UTF-8 Message-Id: <1150491686.19405.355.camel@zosma.extratech.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 16 Jun 2006 14:01:26 -0700 Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV 0.86.1/1544/Fri Jun 16 02:19:15 2006 on portal2.extratech.com X-Virus-Status: Clean X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.556 tagged_above=-999 required=2 tests=[AWL=0.044, BAYES_00=-2.599] X-Spam-Score: -2.556 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2006 21:02:33 -0000 On Fri, 2006-06-16 at 04:28, Tim Janik wrote: > On Fri, 16 Jun 2006, Gustavo J. A. M. Carneiro wrote: > > > Qui, 2006-06-15 às 13:00 -0400, Tristan Van Berkom escreveu: > > >> All of that just to say... I cannot count the times I've thought to > >> myself that > >> GtkContainer should really just be GContainerIface, and implemented by > >> whatever interested objects that want to parent other objects... > > > > That's interesting, but I wonder what is the runtime penalty of > > interface lookup compared to normal class structure lookup? Is it > > really OK to use an interface for this, or is it better just to add a > > new virtual methods to the GObject class? > > the lookup penalties are negligible. > type node/class lookups and is_a checks are O(1); > interface class lookups and conforms_to checks are O(ld(N)), where > N is the number of interfaces a type node conforms to. Your assertion that the penalties are negligable is not really supported by your response, unless the constant is also known for both orders. From ebassi@gmail.com Fri Jun 16 20:14:03 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 3E95D3B069B for ; Fri, 16 Jun 2006 20:14:03 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28883-03 for ; Fri, 16 Jun 2006 20:14:00 -0400 (EDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.185]) by menubar.gnome.org (Postfix) with ESMTP id 969133B015A for ; Fri, 16 Jun 2006 20:13:59 -0400 (EDT) Received: by nf-out-0910.google.com with SMTP id c2so667512nfe for ; Fri, 16 Jun 2006 17:13:07 -0700 (PDT) Received: by 10.49.72.13 with SMTP id z13mr2277195nfk; Fri, 16 Jun 2006 17:05:51 -0700 (PDT) Received: from ?192.168.1.74? ( [86.136.65.180]) by mx.gmail.com with ESMTP id y23sm3836170nfb.2006.06.16.17.05.51; Fri, 16 Jun 2006 17:05:51 -0700 (PDT) Subject: Re: GTK+ 2.10, the endgame From: Emmanuele Bassi To: gtk-devel-list@gnome.org In-Reply-To: <1150447930.5806.4.camel@localhost.localdomain> References: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> <1150390229.17566.191.camel@cacharro.xalalinux.org> <1150391737.3187.33.camel@dhcp83-98.boston.redhat.com> <1150447930.5806.4.camel@localhost.localdomain> Content-Type: text/plain Date: Sat, 17 Jun 2006 01:05:50 +0100 Message-Id: <1150502750.2668.12.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.34 tagged_above=-999 required=2 tests=[AWL=0.260, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.34 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2006 00:14:03 -0000 Hi Murray, On Fri, 2006-06-16 at 10:52 +0200, Murray Cumming wrote: > I'm also concerned about the recent files stuff. Do we now have > UIManager integration of that? No, and I am to blame because I had less time to spend on fixing this issue. Mostly, I've been stuck on how to implement an action for both the menu and toolbars using the same tag. In the meantime, a nice and clean way to integrate the GtkRecentChooserMenu inside a GtkUIManager is to subclass GtkAction into a custom action that automatically adds a recent chooser menu to the menu item it creates, and use a placeholder in the UI definition (most applications using EggRecentViewUIManager already have that placeholder present). A working example is available here: http://www.gnome.org/~ebassi/test-uimanager.c The action code itself is one hundred lines long and can easily be hidden inside an helper file; it's approximately how GtkRecentAction would be implemented, anyway. I hereby give permission to do whatever you want to do with it. I understand that it's sub-optimal, and hopefully this should really go away once there's an action inside GTK. Ciao, Emmanuele. -- Emmanuele Bassi, E: ebassi@gmail.com W: http://www.emmanuelebassi.net B: http://log.emmanuelebassi.net From behdad.esfahbod@gmail.com Mon Jun 12 17:52:45 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 162C73B02CD for ; Mon, 12 Jun 2006 17:52:45 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00303-05 for ; Mon, 12 Jun 2006 17:52:43 -0400 (EDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.206]) by menubar.gnome.org (Postfix) with ESMTP id 643023B0010 for ; Mon, 12 Jun 2006 17:52:43 -0400 (EDT) Received: by wx-out-0102.google.com with SMTP id h26so956965wxd for ; Mon, 12 Jun 2006 14:51:27 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:subject:from:to:content-type:date:message-id:mime-version:x-mailer:sender; b=HkVpdki0/g3XkGcHUm613LiH99RNWp83QpOiB04twtI9/oyY5QJs7xgUW9ugXUYWTW0FQESua3SiFes9GpwcHFnulMB+jmu6Frg1gjSTz94Z0WNKazKYJCx/0yCrKVvi+sIhO9793kd+R7hBbKFWLBqlIyo5yetvED1gx6HIjnc= Received: by 10.70.36.1 with SMTP id j1mr6891335wxj; Mon, 12 Jun 2006 14:44:52 -0700 (PDT) Received: from to-dhcp26.toronto.redhat.com ( [63.250.163.171]) by mx.gmail.com with ESMTP id h18sm3879342wxd.2006.06.12.14.44.50; Mon, 12 Jun 2006 14:44:51 -0700 (PDT) Subject: Pango-1.13.2 released [unstable] From: Behdad Esfahbod To: Pango Release Lists , gtk-app-devel-list@gnome.org, gtk-devel-list@gnome.org, gtk-i18n-list@gnome.org, gtk-list@gnome.org Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-HZBsNn3KdPR3jVVwB9gO" Date: Mon, 12 Jun 2006 17:44:37 -0400 Message-Id: <1150148678.10765.8.camel@home> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 (2.6.1-1.fc5.2) Sender: Behdad Esfahbod X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.6 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.6 X-Spam-Level: X-Mailman-Approved-At: Fri, 16 Jun 2006 05:27:53 -0400 X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2006 21:52:45 -0000 --=-HZBsNn3KdPR3jVVwB9gO Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Pango-1.13.2 is now available for download at: ftp://ftp.gtk.org/pub/gtk/v2.11/ or http://download.gnome.org/sources/pango/1.13/ 28a6ea9d43c4cd398e7352032f775401 pango-1.13.2.tar.bz2 17d78473c05fece044c6a3b44519b61f pango-1.13.2.tar.gz This is a development release leading up to Pango-1.14.0, which will be released just in time for GNOME-2.16. Notes: * This is unstable development release. While it has had fairly extensive testing, there are likely bugs remaining to be found. This release should not be used in production. * Installing this version will overwrite your existing copy of Pango-1.12. If you have problems, you'll need to reinstall Pango-1.12.x * Bugs should be reported to http://bugzilla.gnome.org. About Pango =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Pango is a library for layout and rendering of text, with an emphasis on internationalization. Pango can be used anywhere that text layout is needed, though most of the work on Pango so far has been done in the context of the GTK+ widget toolkit. Pango forms the core of text and font handling for GTK+-2.x. Pango is designed to be modular; the core Pango layout engine can be used with different font backends. There are three basic backends, with multiple options for rendering with each. - Client side fonts using the FreeType and fontconfig libraries. Rendering can be with with Cairo or Xft libraries, or directly to an in-memory buffer with no additional libraries. - Native fonts on Microsoft Windows. (Optionally using Uniscribe for complex-text handling). Rendering can be done via Cairo or directly using the native Win32 API. - Native fonts on MacOS X, rendering via Cairo. The integration of Pango with Cairo (http://cairographics.org) provides a complete solution with high quality text handling and graphics rendering. Dynamically loaded modules then handle text layout for particular combinations of script and font backend. Pango ships with a wide selection of modules, including modules for Hebrew, Arabic, Hangul, Thai, and a number of Indic scripts. Virtually all of the world's major scripts are supported. As well as the low level layout rendering routines, Pango includes PangoLayout, a high level driver for laying out entire blocks of text, and routines to assist in editing internationalized text. More information about Pango is available from http://www.pango.org/. Pango 1.13.2 depends on version 2.10.0 or newer of the GLib library and version 1.1.2 or newer of the cairo library (if the cairo backend is desired); more information about GLib and cairo can be found at http://www.gtk.org/ and http://cairographics.org/ respectively. Overview of changes between 1.13.1 and 1.13.2 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D * Improved hexbox drawing, and font metrics calculations. * Synthesize italic variants on win32 [Hans Breuer] * New public API: - pango_cairo_show_error_underline - pango_cairo_error_underline_path - pango_font_describe_with_absolute_size * Misc fixes. * Bugs fixed in this release: Bug 326960 =E2=80=93 hex box drawing for win32 and atsui backends of cairo Bug 343717 =E2=80=93 License information in unclear. Bug 343355 =E2=80=93 Add pango_cairo_show_error_underline & pango_cairo_error_underline_path Bug 343966 =E2=80=93 pango Cygwin build fixes Patch from Cygwin Ports maintainer. Bug 343796 =E2=80=93 Italic Chinese character can't be show correctly in Win32. Bug 314114 =E2=80=93 max_x_advance not appropriate for approximate_(char|digit)_width Bug 341138 =E2=80=93 Using TTC font, Gtk2 programs begin to eating big mem= ory and have many cpu usage. Patch from Yong Li. Bug 336153 =E2=80=93 Mark to mark positioning (Lookup Type 6) isn't correc= t when using MarkAttchmentType Patch from Tin Myo Htet. Bug 333984 =E2=80=93 pango_language_from_string improvements Bug 125378 =E2=80=93 Better underline thickness handling Bug 339730 =E2=80=93 Pango needlessly falls back away from a Type 1 font i= nto a TTF font Bug 342562 =E2=80=93 Support absolute sizes in pango_font_description_to/from_string Bug 341922 =E2=80=93 pango should handle more characters as zero width Patch from Roozbeh Pournader Bug 342525 =E2=80=93 With PangoFc and PangoWin32, approximate digit width = is not what it says Bug 342079 =E2=80=93 pangoatsui-private.h missing from release Behdad Esfahbod 12 June 2006 --=-HZBsNn3KdPR3jVVwB9gO Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQBEjeBFn+4E5dNTERURApTwAJ9OvqbaG1xnQYzGPC9u0WPi30b6ggCfXNvZ oFfMwctzkAaKRETc/0aDRj0= =Wl7j -----END PGP SIGNATURE----- --=-HZBsNn3KdPR3jVVwB9gO-- From Klaus.Stengel@asamnet.de Tue Jun 13 06:57:05 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 1BD1E3B008F for ; Tue, 13 Jun 2006 06:57:05 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20572-03 for ; Tue, 13 Jun 2006 06:57:03 -0400 (EDT) Received: from mail.asamnet.de (mail.asamnet.de [194.25.81.18]) by menubar.gnome.org (Postfix) with ESMTP id A52473B000C for ; Tue, 13 Jun 2006 06:57:03 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.asamnet.de (Asamnet e.V. Mailserver) with ESMTP id D01E8A7076 for ; Tue, 13 Jun 2006 12:56:24 +0200 (CEST) Received: from mail.asamnet.de ([127.0.0.1]) by localhost (mail.asamnet.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00951-06 for ; Tue, 13 Jun 2006 12:56:24 +0200 (CEST) Received: from aquarian.nathanet.lan (p5492D6A6.dip.t-dialin.net [84.146.214.166]) by mail.asamnet.de (Asamnet e.V. Mailserver) with ESMTP id 6350FA7066 for ; Tue, 13 Jun 2006 12:56:24 +0200 (CEST) Subject: Pango memory leak in get_ruleset() in modules/basic/basic-fc.c From: Klaus Stengel To: gtk-devel-list@gnome.org Content-Type: text/plain Date: Tue, 13 Jun 2006 12:56:34 +0200 Message-Id: <1150196194.9594.16.camel@aquarian.nathanet.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at asamnet.de X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.464 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.464 X-Spam-Level: X-Mailman-Approved-At: Fri, 16 Jun 2006 05:27:53 -0400 X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2006 10:57:05 -0000 Hi, while working with the diagram editor "dia" I noticed a major memory leak when editing text objects. I tracked this down to a problem in the above function. From what I understand the function looks for an ruleset associated with the given font face and in case there is none, the ruleset is created with pango_ot_ruleset_new() and finally attached to the font face. The g_object_unref() is given as "notification callback" so that the ruleset is destroyed when the font face is finalized. In theory this should work, but unfortunately it doesn't in practice, because pango_ot_ruleset_new() internally references "info" itself, thus creating a circular dependency that keeps the objects alive indefinitely. Unfortunately I don't see an simple solution, except to drop that kind of caching again... Bye, Klaus. P.S.: Please reply to my email address as well, as I'm not subscribed to the list. From newren@gmail.com Sat Jun 17 01:54:29 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 7F2843B066E for ; Sat, 17 Jun 2006 01:54:29 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08609-05 for ; Sat, 17 Jun 2006 01:54:28 -0400 (EDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.198]) by menubar.gnome.org (Postfix) with ESMTP id 354E43B050E for ; Sat, 17 Jun 2006 01:54:28 -0400 (EDT) Received: by wx-out-0102.google.com with SMTP id h26so603851wxd for ; Fri, 16 Jun 2006 22:53:32 -0700 (PDT) Received: by 10.70.24.3 with SMTP id 3mr5192323wxx; Fri, 16 Jun 2006 22:53:32 -0700 (PDT) Received: by 10.70.102.9 with HTTP; Fri, 16 Jun 2006 22:53:32 -0700 (PDT) Message-ID: <51419b2c0606162253pfe0e7edsba8af3f8a1573477@mail.gmail.com> Date: Fri, 16 Jun 2006 23:53:32 -0600 From: "Elijah Newren" To: "Jason Spiro" Subject: Re: Imagine: what if points in Bugzilla had a significant effect? In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.572 tagged_above=-999 required=2 tests=[AWL=0.028, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.572 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2006 05:54:29 -0000 On 6/15/06, Jason Spiro wrote: > Imagine: what if points did something in Bugzilla, like, the more points > you have, the more votes you get? > > I think this would encourage people to file more bug reports, both good > bug reports and not-so-good ones. Would that be a net gain or a net loss > for GTK+? This isn't the right list for this email; bugzilla-devel or filed in bugzilla (against the bugzilla.gnome.org module) would be much better. Thanks, Elijah From timj@gtk.org Sat Jun 17 10:12:11 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id CD5003B00A6 for ; Sat, 17 Jun 2006 10:12:11 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23968-01 for ; Sat, 17 Jun 2006 10:12:08 -0400 (EDT) Received: from holken.mikan.net (holken.mikan.net [83.145.56.183]) by menubar.gnome.org (Postfix) with ESMTP id 34EA13B00D5 for ; Sat, 17 Jun 2006 10:12:07 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by holken.mikan.net (Postfix) with ESMTP id AC6413352A5; Sat, 17 Jun 2006 13:44:21 +0200 (CEST) Received: from holken.mikan.net ([127.0.0.1]) by localhost (holken.mikan.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07456-06; Sat, 17 Jun 2006 13:44:16 +0200 (CEST) Received: from birnet.org (d003096.adsl.hansenet.de [80.171.3.96]) by holken.mikan.net (Postfix) with ESMTP id 7CD8233524F; Sat, 17 Jun 2006 13:44:16 +0200 (CEST) Received: from master.birnet.private (localhost.localdomain [127.0.0.1]) by birnet.org (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k5HBiART015834 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 17 Jun 2006 13:44:11 +0200 Received: (from timj@localhost) by master.birnet.private (8.13.4/8.13.4/Submit) id k5HBhvjK015833; Sat, 17 Jun 2006 13:43:57 +0200 Date: Sat, 17 Jun 2006 13:43:57 +0200 (CEST) From: Tim Janik X-X-Sender: timj@master.birnet.private To: Michalis Giannakidis Subject: Re: gslice allocator: general impresions. In-Reply-To: <200606151827.45477.mgiannakidis@gmail.com> Message-ID: References: <200606151827.45477.mgiannakidis@gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at holken.mikan.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.339 tagged_above=-999 required=2 tests=[AWL=0.048, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, TW_TX=0.077] X-Spam-Score: -2.339 X-Spam-Level: Cc: Gtk+ Developers X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2006 14:12:12 -0000 On Thu, 15 Jun 2006, Michalis Giannakidis wrote: > Dear Glib team, > > I have recently used the glib-glice allocator in a very malloc intensive > application, and I would like to share a few observations I made, with you. > > The typical size I send to g_slice_alloc is 20 and 76 bytes (32 bit build). > The total memory consumed by my application has decreased - which is great! > However it `seems' to me, that this decrease in size is larger for the 64bit > build compared to the 32bit build. (I have modified gslice to align a chunk > to its own size so that I don't have unused memory between chunks eg: request > 20 and get 24...) you mean you've set P2ALIGNMENT to 1 * sizeof(void*) to get better granularity of the slices? have you left NATIVE_MALLOC_PADDING at 2*sizeof(void*) at least? (if not, memory fragmentation on some glibc systems and on all 64bit systems can become etxremely bad). > In my application now I use both g_slice_alloc and malloc.Testing the new > allocator in linux I came accross the following: > After using g_slice_alloc to alloc a great amount of data (eg 1500mb), each of > them being 20 or 76 bytes in size, subsequent calls to malloc(8*1024) or > similar sizes take much longer (the allocation does _not_ got to the swap). this is a magnitude of memory allocations where gslice hasn't been well tested. (my machine only has 1GB of memory for instance). while gslice should perform well even much beyond 1GB, i'd suspect that malloc()/memalign() don't, and thus could result in *some* GSlice slowdown as well. > Also if I chage the min_page_size from 128 to 4096, then the subsequent calls > to malloc(8*1024) or similar sizes take even longer. It takes for ever in the > 64 bit build! maybe due to your alignment tweaks. but maybe also because some malloc() buckets will have even longer lists that way. > Moreover, even with min_page_size set to 128, the calls to malloc take for > ever on a Linux 2.4.20 glibc-2.2.4(glibc up to 2.2.5 has a broken > posix_memalign so I fallback to memalign). broken in what way? > In all of the cases above, malloc responds much faster when the gslice > allocator is turned off. aparently some malloc implementations aren't too good at handling large numbers of page allocations. if modifying GSlice is an option for you, you could try to work around this at the expense of read-only allocation of the memory used by GSlice. to do that, you need to disable the HAVE_COMPLIANT_POSIX_MEMALIGN, HAVE_MEMALIGN and HAVE_VALLOC branches in allocator_memalign() and allocator_memfree() so the read-only malloc()-based fallback allocator is enabled. on 32bit systems, that'll by default allocate 16*4096=64k areas to allocate pages from. by doing: - const guint n_pages = 16; + const guint n_pages = 2560; you'll instead allocate 10MB areas, which should put far less stress on the system malloc() (that way, to fill 1GB, a maximum of 100 allocations are required). > I know I should be providing sample code and test programms here to back up > my observations. I also understand that I should provide execution times > instead of just stating that the calls to malloc take for ever. test programs would be great. allthough this kind of stress test can only be run and examined on a limited set of machines. e.g. the development machines i use have just 1GB and normally have only 30%-40% of free memory to spare for tests during runs like make check -C glib/test ;) > I would like to ask you, if there are any known issues in mixing gslice and > malloc calls in malloc intensive applications. > Any suggested readings would be most welcome. you've already seen the two papers cited in the big comment block at the start of gslice.c? it links to: http://citeseer.ist.psu.edu/bonwick94slab.html http://citeseer.ist.psu.edu/bonwick01magazines.html the first of which describes a kernel page allocator which isn't implemented by GSlice. we use memalign() instead, on the assumption that this is good enough for the vast majority of applications out there. if malloc is too stressed out by the aligned allocations gslice makes in your scenario, implementing this page allocator on top of mmap() and using that as a base allocator for gslice may be another option. > Regards > Michalis --- ciaoTJ From tristan.van.berkom@gmail.com Sat Jun 17 12:09:06 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 2E2D13B013A for ; Sat, 17 Jun 2006 12:09:06 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26133-07 for ; Sat, 17 Jun 2006 12:09:03 -0400 (EDT) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.239]) by menubar.gnome.org (Postfix) with ESMTP id DEE4F3B0061 for ; Sat, 17 Jun 2006 12:09:02 -0400 (EDT) Received: by wr-out-0506.google.com with SMTP id 57so940143wri for ; Sat, 17 Jun 2006 09:07:30 -0700 (PDT) Received: by 10.54.116.7 with SMTP id o7mr3977729wrc; Sat, 17 Jun 2006 09:00:41 -0700 (PDT) Received: from ?66.48.170.156? ( [66.48.170.156]) by mx.gmail.com with ESMTP id 44sm2844499wri.2006.06.17.09.02.05; Sat, 17 Jun 2006 09:02:06 -0700 (PDT) Message-ID: <44942B5F.2090903@gnome.org> Date: Sat, 17 Jun 2006 12:18:39 -0400 User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Alan M. Evans" Subject: Re: GObject extension propose (GContainer) References: <200606151101.12868.ntd@users.sourceforge.net> <44919246.8060301@gnome.org> <1150456522.5305.12.camel@localhost.localdomain> <1150491686.19405.355.camel@zosma.extratech.com> In-Reply-To: <1150491686.19405.355.camel@zosma.extratech.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit From: Tristan Van Berkom X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.208 tagged_above=-999 required=2 tests=[AWL=0.392, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.208 X-Spam-Level: Cc: Gtk+ Developers X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2006 16:09:06 -0000 Alan M. Evans wrote: [...] >>the lookup penalties are negligible. >>type node/class lookups and is_a checks are O(1); >>interface class lookups and conforms_to checks are O(ld(N)), where >>N is the number of interfaces a type node conforms to. >> >> > >Your assertion that the penalties are negligable is not really supported >by your response, unless the constant is also known for both orders. > > From my swift glance at gtype.c, it seems that in the case of an interface, the implementing interface is searched on that class's list of implementing interfaces... so when classes implement hundreds of interfaces it might be a performance hit. I dont think we've yet reached the day that we have to ditch good design and avoid using interfaces because of performance woes, that would be sorry day indeed... (I also dont think GTK+ code will be the only OO code needing major refactoring in those areas too... if these interface lookups weren't negligable) Cheers, -Tristan From chris@gnome-de.org Sat Jun 17 12:59:38 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 89E3F3B00A7 for ; Sat, 17 Jun 2006 12:59:38 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27929-06 for ; Sat, 17 Jun 2006 12:59:35 -0400 (EDT) Received: from mail.bytecamp.net (mail.bytecamp.net [212.204.60.9]) by menubar.gnome.org (Postfix) with SMTP id DF0E93B000D for ; Sat, 17 Jun 2006 12:59:34 -0400 (EDT) Received: (qmail 40076 invoked by uid 85); 17 Jun 2006 16:58:00 -0000 Received: from chris@gnome-de.org by mail.bytecamp.net by uid 88 with qmail-scanner-1.20 (clamscan: 0.88.1 Clear:RC:0(84.150.174.158):. Processed in 0.431315 secs); 17 Jun 2006 16:58:00 -0000 Received: from p5496ae9e.dip0.t-ipconnect.de (HELO ?192.168.123.112?) (chris@gnome-de.org@84.150.174.158) by mail.bytecamp.net with RC4-MD5 encrypted SMTP; 17 Jun 2006 16:57:59 -0000 Subject: GtkFileChooser/GnomeVFS backend still messing up authentication manager? (was: GTK+ 2.10, the endgame) From: Christian Neumair To: Matthias Clasen In-Reply-To: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> References: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> Content-Type: text/plain Date: Sat, 17 Jun 2006 18:57:54 +0200 Message-Id: <1150563475.24534.12.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.586 tagged_above=-999 required=2 tests=[AWL=0.013, BAYES_00=-2.599] X-Spam-Score: -2.586 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2006 16:59:38 -0000 Am Donnerstag, den 15.06.2006, 09:56 -0400 schrieb Matthias Clasen: > I want to have GTK+ 2.10 ready at or immediately after GUADEC. > > I did not declare 2.9.3 api frozen in the release announcement, > because we were still holding the door open for Kris' work on > the new tooltips api. But he has run into some difficulties > with the implementation which will take some time to overcome, > so we have decided to punt this feature and try to get it > into 2.12 early. > > Therefore, I want to consider 2.9.3 api frozen, and take a > look at what still needs to happen before 2.10. Here are some > things I personally would like get worked on (not sure > how much time I can free to look into these myself): > > - I think the async filechooser conversion has caused some > regressions, I noticed that .hidden support seems broken > and autocompletion also behaved badly for me recently. > > - There is a number of FIXMEs and unimplemented bits in > the print code. > > - The print backends need a careful look wrt to memory leaks > and error reporting. > > Are there other important bugs or regressions that need > attention before 2.10 ? Some months ago I investigated an issue where the GtkFileChooser requested file info for all shortcuts and caused mass login requests for all bookmarked remote locations on startup that require login with the GnomeVFS backend. I think the issue was that the file chooser has no way of requesting file info, but signalling at the same time that failure due to unavailability of resources or access constraints isn't fatal, allowing the GnomeVFS backend to not request login data when it is invoked through gtkfilechooserdefault.c:shortcuts_reload_icons. In that case, we may want to fall back to a folder icon. >From reading the GTK+ HEAD source code, the shortcut code still doesn't seem to pass any special flags, so it still seems to be relevant. -- Christian Neumair From gcottenc@gmail.com Sat Jun 17 13:23:55 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 81FC83B000D for ; Sat, 17 Jun 2006 13:23:55 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30389-08 for ; Sat, 17 Jun 2006 13:23:54 -0400 (EDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.197]) by menubar.gnome.org (Postfix) with ESMTP id 01A153B010F for ; Sat, 17 Jun 2006 13:23:53 -0400 (EDT) Received: by wx-out-0102.google.com with SMTP id h26so659270wxd for ; Sat, 17 Jun 2006 10:22:54 -0700 (PDT) Received: by 10.70.116.8 with SMTP id o8mr5867050wxc; Sat, 17 Jun 2006 10:22:54 -0700 (PDT) Received: by 10.70.19.4 with HTTP; Sat, 17 Jun 2006 10:22:54 -0700 (PDT) Message-ID: Date: Sat, 17 Jun 2006 19:22:54 +0200 From: "Guillaume Cottenceau" To: "Matthias Clasen" Subject: Re: GTK+ 2.10, the endgame In-Reply-To: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.6 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.6 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2006 17:23:55 -0000 On 6/15/06, Matthias Clasen wrote: > Therefore, I want to consider 2.9.3 api frozen, and take a Does this mean that http://developer.gnome.org/doc/API/2.0/gtk/ix07.html (and equivalents for gdk, pango, atk) is now a fully stable source for bindings which want to support new features of 2.10? -- Guillaume Cottenceau - http://zarb.org/~gc/ From timj@gtk.org Sun Jun 18 07:31:59 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id D384A3B0316 for ; Sun, 18 Jun 2006 07:31:59 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21403-07 for ; Sun, 18 Jun 2006 07:31:57 -0400 (EDT) Received: from holken.mikan.net (holken.mikan.net [83.145.56.183]) by menubar.gnome.org (Postfix) with ESMTP id 5988B3B09AB for ; Sun, 18 Jun 2006 07:31:57 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by holken.mikan.net (Postfix) with ESMTP id D1B0818461; Sun, 18 Jun 2006 13:31:12 +0200 (CEST) Received: from holken.mikan.net ([127.0.0.1]) by localhost (holken.mikan.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16166-04; Sun, 18 Jun 2006 13:31:09 +0200 (CEST) Received: from birnet.org (d003096.adsl.hansenet.de [80.171.3.96]) by holken.mikan.net (Postfix) with ESMTP id DE31E14571; Sun, 18 Jun 2006 13:31:08 +0200 (CEST) Received: from master.birnet.private (localhost.localdomain [127.0.0.1]) by birnet.org (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k5IBV5n9025330 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 18 Jun 2006 13:31:05 +0200 Received: (from timj@localhost) by master.birnet.private (8.13.4/8.13.4/Submit) id k5IBUuX0025320; Sun, 18 Jun 2006 13:30:56 +0200 Date: Sun, 18 Jun 2006 13:30:56 +0200 (CEST) From: Tim Janik X-X-Sender: timj@master.birnet.private To: Tristan Van Berkom Subject: Re: GObject extension propose (GContainer) In-Reply-To: <44942B5F.2090903@gnome.org> Message-ID: References: <200606151101.12868.ntd@users.sourceforge.net> <44919246.8060301@gnome.org> <1150456522.5305.12.camel@localhost.localdomain> <1150491686.19405.355.camel@zosma.extratech.com> <44942B5F.2090903@gnome.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at holken.mikan.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.378 tagged_above=-999 required=2 tests=[AWL=0.086, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.378 X-Spam-Level: Cc: Gtk+ Developers X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jun 2006 11:32:00 -0000 On Sat, 17 Jun 2006, Tristan Van Berkom wrote: > Alan M. Evans wrote: > [...] > >>> the lookup penalties are negligible. >>> type node/class lookups and is_a checks are O(1); >>> interface class lookups and conforms_to checks are O(ld(N)), where >>> N is the number of interfaces a type node conforms to. >>> >>> >> >> Your assertion that the penalties are negligable is not really supported >> by your response, unless the constant is also known for both orders. >> >> > From my swift glance at gtype.c, it seems that in the case of > an interface, the implementing interface is searched on that class's > list of implementing interfaces... so when classes implement > hundreds of interfaces it might be a performance hit. no there won't be a performance hit. that's because gtype.c uses a binary search for the lookups (as indicated in my last email by the O(ld(N)) complexity). the function used for frequent interface lookups is: gpointer g_type_interface_peek (gpointer instance_class, GType iface_type); and in a nutshell, it does: { TypeNode *node = lookup_type_node_I (class->g_type); // O(1) TypeNode *iface = lookup_type_node_I (iface_type); // O(1) IFaceEntry *entry = type_lookup_iface_entry_L (node, iface); // O(ld(N)) return entry->vtable; } take a look at gtype.c and type_lookup_iface_entry_L() to confirm. using a binary lookup in type_lookup_iface_entry_L() means, lookups in terms of number of interfaces and node visits during the search relate like this: interfaces-per-node | visits-per-lookup 1 | 1.0 2 | 2.0 3 | 2.6 4 | 3.0 5 | 3.3 6 | 3.6 8 | 4.0 16 | 5.0 32 | 6.0 64 | 7.0 128 | 8.0 256 | 9.0 512 | 10.0 1024 | 11.0 65536 | 17.0 262144 | 19.0 1048576 | 21.0 67108864 | 27.0 268435456 | 29.0 2147483648 | 32.0 that is, for all practical purposes, interface lookups are negligible even for many thausands of interfaces implemented per node. and now, please show me the OO system that gets into the hundreds at least... > Cheers, > -Tristan --- ciaoTJ From nicola@effe-gi.it Wed Jun 14 13:42:30 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id D182C3B0003 for ; Wed, 14 Jun 2006 13:42:30 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20727-04 for ; Wed, 14 Jun 2006 13:42:29 -0400 (EDT) Received: from mailout01.albacom.net (mailout01.albacom.net [217.220.34.13]) by menubar.gnome.org (Postfix) with SMTP id 968DC3B0081 for ; Wed, 14 Jun 2006 13:42:28 -0400 (EDT) Received: (qmail 15057 invoked by uid 508); 14 Jun 2006 17:41:43 -0000 Received: from nicola@effe-gi.it by mailout01.albacom.net with qmail-scanner (spamassassin: ???. Clear:RC:1(217.221.76.9):SA:0(0.0/15.0):. Processed in 2.56365 secs); 14 Jun 2006 17:41:43 -0000 Received: from unknown (HELO sviluppo.internet.local) (postmaster@effe-gi.it@217.221.76.9) by mailout01.albacom.net with SMTP; 14 Jun 2006 17:41:40 -0000 From: Fontana Nicola Organization: Elettronica EFFE-GI s.n.c. To: gtk-devel-list@gnome.org Subject: GObject extension propose (GContainer) Date: Wed, 14 Jun 2006 20:17:53 +0000 User-Agent: KMail/1.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200606142017.53525.nicola@effe-gi.it> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.599 tagged_above=-999 required=2 tests=[BAYES_00=-2.599] X-Spam-Score: -2.599 X-Spam-Level: X-Mailman-Approved-At: Sun, 18 Jun 2006 10:56:05 -0400 X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2006 17:42:31 -0000 Hi all, I'm a GObject based libraries (for UI purpose and not) user and I often need a generic container to derive my own types. In my opinion, I think this generic container must be included inside the GObject library ... it could be used by a lot of derived libraries providing a common approach. I published my solution - that is, what I am currently using - on sourceforge. http://sourceforge.net/projects/gcontainer/ Is it a good idea? Is something planned in this direction? Am I totally wrong? I need feedbacks ... Nicola From tristan.van.berkom@gmail.com Sun Jun 18 12:43:27 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 15A9A3B0BF9 for ; Sun, 18 Jun 2006 12:43:27 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03626-01 for ; Sun, 18 Jun 2006 12:43:26 -0400 (EDT) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.225]) by menubar.gnome.org (Postfix) with ESMTP id 1D9F83B0C2D for ; Sun, 18 Jun 2006 12:43:26 -0400 (EDT) Received: by wr-out-0506.google.com with SMTP id 37so824607wra for ; Sun, 18 Jun 2006 09:42:28 -0700 (PDT) Received: by 10.54.153.8 with SMTP id a8mr5030935wre; Sun, 18 Jun 2006 09:42:28 -0700 (PDT) Received: from ?66.48.170.160? ( [66.48.170.160]) by mx.gmail.com with ESMTP id 25sm98918wra.2006.06.18.09.42.26; Sun, 18 Jun 2006 09:42:27 -0700 (PDT) Message-ID: <44958664.4050704@gmail.com> Date: Sun, 18 Jun 2006 12:59:16 -0400 From: Tristan Van Berkom User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Janik Subject: Re: GObject extension propose (GContainer) References: <200606151101.12868.ntd@users.sourceforge.net> <44919246.8060301@gnome.org> <1150456522.5305.12.camel@localhost.localdomain> <1150491686.19405.355.camel@zosma.extratech.com> <44942B5F.2090903@gnome.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.495 tagged_above=-999 required=2 tests=[AWL=-0.351, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=1.456, SPF_PASS=-0.001] X-Spam-Score: -1.495 X-Spam-Level: Cc: Gtk+ Developers X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jun 2006 16:43:27 -0000 Tim Janik wrote: [...] > no there won't be a performance hit. [...] > 268435456 | 29.0 > 2147483648 | 32.0 > > that is, for all practical purposes, interface lookups are negligible > even > for many thausands of interfaces implemented per node. > Those stats look great Tim, sorry for any confusion I may have unwillingly caused in this thread, I think its of great importance that people not fear the GInterface. Cheers, -Tristan From jnoreiko@yahoo.com Sun Jun 18 15:19:51 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id E64063B0114 for ; Sun, 18 Jun 2006 15:19:50 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08166-08 for ; Sun, 18 Jun 2006 15:19:48 -0400 (EDT) Received: from web32405.mail.mud.yahoo.com (web32405.mail.mud.yahoo.com [68.142.207.198]) by menubar.gnome.org (Postfix) with SMTP id 24E153B00E5 for ; Sun, 18 Jun 2006 15:19:47 -0400 (EDT) Received: (qmail 1542 invoked by uid 60001); 18 Jun 2006 19:19:02 -0000 Message-ID: <20060618191902.1540.qmail@web32405.mail.mud.yahoo.com> Received: from [172.213.179.4] by web32405.mail.mud.yahoo.com via HTTP; Sun, 18 Jun 2006 20:19:02 BST Date: Sun, 18 Jun 2006 20:19:02 +0100 (BST) From: Joachim Noreiko Subject: Re: GtkFileChooser/GnomeVFS backend still messing up authentication manager? (was: GTK+ 2.10, the endgame) To: gtk-devel-list@gnome.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.64 tagged_above=-999 required=2 tests=[AWL=-0.688, BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2, DNS_FROM_RFC_WHOIS=1.447] X-Spam-Score: -1.64 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jun 2006 19:19:51 -0000 > Date: Sat, 17 Jun 2006 18:57:54 +0200 > From: Christian Neumair > Subject: GtkFileChooser/GnomeVFS backend still > > Are there other important bugs or regressions that > need > > attention before 2.10 ? Yes! Please could you implement a help button in the filechooser. The documentation is already written and is ready to be linked to. ___________________________________________________________ All new Yahoo! Mail "The new Interface is stunning in its simplicity and ease of use." - PC Magazine http://uk.docs.yahoo.com/nowyoucan.html From alexl@redhat.com Mon Jun 19 05:47:41 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id AB66D3B00A4 for ; Mon, 19 Jun 2006 05:47:41 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02513-02 for ; Mon, 19 Jun 2006 05:47:40 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id 4A6763B0014 for ; Mon, 19 Jun 2006 05:47:40 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5J9Aqqj029011; Mon, 19 Jun 2006 05:10:52 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5J9AqpA029834; Mon, 19 Jun 2006 05:10:52 -0400 Received: from [127.0.0.1] (sebastian-int.corp.redhat.com [172.16.52.221]) by devserv.devel.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5J9Ap4k026344; Mon, 19 Jun 2006 05:10:51 -0400 Subject: Re: Printing and blocking ui From: Alexander Larsson To: Yevgen Muntyan In-Reply-To: <4491AF5A.2050702@tamu.edu> References: <4491AF5A.2050702@tamu.edu> Content-Type: text/plain Date: Mon, 19 Jun 2006 11:10:51 +0200 Message-Id: <1150708251.1962.23.camel@greebo> Mime-Version: 1.0 X-Mailer: Evolution 2.7.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.588 tagged_above=-999 required=2 tests=[AWL=0.013, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.588 X-Spam-Level: Cc: GTK Devel List X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2006 09:47:41 -0000 On Thu, 2006-06-15 at 14:04 -0500, Yevgen Muntyan wrote: > Hi there, > > I print a text document from GtkTextView here. There is a problem > with pagination: pagination is potentially slow, so some sort of progress > dialog should be shown during it. From the other hand, the text buffer > must not be modified during pagination. > How to solve it? Should I show my own modal dialog and make sure user > doesn't modify the buffer, or GtkPrintOperation can take care of it? This is supported now with the Gtkprintoperation::paginate signal and gtk_print_operation_set_show_progress(). > Actually, it would be good to ensure printing blocks the text widget too, > since in this case it wouldn't be necessary to calculate and store all > the pango > layouts in begin-print. Maybe just show a modal dialog between begin-print > and end-print. Locking the editing widget is probably something you have to do yourself. You could also do a snapshot of the data at print time. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl@redhat.com alla@lysator.liu.se He's an otherworldly guerilla ex-con with a secret. She's a scantily clad belly-dancing widow who can talk to animals. They fight crime! From muntyan@tamu.edu Mon Jun 19 06:17:07 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 591293B00FB for ; Mon, 19 Jun 2006 06:17:07 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04050-03 for ; Mon, 19 Jun 2006 06:17:05 -0400 (EDT) Received: from smtp101.vzn.mail.mud.yahoo.com (smtp101.vzn.mail.mud.yahoo.com [68.142.203.45]) by menubar.gnome.org (Postfix) with SMTP id 64EE03B00C8 for ; Mon, 19 Jun 2006 06:17:05 -0400 (EDT) Received: (qmail 1322 invoked from network); 19 Jun 2006 10:16:02 -0000 Received: from unknown (HELO ?192.168.3.9?) (muntyan@verizon.net@71.113.224.59 with plain) by smtp101.vzn.mail.mud.yahoo.com with SMTP; 19 Jun 2006 10:16:01 -0000 Message-ID: <44967960.3060609@tamu.edu> Date: Mon, 19 Jun 2006 05:16:00 -0500 From: Yevgen Muntyan User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20060216 Debian/1.7.12-1.1ubuntu2 X-Accept-Language: en MIME-Version: 1.0 To: Alexander Larsson Subject: Re: Printing and blocking ui References: <4491AF5A.2050702@tamu.edu> <1150708251.1962.23.camel@greebo> In-Reply-To: <1150708251.1962.23.camel@greebo> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.553 tagged_above=-999 required=2 tests=[AWL=0.046, BAYES_00=-2.599] X-Spam-Score: -2.553 X-Spam-Level: Cc: GTK Devel List X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2006 10:17:07 -0000 Alexander Larsson wrote: >On Thu, 2006-06-15 at 14:04 -0500, Yevgen Muntyan wrote: > > >>Hi there, >> >>I print a text document from GtkTextView here. There is a problem >>with pagination: pagination is potentially slow, so some sort of progress >>dialog should be shown during it. From the other hand, the text buffer >>must not be modified during pagination. >>How to solve it? Should I show my own modal dialog and make sure user >>doesn't modify the buffer, or GtkPrintOperation can take care of it? >> >> > >This is supported now with the Gtkprintoperation::paginate signal and >gtk_print_operation_set_show_progress(). > > I don't know how paginate works, but the dialog which shows up during printing is not modal, and it appears only after some delay. I can erase text in the buffer between clicking Print button and the time when progress dialog appears. >>Actually, it would be good to ensure printing blocks the text widget too, >>since in this case it wouldn't be necessary to calculate and store all >>the pango >>layouts in begin-print. Maybe just show a modal dialog between begin-print >>and end-print. >> >> > >Locking the editing widget is probably something you have to do >yourself. You could also do a snapshot of the data at print time. > > Well, locking is easy, but I have to tell user about what's happening. So I guess the solution is to have my own modal progress dialog. Regards, Yevgen From mardy@users.sourceforge.net Mon Jun 19 10:20:09 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id B4CCC3B018E for ; Mon, 19 Jun 2006 10:20:09 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14994-07 for ; Mon, 19 Jun 2006 10:20:06 -0400 (EDT) Received: from smtp008.mail.ukl.yahoo.com (smtp008.mail.ukl.yahoo.com [217.12.11.62]) by menubar.gnome.org (Postfix) with SMTP id 190673B0076 for ; Mon, 19 Jun 2006 10:20:05 -0400 (EDT) Received: (qmail 79361 invoked from network); 19 Jun 2006 14:12:00 -0000 Received: from unknown (HELO pupilla) (mardy78@151.38.48.109 with login) by smtp008.mail.ukl.yahoo.com with SMTP; 19 Jun 2006 14:12:00 -0000 Received: by pupilla (Postfix, from userid 1000) id D59DB6B883; Mon, 19 Jun 2006 16:10:17 +0200 (CEST) Date: Mon, 19 Jun 2006 16:10:17 +0200 From: Alberto Mardegan To: gtk-devel-list@gnome.org Subject: GtkLabel as a child of a windowless widget Message-ID: <20060619141017.GA31744@pupilla> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Accept-Language: it,ia,en,bg,es,fr User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.599 tagged_above=-999 required=2 tests=[BAYES_00=-2.599] X-Spam-Score: -2.599 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2006 14:20:09 -0000 Hi all! I'm creating a Widget based on GtkFrame, with little differences: 1) It's not a container 2) It has the GTK_NO_WINDOW flag set. I'm going to use this widget inside a GtkFixed container, with the only goal of having it paint its frame (and draw its label) on the screen. I want it windowless, so that I can insert other widgets which will appear to be inside it, but which will be actually be owned by the GtkFixed. I know this is not really senseful, but I need such a widget for porting lots of applications from Prolific's Panther GUI to Gtk+. The problem I have, is that the frame label isn't drawn. I'm not sure if there are any operation I should do on it... I just create it, and call gtk_widget_set_parent(). On size_allocate, I'm not sure whether the child's x and y members of the size_allocation struct should be relative to (0,0) or to the parent widget's x and y allocation (since the parent is windowless, too). But this won't work in any case... Any hints? I have no clue. -- Saluti, Mardy http://interlingua.altervista.org Chiacchiera con i tuoi amici in tempo reale! http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com From ame1@extratech.com Mon Jun 19 11:13:35 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 1E8293B03A9 for ; Mon, 19 Jun 2006 11:13:35 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16850-05 for ; Mon, 19 Jun 2006 11:13:32 -0400 (EDT) Received: from portal2.extratech.com (portal.extratech.com [67.105.201.210]) by menubar.gnome.org (Postfix) with ESMTP id BF3D93B0076 for ; Mon, 19 Jun 2006 11:13:30 -0400 (EDT) Received: from zosma.extratech.com (zosma.extratech.com [192.168.0.41]) by portal2.extratech.com (8.12.11/8.12.11) with ESMTP id k5JFBMdd004376; Mon, 19 Jun 2006 08:11:22 -0700 Subject: Re: GObject extension propose (GContainer) From: "Alan M. Evans" To: Tristan Van Berkom In-Reply-To: <44942B5F.2090903@gnome.org> References: <200606151101.12868.ntd@users.sourceforge.net> <44919246.8060301@gnome.org> <1150456522.5305.12.camel@localhost.localdomain> <1150491686.19405.355.camel@zosma.extratech.com> <44942B5F.2090903@gnome.org> Content-Type: text/plain Message-Id: <1150729881.19405.420.camel@zosma.extratech.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 19 Jun 2006 08:11:21 -0700 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.86.1/1549/Sat Jun 17 15:20:39 2006 on portal2.extratech.com X-Virus-Status: Clean X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.551 tagged_above=-999 required=2 tests=[AWL=0.048, BAYES_00=-2.599] X-Spam-Score: -2.551 X-Spam-Level: Cc: Gtk+ Developers X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2006 15:13:35 -0000 On Sat, 2006-06-17 at 09:18, Tristan Van Berkom wrote: > Alan M. Evans wrote: > >>the lookup penalties are negligible. > >>type node/class lookups and is_a checks are O(1); > >>interface class lookups and conforms_to checks are O(ld(N)), where > >>N is the number of interfaces a type node conforms to. > > > >Your assertion that the penalties are negligable is not really supported > >by your response, unless the constant is also known for both orders.> > > > From my swift glance at gtype.c, it seems that in the case of > an interface, the implementing interface is searched on that class's > list of implementing interfaces... so when classes implement > hundreds of interfaces it might be a performance hit. My impression from the original question, which I didn't ask, was not so much about access to a large number of members. If a single variable needs to be examined many times then the performance penalty of a generic interface lookup can add up. In any case, I merely observed an assertion, "the lookup penalties are negligible," and the what appeared to be supporting data, the order of the lookups. This doesn't tell us what the penalty is, only that there is a penalty that gets worse as the number of members increases. Maybe the penalty is negligible, but the data presented didn't say so. That's all I was saying. > I dont think we've yet reached the day that we have to ditch good design > and avoid using interfaces because of performance woes, that would > be sorry day indeed... (I also dont think GTK+ code will be the only OO code > needing major refactoring in those areas too... if these interface > lookups weren't negligable) Indeed. I would certainly not advocate dispensing with good design. In fact, I usually advocate the purist design in my own software, and let Moore's Law fix the performance issues. But some cases still call for direct access for essential performance. I, too, would like to know the performance penalty of the generic interface. Being lazy, I suppose I will set up some experiment to discover it pragmatically. From federico@ximian.com Mon Jun 19 13:28:06 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id B62B13B05EF for ; Mon, 19 Jun 2006 13:28:06 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23010-05 for ; Mon, 19 Jun 2006 13:28:05 -0400 (EDT) Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) by menubar.gnome.org (Postfix) with ESMTP id 163BA3B0809 for ; Mon, 19 Jun 2006 13:28:04 -0400 (EDT) Received: (qmail 29558 invoked from network); 19 Jun 2006 17:27:00 -0000 Received: from localhost (HELO 164-99-120-63.boston.ximian.com) (127.0.0.1) by localhost with SMTP; 19 Jun 2006 17:27:00 -0000 Subject: Re: GtkFileChooser/GnomeVFS backend still messing up authentication manager? (was: GTK+ 2.10, the endgame) From: Federico Mena Quintero To: Joachim Noreiko In-Reply-To: <20060618191902.1540.qmail@web32405.mail.mud.yahoo.com> References: <20060618191902.1540.qmail@web32405.mail.mud.yahoo.com> Content-Type: text/plain Date: Mon, 19 Jun 2006 12:22:31 -0500 Message-Id: <1150737751.8452.77.camel@cacharro.xalalinux.org> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.575 tagged_above=-999 required=2 tests=[AWL=0.024, BAYES_00=-2.599] X-Spam-Score: -2.575 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2006 17:28:06 -0000 On Sun, 2006-06-18 at 20:19 +0100, Joachim Noreiko wrote: > Yes! > Please could you implement a help button in the > filechooser. The documentation is already written and > is ready to be linked to. Do we have a mechanism for this? I see that GtkColorSelectionDialog creates a Help button but hides it by default, and it gives GTK_RESPONSE_HELP when pressed. Does that get captured anywhere so that it can take you to the right help page? Federico From tvb@gnome.org Mon Jun 19 14:23:28 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 8657F3B04AC for ; Mon, 19 Jun 2006 14:23:28 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25353-05 for ; Mon, 19 Jun 2006 14:23:26 -0400 (EDT) Received: from mail.touchtunes.com (mail.touchtunes.com [207.96.182.162]) by menubar.gnome.org (Postfix) with ESMTP id 74D063B03C7 for ; Mon, 19 Jun 2006 14:23:26 -0400 (EDT) Received: from [192.168.0.138] (unknown [192.168.0.138]) by mail.touchtunes.com (Postfix) with ESMTP id 1C61615AAA; Mon, 19 Jun 2006 14:22:06 -0400 (EDT) Message-ID: <4496ED9C.3090009@gnome.org> Date: Mon, 19 Jun 2006 14:31:56 -0400 From: Tristan Van Berkom User-Agent: Mozilla Thunderbird 0.8 (X11/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alberto Mardegan Subject: Re: GtkLabel as a child of a windowless widget References: <20060619141017.GA31744@pupilla> In-Reply-To: <20060619141017.GA31744@pupilla> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.517 tagged_above=-999 required=2 tests=[AWL=0.006, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, TW_GT=0.077] X-Spam-Score: -2.517 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2006 18:23:28 -0000 Alberto Mardegan wrote: [...] > > Any hints? I have no clue. This mailing list is for the discussion of GTK+ development itself, for questions related to writing applications in gtk+ please write to gtk-app-devel-list@gnome.org or gtk-list@gnome.org. FYI: Widgets do not overlap in any containers in gtk+ (I've heard that there is z-ordering in gnomecanvas... you might want to check that out). You can: - Draw the frame yourself in the GtkFixed and place a child label where the frames label would be - Add a fixed as the child widget of the frame (probably what you want anyway). Cheers, -Tristan From federico@ximian.com Mon Jun 19 22:53:07 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 955513B044F for ; Mon, 19 Jun 2006 22:53:07 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18923-10 for ; Mon, 19 Jun 2006 22:53:06 -0400 (EDT) Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) by menubar.gnome.org (Postfix) with ESMTP id E23A03B0301 for ; Mon, 19 Jun 2006 22:53:05 -0400 (EDT) Received: (qmail 30485 invoked from network); 20 Jun 2006 02:52:00 -0000 Received: from localhost (HELO 164-99-120-63.boston.ximian.com) (127.0.0.1) by localhost with SMTP; 20 Jun 2006 02:52:00 -0000 Subject: Re: GtkLabel as a child of a windowless widget From: Federico Mena Quintero To: Alberto Mardegan In-Reply-To: <20060619141017.GA31744@pupilla> References: <20060619141017.GA31744@pupilla> Content-Type: text/plain Date: Mon, 19 Jun 2006 21:47:24 -0500 Message-Id: <1150771645.8452.94.camel@cacharro.xalalinux.org> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.575 tagged_above=-999 required=2 tests=[AWL=0.024, BAYES_00=-2.599] X-Spam-Score: -2.575 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2006 02:53:07 -0000 On Mon, 2006-06-19 at 16:10 +0200, Alberto Mardegan wrote: > Hi all! > I'm creating a Widget based on GtkFrame, with little differences: > 1) It's not a container > 2) It has the GTK_NO_WINDOW flag set. > > I'm going to use this widget inside a GtkFixed container, with the only > goal of having it paint its frame (and draw its label) on the screen. > I want it windowless, so that I can insert other widgets which will > appear to be inside it, but which will be actually be owned by the > GtkFixed. First, can you simply use a GtkFrame inside a GtkFixed, and just not put a child inside the frame? > The problem I have, is that the frame label isn't drawn. I'm not sure if > there are any operation I should do on it... I just create it, and call > gtk_widget_set_parent(). > On size_allocate, I'm not sure whether the child's x and y members of > the size_allocation struct should be relative to (0,0) or to the parent > widget's x and y allocation (since the parent is windowless, too). But > this won't work in any case... Allocations are always with respect to the parent window. So if you have a windowed parent, then inside it a no-window container at (10, 20), and a child of that container which is supposed to be offset (3, 4) pixels from the container's top-left corner, then the child's allocation will be at (13, 24). Federico From mclasen@redhat.com Tue Jun 20 09:27:18 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 4C2873B02C2 for ; Tue, 20 Jun 2006 09:27:18 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17744-01 for ; Tue, 20 Jun 2006 09:27:17 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id D5CE13B0184 for ; Tue, 20 Jun 2006 09:27:16 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5KDQgQV017831 for ; Tue, 20 Jun 2006 09:26:42 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5KDQbkk003106 for ; Tue, 20 Jun 2006 09:26:37 -0400 Received: from golem.boston.redhat.com (golem.boston.redhat.com [172.16.80.24]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id k5KDQbdH021200 for ; Tue, 20 Jun 2006 09:26:37 -0400 Subject: GTK+ team meeting From: Matthias Clasen To: gtk-devel-list@gnome.org Content-Type: text/plain Date: Tue, 20 Jun 2006 09:26:36 -0400 Message-Id: <1150809996.15532.50.camel@golem.boston.redhat.com> Mime-Version: 1.0 X-Mailer: Evolution 2.7.1 (2.7.1-1) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.543 tagged_above=-999 required=2 tests=[AWL=0.058, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.543 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2006 13:27:18 -0000 After a few weeks, we should probably have a team meeting today. The meeting is intended for the GTK+ team, but everybody is welcome to come and listen. The meeting logs will be posted on the GTK+ website (http://www.gtk.org/plan/meetings). Place: irc.gnome.org:#gtk-devel Time: 19:30 UTC (15:30 EDT), Tue, Jun 20 Possible agenda items: - GUADEC meeting - 2.10 + when to release + what needs to be on the 2.10 milestone but isn't ? Matthias From mclasen@redhat.com Tue Jun 20 11:22:11 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 3B32C3B043F; Tue, 20 Jun 2006 11:22:11 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22457-09; Tue, 20 Jun 2006 11:22:09 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id 71CF13B00E7; Tue, 20 Jun 2006 11:22:09 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5KFLLnL004523; Tue, 20 Jun 2006 11:21:21 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5KFLLNA016479; Tue, 20 Jun 2006 11:21:21 -0400 Received: from golem.boston.redhat.com (golem.boston.redhat.com [172.16.80.24]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id k5KFLKdH032719; Tue, 20 Jun 2006 11:21:20 -0400 Subject: GLib 2.11.4 released From: Matthias Clasen To: gnome-announce-list@gnome.org, gtk-devel-list@gnome.org, gtk-list@gnome.org, gtk-app-devel-list@gnome.org Content-Type: text/plain Date: Tue, 20 Jun 2006 11:21:20 -0400 Message-Id: <1150816880.15532.58.camel@golem.boston.redhat.com> Mime-Version: 1.0 X-Mailer: Evolution 2.7.1 (2.7.1-1) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.543 tagged_above=-999 required=2 tests=[AWL=0.058, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.543 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: gnome-hackers@gnome.org List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2006 15:22:11 -0000 GLib 2.11.4 is now available for download at: ftp://ftp.gtk.org/pub/gtk/v2.11/ http://ftp.gnome.org/pub/GNOME/sources/glib/2.11/ glib-2.11.4.tar.bz2 md5sum: 9d3a94baa4bfcd9a579b45eea6de3a8c glib-2.11.4.tar.gz md5sum: f7768bc7ed524c6b40cb87daccb6c2b2 This is a development release leading up to GLib 2.12. Notes: * This is unstable development release. While it has had a bit of testing, there are certainly plenty of bugs remaining to be found. This release should not be used in production. * Installing this version will overwrite your existing copy of GLib 2.10. If you have problems, you'll need to reinstall GLib 2.10. * GLib 2.12 will be source and binary compatible with the GLib 2.10.x series (for some caveats, see the README). At this point, the API additions in the 2.11.x series are finished. * Bugs should be reported to http://bugzilla.gnome.org. About GLib ========== GLib is the low-level core library that forms the basis for projects such as GTK+ and GNOME. It provides data structure handling for C, portability wrappers, and interfaces for such runtime functionality as an event loop, threads, dynamic loading, and an object system. More information about GLib is available at: http://www.gtk.org/ An installation guide for the GTK+ libraries, including GLib, can be found at: http://developer.gnome.org/doc/API/2.0/gtk/gtk-building.html Overview of Changes from GLib 2.11.3 to GLib 2.11.4 =================================================== * GBookmarkFile: - g_bookmark_file_remove_item returns a boolean * g_mkstemp accepts the XXXXXX in the middle of the template * Bugs fixed: 344868 g_key_file_to_data should separate groups * Updated translations (de,es,fr,gu,hi,ko,th) A list of all bugs fixed in this release can be found at: http://bugzilla.gnome.org/buglist.cgi?bug_id=344868 Thanks to everybody who has contributed to this release, in the form of bug reports or patches: Emmanuele Bassi, Christian Persch, Federico Mena Quintero Matthias Clasen June 20, 2006 From mgiannakidis@gmail.com Mon Jun 19 08:23:48 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id E62893B0AAF for ; Mon, 19 Jun 2006 08:23:47 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10711-01 for ; Mon, 19 Jun 2006 08:23:44 -0400 (EDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.191]) by menubar.gnome.org (Postfix) with ESMTP id E721A3B089A for ; Mon, 19 Jun 2006 08:23:43 -0400 (EDT) Received: by nf-out-0910.google.com with SMTP id x30so1070652nfb for ; Mon, 19 Jun 2006 05:22:35 -0700 (PDT) Received: by 10.48.14.1 with SMTP id 1mr1206423nfn; Mon, 19 Jun 2006 05:16:27 -0700 (PDT) Received: from ?213.140.137.120? ( [213.140.137.120]) by mx.gmail.com with ESMTP id d2sm4750763nfe.2006.06.19.05.16.26; Mon, 19 Jun 2006 05:16:26 -0700 (PDT) From: Michalis Giannakidis To: gtk-devel-list@gnome.org Subject: Re: gslice allocator: general impresions. Date: Mon, 19 Jun 2006 15:20:48 +0300 User-Agent: KMail/1.8.3 References: <200606151827.45477.mgiannakidis@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200606191520.48220.mgiannakidis@gmail.com> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.526 tagged_above=-999 required=2 tests=[AWL=-0.002, BAYES_00=-2.599, SPF_PASS=-0.001, TW_TX=0.077] X-Spam-Score: -2.526 X-Spam-Level: X-Mailman-Approved-At: Tue, 20 Jun 2006 12:30:13 -0400 X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2006 12:23:48 -0000 Dear Tim > > (I have modified gslice > > to align a chunk to its own size so that I don't have unused memory > > between chunks eg: request 20 and get 24...) > > you mean you've set P2ALIGNMENT to 1 * sizeof(void*) to get better > granularity of the slices? have you left NATIVE_MALLOC_PADDING at > 2*sizeof(void*) at least? (if not, memory fragmentation on some glibc > systems and on all 64bit systems can become etxremely bad). > I didn't change P2ALIGNMENT . I modified SLAB_INDEX to (asize - 1), SLAB_CHUNK_SIZE to (ix + 1) I also modified P2ALIGN to (size) for all occurances of P2ALIGN except for SLAB_INFO_SIZE. I understand that this will create different memory pools for each size I alloc for, but this is accpeted since I only call g_slice_alloc for two sizes. The tweak seem to be OK since I don't get any segfaults. > maybe due to your alignment tweaks. but maybe also because some malloc() > buckets will have even longer lists that way. > The slowdown also occurred without the alignment tweaks. My understanding is that it is a general malloc slowdown that occurres of the many small mallocs done in the application plus the many larger mallocs done by the gslice allocator. I have read the references available in the gslice allocator comments and were very helpful. What I am looking for know is some sort of comparisons in memory usage and speed in applications changing from malloc to gslice. Also, any tweaks in the gslice allocation sizes providing a more responsive malloc would be great! Any suggestions would be very welcome. Thank you very much. Michalis -- Michalis Giannakidis From mclasen@redhat.com Wed Jun 21 09:13:22 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C2BA53B1007 for ; Wed, 21 Jun 2006 09:13:22 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07614-06 for ; Wed, 21 Jun 2006 09:13:21 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id E02C63B0FE5 for ; Wed, 21 Jun 2006 09:13:20 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5LDDKUh027657; Wed, 21 Jun 2006 09:13:20 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5LDDJnE017553; Wed, 21 Jun 2006 09:13:19 -0400 Received: from golem.boston.redhat.com (golem.boston.redhat.com [172.16.80.24]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id k5LDDJdH018065; Wed, 21 Jun 2006 09:13:19 -0400 Subject: Re: Fwd: GTK+ 2.10, the endgame From: Matthias Clasen To: Guillaume Cottenceau In-Reply-To: References: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> Content-Type: text/plain Date: Wed, 21 Jun 2006 09:13:19 -0400 Message-Id: <1150895599.15532.80.camel@golem.boston.redhat.com> Mime-Version: 1.0 X-Mailer: Evolution 2.7.1 (2.7.1-1) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.506 tagged_above=-999 required=2 tests=[AWL=0.018, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, TW_GT=0.077] X-Spam-Score: -2.506 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2006 13:13:23 -0000 On Wed, 2006-06-21 at 08:38 +0200, Guillaume Cottenceau wrote: > Hi Matthias, > > Could you just drop a line on the list about this question? > > Thanks in advance. > > ---------- Forwarded message ---------- > From: Guillaume Cottenceau > Date: Jun 17, 2006 7:22 PM > Subject: Re: GTK+ 2.10, the endgame > To: Matthias Clasen > Cc: gtk-devel-list@gnome.org > > > On 6/15/06, Matthias Clasen wrote: > > Therefore, I want to consider 2.9.3 api frozen, and take a > > Does this mean that > http://developer.gnome.org/doc/API/2.0/gtk/ix07.html (and equivalents > for gdk, pango, atk) is now a fully stable source for bindings which > want to support new features of 2.10? > > -- > Guillaume Cottenceau - http://zarb.org/~gc/ > The online documentation is still at 2.9.2. I hope to find time to update it to 2.9.4 before leaving for GUADEC tomorrow. A small number of API additions turned out to be necessary in the lowlevel printing apis after 2.9.3: gtk_enumerate_printers GTK_PRINT_CAPABILITY_CAN_GENERATE_PS GTK_PRINT_SETTINGS_OUTPUT_FILE_FORMAT GTK_PRINT_SETTINGS_OUTPUT_URI Furthermore, GTK_PRINT_SETTINGS_PRINT_TO_FILE was found to be unused and removed, together with its setter and getter. Matthias From mclasen@redhat.com Wed Jun 21 13:35:58 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id EE5983B046D for ; Wed, 21 Jun 2006 13:35:57 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25325-06 for ; Wed, 21 Jun 2006 13:35:56 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id 7ACFF3B02CE for ; Wed, 21 Jun 2006 13:35:56 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5LHZtpq012200 for ; Wed, 21 Jun 2006 13:35:55 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5LHZthC009595 for ; Wed, 21 Jun 2006 13:35:55 -0400 Received: from golem.boston.redhat.com (golem.boston.redhat.com [172.16.80.24]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id k5LHZtdH019718 for ; Wed, 21 Jun 2006 13:35:55 -0400 Subject: Looking beyond 2.10 From: Matthias Clasen To: gtk-devel-list@gnome.org Content-Type: text/plain Date: Wed, 21 Jun 2006 13:35:55 -0400 Message-Id: <1150911355.15532.100.camel@golem.boston.redhat.com> Mime-Version: 1.0 X-Mailer: Evolution 2.7.1 (2.7.1-1) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.545 tagged_above=-999 required=2 tests=[AWL=0.056, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.545 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2006 17:35:58 -0000 So, with GTK+ 2.10 on the finish line, I tried to make a quick list of things we may want to look at for 2.12, as input to GUADEC discussions. Patches almost ready to go in - libglade integration - new tooltips api Stuff that needs more work - introspection - international calendar support Stuff that we need to figure out - canvas - libsexy cherrypicking ? (Of course, bugzilla has an endless supply of feature requests and bugs that one can work on, these are just the things that came to my mind first) Matthias From hfiguiere@teaser.fr Wed Jun 21 15:04:27 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C0B713B00F6 for ; Wed, 21 Jun 2006 15:04:27 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31064-02 for ; Wed, 21 Jun 2006 15:04:19 -0400 (EDT) Received: from xandros.com (smtp1.xandros.com [209.87.238.70]) by menubar.gnome.org (Postfix) with ESMTP id 873C83B02DA for ; Wed, 21 Jun 2006 15:04:14 -0400 (EDT) Received: from [172.16.1.95] (unknown [209.87.238.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by xandros.com (Postfix) with ESMTP id 09337A030 for ; Wed, 21 Jun 2006 15:04:13 -0400 (EDT) Message-ID: <4499982C.1010004@teaser.fr> Date: Wed, 21 Jun 2006 15:04:12 -0400 From: Hubert Figuiere User-Agent: Thunderbird 1.5.0.4 (X11/20060615) MIME-Version: 1.0 To: gtk-devel-list@gnome.org Subject: Re: Looking beyond 2.10 References: <1150911355.15532.100.camel@golem.boston.redhat.com> In-Reply-To: <1150911355.15532.100.camel@golem.boston.redhat.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.542 tagged_above=-999 required=2 tests=[AWL=0.057, BAYES_00=-2.599] X-Spam-Score: -2.542 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2006 19:04:27 -0000 Matthias Clasen wrote: > Stuff that needs more work > > - introspection > - international calendar support Complete MacOS X support? I'm about to pick Qt as a toolkit for a personal project just because of that. Hub From matthias.clasen@gmail.com Wed Jun 21 18:26:02 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id A5B4E3B006C for ; Wed, 21 Jun 2006 18:26:02 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09882-05 for ; Wed, 21 Jun 2006 18:26:01 -0400 (EDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.177]) by menubar.gnome.org (Postfix) with ESMTP id 477AE3B00F8 for ; Wed, 21 Jun 2006 18:26:01 -0400 (EDT) Received: by py-out-1112.google.com with SMTP id e30so107107pya for ; Wed, 21 Jun 2006 15:26:00 -0700 (PDT) Received: by 10.35.111.14 with SMTP id o14mr363031pym; Wed, 21 Jun 2006 15:26:00 -0700 (PDT) Received: by 10.35.39.16 with HTTP; Wed, 21 Jun 2006 15:26:00 -0700 (PDT) Message-ID: Date: Wed, 21 Jun 2006 18:26:00 -0400 From: "Matthias Clasen" To: "Hubert Figuiere" Subject: Re: Looking beyond 2.10 In-Reply-To: <4499982C.1010004@teaser.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1150911355.15532.100.camel@golem.boston.redhat.com> <4499982C.1010004@teaser.fr> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.51 tagged_above=-999 required=2 tests=[AWL=0.090, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.51 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2006 22:26:02 -0000 On 6/21/06, Hubert Figuiere wrote: > Matthias Clasen wrote: > > > Stuff that needs more work > > > > - introspection > > - international calendar support > > Complete MacOS X support? Sure, if someone with access to a Mac works on it. I don't have a Mac... > I'm about to pick Qt as a toolkit for a personal project just because of > that. Good luck. Matthias From trowbrds@gmail.com Wed Jun 21 18:29:52 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 103073B0011 for ; Wed, 21 Jun 2006 18:29:52 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10124-04 for ; Wed, 21 Jun 2006 18:29:49 -0400 (EDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.185]) by menubar.gnome.org (Postfix) with ESMTP id B842D3B00E4 for ; Wed, 21 Jun 2006 18:29:48 -0400 (EDT) Received: by nf-out-0910.google.com with SMTP id h2so177759nfe for ; Wed, 21 Jun 2006 15:29:47 -0700 (PDT) Received: by 10.49.81.12 with SMTP id i12mr1011269nfl; Wed, 21 Jun 2006 15:29:47 -0700 (PDT) Received: by 10.49.36.8 with HTTP; Wed, 21 Jun 2006 15:29:47 -0700 (PDT) Message-ID: Date: Wed, 21 Jun 2006 16:29:47 -0600 From: "David Trowbridge" To: gtk-devel-list@gnome.org Subject: Re: Looking beyond 2.10 In-Reply-To: <1150911355.15532.100.camel@golem.boston.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1150911355.15532.100.camel@golem.boston.redhat.com> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.538 tagged_above=-999 required=2 tests=[AWL=0.062, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.538 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2006 22:29:52 -0000 On 6/21/06, Matthias Clasen wrote: > - libsexy cherrypicking ? The icon entry and url labels are probably robust enough (and widely useful enough) to go in. For anything else, it will require some work. -David From mclasen@redhat.com Wed Jun 21 23:10:41 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id AA4213B0172; Wed, 21 Jun 2006 23:10:41 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23030-07; Wed, 21 Jun 2006 23:10:39 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id 63BA23B0008; Wed, 21 Jun 2006 23:10:39 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5M3AclX021506; Wed, 21 Jun 2006 23:10:38 -0400 Received: from lacrosse.corp.redhat.com (lacrosse.corp.redhat.com [172.16.52.154]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5M3AcnM019751; Wed, 21 Jun 2006 23:10:38 -0400 Received: from [172.16.83.158] (vpn83-158.boston.redhat.com [172.16.83.158]) by lacrosse.corp.redhat.com (8.12.11.20060308/8.11.6) with ESMTP id k5M3AciB004961; Wed, 21 Jun 2006 23:10:38 -0400 Subject: GTK+ 2.9.4 released From: Matthias Clasen To: gnome-announce-list@gnome.org, gtk-devel-list@gnome.org, gtk-app-devel-list@gnome.org, gtk-list@gnome.org Content-Type: text/plain Organization: Red Hat Date: Wed, 21 Jun 2006 23:12:41 -0400 Message-Id: <1150945961.4457.2.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.7.3 (2.7.3-2) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.507 tagged_above=-999 required=2 tests=[AWL=0.017, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, TW_GT=0.077] X-Spam-Score: -2.507 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: gnome-hackers@gnome.org List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 03:10:42 -0000 GTK+ 2.9.4 is now available for download at: http://ftp.gnome.org/pub/gnome/sources/gtk+/2.9/ gtk+-2.9.4.tar.bz2 md5sum: c06cf2cfa66485600d90789c9e58f27c gtk+-2.9.4.tar.gz md5sum: e3fefedc7f1a89b66c71c9967168a857 This is a development release leading up to GTK+ 2.10. Notes: * This is unstable development release. There are certainly plenty of bugs remaining to be found. This release should not be used in production. * Installing this version will overwrite your existing copy of GTK+ 2.8. If you have problems, you'll need to reinstall GTK+ 2.8. * GTK+ 2.10 will be source compatible with the GTK+ 2.8 series; the new API additions in GTK+ 2.9.0 are finalized by now. * The ABI version has been bumped from 2.4.0 to 2.10.0, since the filechooser backend interface has been changed. Third-party filechooser backends need to be ported to the new interface. Other third-party modules (input methods, image loaders, etc) just need to be reinstalled in the proper location for GTK+ to find them. * Remaining issues for GTK+ 2.10 can be found with following bugzilla query: http://bugzilla.gnome.org/buglist.cgi?product=gtk%2b&target_milestone=2.10+API+Freeze&target_milestone=2.10+Freeze&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED * Bugs should be reported to http://bugzilla.gnome.org. What is GTK+ ============ GTK+ is a multi-platform toolkit for creating graphical user interfaces. Offering a complete set of widgets, GTK+ is suitable for projects ranging from small one-off tools to complete application suites. GTK+ has been designed from the ground up to support a range of languages, not only C/C++. Using GTK+ from languages such as Perl and Python (especially in combination with the Glade GUI builder) provides an effective method of rapid application development. GTK+ is free software and part of the GNU Project. However, the licensing terms for GTK+, the GNU LGPL, allow it to be used by all developers, including those developing proprietary software, without any license fees or royalties. Where to get more information about GTK+ ======================================== Information about GTK+ including links to documentation can be found at: http://www.gtk.org/ An installation guide for GTK+ 2.x is found at: http://developer.gnome.org/doc/API/2.4/gtk/gtk-building.html Common questions: http://developer.gnome.org/doc/API/2.4/gtk/gtk-question-index.html http://www.gtk.org/faq/ Overview of Changes from GTK+ 2.9.3 to 2.9.4 ============================================ * GtkPrintOperation: - UI improvements in the print dialog - Make printing work without a display connection - Replace "Print to PDF" by "Print to file" that can generate PDF or PostScript - Add a function to the low-level API to enumerate all printers * GtkNotebook tab DND has been improved * GtkProgressbar supports text in activity mode * GtkLabel allows to set the wrap mode * GtkStatusIcon supports transparency * Bugs fixed: 344850 Dragging a GtkTreeViewColumn segfaults when using certain GtkTreeViewColumnDropFunc 342458 Stock menu items without icons are broken in recent GTK+ releases. 335873 notebook DND + popup windows 337882 gtk_progress_bar_set_text() does nothing in activity mode 339456 unix print dialogue help button bug 339702 Make sure printing works without a display 341571 tabs too easily reordered 344074 New Feature: get printer list, and get default print 344743 gtk_targets_include_text() should initialize atoms 344838 Allow func to be NULL in gtk_tree_view_set_search_position_func 344891 GtkPrintOperationPreview signal defs correction 345008 Need updated cairo req 345093 print preview temp file issues 345107 Memory leak in gtk_entry_completion_finalize: User data not freed 345194 gdk_window_set_functions() docs need to be updated 345456 grid-lines property is wrongly registered and get/set. 314278 strings in gtk-update-icon-cache are not marked for translation 344707 size group with widgets in hidden container 344897 Entry completion model NULL handling should be documented 345038 gtk_print_job_set_status' status 345106 dialog button box spacings 345176 GtkIconView doc about drag and drop 345275 doc imporovements for gtk_window_move 345320 Two very similiar strings should be made equal 345321 Add meaning of "shortcut" as translator comment 320034 transparency gtkstatusicon 339592 Add print-to-postscript 344867 custom paper file could use keyfile * Updated translations (cs,de,es,fr,gl,gu,hi,ko,ta,th) A list of all bugs fixed in this release can be found at http://bugzilla.gnome.org/buglist.cgi?bug_id=344838,344743,344867,344891,345008,341571,345038,337882,345093,344707,339456,345107,345275,339702,344074,345320,345321,344897,314278,320034,344850,345194,345176,345106,335873,342458,339592,345456 Thanks to everybody who has contributed to this release, in the form of bug reports or patches: Christian Persch, John Finlay, Federico Mena Quintero, Michael Emmel, Marko Anastasov, Bastien Nocera, Carlos Garnacho, Yevgen Muntyan, Tommi Komulainen, Tim Janik, Christian Weiske, Behdad Esfahbod, Alexander Larsson, Felipe Heidrich, Hendrik Richter, Claudio Saavedra, Dan Winship, Callum McKenzie, John Palmieri, Murray Cumming, Kristian Rietveld June 21, 2006 Matthias Clasen From alexl@redhat.com Thu Jun 22 03:30:13 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id F02D73B04C8 for ; Thu, 22 Jun 2006 03:30:12 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04379-10 for ; Thu, 22 Jun 2006 03:30:11 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id 3177C3B021B for ; Thu, 22 Jun 2006 03:30:11 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5M7UAw1025719 for ; Thu, 22 Jun 2006 03:30:10 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5M7UAI5026706; Thu, 22 Jun 2006 03:30:10 -0400 Received: from [127.0.0.1] (sebastian-int.corp.redhat.com [172.16.52.221]) by devserv.devel.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5M7U90l029917; Thu, 22 Jun 2006 03:30:09 -0400 Subject: Re: Looking beyond 2.10 From: Alexander Larsson To: Matthias Clasen In-Reply-To: <1150911355.15532.100.camel@golem.boston.redhat.com> References: <1150911355.15532.100.camel@golem.boston.redhat.com> Content-Type: text/plain Date: Thu, 22 Jun 2006 09:30:09 +0200 Message-Id: <1150961409.16397.101.camel@greebo> Mime-Version: 1.0 X-Mailer: Evolution 2.7.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.588 tagged_above=-999 required=2 tests=[AWL=0.013, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.588 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 07:30:13 -0000 On Wed, 2006-06-21 at 13:35 -0400, Matthias Clasen wrote: > So, with GTK+ 2.10 on the finish line, I tried to make a quick > list of things we may want to look at for 2.12, as input to > GUADEC discussions. The EditableLable stuff would be nice to have in gtk+: http://live.gnome.org/ProjectRidley/EelEditableLabel This would mean i could drop EelEditableLabel, and i'm sure others need something like this too. For instance, GtkIconView would need it to support renaming. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl@redhat.com alla@lysator.liu.se He's a lonely hunchbacked matador on the edge. She's a radical impetuous single mother who don't take no shit from nobody. They fight crime! From mclasen@redhat.com Thu Jun 22 09:23:37 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 8880D3B0667 for ; Thu, 22 Jun 2006 09:23:37 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30015-09 for ; Thu, 22 Jun 2006 09:23:23 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id 58F4B3B03E5 for ; Thu, 22 Jun 2006 09:23:04 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5MDN3ca016505 for ; Thu, 22 Jun 2006 09:23:03 -0400 Received: from lacrosse.corp.redhat.com (lacrosse.corp.redhat.com [172.16.52.154]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5MDN3dV000789; Thu, 22 Jun 2006 09:23:03 -0400 Received: from [172.16.83.176] (vpn83-176.boston.redhat.com [172.16.83.176]) by lacrosse.corp.redhat.com (8.12.11.20060308/8.11.6) with ESMTP id k5MDN2MM012188; Thu, 22 Jun 2006 09:23:03 -0400 Subject: Re: Looking beyond 2.10 From: Matthias Clasen To: Alexander Larsson In-Reply-To: <1150961409.16397.101.camel@greebo> References: <1150911355.15532.100.camel@golem.boston.redhat.com> <1150961409.16397.101.camel@greebo> Content-Type: text/plain Organization: Red Hat Date: Thu, 22 Jun 2006 09:25:07 -0400 Message-Id: <1150982707.2966.6.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.7.3 (2.7.3-2) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.546 tagged_above=-999 required=2 tests=[AWL=0.055, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.546 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 13:23:37 -0000 On Thu, 2006-06-22 at 09:30 +0200, Alexander Larsson wrote: > On Wed, 2006-06-21 at 13:35 -0400, Matthias Clasen wrote: > > So, with GTK+ 2.10 on the finish line, I tried to make a quick > > list of things we may want to look at for 2.12, as input to > > GUADEC discussions. > > The EditableLable stuff would be nice to have in gtk+: > http://live.gnome.org/ProjectRidley/EelEditableLabel > > This would mean i could drop EelEditableLabel, and i'm sure others need > something like this too. For instance, GtkIconView would need it to > support renaming. > Not that it would not be useful, but GtkIconView uses cell renderers, and already supports editing... From alexl@redhat.com Thu Jun 22 09:33:59 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 9529C3B0748 for ; Thu, 22 Jun 2006 09:33:59 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30708-06 for ; Thu, 22 Jun 2006 09:33:54 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id B4FBD3B0559 for ; Thu, 22 Jun 2006 09:33:54 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5MDXsaJ021314 for ; Thu, 22 Jun 2006 09:33:54 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5MDXrtU004254; Thu, 22 Jun 2006 09:33:53 -0400 Received: from [127.0.0.1] (sebastian-int.corp.redhat.com [172.16.52.221]) by devserv.devel.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5MDXqt9025805; Thu, 22 Jun 2006 09:33:53 -0400 Subject: Re: Looking beyond 2.10 From: Alexander Larsson To: Matthias Clasen In-Reply-To: <1150982707.2966.6.camel@localhost.localdomain> References: <1150911355.15532.100.camel@golem.boston.redhat.com> <1150961409.16397.101.camel@greebo> <1150982707.2966.6.camel@localhost.localdomain> Content-Type: text/plain Date: Thu, 22 Jun 2006 15:33:52 +0200 Message-Id: <1150983232.16397.107.camel@greebo> Mime-Version: 1.0 X-Mailer: Evolution 2.7.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.588 tagged_above=-999 required=2 tests=[AWL=0.013, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.588 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 13:33:59 -0000 On Thu, 2006-06-22 at 09:25 -0400, Matthias Clasen wrote: > On Thu, 2006-06-22 at 09:30 +0200, Alexander Larsson wrote: > > On Wed, 2006-06-21 at 13:35 -0400, Matthias Clasen wrote: > > > So, with GTK+ 2.10 on the finish line, I tried to make a quick > > > list of things we may want to look at for 2.12, as input to > > > GUADEC discussions. > > > > The EditableLable stuff would be nice to have in gtk+: > > http://live.gnome.org/ProjectRidley/EelEditableLabel > > > > This would mean i could drop EelEditableLabel, and i'm sure others need > > something like this too. For instance, GtkIconView would need it to > > support renaming. > > > > Not that it would not be useful, but GtkIconView uses cell renderers, > and already supports editing... How does that handle labels that are several lines long? =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl@redhat.com alla@lysator.liu.se He's a war-weary moralistic waffle chef with nothing left to lose. She's an orphaned red-headed barmaid looking for love in all the wrong places. They fight crime! From mclasen@redhat.com Thu Jun 22 09:48:21 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 98DD03B04F0 for ; Thu, 22 Jun 2006 09:48:21 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31802-05 for ; Thu, 22 Jun 2006 09:48:20 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id DD2613B00DE for ; Thu, 22 Jun 2006 09:48:19 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5MDmJQS027439 for ; Thu, 22 Jun 2006 09:48:19 -0400 Received: from lacrosse.corp.redhat.com (lacrosse.corp.redhat.com [172.16.52.154]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5MDmJB6008537; Thu, 22 Jun 2006 09:48:19 -0400 Received: from [172.16.83.176] (vpn83-176.boston.redhat.com [172.16.83.176]) by lacrosse.corp.redhat.com (8.12.11.20060308/8.11.6) with ESMTP id k5MDmIjF015592; Thu, 22 Jun 2006 09:48:18 -0400 Subject: Re: Looking beyond 2.10 From: Matthias Clasen To: Alexander Larsson In-Reply-To: <1150983232.16397.107.camel@greebo> References: <1150911355.15532.100.camel@golem.boston.redhat.com> <1150961409.16397.101.camel@greebo> <1150982707.2966.6.camel@localhost.localdomain> <1150983232.16397.107.camel@greebo> Content-Type: text/plain Organization: Red Hat Date: Thu, 22 Jun 2006 09:50:23 -0400 Message-Id: <1150984223.2966.10.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.7.3 (2.7.3-2) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.546 tagged_above=-999 required=2 tests=[AWL=0.055, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.546 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 13:48:21 -0000 On Thu, 2006-06-22 at 15:33 +0200, Alexander Larsson wrote: > On Thu, 2006-06-22 at 09:25 -0400, Matthias Clasen wrote: > > On Thu, 2006-06-22 at 09:30 +0200, Alexander Larsson wrote: > > > On Wed, 2006-06-21 at 13:35 -0400, Matthias Clasen wrote: > > > > So, with GTK+ 2.10 on the finish line, I tried to make a quick > > > > list of things we may want to look at for 2.12, as input to > > > > GUADEC discussions. > > > > > > The EditableLable stuff would be nice to have in gtk+: > > > http://live.gnome.org/ProjectRidley/EelEditableLabel > > > > > > This would mean i could drop EelEditableLabel, and i'm sure others need > > > something like this too. For instance, GtkIconView would need it to > > > support renaming. > > > > > > > Not that it would not be useful, but GtkIconView uses cell renderers, > > and already supports editing... > > How does that handle labels that are several lines long? > As well as the treeview does... eventually we'll have to sit down and add multline to GtkEntry... From alexl@redhat.com Thu Jun 22 09:52:23 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 292473B081B for ; Thu, 22 Jun 2006 09:52:23 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32031-08 for ; Thu, 22 Jun 2006 09:52:21 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id 83E8E3B0811 for ; Thu, 22 Jun 2006 09:52:21 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5MDqKud029180 for ; Thu, 22 Jun 2006 09:52:21 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5MDqFg0009757; Thu, 22 Jun 2006 09:52:15 -0400 Received: from [127.0.0.1] (sebastian-int.corp.redhat.com [172.16.52.221]) by devserv.devel.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5MDqE6x027583; Thu, 22 Jun 2006 09:52:14 -0400 Subject: Re: Looking beyond 2.10 From: Alexander Larsson To: Matthias Clasen In-Reply-To: <1150984223.2966.10.camel@localhost.localdomain> References: <1150911355.15532.100.camel@golem.boston.redhat.com> <1150961409.16397.101.camel@greebo> <1150982707.2966.6.camel@localhost.localdomain> <1150983232.16397.107.camel@greebo> <1150984223.2966.10.camel@localhost.localdomain> Content-Type: text/plain Date: Thu, 22 Jun 2006 15:52:14 +0200 Message-Id: <1150984334.16397.110.camel@greebo> Mime-Version: 1.0 X-Mailer: Evolution 2.7.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.588 tagged_above=-999 required=2 tests=[AWL=0.013, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.588 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 13:52:23 -0000 On Thu, 2006-06-22 at 09:50 -0400, Matthias Clasen wrote: > On Thu, 2006-06-22 at 15:33 +0200, Alexander Larsson wrote: > > > How does that handle labels that are several lines long? > > As well as the treeview does... eventually we'll have to sit down > and add multline to GtkEntry... Thats basically what EelEditableLabel is. I'm not sure its better to combine the two into one than having a separate widget for it. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl@redhat.com alla@lysator.liu.se He's a sword-wielding Catholic gangster fleeing from a secret government programme. She's a beautiful mute snake charmer with the power to bend men's minds. They fight crime! From Bill.Haneman@Sun.COM Thu Jun 22 09:59:01 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id A04A33B06B5 for ; Thu, 22 Jun 2006 09:59:01 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32611-04 for ; Thu, 22 Jun 2006 09:58:59 -0400 (EDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by menubar.gnome.org (Postfix) with ESMTP id EC16D3B0487 for ; Thu, 22 Jun 2006 09:58:52 -0400 (EDT) Received: from phys-gadget-1 ([129.156.85.171]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k5MDwpH2016279 for ; Thu, 22 Jun 2006 07:58:52 -0600 (MDT) Received: from conversion-daemon.gadget-mail1.uk.sun.com by gadget-mail1.uk.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0J1900F01LG3TK@gadget-mail1.uk.sun.com> (original mail from Bill.Haneman@Sun.COM) for gtk-devel-list@gnome.org; Thu, 22 Jun 2006 14:58:51 +0100 (BST) Received: from [192.168.1.120] (vpn-129-150-116-130.UK.Sun.COM [129.150.116.130]) by gadget-mail1.uk.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0J1900AYWLI2KV@gadget-mail1.uk.sun.com> for gtk-devel-list@gnome.org; Thu, 22 Jun 2006 14:58:51 +0100 (BST) Date: Thu, 22 Jun 2006 15:00:03 +0100 From: Bill Haneman Subject: GtkTextBuffer serialization formats: why no "text/plain" ? To: gtk-devel-list@gnome.org Message-id: <1150984802.7100.4.camel@linux.site> MIME-version: 1.0 X-Mailer: Ximian Evolution 1.4.6.338 Content-type: text/plain Content-transfer-encoding: 7BIT X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.538 tagged_above=-999 required=2 tests=[AWL=-0.017, BAYES_00=-2.599, TW_GT=0.077, UNPARSEABLE_RELAY=0.001] X-Spam-Score: -2.538 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 13:59:01 -0000 Hi; The new serialize/deserialize API for GtkTextBuffer looks to be very useful to accessibility among other things. I am currently using it to implement AtkStreamableContent, an interface which allows objects with streamable backing data (for instance images, HTML widgets, text containers...) to advertise that fact and stream the data to remote clients such as assistive technologies. However I am somewhat surprised to see in gtk-demo's Hypertext widget that, although there's a serialization format called "application/x-gtk-rich-text", there's no "text/plain". Of course serialization via plain text would not be lossless, but why isn't there a plain text serialization available for all GtkTextBuffer instances? We certainly need it for the accessibility case - otherwise we'll have to fake one in gail, necessitating multiple code paths or at least some odd concatenation of "text/plain" if it is not among those returned by gtk_text_buffer_get_serialize_formats... regards, Bill From ebassi@gmail.com Thu Jun 22 10:02:56 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id D0CCE3B074F for ; Thu, 22 Jun 2006 10:02:56 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00339-10 for ; Thu, 22 Jun 2006 10:02:55 -0400 (EDT) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.171]) by menubar.gnome.org (Postfix) with ESMTP id CC4073B0634 for ; Thu, 22 Jun 2006 10:02:54 -0400 (EDT) Received: by ug-out-1314.google.com with SMTP id o2so482915uge for ; Thu, 22 Jun 2006 07:02:53 -0700 (PDT) Received: by 10.78.151.3 with SMTP id y3mr507751hud; Thu, 22 Jun 2006 07:02:53 -0700 (PDT) Received: from ?192.168.1.70? ( [86.136.65.180]) by mx.gmail.com with ESMTP id 8sm364730hug.2006.06.22.07.02.53; Thu, 22 Jun 2006 07:02:53 -0700 (PDT) Subject: Re: Looking beyond 2.10 From: Emmanuele Bassi To: gtk-devel-list@gnome.org In-Reply-To: <1150911355.15532.100.camel@golem.boston.redhat.com> References: <1150911355.15532.100.camel@golem.boston.redhat.com> Content-Type: text/plain Date: Thu, 22 Jun 2006 15:02:51 +0100 Message-Id: <1150984971.5346.12.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.362 tagged_above=-999 required=2 tests=[AWL=0.238, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.362 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 14:02:57 -0000 Hi; On Wed, 2006-06-21 at 13:35 -0400, Matthias Clasen wrote: > So, with GTK+ 2.10 on the finish line, I tried to make a quick > list of things we may want to look at for 2.12, as input to > GUADEC discussions. > Stuff that needs more work > > - introspection > - international calendar support - use GBookmarkFile inside GtkFileSystem and add recent files inside GtkFileChooser. > Stuff that we need to figure out > > - canvas > - libsexy cherrypicking ? - EggIconChooser. AFAIR there were issues but I can't find any pointer to those. Also, I'd like to see the thumbnailing code added to GTK, and the thumbnail helpers changed from using GConf to a lower level position in the stack. Ciao, Emmanuele. -- Emmanuele Bassi, E: ebassi@gmail.com W: http://www.emmanuelebassi.net B: http://log.emmanuelebassi.net From kris@babi-pangang.org Thu Jun 22 10:07:12 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 9474E3B07EB for ; Thu, 22 Jun 2006 10:07:12 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00887-04 for ; Thu, 22 Jun 2006 10:07:09 -0400 (EDT) Received: from nasi-goreng.babi-pangang.org (nasi-goreng.babi-pangang.org [83.166.137.20]) by menubar.gnome.org (Postfix) with ESMTP id ECDDC3B07F0 for ; Thu, 22 Jun 2006 10:07:08 -0400 (EDT) Received: by nasi-goreng.babi-pangang.org (Postfix, from userid 1000) id 5DB383DCA0; Thu, 22 Jun 2006 16:07:04 +0200 (CEST) Date: Thu, 22 Jun 2006 16:07:04 +0200 From: Kristian Rietveld To: Matthias Clasen Subject: Re: Looking beyond 2.10 Message-ID: <20060622140703.GA15275@babi-pangang.org> References: <1150911355.15532.100.camel@golem.boston.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1150911355.15532.100.camel@golem.boston.redhat.com> User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.565 tagged_above=-999 required=2 tests=[AWL=0.034, BAYES_00=-2.599] X-Spam-Score: -2.565 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 14:07:12 -0000 On Wed, Jun 21, 2006 at 01:35:55PM -0400, Matthias Clasen wrote: > Stuff that needs more work > > - introspection > - international calendar support (I want to try to do multiple row DnD in GtkTreeView for real now. But I won't promise anything :) -kris. From jnoreiko@yahoo.com Thu Jun 22 10:28:15 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id CEBD43B0110 for ; Thu, 22 Jun 2006 10:28:15 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01906-05 for ; Thu, 22 Jun 2006 10:28:15 -0400 (EDT) Received: from web32406.mail.mud.yahoo.com (web32406.mail.mud.yahoo.com [68.142.207.199]) by menubar.gnome.org (Postfix) with SMTP id DCE8B3B0251 for ; Thu, 22 Jun 2006 10:28:14 -0400 (EDT) Received: (qmail 59923 invoked by uid 60001); 22 Jun 2006 14:28:14 -0000 Message-ID: <20060622142814.59921.qmail@web32406.mail.mud.yahoo.com> Received: from [172.203.129.193] by web32406.mail.mud.yahoo.com via HTTP; Thu, 22 Jun 2006 15:28:14 BST Date: Thu, 22 Jun 2006 15:28:14 +0100 (BST) From: Joachim Noreiko Subject: Re: Looking beyond 2.10 To: gtk-devel-list@gnome.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-0.405 tagged_above=-999 required=2 tests=[AWL=-1.612, BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2, DNS_FROM_RFC_WHOIS=1.447, RCVD_IN_SORBS_SOCKS=2.159] X-Spam-Score: -0.405 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 14:28:16 -0000 > Date: Wed, 21 Jun 2006 13:35:55 -0400 > From: Matthias Clasen > Subject: Looking beyond 2.10 > So, with GTK+ 2.10 on the finish line, I tried to > make a quick > list of things we may want to look at for 2.12, as > input to > GUADEC discussions. > > (Of course, bugzilla has an endless supply of > feature requests > and bugs that one can work on, these are just the > things that > came to my mind first) > I feel like I'm talking to myself here, but please could someone look at adding a help button to the fileselector. ___________________________________________________________ Inbox full of spam? Get leading spam protection and 1GB storage with All New Yahoo! Mail. http://uk.docs.yahoo.com/nowyoucan.html From tristan.van.berkom@gmail.com Thu Jun 22 13:10:30 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id A0DBC3B0690 for ; Thu, 22 Jun 2006 13:10:30 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12156-06 for ; Thu, 22 Jun 2006 13:10:28 -0400 (EDT) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.225]) by menubar.gnome.org (Postfix) with ESMTP id 215163B0137 for ; Thu, 22 Jun 2006 13:10:28 -0400 (EDT) Received: by wr-out-0506.google.com with SMTP id i12so437125wra for ; Thu, 22 Jun 2006 10:10:27 -0700 (PDT) Received: by 10.54.153.18 with SMTP id a18mr2404093wre; Thu, 22 Jun 2006 10:10:27 -0700 (PDT) Received: from ?66.48.170.242? ( [66.48.170.242]) by mx.gmail.com with ESMTP id 7sm1704382wrl.2006.06.22.10.10.22; Thu, 22 Jun 2006 10:10:27 -0700 (PDT) Message-ID: <449AD300.3030809@gnome.org> Date: Thu, 22 Jun 2006 13:27:28 -0400 User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mclasen@redhat.com Subject: Re: Looking beyond 2.10 References: <1150911355.15532.100.camel@golem.boston.redhat.com> <1150984971.5346.12.camel@localhost> In-Reply-To: <1150984971.5346.12.camel@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit From: Tristan Van Berkom X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.216 tagged_above=-999 required=2 tests=[AWL=0.384, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.216 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 17:10:30 -0000 Emmanuele Bassi wrote: >Hi; > >On Wed, 2006-06-21 at 13:35 -0400, Matthias Clasen wrote: > > >>So, with GTK+ 2.10 on the finish line, I tried to make a quick >>list of things we may want to look at for 2.12, as input to >>GUADEC discussions. >> >> Heh, unfortunately I wont be at GAUDEC to discuss any of this (which I am sure would be a great experience), so I'll do my best from the mailing lists and irc to tag along :) In light of the new Gtk Builder code getting in, I would like to propose that we depricate UIManager completely in favour of the Gtk Builder and provide a unified front for the creation of GObjects parsed from ui descriptions (or whatever the new "glade file" is to be called). My proposals to address issues of UI merging and handling of GtkActions are described in detail in these to emails: http://mail.gnome.org/archives/gtk-devel-list/2006-May/msg00157.html http://mail.gnome.org/archives/gtk-devel-list/2006-May/msg00166.html Please let me know your thoughts on the proposition and design, if accepted; I am sure I can get all this "ui merging/action subscription" stuff working properly inside of one month... hopefully leaving time enough for it to mature before 2.12. Cheers, -Tristan From sven@gimp.org Thu Jun 22 14:23:14 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C09883B062A for ; Thu, 22 Jun 2006 14:23:14 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16777-05 for ; Thu, 22 Jun 2006 14:23:11 -0400 (EDT) Received: from buzzloop.caiaq.de (buzzloop.caiaq.de [212.112.241.133]) by menubar.gnome.org (Postfix) with ESMTP id 26D1A3B05BF for ; Thu, 22 Jun 2006 14:23:08 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by buzzloop.caiaq.de (Postfix) with ESMTP id 194427F402E; Thu, 22 Jun 2006 20:23:10 +0200 (CEST) Received: from buzzloop.caiaq.de ([127.0.0.1]) by localhost (buzzloop [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11007-03; Thu, 22 Jun 2006 20:23:09 +0200 (CEST) Received: from [192.168.3.158] (i577B6734.versanet.de [87.123.103.52]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by buzzloop.caiaq.de (Postfix) with ESMTP id A11AD7F4024; Thu, 22 Jun 2006 20:23:09 +0200 (CEST) Subject: Re: Looking beyond 2.10 From: Sven Neumann To: Joachim Noreiko In-Reply-To: <20060622142814.59921.qmail@web32406.mail.mud.yahoo.com> References: <20060622142814.59921.qmail@web32406.mail.mud.yahoo.com> Content-Type: text/plain Date: Thu, 22 Jun 2006 20:22:49 +0200 Message-Id: <1151000569.12681.22.camel@bender> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.692 tagged_above=-999 required=2 tests=[AWL=0.907, BAYES_00=-2.599] X-Spam-Score: -1.692 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 18:23:15 -0000 Hi, On Thu, 2006-06-22 at 15:28 +0100, Joachim Noreiko wrote: > I feel like I'm talking to myself here, but please > could someone look at adding a help button to the fileselector. GIMP has done that for quite a while already, so there's nothing that would keep an application from adding a Help button to the file-chooser. What's the point of adding one by default? By default it won't be connected to anything useful and what good is a help button that does nothing when the user clicks it? Sven From murrayc@murrayc.com Thu Jun 22 14:45:17 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 2C2CB3B0649 for ; Thu, 22 Jun 2006 14:45:17 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18110-06 for ; Thu, 22 Jun 2006 14:45:13 -0400 (EDT) Received: from swarthymail-a1.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by menubar.gnome.org (Postfix) with ESMTP id A79253B083A for ; Thu, 22 Jun 2006 14:45:12 -0400 (EDT) Received: from noname (p5497EA12.dip.t-dialin.net [84.151.234.18]) by swarthymail-a1.dreamhost.com (Postfix) with ESMTP id 71BF690FA6; Thu, 22 Jun 2006 11:45:00 -0700 (PDT) Subject: Re: GTK+ 2.10, the endgame From: Murray Cumming To: Emmanuele Bassi In-Reply-To: <1150502750.2668.12.camel@localhost> References: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> <1150390229.17566.191.camel@cacharro.xalalinux.org> <1150391737.3187.33.camel@dhcp83-98.boston.redhat.com> <1150447930.5806.4.camel@localhost.localdomain> <1150502750.2668.12.camel@localhost> Content-Type: text/plain Date: Thu, 22 Jun 2006 20:44:54 +0200 Message-Id: <1151001894.5804.33.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.477 tagged_above=-999 required=2 tests=[AWL=0.122, BAYES_00=-2.599] X-Spam-Score: -2.477 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 18:45:17 -0000 On Sat, 2006-06-17 at 01:05 +0100, Emmanuele Bassi wrote: > Hi Murray, > > On Fri, 2006-06-16 at 10:52 +0200, Murray Cumming wrote: > > I'm also concerned about the recent files stuff. Do we now have > > UIManager integration of that? > > No, and I am to blame because I had less time to spend on fixing this > issue. > > Mostly, I've been stuck on how to implement an action for both the menu > and toolbars using the same tag. In the meantime, a nice and clean way > to integrate the GtkRecentChooserMenu inside a GtkUIManager is to > subclass GtkAction into a custom action that automatically adds a recent > chooser menu to the menu item it creates, and use a placeholder in the > UI definition (most applications using EggRecentViewUIManager already > have that placeholder present). > > A working example is available here: > > http://www.gnome.org/~ebassi/test-uimanager.c > > The action code itself is one hundred lines long and can easily be > hidden inside an helper file; it's approximately how GtkRecentAction > would be implemented, anyway. I hereby give permission to do whatever > you want to do with it. > > I understand that it's sub-optimal, and hopefully this should really go > away once there's an action inside GTK. Do you feel that the existing API might need to be changed to add this to a future version of GTK+? For instance, would it need need existing classes to implement new interfaces, or add new signals? -- Murray Cumming murrayc@murrayc.com www.murrayc.com www.openismus.com From ebassi@gmail.com Thu Jun 22 15:19:39 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id F26233B077F for ; Thu, 22 Jun 2006 15:19:38 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20426-04 for ; Thu, 22 Jun 2006 15:19:35 -0400 (EDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.186]) by menubar.gnome.org (Postfix) with ESMTP id 2A7653B062A for ; Thu, 22 Jun 2006 15:19:35 -0400 (EDT) Received: by nf-out-0910.google.com with SMTP id h2so304101nfe for ; Thu, 22 Jun 2006 12:19:34 -0700 (PDT) Received: by 10.48.242.3 with SMTP id p3mr1697803nfh; Thu, 22 Jun 2006 12:19:34 -0700 (PDT) Received: from ?192.168.1.70? ( [86.136.65.180]) by mx.gmail.com with ESMTP id z73sm2097413nfb.2006.06.22.12.19.33; Thu, 22 Jun 2006 12:19:33 -0700 (PDT) Subject: Re: GTK+ 2.10, the endgame From: Emmanuele Bassi To: Murray Cumming In-Reply-To: <1151001894.5804.33.camel@localhost.localdomain> References: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> <1150390229.17566.191.camel@cacharro.xalalinux.org> <1150391737.3187.33.camel@dhcp83-98.boston.redhat.com> <1150447930.5806.4.camel@localhost.localdomain> <1150502750.2668.12.camel@localhost> <1151001894.5804.33.camel@localhost.localdomain> Content-Type: text/plain Date: Thu, 22 Jun 2006 20:19:32 +0100 Message-Id: <1151003972.5346.29.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.371 tagged_above=-999 required=2 tests=[AWL=0.229, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.371 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 19:19:39 -0000 Hi Murray; On Thu, 2006-06-22 at 20:44 +0200, Murray Cumming wrote: > > The action code itself is one hundred lines long and can easily be > > hidden inside an helper file; it's approximately how GtkRecentAction > > would be implemented, anyway. I hereby give permission to do whatever > > you want to do with it. > > > > I understand that it's sub-optimal, and hopefully this should really go > > away once there's an action inside GTK. > > Do you feel that the existing API might need to be changed to add this > to a future version of GTK+? For instance, would it need need existing > classes to implement new interfaces, or add new signals? The point is: I don't know. :-) The currently unresolved issue is that I can't find a way to use this UI definition:

which is the "right" way to offer a submenu and a menu inside a toolbar item. The only case where I know for sure would require adding API is the case where you want an inlined recent files list - as it would require the ability to create a list of menu items instead of a single widget with the same GtkAction. At this point, I'd like a UIManager author/guru to step in and see if I'm doing something wrong. The bug is #338843 [1]. +++ http://bugzilla.gnome.org/show_bug.cgi?id=338843 -- Emmanuele Bassi, E: ebassi@gmail.com W: http://www.emmanuelebassi.net B: http://log.emmanuelebassi.net From jnoreiko@yahoo.com Thu Jun 22 17:19:57 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 48DC33B07DC for ; Thu, 22 Jun 2006 17:19:57 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27254-05 for ; Thu, 22 Jun 2006 17:19:56 -0400 (EDT) Received: from web32404.mail.mud.yahoo.com (web32404.mail.mud.yahoo.com [68.142.207.197]) by menubar.gnome.org (Postfix) with SMTP id 6C40C3B0601 for ; Thu, 22 Jun 2006 17:19:56 -0400 (EDT) Received: (qmail 9697 invoked by uid 60001); 22 Jun 2006 21:19:55 -0000 Message-ID: <20060622211955.9695.qmail@web32404.mail.mud.yahoo.com> Received: from [172.216.98.138] by web32404.mail.mud.yahoo.com via HTTP; Thu, 22 Jun 2006 22:19:55 BST Date: Thu, 22 Jun 2006 22:19:55 +0100 (BST) From: Joachim Noreiko Subject: Re: Looking beyond 2.10 To: Sven Neumann In-Reply-To: <1151000569.12681.22.camel@bender> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.693 tagged_above=-999 required=2 tests=[AWL=-0.741, BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2, DNS_FROM_RFC_WHOIS=1.447] X-Spam-Score: -1.693 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 21:19:57 -0000 --- Sven Neumann wrote: > Hi, > > On Thu, 2006-06-22 at 15:28 +0100, Joachim Noreiko > wrote: > > > I feel like I'm talking to myself here, but please > > could someone look at adding a help button to the > fileselector. > > GIMP has done that for quite a while already, so > there's nothing that > would keep an application from adding a Help button > to the file-chooser. > What's the point of adding one by default? By > default it won't be > connected to anything useful and what good is a help > button that does > nothing when the user clicks it? The documentation for the fileselector has been in the GNOME Desktop User Guide since 2.14. I'm sure I posted on this list when I wrote it. ___________________________________________________________ All new Yahoo! Mail "The new Interface is stunning in its simplicity and ease of use." - PC Magazine http://uk.docs.yahoo.com/nowyoucan.html From scott@asofyet.org Thu Jun 22 22:52:08 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 046A73B05F9 for ; Thu, 22 Jun 2006 22:52:08 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09189-02 for ; Thu, 22 Jun 2006 22:52:06 -0400 (EDT) Received: from looneymail-a2.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by menubar.gnome.org (Postfix) with ESMTP id 39B703B071C for ; Thu, 22 Jun 2006 22:52:06 -0400 (EDT) Received: from [192.168.0.100] (unknown [74.131.115.107]) by looneymail-a2.dreamhost.com (Postfix) with ESMTP id 2C0F016E8CD for ; Thu, 22 Jun 2006 19:52:05 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v750) In-Reply-To: <20060622211955.9695.qmail@web32404.mail.mud.yahoo.com> References: <20060622211955.9695.qmail@web32404.mail.mud.yahoo.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: muppet Subject: Re: Looking beyond 2.10 Date: Thu, 22 Jun 2006 22:51:48 -0400 To: GTK+ development mailing list X-Mailer: Apple Mail (2.750) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.558 tagged_above=-999 required=2 tests=[AWL=0.041, BAYES_00=-2.599] X-Spam-Score: -2.558 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2006 02:52:08 -0000 On Jun 22, 2006, at 5:19 PM, Joachim Noreiko wrote: > > --- Sven Neumann wrote: > >> GIMP has done that for quite a while already, so there's nothing >> that would keep an application from adding a Help button to the >> file-chooser. What's the point of adding one by default? By >> default it won't be connected to anything useful and what good is >> a help button that does nothing when the user clicks it? > > The documentation for the fileselector has been in the GNOME > Desktop User Guide since 2.14. I'm sure I posted on this list when > I wrote it. That doesn't do much good for gtk+ environments that don't involve GNOME. -- Jolt is my co-pilot. -- Slogan on a giant paper airplane hung in Lobby 7 at MIT. http://hacks.mit.edu/ From magnusbe@algonet.se Fri Jun 23 05:33:19 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 0D0353B0591 for ; Fri, 23 Jun 2006 05:33:19 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31880-05 for ; Fri, 23 Jun 2006 05:33:17 -0400 (EDT) Received: from pne-smtpout2-sn2.hy.skanova.net (pne-smtpout2-sn2.hy.skanova.net [81.228.8.164]) by menubar.gnome.org (Postfix) with ESMTP id 294473B041F for ; Fri, 23 Jun 2006 05:33:16 -0400 (EDT) Received: from feathers (83.252.145.175) by pne-smtpout2-sn2.hy.skanova.net (7.2.072.1) (authenticated as u73906364) id 449A811D0002C366 for gtk-devel-list@gnome.org; Fri, 23 Jun 2006 11:33:15 +0200 Date: Fri, 23 Jun 2006 12:31:05 +0200 From: Magnus Bergman To: GTK+ devel list Subject: Problems making loaders for header-less images Message-ID: <20060623123105.1589fed8@feathers> X-Mailer: Sylpheed-Claws 2.3.0 (GTK+ 2.8.16; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.522 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, TW_GD=0.077] X-Spam-Score: -2.522 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2006 09:33:19 -0000 I've made a couple of gdk-pixbuf loaders for formats that cannot be finger printed using a pattern, because they totaly lack some kind of header or that information is located at the end of the file. This has causes me the following problems: * If one loader handles several (similar) formats that cannot be distinguished from each other by looking at the first bytes. Then gdk-pixbuf uses other means to distinguish between them (extension or mime-type) but the information about what the match was based on is unavailable to loader (or am I missing something). Can this be solved is some way (except by making a different loader for each variant)? Example: There is an image format called pi1 (the most common format on the Atari ST). It consists of one word telling about the resolution, the palette and a copy of the screen memory. A variant of the format is called pc1 and has the only difference that the screen memory image is compressed. It is easy to distinguish between them using the extension or by looking at the file size (pi1 has a fixed size of 32066 bytes while pc1 is always smaller). * If a loader doesn't provide any fingerprinting pattern gdk-pixbuf causes a segfault at runtime then trying to load a picture in any format. Is the loader required to provide at least one pattern or is this a bug? * If the only thing that is known about the format is that it starts with one or more zeros, then gdk-pixbuf-query-loaders will refuse to register the loader because it considers the pattern to be empty. This could be avoided to checking the length of the mask field instead to the prefix field. A bug? From gcottenc@gmail.com Fri Jun 23 07:57:54 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id DA1E43B0678 for ; Fri, 23 Jun 2006 07:57:54 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08025-10 for ; Fri, 23 Jun 2006 07:57:53 -0400 (EDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.192]) by menubar.gnome.org (Postfix) with ESMTP id 7D8543B01A4 for ; Fri, 23 Jun 2006 07:57:53 -0400 (EDT) Received: by wx-out-0102.google.com with SMTP id s6so466104wxc for ; Fri, 23 Jun 2006 04:57:53 -0700 (PDT) Received: by 10.70.103.17 with SMTP id a17mr4494204wxc; Fri, 23 Jun 2006 04:57:52 -0700 (PDT) Received: by 10.70.46.6 with HTTP; Fri, 23 Jun 2006 04:57:52 -0700 (PDT) Message-ID: Date: Fri, 23 Jun 2006 13:57:52 +0200 From: "Guillaume Cottenceau" To: "Matthias Clasen" Subject: Re: Fwd: GTK+ 2.10, the endgame In-Reply-To: <1150895599.15532.80.camel@golem.boston.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> <1150895599.15532.80.camel@golem.boston.redhat.com> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.564 tagged_above=-999 required=2 tests=[AWL=0.036, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.564 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2006 11:57:55 -0000 Hi Matthias, > The online documentation is still at 2.9.2. I hope to find time > to update it to 2.9.4 before leaving for GUADEC tomorrow. Please warn us when the online API documentation regarding new symbols is fully freezed for 2.10 so that we can start working on adding the new symbols in bindings. Thanks! -- Guillaume Cottenceau - http://zarb.org/~gc/ From hfiguiere@teaser.fr Fri Jun 23 11:50:42 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 100083B04A7 for ; Fri, 23 Jun 2006 11:50:42 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21632-05 for ; Fri, 23 Jun 2006 11:50:39 -0400 (EDT) Received: from xandros.com (smtp1.xandros.com [209.87.238.70]) by menubar.gnome.org (Postfix) with ESMTP id 83AC63B0907 for ; Fri, 23 Jun 2006 11:50:33 -0400 (EDT) Received: from [172.16.1.95] (unknown [209.87.238.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by xandros.com (Postfix) with ESMTP id 6A6F223033 for ; Fri, 23 Jun 2006 11:50:32 -0400 (EDT) Message-ID: <449C0DC7.60502@teaser.fr> Date: Fri, 23 Jun 2006 11:50:31 -0400 From: Hubert Figuiere User-Agent: Thunderbird 1.5.0.4 (X11/20060615) MIME-Version: 1.0 To: gtk-devel-list@gnome.org Subject: Re: Looking beyond 2.10 References: <20060622142814.59921.qmail@web32406.mail.mud.yahoo.com> <1151000569.12681.22.camel@bender> In-Reply-To: <1151000569.12681.22.camel@bender> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.544 tagged_above=-999 required=2 tests=[AWL=0.055, BAYES_00=-2.599] X-Spam-Score: -2.544 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2006 15:50:42 -0000 Sven Neumann wrote: > GIMP has done that for quite a while already, so there's nothing that > would keep an application from adding a Help button to the file-chooser. > What's the point of adding one by default? By default it won't be > connected to anything useful and what good is a help button that does > nothing when the user clicks it? Why not putting it in only if the signal is connected ? (a signal like "help_requested"). Hub From gjc@inescporto.pt Fri Jun 23 18:23:20 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 9B8D83B0847 for ; Fri, 23 Jun 2006 18:23:20 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08741-04 for ; Fri, 23 Jun 2006 18:23:19 -0400 (EDT) Received: from animal.inescn.pt (animal.inescn.pt [194.117.24.9]) by menubar.gnome.org (Postfix) with ESMTP id AC38C3B0971 for ; Fri, 23 Jun 2006 18:23:18 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by animal.inescn.pt (8.13.6/8.13.6/7) with ESMTP id k5NMNG4Z018417; Fri, 23 Jun 2006 23:23:17 +0100 (WEST) Received: from pong.inescporto.pt (pong.inescn.pt [194.117.26.74]) by animal.inescn.pt (8.13.6/8.13.6/5) with ESMTP id k5NMN5ql018402; Fri, 23 Jun 2006 23:23:05 +0100 (WEST) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by pong.inescporto.pt (Postfix) with ESMTP id 31501155721; Fri, 23 Jun 2006 23:19:37 +0100 (WEST) Subject: Re: Looking beyond 2.10 From: "Gustavo J. A. M. Carneiro" To: Matthias Clasen In-Reply-To: <1150911355.15532.100.camel@golem.boston.redhat.com> References: <1150911355.15532.100.camel@golem.boston.redhat.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-2prtuoBhNnmmz3lcPkNU" Date: Fri, 23 Jun 2006 23:22:59 +0100 Message-Id: <1151101379.5189.5.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 X-Virus-Scanned: by amavisd-new at inescporto.pt X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.428 tagged_above=-999 required=2 tests=[AWL=0.038, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.428 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2006 22:23:20 -0000 --=-2prtuoBhNnmmz3lcPkNU Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Qua, 2006-06-21 =C3=A0s 13:35 -0400, Matthias Clasen escreveu: > So, with GTK+ 2.10 on the finish line, I tried to make a quick > list of things we may want to look at for 2.12, as input to > GUADEC discussions. >=20 > Patches almost ready to go in >=20 > - libglade integration > - new tooltips api >=20 >=20 > Stuff that needs more work >=20 > - introspection I'm willing to do some work in introspection. However, if you say it needs more work then I think you should identify precisely what work needs to be done. I could try guessing, but that usually leads to patches sitting in bugzilla for whole release cycles (e.g. #313268). Regards. --=20 Gustavo J. A. M. Carneiro The universe is always one step beyond logic --=-2prtuoBhNnmmz3lcPkNU Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta =?ISO-8859-1?Q?=E9?= uma parte de mensagem assinada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQBEnGnD2XoHyMdS6TARAk0JAJ95rFWntIs1xJ0hPTYMBwXdg26PgACeJo0x DrkoftT0jbf/hSym/poi0Uo= =WVRK -----END PGP SIGNATURE----- --=-2prtuoBhNnmmz3lcPkNU-- From jnoreiko@yahoo.com Sat Jun 24 03:40:19 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id EBA9B3B00F5 for ; Sat, 24 Jun 2006 03:40:18 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30651-07 for ; Sat, 24 Jun 2006 03:40:17 -0400 (EDT) Received: from web32401.mail.mud.yahoo.com (web32401.mail.mud.yahoo.com [68.142.207.194]) by menubar.gnome.org (Postfix) with SMTP id BD1E03B0194 for ; Sat, 24 Jun 2006 03:40:16 -0400 (EDT) Received: (qmail 229 invoked by uid 60001); 24 Jun 2006 07:40:15 -0000 Message-ID: <20060624074015.227.qmail@web32401.mail.mud.yahoo.com> Received: from [172.212.40.3] by web32401.mail.mud.yahoo.com via HTTP; Sat, 24 Jun 2006 08:40:15 BST Date: Sat, 24 Jun 2006 08:40:15 +0100 (BST) From: Joachim Noreiko Subject: Re: Looking beyond 2.10 To: gtk-devel-list@gnome.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.681 tagged_above=-999 required=2 tests=[AWL=-0.729, BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2, DNS_FROM_RFC_WHOIS=1.447] X-Spam-Score: -1.681 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2006 07:40:19 -0000 Message: 6 Date: Thu, 22 Jun 2006 22:51:48 -0400 From: muppet Subject: Re: Looking beyond 2.10 > The documentation for the fileselector has been in the GNOME > Desktop User Guide since 2.14. I'm sure I posted on this list when > I wrote it. That doesn't do much good for gtk+ environments that don't involve GNOME. -------------- Then figure out some way for it to detect whether it's on GNOME or not, maybe? Dialog boxes used in GNOME required help buttons, especially ones with as many features as the fileselector. Please could somebody look into this? I put a lot of work into writing the docs, and that's not a huge amount of use until it's linked to. ___________________________________________________________ Inbox full of spam? Get leading spam protection and 1GB storage with All New Yahoo! Mail. http://uk.docs.yahoo.com/nowyoucan.html From macfreesoft@free.fr Sat Jun 24 05:56:35 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C31133B02D5 for ; Sat, 24 Jun 2006 05:56:35 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05338-06 for ; Sat, 24 Jun 2006 05:56:33 -0400 (EDT) Received: from smtp010.mail.ukl.yahoo.com (smtp010.mail.ukl.yahoo.com [217.12.11.79]) by menubar.gnome.org (Postfix) with SMTP id 3D48E3B02B2 for ; Sat, 24 Jun 2006 05:56:33 -0400 (EDT) Received: (qmail 6982 invoked from network); 24 Jun 2006 09:56:32 -0000 Received: from unknown (HELO ?192.168.1.10?) (a?gillaizeau@217.66.126.141 with plain) by smtp010.mail.ukl.yahoo.com with SMTP; 24 Jun 2006 09:56:32 -0000 Message-ID: <449D0C4E.504@free.fr> Date: Sat, 24 Jun 2006 11:56:30 +0200 From: Aymeric GILLAIZEAU User-Agent: Thunderbird 1.5 (Macintosh/20051201) MIME-Version: 1.0 To: Easy B Subject: Gtk+.framework snapshot Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.033 tagged_above=-999 required=2 tests=[BAYES_05=-1.11, TW_GT=0.077] X-Spam-Score: -1.033 X-Spam-Level: X-Mailman-Approved-At: Sat, 24 Jun 2006 06:24:14 -0400 Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2006 09:56:36 -0000 > Hi guys > > Well I wasn't that happy with the result I got from the mono scripts > so I pretty much rewrote them. I now install everything into one > framework. I still don't have libtiff and jpeg support though. How is > the best way to make the gtk configure look for libtiff 3.8.2? I saw > that it looks for 3.4. Do I have to patch configure? > > Anyway, who's interested can give my installer a try. It installs the > framework into /Library/Frameworks and Gtk-Demo into /Applications. I > managed to compile one of my small apps by setting PKG_CONFIG_PATH to > /Library/Frameworks/Gtk+.framework/Libraries/pkgconfig/ and > ./configure, make. > > To make an application bundles I use this script: > http://www.easyb.ch/files/bundleApp.sh > > The Installer you can download here: > http://www.easyb.ch/files/Gtk%2B-2.9.1%20Framework%20snapshot.pkg.zip > > Cheers, > Ezra. Why to not use the already built Frameworks used by Scribus ? Instead of having many times the same things, it is present once and used by anyone. The problem with OpenSource is that everyone makes his cooking in his place without never taking consideration in the work others has already done. It could save time, also use less space on the drive, and so save room. http://www.scribus.net/index.php?name=Sections&req=viewarticle&artid=3&page=1 > ome support libraries, which should be moved to /Library/Frameworks : > Qt.framework > Freetype.framework > Fontconfig2.framework > libart.framework > libexpat.framework > libjpeg.framework > liblcms.framework > libpng.framework > libtiff.framework ___________________________________________________________________________ Yahoo! Mail rinvente le mail ! Dcouvrez le nouveau Yahoo! Mail et son interface rvolutionnaire. http://fr.mail.yahoo.com From alex@halogen-dg.com Sat Jun 24 08:41:32 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 92B9B3B013A for ; Sat, 24 Jun 2006 08:41:32 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13862-09 for ; Sat, 24 Jun 2006 08:41:31 -0400 (EDT) Received: from appserver.halogen.kharkov.ua (appserver.halogen.kharkov.ua [217.144.70.65]) by menubar.gnome.org (Postfix) with ESMTP id 256C33B00FB for ; Sat, 24 Jun 2006 08:41:31 -0400 (EDT) Received: (qmail 29949 invoked from network); 24 Jun 2006 15:41:32 +0300 Received: from dom.koval.kharkov.ua (217.144.70.182) by alex.halogen.kharkov.ua with AES256-SHA encrypted SMTP; 24 Jun 2006 15:41:32 +0300 Date: Sat, 24 Jun 2006 15:45:30 +0300 (EEST) From: alex@halogen-dg.com X-X-Sender: alex@dom.koval.kharkov.ua To: gtk-devel-list@gnome.org Subject: gtk file open dialog usability. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-0.858 tagged_above=-999 required=2 tests=[AWL=-0.709, BAYES_05=-1.11, NO_REAL_NAME=0.961] X-Spam-Score: -0.858 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2006 12:41:32 -0000 Anyone except me also disappointed by it? Any way how we can have old file open dialog back? I really find it very frustating and explained why, with some images here: http://www.halogen-dg.com/alex/file_selection_dialog/GtkFileOpenBadUsability -- Alex V. Koval http://www.halogen-dg.com/ http://www.zwarehouse.org/ From gnome-gtk-devel-list@m.gmane.org Sat Jun 24 08:49:58 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id F15263B00A8 for ; Sat, 24 Jun 2006 08:49:57 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14302-05 for ; Sat, 24 Jun 2006 08:49:55 -0400 (EDT) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by menubar.gnome.org (Postfix) with ESMTP id 402703B00FB for ; Sat, 24 Jun 2006 08:49:55 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Fu7a8-0004yS-Mc for gtk-devel-list@gnome.org; Sat, 24 Jun 2006 14:49:48 +0200 Received: from 84.52.165.220 ([84.52.165.220]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 24 Jun 2006 14:49:48 +0200 Received: from jernej.listsonly by 84.52.165.220 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 24 Jun 2006 14:49:48 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gtk-devel-list@gnome.org From: Jernej =?utf-7?Q?Simon+AQ0-i+AQ0-?= Subject: Re: gtk file open dialog usability. Date: Sat, 24 Jun 2006 14:49:37 +0200 Lines: 9 Message-ID: <10umqokepyu8y.10vhe4alqj04.dlg@40tude.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset="utf-7" Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 84.52.165.220 User-Agent: 40tude_Dialog/2.0.15.84 (cfc06cd9.460.419) X-Face: BOCQpf4)pfW>6Ya?'@oBT]=LBF; <6`_r[6pwqLggP!RG:*D)^Fz; O(I'n(FwJ{]5lo>g.H. _,Z:_`nLsfz]]8V'&9OmX)o-bXd?(P|CO=@5}[y\0rH9!AN&Qt:GXC(r!1}$q@@C]x`](7+#C]WRzw L|0W}vdFR/b@AFWIw~ X-Ultimate-Answer: 42 Sender: news X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.008 tagged_above=-999 required=2 tests=[AWL=0.016, BAYES_00=-2.599, FROM_EXCESS_QP=0, RCVD_NUMERIC_HELO=1.5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, TW_GT=0.077] X-Spam-Score: -1.008 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2006 12:49:58 -0000 On Sat, 24 Jun 2006 15:45:30 +-0300 (EEST), alex@halogen-dg.com wrote: > Anyone except me also disappointed by it? Search the archives, you're far from being the only one. -- < Jernej Simon+AQ0-i+AQ0- >< http://deepthought.ena.si/ > < Contact address: >< jernej simoncic at isg si > From alex@halogen-dg.com Sat Jun 24 09:01:55 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id F3A283B00A8 for ; Sat, 24 Jun 2006 09:01:54 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15013-06 for ; Sat, 24 Jun 2006 09:01:54 -0400 (EDT) Received: from appserver.halogen.kharkov.ua (appserver.halogen.kharkov.ua [217.144.70.65]) by menubar.gnome.org (Postfix) with ESMTP id 388713B0490 for ; Sat, 24 Jun 2006 09:01:53 -0400 (EDT) Received: (qmail 32296 invoked from network); 24 Jun 2006 16:01:54 +0300 Received: from dom.koval.kharkov.ua (217.144.70.182) by alex.halogen.kharkov.ua with AES256-SHA encrypted SMTP; 24 Jun 2006 16:01:54 +0300 Date: Sat, 24 Jun 2006 16:05:52 +0300 (EEST) From: alex@halogen-dg.com X-X-Sender: alex@dom.koval.kharkov.ua To: gtk-devel-list@gnome.org Subject: Re: gtk file open dialog usability. In-Reply-To: <10umqokepyu8y.10vhe4alqj04.dlg@40tude.net> Message-ID: References: <10umqokepyu8y.10vhe4alqj04.dlg@40tude.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.533 tagged_above=-999 required=2 tests=[AWL=0.028, BAYES_00=-2.599, NO_REAL_NAME=0.961, TW_GT=0.077] X-Spam-Score: -1.533 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2006 13:01:55 -0000 Hi Jernej On Sat, 24 Jun 2006, Jernej Simon+AQ0-i+AQ0- wrote: > On Sat, 24 Jun 2006 15:45:30 +-0300 (EEST), alex@halogen-dg.com wrote: > >> Anyone except me also disappointed by it? I am happy that people noticed that, too. The question is what can we do to fix this? My feeling is that at least 2 things could be done: 1. Make automatic selection of file optional (like its being done in KDE, in grey) 2. Do not display additional file open dialog when I *already* typed file name. > > Search the archives, you're far from being the only one. > BTW, before doing this post I've tried to search for "file dialog usability GTK". To my regret mail.gnome.org mailman search is not working ("The requested URL /mailman/search was not found on this server."),so I searched google a little, did not found any good results and posted here... Althrough this search returns more results: http://www.google.com.ua/search?q=gtk+file+open+usability&start=0&ie=utf-8&oe=utf-8&client=firefox-a&rls=org.mozilla:en-US:official Alex From g.tagliaretti@gmail.com Sat Jun 24 09:53:34 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 2C1C83B02E0 for ; Sat, 24 Jun 2006 09:53:34 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17447-04 for ; Sat, 24 Jun 2006 09:53:33 -0400 (EDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.178]) by menubar.gnome.org (Postfix) with ESMTP id 054D13B0228 for ; Sat, 24 Jun 2006 09:53:32 -0400 (EDT) Received: by py-out-1112.google.com with SMTP id i49so1099450pyi for ; Sat, 24 Jun 2006 06:52:59 -0700 (PDT) Received: by 10.35.99.14 with SMTP id b14mr3541165pym; Sat, 24 Jun 2006 06:52:56 -0700 (PDT) Received: by 10.35.132.18 with HTTP; Sat, 24 Jun 2006 06:52:56 -0700 (PDT) Message-ID: <35bf41160606240652s3da0fe6brd3915cd84c601114@mail.gmail.com> Date: Sat, 24 Jun 2006 15:52:56 +0200 From: "Gian Mario Tagliaretti" To: "alex@halogen-dg.com" Subject: Re: gtk file open dialog usability. In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.257 tagged_above=-999 required=2 tests=[AWL=0.066, BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2, SPF_PASS=-0.001, TW_GT=0.077] X-Spam-Score: -2.257 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2006 13:53:34 -0000 2006/6/24, alex@halogen-dg.com : > > Anyone except me also disappointed by it? > Any way how we can have old file open dialog back? code not complain :) > I really find it very frustating and explained > why, with some images here: > http://www.halogen-dg.com/alex/file_selection_dialog/GtkFileOpenBadUsability are you using gtk+ 2.9.x ? ciao -- Gian Mario Tagliaretti http://www.parafernalia.org/pygtk/ http://pygstdocs.berlios.de From timj@gtk.org Sat Jun 24 13:36:49 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 6B4403B006E; Sat, 24 Jun 2006 13:36:49 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27591-06; Sat, 24 Jun 2006 13:36:45 -0400 (EDT) Received: from holken.mikan.net (holken.mikan.net [83.145.56.183]) by menubar.gnome.org (Postfix) with ESMTP id C28AD3B06ED; Sat, 24 Jun 2006 13:36:44 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by holken.mikan.net (Postfix) with ESMTP id 59BF93352A5; Sat, 24 Jun 2006 19:36:26 +0200 (CEST) Received: from holken.mikan.net ([127.0.0.1]) by localhost (holken.mikan.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27952-05; Sat, 24 Jun 2006 19:36:22 +0200 (CEST) Received: from birnet.org (c135173.adsl.hansenet.de [213.39.135.173]) by holken.mikan.net (Postfix) with ESMTP id E12711844A; Sat, 24 Jun 2006 19:36:21 +0200 (CEST) Received: from master.birnet.private (localhost.localdomain [127.0.0.1]) by birnet.org (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k5OHaLjt023300 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 24 Jun 2006 19:36:21 +0200 Received: (from timj@localhost) by master.birnet.private (8.13.4/8.13.4/Submit) id k5OHZcXs023295; Sat, 24 Jun 2006 19:35:38 +0200 Date: Sat, 24 Jun 2006 19:35:38 +0200 (CEST) From: Tim Janik X-X-Sender: timj@master.birnet.private To: Gtk+ Developers Subject: Re: GTK+ meeting at GUADEC (Re: GTK+ 2.10, the endgame) In-Reply-To: Message-ID: References: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at holken.mikan.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.637 tagged_above=-999 required=2 tests=[AWL=-0.662, BAYES_05=-1.11, FORGED_RCVD_HELO=0.135] X-Spam-Score: -1.637 X-Spam-Level: X-Mailman-Approved-At: Sat, 24 Jun 2006 13:47:30 -0400 Cc: Federico Mena Quintero , Jonathan Blandford , Tim Janik , sandmann@daimi.au.dk, cworth@cworth.org, Komulainen Tommi , Alex Larsson , Michael Natterer , Kristian Rietveld , Matthias Clasen , Richard Hult , johan@gnome.org, michael meeks X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2006 17:36:49 -0000 On Thu, 15 Jun 2006, Tim Janik wrote: > the plan for that was to send out en email next friday/saturday (i.e > right at the guadec start) to figure/suggest dates suitable for > everyone to attend. we have gotten a room for the Gtk+ meeting now. it's on Sunday the 25th from 16:00-18:00 in the blue room (at the conference facility, second floor). --- ciaoTJ From torriem@chem.byu.edu Sun Jun 25 01:08:26 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id EA0E73B0079 for ; Sun, 25 Jun 2006 01:08:25 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17289-04 for ; Sun, 25 Jun 2006 01:08:22 -0400 (EDT) Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [63.240.77.83]) by menubar.gnome.org (Postfix) with ESMTP id ACB1F3B00A6 for ; Sun, 25 Jun 2006 01:08:22 -0400 (EDT) Received: from enterprise.local.lan (c-24-2-75-5.hsd1.ut.comcast.net[24.2.75.5]) by comcast.net (sccrmhc13) with ESMTP id <2006062505073001300me7qte>; Sun, 25 Jun 2006 05:07:31 +0000 Received: from enterprise.local.lan (enterprise.local.lan [127.0.0.1]) by enterprise.local.lan (8.13.1/8.12.8) with ESMTP id k5P57TFs002388 for ; Sat, 24 Jun 2006 23:07:29 -0600 Received: (from torriem@localhost) by enterprise.local.lan (8.13.1/8.13.1/Submit) id k5P57T1Z002387 for gtk-devel-list@gnome.org; Sat, 24 Jun 2006 23:07:29 -0600 X-Authentication-Warning: enterprise.local.lan: torriem set sender to torriem@chem.byu.edu using -f Subject: Re: Looking beyond 2.10 From: Michael Torrie To: gtk-devel-list@gnome.org In-Reply-To: References: <1150911355.15532.100.camel@golem.boston.redhat.com> <4499982C.1010004@teaser.fr> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Sat, 24 Jun 2006 23:07:29 -0600 Message-Id: <1151212049.32440.11.camel@enterprise.local.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-7) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.377 tagged_above=-999 required=2 tests=[AWL=0.010, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, TW_GT=0.077] X-Spam-Score: -2.377 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jun 2006 05:08:26 -0000 On Wed, 2006-06-21 at 18:26 -0400, Matthias Clasen wrote: > > I'm about to pick Qt as a toolkit for a personal project just because of > > that. > > Good luck. I was in the same boat as Hubert. I also ended up picking Qt. Although I like GTK much better, Qt was the best choice given the circumstances. I have not regretted it. But, as soon as GTK is fully supported on OS X, I will abandon Qt entirely, as GTK is cleaner, a little easier to work with, and, ironically, has better C++ bindings than Qt. > > Matthias > _______________________________________________ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-devel-list > From torriem@chem.byu.edu Sun Jun 25 01:21:50 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 36FD43B01F4 for ; Sun, 25 Jun 2006 01:21:50 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18141-02 for ; Sun, 25 Jun 2006 01:21:47 -0400 (EDT) Received: from sccrmhc14.comcast.net (sccrmhc14.comcast.net [204.127.200.84]) by menubar.gnome.org (Postfix) with ESMTP id DD6353B02BD for ; Sun, 25 Jun 2006 01:21:46 -0400 (EDT) Received: from enterprise.local.lan (c-24-2-75-5.hsd1.ut.comcast.net[24.2.75.5]) by comcast.net (sccrmhc14) with ESMTP id <2006062505211801400apa3je>; Sun, 25 Jun 2006 05:21:19 +0000 Received: from enterprise.local.lan (enterprise.local.lan [127.0.0.1]) by enterprise.local.lan (8.13.1/8.12.8) with ESMTP id k5P5LHWa002930; Sat, 24 Jun 2006 23:21:17 -0600 Received: (from torriem@localhost) by enterprise.local.lan (8.13.1/8.13.1/Submit) id k5P5LH4T002929; Sat, 24 Jun 2006 23:21:17 -0600 X-Authentication-Warning: enterprise.local.lan: torriem set sender to torriem@chem.byu.edu using -f Subject: Re: gtk file open dialog usability. From: Michael Torrie To: Gian Mario Tagliaretti In-Reply-To: <35bf41160606240652s3da0fe6brd3915cd84c601114@mail.gmail.com> References: <35bf41160606240652s3da0fe6brd3915cd84c601114@mail.gmail.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Sat, 24 Jun 2006 23:21:16 -0600 Message-Id: <1151212877.32440.24.camel@enterprise.local.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-7) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.378 tagged_above=-999 required=2 tests=[AWL=0.009, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, TW_GT=0.077] X-Spam-Score: -2.378 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jun 2006 05:21:50 -0000 On Sat, 2006-06-24 at 15:52 +0200, Gian Mario Tagliaretti wrote: > 2006/6/24, alex@halogen-dg.com : > > > > Anyone except me also disappointed by it? > > Any way how we can have old file open dialog back? > > code not complain :) BS. Before anyone can code anything, especially in the framework of GTK, the design has to be worked out. You can't just willy-nilly code up some pseudo-compatible widget. The problem is that every time this is discussed there is never any consensus on what the problems are, why they are problems, and how to fix them. And without this, we cannot convince developers to do anything about the problem. Now having said that, if someone wants to prototype a better widget (one that is API compatible with the current one), maybe that would jump- start the process. Myself, I fear that inertia guarantees we're stuck with this bad design for the duration. > > > I really find it very frustating and explained > > why, with some images here: > > http://www.halogen-dg.com/alex/file_selection_dialog/GtkFileOpenBadUsability > > are you using gtk+ 2.9.x ? > > ciao From dan@entropy.homelinux.org Mon Jun 26 21:13:46 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id D7F733B029A for ; Mon, 26 Jun 2006 21:13:46 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27746-05 for ; Mon, 26 Jun 2006 21:13:44 -0400 (EDT) Received: from screamer.nusconsulting.com.au (mail.nusconsulting.com.au [203.191.186.114]) by menubar.gnome.org (Postfix) with ESMTP id 5E0173B00FE for ; Mon, 26 Jun 2006 21:13:43 -0400 (EDT) Received: from [10.146.1.25] (dkasak.nusconsulting.com.au [10.146.1.25]) by screamer.nusconsulting.com.au (8.13.6/8.13.6) with ESMTP id k5R1FSwU022408 for ; Tue, 27 Jun 2006 11:15:28 +1000 Message-ID: <44A08654.1090208@entropy.homelinux.org> Date: Tue, 27 Jun 2006 11:13:56 +1000 From: Daniel Kasak User-Agent: Thunderbird 1.5.0.2 (X11/20060531) MIME-Version: 1.0 To: gtk-devel-list@gnome.org Subject: Custom Cell Renderers in a TreeView that requires scrolling broken in gtk+-2.8.18 and 2.8.19 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Canit-Stats-ID: 464197 - 7afdf0e072d5 X-Antispam-Training: Train as spam: http://screamer.nusconsulting.com.au/internal/canit/b.php?c=s&i=464197&m=7afdf0e072d5 X-Antispam-Training: Train as non-spam: http://screamer.nusconsulting.com.au/internal/canit/b.php?c=n&i=464197&m=7afdf0e072d5 X-Antispam-Training: Cancel training: http://screamer.nusconsulting.com.au/internal/canit/b.php?c=f&i=464197&m=7afdf0e072d5 X-Scanned-By: CanIt (www . roaringpenguin . com) on 10.146.0.254 X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.564 tagged_above=-999 required=2 tests=[AWL=0.035, BAYES_00=-2.599] X-Spam-Score: -2.564 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2006 01:13:47 -0000 Hi all. I've just noticed a very strange bug in my TreeViews since updating gtk. I have some apps that use a custom cell renderer to provide a pop-up GtkCalender. When I insert a row in the model, the custom cell renderer pops up ( begins editing ) as it's the 1st column. After I select a date and accept changes AND IF THERE ARE MORE ROWS THAN WILL FIT IN THE TREEVIEW WITHOUT SCROLLING, the new row DISAPPEARS from the TreeView. I scroll right from top to bottom - the new row certainly *looks* like it's gone. However if I insert *another* row, my previous missing row appears ( momentarily ) at the bottom again ... until I accept changes from the custom cell renderer on the newest row, and then they both ( or ALL, if I've inserted a number of rows ) disappear. For completeness ( partial anyway - it's a pretty complicated beast, but I can post an entire working example if required - please reply and request this if necessary, but note that it will be in Perl ), I'm pasting the entire CellRendererDate.pm module that provides the custom cell renderer at the bottom, however I note again that everything has worked properly for every version of gtk+ prior to 2.8.18. I initially updated from 2.8.17 to 2.8.19, and then when I found the bug, reverted to 2.8.17 ... tested some more ( no such bug here ), and then updated to 2.8.18 and did some more testing. It definitely arrived in 2.8.18. Has anyone noticed this behaviour with custom cell renderers? I have tested many other TreeViews that *don't* have a custom cell renderer, and have also tried moving the custom cell renderer to another position ( column ). I am almost positive that something is broken with displaying rows with a custom cell renderer when scrolling is required. I would greatly appreciate some help / suggests / confirmations / etc. Dan --- use strict; use Gtk2 -init; package Gtk2::Ex::Datasheet::DBI::CellRendererDate; use Glib::Object::Subclass "Gtk2::CellRenderer", signals => { edited => { flags => [qw(run-last)], param_types => [qw(Glib::String Glib::Scalar)], }, }, properties => [ Glib::ParamSpec -> boolean("editable", "Editable", "Can I change that?", 0, [qw(readable writable)]), Glib::ParamSpec -> string("date", "Date", "What's the date again?", "", [qw(readable writable)]), ] ; use constant x_padding => 2; use constant y_padding => 3; use constant arrow_width => 15; use constant arrow_height => 15; sub hide_popup { my ($cell) = @_; Gtk2 -> grab_remove($cell -> { _popup }); $cell -> { _popup } -> hide(); } sub get_today { my ($cell) = @_; my ($day, $month, $year) = (localtime())[3, 4, 5]; $year += 1900; $month += 1; return ($year, $month, $day); } sub get_date { my ($cell) = @_; my $text = $cell -> get("date"); my ($year, $month, $day) = $text ? split(/[\/-]/, $text) : $cell -> get_today(); return ($year, $month, $day); } sub add_padding { my ($cell, $year, $month, $day) = @_; return ($year, sprintf("%02d", $month), sprintf("%02d", $day)); } sub INIT_INSTANCE { my ($cell) = @_; my $popup = Gtk2::Window -> new ('popup'); my $vbox = Gtk2::VBox -> new(0, 0); my $calendar = Gtk2::Calendar -> new(); my $hbox = Gtk2::HBox -> new(0, 0); my $today = Gtk2::Button -> new('Today'); my $none = Gtk2::Button -> new('None'); $cell -> {_arrow} = Gtk2::Arrow -> new("down", "none"); # We can't just provide the callbacks now because they might need access to # cell-specific variables. And we can't just connect the signals in # START_EDITING because we'd be connecting many signal handlers to the same # widgets. $today -> signal_connect(clicked => sub { $cell -> { _today_clicked_callback } -> (@_) if (exists($cell -> { _today_clicked_callback })); }); $none -> signal_connect(clicked => sub { $cell -> { _none_clicked_callback } -> (@_) if (exists($cell -> { _none_clicked_callback })); }); $calendar -> signal_connect(day_selected_double_click => sub { $cell -> { _day_selected_double_click_callback } -> (@_) if (exists($cell -> { _day_selected_double_click_callback })); }); $calendar -> signal_connect(month_changed => sub { $cell -> { _month_changed } -> (@_) if (exists($cell -> { _month_changed })); }); $hbox -> pack_start($today, 1, 1, 0); $hbox -> pack_start($none, 1, 1, 0); $vbox -> pack_start($calendar, 1, 1, 0); $vbox -> pack_start($hbox, 0, 0, 0); # Find out if the click happended outside of our window. If so, hide it. # Largely copied from Planner (the former MrProject). # Implement via Gtk2::get_event_widget? $popup -> signal_connect(button_press_event => sub { my ($popup, $event) = @_; if ($event -> button() == 1) { my ($x, $y) = ($event -> x_root(), $event -> y_root()); my ($xoffset, $yoffset) = $popup -> window() -> get_root_origin(); my $allocation = $popup -> allocation(); my $x1 = $xoffset + 2 * $allocation -> x(); my $y1 = $yoffset + 2 * $allocation -> y(); my $x2 = $x1 + $allocation -> width(); my $y2 = $y1 + $allocation -> height(); unless ($x > $x1 && $x < $x2 && $y > $y1 && $y < $y2) { $cell -> hide_popup(); return 1; } } return 0; }); $popup -> add($vbox); $cell -> { _popup } = $popup; $cell -> { _calendar } = $calendar; } sub START_EDITING { my ($cell, $event, $view, $path, $background_area, $cell_area, $flags) = @_; my $popup = $cell -> { _popup }; my $calendar = $cell -> { _calendar }; # Specify the callbacks. Will be called by the signal handlers set up in # INIT_INSTANCE. $cell -> { _today_clicked_callback } = sub { my ($button) = @_; my ($year, $month, $day) = $cell -> get_today(); $cell -> signal_emit(edited => $path, join("-", $cell -> add_padding($year, $month, $day))); $cell -> hide_popup(); }; $cell -> { _none_clicked_callback } = sub { my ($button) = @_; $cell -> signal_emit(edited => $path, ""); $cell -> hide_popup(); }; $cell -> { _day_selected_double_click_callback } = sub { my ($calendar) = @_; my ($year, $month, $day) = $calendar -> get_date(); $cell -> signal_emit(edited => $path, join("-", $cell -> add_padding($year, ++$month, $day))); $cell -> hide_popup(); }; $cell -> { _month_changed } = sub { my ($calendar) = @_; my ($selected_year, $selected_month) = $calendar -> get_date(); my ($current_year, $current_month, $current_day) = $cell -> get_today(); if ($selected_year == $current_year && ++$selected_month == $current_month) { $calendar -> mark_day($current_day); } else { $calendar -> unmark_day($current_day); } }; my ($year, $month, $day) = $cell -> get_date(); $calendar -> select_month($month - 1, $year); $calendar -> select_day($day); # Necessary to get the correct allocation of the popup. $popup -> move(-500, -500); $popup -> show_all(); # Figure out where to put the popup - ie don't put it offscreen, # as it's not movable ( by the user ) my $screen_height = $popup->get_screen->get_height; my $requisition = $popup->size_request(); my $popup_width = $requisition->width; my $popup_height = $requisition->height; my ($x_origin, $y_origin) = $view -> get_bin_window() -> get_origin(); my ($popup_x, $popup_y); $popup_x = $x_origin + $cell_area->x() + $cell_area->width() - $popup_width; $popup_x = 0 if $popup_x < 0; $popup_y = $y_origin + $cell_area -> y() + $cell_area -> height(); if ( $popup_y + $popup_height > $screen_height ) { $popup_y = $y_origin + $cell_area -> y() - $popup_height; } $popup -> move( $popup_x, $popup_y ); # Grab the focus and the pointer. Gtk2 -> grab_add($popup); $popup -> grab_focus(); Gtk2::Gdk -> pointer_grab($popup -> window(), 1, [qw(button-press-mask button-release-mask pointer-motion-mask)], undef, undef, 0); return; } sub get_date_string { my $cell = shift; return $cell->get ('date'); } sub calc_size { my ($cell, $layout) = @_; my ($width, $height) = $layout -> get_pixel_size(); return (0, 0, $width + x_padding * 2 + arrow_width, $height + y_padding * 2); } sub GET_SIZE { my ($cell, $widget, $cell_area) = @_; my $layout = $cell -> get_layout($widget); $layout -> set_text( $cell -> get_date_string() || '' ); return $cell -> calc_size($layout); } sub get_layout { my ($cell, $widget) = @_; return $widget -> create_pango_layout(""); } sub RENDER { my ($cell, $window, $widget, $background_area, $cell_area, $expose_area, $flags) = @_; my $state; if ($flags & 'selected') { $state = $widget -> has_focus() ? 'selected' : 'active'; } else { $state = $widget -> state() eq 'insensitive' ? 'insensitive' : 'normal'; } my $layout = $cell -> get_layout($widget); $layout -> set_text( $cell -> get_date_string() || '' ); my ($x_offset, $y_offset, $width, $height) = $cell -> calc_size($layout); $widget -> get_style -> paint_layout($window, $state, 1, $cell_area, $widget, "cellrenderertext", $cell_area -> x() + $x_offset + x_padding, $cell_area -> y() + $y_offset + y_padding, $layout); $widget -> get_style -> paint_arrow ($window, $widget->state, 'none', $cell_area, $cell -> { _arrow }, "", "down", 1, $cell_area -> x + $cell_area -> width - arrow_width, $cell_area -> y + $cell_area -> height - arrow_height - 2, arrow_width - 3, arrow_height); } 1; From mail2karuna@hotmail.com Tue Jun 27 05:53:25 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 0ECA43B00E4 for ; Tue, 27 Jun 2006 05:53:25 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21270-07 for ; Tue, 27 Jun 2006 05:53:11 -0400 (EDT) Received: from hotmail.com (bay123-f24.bay123.hotmail.com [207.46.11.104]) by menubar.gnome.org (Postfix) with ESMTP id 2C7C03B0104 for ; Tue, 27 Jun 2006 05:53:11 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 27 Jun 2006 02:53:10 -0700 Message-ID: Received: from 207.46.11.123 by by123fd.bay123.hotmail.msn.com with HTTP; Tue, 27 Jun 2006 09:53:09 GMT X-Originating-IP: [62.193.236.100] X-Originating-Email: [mail2karuna@hotmail.com] X-Sender: mail2karuna@hotmail.com From: "karuna karan" To: gtk-devel-list@gnome.org Subject: Re: Failed building GTK with the DFB backend Date: Tue, 27 Jun 2006 09:53:09 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 27 Jun 2006 09:53:10.0427 (UTC) FILETIME=[7F932EB0:01C699CF] X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-0.958 tagged_above=-999 required=2 tests=[BAYES_05=-1.11, MSGID_FROM_MTA_HEADER=0, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, TW_BG=0.077, TW_GT=0.077] X-Spam-Score: -0.958 X-Spam-Level: Cc: skar@tataelxsi.co.in X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2006 09:53:25 -0000 Hi all, I tried to build gtk 2.9.1 with directFB backend with following dependencies, glib 2.11.1 atk 1.10.1 cairo 1.1.6 pango 1.13.1 directfb 0.9.25.1 while building gtk with, 1 ./configure --prefix=/opt/gtkdfb/ --without-x --with-gdktarget=directfb --enable-debug=no 2 make the buld fails and throws the error as, queryimmodules.c: In function `query_module': queryimmodules.c:116: warning: dereferencing type-punned pointer will break strict-aliasing rules queryimmodules.c:117: warning: dereferencing type-punned pointer will break strict-aliasing rules queryimmodules.c:118: warning: dereferencing type-punned pointer will break strict-aliasing rules queryimmodules.c:119: warning: dereferencing type-punned pointer will break strict-aliasing rules /bin/sh ../libtool --mode=link gcc -g -O2 -Wall -o gtk-query-immodules-2.0 queryimmodules.o libgtk-directfb-2.0.la .../gdk-pixbuf/libgdk_pixbuf-2.0.la ../gdk/libgdk-directfb-2.0.la gcc -g -O2 -Wall -o .libs/gtk-query-immodules-2.0 queryimmodules.o ../.libs/libgtk-directfb-2.0.so -L/opt/gtkdfb/lib /root/gtk+-2.9.1/gdk/.libs/libgdk-directfb-2.0.so /opt/gtkdfb/lib/libatk-1.0.so ../gdk-pixbuf/.libs/libgdk_pixbuf-2.0.so .../gdk/.libs/libgdk-directfb-2.0.so /opt/gtkdfb/lib/libpangocairo-1.0.so /opt/gtkdfb/lib/libpangoft2-1.0.so /opt/gtkdfb/lib/libpango-1.0.so /opt/gtkdfb/lib/libcairo.so -lpng12 /opt/gtkdfb/lib/libdirectfb.so /opt/gtkdfb/lib/libfusion.so /opt/gtkdfb/lib/libdirect.so -lfontconfig /usr/lib/libfreetype.so /usr/lib/libxml2.so -lpthread -lz /root/gtk+-2.9.1/gdk-pixbuf/.libs/libgdk_pixbuf-2.0.so /opt/gtkdfb/lib/libgmodule-2.0.so -ldl /opt/gtkdfb/lib/libgobject-2.0.so /opt/gtkdfb/lib/libglib-2.0.so -lm -Wl,--rpath -Wl,/opt/gtkdfb/lib ../.libs/libgtk-directfb-2.0.so: undefined reference to `gdk_screen_is_composited' /root/gtk+-2.9.1/gdk/.libs/libgdk-directfb-2.0.so: undefined reference to `IA__gdk_screen_is_composited' collect2: ld returned 1 exit status make[4]: *** [gtk-query-immodules-2.0] Error 1 make[4]: Leaving directory `/root/gtk+-2.9.1/gtk' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/root/gtk+-2.9.1/gtk' make[2]: *** [all] Error 2 make[2]: Leaving directory `/root/gtk+-2.9.1/gtk' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/root/gtk+-2.9.1' make: *** [all] Error 2 help me out in this.. Thanks, Karunakaran A. _________________________________________________________________ Dont just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/ From fiandro@tiscali.it Tue Jun 27 06:05:04 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C52653B0010 for ; Tue, 27 Jun 2006 06:05:04 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22230-02 for ; Tue, 27 Jun 2006 06:05:02 -0400 (EDT) Received: from polito.it (anacreon.polito.it [130.192.3.82]) by menubar.gnome.org (Postfix) with ESMTP id 1B1113B0088 for ; Tue, 27 Jun 2006 06:05:00 -0400 (EDT) X-ExtScanner: Niversoft's FindAttachments (free) Received: from [130.192.31.127] (HELO [130.192.31.127]) by anacreon.polito.it (CommuniGate Pro SMTP 5.0.9) with ESMTP id 39350329; Tue, 27 Jun 2006 12:04:58 +0200 Message-ID: <44A103E0.8000000@tiscali.it> Date: Tue, 27 Jun 2006 12:09:36 +0200 From: Attilio Fiandrotti User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.13) Gecko/20060620 Debian/1.7.13-0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: karuna karan Subject: Re: Failed building GTK with the DFB backend References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.224 tagged_above=-999 required=2 tests=[AWL=-0.337, BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2, FORGED_RCVD_HELO=0.135, SPF_NEUTRAL=1.069, TW_DF=0.077, TW_GT=0.077, TW_KD=0.077, TW_TK=0.077] X-Spam-Score: -1.224 X-Spam-Level: Cc: gtk-devel-list@gnome.org, skar@tataelxsi.co.in X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2006 10:05:05 -0000 karuna karan wrote: > Hi all, > > I tried to build gtk 2.9.1 with directFB backend with following > dependencies, DFB support in was broken: you should try 2.9.4 or follow instructions in the wiki page to build from sratch. If you're a debian user, you can also use precompiled i386 official packages that were built this week http://download.dajobe.org/debian/experimental/ <-cairodfb http://people.debian.org/~joss/packages/ <-gtkdfb Attilio From kris@babi-pangang.org Tue Jun 27 08:43:52 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 623A53B00AE for ; Tue, 27 Jun 2006 08:43:52 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29028-04 for ; Tue, 27 Jun 2006 08:43:48 -0400 (EDT) Received: from nasi-goreng.babi-pangang.org (nasi-goreng.babi-pangang.org [83.166.137.20]) by menubar.gnome.org (Postfix) with ESMTP id 5BA363B008D for ; Tue, 27 Jun 2006 08:43:48 -0400 (EDT) Received: by nasi-goreng.babi-pangang.org (Postfix, from userid 1000) id C52593DCA0; Tue, 27 Jun 2006 14:42:09 +0200 (CEST) Date: Tue, 27 Jun 2006 14:42:09 +0200 From: Kristian Rietveld To: gtk-devel-list@gnome.org Subject: Minutes of the GTK+ meeting at GUADEC Message-ID: <20060627124209.GA23474@babi-pangang.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.564 tagged_above=-999 required=2 tests=[AWL=0.035, BAYES_00=-2.599] X-Spam-Score: -2.564 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2006 12:43:52 -0000 Hey, We had a GTK+ meeting in person at GUADEC last Sunday. Below are the minutes (or really just the notes I took). -kris. ---- GTK+ Meeting, 25 June 2006, GUADEC7 ----------------------------------- * 2.10 is basically done, we are aiming for a release next week. * Tommi asks whether the GTK+ development/maintainer team is big enough. Matthias and Tim both answer that the team has been too small for the last few years, everybody else seems to agree. * Planning 2.12, possible new features: - Canvas, and we need off-screen rendering for that. # At least 3 different candidate canvases around. # Some ideas from Soeren; immediate mode, callbacks. He will write up his ideas and send it to the list for discussion. # Defining the feature set for a canvas is really difficult, though most people agreed that GnomeCanvas does cover most of the features needed by general applications. # Might want to look at the new canvas in Qt 4.1. - Introspection - GtkBuilder, the libglade integration into GTK+. - The new tooltips API. - Maemo.org patches # Menu patches, # Input method, # Tap and hold. - International calendar support # GLib patch is about ready, # After that the GTK+ widget (GtkCalendar) needs some fixing up. - Support for editable multi-line labels, probably by extending GtkEntry. - libsexy cherrypicking # Support having an icon in the entry. # Input masks. - Recent file code updates # GtkRecentAction. # GtkFileChooser integration. * Matthias continues on Tommi's previous question on maintenance, mentioning the OS X backend. Micke and Richard explain that the backend is mostly working, but does need some bug fixing. It's marked as still experimental. * The file chooser API does have some issues. For example the backend API is private, and getting the model from the file chooser dialog is impossible. Also the code for supporting the pluggability of the UI does not work/has not been tested at all. * We decided to target the GTK+ 2.12 release on January '07. This should give us enough time to put all new features in. If we decide to include a canvas with GTK+ 2.12, we might have to depend on a new release of Cairo. According to Carl Worth the next releases of Cairo are pretty much "open". They will probably focus on performance for the next release. Making a new release for supporting some special canvas features should be feasible. * We get interrupted by some guys of the board. Jeff speaks about having the GTK+ project join the GNOME foundation. The foundation can provide help to the GTK+ project with financial and administrative tasks. It has been doing this for the GIMP project already, which has been working fine so far. The foundation does not get any influence on the technical decisions made by the GTK+ team. Also, the plan is to get a press release out on this. * The board leaves and the core team pretty much decides that doing this is not bad at all, and the only thing that needs work is the wording in the press release. Nobody appears to be against. * The topic of GTK+ 3.0 was brought up after this. 3.0 would be an API and ABI breaking release. The team decided that we would like to avoid breaking API since a lot of companies invested into GTK+ 2.x and expect that it'll be supported for some more years. Most of the team seems to agree that we want to get rid of the cruft in the 2.x series, some of which is still sticking around from the 1.x series. Matthias mentions that FC6 will not ship with GTK+ 1.x. (People cheered and Tim complained about he won't be able to run xmms then). The idea of introducing compiling subsets was brought up. We could set up a make system where the full library or only a subset is built, for example omitting all the old stuff and the printing support. The people using GTK+ on embedded devices would be really happy if we implemented something like this. If we want the compiling subsets to work, we need to make sure that none of the internal code is using deprecated widgets. Breaking API is not really something we really want to do soon. If we ever do it, we want to do it right so it can last for at least a couple of years. Also, we would prefer the development on 3.0 to happen in parallel with 2.x development. Alex brought up the idea of creating a bug which we can use to track all issues which require breaking the API, so we get a formalized list of stuff which needs API breakage. According to Tim breaking the ABI is not a real problem, since distributions and also for example the Maemo.org platform can just be recompiled. * Tim also mentioned that Michael Meeks has been working on optimizing shared library loading optimization in OpenOffice.org. We wondered if there's anything we can do to improve GTK+'s performance in this area. As Michael was unable to attend Tim and/or Matthias will try to have a talk with Michael about this. As there was nothing left discuss, we decided to close the meeting. From skar@tataelxsi.co.in Tue Jun 27 07:22:44 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 665AF3B0072 for ; Tue, 27 Jun 2006 07:22:44 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25789-03 for ; Tue, 27 Jun 2006 07:22:43 -0400 (EDT) Received: from mail.tataelxsi.co.in (mail.tataelxsi.co.in [203.200.1.48]) by menubar.gnome.org (Postfix) with ESMTP id 1DFEF3B0011 for ; Tue, 27 Jun 2006 07:22:41 -0400 (EDT) Received: from skar (tataelxsi.co.in [203.197.169.80] (may be forged)) by mail.tataelxsi.co.in (MOS 3.7.4b-GA) with ESMTP id BRG33699 (AUTH skar); Tue, 27 Jun 2006 16:52:16 +0530 (IST) From: Suman Kar To: "'Attilio Fiandrotti'" , "'karuna karan'" Subject: RE: Failed building GTK with the DFB backend Date: Tue, 27 Jun 2006 16:51:13 +0530 Message-ID: <002301c699db$cd352ea0$381b320a@telxsi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal In-Reply-To: <44A103E0.8000000@tiscali.it> X-Junkmail: Blacklisted X-Mirapoint-Sig: mail.tataelxsi.co.in X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=0.386 tagged_above=-999 required=2 tests=[BAYES_50=0.001, TW_DF=0.077, TW_GD=0.077, TW_GT=0.077, TW_KD=0.077, TW_TK=0.077] X-Spam-Score: 0.386 X-Spam-Level: X-Mailman-Approved-At: Tue, 27 Jun 2006 10:07:05 -0400 Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: Suman Kar List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2006 11:22:44 -0000 Hello Attilio, Thanks for the quick update. However, the problem goes away when we added the following: gboolean gdk_screen_is_composited (GdkScreen *screen) { g_return_val_if_fail (GDK_IS_SCREEN (screen), NULL); return FALSE; } is added to gdkscreen-directfb.c (from http://mail.gnome.org/archives/gtk-devel-list/2006-May/msg00210.html ). We will definitely try building gtk+2.9.4 and will get back in case there are any issues. One more thing: we would be really interested in gtk+-2.10. Any idea when this will be out? Regards, Suman. -----Original Message----- From: Attilio Fiandrotti [mailto:fiandro@tiscali.it] Sent: Tuesday, June 27, 2006 3:40 PM To: karuna karan Cc: gtk-devel-list@gnome.org; skar@tataelxsi.co.in Subject: Re: Failed building GTK with the DFB backend karuna karan wrote: > Hi all, > > I tried to build gtk 2.9.1 with directFB backend with following > dependencies, DFB support in was broken: you should try 2.9.4 or follow instructions in the wiki page to build from sratch. If you're a debian user, you can also use precompiled i386 official packages that were built this week http://download.dajobe.org/debian/experimental/ <-cairodfb http://people.debian.org/~joss/packages/ <-gtkdfb Attilio The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s)and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender or administrator@tataelxsi.co.in From mail2karuna@hotmail.com Wed Jun 28 01:21:49 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 761EF3B002A for ; Wed, 28 Jun 2006 01:21:49 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27811-08 for ; Wed, 28 Jun 2006 01:21:48 -0400 (EDT) Received: from hotmail.com (bay123-f28.bay123.hotmail.com [207.46.11.108]) by menubar.gnome.org (Postfix) with ESMTP id 40EF13B000F for ; Wed, 28 Jun 2006 01:21:48 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 27 Jun 2006 22:19:26 -0700 Message-ID: Received: from 207.46.11.123 by by123fd.bay123.hotmail.msn.com with HTTP; Wed, 28 Jun 2006 05:19:23 GMT X-Originating-IP: [62.193.236.96] X-Originating-Email: [mail2karuna@hotmail.com] X-Sender: mail2karuna@hotmail.com In-Reply-To: <002301c699db$cd352ea0$381b320a@telxsi.com> From: "karuna karan" To: fiandro@tiscali.it, skar@tataelxsi.co.in, amirthakaruna@tataelxsi.co.in Subject: RE: Failed building GTK with the DFB backend Date: Wed, 28 Jun 2006 05:19:23 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 28 Jun 2006 05:19:26.0977 (UTC) FILETIME=[6CD95710:01C69A72] X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-0.502 tagged_above=-999 required=2 tests=[AWL=-1.829, BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2, DNS_FROM_RFC_POST=1.708, MSGID_FROM_MTA_HEADER=0, RCVD_IN_BL_SPAMCOP_NET=1.558, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, TW_DF=0.077, TW_DK=0.077, TW_GD=0.077, TW_GT=0.077, TW_KD=0.077, TW_TK=0.077] X-Spam-Score: -0.502 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2006 05:21:49 -0000 Hi, we have tried to build gtk+ 2.9.4 with backend dfb. we got the follwing error while building, gdkwindow-directfb.c: In function `gdk_directfb_create_child_window': gdkwindow-directfb.c:2508: error: structure has no member named `GetPosition' make[4]: *** [gdkwindow-directfb.lo] Error 1 make[4]: Leaving directory `/root/new/gtk+-2.9.4/gdk/directfb' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/root/new/gtk+-2.9.4/gdk' make[2]: *** [all] Error 2 make[2]: Leaving directory `/root/new/gtk+-2.9.4/gdk' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/root/new/gtk+-2.9.4' make: *** [all] Error 2 so kindly give feedback on this issue.. Thanks, Karunakaran A. >From: Suman Kar >Reply-To: Suman Kar >To: "'Attilio Fiandrotti'" , "'karuna karan'" > >CC: >Subject: RE: Failed building GTK with the DFB backend >Date: Tue, 27 Jun 2006 16:51:13 +0530 > >Hello Attilio, > >Thanks for the quick update. However, the problem goes away when we added >the following: > >gboolean >gdk_screen_is_composited (GdkScreen *screen) >{ > g_return_val_if_fail (GDK_IS_SCREEN (screen), NULL); > return FALSE; >} > > >is added to gdkscreen-directfb.c (from >http://mail.gnome.org/archives/gtk-devel-list/2006-May/msg00210.html ). > >We will definitely try building gtk+2.9.4 and will get back in case there >are any issues. > >One more thing: we would be really interested in gtk+-2.10. Any idea when >this will be out? > >Regards, >Suman. > >-----Original Message----- >From: Attilio Fiandrotti [mailto:fiandro@tiscali.it] >Sent: Tuesday, June 27, 2006 3:40 PM >To: karuna karan >Cc: gtk-devel-list@gnome.org; skar@tataelxsi.co.in >Subject: Re: Failed building GTK with the DFB backend > > >karuna karan wrote: > > Hi all, > > > > I tried to build gtk 2.9.1 with directFB backend with following > > dependencies, > >DFB support in was broken: you should try 2.9.4 or follow instructions >in the wiki page to build from sratch. >If you're a debian user, you can also use precompiled i386 official >packages that were built this week > >http://download.dajobe.org/debian/experimental/ <-cairodfb >http://people.debian.org/~joss/packages/ <-gtkdfb > >Attilio > >The information contained in this electronic message and any attachments to >this message are intended for the exclusive use of the addressee(s)and may >contain confidential or privileged information. If you are not the intended >recipient, please notify the sender or administrator@tataelxsi.co.in _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today - it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ From matthias.clasen@gmail.com Wed Jun 28 03:10:14 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 5BEF93B002C for ; Wed, 28 Jun 2006 03:10:14 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30060-02 for ; Wed, 28 Jun 2006 03:10:12 -0400 (EDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.183]) by menubar.gnome.org (Postfix) with ESMTP id 603903B009C for ; Wed, 28 Jun 2006 03:10:12 -0400 (EDT) Received: by py-out-1112.google.com with SMTP id c30so2171621pyc for ; Wed, 28 Jun 2006 00:09:17 -0700 (PDT) Received: by 10.35.83.6 with SMTP id k6mr338054pyl; Wed, 28 Jun 2006 00:09:17 -0700 (PDT) Received: by 10.35.39.16 with HTTP; Wed, 28 Jun 2006 00:09:17 -0700 (PDT) Message-ID: Date: Wed, 28 Jun 2006 03:09:17 -0400 From: "Matthias Clasen" To: "Suman Kar" Subject: Re: Failed building GTK with the DFB backend In-Reply-To: <002301c699db$cd352ea0$381b320a@telxsi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <44A103E0.8000000@tiscali.it> <002301c699db$cd352ea0$381b320a@telxsi.com> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.41 tagged_above=-999 required=2 tests=[AWL=-0.010, BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2, SPF_PASS=-0.001] X-Spam-Score: -2.41 X-Spam-Level: Cc: gtk-devel-list@gnome.org, karuna karan X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2006 07:10:14 -0000 On 6/27/06, Suman Kar wrote: > One more thing: we would be really interested in gtk+-2.10. Any idea when > this will be out? > I'll start working on the release when I'm back from Guadec next week. From fiandro@tiscali.it Wed Jun 28 03:57:13 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 3E6E73B0002 for ; Wed, 28 Jun 2006 03:57:13 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31177-01 for ; Wed, 28 Jun 2006 03:57:10 -0400 (EDT) Received: from aa003msr.fastwebnet.it (aa003msr.fastwebnet.it [85.18.95.66]) by menubar.gnome.org (Postfix) with ESMTP id 4417B3B0005 for ; Wed, 28 Jun 2006 03:57:10 -0400 (EDT) Received: from [192.168.2.2] (41.255.136.50) by aa003msr.fastwebnet.it (7.2.070.1) id 44965DC20058C56D; Wed, 28 Jun 2006 09:55:45 +0200 Message-ID: <44A23718.3020008@tiscali.it> Date: Wed, 28 Jun 2006 10:00:24 +0200 From: Attilio Fiandrotti User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.13) Gecko/20060620 Debian/1.7.13-0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: karuna karan Subject: Re: Failed building GTK with the DFB backend References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=1.347 tagged_above=-999 required=2 tests=[AWL=-0.215, BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2, RCVD_IN_WHOIS_BOGONS=2.43, SPF_NEUTRAL=1.069, TW_DF=0.077, TW_DK=0.077, TW_GD=0.077, TW_GT=0.077, TW_KD=0.077, TW_TK=0.077] X-Spam-Score: 1.347 X-Spam-Level: * Cc: gtk-devel-list@gnome.org, skar@tataelxsi.co.in, amirthakaruna@tataelxsi.co.in X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2006 07:57:13 -0000 A couple of days ago mike checked in the patch that excludes from compilation some extra code that requires DFB 0.9.25 in the case DFN 0.9.24 is used. Use CVS sources or apply to GTK 2.9.4 gdkdirectfb.h and gdkwindow-directfb.c from current SVN. If you're a Debian user and run on i386, simply install cairodfb and gtkdfb packages [1] which were made recently available (other archs will follow soon). Attilio [1] http://mail.directfb.org/pipermail/directfb-dev/2006-June/001973.html karuna karan wrote: > Hi, > > we have tried to build gtk+ 2.9.4 with backend dfb. > we got the follwing error while building, > > gdkwindow-directfb.c: In function `gdk_directfb_create_child_window': > gdkwindow-directfb.c:2508: error: structure has no member named > `GetPosition' > make[4]: *** [gdkwindow-directfb.lo] Error 1 > make[4]: Leaving directory `/root/new/gtk+-2.9.4/gdk/directfb' > make[3]: *** [all-recursive] Error 1 > make[3]: Leaving directory `/root/new/gtk+-2.9.4/gdk' > make[2]: *** [all] Error 2 > make[2]: Leaving directory `/root/new/gtk+-2.9.4/gdk' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/root/new/gtk+-2.9.4' > make: *** [all] Error 2 > > so kindly give feedback on this issue.. > > Thanks, > Karunakaran A. > > > > >> From: Suman Kar >> Reply-To: Suman Kar >> To: "'Attilio Fiandrotti'" , "'karuna >> karan'" >> CC: >> Subject: RE: Failed building GTK with the DFB backend >> Date: Tue, 27 Jun 2006 16:51:13 +0530 >> >> Hello Attilio, >> >> Thanks for the quick update. However, the problem goes away when we added >> the following: >> >> gboolean >> gdk_screen_is_composited (GdkScreen *screen) >> { >> g_return_val_if_fail (GDK_IS_SCREEN (screen), NULL); >> return FALSE; >> } >> >> >> is added to gdkscreen-directfb.c (from >> http://mail.gnome.org/archives/gtk-devel-list/2006-May/msg00210.html ). >> >> We will definitely try building gtk+2.9.4 and will get back in case there >> are any issues. >> >> One more thing: we would be really interested in gtk+-2.10. Any idea when >> this will be out? >> >> Regards, >> Suman. >> >> -----Original Message----- >> From: Attilio Fiandrotti [mailto:fiandro@tiscali.it] >> Sent: Tuesday, June 27, 2006 3:40 PM >> To: karuna karan >> Cc: gtk-devel-list@gnome.org; skar@tataelxsi.co.in >> Subject: Re: Failed building GTK with the DFB backend >> >> >> karuna karan wrote: >> > Hi all, >> > >> > I tried to build gtk 2.9.1 with directFB backend with following >> > dependencies, >> >> DFB support in was broken: you should try 2.9.4 or follow instructions >> in the wiki page to build from sratch. >> If you're a debian user, you can also use precompiled i386 official >> packages that were built this week >> >> http://download.dajobe.org/debian/experimental/ <-cairodfb >> http://people.debian.org/~joss/packages/ <-gtkdfb >> >> Attilio >> >> The information contained in this electronic message and any >> attachments to this message are intended for the exclusive use of the >> addressee(s)and may contain confidential or privileged information. If >> you are not the intended recipient, please notify the sender or >> administrator@tataelxsi.co.in > > > _________________________________________________________________ > Express yourself instantly with MSN Messenger! Download today - it's > FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ > > From mail2karuna@hotmail.com Wed Jun 28 04:51:51 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 8EFB63B0079 for ; Wed, 28 Jun 2006 04:51:51 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00776-08 for ; Wed, 28 Jun 2006 04:51:50 -0400 (EDT) Received: from hotmail.com (bay123-f31.bay123.hotmail.com [207.46.11.111]) by menubar.gnome.org (Postfix) with ESMTP id 2CB433B0005 for ; Wed, 28 Jun 2006 04:51:50 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 28 Jun 2006 01:50:10 -0700 Message-ID: Received: from 207.46.11.123 by by123fd.bay123.hotmail.msn.com with HTTP; Wed, 28 Jun 2006 08:50:07 GMT X-Originating-IP: [62.193.226.74] X-Originating-Email: [mail2karuna@hotmail.com] X-Sender: mail2karuna@hotmail.com In-Reply-To: <44A23718.3020008@tiscali.it> From: "karuna karan" To: fiandro@tiscali.it Subject: Re: Failed building GTK with the DFB backend Date: Wed, 28 Jun 2006 08:50:07 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 28 Jun 2006 08:50:10.0376 (UTC) FILETIME=[DCE6EC80:01C69A8F] X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=1.17 tagged_above=-999 required=2 tests=[AWL=-3.240, BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2, DNS_FROM_RFC_POST=1.708, MSGID_FROM_MTA_HEADER=0, RCVD_IN_BL_SPAMCOP_NET=1.558, RCVD_IN_SBL=3.16, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, TW_DF=0.077, TW_GD=0.077, TW_GT=0.077, TW_KD=0.077, TW_TK=0.077] X-Spam-Score: 1.17 X-Spam-Level: * Cc: gtk-devel-list@gnome.org, skar@tataelxsi.co.in, amirthakaruna@tataelxsi.co.in X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2006 08:51:51 -0000 hi, we are already working with DirectFB 0.9.25.1 and GTK 2.9.4(released) we will start work with GTK 2.9.4 from CVS as suggested by you. we will get back if any issue arises. Thanks, Karunakaran A. >From: Attilio Fiandrotti >A couple of days ago mike checked in the patch that excludes from >compilation some extra code that requires DFB 0.9.25 in the case DFN 0.9.24 >is used. >Use CVS sources or apply to GTK 2.9.4 gdkdirectfb.h and >gdkwindow-directfb.c from current SVN. >If you're a Debian user and run on i386, simply install cairodfb and gtkdfb >packages [1] which were made recently available (other archs will follow >soon). > >Attilio > >[1] http://mail.directfb.org/pipermail/directfb-dev/2006-June/001973.html > >karuna karan wrote: >>Hi, >> >>we have tried to build gtk+ 2.9.4 with backend dfb. >>we got the follwing error while building, >> >>gdkwindow-directfb.c: In function `gdk_directfb_create_child_window': >>gdkwindow-directfb.c:2508: error: structure has no member named >>`GetPosition' >>make[4]: *** [gdkwindow-directfb.lo] Error 1 >>make[4]: Leaving directory `/root/new/gtk+-2.9.4/gdk/directfb' >>make[3]: *** [all-recursive] Error 1 >>make[3]: Leaving directory `/root/new/gtk+-2.9.4/gdk' >>make[2]: *** [all] Error 2 >>make[2]: Leaving directory `/root/new/gtk+-2.9.4/gdk' >>make[1]: *** [all-recursive] Error 1 >>make[1]: Leaving directory `/root/new/gtk+-2.9.4' >>make: *** [all] Error 2 >> >>so kindly give feedback on this issue.. >> >>Thanks, >>Karunakaran A. >> >> >> >> >>>From: Suman Kar >>>Reply-To: Suman Kar >>>To: "'Attilio Fiandrotti'" , "'karuna karan'" >>> >>>CC: >>>Subject: RE: Failed building GTK with the DFB backend >>>Date: Tue, 27 Jun 2006 16:51:13 +0530 >>> >>>Hello Attilio, >>> >>>Thanks for the quick update. However, the problem goes away when we added >>>the following: >>> >>>gboolean >>>gdk_screen_is_composited (GdkScreen *screen) >>>{ >>> g_return_val_if_fail (GDK_IS_SCREEN (screen), NULL); >>> return FALSE; >>>} >>> >>> >>>is added to gdkscreen-directfb.c (from >>>http://mail.gnome.org/archives/gtk-devel-list/2006-May/msg00210.html ). >>> >>>We will definitely try building gtk+2.9.4 and will get back in case there >>>are any issues. >>> >>>One more thing: we would be really interested in gtk+-2.10. Any idea when >>>this will be out? >>> >>>Regards, >>>Suman. >>> >>>-----Original Message----- >>>From: Attilio Fiandrotti [mailto:fiandro@tiscali.it] >>>Sent: Tuesday, June 27, 2006 3:40 PM >>>To: karuna karan >>>Cc: gtk-devel-list@gnome.org; skar@tataelxsi.co.in >>>Subject: Re: Failed building GTK with the DFB backend >>> >>> >>>karuna karan wrote: >>> > Hi all, >>> > >>> > I tried to build gtk 2.9.1 with directFB backend with following >>> > dependencies, >>> >>>DFB support in was broken: you should try 2.9.4 or follow instructions >>>in the wiki page to build from sratch. >>>If you're a debian user, you can also use precompiled i386 official >>>packages that were built this week >>> >>>http://download.dajobe.org/debian/experimental/ <-cairodfb >>>http://people.debian.org/~joss/packages/ <-gtkdfb >>> >>>Attilio >>> >>>The information contained in this electronic message and any attachments >>>to this message are intended for the exclusive use of the addressee(s)and >>>may contain confidential or privileged information. If you are not the >>>intended recipient, please notify the sender or >>>administrator@tataelxsi.co.in >> >> >>_________________________________________________________________ >>Express yourself instantly with MSN Messenger! Download today - it's FREE! >>http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ >> >> > _________________________________________________________________ Dont just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/ From mail2karuna@hotmail.com Wed Jun 28 04:57:44 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id EB6A23B00A2 for ; Wed, 28 Jun 2006 04:57:43 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01098-06 for ; Wed, 28 Jun 2006 04:57:42 -0400 (EDT) Received: from bay0-omc3-s25.bay0.hotmail.com (bay0-omc3-s25.bay0.hotmail.com [65.54.246.225]) by menubar.gnome.org (Postfix) with ESMTP id 8E64F3B0002 for ; Wed, 28 Jun 2006 04:57:42 -0400 (EDT) Received: from hotmail.com ([207.46.11.110]) by bay0-omc3-s25.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Jun 2006 01:57:15 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 28 Jun 2006 01:57:15 -0700 Message-ID: Received: from 207.46.11.123 by by123fd.bay123.hotmail.msn.com with HTTP; Wed, 28 Jun 2006 08:57:12 GMT X-Originating-IP: [62.193.235.46] X-Originating-Email: [mail2karuna@hotmail.com] X-Sender: mail2karuna@hotmail.com In-Reply-To: <006101c69a90$871e5d00$361b320a@telxsi.com> From: "karuna karan" To: gtk-devel-list@gnome.org Subject: RE: Failed building GTK with the DFB backend Date: Wed, 28 Jun 2006 08:57:12 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 28 Jun 2006 08:57:15.0331 (UTC) FILETIME=[DA31E930:01C69A90] X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-0.194 tagged_above=-999 required=2 tests=[AWL=-1.445, BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2, DNS_FROM_RFC_POST=1.708, MSGID_FROM_MTA_HEADER=0, RCVD_IN_BL_SPAMCOP_NET=1.558, SPF_PASS=-0.001, TW_DF=0.077, TW_GD=0.077, TW_GT=0.077, TW_KD=0.077, TW_TK=0.077] X-Spam-Score: -0.194 X-Spam-Level: Cc: amirthakaruna@tataelxsi.co.in, skar@tataelxsi.co.in X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2006 08:57:44 -0000 hi, we are already working with DirectFB 0.9.25.1 and GTK 2.9.4(released) we will start work with GTK 2.9.4 from CVS as suggested by you. we will get back if any issue arises. Thanks, Karunakaran A. >From: Attilio Fiandrotti >A couple of days ago mike checked in the patch that excludes from >compilation some extra code that requires DFB 0.9.25 in the case DFN 0.9.24 >is used. >Use CVS sources or apply to GTK 2.9.4 gdkdirectfb.h and >gdkwindow-directfb.c from current SVN. >If you're a Debian user and run on i386, simply install cairodfb and gtkdfb >packages [1] which were made recently available (other archs will follow >soon). > >Attilio > >[1] http://mail.directfb.org/pipermail/directfb-dev/2006-June/001973.html > >karuna karan wrote: >>Hi, >> >>we have tried to build gtk+ 2.9.4 with backend dfb. >>we got the follwing error while building, >> >>gdkwindow-directfb.c: In function `gdk_directfb_create_child_window': >>gdkwindow-directfb.c:2508: error: structure has no member named >>`GetPosition' >>make[4]: *** [gdkwindow-directfb.lo] Error 1 >>make[4]: Leaving directory `/root/new/gtk+-2.9.4/gdk/directfb' >>make[3]: *** [all-recursive] Error 1 >>make[3]: Leaving directory `/root/new/gtk+-2.9.4/gdk' >>make[2]: *** [all] Error 2 >>make[2]: Leaving directory `/root/new/gtk+-2.9.4/gdk' >>make[1]: *** [all-recursive] Error 1 >>make[1]: Leaving directory `/root/new/gtk+-2.9.4' >>make: *** [all] Error 2 >> >>so kindly give feedback on this issue.. >> >>Thanks, >>Karunakaran A. >> >> >> >> >>>From: Suman Kar >>>Reply-To: Suman Kar >>>To: "'Attilio Fiandrotti'" , "'karuna karan'" >>> >>>CC: >>>Subject: RE: Failed building GTK with the DFB backend >>>Date: Tue, 27 Jun 2006 16:51:13 +0530 >>> >>>Hello Attilio, >>> >>>Thanks for the quick update. However, the problem goes away when we added >>>the following: >>> >>>gboolean >>>gdk_screen_is_composited (GdkScreen *screen) >>>{ >>> g_return_val_if_fail (GDK_IS_SCREEN (screen), NULL); >>> return FALSE; >>>} >>> >>> >>>is added to gdkscreen-directfb.c (from >>>http://mail.gnome.org/archives/gtk-devel-list/2006-May/msg00210.html ). >>> >>>We will definitely try building gtk+2.9.4 and will get back in case there > >>>are any issues. > >>> > >>>One more thing: we would be really interested in gtk+-2.10. Any idea >when > >>>this will be out? > >>> > >>>Regards, > >>>Suman. > >>> > >>>-----Original Message----- > >>>From: Attilio Fiandrotti [mailto:fiandro@tiscali.it] > >>>Sent: Tuesday, June 27, 2006 3:40 PM > >>>To: karuna karan > >>>Cc: gtk-devel-list@gnome.org; skar@tataelxsi.co.in > >>>Subject: Re: Failed building GTK with the DFB backend > >>> > >>> > >>>karuna karan wrote: > >>> > Hi all, > >>> > > >>> > I tried to build gtk 2.9.1 with directFB backend with following > >>> > dependencies, > >>> > >>>DFB support in was broken: you should try 2.9.4 or follow instructions > >>>in the wiki page to build from sratch. > >>>If you're a debian user, you can also use precompiled i386 official > >>>packages that were built this week > >>> > >>>http://download.dajobe.org/debian/experimental/ <-cairodfb > >>>http://people.debian.org/~joss/packages/ <-gtkdfb > >>> > >>>Attilio > >>> > >>>The information contained in this electronic message and any >attachments > >>>to this message are intended for the exclusive use of the >addressee(s)and > >>>may contain confidential or privileged information. If you are not the > >>>intended recipient, please notify the sender or > >>>administrator@tataelxsi.co.in > >> > >> > >>_________________________________________________________________ > >>Express yourself instantly with MSN Messenger! Download today - it's >FREE! > >>http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ > >> > >> > > > >_________________________________________________________________ >Dont just search. Find. Check out the new MSN Search! >http://search.msn.click-url.com/go/onm00200636ave/direct/01/ > >The information contained in this electronic message and any attachments to >this message are intended for the exclusive use of the addressee(s)and may >contain confidential or privileged information. If you are not the intended >recipient, please notify the sender or administrator@tataelxsi.co.in _________________________________________________________________ Dont just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/ From dave.foster@gmail.com Tue Jun 27 23:09:46 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id A42223B0010 for ; Tue, 27 Jun 2006 23:09:46 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25505-01 for ; Tue, 27 Jun 2006 23:09:45 -0400 (EDT) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.225]) by menubar.gnome.org (Postfix) with ESMTP id CEB183B0005 for ; Tue, 27 Jun 2006 23:09:44 -0400 (EDT) Received: by wr-out-0506.google.com with SMTP id i4so303425wra for ; Tue, 27 Jun 2006 20:08:24 -0700 (PDT) Received: by 10.54.80.7 with SMTP id d7mr394957wrb; Tue, 27 Jun 2006 20:08:24 -0700 (PDT) Received: from ?192.168.1.107? ( [68.0.246.8]) by mx.gmail.com with ESMTP id 64sm2194346wra.2006.06.27.20.08.24; Tue, 27 Jun 2006 20:08:24 -0700 (PDT) Subject: gdk_display_close segfault? From: Dave Foster To: gtk-devel-list@gnome.org Content-Type: text/plain Date: Wed, 28 Jun 2006 01:01:55 -0400 Message-Id: <1151470915.4791.3.camel@neptune.minuslab.net> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.6 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.6 X-Spam-Level: X-Mailman-Approved-At: Wed, 28 Jun 2006 07:11:10 -0400 X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2006 03:09:46 -0000 Hi, I've been trying to write a small section of code in my program which makes a second connection to the X display, using gtkmm.. I kept having problems, after rewriting it about 5 or 6 times, I tried writing it in straight gdk, and STILL got the problems. I seem to get a segfault whenever I call gdk_display_close(). Here is a rediculously simple example that gives the problem: Glib::ustring disp = ":0.0"; GdkDisplay* gdisp = gdk_display_open(disp.c_str()); if (!gdisp) ... gdk_display_close(gdisp); /* Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1224202560 (LWP 5689)] 0xb7b413d0 in gdk_display_x11_dispose () from /usr/lib/libgdk-x11-2.0.so.0 (gdb) bt #0 0xb7b413d0 in gdk_display_x11_dispose () from /usr/lib/libgdk-x11-2.0.so.0 #1 0xb7a11f2b in g_object_unref () from /usr/lib/libgobject-2.0.so.0 #2 0xb7b20c04 in gdk_display_close () from /usr/lib/libgdk-x11-2.0.so.0 #3 0x080571d5 in SetBG::set_bg (disp=@0xbfe1b2b0, file=@0xbfe1b2ac, mode=SetBG::SET_SCALE, bgcolor=@0xbfe1b2a8) at SetBG.cc:67 ... */ The display is opening fine. I'm running: gtk: 2.8.17-1 glib: 2.10.2-1 (hmm, didn't notice that before,t he 2.8 vs 2.10 thing, could that be it?) Anyway, I've spent all night trying to debug this and weeks trying to sort this problem out in my program. What is up with this, what can I do? thanks all. dave From fiandro@tiscali.it Wed Jun 28 07:47:12 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id EF7893B0087 for ; Wed, 28 Jun 2006 07:47:11 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08611-03 for ; Wed, 28 Jun 2006 07:47:10 -0400 (EDT) Received: from polito.it (anacreon.polito.it [130.192.3.82]) by menubar.gnome.org (Postfix) with ESMTP id AEB163B00A0 for ; Wed, 28 Jun 2006 07:47:09 -0400 (EDT) X-ExtScanner: Niversoft's FindAttachments (free) Received: from [130.192.31.127] (HELO [130.192.31.127]) by anacreon.polito.it (CommuniGate Pro SMTP 5.0.9) with ESMTP id 39386694; Wed, 28 Jun 2006 13:46:14 +0200 Message-ID: <44A26D1D.9090905@tiscali.it> Date: Wed, 28 Jun 2006 13:50:53 +0200 From: Attilio Fiandrotti User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.13) Gecko/20060620 Debian/1.7.13-0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Suman Kar Subject: Re: Failed building GTK with the DFB backend References: <000101c69aa6$6547c9d0$381b320a@telxsi.com> In-Reply-To: <000101c69aa6$6547c9d0$381b320a@telxsi.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.35 tagged_above=-999 required=2 tests=[AWL=-0.540, BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2, FORGED_RCVD_HELO=0.135, SPF_NEUTRAL=1.069, TW_DF=0.077, TW_GD=0.077, TW_GT=0.077, TW_KD=0.077, TW_TK=0.077] X-Spam-Score: -1.35 X-Spam-Level: Cc: gtk-devel-list@gnome.org, amirthakaruna@tataelxsi.co.in X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2006 11:47:12 -0000 I apologize for my mistake: only now i realize taht getposition() and getsize() were introduced *after* DFB 0.9.25 was released! Yesterday mike checked in a patch ("Added ifdef to compile with 0.9.24 removes creating a child GdkWindow since it u...") that allows GTK+ to be compiled against DFB >= 0.9.24 (so, also 0.9.25 will do) The correct recipe is: DFB >= 0.9.24 GTK+ HEAD from CVS Attilio Suman Kar wrote: > Hello Attilio, > > Let me try to explain Karuna's problem: we are using the > downloadable source tarball from > http://directfb.org/index.php?path=Main%2FDownloads: > DirectFB-0.9.25.1.tar.gz > > Also, this was released on 03-May-2006. Mike's checkin has happened > on 11-June-2006. Moreover, we could not find the GetPosition() > member in either the http://directfb.org/index.php?path=Main%2FNews > page or in the source files Mike has mentioned in the mail to > the directFB list. > > These indicates to me that this is not really an issue with some path > variable as you suggested. Your inputs are awaited. > > Regards, > Suman. > > -----Original Message----- > From: Attilio Fiandrotti [mailto:fiandro@tiscali.it] > Sent: Wednesday, June 28, 2006 3:03 PM > To: karuna karan > Cc: skar@tataelxsi.co.in; amirthakaruna@tataelxsi.co.in > Subject: Re: Failed building GTK with the DFB backend > > > the symbol GetPosition (and getsize, too) were introduced in DFB 0.9.25 > : if you're trying to compile GTKDFB against DFB 0.9.25, then you must > have provided wrong pkg_config_path or ld_library_path > > Attilio > > karuna karan wrote: > >>hi, >> >>we are already working with DirectFB 0.9.25.1 and GTK 2.9.4(released) >> >>we will start work with GTK 2.9.4 from CVS as suggested by you. >> >>we will get back if any issue arises. >> >>Thanks, >>Karunakaran A. >> >> >> >> >From: Attilio Fiandrotti >> >> >A couple of days ago mike checked in the patch that excludes from >> >compilation some extra code that requires DFB 0.9.25 in the case DFN >>0.9.24 >> >is used. >> >Use CVS sources or apply to GTK 2.9.4 gdkdirectfb.h and >> >gdkwindow-directfb.c from current SVN. >> >If you're a Debian user and run on i386, simply install cairodfb and >>gtkdfb >> >packages [1] which were made recently available (other archs will follow >> >soon). >> > >> >Attilio >> > >> >[1] > > http://mail.directfb.org/pipermail/directfb-dev/2006-June/001973.html > >> > >> >karuna karan wrote: >> >>Hi, >> >> >> >>we have tried to build gtk+ 2.9.4 with backend dfb. >> >>we got the follwing error while building, >> >> >> >>gdkwindow-directfb.c: In function `gdk_directfb_create_child_window': >> >>gdkwindow-directfb.c:2508: error: structure has no member named >> >>`GetPosition' >> >>make[4]: *** [gdkwindow-directfb.lo] Error 1 >> >>make[4]: Leaving directory `/root/new/gtk+-2.9.4/gdk/directfb' >> >>make[3]: *** [all-recursive] Error 1 >> >>make[3]: Leaving directory `/root/new/gtk+-2.9.4/gdk' >> >>make[2]: *** [all] Error 2 >> >>make[2]: Leaving directory `/root/new/gtk+-2.9.4/gdk' >> >>make[1]: *** [all-recursive] Error 1 >> >>make[1]: Leaving directory `/root/new/gtk+-2.9.4' >> >>make: *** [all] Error 2 >> >> >> >>so kindly give feedback on this issue.. >> >> >> >>Thanks, >> >>Karunakaran A. >> >> >> >> >> >> >> >> >> >>>From: Suman Kar >> >>>Reply-To: Suman Kar >> >>>To: "'Attilio Fiandrotti'" , "'karuna >>karan'" >> >>> >> >>>CC: >> >>>Subject: RE: Failed building GTK with the DFB backend >> >>>Date: Tue, 27 Jun 2006 16:51:13 +0530 >> >>> >> >>>Hello Attilio, >> >>> >> >>>Thanks for the quick update. However, the problem goes away when we >>added >> >>>the following: >> >>> >> >>>gboolean >> >>>gdk_screen_is_composited (GdkScreen *screen) >> >>>{ >> >>> g_return_val_if_fail (GDK_IS_SCREEN (screen), NULL); >> >>> return FALSE; >> >>>} >> >>> >> >>> >> >>>is added to gdkscreen-directfb.c (from >> >> >>>>>http://mail.gnome.org/archives/gtk-devel-list/2006-May/msg00210.html ). >> >> >>> >> >>>We will definitely try building gtk+2.9.4 and will get back in case >>there >> >> >>>>>>are any issues. >>>>>> >>>>>>One more thing: we would be really interested in gtk+-2.10. Any >>> >>>idea when >>> >>>>>>this will be out? >>>>>> >>>>>>Regards, >>>>>>Suman. >>>>>> >>>>>>-----Original Message----- >>>>>>From: Attilio Fiandrotti [mailto:fiandro@tiscali.it] >>>>>>Sent: Tuesday, June 27, 2006 3:40 PM >>>>>>To: karuna karan >>>>>>Cc: gtk-devel-list@gnome.org; skar@tataelxsi.co.in >>>>>>Subject: Re: Failed building GTK with the DFB backend >>>>>> >>>>>> >>>>>>karuna karan wrote: >>>>>> >>>>>>>Hi all, >>>>>>> >>>>>>>I tried to build gtk 2.9.1 with directFB backend with following >>>>>>>dependencies, >>>>>> >>>>>>DFB support in was broken: you should try 2.9.4 or follow instructions >>>>>>in the wiki page to build from sratch. >>>>>>If you're a debian user, you can also use precompiled i386 official >>>>>>packages that were built this week >>>>>> >>>>>>http://download.dajobe.org/debian/experimental/ <-cairodfb >>>>>>http://people.debian.org/~joss/packages/ <-gtkdfb >>>>>> >>>>>>Attilio >>>>>> >>>>>>The information contained in this electronic message and any >>> >>>attachments >>> >>>>>>to this message are intended for the exclusive use of the >>> >>>addressee(s)and >>> >>>>>>may contain confidential or privileged information. If you are not the >>>>>>intended recipient, please notify the sender or >>>>>>administrator@tataelxsi.co.in >>>>> >>>>> >>>>>_________________________________________________________________ >>>>>Express yourself instantly with MSN Messenger! Download today - it's >>> >>>FREE! >>> >>>>>http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ >>>>> >>>>> >>>> >>>_________________________________________________________________ >>>Dont just search. Find. Check out the new MSN Search! >>>http://search.msn.click-url.com/go/onm00200636ave/direct/01/ >>> >>>The information contained in this electronic message and any >>>attachments to this message are intended for the exclusive use of the >>>addressee(s)and may contain confidential or privileged information. If >>>you are not the intended recipient, please notify the sender or >>>administrator@tataelxsi.co.in >> >> >>_________________________________________________________________ >>Dont just search. Find. Check out the new MSN Search! >>http://search.msn.click-url.com/go/onm00200636ave/direct/01/ >> >> >> >> >>------------------------------------------------------------------------ >> >>The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s)and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender or administrator@tataelxsi.co.in From skar@tataelxsi.co.in Wed Jun 28 07:31:56 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id B3F193B006C for ; Wed, 28 Jun 2006 07:31:56 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07955-07 for ; Wed, 28 Jun 2006 07:31:55 -0400 (EDT) Received: from mail.tataelxsi.co.in (mail.tataelxsi.co.in [203.200.1.48]) by menubar.gnome.org (Postfix) with ESMTP id 0CA9D3B00F3 for ; Wed, 28 Jun 2006 07:31:53 -0400 (EDT) Received: from skar (tataelxsi.co.in [203.197.169.80] (may be forged)) by mail.tataelxsi.co.in (MOS 3.7.4b-GA) with ESMTP id BRJ72122 (AUTH skar); Wed, 28 Jun 2006 17:02:27 +0530 (IST) From: Suman Kar To: "'Attilio Fiandrotti'" , Subject: RE: Failed building GTK with the DFB backend Date: Wed, 28 Jun 2006 17:01:26 +0530 Message-ID: <000101c69aa6$6547c9d0$381b320a@telxsi.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <44A24CDC.4070707@tiscali.it> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Junkmail: Blacklisted Content-Type: multipart/mixed; boundary="MIRAPOINT_PART1_44a268cc" X-Mirapoint-Sig: mail.tataelxsi.co.in X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.291 tagged_above=-999 required=2 tests=[AWL=-0.635, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.558, TW_DF=0.077, TW_GD=0.077, TW_GT=0.077, TW_KD=0.077, TW_TK=0.077] X-Spam-Score: -1.291 X-Spam-Level: X-Mailman-Approved-At: Wed, 28 Jun 2006 08:28:51 -0400 Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: Suman Kar List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2006 11:31:56 -0000 --MIRAPOINT_PART1_44a268cc Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 8bit Hello Attilio, Let me try to explain Karuna's problem: we are using the downloadable source tarball from http://directfb.org/index.php?path=Main%2FDownloads: DirectFB-0.9.25.1.tar.gz Also, this was released on 03-May-2006. Mike's checkin has happened on 11-June-2006. Moreover, we could not find the GetPosition() member in either the http://directfb.org/index.php?path=Main%2FNews page or in the source files Mike has mentioned in the mail to the directFB list. These indicates to me that this is not really an issue with some path variable as you suggested. Your inputs are awaited. Regards, Suman. -----Original Message----- From: Attilio Fiandrotti [mailto:fiandro@tiscali.it] Sent: Wednesday, June 28, 2006 3:03 PM To: karuna karan Cc: skar@tataelxsi.co.in; amirthakaruna@tataelxsi.co.in Subject: Re: Failed building GTK with the DFB backend the symbol GetPosition (and getsize, too) were introduced in DFB 0.9.25 : if you're trying to compile GTKDFB against DFB 0.9.25, then you must have provided wrong pkg_config_path or ld_library_path Attilio karuna karan wrote: > hi, > > we are already working with DirectFB 0.9.25.1 and GTK 2.9.4(released) > > we will start work with GTK 2.9.4 from CVS as suggested by you. > > we will get back if any issue arises. > > Thanks, > Karunakaran A. > > > > >From: Attilio Fiandrotti > > >A couple of days ago mike checked in the patch that excludes from > >compilation some extra code that requires DFB 0.9.25 in the case DFN > 0.9.24 > >is used. > >Use CVS sources or apply to GTK 2.9.4 gdkdirectfb.h and > >gdkwindow-directfb.c from current SVN. > >If you're a Debian user and run on i386, simply install cairodfb and > gtkdfb > >packages [1] which were made recently available (other archs will follow > >soon). > > > >Attilio > > > >[1] http://mail.directfb.org/pipermail/directfb-dev/2006-June/001973.html > > > >karuna karan wrote: > >>Hi, > >> > >>we have tried to build gtk+ 2.9.4 with backend dfb. > >>we got the follwing error while building, > >> > >>gdkwindow-directfb.c: In function `gdk_directfb_create_child_window': > >>gdkwindow-directfb.c:2508: error: structure has no member named > >>`GetPosition' > >>make[4]: *** [gdkwindow-directfb.lo] Error 1 > >>make[4]: Leaving directory `/root/new/gtk+-2.9.4/gdk/directfb' > >>make[3]: *** [all-recursive] Error 1 > >>make[3]: Leaving directory `/root/new/gtk+-2.9.4/gdk' > >>make[2]: *** [all] Error 2 > >>make[2]: Leaving directory `/root/new/gtk+-2.9.4/gdk' > >>make[1]: *** [all-recursive] Error 1 > >>make[1]: Leaving directory `/root/new/gtk+-2.9.4' > >>make: *** [all] Error 2 > >> > >>so kindly give feedback on this issue.. > >> > >>Thanks, > >>Karunakaran A. > >> > >> > >> > >> > >>>From: Suman Kar > >>>Reply-To: Suman Kar > >>>To: "'Attilio Fiandrotti'" , "'karuna > karan'" > >>> > >>>CC: > >>>Subject: RE: Failed building GTK with the DFB backend > >>>Date: Tue, 27 Jun 2006 16:51:13 +0530 > >>> > >>>Hello Attilio, > >>> > >>>Thanks for the quick update. However, the problem goes away when we > added > >>>the following: > >>> > >>>gboolean > >>>gdk_screen_is_composited (GdkScreen *screen) > >>>{ > >>> g_return_val_if_fail (GDK_IS_SCREEN (screen), NULL); > >>> return FALSE; > >>>} > >>> > >>> > >>>is added to gdkscreen-directfb.c (from > >>>> http://mail.gnome.org/archives/gtk-devel-list/2006-May/msg00210.html ). > > >>> > >>>We will definitely try building gtk+2.9.4 and will get back in case > there > >> >>>are any issues. >> >>> >> >>>One more thing: we would be really interested in gtk+-2.10. Any >> idea when >> >>>this will be out? >> >>> >> >>>Regards, >> >>>Suman. >> >>> >> >>>-----Original Message----- >> >>>From: Attilio Fiandrotti [mailto:fiandro@tiscali.it] >> >>>Sent: Tuesday, June 27, 2006 3:40 PM >> >>>To: karuna karan >> >>>Cc: gtk-devel-list@gnome.org; skar@tataelxsi.co.in >> >>>Subject: Re: Failed building GTK with the DFB backend >> >>> >> >>> >> >>>karuna karan wrote: >> >>> > Hi all, >> >>> > >> >>> > I tried to build gtk 2.9.1 with directFB backend with following >> >>> > dependencies, >> >>> >> >>>DFB support in was broken: you should try 2.9.4 or follow instructions >> >>>in the wiki page to build from sratch. >> >>>If you're a debian user, you can also use precompiled i386 official >> >>>packages that were built this week >> >>> >> >>>http://download.dajobe.org/debian/experimental/ <-cairodfb >> >>>http://people.debian.org/~joss/packages/ <-gtkdfb >> >>> >> >>>Attilio >> >>> >> >>>The information contained in this electronic message and any >> attachments >> >>>to this message are intended for the exclusive use of the >> addressee(s)and >> >>>may contain confidential or privileged information. If you are not the >> >>>intended recipient, please notify the sender or >> >>>administrator@tataelxsi.co.in >> >> >> >> >> >>_________________________________________________________________ >> >>Express yourself instantly with MSN Messenger! Download today - it's >> FREE! >> >>http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ >> >> >> >> >> > >> >> _________________________________________________________________ >> Dont just search. Find. Check out the new MSN Search! >> http://search.msn.click-url.com/go/onm00200636ave/direct/01/ >> >> The information contained in this electronic message and any >> attachments to this message are intended for the exclusive use of the >> addressee(s)and may contain confidential or privileged information. If >> you are not the intended recipient, please notify the sender or >> administrator@tataelxsi.co.in > > > _________________________________________________________________ > Dont just search. Find. Check out the new MSN Search! > http://search.msn.click-url.com/go/onm00200636ave/direct/01/ > > --MIRAPOINT_PART1_44a268cc Content-Disposition: inline The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s)and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender or administrator@tataelxsi.co.in --MIRAPOINT_PART1_44a268cc-- From skar@tataelxsi.co.in Wed Jun 28 08:09:32 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id B55753B016E for ; Wed, 28 Jun 2006 08:09:32 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09711-02 for ; Wed, 28 Jun 2006 08:09:31 -0400 (EDT) Received: from mail.tataelxsi.co.in (mail.tataelxsi.co.in [203.200.1.48]) by menubar.gnome.org (Postfix) with ESMTP id B45AB3B01C1 for ; Wed, 28 Jun 2006 08:09:29 -0400 (EDT) Received: from skar (tataelxsi.co.in [203.197.169.80] (may be forged)) by mail.tataelxsi.co.in (MOS 3.7.4b-GA) with ESMTP id BRJ80256 (AUTH skar); Wed, 28 Jun 2006 17:40:28 +0530 (IST) From: Suman Kar To: "'Attilio Fiandrotti'" Subject: RE: Failed building GTK with the DFB backend Date: Wed, 28 Jun 2006 17:39:28 +0530 Message-ID: <000801c69aab$b5138bc0$381b320a@telxsi.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <44A26D1D.9090905@tiscali.it> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Junkmail: Blacklisted Content-Type: multipart/mixed; boundary="MIRAPOINT_PART1_44a271b6" X-Mirapoint-Sig: mail.tataelxsi.co.in X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.227 tagged_above=-999 required=2 tests=[AWL=-0.571, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.558, TW_DF=0.077, TW_GD=0.077, TW_GT=0.077, TW_KD=0.077, TW_TK=0.077] X-Spam-Score: -1.227 X-Spam-Level: X-Mailman-Approved-At: Wed, 28 Jun 2006 08:29:04 -0400 Cc: gtk-devel-list@gnome.org, amirthakaruna@tataelxsi.co.in X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: Suman Kar List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2006 12:09:32 -0000 --MIRAPOINT_PART1_44a271b6 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 8bit Can you please post a link to Mike's change? URL to the CVS will do. I am a little confused as the GNOME cvs did not show any results when searching for entries by memmel and the directFB CVS did not throw up a check-in in the last two days. Regards, Suman. -----Original Message----- From: Attilio Fiandrotti [mailto:fiandro@tiscali.it] Sent: Wednesday, June 28, 2006 5:21 PM To: Suman Kar Cc: amirthakaruna@tataelxsi.co.in; gtk-devel-list@gnome.org Subject: Re: Failed building GTK with the DFB backend I apologize for my mistake: only now i realize taht getposition() and getsize() were introduced *after* DFB 0.9.25 was released! Yesterday mike checked in a patch ("Added ifdef to compile with 0.9.24 removes creating a child GdkWindow since it u...") that allows GTK+ to be compiled against DFB >= 0.9.24 (so, also 0.9.25 will do) The correct recipe is: DFB >= 0.9.24 GTK+ HEAD from CVS Attilio Suman Kar wrote: > Hello Attilio, > > Let me try to explain Karuna's problem: we are using the > downloadable source tarball from > http://directfb.org/index.php?path=Main%2FDownloads: > DirectFB-0.9.25.1.tar.gz > > Also, this was released on 03-May-2006. Mike's checkin has happened > on 11-June-2006. Moreover, we could not find the GetPosition() > member in either the http://directfb.org/index.php?path=Main%2FNews > page or in the source files Mike has mentioned in the mail to > the directFB list. > > These indicates to me that this is not really an issue with some path > variable as you suggested. Your inputs are awaited. > > Regards, > Suman. > > -----Original Message----- > From: Attilio Fiandrotti [mailto:fiandro@tiscali.it] > Sent: Wednesday, June 28, 2006 3:03 PM > To: karuna karan > Cc: skar@tataelxsi.co.in; amirthakaruna@tataelxsi.co.in > Subject: Re: Failed building GTK with the DFB backend > > > the symbol GetPosition (and getsize, too) were introduced in DFB 0.9.25 > : if you're trying to compile GTKDFB against DFB 0.9.25, then you must > have provided wrong pkg_config_path or ld_library_path > > Attilio > > karuna karan wrote: > >>hi, >> >>we are already working with DirectFB 0.9.25.1 and GTK 2.9.4(released) >> >>we will start work with GTK 2.9.4 from CVS as suggested by you. >> >>we will get back if any issue arises. >> >>Thanks, >>Karunakaran A. >> >> >> >> >From: Attilio Fiandrotti >> >> >A couple of days ago mike checked in the patch that excludes from >> >compilation some extra code that requires DFB 0.9.25 in the case DFN >>0.9.24 >> >is used. >> >Use CVS sources or apply to GTK 2.9.4 gdkdirectfb.h and >> >gdkwindow-directfb.c from current SVN. >> >If you're a Debian user and run on i386, simply install cairodfb and >>gtkdfb >> >packages [1] which were made recently available (other archs will follow >> >soon). >> > >> >Attilio >> > >> >[1] > > http://mail.directfb.org/pipermail/directfb-dev/2006-June/001973.html > >> > >> >karuna karan wrote: >> >>Hi, >> >> >> >>we have tried to build gtk+ 2.9.4 with backend dfb. >> >>we got the follwing error while building, >> >> >> >>gdkwindow-directfb.c: In function `gdk_directfb_create_child_window': >> >>gdkwindow-directfb.c:2508: error: structure has no member named >> >>`GetPosition' >> >>make[4]: *** [gdkwindow-directfb.lo] Error 1 >> >>make[4]: Leaving directory `/root/new/gtk+-2.9.4/gdk/directfb' >> >>make[3]: *** [all-recursive] Error 1 >> >>make[3]: Leaving directory `/root/new/gtk+-2.9.4/gdk' >> >>make[2]: *** [all] Error 2 >> >>make[2]: Leaving directory `/root/new/gtk+-2.9.4/gdk' >> >>make[1]: *** [all-recursive] Error 1 >> >>make[1]: Leaving directory `/root/new/gtk+-2.9.4' >> >>make: *** [all] Error 2 >> >> >> >>so kindly give feedback on this issue.. >> >> >> >>Thanks, >> >>Karunakaran A. >> >> >> >> >> >> >> >> >> >>>From: Suman Kar >> >>>Reply-To: Suman Kar >> >>>To: "'Attilio Fiandrotti'" , "'karuna >>karan'" >> >>> >> >>>CC: >> >>>Subject: RE: Failed building GTK with the DFB backend >> >>>Date: Tue, 27 Jun 2006 16:51:13 +0530 >> >>> >> >>>Hello Attilio, >> >>> >> >>>Thanks for the quick update. However, the problem goes away when we >>added >> >>>the following: >> >>> >> >>>gboolean >> >>>gdk_screen_is_composited (GdkScreen *screen) >> >>>{ >> >>> g_return_val_if_fail (GDK_IS_SCREEN (screen), NULL); >> >>> return FALSE; >> >>>} >> >>> >> >>> >> >>>is added to gdkscreen-directfb.c (from >> >> >>>>>http://mail.gnome.org/archives/gtk-devel-list/2006-May/msg00210.html ). >> >> >>> >> >>>We will definitely try building gtk+2.9.4 and will get back in case >>there >> >> >>>>>>are any issues. >>>>>> >>>>>>One more thing: we would be really interested in gtk+-2.10. Any >>> >>>idea when >>> >>>>>>this will be out? >>>>>> >>>>>>Regards, >>>>>>Suman. >>>>>> >>>>>>-----Original Message----- >>>>>>From: Attilio Fiandrotti [mailto:fiandro@tiscali.it] >>>>>>Sent: Tuesday, June 27, 2006 3:40 PM >>>>>>To: karuna karan >>>>>>Cc: gtk-devel-list@gnome.org; skar@tataelxsi.co.in >>>>>>Subject: Re: Failed building GTK with the DFB backend >>>>>> >>>>>> >>>>>>karuna karan wrote: >>>>>> >>>>>>>Hi all, >>>>>>> >>>>>>>I tried to build gtk 2.9.1 with directFB backend with following >>>>>>>dependencies, >>>>>> >>>>>>DFB support in was broken: you should try 2.9.4 or follow instructions >>>>>>in the wiki page to build from sratch. >>>>>>If you're a debian user, you can also use precompiled i386 official >>>>>>packages that were built this week >>>>>> >>>>>>http://download.dajobe.org/debian/experimental/ <-cairodfb >>>>>>http://people.debian.org/~joss/packages/ <-gtkdfb >>>>>> >>>>>>Attilio >>>>>> >>>>>>The information contained in this electronic message and any >>> >>>attachments >>> >>>>>>to this message are intended for the exclusive use of the >>> >>>addressee(s)and >>> >>>>>>may contain confidential or privileged information. If you are not the >>>>>>intended recipient, please notify the sender or >>>>>>administrator@tataelxsi.co.in >>>>> >>>>> >>>>>_________________________________________________________________ >>>>>Express yourself instantly with MSN Messenger! Download today - it's >>> >>>FREE! >>> >>>>>http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ >>>>> >>>>> >>>> >>>_________________________________________________________________ >>>Dont just search. Find. Check out the new MSN Search! >>>http://search.msn.click-url.com/go/onm00200636ave/direct/01/ >>> >>>The information contained in this electronic message and any >>>attachments to this message are intended for the exclusive use of the >>>addressee(s)and may contain confidential or privileged information. If >>>you are not the intended recipient, please notify the sender or >>>administrator@tataelxsi.co.in >> >> >>_________________________________________________________________ >>Dont just search. Find. Check out the new MSN Search! >>http://search.msn.click-url.com/go/onm00200636ave/direct/01/ >> >> >> >> >>------------------------------------------------------------------------ >> >>The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s)and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender or administrator@tataelxsi.co.in --MIRAPOINT_PART1_44a271b6 Content-Disposition: inline The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s)and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender or administrator@tataelxsi.co.in --MIRAPOINT_PART1_44a271b6-- From skar@tataelxsi.co.in Wed Jun 28 08:23:02 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 0B3E43B00B1 for ; Wed, 28 Jun 2006 08:23:02 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10159-01 for ; Wed, 28 Jun 2006 08:23:01 -0400 (EDT) Received: from mail.tataelxsi.co.in (mail.tataelxsi.co.in [203.200.1.48]) by menubar.gnome.org (Postfix) with ESMTP id 8F3FE3B006C for ; Wed, 28 Jun 2006 08:23:00 -0400 (EDT) Received: from skar (tataelxsi.co.in [203.197.169.80] (may be forged)) by mail.tataelxsi.co.in (MOS 3.7.4b-GA) with ESMTP id BRJ83266 (AUTH skar); Wed, 28 Jun 2006 17:53:15 +0530 (IST) From: Suman Kar To: "'Matthias Clasen'" Subject: RE: Failed building GTK with the DFB backend Date: Wed, 28 Jun 2006 17:52:15 +0530 Message-ID: <000a01c69aad$7e2b6270$381b320a@telxsi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Junkmail: Blacklisted X-Mirapoint-Sig: mail.tataelxsi.co.in X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-0.029 tagged_above=-999 required=2 tests=[AWL=-1.665, BAYES_50=0.001, RCVD_IN_BL_SPAMCOP_NET=1.558, TW_GT=0.077] X-Spam-Score: -0.029 X-Spam-Level: X-Mailman-Approved-At: Wed, 28 Jun 2006 08:29:19 -0400 Cc: gtk-devel-list@gnome.org, Karunakaran A X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: Suman Kar List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2006 12:23:02 -0000 Matthias, Thanks for the update! Regards, Suman. -----Original Message----- From: Matthias Clasen [mailto:matthias.clasen@gmail.com] Sent: Wednesday, June 28, 2006 12:39 PM To: Suman Kar Cc: Attilio Fiandrotti; karuna karan; gtk-devel-list@gnome.org Subject: Re: Failed building GTK with the DFB backend On 6/27/06, Suman Kar wrote: > One more thing: we would be really interested in gtk+-2.10. Any idea when > this will be out? > I'll start working on the release when I'm back from Guadec next week. The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s)and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender or administrator@tataelxsi.co.in From matthias.clasen@gmail.com Wed Jun 28 09:56:21 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id A02133B0238 for ; Wed, 28 Jun 2006 09:56:21 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14093-02 for ; Wed, 28 Jun 2006 09:56:20 -0400 (EDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.183]) by menubar.gnome.org (Postfix) with ESMTP id 9B78C3B017A for ; Wed, 28 Jun 2006 09:56:20 -0400 (EDT) Received: by py-out-1112.google.com with SMTP id c30so2229313pyc for ; Wed, 28 Jun 2006 06:55:43 -0700 (PDT) Received: by 10.35.63.2 with SMTP id q2mr140094pyk; Wed, 28 Jun 2006 06:55:43 -0700 (PDT) Received: by 10.35.39.16 with HTTP; Wed, 28 Jun 2006 06:55:43 -0700 (PDT) Message-ID: Date: Wed, 28 Jun 2006 09:55:43 -0400 From: "Matthias Clasen" To: "Dave Foster" Subject: Re: gdk_display_close segfault? In-Reply-To: <1151470915.4791.3.camel@neptune.minuslab.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1151470915.4791.3.camel@neptune.minuslab.net> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.41 tagged_above=-999 required=2 tests=[AWL=-0.010, BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2, SPF_PASS=-0.001] X-Spam-Score: -2.41 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2006 13:56:21 -0000 On 6/28/06, Dave Foster wrote: > Hi, > > I've been trying to write a small section of code in my program which > makes a second connection to the X display, using gtkmm.. I kept having > problems, after rewriting it about 5 or 6 times, I tried writing it in > straight gdk, and STILL got the problems. > > I seem to get a segfault whenever I call gdk_display_close(). Here is a > rediculously simple example that gives the problem: > > Glib::ustring disp = ":0.0"; > GdkDisplay* gdisp = gdk_display_open(disp.c_str()); > if (!gdisp) ... > gdk_display_close(gdisp); > > /* > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread -1224202560 (LWP 5689)] > 0xb7b413d0 in gdk_display_x11_dispose () from /usr/lib/libgdk-x11-2.0.so.0 > (gdb) bt > #0 0xb7b413d0 in gdk_display_x11_dispose () from /usr/lib/libgdk-x11-2.0.so.0 > #1 0xb7a11f2b in g_object_unref () from /usr/lib/libgobject-2.0.so.0 > #2 0xb7b20c04 in gdk_display_close () from /usr/lib/libgdk-x11-2.0.so.0 > #3 0x080571d5 in SetBG::set_bg (disp=@0xbfe1b2b0, file=@0xbfe1b2ac, > mode=SetBG::SET_SCALE, bgcolor=@0xbfe1b2a8) at SetBG.cc:67 > ... > */ > > The display is opening fine. I'm running: > > gtk: 2.8.17-1 > glib: 2.10.2-1 > > (hmm, didn't notice that before,t he 2.8 vs 2.10 thing, could that be it?) > > Anyway, I've spent all night trying to debug this and weeks trying to > sort this problem out in my program. What is up with this, what can I > do? gdk_display_close has been fixed in GTK+ 2.10, which should be available soon. From dave.foster@gmail.com Wed Jun 28 10:19:15 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 006DC3B02CA for ; Wed, 28 Jun 2006 10:19:15 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15554-01 for ; Wed, 28 Jun 2006 10:19:14 -0400 (EDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.193]) by menubar.gnome.org (Postfix) with ESMTP id 907993B02D3 for ; Wed, 28 Jun 2006 10:19:13 -0400 (EDT) Received: by wx-out-0102.google.com with SMTP id s15so69257wxc for ; Wed, 28 Jun 2006 07:18:46 -0700 (PDT) Received: by 10.70.49.13 with SMTP id w13mr1383280wxw; Wed, 28 Jun 2006 07:18:46 -0700 (PDT) Received: by 10.70.6.9 with HTTP; Wed, 28 Jun 2006 07:18:46 -0700 (PDT) Message-ID: Date: Wed, 28 Jun 2006 10:18:46 -0400 From: "Dave Foster" To: "Matthias Clasen" Subject: Re: gdk_display_close segfault? In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_68848_11799959.1151504326383" References: <1151470915.4791.3.camel@neptune.minuslab.net> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.399 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2, HTML_MESSAGE=0.001, SPF_PASS=-0.001] X-Spam-Score: -2.399 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2006 14:19:15 -0000 ------=_Part_68848_11799959.1151504326383 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline ok, thank you Matthias. dave On 6/28/06, Matthias Clasen wrote: > > On 6/28/06, Dave Foster wrote: > > Hi, > > > > I've been trying to write a small section of code in my program which > > makes a second connection to the X display, using gtkmm.. I kept having > > problems, after rewriting it about 5 or 6 times, I tried writing it in > > straight gdk, and STILL got the problems. > > > > I seem to get a segfault whenever I call gdk_display_close(). Here is a > > rediculously simple example that gives the problem: > > > > Glib::ustring disp = ":0.0"; > > GdkDisplay* gdisp = gdk_display_open(disp.c_str()); > > if (!gdisp) ... > > gdk_display_close(gdisp); > > > > /* > > Program received signal SIGSEGV, Segmentation fault. > > [Switching to Thread -1224202560 (LWP 5689)] > > 0xb7b413d0 in gdk_display_x11_dispose () from /usr/lib/libgdk- > x11-2.0.so.0 > > (gdb) bt > > #0 0xb7b413d0 in gdk_display_x11_dispose () from /usr/lib/libgdk- > x11-2.0.so.0 > > #1 0xb7a11f2b in g_object_unref () from /usr/lib/libgobject-2.0.so.0 > > #2 0xb7b20c04 in gdk_display_close () from /usr/lib/libgdk-x11-2.0.so.0 > > #3 0x080571d5 in SetBG::set_bg (disp=@0xbfe1b2b0, file=@0xbfe1b2ac, > > mode=SetBG::SET_SCALE, bgcolor=@0xbfe1b2a8) at SetBG.cc:67 > > ... > > */ > > > > The display is opening fine. I'm running: > > > > gtk: 2.8.17-1 > > glib: 2.10.2-1 > > > > (hmm, didn't notice that before,t he 2.8 vs 2.10 thing, could that be > it?) > > > > Anyway, I've spent all night trying to debug this and weeks trying to > > sort this problem out in my program. What is up with this, what can I > > do? > > gdk_display_close has been fixed in GTK+ 2.10, which should be > available soon. > ------=_Part_68848_11799959.1151504326383 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline ok, thank you Matthias.

dave

On 6/28/06, Matthias Clasen <matthias.clasen@gmail.com> wrote:
On 6/28/06, Dave Foster <dave.foster@gmail.com > wrote:
> Hi,
>
> I've been trying to write a small section of code in my program which
> makes a second connection to the X display, using gtkmm.. I kept having
> problems, after rewriting it about 5 or 6 times, I tried writing it in
> straight gdk, and STILL got the problems.
>
> I seem to get a segfault whenever I call gdk_display_close().  Here is a
> rediculously simple example that gives the problem:
>
> Glib::ustring disp = ": 0.0";
> GdkDisplay* gdisp = gdk_display_open(disp.c_str());
> if (!gdisp) ...
> gdk_display_close(gdisp);
>
> /*
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread -1224202560 (LWP 5689)]
> 0xb7b413d0 in gdk_display_x11_dispose () from /usr/lib/libgdk-x11-2.0.so.0
> (gdb) bt
> #0  0xb7b413d0 in gdk_display_x11_dispose () from /usr/lib/libgdk-x11-2.0.so.0
> #1  0xb7a11f2b in g_object_unref () from /usr/lib/libgobject- 2.0.so.0
> #2  0xb7b20c04 in gdk_display_close () from /usr/lib/libgdk-x11-2.0.so.0
> #3  0x080571d5 in SetBG::set_bg (disp=@0xbfe1b2b0, file=@0xbfe1b2ac,
>     mode=SetBG::SET_SCALE, bgcolor=@0xbfe1b2a8) at SetBG.cc:67
> ...
> */
>
> The display is opening fine.  I'm running:
>
> gtk: 2.8.17-1
> glib: 2.10.2-1
>
> (hmm, didn't notice that before,t he 2.8 vs 2.10 thing, could that be it?)
>
> Anyway, I've spent all night trying to debug this and weeks trying to
> sort this problem out in my program.  What is up with this, what can I
> do?

gdk_display_close has been fixed in GTK+ 2.10, which should  be
available soon.

------=_Part_68848_11799959.1151504326383-- From amirthakaruna@tataelxsi.co.in Wed Jun 28 10:30:48 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 6BE0F3B00A7 for ; Wed, 28 Jun 2006 10:30:48 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15942-08 for ; Wed, 28 Jun 2006 10:30:47 -0400 (EDT) Received: from mail.tataelxsi.co.in (mail.tataelxsi.co.in [203.200.1.48]) by menubar.gnome.org (Postfix) with ESMTP id 2C7823B00B0 for ; Wed, 28 Jun 2006 10:30:46 -0400 (EDT) Received: from amirthakaruna (tataelxsi.co.in [203.197.169.80] (may be forged)) by mail.tataelxsi.co.in (MOS 3.7.4b-GA) with ESMTP id BRK15473 (AUTH amirthakaruna); Wed, 28 Jun 2006 20:00:59 +0530 (IST) From: Karunakaran A To: "'Attilio Fiandrotti'" , "'Suman Kar'" Subject: RE: Failed building GTK with the DFB backend Date: Wed, 28 Jun 2006 20:00:01 +0530 Message-ID: <000601c69abf$5747eb80$361b320a@telxsi.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <44A26D1D.9090905@tiscali.it> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Junkmail: Blacklisted Content-Type: multipart/mixed; boundary="MIRAPOINT_PART1_44a292a6" X-Mirapoint-Sig: mail.tataelxsi.co.in X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-0.656 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.558, TW_DF=0.077, TW_GD=0.077, TW_GT=0.077, TW_KD=0.077, TW_TK=0.077] X-Spam-Score: -0.656 X-Spam-Level: X-Mailman-Approved-At: Thu, 29 Jun 2006 03:02:46 -0400 Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2006 14:30:48 -0000 --MIRAPOINT_PART1_44a292a6 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 8bit Hi all, We also tried to build gtk 2.8.18 with patch( gtk+-directfb.patch downloaded from https://debian.polito.it/downloads/gtk+-directfb.tar.bzip ) with DFB as a backend on a different machine. In that, the patch file alters only configure.in file, not the Makefile.in. so while building,it throws error in the directory `/root/gtkdfb/gtk+-2.8.18/gdk' as, make[4]: *** No rule to make target `libgdk-directfb-2.0.la',needed by `all-am'. help me out in this. Karunakaran A. -----Original Message----- From: Attilio Fiandrotti [mailto:fiandro@tiscali.it] Sent: Wednesday, June 28, 2006 5:21 PM To: Suman Kar Cc: amirthakaruna@tataelxsi.co.in; gtk-devel-list@gnome.org Subject: Re: Failed building GTK with the DFB backend I apologize for my mistake: only now i realize taht getposition() and getsize() were introduced *after* DFB 0.9.25 was released! Yesterday mike checked in a patch ("Added ifdef to compile with 0.9.24 removes creating a child GdkWindow since it u...") that allows GTK+ to be compiled against DFB >= 0.9.24 (so, also 0.9.25 will do) The correct recipe is: DFB >= 0.9.24 GTK+ HEAD from CVS Attilio Suman Kar wrote: > Hello Attilio, > > Let me try to explain Karuna's problem: we are using the > downloadable source tarball from > http://directfb.org/index.php?path=Main%2FDownloads: > DirectFB-0.9.25.1.tar.gz > > Also, this was released on 03-May-2006. Mike's checkin has happened > on 11-June-2006. Moreover, we could not find the GetPosition() > member in either the http://directfb.org/index.php?path=Main%2FNews > page or in the source files Mike has mentioned in the mail to > the directFB list. > > These indicates to me that this is not really an issue with some path > variable as you suggested. Your inputs are awaited. > > Regards, > Suman. > > -----Original Message----- > From: Attilio Fiandrotti [mailto:fiandro@tiscali.it] > Sent: Wednesday, June 28, 2006 3:03 PM > To: karuna karan > Cc: skar@tataelxsi.co.in; amirthakaruna@tataelxsi.co.in > Subject: Re: Failed building GTK with the DFB backend > > > the symbol GetPosition (and getsize, too) were introduced in DFB 0.9.25 > : if you're trying to compile GTKDFB against DFB 0.9.25, then you must > have provided wrong pkg_config_path or ld_library_path > > Attilio > > karuna karan wrote: > >>hi, >> >>we are already working with DirectFB 0.9.25.1 and GTK 2.9.4(released) >> >>we will start work with GTK 2.9.4 from CVS as suggested by you. >> >>we will get back if any issue arises. >> >>Thanks, >>Karunakaran A. >> >> >> >> >From: Attilio Fiandrotti >> >> >A couple of days ago mike checked in the patch that excludes from >> >compilation some extra code that requires DFB 0.9.25 in the case DFN >>0.9.24 >> >is used. >> >Use CVS sources or apply to GTK 2.9.4 gdkdirectfb.h and >> >gdkwindow-directfb.c from current SVN. >> >If you're a Debian user and run on i386, simply install cairodfb and >>gtkdfb >> >packages [1] which were made recently available (other archs will follow >> >soon). >> > >> >Attilio >> > >> >[1] > > http://mail.directfb.org/pipermail/directfb-dev/2006-June/001973.html > >> > >> >karuna karan wrote: >> >>Hi, >> >> >> >>we have tried to build gtk+ 2.9.4 with backend dfb. >> >>we got the follwing error while building, >> >> >> >>gdkwindow-directfb.c: In function `gdk_directfb_create_child_window': >> >>gdkwindow-directfb.c:2508: error: structure has no member named >> >>`GetPosition' >> >>make[4]: *** [gdkwindow-directfb.lo] Error 1 >> >>make[4]: Leaving directory `/root/new/gtk+-2.9.4/gdk/directfb' >> >>make[3]: *** [all-recursive] Error 1 >> >>make[3]: Leaving directory `/root/new/gtk+-2.9.4/gdk' >> >>make[2]: *** [all] Error 2 >> >>make[2]: Leaving directory `/root/new/gtk+-2.9.4/gdk' >> >>make[1]: *** [all-recursive] Error 1 >> >>make[1]: Leaving directory `/root/new/gtk+-2.9.4' >> >>make: *** [all] Error 2 >> >> >> >>so kindly give feedback on this issue.. >> >> >> >>Thanks, >> >>Karunakaran A. >> >> >> >> >> >> >> >> >> >>>From: Suman Kar >> >>>Reply-To: Suman Kar >> >>>To: "'Attilio Fiandrotti'" , "'karuna >>karan'" >> >>> >> >>>CC: >> >>>Subject: RE: Failed building GTK with the DFB backend >> >>>Date: Tue, 27 Jun 2006 16:51:13 +0530 >> >>> >> >>>Hello Attilio, >> >>> >> >>>Thanks for the quick update. However, the problem goes away when we >>added >> >>>the following: >> >>> >> >>>gboolean >> >>>gdk_screen_is_composited (GdkScreen *screen) >> >>>{ >> >>> g_return_val_if_fail (GDK_IS_SCREEN (screen), NULL); >> >>> return FALSE; >> >>>} >> >>> >> >>> >> >>>is added to gdkscreen-directfb.c (from >> >> >>>>>http://mail.gnome.org/archives/gtk-devel-list/2006-May/msg00210.html ). >> >> >>> >> >>>We will definitely try building gtk+2.9.4 and will get back in case >>there >> >> >>>>>>are any issues. >>>>>> >>>>>>One more thing: we would be really interested in gtk+-2.10. Any >>> >>>idea when >>> >>>>>>this will be out? >>>>>> >>>>>>Regards, >>>>>>Suman. >>>>>> >>>>>>-----Original Message----- >>>>>>From: Attilio Fiandrotti [mailto:fiandro@tiscali.it] >>>>>>Sent: Tuesday, June 27, 2006 3:40 PM >>>>>>To: karuna karan >>>>>>Cc: gtk-devel-list@gnome.org; skar@tataelxsi.co.in >>>>>>Subject: Re: Failed building GTK with the DFB backend >>>>>> >>>>>> >>>>>>karuna karan wrote: >>>>>> >>>>>>>Hi all, >>>>>>> >>>>>>>I tried to build gtk 2.9.1 with directFB backend with following >>>>>>>dependencies, >>>>>> >>>>>>DFB support in was broken: you should try 2.9.4 or follow instructions >>>>>>in the wiki page to build from sratch. >>>>>>If you're a debian user, you can also use precompiled i386 official >>>>>>packages that were built this week >>>>>> >>>>>>http://download.dajobe.org/debian/experimental/ <-cairodfb >>>>>>http://people.debian.org/~joss/packages/ <-gtkdfb >>>>>> >>>>>>Attilio >>>>>> >>>>>>The information contained in this electronic message and any >>> >>>attachments >>> >>>>>>to this message are intended for the exclusive use of the >>> >>>addressee(s)and >>> >>>>>>may contain confidential or privileged information. If you are not the >>>>>>intended recipient, please notify the sender or >>>>>>administrator@tataelxsi.co.in >>>>> >>>>> >>>>>_________________________________________________________________ >>>>>Express yourself instantly with MSN Messenger! Download today - it's >>> >>>FREE! >>> >>>>>http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ >>>>> >>>>> >>>> >>>_________________________________________________________________ >>>Dont just search. Find. Check out the new MSN Search! >>>http://search.msn.click-url.com/go/onm00200636ave/direct/01/ >>> >>>The information contained in this electronic message and any >>>attachments to this message are intended for the exclusive use of the >>>addressee(s)and may contain confidential or privileged information. If >>>you are not the intended recipient, please notify the sender or >>>administrator@tataelxsi.co.in >> >> >>_________________________________________________________________ >>Dont just search. Find. Check out the new MSN Search! >>http://search.msn.click-url.com/go/onm00200636ave/direct/01/ >> >> >> >> >>------------------------------------------------------------------------ >> >>The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s)and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender or administrator@tataelxsi.co.in --MIRAPOINT_PART1_44a292a6 Content-Disposition: inline The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s)and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender or administrator@tataelxsi.co.in --MIRAPOINT_PART1_44a292a6-- From jalaganapathy@tataelxsi.co.in Thu Jun 29 03:08:28 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 62B543B03EF for ; Thu, 29 Jun 2006 03:08:28 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24602-01 for ; Thu, 29 Jun 2006 03:08:26 -0400 (EDT) Received: from mail.tataelxsi.co.in (mail.tataelxsi.co.in [203.200.1.48]) by menubar.gnome.org (Postfix) with ESMTP id 1B5DF3B03B2 for ; Thu, 29 Jun 2006 03:08:25 -0400 (EDT) Received: (from mail.tataelxsi.co.in [203.197.169.20]) by mail.tataelxsi.co.in (MOS 3.7.4b-GA) with HTTP/1.1 id BRM16267 (AUTH jalaganapathy); Thu, 29 Jun 2006 12:39:37 +0530 (IST) From: Jalagandeswari G Subject: Installing GTK+2.9.1 in Fedora core2 To: gtk-devel-list@gnome.org X-Mailer: Mirapoint Webmail Direct 3.7.4b-GA MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20060629123937.BRM16267@mail.tataelxsi.co.in> Date: Thu, 29 Jun 2006 12:39:37 +0530 (IST) X-Junkmail: Blacklisted X-Mirapoint-Sig: mail.tataelxsi.co.in X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.599 tagged_above=-999 required=2 tests=[BAYES_00=-2.599] X-Spam-Score: -2.599 X-Spam-Level: X-Mailman-Approved-At: Thu, 29 Jun 2006 07:31:44 -0400 X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2006 07:08:28 -0000 Hello All, Iam trying to install gtk+2.9.1 in fedora core2. i am using glib-1.10.1, cairo-1.1.6,atk-1.0.1 and pango-1.13.1 my configure options are ./configure --prefix=/exp/ffox Confugure works fine. While running make i am getting the following errors. gcc -DHAVE_CONFIG_H -I. -I. -I.. -DG_LOG_DOMAIN=\"Gtk\" -DGTK_LIBDIR=\"/exp/ffox/lib\" -DGTK_DATADIR=\"/exp/ffox/share\" -DGTK_DATA_PREFIX=\"/exp/ffox\" -DGTK_SYSCONFDIR=\"/exp/ffox/etc\" -DGTK_VERSION=\"2.9.1\" -DGTK_BINARY_VERSION=\"2.10.0\" -DGTK_HOST=\"i686-pc-linux-gnu\" -DGTK_COMPILATION -DGTK_PRINT_BACKENDS=\"pdf,cups\" -I../gtk -I.. -I../gdk -I../gdk -I../gdk-pixbuf -I../gdk-pixbuf -DGDK_PIXBUF_DISABLE_DEPRECATED -DGDK_DISABLE_DEPRECATED -DGTK_DISABLE_DEPRECATED -DGTK_FILE_SYSTEM_ENABLE_UNSUPPORTED -DGTK_PRINT_BACKEND_ENABLE_UNSUPPORTED -DG_ENABLE_DEBUG -pthread -I/exp/ffox//include/glib-2.0 -I/exp/ffox//lib/glib-2.0/include -I/exp/ffox//include/pango-1.0 -I/exp/ffox//include/cairo -I/exp/ffox//include/atk-1.0 -I/exp/ffox/include -I/usr/X11R6/include -DG_DISABLE_DEPRECATED -g -O2 -g -Wall -MT gtkrecentmanager.lo -MD -MP -MF .deps/gtkrecentmanager.Tpo -c gtkrecentmanager.c -fPIC -DPIC -o .libs/gtkrecentmanager.o gtkrecentmanager.c:109: error: syntax error before "GBookmarkFile" gtkrecentmanager.c:109: warning: no semicolon at end of struct or union gtkrecentmanager.c:113: error: syntax error before '}' token gtkrecentmanager.c: In function `gtk_recent_manager_class_init': gtkrecentmanager.c:274: error: invalid application of `sizeof' to an incomplete type gtkrecentmanager.c: In function `gtk_recent_manager_init': gtkrecentmanager.c:286: error: dereferencing pointer to incomplete type gtkrecentmanager.c:290: error: dereferencing pointer to incomplete type gtkrecentmanager.c:291: error: dereferencing pointer to incomplete type gtkrecentmanager.c:293: error: dereferencing pointer to incomplete type gtkrecentmanager.c:294: error: dereferencing pointer to incomplete type gtkrecentmanager.c:295: error: dereferencing pointer to incomplete type gtkrecentmanager.c:296: error: dereferencing pointer to incomplete type gtkrecentmanager.c:298: error: dereferencing pointer to incomplete type gtkrecentmanager.c: In function `gtk_recent_manager_get_property': gtkrecentmanager.c:336: error: dereferencing pointer to incomplete type gtkrecentmanager.c:339: error: dereferencing pointer to incomplete type gtkrecentmanager.c:342: error: dereferencing pointer to incomplete type gtkrecentmanager.c: In function `gtk_recent_manager_finalize': gtkrecentmanager.c:357: error: dereferencing pointer to incomplete type gtkrecentmanager.c:358: error: dereferencing pointer to incomplete type gtkrecentmanager.c:360: error: dereferencing pointer to incomplete type gtkrecentmanager.c:361: error: dereferencing pointer to incomplete type gtkrecentmanager.c:363: error: dereferencing pointer to incomplete type gtkrecentmanager.c:364: warning: implicit declaration of function `g_bookmark_file_free' gtkrecentmanager.c:364: error: dereferencing pointer to incomplete type gtkrecentmanager.c: In function `gtk_recent_manager_real_changed': gtkrecentmanager.c:377: error: dereferencing pointer to incomplete type gtkrecentmanager.c:385: error: dereferencing pointer to incomplete type gtkrecentmanager.c:387: error: dereferencing pointer to incomplete type gtkrecentmanager.c:392: error: dereferencing pointer to incomplete type gtkrecentmanager.c:394: error: dereferencing pointer to incomplete type gtkrecentmanager.c:394: warning: implicit declaration of function `g_bookmark_file_new' gtkrecentmanager.c:395: error: dereferencing pointer to incomplete type gtkrecentmanager.c:399: warning: implicit declaration of function `g_bookmark_file_to_file' gtkrecentmanager.c:399: error: dereferencing pointer to incomplete type gtkrecentmanager.c:400: error: dereferencing pointer to incomplete type gtkrecentmanager.c:406: error: dereferencing pointer to incomplete type gtkrecentmanager.c:415: error: dereferencing pointer to incomplete type gtkrecentmanager.c:419: error: dereferencing pointer to incomplete type gtkrecentmanager.c:422: error: dereferencing pointer to incomplete type gtkrecentmanager.c:429: error: dereferencing pointer to incomplete type gtkrecentmanager.c:432: error: dereferencing pointer to incomplete type gtkrecentmanager.c: In function `gtk_recent_manager_poll_timeout': gtkrecentmanager.c:458: error: dereferencing pointer to incomplete type gtkrecentmanager.c:458: error: dereferencing pointer to incomplete type gtkrecentmanager.c:461: error: dereferencing pointer to incomplete type gtkrecentmanager.c:470: error: dereferencing pointer to incomplete type gtkrecentmanager.c:477: error: dereferencing pointer to incomplete type gtkrecentmanager.c: In function `gtk_recent_manager_set_filename': gtkrecentmanager.c:498: error: dereferencing pointer to incomplete type gtkrecentmanager.c:500: error: dereferencing pointer to incomplete type gtkrecentmanager.c:502: error: dereferencing pointer to incomplete type gtkrecentmanager.c:503: error: dereferencing pointer to incomplete type gtkrecentmanager.c:506: error: dereferencing pointer to incomplete type gtkrecentmanager.c:507: error: dereferencing pointer to incomplete type gtkrecentmanager.c:514: error: dereferencing pointer to incomplete type gtkrecentmanager.c: In function `build_recent_items_list': gtkrecentmanager.c:534: error: dereferencing pointer to incomplete type gtkrecentmanager.c:536: error: dereferencing pointer to incomplete type gtkrecentmanager.c:538: error: dereferencing pointer to incomplete type gtkrecentmanager.c:539: error: dereferencing pointer to incomplete type gtkrecentmanager.c:542: error: dereferencing pointer to incomplete type gtkrecentmanager.c:555: error: dereferencing pointer to incomplete type gtkrecentmanager.c:563: error: dereferencing pointer to incomplete type gtkrecentmanager.c:565: error: dereferencing pointer to incomplete type gtkrecentmanager.c:571: warning: implicit declaration of function `g_bookmark_file_load_from_file' gtkrecentmanager.c:571: error: dereferencing pointer to incomplete type gtkrecentmanager.c:572: error: dereferencing pointer to incomplete type gtkrecentmanager.c:578: error: dereferencing pointer to incomplete type gtkrecentmanager.c:581: error: dereferencing pointer to incomplete type gtkrecentmanager.c:582: error: dereferencing pointer to incomplete type gtkrecentmanager.c:587: warning: implicit declaration of function `g_bookmark_file_get_size' gtkrecentmanager.c:587: error: dereferencing pointer to incomplete type gtkrecentmanager.c:588: error: dereferencing pointer to incomplete type gtkrecentmanager.c:590: error: dereferencing pointer to incomplete type gtkrecentmanager.c:595: error: dereferencing pointer to incomplete type gtkrecentmanager.c:596: error: dereferencing pointer to incomplete type gtkrecentmanager.c: In function `IA__gtk_recent_manager_get_for_screen': gtkrecentmanager.c:683: error: dereferencing pointer to incomplete type gtkrecentmanager.c: In function `display_closed': gtkrecentmanager.c:697: error: dereferencing pointer to incomplete type gtkrecentmanager.c:698: error: dereferencing pointer to incomplete type gtkrecentmanager.c:703: error: dereferencing pointer to incomplete type gtkrecentmanager.c: In function `unset_screen': gtkrecentmanager.c:718: error: dereferencing pointer to incomplete type gtkrecentmanager.c:720: error: dereferencing pointer to incomplete type gtkrecentmanager.c:726: error: dereferencing pointer to incomplete type gtkrecentmanager.c: In function `IA__gtk_recent_manager_set_screen': gtkrecentmanager.c:759: error: dereferencing pointer to incomplete type gtkrecentmanager.c: In function `IA__gtk_recent_manager_set_limit': gtkrecentmanager.c:786: error: dereferencing pointer to incomplete type gtkrecentmanager.c: In function `IA__gtk_recent_manager_get_limit': gtkrecentmanager.c:808: error: dereferencing pointer to incomplete type gtkrecentmanager.c: In function `IA__gtk_recent_manager_add_full': gtkrecentmanager.c:977: error: dereferencing pointer to incomplete type gtkrecentmanager.c:979: error: dereferencing pointer to incomplete type gtkrecentmanager.c:980: error: dereferencing pointer to incomplete type gtkrecentmanager.c:984: warning: implicit declaration of function `g_bookmark_file_set_title' gtkrecentmanager.c:984: error: dereferencing pointer to incomplete type gtkrecentmanager.c:987: warning: implicit declaration of function `g_bookmark_file_set_description' gtkrecentmanager.c:987: error: dereferencing pointer to incomplete type gtkrecentmanager.c:989: warning: implicit declaration of function `g_bookmark_file_set_mime_type' gtkrecentmanager.c:989: error: dereferencing pointer to incomplete type gtkrecentmanager.c:996: warning: implicit declaration of function `g_bookmark_file_add_group' gtkrecentmanager.c:996: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1003: warning: implicit declaration of function `g_bookmark_file_add_application' gtkrecentmanager.c:1003: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1007: warning: implicit declaration of function `g_bookmark_file_set_is_private' gtkrecentmanager.c:1007: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1013: error: dereferencing pointer to incomplete type gtkrecentmanager.c: In function `IA__gtk_recent_manager_remove_item': gtkrecentmanager.c:1048: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1050: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1051: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1061: warning: implicit declaration of function `g_bookmark_file_remove_item' gtkrecentmanager.c:1061: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1069: error: dereferencing pointer to incomplete type gtkrecentmanager.c: In function `IA__gtk_recent_manager_has_item': gtkrecentmanager.c:1098: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1100: warning: implicit declaration of function `g_bookmark_file_has_item' gtkrecentmanager.c:1100: error: dereferencing pointer to incomplete type gtkrecentmanager.c: At top level: gtkrecentmanager.c:1104: error: syntax error before '*' token gtkrecentmanager.c: In function `build_recent_info': gtkrecentmanager.c:1110: error: `bookmarks' undeclared (first use in this function) gtkrecentmanager.c:1110: error: (Each undeclared identifier is reported only once gtkrecentmanager.c:1110: error: for each function it appears in.) gtkrecentmanager.c:1111: error: `info' undeclared (first use in this function) gtkrecentmanager.c:1113: warning: implicit declaration of function `g_bookmark_file_get_title' gtkrecentmanager.c:1114: warning: implicit declaration of function `g_bookmark_file_get_description' gtkrecentmanager.c:1115: warning: implicit declaration of function `g_bookmark_file_get_mime_type' gtkrecentmanager.c:1117: warning: implicit declaration of function `g_bookmark_file_get_is_private' gtkrecentmanager.c:1119: warning: implicit declaration of function `g_bookmark_file_get_added' gtkrecentmanager.c:1120: warning: implicit declaration of function `g_bookmark_file_get_modified' gtkrecentmanager.c:1121: warning: implicit declaration of function `g_bookmark_file_get_visited' gtkrecentmanager.c:1123: warning: implicit declaration of function `g_bookmark_file_get_groups' gtkrecentmanager.c:1123: warning: assignment makes pointer from integer without a cast gtkrecentmanager.c:1133: warning: implicit declaration of function `g_bookmark_file_get_applications' gtkrecentmanager.c:1133: warning: assignment makes pointer from integer without a cast gtkrecentmanager.c:1144: warning: implicit declaration of function `g_bookmark_file_get_app_info' gtkrecentmanager.c: In function `IA__gtk_recent_manager_lookup_item': gtkrecentmanager.c:1196: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1198: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1199: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1209: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1224: error: dereferencing pointer to incomplete type gtkrecentmanager.c: In function `IA__gtk_recent_manager_move_item': gtkrecentmanager.c:1268: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1278: warning: implicit declaration of function `g_bookmark_file_move_item' gtkrecentmanager.c:1278: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1287: error: dereferencing pointer to incomplete type gtkrecentmanager.c: In function `IA__gtk_recent_manager_get_items': gtkrecentmanager.c:1317: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1320: warning: implicit declaration of function `g_bookmark_file_get_uris' gtkrecentmanager.c:1320: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1320: warning: assignment makes pointer from integer without a cast gtkrecentmanager.c:1327: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1344: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1345: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1349: error: dereferencing pointer to incomplete type gtkrecentmanager.c: In function `purge_recent_items_list': gtkrecentmanager.c:1370: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1373: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1374: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1376: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1377: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1378: error: dereferencing pointer to incomplete type gtkrecentmanager.c: In function `IA__gtk_recent_manager_purge_items': gtkrecentmanager.c:1406: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1409: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1415: error: dereferencing pointer to incomplete type make[4]: *** [gtkrecentmanager.lo] Error 1 make[4]: Leaving directory `/exp/ffox/gtk+-2.9.1/gtk' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/exp/ffox/gtk+-2.9.1/gtk' make[2]: *** [all] Error 2 make[2]: Leaving directory `/exp/ffox/gtk+-2.9.1/gtk' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/exp/ffox/gtk+-2.9.1' make: *** [all] Error 2 Pls help me out to find a solution. regards, Jala The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s)and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender or administrator@tataelxsi.co.in From sandmann@daimi.au.dk Wed May 31 23:16:04 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id F331F3B0084 for ; Wed, 31 May 2006 23:16:03 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01799-09 for ; Wed, 31 May 2006 23:16:01 -0400 (EDT) Received: from daimi.au.dk (daimi.au.dk [130.225.16.1]) by menubar.gnome.org (Postfix) with ESMTP id 48A283B00AD for ; Wed, 31 May 2006 23:16:00 -0400 (EDT) Received: from camel30.daimi.au.dk (camel30 [130.225.16.149]) by daimi.au.dk (8.12.11.20060308/8.12.11) with ESMTP id k513FvkJ026470; Thu, 1 Jun 2006 05:15:58 +0200 Received: from camel30.daimi.au.dk (IDENT:U2FsdGVkX1+qd3TE3mk4InNR0+PybNGNUpbzCHnIsw0@localhost [127.0.0.1]) by camel30.daimi.au.dk (8.13.1/8.13.1) with ESMTP id k513Fvit009418; Thu, 1 Jun 2006 05:15:57 +0200 Received: (from sandmann@localhost) by camel30.daimi.au.dk (8.13.1/8.13.1/Submit) id k513FvG8009413; Thu, 1 Jun 2006 05:15:57 +0200 X-Authentication-Warning: camel30.daimi.au.dk: sandmann set sender to sandmann@daimi.au.dk using -f Sender: sandmann@daimi.au.dk To: Kristian Rietveld References: <20060314132538.GA3526@babi-pangang.org> <443B4A8A.8000302@imendio.com> <20060425103017.GA15762@babi-pangang.org> <20060531183045.GA7564@babi-pangang.org> From: Soeren Sandmann Date: 01 Jun 2006 05:15:57 +0200 In-Reply-To: <20060531183045.GA7564@babi-pangang.org> Message-ID: Lines: 28 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.56 on 130.225.16.1 X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.575 tagged_above=-999 required=2 tests=[AWL=0.024, BAYES_00=-2.599] X-Spam-Score: -2.575 X-Spam-Level: Cc: Gtk+ Developers , Tim Janik Subject: Re: Callback based tooltips (Re: New tooltips API, continued) X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2006 03:16:04 -0000 Kristian Rietveld writes: > I mostly like the behaviour you described below. > > > - Tooltips are too intrusive. The text should be smaller, and > > they should to the right of the cursor, and a little below > > the cursor's center. > > > > |\ ___________ > > | | tooltip | > > > > not centered below the cursor. > > If you want to have the tooltip right of the cursor, a little below the > cursor's center, does this also mean you want to have the tooltip follow > the mouse pointer? Might make sense else in this case, else the tooltip > might end up being positioned statically above the middle of a widget > ... Probably not; I'd have to try it out to see. Mostly the important thing is that the tooltip is positioned to the right of the cursor rather than centered as it is currently. I think Firefox gets the positioning mostly right, so copying that might not be the worst idea. Soren From mardy@users.sourceforge.net Thu Jun 1 07:04:29 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 633423B0C7E for ; Thu, 1 Jun 2006 07:04:29 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28962-04 for ; Thu, 1 Jun 2006 07:04:28 -0400 (EDT) Received: from smtp010.mail.ukl.yahoo.com (smtp010.mail.ukl.yahoo.com [217.12.11.79]) by menubar.gnome.org (Postfix) with SMTP id 690073B013F for ; Thu, 1 Jun 2006 07:04:27 -0400 (EDT) Received: (qmail 61490 invoked from network); 1 Jun 2006 11:04:26 -0000 Received: from unknown (HELO pupilla) (mardy78@151.42.226.237 with login) by smtp010.mail.ukl.yahoo.com with SMTP; 1 Jun 2006 11:04:26 -0000 Received: by pupilla (Postfix, from userid 1000) id 038336B7FF; Thu, 1 Jun 2006 13:03:17 +0200 (CEST) Date: Thu, 1 Jun 2006 13:03:17 +0200 From: Alberto Mardegan To: gtk-devel-list@gnome.org Message-ID: <20060601110317.GA23802@pupilla> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Accept-Language: it,ia,en,bg,es,fr User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.599 tagged_above=-999 required=2 tests=[BAYES_00=-2.599] X-Spam-Score: -2.599 X-Spam-Level: Subject: Histogram widget X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2006 11:04:29 -0000 Hi all! I'm going to write a widget for displaying histograms. Would it be elegant/smart/useful if it were to fetch the data from a GtkTreeModel, or would it be an unneeded complexity and just some GArrays are better? I'm thinking of a GtkTreeModel, in which every row is a histogram bar; hence we would/could have a double field for the value, a string field for the label in the X axis, maybe a GdkColor for the color and whatever can come to mind. Many thanks in advance to all those who will share their thoughts on the matter. -- Saluti, Mardy http://www.interlingua.com ___________________________________ Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB http://mail.yahoo.it From matthias.clasen@gmail.com Thu Jun 1 09:35:39 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 44D6D3B0213 for ; Thu, 1 Jun 2006 09:35:39 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06492-04 for ; Thu, 1 Jun 2006 09:35:37 -0400 (EDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.190]) by menubar.gnome.org (Postfix) with ESMTP id 2B1463B019C for ; Thu, 1 Jun 2006 09:35:37 -0400 (EDT) Received: by nf-out-0910.google.com with SMTP id l37so564726nfc for ; Thu, 01 Jun 2006 06:35:36 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=AXg4pkieJhFwK/fsPTG5BVq6Sv29H8f6t8wbUeiehWS8QFuJL4sEqqu5dTplyA7vdRrz50uICadI8ZT1y2rp+BasRLmOBacUSSXY1blUEAIWfvb1udC+bqhsXFVhdU6V4+2wZCjIuaczx07TxLq1x+v9zHm4YPkA8kydW+5SycA= Received: by 10.48.31.10 with SMTP id e10mr779574nfe; Thu, 01 Jun 2006 06:33:48 -0700 (PDT) Received: by 10.48.215.7 with HTTP; Thu, 1 Jun 2006 06:33:48 -0700 (PDT) Message-ID: Date: Thu, 1 Jun 2006 09:33:48 -0400 From: "Matthias Clasen" To: "Kristian Rietveld" In-Reply-To: <20060531200823.GA7846@babi-pangang.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20060531200823.GA7846@babi-pangang.org> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.742 tagged_above=-999 required=2 tests=[AWL=-0.700, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.558, SPF_PASS=-0.001] X-Spam-Score: -1.742 X-Spam-Level: Cc: gtk-devel-list@gnome.org, timj@imendio.com Subject: Re: Tooltips progress X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2006 13:35:39 -0000 > Attached is some sample code using the new API. Opinions, comments, > suggestions are appreciated. > I don't remember too much of the original proposal, so I'll just go by what I see in the examples... What is the relation between the tooltip-markup and has-tooltip properties ? Is has-tooltip automatically set when setting tooltip-markup ? Or do you only need to set has-tooltip if you want to connect to query-tooltip ? Is the tooltip window available as a property too ? (The example uses a dedicated setter for it). The example doesn't show tooltips constructed using the old tooltips api, but I assume those will continue to work as before, right ? Using x == -1 to indicate a keyboard-triggered tooltip looks a bit odd to me; how about adding a boolean parameter for this ? Regarding dedicated treeview api, I think we can do without it (at least initially), if we have a good example in the docs. Though lots of people will forget the selection_changed thing for keyboard tooltips... Could you enhance your demo with an example of text view tooltips on a tag ? Matthias From jean.brefort@normalesup.org Thu Jun 1 09:58:21 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 479CD3B0171 for ; Thu, 1 Jun 2006 09:58:03 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08512-08 for ; Thu, 1 Jun 2006 09:58:01 -0400 (EDT) Received: from smtp4-g19.free.fr (smtp4-g19.free.fr [212.27.42.30]) by menubar.gnome.org (Postfix) with ESMTP id 84A533B0CBB for ; Thu, 1 Jun 2006 09:57:52 -0400 (EDT) Received: from che21-1-82-239-125-56.fbx.proxad.net (che21-1-82-239-125-56.fbx.proxad.net [82.239.125.56]) by smtp4-g19.free.fr (Postfix) with ESMTP id DE3EA54C0D; Thu, 1 Jun 2006 15:57:50 +0200 (CEST) From: Jean =?ISO-8859-1?Q?Br=E9fort?= To: Alberto Mardegan In-Reply-To: <20060601110317.GA23802@pupilla> References: <20060601110317.GA23802@pupilla> Content-Type: text/plain; charset=utf-8 Date: Thu, 01 Jun 2006 16:00:49 +0200 Message-Id: <1149170449.11316.1.camel@athlon.brefort.fr> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.884 tagged_above=-999 required=2 tests=[AWL=-0.354, BAYES_00=-2.599, SPF_NEUTRAL=1.069] X-Spam-Score: -1.884 X-Spam-Level: Cc: gtk-devel-list@gnome.org Subject: Re: Histogram widget X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2006 13:58:21 -0000 Le jeudi 01 juin 2006 13:03 +0200, Alberto Mardegan a crit : > Hi all! > I'm going to write a widget for displaying histograms. Would it be > elegant/smart/useful if it were to fetch the data from a GtkTreeModel, > or would it be an unneeded complexity and just some GArrays are better? > > I'm thinking of a GtkTreeModel, in which every row is a histogram bar; > hence we would/could have a double field for the value, a string field > for the label in the X axis, maybe a GdkColor for the color and whatever > can come to mind. > > Many thanks in advance to all those who will share their thoughts on the > matter. Do you want histograms or column charts? Anyway both already exist in goffice and we have the GOGraphWidget widget to display a large variety of 2D charts. Regards, Jean Brfort From mitch@gimp.org Thu Jun 1 10:37:41 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 9C8673B0253 for ; Thu, 1 Jun 2006 10:37:41 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12026-06 for ; Thu, 1 Jun 2006 10:37:40 -0400 (EDT) Received: from mitch.gimp.org (p549C9506.dip0.t-ipconnect.de [84.156.149.6]) by menubar.gnome.org (Postfix) with ESMTP id 630D53B0171 for ; Thu, 1 Jun 2006 10:37:40 -0400 (EDT) Received: from mitch by mitch.gimp.org with local (Exim 3.36 #1 (Debian)) id 1FloKa-0005tI-00; Thu, 01 Jun 2006 16:39:24 +0200 From: Michael Natterer To: Kristian Rietveld In-Reply-To: <20060531200823.GA7846@babi-pangang.org> References: <20060531200823.GA7846@babi-pangang.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Thu, 01 Jun 2006 16:39:24 +0200 Message-Id: <1149172764.5721.13.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-0.468 tagged_above=-999 required=2 tests=[AWL=-1.996, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, RCVD_IN_NJABL_DUL=1.946, RCVD_IN_SORBS_DUL=2.046] X-Spam-Score: -0.468 X-Spam-Level: Cc: gtk-devel-list@gnome.org, timj@imendio.com Subject: Re: Tooltips progress X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2006 14:37:41 -0000 On Wed, 2006-05-31 at 22:08 +0200, Kristian Rietveld wrote: > Currently, we are using the following query-tooltips signal: > > gboolean (*query_tooltip) (GtkWidget *widget, > gint x, > gint y, > GtkTooltip *tooltip); > > But if a user sets a custom using gtk_widget_set_custom_window(), we don't > have to pass a GtkTooltip around. So currently I just set the tooltip > field to NULL, so the user knows he has to use his own custom tooltip > window (and we assume he has a reference to that). Is this okay or do > we want to change this? We could also move the _set_custom_window() > functions into GtkTooltip for example. I would very much appreciate if the GtkTooltip object also kept track of the custom window. IMHO it makes no sense to handle this differently. gtk_tooltip_set_markup() vs. gtk_tooltip_set_window() simply feels much better than the asymmetry in gtk_tooltip_set_markup() vs. gtk_widget_set_tooltip_window() The current approach even limits the new tooltip system's use cases, since you have to set the custom window *outside* the callback. There is no way to decide *in* the callback if a standard tooltip is sufficient, or if a custom window is needed. Another problem is the assymetry in getting the relevant data to the callback. With markup, the GtkTooltip can be queried for the markup, if it's a custom window, you have to get it to the callback somehow. In your example code it's passed as user_data, but user_data is often not available since it's needed for other things, so you have to add a "GtkWidget *tooltip_window" to the "other thing". If "other thing" is e.g. the application toplevel window, which of the sub-widget's tooltips should it keep? All of them? People will in many cases end up attaching the tooltip window to the widget. I also fail to see why the "has-tooltip" property has to be set to TRUE, even tho a tooltip window was set on the widget. ciao, --mitch From islewind@gmail.com Thu Jun 1 11:16:53 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id CCF0F3B027D for ; Thu, 1 Jun 2006 11:16:53 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15167-10 for ; Thu, 1 Jun 2006 11:16:52 -0400 (EDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.181]) by menubar.gnome.org (Postfix) with ESMTP id EBDF73B02A2 for ; Thu, 1 Jun 2006 11:16:51 -0400 (EDT) Received: by py-out-1112.google.com with SMTP id x31so492875pye for ; Thu, 01 Jun 2006 08:16:51 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=TJcxirCpCUc11Q5e90yGryvZPvt6/4y9oixknOJbU9D0ul2vMJTRqtCSsnJU4SxRLn9lAKaOyN+GZ5nbxOOcf0T99ZPfjnqzOA3KseyOVQ4Ap+A8c67skU0CG6t40az7MwaWe4KCKIFXgrpOCN10KzuNVCisW4dtldpMgxlx5bQ= Received: by 10.35.36.13 with SMTP id o13mr1010511pyj; Thu, 01 Jun 2006 08:16:51 -0700 (PDT) Received: by 10.35.10.17 with HTTP; Thu, 1 Jun 2006 08:16:50 -0700 (PDT) Message-ID: <7bf6f2dc0606010816q15d512aejc30a6c93bc165e6@mail.gmail.com> Date: Thu, 1 Jun 2006 17:16:50 +0200 From: "=?ISO-8859-1?Q?=D8yvind_Kol=E5s?=" Sender: islewind@gmail.com To: "=?ISO-8859-1?Q?Carlos_Eduardo_Rodrigues_Di=F3genes?=" In-Reply-To: <1149104973.27709.4.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <1149104973.27709.4.camel@localhost.localdomain> X-Google-Sender-Auth: aee248fb7aae0f83 X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.571 tagged_above=-999 required=2 tests=[AWL=0.029, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.571 X-Spam-Level: Cc: gtk-devel-list@gnome.org Subject: Re: Color space transformations in GTK X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2006 15:16:54 -0000 On 5/31/06, Carlos Eduardo Rodrigues Di=F3genes = wrote: > Hi, > > There is any plan to add color spaces conversions in GTK+ (GDK or > Gdk-Pixbuf)? If the answear is no, why not? Pixel format conversions is not a small piece of code and the needed pixel formats varies from scenario to scenario. Most programs will not need such a large general infrastructure and the ones that really need it would probably not be satisfied with a simpler solution. What functionality is it you miss that you think fits into a GUI toolkit? (color management is a seperate issue to color space(pixel format) conversions according to my interpretation of your question). /=D8yvind K. --=20 =ABThe future is already here. It's just not very evenly distributed=BB -- William Gibson http://pippin.gimp.org/ http://ffii.org/ From timj@gtk.org Thu Jun 1 11:17:09 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 565CF3B0DC9 for ; Thu, 1 Jun 2006 11:17:09 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15377-03 for ; Thu, 1 Jun 2006 11:17:02 -0400 (EDT) Received: from webmail.hansenet.de (mail01.hansenet.de [213.191.73.61]) by menubar.gnome.org (Postfix) with ESMTP id 8AFEE3B0DB5 for ; Thu, 1 Jun 2006 11:17:00 -0400 (EDT) Received: from birnet.org (213.39.195.111) by webmail.hansenet.de (7.2.059) id 447D3FB2000502B1; Thu, 1 Jun 2006 17:16:59 +0200 Received: from master.birnet.private (localhost [127.0.0.1]) by birnet.org (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k51FGvIU003186 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 1 Jun 2006 17:16:57 +0200 Received: (from timj@localhost) by master.birnet.private (8.13.4/8.13.4/Submit) id k51FGpl3003183; Thu, 1 Jun 2006 17:16:51 +0200 Date: Thu, 1 Jun 2006 17:16:51 +0200 (CEST) From: Tim Janik X-X-Sender: timj@master.birnet.private To: Kristian Rietveld In-Reply-To: <20060531183045.GA7564@babi-pangang.org> Message-ID: References: <20060314132538.GA3526@babi-pangang.org> <443B4A8A.8000302@imendio.com> <20060425103017.GA15762@babi-pangang.org> <20060531183045.GA7564@babi-pangang.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.431 tagged_above=-999 required=2 tests=[AWL=0.168, BAYES_00=-2.599] X-Spam-Score: -2.431 X-Spam-Level: Cc: Gtk+ Developers , Soeren Sandmann Subject: Re: Callback based tooltips (Re: New tooltips API, continued) X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2006 15:17:10 -0000 On Wed, 31 May 2006, Kristian Rietveld wrote: > On Tue, Apr 25, 2006 at 03:08:12PM +0200, Soeren Sandmann wrote: >> I once wrote down how tooltips should behave: > > I mostly like the behaviour you described below. > >> - Tooltips are too intrusive. The text should be smaller, and not sure if this has been raised already... the font size of the tooltips should be exactly as large as the default font size (module tooltip markup of course) to avoid reducing usability of the tooltips in contrast to normal text (labels). >> they should to the right of the cursor, and a little below >> the cursor's center. --- ciaoTJ From timj@gtk.org Thu Jun 1 12:12:43 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id E5C0F3B0171 for ; Thu, 1 Jun 2006 12:12:42 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19272-05 for ; Thu, 1 Jun 2006 12:12:40 -0400 (EDT) Received: from webmail.hansenet.de (mail03.hansenet.de [213.191.73.10]) by menubar.gnome.org (Postfix) with ESMTP id 9C9433B015C for ; Thu, 1 Jun 2006 12:12:39 -0400 (EDT) Received: from birnet.org (213.39.195.111) by webmail.hansenet.de (7.2.059) id 447C08450012767E; Thu, 1 Jun 2006 18:12:37 +0200 Received: from master.birnet.private (localhost [127.0.0.1]) by birnet.org (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k51GCZTL005312 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 1 Jun 2006 18:12:35 +0200 Received: (from timj@localhost) by master.birnet.private (8.13.4/8.13.4/Submit) id k51GCY4h005311; Thu, 1 Jun 2006 18:12:34 +0200 Date: Thu, 1 Jun 2006 18:12:34 +0200 (CEST) From: Tim Janik X-X-Sender: timj@master.birnet.private To: Kristian Rietveld In-Reply-To: <20060531200823.GA7846@babi-pangang.org> Message-ID: References: <20060531200823.GA7846@babi-pangang.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.434 tagged_above=-999 required=2 tests=[AWL=0.165, BAYES_00=-2.599] X-Spam-Score: -2.434 X-Spam-Level: Cc: Gtk+ Developers , Matthias Clasen Subject: Re: Tooltips progress X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2006 16:12:43 -0000 On Wed, 31 May 2006, Kristian Rietveld wrote: > Last week I've been working on the tooltips implementation, using the > callback-based approach/interface discussed earlier on this mailing list. > The basics are working already including keyboard support and custom > windows. Before I can finalize a patch for reviewal, I have some comments > and questions. > > > In a follow up to his original mail, Tim is talking about adding the > following function: > > gdk_display_force_query_display (GdkDisplay *); > > I am not sure if this really belongs in GdkDisplay. Currently I have a: > > gtk_widget_force_query_tooltip (GtkWidget *widget); > > which works just fine for forcably updating a tooltip, in both keyboard > and mouse mode. I guess most people will usually know which widget's > tooltip to update. Opinions? yes, in most cases the widget will be known, but not in all. the trivial example is changing per-display settings like ::display-tooltips = off or the timeout. also, since we support nesting/overlaying of widgets. even the display might not be clear, which is why i actually proposed: void gtk_display_force_tooltip_query (GdkDisplay*); /* display may be NULL */ /* because of nesting/overlapping tooltips, widget is not always known * http://mail.gnome.org/archives/gtk-devel-list/2006-April/msg00030.html */ but you have a point here, since in most cases the widget will indeed be known, it'll be most convenient to also provide: void gtk_widget_force_query_tooltip (GtkWidget *widget) { gtk_display_force_tooltip_query (gtk_widget_get_display (widget)); } > Currently, we are using the following query-tooltips signal: > > gboolean (*query_tooltip) (GtkWidget *widget, > gint x, > gint y, > GtkTooltip *tooltip); > > But if a user sets a custom using gtk_widget_set_custom_window(), we don't > have to pass a GtkTooltip around. So currently I just set the tooltip > field to NULL, so the user knows he has to use his own custom tooltip > window (and we assume he has a reference to that). my original proposal http://mail.gnome.org/archives/gtk-devel-list/2006-April/msg00010.html included: GtkWindow* gtk_widget_get_tooltip_window (GtkWidget *widget); so the user doesn't need to duplicate tracking of this window. > Is this okay or do > we want to change this? We could also move the _set_custom_window() > functions into GtkTooltip for example. no, i intentionally didn't put it there. the reasoning for this was: - the setter should go along with a getter - the user should get at the custom window but *not* the tooltips window used by gtk. the latter is violated with a getter on GtkTooltip. > Implementing GtkTreeView tooltips in your application is now pretty easy, > just set up a query_tooltip callback and call gtk_tree_view_get_path_at_pos() > with the coordinates which are provided to you (but if x == -1, the keyboard > mode is enabled and then you should really call gtk_tree_view_get_cursor()). using x==-1&&y==-1 for keyboard mode was a bit of an aftermath patchup to my original proposal. Matthias Clasen now pointed out: > Using x == -1 to indicate a keyboard-triggered tooltip looks a bit > odd to me; how about adding a boolean parameter for this ? and i thnk he is right. another indication that we'd not want (-1,-1) is that you already talk about querying the cursor yourself. so it's probably better to adapt the signal to: gboolean (*query_tooltip) (GtkWidget *widget, gint x, gint y, gboolean keyboard_tip, GtkTooltip *tooltip); and preserve the x,y position. > Would this be sufficient, or do we want to add some special API for supporting > tooltips in the tree view, like having GtkTreeView implement the query > tooltip callback and have tooltip-markup properties on cell renderers. > Personally I think implementing the query-tooltip yourself is easy enough > for people to do and also really flexible, so there's no need for more API. i'd say let's first nail the basic tooltip API. GtkWidget already comes with a default handler. we can still add treeview convenience API later on if that is required. (and for that, i think it'd be easiest to forward the query_tooltip() signal to signals on the columns and cell renderers). > Since we re-query for a tooltip on mouse motion, I was wondering what we > should do in keyboard mode if a key is pressed in, for example, GtkTreeView. > A key press there might change the cursor and we might want to update the > tooltip contents. Do we want stock GTK+ to take care of this, or should the > user do this himself? (For example by calling gtk_widget_force_tooltip_query > from the GtkTreeSelection::changed callback). i think i'd handle key press events like mouse motion and scroll events, i.e. re-query. that eases things on the user side and is consistent with movement. (the basic idea behind my proposal was that gtk+ takes care of the required granularity whenever possible, so gtk_display_force_tooltip_query() needs to allmost never be used). > thanks, > > -kris. > --- ciaoTJ From timj@gtk.org Thu Jun 1 12:21:35 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 96AD53B0E27 for ; Thu, 1 Jun 2006 12:21:35 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19725-05 for ; Thu, 1 Jun 2006 12:21:33 -0400 (EDT) Received: from webmail.hansenet.de (mail02.hansenet.de [213.191.73.62]) by menubar.gnome.org (Postfix) with ESMTP id AE4893B0115 for ; Thu, 1 Jun 2006 12:21:33 -0400 (EDT) Received: from birnet.org (213.39.195.111) by webmail.hansenet.de (7.2.059) id 447C276B001342DD; Thu, 1 Jun 2006 18:21:31 +0200 Received: from master.birnet.private (localhost [127.0.0.1]) by birnet.org (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k51GLTmR005587 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 1 Jun 2006 18:21:29 +0200 Received: (from timj@localhost) by master.birnet.private (8.13.4/8.13.4/Submit) id k51GLTBN005586; Thu, 1 Jun 2006 18:21:29 +0200 Date: Thu, 1 Jun 2006 18:21:29 +0200 (CEST) From: Tim Janik X-X-Sender: timj@master.birnet.private To: Matthias Clasen In-Reply-To: Message-ID: References: <20060531200823.GA7846@babi-pangang.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.436 tagged_above=-999 required=2 tests=[AWL=0.163, BAYES_00=-2.599] X-Spam-Score: -2.436 X-Spam-Level: Cc: Gtk+ Developers , Kristian Rietveld Subject: Re: Tooltips progress X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2006 16:21:35 -0000 On Thu, 1 Jun 2006, Matthias Clasen wrote: >> Attached is some sample code using the new API. Opinions, comments, >> suggestions are appreciated. >> > > I don't remember too much of the original proposal, so I'll just go > by what I see in the examples... > > What is the relation between the tooltip-markup and has-tooltip > properties ? setting ::tooltip-markup should automatically set ::has-tooltip=TRUE; as mentioned in the original proposal: http://mail.gnome.org/archives/gtk-devel-list/2006-April/msg00010.html > Is has-tooltip automatically set when setting tooltip-markup ? > Or do you only need to set has-tooltip if you want to connect to > query-tooltip ? the idea behind ::has-tooltip is to reduce the number of required signal emissions to figure a tooltip. e.g. by adding a PRIVATE_GTK_* flag that indicates if the ::query-tooltips() emission is neccessary. maybe it'd helpt to rename that property to ::can-tooltip? > Is the tooltip window available as a property too ? (The example uses > a dedicated setter for it). i don't quite see a need for that. the custom window is only useful if you implement your own ::query-tooltip() handler anyway and there you could simply use the getter. (if you want to argue consistency with other things settable/gettable on widgets though, then yes, you have a point for also exporting it as a property) > The example doesn't show tooltips constructed using the old tooltips > api, but I assume those will continue to work as before, right ? that was the plan, i.e. you'd basically just do: void gtk_tooltips_set_tip (GtkTooltips *tooltips, GtkWidget *widget, const gchar *tip_text, const gchar *tip_private) { g_object_set (widget, "tooltip-markup", tip_text, NULL); } > Matthias --- ciaoTJ From timj@gtk.org Thu Jun 1 12:37:26 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 777F13B0DE5 for ; Thu, 1 Jun 2006 12:37:26 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20777-08 for ; Thu, 1 Jun 2006 12:37:17 -0400 (EDT) Received: from webmail.hansenet.de (mail03.hansenet.de [213.191.73.10]) by menubar.gnome.org (Postfix) with ESMTP id DD7453B0E15 for ; Thu, 1 Jun 2006 12:37:16 -0400 (EDT) Received: from birnet.org (213.39.195.111) by webmail.hansenet.de (7.2.059) id 447C084500128D01; Thu, 1 Jun 2006 18:36:53 +0200 Received: from master.birnet.private (localhost [127.0.0.1]) by birnet.org (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k51Gaj8T006024 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 1 Jun 2006 18:36:45 +0200 Received: (from timj@localhost) by master.birnet.private (8.13.4/8.13.4/Submit) id k51Gaj0d006023; Thu, 1 Jun 2006 18:36:45 +0200 Date: Thu, 1 Jun 2006 18:36:45 +0200 (CEST) From: Tim Janik X-X-Sender: timj@master.birnet.private To: Michael Natterer In-Reply-To: <1149172764.5721.13.camel@localhost> Message-ID: References: <20060531200823.GA7846@babi-pangang.org> <1149172764.5721.13.camel@localhost> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.439 tagged_above=-999 required=2 tests=[AWL=0.160, BAYES_00=-2.599] X-Spam-Score: -2.439 X-Spam-Level: Cc: Gtk+ Developers , Kristian Rietveld Subject: Re: Tooltips progress X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2006 16:37:26 -0000 On Thu, 1 Jun 2006, Michael Natterer wrote: > On Wed, 2006-05-31 at 22:08 +0200, Kristian Rietveld wrote: > >> Currently, we are using the following query-tooltips signal: >> >> gboolean (*query_tooltip) (GtkWidget *widget, >> gint x, >> gint y, >> GtkTooltip *tooltip); >> >> But if a user sets a custom using gtk_widget_set_custom_window(), we don't >> have to pass a GtkTooltip around. So currently I just set the tooltip >> field to NULL, so the user knows he has to use his own custom tooltip >> window (and we assume he has a reference to that). Is this okay or do >> we want to change this? We could also move the _set_custom_window() >> functions into GtkTooltip for example. > > I would very much appreciate if the GtkTooltip object also kept track > of the custom window. IMHO it makes no sense to handle this differently. the widget is meant to do that: void gtk_widget_set_tooltip_window (GtkWidget *widget, GtkWindow *custom_window); GtkWindow* gtk_widget_get_tooltip_window (GtkWidget *widget); for reasons outlined in a previous reply from me to kris. > gtk_tooltip_set_markup() vs. gtk_tooltip_set_window() > > simply feels much better than the asymmetry in > > gtk_tooltip_set_markup() vs. gtk_widget_set_tooltip_window() well, you'd not use GtkTooltip at all if you used gtk_widget_set_tooltip_window() before. in that way, the "asymmetry" simply reflects your usage. > The current approach even limits the new tooltip system's use cases, > since you have to set the custom window *outside* the callback. There > is no way to decide *in* the callback if a standard tooltip is > sufficient, or if a custom window is needed. i don't think it'd be clear that/if the custom window will be available in the GtkTooltip object again upon the next ::query-tooltip() emission. especially since users are not supposed to access GtkTooltip objects/structures in anyway *outside* of ::query-tooltip(), as outlined originally: http://mail.gnome.org/archives/gtk-devel-list/2006-April/msg00010.html also, passing GtkTooltip as NULL is meant to be as a clear indication that the user has to tinker with gtk_widget_get_tooltip_window() instead of the tooltip object. this avoids ambiguities like: static gboolean query_tooltip (GtkWidget *widget, gint x, gint y, GtkTooltip *tooltip) { gtk_tooltip_set_markup (tooltip, "See Me?"); g_object_new (GTK_TYPE_BUTTON, "parent", gtk_widget_get_tooltip_window(), "label", "Can You Click Me?", NULL); gtk_tooltip_set_icon (tooltip, messup_pixbuf); } what's the tooltip code supposed to do here? and yes, the API basically enforces that you decide per widget if an own tooltip window is needed or not. but i don't think that is a strong limitation, we have been discussing usage cases quite some in thise thread and nothing required to defer this decision into the callback (and no existing tooltip code i know of requires this either). so giving the benefits in API (and implementation) this provides, i think it is a reasonable limitation to make. > Another problem is the assymetry in getting the relevant data to the > callback. With markup, the GtkTooltip can be queried for the markup, > if it's a custom window, you have to get it to the callback somehow. Kris just forgot the getter for the custom window on the widget, so signal handler user_data is left alone. > In your example code it's passed as user_data, but user_data is > often not available since it's needed for other things, so you > have to add a "GtkWidget *tooltip_window" to the "other thing". > If "other thing" is e.g. the application toplevel window, which > of the sub-widget's tooltips should it keep? All of them? People > will in many cases end up attaching the tooltip window to the > widget. > > I also fail to see why the "has-tooltip" property has to be > set to TRUE, even tho a tooltip window was set on the widget. > i think this can be come by if we implement: - gtk_widget_set_tooltip_window() should automatically set: GtkWidget::has-tooltip = (custom_window != NULL || GtkWidget::tooltip-markup != ""); - setting GtkWidget::tooltip-markup should automatically set: GtkWidget::has-tooltip = (custom_window != NULL || GtkWidget::tooltip-markup != ""); right? > ciao, > --mitch > --- ciaoTJ From tkomulai@gmail.com Thu Jun 1 15:14:41 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 5A7023B0D70 for ; Thu, 1 Jun 2006 15:14:41 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31172-10 for ; Thu, 1 Jun 2006 15:14:40 -0400 (EDT) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.174]) by menubar.gnome.org (Postfix) with ESMTP id D35083B0CA3 for ; Thu, 1 Jun 2006 15:14:39 -0400 (EDT) Received: by ug-out-1314.google.com with SMTP id o2so222332uge for ; Thu, 01 Jun 2006 12:14:38 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=pkJ9GUF7tBRSDYTFZk62hCunrEDWh/ETW5JoJhlQx7UdB4QeOLJv/qztCngXO4Co/DiXf7ruqlpPxLBRYMp1hjNHoS2y4j0YEr7klSoN2TI6/rPnna1ZG+sfsuFqJaUK0lPq+fzd8NFeO3Vaf+6D8oJI9g3JXpXVTm3KfKENqYU= Received: by 10.78.47.15 with SMTP id u15mr181197huu; Thu, 01 Jun 2006 12:14:38 -0700 (PDT) Received: by 10.78.41.17 with HTTP; Thu, 1 Jun 2006 12:14:38 -0700 (PDT) Message-ID: <68bd3e050606011214i6c36109chff11c7242268b84@mail.gmail.com> Date: Thu, 1 Jun 2006 22:14:38 +0300 From: "Tommi Komulainen" Sender: tkomulai@gmail.com To: gtk-devel-list@gnome.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20060314132538.GA3526@babi-pangang.org> <443B4A8A.8000302@imendio.com> <20060425103017.GA15762@babi-pangang.org> <20060531183045.GA7564@babi-pangang.org> X-Google-Sender-Auth: 6188435c8e783fb2 X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.792 tagged_above=-999 required=2 tests=[AWL=-0.750, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.558, SPF_PASS=-0.001] X-Spam-Score: -1.792 X-Spam-Level: Subject: Re: Callback based tooltips (Re: New tooltips API, continued) X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2006 19:14:41 -0000 On 6/1/06, Tim Janik wrote: > On Wed, 31 May 2006, Kristian Rietveld wrote: > > > On Tue, Apr 25, 2006 at 03:08:12PM +0200, Soeren Sandmann wrote: > >> I once wrote down how tooltips should behave: > > > > I mostly like the behaviour you described below. > > > >> - Tooltips are too intrusive. The text should be smaller, and > > not sure if this has been raised already... > the font size of the tooltips should be exactly as large as the default > font size (module tooltip markup of course) to avoid reducing usability > of the tooltips in contrast to normal text (labels). As long as the font (and other things) are easily themable, the default values are not as important. And as gtk+ doesn't currently have any kind of design for using different font sizes in different contexts, I'd say the default font is a good default. Until someone comes up with a plan that looks at the bigger picture. -- Tommi Komulainen tommi.komulainen@iki.fi From mclasen@redhat.com Thu Jun 1 19:12:39 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id B0B143B0135 for ; Thu, 1 Jun 2006 19:12:39 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12736-06 for ; Thu, 1 Jun 2006 19:12:36 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id 567E43B0061 for ; Thu, 1 Jun 2006 19:12:36 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k51NCZWS017685 for ; Thu, 1 Jun 2006 19:12:35 -0400 Received: from lacrosse.corp.redhat.com (lacrosse.corp.redhat.com [172.16.52.154]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k51NCZpf020363 for ; Thu, 1 Jun 2006 19:12:35 -0400 Received: from [172.16.83.142] (vpn83-142.boston.redhat.com [172.16.83.142]) by lacrosse.corp.redhat.com (8.12.11.20060308/8.11.6) with ESMTP id k51NCXoG026214 for ; Thu, 1 Jun 2006 19:12:33 -0400 From: Matthias Clasen To: gtk-devel-list@gnome.org Content-Type: multipart/mixed; boundary="=-xjDvOKJb0tdB52kmWdgp" Organization: Red Hat Date: Thu, 01 Jun 2006 19:13:59 -0400 Message-Id: <1149203639.27455.9.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.7.2.1 (2.7.2.1-4) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.466 tagged_above=-999 required=2 tests=[AWL=-0.019, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, TW_GT=0.077, TW_XD=0.077] X-Spam-Score: -2.466 X-Spam-Level: Subject: Print preview api X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2006 23:12:39 -0000 --=-xjDvOKJb0tdB52kmWdgp Content-Type: text/plain Content-Transfer-Encoding: 7bit Ok, after a lot of work (mostly by John and Alex), we finally have a proposal for a print preview api that will allow us to use an external viewer by default, but also support internal preview. It consists of the following pieces: 1) GtkPrintOperation gets a new signal gboolean (*preview) (GtkPrintOperation *operation, GtkPrintOperationPreview *preview, GtkPrintContext *context, GtkWindow *parent); This signal is emitted when the user clicks the preview button. It the application does not handle it, the default handler will arrange for the external viewer to be spawned. An application that handles the preview internally should return TRUE from the signal handler. The GtkPrintOperationPreview that is passed to the signal handler lets the application control the preview. 2) The GtkPrintOperationPreview interface has a number of signals: void (*ready) (GtkPrintOperationPreview *preview, GtkPrintContext *context); The ready signal is emitted when pagination is done. The GtkPrintOperation::preview handler should connect to this signal to know when it is safe to start displaying pages. void (*got_page_size) (GtkPrintOperationPreview *preview, GtkPrintContext *context, GtkPageSetup *page_setup); The got-page-size signal is emitted for every rendered page, when the page setup for the page is know. This signal can be used to adjust the cairo context used for rendering the page (e.g. for resizing the preview window). And methods: void gtk_print_operation_preview_render_page (GtkPrintOperationPreview *preview, gint page_nr) Renders the requested page to the cairo context currently set on the print context for the preview. void gtk_print_operation_preview_end_preview (GtkPrintOperationPreview *preview) Must be called to clean up when the preview is finished. 3) A new way of handling the cairo context associated with a GtkPrintContext. A print context is no longer directly associated with a cairo surface. Instead, a cairo context is set with void gtk_print_context_set_cairo_context (GtkPrintContext *context, cairo_t *cr, double dpi_x, double dpi_y); And this can be repeated, typically in a got-page-size handler. The attached patch against current cvs has a very basic preview implementation in print-editor.c that demonstrates this api. Comments appreciated, Matthias --=-xjDvOKJb0tdB52kmWdgp Content-Disposition: attachment; filename=gtk-print-preview-7.diff Content-Type: text/x-patch; name=gtk-print-preview-7.diff; charset=UTF-8 Content-Transfer-Encoding: 7bit Index: gtk/Makefile.am =================================================================== RCS file: /cvs/gnome/gtk+/gtk/Makefile.am,v retrieving revision 1.308 diff -u -p -r1.308 Makefile.am --- gtk/Makefile.am 22 May 2006 17:19:09 -0000 1.308 +++ gtk/Makefile.am 1 Jun 2006 20:34:39 -0000 @@ -4,6 +4,7 @@ SUBDIRS=theme-bits if OS_UNIX SUBDIRS += xdgmime +GTK_PRINT_PREVIEW_COMMAND="evince %f" endif DIST_SUBDIRS=theme-bits xdgmime @@ -25,6 +26,7 @@ INCLUDES = \ -DGTK_HOST=\"$(host)\" \ -DGTK_COMPILATION \ -DGTK_PRINT_BACKENDS=\"$(GTK_PRINT_BACKENDS)\" \ + -DGTK_PRINT_PREVIEW_COMMAND=\"$(GTK_PRINT_PREVIEW_COMMAND)\" \ -I$(top_builddir)/gtk \ -I$(top_srcdir) -I../gdk \ -I$(top_srcdir)/gdk \ @@ -231,6 +233,7 @@ gtk_public_h_sources = \ gtkpreview.h \ gtkprintcontext.h \ gtkprintoperation.h \ + gtkprintoperationpreview.h \ gtkprintsettings.h \ gtkprivate.h \ gtkprogress.h \ @@ -487,6 +490,7 @@ gtk_c_sources = \ gtkpreview.c \ gtkprintcontext.c \ gtkprintoperation.c \ + gtkprintoperationpreview.c \ gtkprintsettings.c \ gtkprintutils.c \ gtkprogress.c \ Index: gtk/gtkmarshalers.list =================================================================== RCS file: /cvs/gnome/gtk+/gtk/gtkmarshalers.list,v retrieving revision 1.67 diff -u -p -r1.67 gtkmarshalers.list --- gtk/gtkmarshalers.list 22 May 2006 17:19:09 -0000 1.67 +++ gtk/gtkmarshalers.list 1 Jun 2006 20:34:39 -0000 @@ -32,6 +32,7 @@ BOOLEAN:OBJECT,INT,INT,UINT BOOLEAN:OBJECT,STRING,STRING,BOXED BOOLEAN:OBJECT,BOXED BOOLEAN:OBJECT,BOXED,BOXED +BOOLEAN:OBJECT,OBJECT,OBJECT BOOLEAN:OBJECT,STRING,STRING BOOLEAN:INT BOOLEAN:INT,INT Index: gtk/gtkprintbackend.c =================================================================== RCS file: /cvs/gnome/gtk+/gtk/gtkprintbackend.c,v retrieving revision 1.7 diff -u -p -r1.7 gtkprintbackend.c --- gtk/gtkprintbackend.c 1 Jun 2006 05:02:56 -0000 1.7 +++ gtk/gtkprintbackend.c 1 Jun 2006 20:34:39 -0000 @@ -200,7 +200,6 @@ _gtk_print_backend_create (const char *b GtkPrintBackendModule *pb_module; GtkPrintBackend *pb; - /* TODO: make module loading code work */ for (l = loaded_backends; l != NULL; l = l->next) { pb_module = l->data; @@ -255,6 +254,11 @@ gtk_print_backend_initialize (void) GTK_PRINT_BACKENDS, GTK_PARAM_READWRITE)); + gtk_settings_install_property (g_param_spec_string ("gtk-print-preview-command", + P_("Default command to run when displaying a print preview"), + P_("Command to run when displaying a print preview"), + GTK_PRINT_PREVIEW_COMMAND, + GTK_PARAM_READWRITE)); initialized = TRUE; } } Index: gtk/gtkprintbackend.h =================================================================== RCS file: /cvs/gnome/gtk+/gtk/gtkprintbackend.h,v retrieving revision 1.8 diff -u -p -r1.8 gtkprintbackend.h --- gtk/gtkprintbackend.h 24 May 2006 10:50:56 -0000 1.8 +++ gtk/gtkprintbackend.h 1 Jun 2006 20:34:39 -0000 @@ -140,6 +140,9 @@ void gtk_print_backend_print_stre GList * gtk_print_backend_load_modules (void); void gtk_print_backend_destroy (GtkPrintBackend *print_backend); +/* Methods private to gtk */ +GtkPrintBackend * _gtk_print_backend_create (const char *backend_name); + /* Backend-only functions for GtkPrintBackend */ void gtk_print_backend_add_printer (GtkPrintBackend *print_backend, Index: gtk/gtkprintcontext.c =================================================================== RCS file: /cvs/gnome/gtk+/gtk/gtkprintcontext.c,v retrieving revision 1.4 diff -u -p -r1.4 gtkprintcontext.c --- gtk/gtkprintcontext.c 31 May 2006 13:38:10 -0000 1.4 +++ gtk/gtkprintcontext.c 1 Jun 2006 20:34:39 -0000 @@ -40,6 +40,9 @@ struct _GtkPrintContext GtkPageSetup *page_setup; PangoFontMap *fontmap; + gdouble surface_dpi_x; + gdouble surface_dpi_y; + gdouble pixels_per_unit_x; gdouble pixels_per_unit_y; }; @@ -60,8 +63,8 @@ gtk_print_context_finalize (GObject *obj if (context->page_setup) g_object_unref (context->page_setup); - cairo_destroy (context->cr); - + if (context->cr) + cairo_destroy (context->cr); G_OBJECT_CLASS (gtk_print_context_parent_class)->finalize (object); } @@ -83,15 +86,31 @@ gtk_print_context_class_init (GtkPrintCo GtkPrintContext * _gtk_print_context_new (GtkPrintOperation *op) { - GtkPrintOperationPrivate *priv = op->priv; GtkPrintContext *context; context = g_object_new (GTK_TYPE_PRINT_CONTEXT, NULL); context->op = op; - context->cr = cairo_create (priv->surface); + context->cr = NULL; + context->fontmap = pango_cairo_font_map_new (); + + return context; +} + +void +gtk_print_context_set_cairo_context (GtkPrintContext *context, + cairo_t *cr, + double dpi_x, + double dpi_y) +{ + if (context->cr) + cairo_destroy (context->cr); + + context->cr = cairo_reference (cr); + context->surface_dpi_x = dpi_x; + context->surface_dpi_y = dpi_y; - switch (priv->unit) + switch (context->op->priv->unit) { default: case GTK_UNIT_PIXEL: @@ -100,34 +119,31 @@ _gtk_print_context_new (GtkPrintOperatio context->pixels_per_unit_y = 1.0; break; case GTK_UNIT_POINTS: - context->pixels_per_unit_x = priv->dpi_x / POINTS_PER_INCH; - context->pixels_per_unit_y = priv->dpi_y / POINTS_PER_INCH; + context->pixels_per_unit_x = dpi_x / POINTS_PER_INCH; + context->pixels_per_unit_y = dpi_y / POINTS_PER_INCH; break; case GTK_UNIT_INCH: - context->pixels_per_unit_x = priv->dpi_x; - context->pixels_per_unit_y = priv->dpi_y; + context->pixels_per_unit_x = dpi_x; + context->pixels_per_unit_y = dpi_y; break; case GTK_UNIT_MM: - context->pixels_per_unit_x = priv->dpi_x / MM_PER_INCH; - context->pixels_per_unit_y = priv->dpi_y / MM_PER_INCH; + context->pixels_per_unit_x = dpi_x / MM_PER_INCH; + context->pixels_per_unit_y = dpi_y / MM_PER_INCH; break; } cairo_scale (context->cr, context->pixels_per_unit_x, context->pixels_per_unit_y); - context->fontmap = pango_cairo_font_map_new (); /* We use the unit-scaled resolution, as we still want fonts given in points to work */ pango_cairo_font_map_set_resolution (PANGO_CAIRO_FONT_MAP (context->fontmap), - priv->dpi_y / context->pixels_per_unit_y); - - return context; + dpi_y / context->pixels_per_unit_y); } + void _gtk_print_context_rotate_according_to_orientation (GtkPrintContext *context) { - GtkPrintOperationPrivate *priv = context->op->priv; cairo_t *cr = context->cr; cairo_matrix_t matrix; GtkPaperSize *paper_size; @@ -136,9 +152,9 @@ _gtk_print_context_rotate_according_to_o paper_size = gtk_page_setup_get_paper_size (context->page_setup); width = gtk_paper_size_get_width (paper_size, GTK_UNIT_INCH); - width = width * priv->dpi_x / context->pixels_per_unit_x; + width = width * context->surface_dpi_x / context->pixels_per_unit_x; height = gtk_paper_size_get_height (paper_size, GTK_UNIT_INCH); - height = height * priv->dpi_y / context->pixels_per_unit_y; + height = height * context->surface_dpi_y / context->pixels_per_unit_y; switch (gtk_page_setup_get_orientation (context->page_setup)) { @@ -188,8 +204,8 @@ _gtk_print_context_translate_into_margin top = gtk_page_setup_get_top_margin (context->page_setup, GTK_UNIT_INCH); cairo_translate (context->cr, - left * priv->dpi_x / context->pixels_per_unit_x, - top * priv->dpi_y / context->pixels_per_unit_y); + left * context->surface_dpi_x / context->pixels_per_unit_x, + top * context->surface_dpi_y / context->pixels_per_unit_y); } void @@ -272,7 +288,7 @@ gtk_print_context_get_width (GtkPrintCon width = gtk_page_setup_get_page_width (context->page_setup, GTK_UNIT_INCH); /* Really dpi_x? What about landscape? what does dpi_x mean in that case? */ - return width * priv->dpi_x / context->pixels_per_unit_x; + return width * context->surface_dpi_x / context->pixels_per_unit_x; } /** @@ -300,8 +316,8 @@ gtk_print_context_get_height (GtkPrintCo else height = gtk_page_setup_get_page_height (context->page_setup, GTK_UNIT_INCH); - /* Really dpi_x? What about landscape? what does dpi_x mean in that case? */ - return height * priv->dpi_y / context->pixels_per_unit_y; + /* Really dpi_y? What about landscape? what does dpi_y mean in that case? */ + return height * context->surface_dpi_y / context->pixels_per_unit_y; } /** @@ -320,7 +336,7 @@ gtk_print_context_get_dpi_x (GtkPrintCon { g_return_val_if_fail (GTK_IS_PRINT_CONTEXT (context), 0); - return context->op->priv->dpi_x; + return context->surface_dpi_x; } /** @@ -339,7 +355,7 @@ gtk_print_context_get_dpi_y (GtkPrintCon { g_return_val_if_fail (GTK_IS_PRINT_CONTEXT (context), 0); - return context->op->priv->dpi_y; + return context->surface_dpi_y; } /** @@ -376,10 +392,16 @@ PangoContext * gtk_print_context_create_pango_context (GtkPrintContext *context) { PangoContext *pango_context; + cairo_font_options_t *options; g_return_val_if_fail (GTK_IS_PRINT_CONTEXT (context), NULL); pango_context = pango_cairo_font_map_create_context (PANGO_CAIRO_FONT_MAP (context->fontmap)); + + options = cairo_font_options_create (); + cairo_font_options_set_hint_metrics (options, CAIRO_HINT_METRICS_OFF); + pango_cairo_context_set_font_options (pango_context, options); + cairo_font_options_destroy (options); return pango_context; } Index: gtk/gtkprintcontext.h =================================================================== RCS file: /cvs/gnome/gtk+/gtk/gtkprintcontext.h,v retrieving revision 1.3 diff -u -p -r1.3 gtkprintcontext.h --- gtk/gtkprintcontext.h 31 May 2006 13:38:10 -0000 1.3 +++ gtk/gtkprintcontext.h 1 Jun 2006 20:34:39 -0000 @@ -51,6 +51,11 @@ PangoFontMap *gtk_print_context_get_pang PangoContext *gtk_print_context_create_pango_context (GtkPrintContext *context); PangoLayout *gtk_print_context_create_pango_layout (GtkPrintContext *context); +/* Needed for preview implementations */ +void gtk_print_context_set_cairo_context (GtkPrintContext *context, + cairo_t *cr, + double dpi_x, + double dpi_y); G_END_DECLS Index: gtk/gtkprintjob.c =================================================================== RCS file: /cvs/gnome/gtk+/gtk/gtkprintjob.c,v retrieving revision 1.8 diff -u -p -r1.8 gtkprintjob.c --- gtk/gtkprintjob.c 16 May 2006 16:13:48 -0000 1.8 +++ gtk/gtkprintjob.c 1 Jun 2006 20:34:39 -0000 @@ -212,14 +212,14 @@ gtk_print_job_constructor (GType job = GTK_PRINT_JOB (object); priv = job->priv; - g_assert (priv->printer_set && - priv->settings_set && + g_assert (priv->settings_set && priv->page_setup_set); - - _gtk_printer_prepare_for_print (priv->printer, - job, - priv->settings, - priv->page_setup); + + if (priv->printer) + _gtk_printer_prepare_for_print (priv->printer, + job, + priv->settings, + priv->page_setup); return object; } @@ -545,8 +545,12 @@ gtk_print_job_set_property (GObject case GTK_PRINT_JOB_PROP_PRINTER: priv->printer = GTK_PRINTER (g_value_dup_object (value)); - priv->printer_set = TRUE; - priv->backend = g_object_ref (gtk_printer_get_backend (priv->printer)); + + if (priv->printer != NULL) + { + priv->printer_set = TRUE; + priv->backend = g_object_ref (gtk_printer_get_backend (priv->printer)); + } break; case GTK_PRINT_JOB_PROP_PAGE_SETUP: Index: gtk/gtkprintoperation-private.h =================================================================== RCS file: /cvs/gnome/gtk+/gtk/gtkprintoperation-private.h,v retrieving revision 1.11 diff -u -p -r1.11 gtkprintoperation-private.h --- gtk/gtkprintoperation-private.h 1 Jun 2006 12:38:07 -0000 1.11 +++ gtk/gtkprintoperation-private.h 1 Jun 2006 20:34:39 -0000 @@ -46,9 +46,11 @@ struct _GtkPrintOperationPrivate guint print_pages_idle_id; guint show_progress_timeout_id; + GtkPrintContext *print_context; + /* Data for the print job: */ - cairo_surface_t *surface; - gdouble dpi_x, dpi_y; + /* cairo_surface_t *surface; */ + /* gdouble dpi_x, dpi_y; */ GtkPrintPages print_pages; GtkPageRange *page_ranges; @@ -84,11 +86,23 @@ GtkPrintOperationResult _gtk_print_opera GError **error); typedef void (* GtkPrintOperationPrintFunc) (GtkPrintOperation *op, - GtkWindow *parent); + GtkWindow *parent, + gboolean is_preview); void _gtk_print_operation_platform_backend_run_dialog_async (GtkPrintOperation *op, GtkWindow *parent, GtkPrintOperationPrintFunc print_cb); + +void _gtk_print_operation_platform_backend_launch_preview (GtkPrintOperation *op, + GtkWindow *parent, + const char *filename); + +cairo_surface_t *_gtk_print_operation_platform_backend_create_preview_surface (GtkPrintOperation *operation, + gdouble width, + gdouble heigh, + gdouble *dpi_x, + gdouble *dpi_y, + const gchar *target); void _gtk_print_operation_set_status (GtkPrintOperation *op, GtkPrintStatus status, Index: gtk/gtkprintoperation-unix.c =================================================================== RCS file: /cvs/gnome/gtk+/gtk/gtkprintoperation-unix.c,v retrieving revision 1.19 diff -u -p -r1.19 gtkprintoperation-unix.c --- gtk/gtkprintoperation-unix.c 1 Jun 2006 12:38:07 -0000 1.19 +++ gtk/gtkprintoperation-unix.c 1 Jun 2006 20:34:39 -0000 @@ -25,6 +25,9 @@ #include #include #include +#include +#include +#include #include "gtkprintoperation-private.h" #include "gtkmarshal.h" @@ -41,13 +44,17 @@ #include "gtkalias.h" #include "gtkintl.h" - typedef struct { - GtkPrintJob *job; /* the job we are sending to the printer */ - gulong job_status_changed_tag; GtkWindow *parent; /* just in case we need to throw error dialogs */ GMainLoop *loop; gboolean data_sent; + + /* Real printing (not preview: */ + GtkPrintJob *job; /* the job we are sending to the printer */ + cairo_surface_t *surface; + gulong job_status_changed_tag; + + } GtkPrintOperationUnix; typedef struct _PrinterFinder PrinterFinder; @@ -62,21 +69,24 @@ unix_start_page (GtkPrintOperation *op, GtkPrintContext *print_context, GtkPageSetup *page_setup) { + GtkPrintOperationUnix *op_unix; GtkPaperSize *paper_size; cairo_surface_type_t type; double w, h; + op_unix = op->priv->platform_data; + paper_size = gtk_page_setup_get_paper_size (page_setup); w = gtk_paper_size_get_width (paper_size, GTK_UNIT_POINTS); h = gtk_paper_size_get_height (paper_size, GTK_UNIT_POINTS); - type = cairo_surface_get_type (op->priv->surface); + type = cairo_surface_get_type (op_unix->surface); if (type == CAIRO_SURFACE_TYPE_PS) - cairo_ps_surface_set_size (op->priv->surface, w, h); + cairo_ps_surface_set_size (op_unix->surface, w, h); else if (type == CAIRO_SURFACE_TYPE_PDF) - cairo_pdf_surface_set_size (op->priv->surface, w, h); + cairo_pdf_surface_set_size (op_unix->surface, w, h); } static void @@ -102,6 +112,112 @@ op_unix_free (GtkPrintOperationUnix *op_ g_free (op_unix); } +static char * +shell_command_substitute_file (const gchar *cmd, + const gchar *filename) +{ + const char *inptr, *start; + char *result; + GString *final; + + g_return_val_if_fail (cmd != NULL, NULL); + g_return_val_if_fail (filename != NULL, NULL); + + result = NULL; + final = g_string_new (NULL); + + start = inptr = cmd; + + while ((inptr = strchr (inptr, '%')) != NULL) + { + g_string_append_len (final, start, inptr - start); + inptr++; + switch (*inptr) + { + case 'f': + g_string_append (final, filename ? filename : ""); + break; + + case '%': + g_string_append_c (final, '%'); + break; + + default: + g_string_append_c (final, '%'); + if (*inptr) + g_string_append_c (final, *inptr); + break; + } + if (*inptr) + inptr++; + start = inptr; + } + g_string_append (final, start); + + result = final->str; + + g_string_free (final, FALSE); + + return result; +} + +void +_gtk_print_operation_platform_backend_launch_preview (GtkPrintOperation *op, + GtkWindow *parent, + const char *filename) +{ + int argc; + gchar **argv; + gchar *cmd; + gchar *preview_cmd; + GtkSettings *settings; + gchar *quoted_filename; + GdkScreen *screen; + GError *error = NULL; + + settings = gtk_settings_get_default (); + g_object_get (settings, "gtk-print-preview-command", &preview_cmd, NULL); + + quoted_filename = g_shell_quote (filename); + cmd = shell_command_substitute_file (preview_cmd, quoted_filename); + g_shell_parse_argv (cmd, &argc, &argv, &error); + + if (error !=NULL) + goto out; + + if (parent) + screen = gtk_window_get_screen (parent); + else + screen = gdk_screen_get_default (); + + gdk_spawn_on_screen (screen, NULL, argv, NULL, G_SPAWN_SEARCH_PATH, NULL, NULL, NULL, &error); + + out: + if (error != NULL) + { + GtkWidget *edialog; + edialog = gtk_message_dialog_new (parent, + GTK_DIALOG_DESTROY_WITH_PARENT, + GTK_MESSAGE_ERROR, + GTK_BUTTONS_CLOSE, + _("Error launching preview") /* FIXME better text */); + gtk_message_dialog_format_secondary_text (GTK_MESSAGE_DIALOG (edialog), + "%s", error->message); + gtk_window_set_modal (GTK_WINDOW (edialog), TRUE); + g_signal_connect (edialog, "response", + G_CALLBACK (gtk_widget_destroy), NULL); + + gtk_window_present (GTK_WINDOW (edialog)); + + g_error_free (error); + } + + g_free (cmd); + g_free (quoted_filename); + g_free (preview_cmd); + g_strfreev (argv); +} + static void unix_finish_send (GtkPrintJob *job, void *user_data, @@ -129,6 +245,7 @@ unix_finish_send (GtkPrintJob *job, } op_unix->data_sent = TRUE; + if (op_unix->loop) g_main_loop_quit (op_unix->loop); } @@ -140,6 +257,8 @@ unix_end_run (GtkPrintOperation *op, { GtkPrintOperationUnix *op_unix = op->priv->platform_data; + cairo_surface_finish (op_unix->surface); + if (cancelled) return; @@ -147,10 +266,11 @@ unix_end_run (GtkPrintOperation *op, op_unix->loop = g_main_loop_new (NULL, FALSE); /* TODO: Check for error */ - gtk_print_job_send (op_unix->job, - unix_finish_send, - op_unix, NULL, - NULL); + if (op_unix->job != NULL) + gtk_print_job_send (op_unix->job, + unix_finish_send, + op_unix, NULL, + NULL); if (wait) { @@ -253,64 +373,66 @@ finish_print (PrintResponseData *rdata, { GtkPrintOperation *op = rdata->op; GtkPrintOperationPrivate *priv = op->priv; + gboolean is_preview; - priv->start_page = unix_start_page; - priv->end_page = unix_end_page; - priv->end_run = unix_end_run; + g_print ("finish_print\n"); + + is_preview = rdata->result == GTK_PRINT_OPERATION_RESULT_PREVIEW; if (rdata->do_print) { - GtkPrintOperationUnix *op_unix; - gtk_print_operation_set_print_settings (op, settings); - - op_unix = g_new0 (GtkPrintOperationUnix, 1); - op_unix->job = gtk_print_job_new (priv->job_name, - printer, - settings, - page_setup); + op->priv->print_context = _gtk_print_context_new (op); - gtk_print_job_set_track_print_status (op_unix->job, priv->track_print_status); - - rdata->op->priv->surface = gtk_print_job_get_surface (op_unix->job, rdata->error); - if (op->priv->surface == NULL) + if (!is_preview) { - rdata->do_print = FALSE; - op_unix_free (op_unix); - rdata->result = GTK_PRINT_OPERATION_RESULT_ERROR; - goto out; - } - - _gtk_print_operation_set_status (op, gtk_print_job_get_status (op_unix->job), NULL); - op_unix->job_status_changed_tag = - g_signal_connect (op_unix->job, "status-changed", - G_CALLBACK (job_status_changed_cb), op); - - op_unix->parent = rdata->parent; - - priv->dpi_x = 72; - priv->dpi_y = 72; - - priv->platform_data = op_unix; - priv->free_platform_data = (GDestroyNotify) op_unix_free; - - priv->print_pages = op_unix->job->print_pages; - priv->page_ranges = op_unix->job->page_ranges; - priv->num_page_ranges = op_unix->job->num_page_ranges; - - priv->manual_num_copies = op_unix->job->num_copies; - priv->manual_collation = op_unix->job->collate; - priv->manual_reverse = op_unix->job->reverse; - priv->manual_page_set = op_unix->job->page_set; - priv->manual_scale = op_unix->job->scale; - priv->manual_orientation = op_unix->job->rotate_to_orientation; + GtkPrintOperationUnix *op_unix; + cairo_t *cr; + + op_unix = g_new0 (GtkPrintOperationUnix, 1); + priv->platform_data = op_unix; + priv->free_platform_data = (GDestroyNotify) op_unix_free; + op_unix->parent = rdata->parent; + + priv->start_page = unix_start_page; + priv->end_page = unix_end_page; + priv->end_run = unix_end_run; + + op_unix->job = gtk_print_job_new (priv->job_name, + printer, + settings, + page_setup); + gtk_print_job_set_track_print_status (op_unix->job, priv->track_print_status); + /* TODO: handle error */ + op_unix->surface = gtk_print_job_get_surface (op_unix->job, rdata->error); + cr = cairo_create (op_unix->surface); + gtk_print_context_set_cairo_context (op->priv->print_context, + cr, 72, 72); + cairo_destroy (cr); + + _gtk_print_operation_set_status (op, gtk_print_job_get_status (op_unix->job), NULL); + + op_unix->job_status_changed_tag = + g_signal_connect (op_unix->job, "status-changed", + G_CALLBACK (job_status_changed_cb), op); + + priv->print_pages = op_unix->job->print_pages; + priv->page_ranges = op_unix->job->page_ranges; + priv->num_page_ranges = op_unix->job->num_page_ranges; + + priv->manual_num_copies = op_unix->job->num_copies; + priv->manual_collation = op_unix->job->collate; + priv->manual_reverse = op_unix->job->reverse; + priv->manual_page_set = op_unix->job->page_set; + priv->manual_scale = op_unix->job->scale; + priv->manual_orientation = op_unix->job->rotate_to_orientation; + } } - - out: + if (rdata->print_cb) { if (rdata->do_print) - rdata->print_cb (op, rdata->parent); + rdata->print_cb (op, rdata->parent, is_preview); else _gtk_print_operation_set_status (op, GTK_PRINT_STATUS_FINISHED_ABORTED, NULL); } @@ -319,7 +441,7 @@ finish_print (PrintResponseData *rdata, rdata->destroy (rdata); } -static void +static void handle_print_response (GtkWidget *dialog, gint response, gpointer data) @@ -330,6 +452,8 @@ handle_print_response (GtkWidget *dialog GtkPageSetup *page_setup = NULL; GtkPrinter *printer = NULL; + g_print ("handle_print_response\n"); + if (response == GTK_RESPONSE_OK) { rdata->result = GTK_PRINT_OPERATION_RESULT_APPLY; @@ -345,14 +469,24 @@ handle_print_response (GtkWidget *dialog g_signal_emit_by_name (rdata->op, "custom-widget-apply", rdata->op->priv->custom_widget); } + else if (response == GTK_RESPONSE_APPLY) + { + /* print preview */ + rdata->result = GTK_PRINT_OPERATION_RESULT_PREVIEW; + rdata->do_print = TRUE; + settings = gtk_print_unix_dialog_get_settings (GTK_PRINT_UNIX_DIALOG (pd)); + page_setup = gtk_print_unix_dialog_get_page_setup (GTK_PRINT_UNIX_DIALOG (pd)); + } + out: finish_print (rdata, printer, page_setup, settings); if (settings) g_object_unref (settings); - + gtk_widget_destroy (GTK_WIDGET (pd)); + } @@ -436,6 +570,19 @@ _gtk_print_operation_platform_backend_ru } } +cairo_surface_t * +_gtk_print_operation_platform_backend_create_preview_surface (GtkPrintOperation *op, + gdouble width, + gdouble height, + gdouble *dpi_x, + gdouble *dpi_y, + const gchar *target) +{ + g_print ("pdf surface size: %f x %f\n", width, height); + *dpi_x = *dpi_y = 72; + return cairo_pdf_surface_create (target, width, height); +} + GtkPrintOperationResult _gtk_print_operation_platform_backend_run_dialog (GtkPrintOperation *op, GtkWindow *parent, @@ -459,6 +606,7 @@ _gtk_print_operation_platform_backend_ru if (op->priv->show_dialog) { pd = get_print_dialog (op, parent); + response = gtk_dialog_run (GTK_DIALOG (pd)); handle_print_response (pd, response, &rdata); } Index: gtk/gtkprintoperation-win32.c =================================================================== RCS file: /cvs/gnome/gtk+/gtk/gtkprintoperation-win32.c,v retrieving revision 1.9 diff -u -p -r1.9 gtkprintoperation-win32.c --- gtk/gtkprintoperation-win32.c 23 May 2006 16:30:45 -0000 1.9 +++ gtk/gtkprintoperation-win32.c 1 Jun 2006 20:34:39 -0000 @@ -492,6 +492,7 @@ win32_end_run (GtkPrintOperation *op, GlobalFree(op_win32->devmode); GlobalFree(op_win32->devnames); + cairo_surface_finish (op->priv->surface); cairo_surface_destroy (op->priv->surface); op->priv->surface = NULL; Index: gtk/gtkprintoperation.c =================================================================== RCS file: /cvs/gnome/gtk+/gtk/gtkprintoperation.c,v retrieving revision 1.24 diff -u -p -r1.24 gtkprintoperation.c --- gtk/gtkprintoperation.c 1 Jun 2006 12:38:07 -0000 1.24 +++ gtk/gtkprintoperation.c 1 Jun 2006 20:34:39 -0000 @@ -19,6 +19,10 @@ */ #include "config.h" + +#include +#include + #include #include "gtkprintoperation-private.h" #include "gtkmarshalers.h" @@ -41,6 +45,7 @@ enum { STATUS_CHANGED, CREATE_CUSTOM_WIDGET, CUSTOM_WIDGET_APPLY, + PREVIEW, LAST_SIGNAL }; @@ -65,7 +70,15 @@ enum { static guint signals[LAST_SIGNAL] = { 0 }; static int job_nr = 0; -G_DEFINE_TYPE (GtkPrintOperation, gtk_print_operation, G_TYPE_OBJECT) +static void preview_iface_init (GtkPrintOperationPreviewIface *iface); +static GtkPageSetup *create_page_setup (GtkPrintOperation *op); +static void common_render_page (GtkPrintOperation *op, + gint page_nr); + + +G_DEFINE_TYPE_WITH_CODE (GtkPrintOperation, gtk_print_operation, G_TYPE_OBJECT, + G_IMPLEMENT_INTERFACE (GTK_TYPE_PRINT_OPERATION_PREVIEW, + preview_iface_init)) /** * gtk_print_error_quark: @@ -146,6 +159,60 @@ gtk_print_operation_init (GtkPrintOperat } static void +preview_iface_render_page (GtkPrintOperationPreview *preview, + gint page_nr) +{ + GtkPrintOperation *op; + + op = GTK_PRINT_OPERATION (preview); + common_render_page (op, page_nr); +} + +static void +preview_iface_end_preview (GtkPrintOperationPreview *preview) +{ + GtkPrintOperation *op; + + op = GTK_PRINT_OPERATION (preview); + + g_signal_emit (op, signals[END_PRINT], 0, op->priv->print_context); + + if (op->priv->rloop) + g_main_loop_quit (op->priv->rloop); + + op->priv->end_run (op, op->priv->is_sync, TRUE); +} + +static void +preview_iface_init (GtkPrintOperationPreviewIface *iface) +{ + iface->render_page = preview_iface_render_page; + iface->end_preview = preview_iface_end_preview; +} + +static void +preview_start_page (GtkPrintOperation *op, + GtkPrintContext *print_context, + GtkPageSetup *page_setup) +{ + g_signal_emit_by_name (op, "got-page-size",print_context, page_setup); +} + +static void +preview_end_page (GtkPrintOperation *op, + GtkPrintContext *print_context) +{ +} + +static void +preview_end_run (GtkPrintOperation *op, + gboolean wait, + gboolean cancelled) +{ +} + + +static void gtk_print_operation_set_property (GObject *object, guint prop_id, const GValue *value, @@ -256,6 +323,158 @@ gtk_print_operation_get_property (GObjec } } +typedef struct +{ + GtkPrintOperationPreview *preview; + GtkPrintContext *print_context; + GtkWindow *parent; + cairo_surface_t *surface; + gchar *filename; + guint page_nr; + gboolean wait; +} PreviewOp; + +static void +preview_print_idle_done (gpointer data) +{ + GtkPrintOperation *op; + PreviewOp *pop = (PreviewOp *) data; + + op = GTK_PRINT_OPERATION (pop->preview); + + _gtk_print_operation_platform_backend_launch_preview (op, + pop->parent, + pop->filename); + + g_free (pop->filename); + cairo_surface_finish (pop->surface); + cairo_surface_destroy (pop->surface); + + gtk_print_operation_preview_end_preview (pop->preview); + g_free (pop); +} + +static gboolean +preview_print_idle (gpointer data) +{ + PreviewOp *pop; + GtkPrintOperation *op; + gboolean retval = TRUE; + cairo_t *cr; + + GDK_THREADS_ENTER (); + + pop = (PreviewOp *) data; + op = GTK_PRINT_OPERATION (pop->preview); + + gtk_print_operation_preview_render_page (pop->preview, pop->page_nr); + + cr = gtk_print_context_get_cairo_context (pop->print_context); + cairo_show_page (cr); + + /* TODO: print out sheets not pages and follow ranges */ + pop->page_nr++; + if (op->priv->nr_of_pages <= pop->page_nr) + retval = FALSE; + + GDK_THREADS_LEAVE (); + + return retval; +} + +static void +preview_got_page_size (GtkPrintOperationPreview *preview, + GtkPrintContext *context, + GtkPageSetup *page_setup, + PreviewOp *pop) +{ + GtkPrintOperation *op = GTK_PRINT_OPERATION (preview); + GtkPaperSize *paper_size; + double w, h; + + paper_size = gtk_page_setup_get_paper_size (page_setup); + + w = gtk_paper_size_get_width (paper_size, GTK_UNIT_POINTS); + h = gtk_paper_size_get_height (paper_size, GTK_UNIT_POINTS); + + /* TODO: don't hardcode pdf */ + cairo_pdf_surface_set_size (pop->surface, w, h); +} + +static void +preview_ready (GtkPrintOperationPreview *preview, + GtkPrintContext *context, + PreviewOp *pop) +{ + + pop->page_nr = 0; + pop->print_context = context; + + g_idle_add_full (G_PRIORITY_DEFAULT_IDLE, + preview_print_idle, + pop, + preview_print_idle_done); + +} + +/** + * gtk_print_operation_preview_handler: + * + * Default handler for preview operations + **/ +static gboolean +gtk_print_operation_preview_handler (GtkPrintOperation *op, + GtkPrintOperationPreview *preview, + GtkPrintContext *context, + GtkWindow *parent) +{ + gdouble width, height, dpi_x, dpi_y; + gchar *tmp_dir; + gchar *dir_template; + gchar *preview_filename; + PreviewOp *pop; + GtkPrintSettings *settings; + cairo_t *cr; + + dir_template = g_build_filename (g_get_tmp_dir (), "print-preview-XXXXXX", NULL); + + /* use temp dirs because apps like evince need to have extentions + to determine the mine type */ + tmp_dir = mkdtemp(dir_template); + + preview_filename = g_build_filename (tmp_dir, + "Print Preview.pdf", + NULL); + + g_free (dir_template); + + pop = g_new0 (PreviewOp, 1); + pop->filename = preview_filename; + pop->preview = preview; + pop->parent = parent; + + settings = op->priv->print_settings; + + width = gtk_print_settings_get_paper_width (settings, GTK_UNIT_POINTS); + height = gtk_print_settings_get_paper_height (settings, GTK_UNIT_POINTS); + + pop->surface = + _gtk_print_operation_platform_backend_create_preview_surface (op, + width, height, + &dpi_x, &dpi_y, + pop->filename); + + cr = cairo_create (pop->surface); + gtk_print_context_set_cairo_context (op->priv->print_context, cr, + dpi_x, dpi_y); + cairo_destroy (cr); + + g_signal_connect (preview, "ready", (GCallback) preview_ready, pop); + g_signal_connect (preview, "got-page-size", (GCallback) preview_got_page_size, pop); + + return TRUE; +} + static GtkWidget * gtk_print_operation_create_custom_widget (GtkPrintOperation *operation) { @@ -287,7 +506,8 @@ gtk_print_operation_class_init (GtkPrint gobject_class->set_property = gtk_print_operation_set_property; gobject_class->get_property = gtk_print_operation_get_property; gobject_class->finalize = gtk_print_operation_finalize; - + + class->preview = gtk_print_operation_preview_handler; class->create_custom_widget = gtk_print_operation_create_custom_widget; g_type_class_add_private (gobject_class, sizeof (GtkPrintOperationPrivate)); @@ -530,6 +750,33 @@ gtk_print_operation_class_init (GtkPrint g_cclosure_marshal_VOID__OBJECT, G_TYPE_NONE, 1, GTK_TYPE_WIDGET); + /** + * GtkPrintOperation::preview: + * @operation: the #GtkPrintOperation on which the signal was emitted + * @preview: the #GtkPrintPreviewOperation for the current operation + * @context: the #GtkPrintContext that will be used + * @parent: the #GtkWindow to use as window parent, or NULL + * + * Gets emitted when a preview is requested from the native dialog. + * If you handle this you must set the cairo_context on the printing context. + * + * Returns: #TRUE if the listener wants to take over control of the preview + * + * Since: 2.10 + */ + signals[PREVIEW] = + g_signal_new (I_("preview"), + G_TYPE_FROM_CLASS (gobject_class), + G_SIGNAL_RUN_LAST, + G_STRUCT_OFFSET (GtkPrintOperationClass, preview), + _gtk_boolean_handled_accumulator, NULL, + _gtk_marshal_BOOLEAN__OBJECT_OBJECT_OBJECT, + G_TYPE_BOOLEAN, 3, + GTK_TYPE_PRINT_OPERATION_PREVIEW, + GTK_TYPE_PRINT_CONTEXT, + GTK_TYPE_WINDOW); + + /** * GtkPrintOperation:default-page-setup: * @@ -1436,6 +1683,7 @@ pdf_start_page (GtkPrintOperation *op, GtkPageSetup *page_setup) { GtkPaperSize *paper_size; + cairo_surface_t *surface = op->priv->platform_data; double w, h; paper_size = gtk_page_setup_get_paper_size (page_setup); @@ -1443,7 +1691,7 @@ pdf_start_page (GtkPrintOperation *op, w = gtk_paper_size_get_width (paper_size, GTK_UNIT_POINTS); h = gtk_paper_size_get_height (paper_size, GTK_UNIT_POINTS); - cairo_pdf_surface_set_size (op->priv->surface, w, h); + cairo_pdf_surface_set_size (surface, w, h); } static void @@ -1462,9 +1710,10 @@ pdf_end_run (GtkPrintOperation *op, gboolean cancelled) { GtkPrintOperationPrivate *priv = op->priv; + cairo_surface_t *surface = priv->platform_data; - cairo_surface_destroy (priv->surface); - priv->surface = NULL; + cairo_surface_finish (surface); + cairo_surface_destroy (surface); } static GtkPrintOperationResult @@ -1475,6 +1724,8 @@ run_pdf (GtkPrintOperation *op, { GtkPrintOperationPrivate *priv = op->priv; GtkPageSetup *page_setup; + cairo_surface_t *surface; + cairo_t *cr; double width, height; /* This will be overwritten later by the non-default size, but we need to pass some size: */ @@ -1484,13 +1735,19 @@ run_pdf (GtkPrintOperation *op, height = gtk_page_setup_get_paper_height (page_setup, GTK_UNIT_POINTS); g_object_unref (page_setup); - priv->surface = cairo_pdf_surface_create (priv->pdf_target, + surface = cairo_pdf_surface_create (priv->pdf_target, width, height); - cairo_pdf_surface_set_dpi (priv->surface, 300, 300); - - priv->dpi_x = 72; - priv->dpi_y = 72; + cairo_pdf_surface_set_dpi (surface, 300, 300); + + priv->platform_data = surface; + priv->free_platform_data = (GDestroyNotify) cairo_surface_destroy; + cr = cairo_create (surface); + gtk_print_context_set_cairo_context (op->priv->print_context, + cr, 72, 72); + cairo_destroy (cr); + + priv->print_pages = GTK_PRINT_PAGES_ALL; priv->page_ranges = NULL; priv->num_page_ranges = 0; @@ -1524,10 +1781,11 @@ typedef struct gint page, start, end, inc; - GtkPageSetup *initial_page_setup; - GtkPrintContext *print_context; + gboolean initialized; GtkWidget *progress; + + gboolean is_preview; } PrintPagesData; static void @@ -1599,12 +1857,9 @@ print_pages_idle_done (gpointer user_dat if (data->progress) gtk_widget_destroy (data->progress); - g_object_unref (data->print_context); - g_object_unref (data->initial_page_setup); - g_object_unref (data->op); - if (priv->rloop) + if (priv->rloop && !data->is_preview) g_main_loop_quit (priv->rloop); g_free (data); @@ -1640,15 +1895,62 @@ update_progress (PrintPagesData *data) } } +static void +common_render_page (GtkPrintOperation *op, + gint page_nr) +{ + GtkPrintOperationPrivate *priv = op->priv; + GtkPageSetup *page_setup; + GtkPrintContext *print_context; + cairo_t *cr; + + print_context = priv->print_context; + + page_setup = create_page_setup (op); + + g_signal_emit (op, signals[REQUEST_PAGE_SETUP], 0, + print_context, page_nr, page_setup); + + _gtk_print_context_set_page_setup (print_context, page_setup); + + /* TODO: override for preview */ + priv->start_page (op, print_context, page_setup); + + cr = gtk_print_context_get_cairo_context (print_context); + + cairo_save (cr); + if (priv->manual_scale != 1.0) + cairo_scale (cr, + priv->manual_scale, + priv->manual_scale); + + if (priv->manual_orientation) + _gtk_print_context_rotate_according_to_orientation (print_context); + + if (!priv->use_full_page) + _gtk_print_context_translate_into_margin (print_context); + + g_signal_emit (op, signals[DRAW_PAGE], 0, + print_context, page_nr); + + /* TODO: override for preview */ + priv->end_page (op, print_context); + + cairo_restore (cr); + + g_object_unref (page_setup); +} + static gboolean print_pages_idle (gpointer user_data) { PrintPagesData *data; GtkPrintOperationPrivate *priv; GtkPageSetup *page_setup; - cairo_t *cr; gboolean done = FALSE; + g_print ("print_pages_idle\n"); + GDK_THREADS_ENTER (); data = (PrintPagesData*)user_data; @@ -1656,15 +1958,15 @@ print_pages_idle (gpointer user_data) if (priv->status == GTK_PRINT_STATUS_PREPARING) { - if (!data->print_context) + if (!data->initialized) { - data->print_context = _gtk_print_context_new (data->op); - data->initial_page_setup = create_page_setup (data->op); - - _gtk_print_context_set_page_setup (data->print_context, - data->initial_page_setup); + data->initialized = TRUE; + page_setup = create_page_setup (data->op); + _gtk_print_context_set_page_setup (priv->print_context, + page_setup); + g_object_unref (page_setup); - g_signal_emit (data->op, signals[BEGIN_PRINT], 0, data->print_context); + g_signal_emit (data->op, signals[BEGIN_PRINT], 0, priv->print_context); if (priv->manual_collation) { @@ -1684,7 +1986,7 @@ print_pages_idle (gpointer user_data) { gboolean paginated = FALSE; - g_signal_emit (data->op, signals[PAGINATE], 0, data->print_context, &paginated); + g_signal_emit (data->op, signals[PAGINATE], 0, priv->print_context, &paginated); if (!paginated) goto out; } @@ -1751,36 +2053,18 @@ print_pages_idle (gpointer user_data) goto out; } } + + if (data->is_preview) + { + done = TRUE; - page_setup = gtk_page_setup_copy (data->initial_page_setup); - g_signal_emit (data->op, signals[REQUEST_PAGE_SETUP], 0, - data->print_context, data->page, page_setup); - - _gtk_print_context_set_page_setup (data->print_context, page_setup); - priv->start_page (data->op, data->print_context, page_setup); - - cr = gtk_print_context_get_cairo_context (data->print_context); - - cairo_save (cr); - if (priv->manual_scale != 1.0) - cairo_scale (cr, - priv->manual_scale, - priv->manual_scale); - - if (priv->manual_orientation) - _gtk_print_context_rotate_according_to_orientation (data->print_context); - - if (!priv->use_full_page) - _gtk_print_context_translate_into_margin (data->print_context); - - g_signal_emit (data->op, signals[DRAW_PAGE], 0, - data->print_context, data->page); - - priv->end_page (data->op, data->print_context); - - cairo_restore (cr); - - g_object_unref (page_setup); + g_object_ref (data->op); + + g_signal_emit_by_name (data->op, "ready", priv->print_context); + goto out; + } + + common_render_page (data->op, data->page); out: @@ -1791,11 +2075,9 @@ print_pages_idle (gpointer user_data) done = TRUE; } - if (done) + if (done && !data->is_preview) { - g_signal_emit (data->op, signals[END_PRINT], 0, data->print_context); - - cairo_surface_finish (priv->surface); + g_signal_emit (data->op, signals[END_PRINT], 0, priv->print_context); priv->end_run (data->op, priv->is_sync, priv->cancelled); } @@ -1833,15 +2115,19 @@ show_progress_timeout (PrintPagesData *d static void print_pages (GtkPrintOperation *op, - GtkWindow *parent) + GtkWindow *parent, + gboolean is_preview) { GtkPrintOperationPrivate *priv = op->priv; PrintPagesData *data; - + + g_print ("print_pages\n"); + _gtk_print_operation_set_status (op, GTK_PRINT_STATUS_PREPARING, NULL); data = g_new0 (PrintPagesData, 1); data->op = g_object_ref (op); + data->is_preview = is_preview; if (priv->show_progress) { @@ -1862,6 +2148,37 @@ print_pages (GtkPrintOperation *op, data->progress = progress; } + if (is_preview) + { + gboolean handled; + + g_signal_emit_by_name (op, "preview", + GTK_PRINT_OPERATION_PREVIEW (op), + op->priv->print_context, + parent, + &handled); + + if (!handled || + gtk_print_context_get_cairo_context (priv->print_context) == NULL) { + /* TODO: handle error */ + } + + priv->start_page = preview_start_page; + priv->end_page = preview_end_page; + priv->end_run = preview_end_run; + + /* TODO: Do we really need to set these? */ + priv->print_pages = GTK_PRINT_PAGES_ALL; + priv->page_ranges = NULL; + priv->num_page_ranges = 0; + priv->manual_num_copies = 1; + priv->manual_collation = FALSE; + priv->manual_reverse = FALSE; + priv->manual_page_set = GTK_PAGE_SET_ALL; + priv->manual_scale = 1.0; + priv->manual_orientation = TRUE; + } + priv->print_pages_idle_id = g_idle_add_full (G_PRIORITY_DEFAULT_IDLE, print_pages_idle, data, @@ -1877,9 +2194,10 @@ print_pages (GtkPrintOperation *op, GDK_THREADS_LEAVE (); g_main_loop_run (priv->rloop); GDK_THREADS_ENTER (); + + g_main_loop_unref (priv->rloop); + priv->rloop = NULL; } - g_main_loop_unref (priv->rloop); - priv->rloop = NULL; } /** @@ -1964,7 +2282,7 @@ gtk_print_operation_run (GtkPrintOperati &do_print, error); if (do_print) - print_pages (op, parent); + print_pages (op, parent, result == GTK_PRINT_OPERATION_RESULT_PREVIEW); else _gtk_print_operation_set_status (op, GTK_PRINT_STATUS_FINISHED_ABORTED, NULL); @@ -2006,7 +2324,7 @@ gtk_print_operation_run_async (GtkPrintO { run_pdf (op, parent, &do_print, NULL); if (do_print) - print_pages (op, parent); + print_pages (op, parent, FALSE); else _gtk_print_operation_set_status (op, GTK_PRINT_STATUS_FINISHED_ABORTED, NULL); } Index: gtk/gtkprintoperation.h =================================================================== RCS file: /cvs/gnome/gtk+/gtk/gtkprintoperation.h,v retrieving revision 1.10 diff -u -p -r1.10 gtkprintoperation.h --- gtk/gtkprintoperation.h 24 May 2006 16:15:14 -0000 1.10 +++ gtk/gtkprintoperation.h 1 Jun 2006 20:34:39 -0000 @@ -29,6 +29,7 @@ #include "gtkpagesetup.h" #include "gtkprintsettings.h" #include "gtkprintcontext.h" +#include "gtkprintoperationpreview.h" G_BEGIN_DECLS @@ -84,7 +85,13 @@ struct _GtkPrintOperationClass GtkWidget *(*create_custom_widget) (GtkPrintOperation *operation); void (*custom_widget_apply) (GtkPrintOperation *operation, GtkWidget *widget); + + gboolean (*preview) (GtkPrintOperation *operation, + GtkPrintOperationPreview *preview, + GtkPrintContext *context, + GtkWindow *parent); + /* Padding for future expansion */ void (*_gtk_reserved1) (void); void (*_gtk_reserved2) (void); @@ -98,7 +105,8 @@ struct _GtkPrintOperationClass typedef enum { GTK_PRINT_OPERATION_RESULT_ERROR, GTK_PRINT_OPERATION_RESULT_APPLY, - GTK_PRINT_OPERATION_RESULT_CANCEL + GTK_PRINT_OPERATION_RESULT_CANCEL, + GTK_PRINT_OPERATION_RESULT_PREVIEW } GtkPrintOperationResult; #define GTK_PRINT_ERROR gtk_print_error_quark () Index: gtk/gtkprintoperationpreview.c =================================================================== RCS file: gtk/gtkprintoperationpreview.c diff -N gtk/gtkprintoperationpreview.c --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ gtk/gtkprintoperationpreview.c 1 Jun 2006 20:34:39 -0000 @@ -0,0 +1,107 @@ +/* GTK - The GIMP Toolkit + * gtkprintoperationpreview.c: Abstract print preview interface + * Copyright (C) 2006, Red Hat, Inc. + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2 of the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library; if not, write to the + * Free Software Foundation, Inc., 59 Temple Place - Suite 330, + * Boston, MA 02111-1307, USA. + */ + +#include "config.h" + +#include "gtkprintoperationpreview.h" +#include "gtkmarshalers.h" +#include "gtkintl.h" + +static void gtk_print_operation_preview_base_init (gpointer g_iface); + +GType +gtk_print_operation_preview_get_type (void) +{ + static GType print_operation_preview_type = 0; + + if (!print_operation_preview_type) + { + static const GTypeInfo print_operation_preview_info = + { + sizeof (GtkPrintOperationPreviewIface), /* class_size */ + gtk_print_operation_preview_base_init, /* base_init */ + NULL, /* base_finalize */ + NULL, + NULL, /* class_finalize */ + NULL, /* class_data */ + 0, + 0, /* n_preallocs */ + NULL + }; + + print_operation_preview_type = + g_type_register_static (G_TYPE_INTERFACE, I_("GtkPrintOperationPreview"), + &print_operation_preview_info, 0); + + g_type_interface_add_prerequisite (print_operation_preview_type, G_TYPE_OBJECT); + } + + return print_operation_preview_type; +} + +static void +gtk_print_operation_preview_base_init (gpointer g_iface) +{ + static gboolean initialized = FALSE; + + if (!initialized) + { + g_signal_new (I_("ready"), + GTK_TYPE_PRINT_OPERATION_PREVIEW, + G_SIGNAL_RUN_LAST, + G_STRUCT_OFFSET (GtkPrintOperationPreviewIface, ready), + NULL, NULL, + g_cclosure_marshal_VOID__OBJECT, + G_TYPE_NONE, 1, + G_TYPE_OBJECT); + + g_signal_new (I_("got-page-size"), + GTK_TYPE_PRINT_OPERATION_PREVIEW, + G_SIGNAL_RUN_LAST, + G_STRUCT_OFFSET (GtkPrintOperationPreviewIface, ready), + NULL, NULL, + _gtk_marshal_VOID__OBJECT_OBJECT, + G_TYPE_NONE, 2, + GTK_TYPE_PRINT_CONTEXT, + GTK_TYPE_PAGE_SETUP); + + initialized = TRUE; + } +} + + +void +gtk_print_operation_preview_render_page (GtkPrintOperationPreview *preview, + gint page_nr) +{ + g_return_if_fail (GTK_IS_PRINT_OPERATION_PREVIEW (preview)); + + GTK_PRINT_OPERATION_PREVIEW_GET_IFACE (preview)->render_page (preview, + page_nr); +} + +void +gtk_print_operation_preview_end_preview (GtkPrintOperationPreview *preview) +{ + g_return_if_fail (GTK_IS_PRINT_OPERATION_PREVIEW (preview)); + + GTK_PRINT_OPERATION_PREVIEW_GET_IFACE (preview)->end_preview (preview); +} + Index: gtk/gtkprintoperationpreview.h =================================================================== RCS file: gtk/gtkprintoperationpreview.h diff -N gtk/gtkprintoperationpreview.h --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ gtk/gtkprintoperationpreview.h 1 Jun 2006 20:34:39 -0000 @@ -0,0 +1,75 @@ +/* GTK - The GIMP Toolkit + * gtkprintoperationpreview.h: Abstract print preview interface + * Copyright (C) 2006, Red Hat, Inc. + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2 of the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library; if not, write to the + * Free Software Foundation, Inc., 59 Temple Place - Suite 330, + * Boston, MA 02111-1307, USA. + */ + +#ifndef __GTK_PRINT_OPERATION_PREVIEW_H__ +#define __GTK_PRINT_OPERATION_PREVIEW_H__ + +#include +#include + +#include "gtkprintcontext.h" + +G_BEGIN_DECLS + +#define GTK_TYPE_PRINT_OPERATION_PREVIEW (gtk_print_operation_preview_get_type ()) +#define GTK_PRINT_OPERATION_PREVIEW(obj) (G_TYPE_CHECK_INSTANCE_CAST ((obj), GTK_TYPE_PRINT_OPERATION_PREVIEW, GtkPrintOperationPreview)) +#define GTK_IS_PRINT_OPERATION_PREVIEW(obj) (G_TYPE_CHECK_INSTANCE_TYPE ((obj), GTK_TYPE_PRINT_OPERATION_PREVIEW)) +#define GTK_PRINT_OPERATION_PREVIEW_GET_IFACE(obj) (G_TYPE_INSTANCE_GET_INTERFACE ((obj), GTK_TYPE_PRINT_OPERATION_PREVIEW, GtkPrintOperationPreviewIface)) + +typedef struct _GtkPrintOperationPreview GtkPrintOperationPreview; /*dummy typedef */ +typedef struct _GtkPrintOperationPreviewIface GtkPrintOperationPreviewIface; + + +struct _GtkPrintOperationPreviewIface +{ + GTypeInterface g_iface; + + /* signals */ + void (*ready) (GtkPrintOperationPreview *preview, + GtkPrintContext *context); + void (*got_page_size) (GtkPrintOperationPreview *preview, + GtkPrintContext *context, + GtkPageSetup *page_setup); + + /* methods */ + void (*render_page) (GtkPrintOperationPreview *preview, + gint page_nr); + void (*end_preview) (GtkPrintOperationPreview *preview); + + /* Padding for future expansion */ + void (*_gtk_reserved1) (void); + void (*_gtk_reserved2) (void); + void (*_gtk_reserved3) (void); + void (*_gtk_reserved4) (void); + void (*_gtk_reserved5) (void); + void (*_gtk_reserved6) (void); + void (*_gtk_reserved7) (void); +}; + +GType gtk_print_operation_preview_get_type (void) G_GNUC_CONST; + +void gtk_print_operation_preview_render_page (GtkPrintOperationPreview *preview, + gint page_nr); +void gtk_print_operation_preview_render_sheet (GtkPrintOperationPreview *preview, + gint page_nr); +void gtk_print_operation_preview_end_preview (GtkPrintOperationPreview *preview); + + +#endif /* __GTK_PRINT_OPERATION_PREVIEW_H__ */ Index: gtk/gtkprintunixdialog.c =================================================================== RCS file: /cvs/gnome/gtk+/gtk/gtkprintunixdialog.c,v retrieving revision 1.22 diff -u -p -r1.22 gtkprintunixdialog.c --- gtk/gtkprintunixdialog.c 1 Jun 2006 04:58:18 -0000 1.22 +++ gtk/gtkprintunixdialog.c 1 Jun 2006 20:34:39 -0000 @@ -275,7 +275,8 @@ gtk_print_unix_dialog_init (GtkPrintUnix (GCallback) gtk_print_unix_dialog_destroy, NULL); - gtk_dialog_add_buttons (GTK_DIALOG (dialog), + gtk_dialog_add_buttons (GTK_DIALOG (dialog), + GTK_STOCK_PRINT_PREVIEW, GTK_RESPONSE_APPLY, GTK_STOCK_CANCEL, GTK_RESPONSE_CANCEL, GTK_STOCK_PRINT, GTK_RESPONSE_OK, NULL); Index: tests/print-editor.c =================================================================== RCS file: /cvs/gnome/gtk+/tests/print-editor.c,v retrieving revision 1.7 diff -u -p -r1.7 print-editor.c --- tests/print-editor.c 31 May 2006 14:06:02 -0000 1.7 +++ tests/print-editor.c 1 Jun 2006 20:34:39 -0000 @@ -262,6 +262,7 @@ begin_print (GtkPrintOperation *operatio int num_lines; int line; + g_print ("begin-print\n"); width = gtk_print_context_get_width (context); height = gtk_print_context_get_height (context); @@ -304,6 +305,7 @@ begin_print (GtkPrintOperation *operatio print_data->page_breaks = page_breaks; + g_print ("found %d pages\n", g_list_length (page_breaks)); } static void @@ -317,6 +319,9 @@ draw_page (GtkPrintOperation *operation, int start, end, i; PangoLayoutIter *iter; double start_pos; + + g_print ("draw-page %d\n", page_nr); + if (page_nr == 0) start = 0; else @@ -430,17 +435,205 @@ custom_widget_apply (GtkPrintOperation * data->font = g_strdup (selected_font); } +typedef struct +{ + GtkPrintOperation *op; + GtkPrintOperationPreview *preview; + GtkWidget *spin; + GtkWidget *area; + gint page; + PrintData *data; + gdouble dpi_x, dpi_y; +} PreviewOp; + +static gboolean +preview_expose (GtkWidget *widget, + GdkEventExpose *event, + gpointer data) +{ + PreviewOp *pop = data; + + gdk_window_clear (pop->area->window); + gtk_print_operation_preview_render_page (pop->preview, + pop->page - 1); + + return TRUE; +} + +static void +preview_ready (GtkPrintOperationPreview *preview, + GtkPrintContext *context, + gpointer data) +{ + PreviewOp *pop = data; + gint n_pages; + + g_object_get (pop->op, "n-pages", &n_pages, NULL); + g_print ("ready to preview %d pages\n", n_pages); + + gtk_spin_button_set_range (GTK_SPIN_BUTTON (pop->spin), + 1.0, n_pages); + + g_signal_connect (pop->area, "expose_event", + G_CALLBACK (preview_expose), + pop); + + gtk_widget_queue_draw (pop->area); +} + +static void +preview_got_page_size (GtkPrintOperationPreview *preview, + GtkPrintContext *context, + GtkPageSetup *page_setup, + gpointer data) +{ + PreviewOp *pop = data; + GtkPaperSize *paper_size; + double w, h; + cairo_t *cr; + gdouble dpi_x, dpi_y; + + paper_size = gtk_page_setup_get_paper_size (page_setup); + + w = gtk_paper_size_get_width (paper_size, GTK_UNIT_INCH); + h = gtk_paper_size_get_height (paper_size, GTK_UNIT_INCH); + + cr = gdk_cairo_create (pop->area->window); + + dpi_x = pop->area->allocation.width/w; + dpi_y = pop->area->allocation.height/h; + + g_print ("new dpi: %f, %f\n", dpi_x, dpi_y); + if (fabs (dpi_x - pop->dpi_x) > 0.001 || + fabs (dpi_y - pop->dpi_y) > 0.001) + { + gtk_print_context_set_cairo_context (context, cr, dpi_x, dpi_y); + pop->dpi_x = dpi_x; + pop->dpi_y = dpi_y; + } + + pango_cairo_update_layout (cr, pop->data->layout); + cairo_destroy (cr); +} + +static void +update_page (GtkSpinButton *widget, + gpointer data) +{ + PreviewOp *pop = data; + + pop->page = gtk_spin_button_get_value_as_int (widget); + g_print ("go to page %d\n", pop->page); + gtk_widget_queue_draw (pop->area); +} + +static void +preview_destroy (GtkWindow *window, + PreviewOp *pop) +{ + gtk_print_operation_preview_end_preview (pop->preview); + g_object_unref (pop->op); + + g_free (pop); +} + +static gboolean +do_preview (GtkPrintOperation *op, + GtkPrintOperationPreview *preview, + GtkPrintContext *context, + GtkWindow *parent, + gpointer data) +{ + GtkPrintSettings *settings; + GtkWidget *window, *close, *page, *hbox, *vbox, *da; + gdouble width, height; + cairo_t *cr; + PreviewOp *pop; + PrintData *print_data = data; + + pop = g_new0 (PreviewOp, 1); + + pop->data = print_data; + settings = gtk_print_operation_get_print_settings (op); + +#if 0 + /* FIXME need to figure out the size */ + width = gtk_print_settings_get_paper_width (settings, GTK_UNIT_PIXEL); + height = gtk_print_settings_get_paper_height (settings, GTK_UNIT_PIXEL); + + g_print ("%f x %f\n", width, height); +#endif + width = 200; + height = 300; + window = gtk_window_new (GTK_WINDOW_TOPLEVEL); + gtk_window_set_transient_for (GTK_WINDOW (window), + GTK_WINDOW (main_window)); + vbox = gtk_vbox_new (FALSE, 0); + gtk_container_add (GTK_CONTAINER (window), vbox); + hbox = gtk_hbox_new (FALSE, 0); + gtk_box_pack_start (GTK_BOX (vbox), hbox, + FALSE, FALSE, 0); + page = gtk_spin_button_new_with_range (1, 100, 1); + gtk_box_pack_start (GTK_BOX (hbox), page, FALSE, FALSE, 0); + + close = gtk_button_new_from_stock (GTK_STOCK_CLOSE); + gtk_box_pack_start (GTK_BOX (hbox), close, FALSE, FALSE, 0); + + da = gtk_drawing_area_new (); + gtk_widget_set_size_request (GTK_WIDGET (da), width, height); + gtk_box_pack_start (GTK_BOX (vbox), da, TRUE, TRUE, 0); + + gtk_widget_set_double_buffered (da, FALSE); + + gtk_widget_realize (da); + + cr = gdk_cairo_create (da->window); + + /* TODO: What dpi to use here? This will be used for pagination.. */ + gtk_print_context_set_cairo_context (context, cr, 72, 72); + cairo_destroy (cr); + + pop->op = op; + pop->preview = preview; + pop->spin = page; + pop->area = da; + pop->page = 1; + + g_signal_connect (page, "value-changed", + G_CALLBACK (update_page), pop); + g_signal_connect_swapped (close, "clicked", + G_CALLBACK (gtk_widget_destroy), window); + + g_signal_connect (preview, "ready", + G_CALLBACK (preview_ready), pop); + g_signal_connect (preview, "got-page-size", + G_CALLBACK (preview_got_page_size), pop); + + g_signal_connect (window, "destroy", + G_CALLBACK (preview_destroy), pop); + + gtk_widget_show_all (window); + + return TRUE; +} + +/* FIXME had to move this to the heap, since previewing + * returns too early from the sync api + */ +PrintData *print_data; + static void do_print (GtkAction *action) { GtkWidget *error_dialog; GtkPrintOperation *print; - PrintData print_data; GtkPrintOperationResult res; GError *error; - print_data.text = get_text (); - print_data.font = g_strdup ("Sans 12"); + print_data = g_new0 (PrintData, 1); + + print_data->text = get_text (); + print_data->font = g_strdup ("Sans 12"); print = gtk_print_operation_new (); @@ -452,12 +645,15 @@ do_print (GtkAction *action) if (page_setup != NULL) gtk_print_operation_set_default_page_setup (print, page_setup); - g_signal_connect (print, "begin_print", G_CALLBACK (begin_print), &print_data); - g_signal_connect (print, "draw_page", G_CALLBACK (draw_page), &print_data); - g_signal_connect (print, "create_custom_widget", G_CALLBACK (create_custom_widget), &print_data); - g_signal_connect (print, "custom_widget_apply", G_CALLBACK (custom_widget_apply), &print_data); - + g_signal_connect (print, "begin_print", G_CALLBACK (begin_print), print_data); + g_signal_connect (print, "draw_page", G_CALLBACK (draw_page), print_data); + g_signal_connect (print, "create_custom_widget", G_CALLBACK (create_custom_widget), print_data); + g_signal_connect (print, "custom_widget_apply", G_CALLBACK (custom_widget_apply), print_data); + g_signal_connect (print, "preview", G_CALLBACK (do_preview), print_data); + error = NULL; + +#if 1 res = gtk_print_operation_run (print, GTK_WINDOW (main_window), &error); if (res == GTK_PRINT_OPERATION_RESULT_ERROR) @@ -467,7 +663,7 @@ do_print (GtkAction *action) GTK_MESSAGE_ERROR, GTK_BUTTONS_CLOSE, "Error printing file:\n%s", - error->message); + error ? error->message : "no details"); g_signal_connect (error_dialog, "response", G_CALLBACK (gtk_widget_destroy), NULL); gtk_widget_show (error_dialog); g_error_free (error); @@ -489,10 +685,15 @@ do_print (GtkAction *action) g_signal_connect (print, "status_changed", G_CALLBACK (status_changed_cb), NULL); } +#else + gtk_print_operation_run_async (print, GTK_WINDOW (main_window)); +#endif g_object_unref (print); +#if 0 g_free (print_data.text); g_free (print_data.font); +#endif } static void --=-xjDvOKJb0tdB52kmWdgp-- From tomasek@ebed.etf.cuni.cz Fri Jun 2 03:11:55 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 2F96F3B01C7 for ; Fri, 2 Jun 2006 03:11:55 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05061-05 for ; Fri, 2 Jun 2006 03:11:53 -0400 (EDT) Received: from ebed.etf.cuni.cz (ebed.etf.cuni.cz [195.113.5.3]) by menubar.gnome.org (Postfix) with ESMTP id 3EDBD3B011A for ; Fri, 2 Jun 2006 03:11:53 -0400 (EDT) Received: from ebed.etf.cuni.cz (localhost.localdomain [127.0.0.1]) by ebed.etf.cuni.cz (8.12.11.20060308/8.12.11) with ESMTP id k5270gLE004827 for ; Fri, 2 Jun 2006 09:00:42 +0200 Received: (from tomasek@localhost) by ebed.etf.cuni.cz (8.12.11.20060308/8.12.11/Submit) id k5270gdU004825 for gtk-devel-list@gnome.org; Fri, 2 Jun 2006 09:00:42 +0200 Date: Fri, 2 Jun 2006 09:00:42 +0200 From: Petr Tomasek To: gtk-devel-list@gnome.org Message-ID: <20060602070042.GA3470@ebed.etf.cuni.cz> References: <1149203639.27455.9.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1149203639.27455.9.camel@localhost.localdomain> User-Agent: Mutt/1.4.1i X-Homepage: http://www.etf.cuni.cz/~tomasek/ X-Echelon: bomb Arafat Intifada bus kach drugs mafia boss heroin spy Semtex Saddam Al-Qaida Usama bin Ladin Bush Sharon X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.534 tagged_above=-999 required=2 tests=[AWL=0.065, BAYES_00=-2.599] X-Spam-Score: -2.534 X-Spam-Level: Subject: Re: Print preview api X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 07:11:55 -0000 On Thu, Jun 01, 2006 at 07:13:59PM -0400, Matthias Clasen wrote: > Ok, after a lot of work (mostly by John and Alex), > we finally have a proposal for a print preview > api that will allow us to use an external viewer > by default, but also support internal preview. Hi! I think, this is very unfortunate. Many people will not want to use the external viewer (for reasons discused earlier), so everyone will write his own preview widget? Why not just have official internal preview widget like gnome-print has and support it by deafult? P.T. -- Petr Tomasek From shree_poroly@yahoo.com Fri Jun 2 06:49:17 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id DD9063B03E7 for ; Fri, 2 Jun 2006 06:49:10 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19278-08 for ; Fri, 2 Jun 2006 06:49:06 -0400 (EDT) Received: from web53308.mail.yahoo.com (web53308.mail.yahoo.com [206.190.49.98]) by menubar.gnome.org (Postfix) with SMTP id 574673B110A for ; Fri, 2 Jun 2006 06:48:56 -0400 (EDT) Received: (qmail 1625 invoked by uid 60001); 2 Jun 2006 10:48:55 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=opsX4ZJJjJ3RSp61u8057G5DaMkib9ROhHy+AzeYX+l7J8HSwJa+UppJPxFDKOjVDg5ivFj+xumB8simRH1oUSf2tMk9h8YEuyY6OEPoTApYincgsxe7YmLfJe3+jDCaLeD7TV1kXmnpIstEupgel4fQt9kXW1CGDMkwXy+xReA= ; Message-ID: <20060602104855.1623.qmail@web53308.mail.yahoo.com> Received: from [61.246.61.209] by web53308.mail.yahoo.com via HTTP; Fri, 02 Jun 2006 03:48:55 PDT Date: Fri, 2 Jun 2006 03:48:55 -0700 (PDT) From: shree nidhi To: gtk dev MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-596188450-1149245335=:1049" Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=1.399 tagged_above=-999 required=2 tests=[AWL=-3.076, BAYES_50=0.001, DNS_FROM_RFC_ABUSE=0.2, DNS_FROM_RFC_WHOIS=1.447, HTML_40_50=0.496, HTML_IMAGE_ONLY_12=1.867, HTML_IMAGE_RATIO_02=0.463, HTML_MESSAGE=0.001] X-Spam-Score: 1.399 X-Spam-Level: * Subject: Fwd: test X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 10:49:17 -0000 --0-596188450-1149245335=:1049 Content-Type: multipart/alternative; boundary="0-601274911-1149245335=:1049" --0-601274911-1149245335=:1049 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Note: forwarded message attached. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --0-601274911-1149245335=:1049 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit

Note: forwarded message attached.

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com --0-601274911-1149245335=:1049-- --0-596188450-1149245335=:1049 Content-Type: message/rfc822 X-Apparently-To: shree_poroly@yahoo.com via 206.190.49.100; Thu, 01 Jun 2006 21:38:26 -0700 X-Originating-IP: [202.71.129.68] Authentication-Results: mta129.mail.mud.yahoo.com from=galieosoft.com; domainkeys=neutral (no sig) Received: from 202.71.129.68 (EHLO smx1.net4india.com) (202.71.129.68) by mta129.mail.mud.yahoo.com with SMTP; Thu, 01 Jun 2006 21:38:26 -0700 Received: from [125.22.33.12] by smx1.net4india.com with smtp (Exim 4.51) id 1Fm1a8-00025h-AB; Fri, 02 Jun 2006 10:18:21 +0530 OM-Header: origin=omniqube Received: from unknown (192.168.0.89) by SMTP-Receiver; Fri, 2 Jun 2006 10:07:06 +0530 Subject: test From: Nidhi To: nidhi@galieosoft.com, shree_poroly@yahoo.com Content-Type: multipart/mixed; boundary="=-k0bJJnk7Qaq1V0+G97NB" Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-1) Date: Fri, 02 Jun 2006 10:12:00 +0530 Content-Length: 21206 --=-k0bJJnk7Qaq1V0+G97NB Content-Type: multipart/alternative; boundary="=-rVG5rqf50PHPN/AXL0Ln" --=-rVG5rqf50PHPN/AXL0Ln Content-Type: text/plain Content-Transfer-Encoding: 7bit I have developed an application for an handheld device, the initial window will look like this : But the device is having rectangular display if i place the window as it is my drawing area will look compressed, so i dont want to compress my drawing area. If i can tilt the window and display i hope my drawing area will look like enlarged. Is there any way to tilt an application window as shown please help me out. --=-rVG5rqf50PHPN/AXL0Ln Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
I have developed an application for an handheld device, the initial window will look like this :









But the device is having rectangular display if i place the window as it is my drawing area will look compressed, so i dont want to compress my drawing area. If i can tilt the window and display i hope my drawing area will look like enlarged.







Is there any way to tilt an application window as shown please help me out.


--=-rVG5rqf50PHPN/AXL0Ln-- --=-k0bJJnk7Qaq1V0+G97NB Content-Disposition: attachment; filename=test1.map Content-Type: application/octet-stream; name=test1.map Content-Transfer-Encoding: 7bit --=-k0bJJnk7Qaq1V0+G97NB Content-Disposition: attachment; filename=test2.map Content-Type: application/octet-stream; name=test2.map Content-Transfer-Encoding: 7bit --=-k0bJJnk7Qaq1V0+G97NB Content-Disposition: attachment; filename=wintilt.sxw Content-Type: application/vnd.sun.xml.writer; name=wintilt.sxw Content-Transfer-Encoding: base64 UEsDBBQAAAAAAJZQwTSAkGt+mxsAAJsbAAAtAAAAUGljdHVyZXMvMTAwMDAyMDEwMDAwMDEzNzAw MDAwMTM0REUzMjdBMTMucG5niVBORw0KGgoAAAANSUhEUgAAATcAAAE0CAYAAABJtnScAAAABHNC SVQICAgIfAhkiAAAABV0RVh0U29mdHdhcmUARXllIG9mIEdub21lCx+PrwAAGzFJREFUeJzt3X1w XOVh7/Hfvmglr23ZMS/BAWNbmBcrYPOSmCQ0kUMgwYQyIS+9uDdphyZtYzFzk6bJVWZaT5JbXXqH zjT3TlM70Et7XQ+95OIggkOhxAnrtBjiYBAGS7Zky/KLkLEl68162Zdzzv1jdY53VytZu9rVrh5/ PzMaafe8PUe757fPeZ7nnPVJcoQ5o2phtQLBoIb7zqY97/f7S1QioPzYtq2gJLUeP65jp8+oZ2BA I9FYqcuFHLR3dWn3rl165I+/qurqas2bN08VFRWEHS5Kw8PDuu222yQpGW7HTp/RL99sLmmhkJ+9 e/cqeu6cBgcHFQ6HFQwGVVlZqWAwmHX+eDw+5fp8Pp/3t9/v9x47jiPbtuU4U1f0Z7p8IaSWYap5 UuebbBm3vJP9Lib2Y6LJyu++1/r6+7zHQUk609+ffPM5jvzTKAjKh+M4io+NanR0VJZlye/3q7Ky UhUVFZLST1dt21ZVVZUcx5HjOGlvKPfNMZ03IlBuotGogsGgomNR77mgJA2NjimWSMhxHAXGD4Zd zzbJTiRkJRJy3E9cx5HcN3/G3z6/Xz6/Xxse3Di7e3URsx1HtmUpOjysnp4eLViwQBUVFXIcR6FQ SBUVFV7ISclaWzwel2VZXrgFAgFvvmAwmFbbAqbrBz/4gWKxmOLxuBKJxJS1dJ/Pl6xZBYN69NFH C7L82NiYqqqqNDY25s0XlKR4IqGEZcm2HVl+W5KUiMX01P/+Bx1+t1vv9fVraHR0yp07fvq0Xvjn bYolEjn+WzAjjqPoyIh+9PQOVS2sVmU4rGBlpQIVFfrhw5tUVVWlYDCoh//u72UnEkrEYrIty/tw 8gcC+uHDmzR//nxvXtrrkKvh4WE9/vjj055/3759euSRR3Tu3LmCLH/69GktXLhQI8PD3jxBSUpY luIJS5ZtezU3Kx7XoZNdemnfmxNOVbOdvr75H/+u6MiI4glr2gXMxcZP1mk0GtWze14ryvoLvb3N //lBLZo/X99+/IkClyzd6rU364H77kt77uCJk3o98rK6urq0ePFiVVRUKDYyoi3f26yO7lN6r69f w2Njajl+Qm/sjqirq0uXXHKJFi5cqKqqKgUCgaKWGeYZHa/8dHZ2Tmv+nTt3qr+/31tupsufPXtW Pp9PwyMj3jxBSYolEorG40pYloLjb2w7kdDx02cUz1ITc09pUtmWpUR0TNGMButt3/mWJKntZJf+ +//9iff81++7Vx9dfYOOnz6jzdu2X3BnPrl2jfrOndNPdv/7tHY+1Z9/8QGtWblS3/mHf9Tp/n5J 0lc+dafuuvVm/d3Pdur1tnZJ0t233qIvfvwOPfyjrTPaniQtmDdP1eHwhP9HMbzVcTTtcfv+tzQ6 OKCenh75fD5VVVUpEY2q7WSXdr62N+t8qaems9HIDLO4HVUX6rBKNTIyosR4vmQuf91116mtrS1t /sznUpcfGRnRggULstfcYu6p6fgb27Ys9Z87p2g8ntbj5fP50t787jTbtmUnEpOell575QdUWVGh odFRBQMBra1ZmVynnGmdym7860cvOM9k9nd0as3Klbph2VU62dMjSfrgiqu9cu1paZUk3bRyhfYf 7dRINDqj7UnJsz5Js3Kanvl6OLat2MiIBgYGFA6HZdu2ErGYTvb0euVxxtvr3Pmqq6sVDofT2unc Dgba4HAhlpU8Y0vk8H6PxWKybXvC8rW1tZKSYdbS0iJJWZ9LXd5tSx5JaT7zam5j420xCbfmZlmK xuNT1jz8Pt/5MEwkZFuWxmITx8n1DA7q0upq3bhiuV5+a7/W1tQoFo8rXFkpx3E0Fovp0upq/ZcH 7tc1S5dqXiikd3vP6p9e+oX2tR+WJDV97y/VOzSkr/3t/0p7/I8vvqSv3vNphSsr9c+7fqUXfvv6 hO2/3tauL3/qk/rg8qv189/s1WWLFmnpkiWSpBuWXaWxWEyVFRWqXX61Hnv+BY3FYjlvryIQ0B/d 82l94qYbFa6s9LY9FovJJ+l3P3K77l33IV26aJF6Bgb0r3tf187f7JXjOPq9uo9r4/o6ffvxJ3Sk u1t/9vnP6RM33aiGJ/5JbSe79J0vfUFDIyP68fMvTPo6uNxOhkQ06oVbNBpVIhrV2aGhtNfHGQ+9 oaEhDQ4OKhQKeZ0RwWDQq8kRcLgQ9wM2l3CzbdsLp9Tl9+/frzVr1kg6H2qu/fv3e9tIXd6yLNm2 PbFDQUq2sdmWJcfdmG0rlkjImiLcUlvXbCvZ25pt/n2H2nT3bbfqtmtXadfr+7TuulV6rfWg7vnw h7xlApLeaGvXthdfUlUopL/88u/r4fvv0x/+j785v6KM9S8Kh7VxfZ1+vf9tfe6Oj2nj+k/o53te nbD9o+++q75z53TTyhWSZemm5VdraGRER0+9p5tWrtC8YFA3LLtKFYGAXm89eH4bOWxvY90ndM+H btPOV1/TL99o1l899AdaGA7Lisd1/8c+qoc+c7d+03pQf/OTHfpi3cf10GfulmPbevaVPXrnSIe0 vk6rr7pS7SdO6IPLx2uVS5fqYOcx3bhiubb+bGfW/21qE4H7t21ZSsRievKlXygUDisQDMq2LDW3 tav70MHMFejJX+xSKBxWRdU8BUMhBSoq9N8e+kOFw2FvzBydDJiKG065nJZK52tsmcvv27fPG4zr 2rdv34T1u8vbti3LsjQWzRgK4krEYvK7NTfbTvaiZqmJZWOPDy/INv/g8LDeOdqpW69dJb9t6/Yb btD/3PFTL9wSsZiOd3frxKlTWrpkiRYtWKC+oSEtveSS9PU5SnscTyT07S0/1uDwsNavXaPFCxZM Wt4329p15623aOXll+vmmpV6s/2wjp16T2tqVuq6DyzVrauu0ZGud3W6tzev7a1fm/yk+ZeXdmlg eFixeML7n957+4clSY/9bKdOnT2rH/ed1UdW36B7b1+nHS9HdKDjqBKWpdrlV+vVt9/RwnBYPQMD uu7KD2jZkiWqDof1Zlv7tF+Ly1bWaP2nP5323IH2w3r7317wPsAc25bP79fTTz2lA8eOqaunV4Mj IzrQflhdB95RT0+PlozXbiXRyYAp5VNzcxxnQrhNtXzmtNTl3RpcIiX80sLNisckhdwllbDs5LAB yTsYvBVneazxU6IJO2E7eu1Ai9ZcU6MHPv47CldVqnm8EV9OMhhXXXWl/uIPvqIlCxfqxOnTuqS6 OlnotPWlr39kbEz9g4PJsrs7mWX7kvTGoTbdeestuvXaVVq7apWeeP5f1XXmjL7ymbt148oV+vD1 1+tX+97Ie3uXLkqWt39oaPyFOt92edmiRZKkU729sm1b7/Umrwu9bPGi5Km8ZantxEl9cMUKralZ qdbOY+o/d06rl1+tNdfUqOPdbm+7U3Fr3ZK0f7wd0XW644jsREIbbl+nyspK+f1+Pffqa3qr46ie +eWvzs935LDGhgbV29vrnZYGAgE6GTAlL1zGA+iOO+7IOt8rr7zi/e04Ttop5oWWv/322ydd3v2d 2nySHm7jA3ndjcUSCSViUU3H+ZrbxPltK6FXmpv1J/ffp4133ak9b7+j0ZHh8QLaSsSiemjDPVp6 yRJ9+Xs/0KmzZ/XYd/+rrrnyyrT1OY4mfewee5OV97cHDkiS7vvYR1Q9P6zfvvOO+oaGFIvH9anb btX7Fi7Uq2/vz3t7o9Go5s+bp4WVIQ2PjqoqFPKmn+7r15WXXapLFoTV3dOrK8ZrRGf6+rzl97e3 q3bFcn32ox/RK2+/reHRUdXdvFbrb1mrNw4enPbrMBnHtmUlEgoGg1qwYEGyXS0UUkd3d9q63UHB fX193nWqktI6Gc7/P85fApN5xQOdEReX1Ib9qaROdxxHsfGzkdTl169f780TiUQkyXvujjvu8J5L XT5bjS8t3Bzblp3yd8KyZMXjaTW0bNzTnElrbo6jE6dO6fip93T1Fe/XfzQ3n59vvObmNorX3XKz zo2O6qrLL5ckfej667V3vHcksyaV/vh8TSmbM2fPqrO7WyuWLtWJ997TqfFe05ajnbr5ums1NDyi lo6j3j851+292dau31m7Rn/24O8pVBFS5Xi42ZalZyMRPfylL+rrD3xOT774b/r98VPGZ3f/2lu+ ua1ND959l6656kr9/Y6fKuZ2iS9bpv+z8/lJasTJsrqvj1ubzvwtSXYinrzixLK8Ed7y+dQzOOSd qvr8fq+9bnBwUPPnz5ff71c8HlcoFFIgEPA6GNxPTbch1w03v9/vXfUQCAQIuItEZm/prl27ss6X GkK2bXvhlLr8rl27dNddd2nXrl1p68t8LnX5bDJOS+Nem5scR/HxS6/s8QMis/FaShkK4p6mZRsX Nz5M5IdP/ouWXfF+7Wl+K2U+R3YiocefadJffPUh/dH9v6vd+97QE8/+TH/8wOf0n+7+lF7bv//8 PyRj/Rd6nOr1Ay1asXSpXm9p9eZrPnRIN193rX5z4J2sbVrT3d6Pn96hZZdfrjXXXqutT+/Q8ive r0sXL5adSGjHrl/KL58+f+cn9aNv/7neO3tWW3f8VE//YpfX2/x2W3uyp9O21XL4sKzxNs+A36+3 Dh70tpM5xtBxHCkl+Hxu0GT8dod+PP/qawrNmyd/ICDbttXeckC9x48ll3VfW9vWT3f/WqGqKgUr KxUMheQPVuhbX/qCd0r76P/b4V2el7ziwZZ8fvkDAX3rS1/QvHnzvF5Xws18maeV0xUd7wDIXP7F F1+csK5sz7nLZ7tRhE+Ss3nbdjW3tevsyRPeJ/3hPa9o1cfuUHdry4SFJtNzrFM33XPvtOdHAbjn xz5f+vW+Wea7+vob0p463nZIR3+793wnw3hwPvnUU3rj8BEdPXVK/eeGdbztkM50HNHX7vusFixY oGAwqB89+5z+tvGv0uc7dFBnjnboa/d9VosWLVI4HPZqfDDbY489pkceeUQ7d+6c9jLPPPOMvv/9 7xdk+Wg0qiuuuEKRSESNjY2SspyWpjYcH9r9cvJaxPELWeVM0qg8fjriHx9ygPLUmfFB1XfyhKx4 XB9fc5NCoZD8fr9ebn5L+9oP69mf/zxtvrGhIfX29sqyLIVCIcWjY1POJ52/zRHhZj7HcfTNb35T IyMjyXGVKe33mXw+n3drLndc2kyXr15UPWG4Ulq42Zbl1dxWfnhdfjuZ1maFcpZsckh2MsyfPz/Z ThYK6dDJrrTX0bFtxUZHNTAwoIqKiuSdG2KxKeerqqryApNwM9/GjfndDcg9rZzp8u9bvESZNxWf UHPD3DDV0Ixs7aKpl865v5N/+71PwVAoJH8goJ6BgbQauHepVizmvZkcy7rgfGNjY4QbZsWSJe/T 0NBQ2nMTWuHOnjwxawVC6dl2MoxGR0eT99FKJNR9sFX93e+mz2clNDw87PWExsbGppyvv79fiUTC 64AAimlRdbV3hxDXhHBr+/XuWSsQysNPjhxJe3zsjX1Z53sqc759E6/jzTYfUGzf+MY3JvTKp4Vb YHygZilHo7e2tl54JgAYV1tbm/UO0tm/RUSlCZna2lrvdiYAMBNl0xjiXlIBAIVQNuEGAIVEuAEw 0qRtbuUq8/Q19Q4Cc5WJ+wSU2pwJNzcA6uvrJ0zbsmXLnAwEE/cJKBc5hVvm/cxdqV/ikO3vmYpE Il4AZBum4vP58gqDfMpYqP0q5D5dqEyl7IWmBxylknObW0tLy4Sf1GnFNNn4u3zG5bkH3WSBPVsK tU+T7Uep9w8olYJ2KEx1INXW1no/uXBrOBc62Ddt2qRIJKLVq1fntP5sMsvoPs787f6d636VYp9S TVbm1P2bbNpUj/N5fYFimZXeUreW5P6U+gBIPVXKpTypy6Supxz2K9v2s50SXqjMqdOnuz/l9H8A XDl3KGS+cWlPmVsu9Hrl83ryHkA5yjnc8n0jl9unebmVpxDcWlPq72yKse8m/j8xt83aUJB8Q3G6 PaBbt27Vpk2bLnhN7GQH/Wz26hV6n3KRuZ+FCKVirBOYqZJcoZDrm3/Lli0l+5KRYh2oxdqnC9Xa CoHwwlwwKzW3zEbmXA+89evXa8uWLV5NJtXWrVslqaA1nNTy5tLonst+zfY+pZYxs8zTCcOp/if5 rhMoprRvv+o9fkx7tm+T4zizfssjd3jEhQ6IzEuV3GCYy/eBM3GfgNlSW1urvr4+dXZ2qqmpKfu3 X80FmbUcEwLAxH0CSm3OhZuJB76J+wSUGrc8AmAkwg2AkQg3AEaass2N7zUAMFdNGm4M1AQwl2UN t9bW1oIMwCz0rXoAmKdYowWKPhSEYQ4AJlPMK1noUABQEsVu0y9quJXqYneUL9pyMVvm3BUKMMtM bqgATIVwQ8lkuw8cAYdCoc0NgJEINwBGItwAGIlwA2Akwg2AkegtRdFMNqaNXlHMBsINRTPZt8+7 wTbTLw4CpkK4oagmC7jU6UAx0OaGokutqQGzhXDDrCDYMNtm5bSUi6WRivcDZkNRw81xHO4MAqAk soZb6h108w0nx3G0fv161dXV5VcyABeF5557rijrnbTm5t5BN9+2Ep/PR7ABmJaGhoa8lrNtW9/9 7nezTivKaSltKgByletXEtTW1sqyrEmn01sKYM6Zzi3KCTcARiLcAJStmTRxEW4AypIbbPkGHOEG oOxkBlo+AUe4ASgrU90qKxfcFQRAWSnUdcjU3AAYiXADYCTCDYCRaHMDUDamc+XBdBFuAMpCoa9J J9wAlAXHcXJexrbtSacRbgDKAncFAXDR464gAC5ahBsAIxFuAIxEuAEwEuEGwEiEGwAjEW4AjES4 ATAS4QbASIQbACMRbgCMRLgBMBLhBsBIhBsAIxFuAIxEuAEwEuEGwEiEGwAjFfU7FGrW1aQ97tjb wXSmM53pWacXmk+Ss3nbdjW3tav3+DHt2b5NjuPk/GUNqdyv6KqrqytQMQGYasOGDWpoaMgpcyKR iOrr62VZlgKBgPr6+tTZ2ammpiY1NjZK4rQUgKEINwBGItwAGIlwA2Akwg2AkQg3AEYi3AAYiXAD YCTCDYCRCDcARiLcABiJcANgJMINgJEINwBGItwAGIlwA2Akwg2AkQg3AEYi3AAYiXADYCTCDYCR CDcARiLcABiJcANgJMINgJEINwBGItwAGIlwA2Akwg2AkQg3AEYi3AAYiXADYCTCDYCRCDcARiLc ABgpWMyV16yrSXvcsbeD6UxnOtOzTi80nyRn87btam5rV+/xY9qzfZscx1Fra2veK62trZUk1dXV FaiYAEy1YcMGNTQ05JQ5kUhE9fX1sixLgUBAfX196uzsVFNTkxobGyVxWgrAUIQbACMRbgCMRLgB MBLhBsBIhBsAIxFuAIxEuAEwEuEGwEiEGwAjEW4AjES4ATAS4QbASIQbACMRbgCMRLgBMBLhBsBI hBsAIxFuAIxEuAEwEuEGwEiEGwAjEW4AjES4ATAS4QbASIQbACMRbgCMRLgBMBLhBsBIhBsAIxFu AIxEuAEwEuEGwEiEGwAjBUtdAFw8Irt3e3+vr6srYUlwMbhguNXW1ua98pp1NWmPO/Z2MP0inq6U cCvH8jG9xO+PAvNJcjZv267mtnb1Hj+mPdu3yXEctba25r1SNxDr+HRGCmpuyGbDhg1qaGjIKXMi kYjq6+tlWZYCgYD6+vrU2dmppqYmNTY2SsrhtDS1BtfS0pJD0YEkAg2zaVrhVltbmxZomY8BoNzQ WwrASIQbACMRbgCMRLgBMBLhBsBIhBsAI01rKEhLSwvj3ADMKdMexEugAZhLOC0FYCTCDYCRCDcA RiLcABiJcANgpBmH20xuZgkAxVKQmhsBB6DcFOy0lIADUE4K2uZGwAEoFwUNN65iAFAuChZuBBuA clKQcCPYAJSbGYcbwQagHDGIF4CRCDcARiLcABiJcANgJMINgJEINwBGItwAGIlwA2Akwg2AkQg3 AEYi3AAYadpfypyPmnU1aY879nYwnelMZ3rW6YXmk+Rs3rZdzW3t6j1+THu2b5PjOGptbc17pe5N K+vq6gpUTACm2rBhgxoaGnLKnEgkovr6elmWpUAgoL6+PnV2dqqpqUmNjY2SOC0FYCjCDYCRCDcA RiLcABiJcANgJMINgJEINwBGItwAGIlwA2Akwg2AkQg3AEYi3AAYiXADYCTCDYCRCDcARiLcABiJ cANgJMINgJEINwBGItwAGIlwA2Akwg2AkQg3AEYi3AAYiXADYCTCDYCRCDcARiLcABiJcANgJMIN gJEINwBGItwAGIlwA2Akwg2AkQg3AEYKFnPlNetq0h537O1gOtOZzvSs0wvNJ8nZvG27mtva1Xv8 mPZs3ybHcdTa2pr3SmtrayVJdXV1BSomAFNt2LBBDQ0NOWVOJBJRfX29LMtSIBBQX1+fOjs71dTU pMbGRkmclgIwFOEGwEiEGwAjEW4AjES4ATAS4QbASIQbACMRbgCMRLgBMBLhBsBIhBsAIxFuAIxE uAEwEuEGwEiEGwAjEW4AjES4ATAS4QbASEX9DgUAyEUkEinYugg3AGXB/e6VQiHcAJQFx3FyXsa2 7UmnEW4AykKu37hXW1sry7ImnU6HAoA5Zzptc4QbACMRbgCMRJsbgLIyVa9pS0vLtNdDzQ1AWZks wHIJNolwA1CGMoMs12CTCDcAZcoNtHyCTSLcAJSxfINNItwAGIpwA2AkhoIAKBuzdleQQm4IAKYy a3cFKfSGAGAytm1PeRF8PrKGW2tr64x6KVzPPffcjNcBwGz333+/Dh06VPD1Fr3NraGhodibADBH 2bZdlGCTZqlDIZ/7NDmOk/NyAGZfvsfrhe7HNlNlNxSETgxg7sj3eJ2N47yk4UanBWCuUh/fJQu3 Uu84gOIr5XFeknAj2ICLR6mO91kPN4INuPiU4rif9XArxPg5AHNLKY77kpyWEnDAxaNUx3vJOhQI OMB8pTzOSzoUhIADzFXq47vsBvECQCHM2v3cynkkM4DCKKfjdVbCLd9uYIaNAHNHuR2vRQ+3fO/T VIz7OwEojnI8XrOGW6GqltXV1XrssccKsi4AyEXWcNu0adNslwMA8lJfX5/1+bRws+JxSZLP5yt+ iQCgCGzblpQRbpdfs0qbt20vSYEAFEZzW7sORn6lTV/4vFavXq1ly5bpgT/9uh78kz/Ne/rixYtV WVmpQCAwZyo/E05Lm9vaS1EOAAVy+shhxcbG1Nvbq+7ubklSbGxMUvL4zmf6wMCAKisr5ff751a4 uTsEwAznes6oublZXV1dWrx4cfJxynGe6/SqqioFg0H5/XNn3L9PklPqQgBAoc2dGAaAHPx/YMnV s9b8aj0AAAAASUVORK5CYIJQSwMEFAAAAAAAllDBNLasV216HwAAeh8AAC0AAABQaWN0dXJlcy8x MDAwMDIwMTAwMDAwMTM0MDAwMDAxMzdBQjUxQTdGMS5wbmeJUE5HDQoaCgAAAA1JSERSAAABNAAA ATcIBgAAACQVvTEAAAAEc0JJVAgICAh8CGSIAAAAFXRFWHRTb2Z0d2FyZQBFeWUgb2YgR25vbWUL H4+vAAAfEElEQVR4nO3de3hc5WEm8PecGd1tSb6C8QUsbNcShRAMsg2bWoBJIFwCXdJC+zRZIKGR S7fbbGG7adNsku4fLm36bLtIlDalSdjCEggEtgmlEMZJHYIxxBgs2QZ8wYCNbUmj0Whmzn3/kM7x jOZyzpyZo/nm6P09jx+kkWbmNbZef+c73/mOBMACAFmWQURUD0zTLPh4lEVGRGERBYDXXnsNqqZC ySjIZDJITU5iMpVCanISqXQamUwGGUWBrmmQJKnWmYmIcnzjG98AMF1obW1tWNS8CK2trdB1HWNj Y0gmk1AUBYZhwDRNGIZR8IVkWYYsy4hGo2hoaEA0GoUkSSw+IpoVTz31lPNx1P7Asizouo5MJoOJ iQmMjo4ilUpB0zSn1EzThK7r0HV96snRKJqbmzG/fT4WdC7E/Pnz0dHejuaWFs7JEVHgjhw5kvO5 U2imaaKpqQlNTU2IRCLo7OyErutOkRmGAcMwoOs6VFWFqqpQlKlD1MR4AqdOnkImk8GJEyec4R8R UVDGxsbyHosW+L6qGBoaCuqlq+qZZ57BvffeW+sYRHPCgQMHKnp+LBZDf39/0Sktp9Dsb7jvvvsw MjKCeDyOVCoFVVWdU6SWZTm/7MdkWUZDQwPuueeeioLWkizLvub8LMviXCHNOX7/3hebh6+mvBGa ruv4yle+gmeffdbzizzxxBNVDVULQ0NDiMVinr9/27Ztvp5HVM/8/r23nxe0vBGaaZrYsGEDFi1a BE3TnJMAxT5++eWXnZME9a6vr8/T9838g/T6PKJ65vfv/Wz+g593KtKyrJzPe3p68p408zcy8zlE RLXgFFqhY+J169YBAC666CLnsSuuuAIAsHXr1qCzCaFQoRNRLlF+TkouFjt48KDz8YYNG7Bx40bn 8xdeeCG4VIIQ5Q+JqB6I8PPiuvq10PKLuTAJLsIfDlG9qfXPDZfzF1DrPxSielbLnx/XQvNyUiBs 6mVRMJGIavnzk1do2ScH7JMCwNSOHK+88orzefZJgTAuLmWpEZWv1j83TqHZSy+yLyq3Twrs3bvX eWznzp0Ack8KRKOBXUFVU7X+wyGqJyL8vOSN0GaWk5eTAk1NTdVNJRAR/pCIRCfKz0ne0KqhoQEA cN5553l6gcWLF+PFF1+saijRhX0OkagQv3/vZ/PnJWc/NABobGzE3XffjXQ67eyFNvOidHs7Ifvj lpaWWQsclO7u7rK+3/7/Ve7ziOqZ37/32RtaBCmv0L72ta8hmUwinU573g8tk8lAUZTAwwZl+/bt tY5ANCfcdNNNgb5+3c7md3d3V+Xs6pYtW6qQpnq6ertwaNehWsfIwUzuRMsDiJkJQEX7D7ot6s8r tHraD62SrXtmazsTIsrld/9BL/up1f1+aGGboBfxX1RmcidaHkDMTLag9lPLK7S5vB8aEc2eIPZT c90PzQvuh0ZEIij74vQrrrgidId5RBQO3G1DMF29XbWOkIeZ3ImWBxAzUynV2KWDhUZENWeXWaWl lndxOhHRbJpZYpWUGkdoRFQzxcrLb6nlLdvws+AtjPuh1YqIa4eYyZ1oeQAxM81U7V068gotez+0 Qnbu3OmsQ3NeJKT7oRFRfXHdD82LMO+HRkT1g/uhEZHQyln3mldoc3U/NFGIuEMCM7kTLQ8gZiZb UPup5RXaXNwPjYhm16zttkFEFLRZ222DiGg2zMpuG1RbIs55MJM70fIAYmYKGguNiEKDhUZEdcle eZGNhUZEdSl76ZiNhSYYEfewYiZ3ouUBxMxUTYqiQFGUnMswWWhEVJfi8TgSiQQymYzzGAuNiOrS sWPHcPz4ccTjcecxrkMjoro0PDyMkZERnDp1ynmMhSYYEdcOMZM70fIAYmaqpsEnfwA1k0HyNAuN iOrc+r6rcPLdd4C16zBy9CgAzqERUZ26eN1aLD1/Tc5jHKERUd26eN1a7Mn6nCM0wYi4doiZ3ImW BxAzUzU99tDf4bt/87/w80e+4zzGQiOiuvTU3z2IB//8m/idW25xHmOhEVFdKrkOjbeiI6J6wnVo dUDEtUPM5E60PICYmaqp5Do0jtCIqJ5wHRoRhUbJdWgcoRFRveE6NMGJuHaImdyJlgcQM1M1lVyH xhEaEdUTrkMjotDgfmhEFBpch1YHRFw7xEzuRMsDiJmpmrgfGhGFBtehEVFoFFqH5hTazBt2EhHV G47QBCPi2iFmcidaHkDMTEFjoRFRaPCQk4hCg4VGRKHBQ07BiLh2iJnciZYHEDNT0FhoRBQaLDQi Cg0WGhGFBgtNMCKuHWImd6LlAcTMFDQWGhGFBguNiEKDhUZEocGFtYIRce0QM7kTLQ8gZqagcYRG RKHBQiOi0GChEVFosNAEI+LaIWZyJ1oeQMxMQWOhEVFosNCIKDRYaEQUGiw0wYi4doiZ3ImWBxAz U9BYaEQUGiw0IgoNFhoRhQYLTTAirh1iJnei5QHEzBQ0FhoRhQYLjYhCg4VGRKHBQhOMiGuHmMmd aHkAMTMFjYVGRKHBQiOi0GChEVFosNAEI+LaIWZyJ1oeQMxMQWOhEVFosNCIKDRYaEQUGiw0wYi4 doiZ3ImWBxAzU9CcQpMkqZY5iIgqxhEaEYUGR2hEFBocoQlGxLVDzOROtDyAmJmCxhEaEYUGR2hE FBocoRFRaHCEJhgR1w4xkzvR8gBiZgoaC42IQoOFRkShwUIjotBgoQlGxLVDzOROtDyAmJmC5hSa ZVm1zEFEVDGO0IgoNFhoRBQaPOQUjIhrh5jJnWh5ADEzBY2FRkShwUNOIgoNFhoRhQYLTTAirh1i Jnei5QHEzBQ0FhoRhQYLjYhCg4VGRKHBQhOMiGuHmMmdaHkAMTMFjYVGRKHBhbVEFBocoRFRaLDQ BCPi2iFmcidaHkDMTEFjoRFRaLDQiCg0WGhEFBosNMGIuHaImdyJlgcQM1PQWGhEFBosNCIKDRYa EYUGC00wIq4dYiZ3ouUBxMwUNBYaEYUGC42IQoOFRkShwUITjIhrh5jJnWh5ADEzBY2FRkShwUIj otCI1jpANfX09BT92tDQ0CwmIaJaCE2h9fT0lCwtt6+Loqu3S7i5D2ZyJ1oeQMxMQeMhJxGFBguN iEIjNIecQ0NDnEMjmuNCU2hAOEpLxDkPZnInWh5AzExBC1WhFVMvJwTIm9iOHc7HfVu21DAJiSYU hVbqULOc7yGi+uYUmiRJtcxREbfRV3aZ2d/LgiMKH+cspyzPjROeoheZiHtYiZapb8sW3HnvHUId bor2/wgQM1PQnBar5xFaOTiXRhRevufQLMuCZVkwDCPnl2mars/1MkoKonhYZkTh5hSaZVmen2SX ma7rUFUV6XQamUwGmUwGiqK4Pr8WxcIyIwo/55DTy8jKZo/MVFVFKpVCIpHA2NgY4vE4kslkxaGq Pc9VT2Um4tohZnInWh5AzExB83XIaVkWNE1DOp3G+Pg4RkZGMD4+DlVVMTk5WdZrFSqveiogIhKH 7zk0wzDwre8/icxEApmJCajpNEzDgGnonl8je8FrsY+JiLzyPYdmmiZMw8CS1V0Yee8oWtrbnbm1 U+++G0hYIqJSfC0+s4sLlolVv7IeC1asxIIVK9F5zvJq55tzRFw7xEzuRMsDiJkpaL4KTZKkqXVr kozOeW2+3zx7hwz7Yx5uEpFfvubQJEmCLMuQIxGsPvts7KkgQHZ5sciIqBK+TwpEIhFEolFcsuZ8 WDfcgAPvf4DT4+Owylj+QURUTb5HaNFoFHI0ii//6VehKRnoqgrLMKBmMp5fhxsy5hNx7RAzuRMt DyBmpqD5HqFJkoT7fuNWjI+PY2JiApOTk1BVFaOjo3jgtd2eXqNQaXEOjYj88r3Fhr10w778SVVV KIoCTdMqCuS2lTYRUTG+9kOzr+NUFAXJZBLxeNz3lQJERNXiFFq5+6FV60qBQubyIaeI91JkJnei 5QHEzBQ0TyM0+/DS3iJI0zSoqgpT17Ck63yMHD3i60qBuVxcRFR9ricFsrcKUhQFmUwGyWQSExMT 0FUVq9b9CkzDgDV9KdTYB+/PRm4iojyu13LOnC+bmJjA+Pg4xsfHoStKRVcKADzsJKLqcQqt2H5o 9lZBqVQKo6OjGBkZwdjYGBKJBNRMpqIrBbhEI5+Icx7M5E60PICYmYLmaR2aruv4s4e/g8zEBDIT CSiTk1MLaU2TVwoQkTDyCq3YCQBD07D8gl/FiYMH0NLROT1vZuC3b7sN0cZGRBobIUciMHXvZznt NWccpRFRNeTMoWUvlrXvEZBOp5FIJKCrKi5YuwamYUBXFZiGgVOH3oVlWbjy4o+hvb0dzc3NSKVS GHz9NU9vbs+fcddaIqqGnBGafQIgk8lgYmICiUQCk5OTSCQS0DJptLe2nvle04RlWZAkCaZpQtM0 yLJc1pUCLK18Iq4dYiZ3ouUBxMwUtJxCs4tpcnISIyMjOH36tHOtpppKYfniRc73StMLcSVZnlqT ZppIp9NQVbXiUDwMJSI/8ubQNE3DHz4wiFQ8jnRiHGoqBV1VAcvCBeeei1+/+iocOn4cpxMTMDQN 8Q8/xM/2vgnT0CFJMkzTKCsADzeJqFryDjkNw4BpGLhkSx+GXn8tZ9HsZ2+7DQ3NzYg2NgKSBEPT sPqyXowcPeIcgpZzpQBvkkJE1ZRXaFP3CrDQs2olNF2HomlQNA3vv/UmLNPETZs3obOzE7Is43v/ +jyvFKgyEec8mMmdaHkAMTMFLafQztwrQEJbc7PzmPN1WYZpmlBVdepkgJF7eFnOjh1ERNWWV2iR SARyJIKzFnTmfbMky1AUxVmjpqbTOV8v51Z4QO46tJk3TCEiKpdTaA0NDc5/o42N6Fp2Nm7c1Iv3 T49gdGLqBMDpI4fx41d2wdB1mLpelREab5JCRNWSM0KTZRkNDQ2Qo1Fs+/o3oSsKdFWFrihQ0yl0 X3k1jh/YPzVfpmuwLAvvHdjvPL/cERrlE3HtEDO5Ey0PIGamoBW8lvOB3/89jI6OIplMIpVKIR6P 468efQwXrF0DQ9Ng6BpMw4ChaTmjNK8jNC9bbHO0RkTlKlhouq5D0zTn0qdMJgOjwDWaMwvM6wiN 82VEFISCVwpkMhnE43HnSoHx8akFttnsdWd+Za85y/6ciMgvb1cKTM+lZZNkGdKMrYIqOSnAYpsi 4pwHM7kTLQ8gZqagRQE4O2xkbxV0ad+VeOu13c6CWdMwsO/td5wnVjpCm4nFRkSVigJTozLLsqCq KuLxOHRFwfqVK6BoGlRdR2a65LJHaYVGaJUUHIuMiCoVBYB0Og1d12EYBkZHR6FkzZdZlgVZkqDP KCtnhFbhKI1FRkTVIgNAIpHAiRMn8N577+HIkSPITCTyvtGeH8veNmj6C77euKenJ+cqAZrS1dtV 6wh5mMmdaHkAMTMFLWqaJr7y99+GkkxCy6ShTE7mjNBc+RihZa9D412fiKhaogCwZetW7Nq1a2oL bsMALAv7j03tmiFJEkx7F44sldwMhWVFREGIAsDa5cuB3t6pEwO6Dt0woOnu12naO3MQEYlAznvA Y0E5c2hUVSKuHWImd6LlAcTMFDS5bcHCqr0Y90MjolqSC12j6RV31yAikciFlmh4xREZEYnE00TY l66/Dldc0IP2trag88x5Iq4dYiZ3ouUBxMwUtILbB800v7UV/Z+5Ee2trTj04XG8vn8/Xt9/AG/s 349EMun7zbu7u3M+Hx4e9v1aRESeCu3+7z8JU9excuFCXHR+F/o+/jHcetWVME0TW75wt+83Hxwc zPm8v78fAIuNiPzxVGjrVizH2mXLsG75OVi/aiWWLlgAADB8Lq6NxWIAzhSYzS64/v5+lhoRlc1T oW2/6w4AwOnxcew7fARPvhTDvncP4cDhw2W/YSwWw7Zt2wqeIbULbnBwcM6Wmohrh5jJnWh5ADEz Bc3TSYGfvvkWRhIJtLe1oXPePLS1tKCxoQERH4tri5UZEVGlPI3Q/voHT8PUdSyZNw8Xda3G9Zs3 4XPXXQvdMHDlF3/X85vZh5pu+vv75/QojYj88VRo5y9bhu4Vy9Fz7ipccN55aG9rBTB12zsiIlF4 KrS/vPsuAIBuGDh47H3s/fnb2HPwIN48+Hag4eYiEe+lyEzuRMsDiJkpaJ4K7dHYDrz17iHsO3QY mUwGuqpM3WeggsumiIiqzVOhPb7jZ1P3FNC0it6sr68PAwMDkCSp5ImBwcFB9PX1cf6MiMriqdAk ScLNV1yOT2/sxZLODpwaG8PTO36Kx//1eRjuTy/6moVKTZIkDAwM+HxVIprLPBXajRt7ccenrnE+ P3vRInzp12+BZZr45x/9uKw3tEdpQOGL2wcGBtDX11fWa4aJiHMezOROtDyAmJmC5qnQPt17KX4x vB8PPv1DfDQyikVtrfjSLTfj5r4tZRcaAKewZo7E5nKREVHlPBXa4o4O3P9/n8DJsTgsy8KJ0VH8 8/PP43//0X+t6M1ZYERUTZ4Wkp0eH8dnt3wCZy9cCFmWsWzxIvz2tZ/CqbF40PmIiDzzNEL70a7d uONT12Bj9/qcxwe//2QgoeYyEdcOMZM70fIAYmYKmqdCe/YXr8AwDHx642VY0tGBk2NxPB2L4YkX Xgw6HxGRZ54KzQLwzM9fxg9iO2AahrOwlheZE5FIihbaX959F9pbW11f4BN3fqGqgYiI/CpaaOOT kzBME5YFLJw/DxOpFFRNB2ChubERTY2NiE9MzGLUuUHEOQ9mcidaHkDMTEErWmjf/D+PQdE0qLqO R//7ffjqw9/FwaNHYRoGIpaJb9z9Rbz06quzmZWIqCRPyzZSioKrL7kYHW1tkCQJbS0tUDUV/Z+9 Neh8RESeeTop8NM338KNmzfhxs2bch4/evxExQF6enryHhsaGqr4dYlo7vE0QvvH557H47Gf4uRY HKZpYjKdxr+/sRd/8kBlF5H39PRgaGgo71ehkpsrRLyXIjO5Ey0PIGamoHkaoWmGgUdeeBH/9KMf 5yzb4H5oRCQS7qFNRKHhaYR23WWX4va+X8P8AuvSKlmHVuzwknNoROSHp0L73Nar0NzYiHgyCcMw MHWBQHWuEmB55RJx7RAzuRMtDyBmpqB5KrSUouC5V3fjoR8+W9U5NPukgNfHiYhK8VRo337uedze twWPtbUhnkhU/KbZh5lz+YwmEVWXp0K789pPoqO1FQ//8b1IZTI5h5y3fPmPyn5Te/TFkRgRVZOn s5yL5s9HNBJBS1MTFnV0YHFnBxZ3dmJxZ2dFb84yyyfi2iFmcidaHkDMTEHzNEK75et/PnUbO1Wt +hxaMSw7IiqXp0ILCk8IEFE1FS20my/fhM093dj2twP4hy//AWBZ09NmVsVzaKXYa9NYakRUrqKF 1tLUhAXz5gGYmkOj2SHi2iFmcidaHkDMTEErWmiPvrQDj7z4EoDZn0Pj6IyI/Cg5h/bAPf3Ye/gI dh04iN3D+3FyZKSqb87iIqJqKlloT/xsJy5cfR5+9/rrcM9NN+DdDz7ErqFhvPzmXgwdOgxzlkIS EXlRstD+7fVf4l92vQrLstCzcgUuWXM+rtpwCW6/5mpMTKbwyr638PUHH6pamOxD0Lk6ehPxXorM 5E60PICYmYLmadmGomnY/94xmLqOjKLg6g2XYMH8+dja21txobHEiKhaShbapevWYu3yc7B+5Qqc u3QpJEkCAKiahj0H38aeAwd8v7FdZNmXQRERVaJkof3+Z250Pt576DDeePsdvPHOO9j3zjtQFMX3 WU6uMyOiIJS8lvOF1/fg+OgoAGD12Wfh3LPPwvIlS7CgwnVp9uJZjsryiTjnwUzuRMsDiJkpaCVH aN978SdQdR3zW1pw4bmrcHHXatx1/afxh79xK4599BF2Dw3jW997xNcb81CTiKrN00mBU+Pj+Mkv 9+DwBx/i6ImPcMPlm7DyrLOw8qyzfBeaLfvQkycIiKgSJQttaWcn1q9cgQvOXYULV5+HtuZm52tH jh/H7n3VLR2WGBFVomSh3f/FO52Px5JJvPL6L/H6gYN4dd8+nBod5W3sAiDi2iFmcidaHkDMTEEr WWh7Dx/G3kNHsPvg2zj84YfQFMW5lpOISDQlC+2vnngKqq4jo6qwrOrc5YmIKCi80TARhQYLTTAi znkwkzvR8gBiZgoaC42IQqOm9xTo7u7O+Xx4eLhGSYgoDDwV2nWXXYrb+34N81tb8772iTu/4PvN BwcHcz7v7+8HwGIjIn88Fdrntl6F5sZGxJNJGIaRc5MUP2KxGIAzBWazC66/v3/OlpqIa4eYyZ1o eQAxMwXNU6GlFAXPvbobD/3w2YrvKRCLxbBt27aCy0DsghscHJzTpUZE/ng6KfDt557HpevWob2t reI3LFZmRESV8jRCu/PaT6KjtRUP//G9SGUyvu/LaR9quunv7+cojYjK5qnQ7PtyRiMRtDQ1BRpo rhNxzoOZ3ImWBxAzU9A8FVpQ9+UkIqomLqwlotAoOkK7+fJN2NzTjW1/O4B/+PIfAJY1PW1m+Z5D 6+vrw8DAACRJKnliYHBwEH19fZw/I6KyFB2htTQ1YcG8eQCm5tAWtbdjUUc7FnV0YHFnBxZ3dmJx Z6fvN7bvIOX18bmiq7er1hHyMJM70fIAYmYKWtER2qMv7cA/Pf8CgOrOodmjNKBweQ0MDKCvr6/s 1yUi8n0tZ29PD37zmqvxn7ffX/Zz7cKyi23m40REfngqtA1r1+D3brrBOQS1aRWe5WSBEZGbcnrC U6Hd8clr0NLYiOMjI1jU3o5jJ09ixdKl+PbTP/SbkYoQce0QM7kTLQ8gZibbzJ123FiWBdM0Xb/P U6Gds2ghvvrwd5BOZ9D/mRvxpe1/gesv34yPrVlTVigiIsDfyT/DMFy/x1OhpVUVGVXFeDKJlUuX 4uyFCzGvpQVbNlxSdigioqGhIc+XQgJT14B74anQ3j1+HBd2rcbjL76E0YkJPPL1rwEA3j95suhz uru7A12CwQvcieqb17mxcorPU6H9zVPPIIKpEvmf3/0e7rjuWsiShId+8FTJ55Xbwl55bet6JOIe VszkTrQ8gJiZguap0E4nEjA0DQDwzvsf4L89MOB5HVq1z2QGUZBEFA4lC+2bn/8dWLBgWWd+wQIs y3Qug/pPf/Y/ZiUoEZGbkoW2aumS2cpBRHNQT09P0a8NDQ2V/XolC+3l4f34WNdqqJqGXwzvx869 b2LPwbeRTk1y+6CAiDjnwUzuRMsDiJlppqGhoYKl5qfMAJdCe/D//QimZeH8ZcvQu24N/sut/xGt zU14Zd8Q/n3PHvx8zxuYSCZ9vbEt+zdj/+b8/maIqP7MLLVKfv5d90PTDQNvHDqEB5/9F9y1/X48 /pMYLr/wV/Gnd96BrRt7fb8xAKe8sn8DxRqbiMLL7oBKBzOuZznnt7Rgc/d6bFi7BpesXYOWxkYA wHsnPsKxEx9V9OZERLZqHJmVLLQ/uf03sXb5OZAkCaZp4q3DR/CLfUPYuWcPjp04wTm0AIi4doiZ 3ImWBxAzU9BKFtq6FcsBTK1De+3AQSQmJ9E5bx6u27xpahmHaWLw8e/7fvOZh5f2x5xDIyJb1Xfb WNzejk9ddmnBr1VSaEDtyotzdUS1U5PdNj5//7eg6joyqirkXZ/s/yl+rxm1LIt7shHNsu3bt/t+ bnt7e8mv+96xthJeRkZuI7fsG6j4HeUNDw8jFosJdR+DHTt21DpCHmZyJ1oeQMxMg4ODFT3f7dLH mhSaSHNkkiTx8JMoJGpSaCISqWTJHRdg15dYLDYru+TkFdqPH3sUaioFJZWCrmRg6jpMw8i6OP3M fwEAkgQ5EsH6vqs8v6n9l7Ha13ER+cWCDIe8QrNME9d97vPYFYtNTfyb5nSpTRebaeb99/SRw2W9 abVWBRNVg/0PK0ut/hUstFVLl0L7D5+AomlFz3IamgbLNPH+m3s9nU4lEtHMowSWWn3Lv5bT4xk/ Sc56apnbYXMCnkRQ7O8h/37WL9eTApZlQZYkFLrfSrX29ee/ilQL/DsXPvkjtAIlZWY9ZvHwkogE lT9Cmz7kNO2zmTO/nHWoKdKCVJq7eLacbEUPOWVJgjT9i0hUbtMVnM6YW/ILbcaorNQ8WSVzaIXO LmXjX0IiKlfRQ84zn+Z+nj2H5nytzFEcy4qIgpBXaJIkYX5LS9EnZM+h2SM0WXbdyZsoELzihLLl F5os46wFnc6ZzWKHlZZpOiM0OcpLQql2WFpky2uiSDSKNecswyc3fBzvnTyFeDLpXDGg6Tp0w4Sq 69ANA5quw9B1JE7W770FLMvK2YqI6gNLjArJKzQ5GsVtX/giDE1zLkx3rt00TWB650hr+mPLshBp aJy1wNyQkaj+zNbPbV6hbb35lunRmFHyWk57x1pDP3PR+kzlbrPrVbVHVUHlJKIzZuNoKLDJL65f I6IglNpXLQoArU1Th4ymZcEwTZjm1H91w4A+fchp/zI0NW/7IEzfAcoyTSw4Zzk23vZbiDQ0zM7v jojmHEPTsOfg23mPRwFgcUcHgDNXB8iyhIgsIxqJwLQs6JEILNNEY0sLUGJJBxFRLUUB4NylS3D1 xy/GqXgcE+nM9NlMwzmbqfKGwkQkqD1ZH0sAqrMHEBFRjf1/WwoQUouhLCMAAAAASUVORK5CYIJQ SwMEFAAIAAgAllDBNAAAAAAAAAAAAAAAAAsAAABjb250ZW50LnhtbMVXbVPjNhD+3l+xdaedduYc JwSGIyW5gQtc6YSXKTDTflQkxdYgS64kJ+R+fVfySxIg4a50rh+wo9WzL9p9di2OPzzmEubcWKHV MOp1uhFwRTUTKh1G93fn8fvow+i74+/H1x/v/ro5Az2bCcoHTNMy58rFVCuHb7i5P51cfIQoTpLr gqvrAOtokybJ+G4M1XpcawH6SZKzqwiiyl6HORaNjrcZxxiVHVS7wyhzrhgkiUY3euVmr9vtJtU6 qhWsW8rd+IBo4I4/up1oD2jBZPqK7YBo4MyQxU60B2DOG/xMt+jFYtFZ9AOyd3R0lPx5O0nOtclJ G8ujFOphKz7sNlBV5lNudkdCHNnIi52nLxmvEjhvQ6YZMbvzFxCrjPTZKxnpswaMh822HPB9comb 4XE5WaXP5DuNe0B7PmpEsTvyChI17KeSWDuMKj7Uso0eaqlcKSbteoaMjhmn0o6OQ5JXEqjWiuTI qxMjiIR7JbAVOVzeRjDTFXRGciGXw+gnUmj761NcJY1gzXYhHMXkzQlCPSOT3Z5/+wSXQtFMw0Sk mYPft7l+Bny77yuRT0sLf+icKLjSRzDZ5vw58gXvlUqccsWNoMPIePRr8SUvVKoWkdKhBSdoHEy0 JQzPjYPc9Vo3ddiBK41CYZBkxglu2+MtuE/iMJpqyUIYa6a3+5mZZ45SQ4pMUNvIC2L8KA2LuNL6 1EBeiKcSZNqIzxgWkTFmdRhRNMFN9HzXcDmM0AUJbhtALozROGWUVjxUkEpRYP45dT93aQ5rf79E 4EffQJa5UET5+d79sZb58W9wFq2JDGdrq9RwrtbWU1mu66ckzwk2ZGtOahML1XbqjEjL6010pGzI FcUkxr3uWhReLcf+GkbWEcWIeaFCyVaO1BtTzZajY0+DgeV/l+iHN/R6LoQgYsIWkixjXTqc4TyW fO7TjZ/osF0V80LK0mL0Do/kw3qTsbumC95mxXP9rUbG9QfRZ3p71opKZZ3dt02NRheQkTkH5s0j wRngrCBFIQUN2UJiGi/KEJ9xyTwQK/UOXMahDj4ZCSWcn7EYDNMLfEkJUusHkOKBI1RYGNQRFl8Q VPINMaPjQGCRk5RXXF6HhdkRpBtToVdXgfjRbmK3LPhmh8/TwUIw/z0+7Bzs9WleybJ6gB129g96 XhhMf8Z+Y/wxFDdcRAaZ4bNh9MONoK403CbYad3uXje8ur3+Yf3eH5/19w5Pev1OEW5FQbcKxoq8 CLeTILOZxpsVx2sNa0QETROHSK0mmrAVhf6rAo1OSxdYUjEGkAPINGQr+BFHVFpKYqCmOYgZCMBf lAedmkjEgnBeM19CffkDHD9kjWFU5wWmyHL2DqxGIwwHIiwIPpxud58a6MCFd0iR2U5It+FTsVVU kGFP7PAe+M0VniTlrAP/A8f/FX/3voa/NVU3+VuTepO/vS/k737D45PTg97J4XnvW/O3GbuFr/9T FN5LRhfWU8JwZMMSybT0XApEeTIdVzz1ISpkMCeWA07KAnIOOLw7zWRGX1/ZYsnGVzHZ8o/f6B9Q SwcIVrL7yYQEAACfDgAAUEsDBBQACAAIAJZQwTQAAAAAAAAAAAAAAAAKAAAAc3R5bGVzLnhtbO1Y S2/jNhC+91eoLNqbLNmJmziNsmg3+2iRx6JJgPZIS5TFViIFkrKT/fUdkqJk2ZSTwkBPzSGION88 9XFmlMt3z1UZrImQlLMETScxCghLeUbZKkFPjx/Dc/Tu6pvLb6/v3z/++eVDwPOcpuQi42lTEaZC qV5KIoMvT7/c/Po+QGEU3deE3RvUhItVFF0/Xgf2+bpVCsBNFH24QwGy5iaZytDV5YhtiJDJCytM UKFUfRFFHLzw3sssjuPIPqNWwWgfxBuEgyvyrA6iNaAD4+Urtg3CwTOBNwfRGgAVd/icd+jNZjPZ nBjkdLFYRH883EQfuahwF8tzSdnfo3gjdVDWVEsiDkeCFR7URa5XPuO2gOsu5LTA4nD9DKKvyEn2 SkVOMgeGZIuRBM+jWxCaX7c3fflEddC4BnT5pYLWhyO3EOS4P7gtHWtzDozNSFrKq0tTwP4ksM8M V8CZnwXFZfDEKFwyEtw+oCDnFprjipYvCfoB11z+tIuzpyjYsl1TlUJh1higmm3RYc+fPwW3lKUF D27oqlDBb2Ou94DH+76j1bKRwe+8wiy444vgZsz5PtLj3aqEK8KIoGmChEa/Fl/keVPtke00LoWM 5Lgp2/7jjLZBrgSuC5pK5MC1AMoIRaFR6VsMpoDmIdw6Esoap3Crw4IL+hWc4jJB8WR2fpIC+8bA a20s3YcSlr3V6h7UYxOKn/KSQzP4LjY/g+q9/tIk/QqI6UzfCzgrMVs1eAVHhLXGG6YEFOzpYc9y iCXFzEvILaT24JDWjxU6V07GOCNO1nr1iXrvKa/qkjz7ruKu+w7qDaCT+kLwCvUMCXGjuH4zUCya EW4YFeKyLrCD1Q1LVYMVdJlwA+IESaqtdRHol7sUBEPflwpugOroCHMHeMtrqQm/y9DuaMDwt9C+ xgKbQH28/59L/y2XoCTFS10QhhUUKcelHB5q2ghSYcpCPXRDYyZBsz1Q3cjiFUiJs4x0csahsVRU Hc3nAvI2C88ooYMhn8OMQrNk2slsMovnuodZxEZQpZtcBYVPUClCtUTRYaZvM9zS8wFsZ1hkaJT3 7pWUWMoEmWUwGrf3yY2JfzE+tM0LrDkMObzUZOh9vboAAsQmb/j7xf3d1kAXdZs6ruWHMDshXF7v CQQpPfn1U8VqprCIE+GR7qj3FW8rbbLhjbKDyHNWkjUp22ZjBOYArodzBttqmJtVN0Ha/pu0Z0dp nxylfXqU9vwo7R+P0j47Svv8KO3FUdrTeEw9GmVgzrliXBEJbY3ldNUI05o8doCLRsPuaWtcNnAr 4/awNwM3hSrzSVBDLx/o2E8u3Z+0Pfdp26UHq9rbIqH+SJwdnWPvamjMAKzQrIWymxm2QnkuidKr 4eli0bcUXxlaI326JclVK4PhCzOH6Ckx39623WrdPuphATZpGg53bl24sIJPTyIGjbSupiMrh9HY 0Ex/G86mk/miXWvNeUH0FgCCs8nidDQpZ5bCjIbOBsHj9jVyoQSmdh+psIBZFUIP1bNnftr6aY+X XEFGPokuDrSUyfRsPhQIG1sncZuCpRNU4bmLX/f4/suqBUhSu75v048n8fS8t+RGZbgkkKzBa8w0 nnowOIeSeyE4+6uRyr5S+6LtOXT+ru7z7/tdZbAB+tfPdooQrHcK8xBtZ7d1GO3RoqfUPodagQXu MKs91JYOjvwtV2HPvS0m71iP/P+uuvoHUEsHCFT8PRwABQAAUxMAAFBLAwQUAAAAAACWUME0gbtD aWIEAABiBAAACAAAAG1ldGEueG1sPD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgi Pz4KPCFET0NUWVBFIG9mZmljZTpkb2N1bWVudC1tZXRhIFBVQkxJQyAiLS8vT3Blbk9mZmljZS5v cmcvL0RURCBPZmZpY2VEb2N1bWVudCAxLjAvL0VOIiAib2ZmaWNlLmR0ZCI+PG9mZmljZTpkb2N1 bWVudC1tZXRhIHhtbG5zOm9mZmljZT0iaHR0cDovL29wZW5vZmZpY2Uub3JnLzIwMDAvb2ZmaWNl IiB4bWxuczp4bGluaz0iaHR0cDovL3d3dy53My5vcmcvMTk5OS94bGluayIgeG1sbnM6ZGM9Imh0 dHA6Ly9wdXJsLm9yZy9kYy9lbGVtZW50cy8xLjEvIiB4bWxuczptZXRhPSJodHRwOi8vb3Blbm9m ZmljZS5vcmcvMjAwMC9tZXRhIiBvZmZpY2U6dmVyc2lvbj0iMS4wIj48b2ZmaWNlOm1ldGE+PG1l dGE6Z2VuZXJhdG9yPk9wZW5PZmZpY2Uub3JnIDEuMC4yIChMaW51eCk8L21ldGE6Z2VuZXJhdG9y PjwhLS1TUkM2NDFfWzc2NjNdX0xJTlVYX0lOVEVMX19zeWx2ZXN0ZXIuZGV2ZWwucmVkaGF0LmNv bV9hdF8yLzIwLzAzXzEyOjMzOjQ1LS0+PG1ldGE6Y3JlYXRpb24tZGF0ZT4yMDA2LTA2LTAxVDEw OjQ1OjU1PC9tZXRhOmNyZWF0aW9uLWRhdGU+PGRjOmRhdGU+MjAwNi0wNi0wMVQxMTowNDo0NDwv ZGM6ZGF0ZT48ZGM6bGFuZ3VhZ2U+ZW4tVVM8L2RjOmxhbmd1YWdlPjxtZXRhOmVkaXRpbmctY3lj bGVzPjI8L21ldGE6ZWRpdGluZy1jeWNsZXM+PG1ldGE6ZWRpdGluZy1kdXJhdGlvbj5QVDE4TTQ5 UzwvbWV0YTplZGl0aW5nLWR1cmF0aW9uPjxtZXRhOnVzZXItZGVmaW5lZCBtZXRhOm5hbWU9Iklu Zm8gMSIvPjxtZXRhOnVzZXItZGVmaW5lZCBtZXRhOm5hbWU9IkluZm8gMiIvPjxtZXRhOnVzZXIt ZGVmaW5lZCBtZXRhOm5hbWU9IkluZm8gMyIvPjxtZXRhOnVzZXItZGVmaW5lZCBtZXRhOm5hbWU9 IkluZm8gNCIvPjxtZXRhOmRvY3VtZW50LXN0YXRpc3RpYyBtZXRhOnRhYmxlLWNvdW50PSIwIiBt ZXRhOmltYWdlLWNvdW50PSIyIiBtZXRhOm9iamVjdC1jb3VudD0iMCIgbWV0YTpwYWdlLWNvdW50 PSIxIiBtZXRhOnBhcmFncmFwaC1jb3VudD0iMTIiIG1ldGE6d29yZC1jb3VudD0iNzkiIG1ldGE6 Y2hhcmFjdGVyLWNvdW50PSI0MTUiLz48L29mZmljZTptZXRhPjwvb2ZmaWNlOmRvY3VtZW50LW1l dGE+UEsDBBQACAAIAJZQwTQAAAAAAAAAAAAAAAAMAAAAc2V0dGluZ3MueG1s7Vjdd6I4FH/fv8Ll dY8F7Uxbe1rngAq1H9YKYutbJLdKJyRsCKLz129AbacVZrsqe/ZhOceDITe/e3NzP3PxbRGQyhx4 5DN6qdSONKUC1GPYp9NLZeiY1TPlW/O3i9/b9y3nqd+psOdn34NzzLw4ACqqEQghaaNKf2jcdlsV paqq9yHQ+4zuiPGpqraddmU1bq+XVSQjVe30lIqyAjzCAivNi0J0KSWNzlfTl8pMiPBcVZnkw974 1DVNU1djZb1gQXz6/ZU+SZKj5DijrTUaDTWb3ZB6jD77019g19QVibLRwTutvcq+Ebl5sSJfA1d9 AUG6n8r6M0WB3Mnch+R1l0remvf0rqTXOSCHhcpmRixDOeNToTTrF+o2wudRb+FZ5MFq+8GOfCxm ueIe1xun+2FfgT+d5QpdO67VjncDt2csGQCW5gGtGaJTiD4wmDBGAFGlKXgMu/O4AoSBj2Y+AYOz JJJGUMToGZFoD04mY6J8Tl2agcMdw3AQ+GqAwqpPMSwAb59/vsNka2Tw4MvPWVEXfxA1EjxVTzP1 zT0cqsiZvtRO97D5Isf/enK6s5dG/oTAwX0/Qz10nMpAB0Uun8aTk72gDSYECw4cTsaMBY5E+mhn M8Z3V3AKaiJPMJ4PW9N2BO5GNhDwBGCTyw87+HHOx5+dsmh67ef5BDJHfi6jrgYxR0Lm5n+SWnWM +4gjB0kzsEPklRMi+zK2iAGktQN8DDyHwL+VJc0wxEjkBeGNaewGLVMhlwYHvMWCkEOUFj8HN+tM P7bUPYFrNinMu/ueQB+FwE3OAhtE/DFEHYxLGlP7qJTyIcPPbLUE8PSkhR4LtrKkkqRvMRkPGClL OcBzzxZFcPLF8CniS6UZT2//UDVMJoG7RKO76fDqOpzQAfGm+n/yGWrYdIhhu39POtL1O/nqZgNV PTN1yxjqevtsIsd20PAHlqk92fqiRQ2596/a+LHbGNTdePx4HT4tjQcvIDG23GUraMh5V/43NTRq xH3XmHt0sHwaEa0V9OaeRYj3Q5M4vZen0YL0nc7NZGQux3USjy3zT/zY0ybp+rYm7uzk7fcQvkzq i7kXSH1fDVjf6WpSlh8Ty62PR0njTn+bxwF5GTta0iLGw6DTm6dnBJ3BDFudm6Fl0rHbCyEYnjiW q6Uyl3oI/z//5nO5RwjQKWUiKwSKk+GOeUoPQ7IcRsDbSKDDRzDTB4LLjMA2moO7usC4py3CosM0 bNtMLMImiGwuftLypIyk3o1ugFM98hHtx9QTcXbqJTDSiT+lMu/agoV9FvklsWnFnEt1pcaVZqz0 bbOYe1tGvOpV1U/nxN52Sb/pdy2gwH2vsqbcw+9MtCjm81lZsy6vpOopp9bXhS1k1VNawclZFMqu qix8i6Nw5ntlFIPvTVEW/wGiOKfw3+e6YF2UT8FA3vcpZzEtbI4OvZP9rLTNUZI1mOUUsQaR+jBl obxL0Czso9Wtu2q16Oa9+RdQSwcIYIjI8FgEAAAiGAAAUEsDBBQACAAIAJZQwTQAAAAAAAAAAAAA AAAVAAAATUVUQS1JTkYvbWFuaWZlc3QueG1svZNRa8IwEMff9ymyvDfXqMMhVlGrMNimD/qwx9Be a6BNQ3M6/faLY1VBYThkeblcuPv9/+G4/nBXFmyLtdOVibgUIWdokirVJo/4ajkLnvlw8NB/jOeT 5cdiykpldIaOes2FLVbj15cJ4wHA3KKZZ5lOUFR1DhAvY/bW1Hk2wPSdM948iZRS7uGXTG/KuGMa 8TWR7QFUnl+d+K0wlNAUeRA7kTJdYICG6v2ZY0y1CmhvMeLK2kInivyvYWtS4TZGeFHxWWvCmp+a sk1RBFbROuLA4SYNXaocwZr8Om6hE9rU6ECG/rTC7xDKdvcnduJpu9UdybY4IP5FutNYGI2f5Kg7 k3+Q/kXxRhrhjsAP5jo1qQz55sPk7sp1tC/Q3R1bIqn7e0Uiv6xHt324WKfBF1BLBwhaFbNOMAEA AOYDAABQSwECFAAUAAAAAACWUME0gJBrfpsbAACbGwAALQAAAAAAAAAAAAAAAAAAAAAAUGljdHVy ZXMvMTAwMDAyMDEwMDAwMDEzNzAwMDAwMTM0REUzMjdBMTMucG5nUEsBAhQAFAAAAAAAllDBNLas V216HwAAeh8AAC0AAAAAAAAAAAAAAAAA5hsAAFBpY3R1cmVzLzEwMDAwMjAxMDAwMDAxMzQwMDAw MDEzN0FCNTFBN0YxLnBuZ1BLAQIUABQACAAIAJZQwTRWsvvJhAQAAJ8OAAALAAAAAAAAAAAAAAAA AKs7AABjb250ZW50LnhtbFBLAQIUABQACAAIAJZQwTRU/D0cAAUAAFMTAAAKAAAAAAAAAAAAAAAA AGhAAABzdHlsZXMueG1sUEsBAhQAFAAAAAAAllDBNIG7Q2liBAAAYgQAAAgAAAAAAAAAAAAAAAAA oEUAAG1ldGEueG1sUEsBAhQAFAAIAAgAllDBNGCIyPBYBAAAIhgAAAwAAAAAAAAAAAAAAAAAKEoA AHNldHRpbmdzLnhtbFBLAQIUABQACAAIAJZQwTRaFbNOMAEAAOYDAAAVAAAAAAAAAAAAAAAAALpO AABNRVRBLUlORi9tYW5pZmVzdC54bWxQSwUGAAAAAAcABwDaAQAALVAAAAAA --=-k0bJJnk7Qaq1V0+G97NB-- --0-596188450-1149245335=:1049-- From kris@babi-pangang.org Fri Jun 2 07:03:22 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 7783B3B03DE for ; Fri, 2 Jun 2006 07:03:22 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20299-05 for ; Fri, 2 Jun 2006 07:03:21 -0400 (EDT) Received: from nasi-goreng.babi-pangang.org (nasi-goreng.babi-pangang.org [83.166.137.20]) by menubar.gnome.org (Postfix) with ESMTP id 0CC793B0196 for ; Fri, 2 Jun 2006 07:03:20 -0400 (EDT) Received: by nasi-goreng.babi-pangang.org (Postfix, from userid 1000) id 417E73DCA0; Fri, 2 Jun 2006 13:03:18 +0200 (CEST) Date: Fri, 2 Jun 2006 13:03:17 +0200 From: Kristian Rietveld To: Tim Janik Message-ID: <20060602110317.GA10757@babi-pangang.org> References: <20060314132538.GA3526@babi-pangang.org> <443B4A8A.8000302@imendio.com> <20060425103017.GA15762@babi-pangang.org> <20060531183045.GA7564@babi-pangang.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.563 tagged_above=-999 required=2 tests=[AWL=0.036, BAYES_00=-2.599] X-Spam-Score: -2.563 X-Spam-Level: Cc: Gtk+ Developers , Soeren Sandmann Subject: Re: Callback based tooltips (Re: New tooltips API, continued) X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 11:03:22 -0000 On Thu, Jun 01, 2006 at 05:16:51PM +0200, Tim Janik wrote: > On Wed, 31 May 2006, Kristian Rietveld wrote: > > >On Tue, Apr 25, 2006 at 03:08:12PM +0200, Soeren Sandmann wrote: > >>I once wrote down how tooltips should behave: > > > >I mostly like the behaviour you described below. > > > >> - Tooltips are too intrusive. The text should be smaller, and > > not sure if this has been raised already... > the font size of the tooltips should be exactly as large as the default > font size (module tooltip markup of course) to avoid reducing usability > of the tooltips in contrast to normal text (labels). The text for default/simple tooltips using toolip-markup are drawn using the default GTK+ font at this point. FireFox does this too, it seems. -kris. From lists@nabble.com Fri Jun 2 07:11:06 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 15ADC3B10CE for ; Fri, 2 Jun 2006 07:11:06 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20935-09 for ; Fri, 2 Jun 2006 07:11:04 -0400 (EDT) Received: from talk.nabble.com (www.nabble.com [72.21.53.35]) by menubar.gnome.org (Postfix) with ESMTP id 7B8A53B0E85 for ; Fri, 2 Jun 2006 07:11:04 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=talk.nabble.com) by talk.nabble.com with esmtp (Exim 4.50) id 1Fm7YV-00067i-S9 for gtk-devel-list@gnome.org; Fri, 02 Jun 2006 04:11:03 -0700 Message-ID: <4677819.post@talk.nabble.com> Date: Fri, 2 Jun 2006 04:11:03 -0700 (PDT) From: heavenscape To: gtk-devel-list@gnome.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-Sender: masonduan1@sina.com X-Nabble-From: heavenscape X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.564 tagged_above=-999 required=2 tests=[AWL=0.037, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.564 X-Spam-Level: Subject: strange trouble in displaying a 8bit monochromy grey scale image X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 11:11:06 -0000 I need to display a 8 bit monochromy image with size of 2048x2048 pixels, all the image data are already loaded into memory, and out of which I created a 24 bit RGB buffer for the GdkPixbuf (please see code below) Well, the result is: The GtkImage widget was expanded to size of 2048x2048 pixels, THREE exactly same images tile in a row in the top of the GtkImage widget, each with size shrinked to 684x684 pixels, and all the lower 2/3 space is left blank.(see the attached image below) Can anyone please look at my code and give me some suggestion on this problem? I have been debugging is problem for almost one week time! Or I wonder if there is any other alternative mean to display a grey scale monochromy image. Any help is highly appriciated! following is my code: ...... char* pDisplayBuf = malloc(sizeX*sizeY*3); for(i=0;i X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 129D43B0401 for ; Fri, 2 Jun 2006 07:42:43 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22729-02 for ; Fri, 2 Jun 2006 07:42:41 -0400 (EDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.204]) by menubar.gnome.org (Postfix) with ESMTP id AACEB3B03DC for ; Fri, 2 Jun 2006 07:42:41 -0400 (EDT) Received: by wx-out-0102.google.com with SMTP id i30so488730wxd for ; Fri, 02 Jun 2006 04:42:41 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=gT1j5ejSD/b/CcxQn0QQsSvUHhFufm/g+0pbZR2i/XzGfNpGoCbQpb21JCQ8031mkn0Ki6u8pLPOMj7RR8l3DAglKtDDYSYHma6DaM5dCPwAcVKD9bRfW3lU8+yvbKvGFEapsCpgbG/Y1Pe5Z3GQWmSp7m88CvcAjjuc1aYqX10= Received: by 10.70.62.1 with SMTP id k1mr2290069wxa; Fri, 02 Jun 2006 04:42:41 -0700 (PDT) Received: by 10.70.96.6 with HTTP; Fri, 2 Jun 2006 04:42:40 -0700 (PDT) Message-ID: <522c6460606020442q5704285jefadb260aa5ceda1@mail.gmail.com> Date: Fri, 2 Jun 2006 12:42:40 +0100 From: "John Cupitt" To: heavenscape In-Reply-To: <4677819.post@talk.nabble.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4677819.post@talk.nabble.com> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.554 tagged_above=-999 required=2 tests=[AWL=0.046, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.554 X-Spam-Level: Cc: gtk-devel-list@gnome.org Subject: Re: strange trouble in displaying a 8bit monochromy grey scale image X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 11:42:43 -0000 On 6/2/06, heavenscape wrote: > char* pDisplayBuf = malloc(sizeX*sizeY*3); > for(i=0;i { > //create a gray scale img in the display buffer > pDisplayBuf[i+1]=pDisplayBuf[i+1]=pDisplayBuf[i+2] = pixel_value; > } This isn't going to work. You're only filling the first third of the memory area. How about (untested): // malloc() can return NULL: you need to test the result // g_malloc() cannot fail char *p = g_malloc(sizeX * sizeY * 3); char *q; int i; // i loops for number of pixels // q loops pointing at each RGB triplet in turn for (q = p, i = 0; i < sizeX * sizeY; i++, q += 3) q[0] = q[1] = q[2] = pixel_value; // or alternatively in this special case memset( p, sizeX * sizeY * 3, pixel_value ) From jcupitt@gmail.com Fri Jun 2 07:44:31 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C18CD3B0402 for ; Fri, 2 Jun 2006 07:44:31 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22729-06 for ; Fri, 2 Jun 2006 07:44:30 -0400 (EDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.202]) by menubar.gnome.org (Postfix) with ESMTP id 8F0073B0413 for ; Fri, 2 Jun 2006 07:44:30 -0400 (EDT) Received: by wx-out-0102.google.com with SMTP id i30so489124wxd for ; Fri, 02 Jun 2006 04:44:29 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=EMOfucJIundQbGeCrVxW4fD6Iz3tUALWFaW8hgWFjuzmGzy3HlOTtgzn8QGVrywRA62j6kzikELTcAJL+GvTNGqGag3vtyJIcBhy5nQKUdv8v5Gm6dzT8SPDVoRKsWY874GU5fTfTuEc6cSK5TYAaWH6Ezj7csUQ73y/uo1NF/8= Received: by 10.70.128.5 with SMTP id a5mr2255574wxd; Fri, 02 Jun 2006 04:44:29 -0700 (PDT) Received: by 10.70.96.6 with HTTP; Fri, 2 Jun 2006 04:44:29 -0700 (PDT) Message-ID: <522c6460606020444q6963f934g8d7b671fb87905b0@mail.gmail.com> Date: Fri, 2 Jun 2006 12:44:29 +0100 From: "John Cupitt" To: heavenscape In-Reply-To: <522c6460606020442q5704285jefadb260aa5ceda1@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4677819.post@talk.nabble.com> <522c6460606020442q5704285jefadb260aa5ceda1@mail.gmail.com> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.555 tagged_above=-999 required=2 tests=[AWL=0.045, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.555 X-Spam-Level: Cc: gtk-devel-list@gnome.org Subject: Re: strange trouble in displaying a 8bit monochromy grey scale image X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 11:44:31 -0000 On 6/2/06, John Cupitt wrote: > memset( p, sizeX * sizeY * 3, pixel_value ) Ahem, of course that should be memset (p, pixel_value, sizeX * sizeY * 3); From cerdiogenes@yahoo.com.br Fri Jun 2 09:09:23 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id BD1CF3B03D8 for ; Fri, 2 Jun 2006 09:09:23 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27976-05 for ; Fri, 2 Jun 2006 09:09:21 -0400 (EDT) Received: from cac-bdc03.unioeste.br (pop3.unioeste.br [200.201.8.21]) by menubar.gnome.org (Postfix) with ESMTP id 8FFCD3B0351 for ; Fri, 2 Jun 2006 09:09:20 -0400 (EDT) Received: from [200.201.81.39] (200.201.81.39 [200.201.81.39]) by cac-bdc03.unioeste.br with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id L71GDA45; Fri, 2 Jun 2006 10:07:46 -0300 From: Carlos Eduardo Rodrigues =?ISO-8859-1?Q?Di=F3genes?= To: =?ISO-8859-1?Q?=D8yvind_Kol=E5s?= In-Reply-To: <7bf6f2dc0606010816q15d512aejc30a6c93bc165e6@mail.gmail.com> References: <1149104973.27709.4.camel@localhost.localdomain> <7bf6f2dc0606010816q15d512aejc30a6c93bc165e6@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Date: Fri, 02 Jun 2006 10:01:52 -0300 Message-Id: <1149253312.4847.21.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.221 tagged_above=-999 required=2 tests=[AWL=0.043, BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.221 X-Spam-Level: Cc: gtk-devel-list@gnome.org Subject: Re: Color space transformations in GTK X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 13:09:23 -0000 On Thu, 2006-06-01 at 17:16 +0200, =D8yvind Kol=E5s wrote: > On 5/31/06, Carlos Eduardo Rodrigues Di=F3genes wrote: > > Hi, > > > > There is any plan to add color spaces conversions in GTK+ (GDK or > > Gdk-Pixbuf)? If the answear is no, why not? >=20 > Pixel format conversions is not a small piece of code and the needed > pixel formats varies from scenario to scenario. Most programs will not > need such a large general infrastructure and the ones that really need > it would probably not be satisfied with a simpler solution. I think that I understand your last argument. And what I really have in mind is a simple solution, more below... >=20 > What functionality is it you miss that you think fits into a GUI > toolkit? (color management is a seperate issue to color space(pixel > format) conversions according to my interpretation of your question). I had to make RGB <-> HSL conversions, because it's more intuitive change some color properties in the HSL color space. I thinked that we could have something like GdkColor for other color spaces and functions to convert between GdkColor and the other color spaces. I think that it will help who want to play with colors in a quick way. I don't find this in any other library, and I thinked that GTK+ could be a good place for this, because it will become easiest to work with other colors representations in GTK+ applications. >=20 > /=D8yvind K. --=20 Carlos Eduardo Rodrigues Di=F3genes Projeto xLupa - http://www.unioeste.br/projetos/xlupa From murrayc@murrayc.com Fri Jun 2 09:28:59 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id A768B3B112B for ; Fri, 2 Jun 2006 09:28:59 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28843-09 for ; Fri, 2 Jun 2006 09:28:58 -0400 (EDT) Received: from webmail1.sd.dreamhost.com (webmail1.sd.dreamhost.com [66.33.201.159]) by menubar.gnome.org (Postfix) with ESMTP id 953E83B111A for ; Fri, 2 Jun 2006 09:28:58 -0400 (EDT) Received: from webmail.murrayc.com (localhost [127.0.0.1]) by webmail1.sd.dreamhost.com (Postfix) with ESMTP id 9A66F2CAF2; Fri, 2 Jun 2006 06:23:41 -0700 (PDT) Received: from 194.138.18.132 (proxying for unknown) (SquirrelMail authenticated user murrayc@murrayc.com) by webmail.murrayc.com with HTTP; Fri, 2 Jun 2006 15:23:41 +0200 (CEST) Message-ID: <1464.194.138.18.132.1149254621.squirrel@webmail.murrayc.com> In-Reply-To: <1149253312.4847.21.camel@localhost.localdomain> References: <1149104973.27709.4.camel@localhost.localdomain> <7bf6f2dc0606010816q15d512aejc30a6c93bc165e6@mail.gmail.com> <1149253312.4847.21.camel@localhost.localdomain> Date: Fri, 2 Jun 2006 15:23:41 +0200 (CEST) From: "Murray Cumming" To: Carlos Eduardo Rodrigues =?iso-8859-1?Q?Di=F3genes?= User-Agent: SquirrelMail/1.4.6 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.481 tagged_above=-999 required=2 tests=[AWL=-0.036, BAYES_00=-2.599, TW_GT=0.077, TW_TK=0.077] X-Spam-Score: -2.481 X-Spam-Level: Cc: gtk-devel-list@gnome.org, =?iso-8859-1?Q?=D8yvind_Kol=E5s?= Subject: Re: Color space transformations in GTK X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 13:28:59 -0000 > On Thu, 2006-06-01 at 17:16 +0200, yvind Kols wrote: >> On 5/31/06, Carlos Eduardo Rodrigues Digenes >> wrote: >> > Hi, >> > >> > There is any plan to add color spaces conversions in GTK+ (GDK or >> > Gdk-Pixbuf)? If the answear is no, why not? >> >> Pixel format conversions is not a small piece of code and the needed >> pixel formats varies from scenario to scenario. Most programs will not >> need such a large general infrastructure and the ones that really need >> it would probably not be satisfied with a simpler solution. > > I think that I understand your last argument. And what I really have in > mind is a simple solution, more below... > >> >> What functionality is it you miss that you think fits into a GUI >> toolkit? (color management is a seperate issue to color space(pixel >> format) conversions according to my interpretation of your question). > > I had to make RGB <-> HSL conversions, because it's more intuitive > change some color properties in the HSL color space. I thinked that we > could have something like GdkColor for other color spaces and functions > to convert between GdkColor and the other color spaces. > > I think that it will help who want to play with colors in a quick way. I > don't find this in any other library, and I thinked that GTK+ could be a > good place for this, because it will become easiest to work with other > colors representations in GTK+ applications. In case it's useful, we have some old undocumented RGB <-> HSL color value conversion code in gtkmm here: http://cvs.gnome.org/viewcvs/gtkmm/gdk/src/color.ccg?view=markup (See set_hsl(), for instance) Murray Cumming murrayc@murrayc.com www.murrayc.com www.openismus.com From timj@gtk.org Fri Jun 2 10:28:42 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 270163B043C for ; Fri, 2 Jun 2006 10:28:42 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32586-01 for ; Fri, 2 Jun 2006 10:28:40 -0400 (EDT) Received: from webmail.hansenet.de (mail04.hansenet.de [213.191.73.12]) by menubar.gnome.org (Postfix) with ESMTP id 4C4283B0272 for ; Fri, 2 Jun 2006 10:28:40 -0400 (EDT) Received: from birnet.org (213.39.189.161) by webmail.hansenet.de (7.2.059) id 447C34F100154F1E; Fri, 2 Jun 2006 16:28:37 +0200 Received: from master.birnet.private (localhost [127.0.0.1]) by birnet.org (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k52ESaZY028846 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 2 Jun 2006 16:28:36 +0200 Received: (from timj@localhost) by master.birnet.private (8.13.4/8.13.4/Submit) id k52ESPMh028844; Fri, 2 Jun 2006 16:28:25 +0200 Date: Fri, 2 Jun 2006 16:28:25 +0200 (CEST) From: Tim Janik X-X-Sender: timj@master.birnet.private To: Stefan Kost In-Reply-To: <1148567274.9054.4.camel@fluffy.local> Message-ID: References: <1148567274.9054.4.camel@fluffy.local> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.442 tagged_above=-999 required=2 tests=[AWL=0.157, BAYES_00=-2.599] X-Spam-Score: -2.442 X-Spam-Level: Cc: Gtk+ Developers Subject: Re: Serialization in libgobject X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 14:28:42 -0000 On Thu, 25 May 2006, Stefan Kost wrote: > Hi Tim, > > thanks for the extensive comments and detailed concerns. Don't you think > it would be good to keep the buzzgilla issue open. Its an enhancement > request after all and there seems to be several people wanting to have > it. well, my concern is that most of them want/think different things about serialization which was the main point of my last email. i.e. if you want to cover beast's serialization need, you already need 2 different serializers. if you then also want to cover GStreamer needs, and maybe properly human digestible config files, you can easily end up with 3 or 4 sets of mutually exclusive requirements. so without precise definition of the usage cases: - the exact required behaviour of a GLib serializer isn't clear; - we'll end up with lots of projects still rolling their own serializer because the glib one doesn't cover their needs; - the serializer will be used in scenarios that it's unplanned and suboptimal for. i'm not saying the technical issues i raised are unsolvable, in fact each one has been adressed in one way or the other in beast's serializers. rather, i'm asking: 1) what exactly do we want in glib? (i.e. which use cases should be covered) 2) which use cases should be rejected by the glib implementation(s)? 3) do the answers to (1) and (2) really cover a broad range of serialization applications out there? and i think one of the best way to be sure and positively answer (3) could be the independent development of a serialization lib outside of glib. such a library could be included into glib at a later point, once its mature enough and has an adequate track record of applications. > The bugzilla issue could serve as a tracker item. And now maybe some > more people know about thsi and add their thoughts and ideas. if you still think this should be tracked in glib bugzilla as an enhancement, you can always reopen the report. > @Andrew: is you implementation public? If so where can I find the > sources, if not can you make the serialisation part public? > > Maybe we can find a SoC student for the next summer to look at the > solutions used in our application as come up with a good proposal that > suites most apps. > > Stefan > --- ciaoTJ From timj@gtk.org Fri Jun 2 12:59:30 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id AFEC23B0140 for ; Fri, 2 Jun 2006 12:59:30 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09573-08 for ; Fri, 2 Jun 2006 12:59:29 -0400 (EDT) Received: from webmail.hansenet.de (mail01.hansenet.de [213.191.73.61]) by menubar.gnome.org (Postfix) with ESMTP id 53B8C3B00A5 for ; Fri, 2 Jun 2006 12:59:29 -0400 (EDT) Received: from birnet.org (213.39.189.161) by webmail.hansenet.de (7.2.059) id 447D3FB2000A3052; Fri, 2 Jun 2006 18:59:16 +0200 Received: from master.birnet.private (localhost [127.0.0.1]) by birnet.org (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k52GxEAY001423 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 2 Jun 2006 18:59:14 +0200 Received: (from timj@localhost) by master.birnet.private (8.13.4/8.13.4/Submit) id k52GxETr001415; Fri, 2 Jun 2006 18:59:14 +0200 Date: Fri, 2 Jun 2006 18:59:13 +0200 (CEST) From: Tim Janik X-X-Sender: timj@master.birnet.private To: Owen Taylor Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.445 tagged_above=-999 required=2 tests=[AWL=0.154, BAYES_00=-2.599] X-Spam-Score: -2.445 X-Spam-Level: Cc: Gtk+ Developers Subject: locking around source_funcs->finalize X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 16:59:30 -0000 hi Owen. reading up on g_source_unref() again, i notice that the GMainContext lock is removed and re-acquired around callback_funcs->unref(), but not around source_funcs->finalize(); supposing you're unlocking around unref() so that the handler may do things like adding a new idle handler to the context, shouldnt the same semantics be provided for source_funcs->finalize() as well? > static void > g_source_unref_internal (GSource *source, > GMainContext *context, > gboolean have_lock) > { > gpointer old_cb_data = NULL; > GSourceCallbackFuncs *old_cb_funcs = NULL; > > g_return_if_fail (source != NULL); > > if (!have_lock && context) > LOCK_CONTEXT (context); > > source->ref_count--; > if (source->ref_count == 0) > { > old_cb_data = source->callback_data; > old_cb_funcs = source->callback_funcs; > > source->callback_data = NULL; > source->callback_funcs = NULL; > > if (context && !SOURCE_DESTROYED (source)) > { > g_warning (G_STRLOC ": ref_count == 0, but source is still attached to a context!"); > source->ref_count++; > } > else if (context) > g_source_list_remove (source, context); > > if (source->source_funcs->finalize) > source->source_funcs->finalize (source); lock is being held if have_lock || context. > > g_slist_free (source->poll_fds); > source->poll_fds = NULL; > g_free (source); > } > > if (!have_lock && context) > UNLOCK_CONTEXT (context); > > if (old_cb_funcs) > { > if (have_lock) > UNLOCK_CONTEXT (context); > > old_cb_funcs->unref (old_cb_data); no lock is being held. > > if (have_lock) > LOCK_CONTEXT (context); > } > } --- ciaoTJ From matthias.clasen@gmail.com Fri Jun 2 13:14:22 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 181063B0178 for ; Fri, 2 Jun 2006 13:14:22 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10341-10 for ; Fri, 2 Jun 2006 13:14:21 -0400 (EDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.188]) by menubar.gnome.org (Postfix) with ESMTP id A84F33B0115 for ; Fri, 2 Jun 2006 13:14:20 -0400 (EDT) Received: by nf-out-0910.google.com with SMTP id l37so1131753nfc for ; Fri, 02 Jun 2006 10:14:19 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=IIiw0EjBJce9nDArNbjwYFffpCUCNPuYeqI8uOIN+ycf/KtiNjAY9VtWweGXWApORefDRcNkzdsGRROn1FJvCDC494mL9vZcz0WpDA5tNFO1IZSXHXsfZPz+YqQUJ6orpi6MA7hmCcT7pTYK8vEfd8Pic7cApyoegcqYqJXL1U8= Received: by 10.49.1.9 with SMTP id d9mr941927nfi; Fri, 02 Jun 2006 10:14:19 -0700 (PDT) Received: by 10.48.215.7 with HTTP; Fri, 2 Jun 2006 10:14:19 -0700 (PDT) Message-ID: Date: Fri, 2 Jun 2006 13:14:19 -0400 From: "Matthias Clasen" To: "Tim Janik" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.699 tagged_above=-999 required=2 tests=[AWL=-0.734, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.558, SPF_PASS=-0.001, TW_GT=0.077] X-Spam-Score: -1.699 X-Spam-Level: Cc: Owen Taylor , Gtk+ Developers Subject: Re: locking around source_funcs->finalize X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 17:14:22 -0000 On 6/2/06, Tim Janik wrote: > hi Owen. > > reading up on g_source_unref() again, i notice that the > GMainContext lock is removed and re-acquired around > callback_funcs->unref(), but not around source_funcs->finalize(); > supposing you're unlocking around unref() so that the > handler may do things like adding a new idle handler > to the context, shouldnt the same semantics be provided > for source_funcs->finalize() as well? > Interesting observation Tim. We actually ran into a deadlock in the gtk print module code where a source finalize function was trying to add another idle... So fixing this would help GTK+; it would allow us to unload the print backends. Matthias From matthias.clasen@gmail.com Fri Jun 2 13:22:11 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id B05EA3B01BA for ; Fri, 2 Jun 2006 13:22:11 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10854-10 for ; Fri, 2 Jun 2006 13:22:10 -0400 (EDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.186]) by menubar.gnome.org (Postfix) with ESMTP id 691F63B007B for ; Fri, 2 Jun 2006 13:22:10 -0400 (EDT) Received: by nf-out-0910.google.com with SMTP id l37so1137364nfc for ; Fri, 02 Jun 2006 10:22:09 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=WQtzpP4N8ZyKSiiDfpj/VtLI/AxhPsWp029H1Nvd+SG7mq6Rf64PWWm4vH8TCDmIyieOgUdMr0+Y64igzWX+Liq5FKe/p14IvHTVc7Jf8A3g/lkQrbeGGqzHTAEGhQsu+lwlvRhqNYJVH8XXuOcmjrJxkEXrBrcqWzQyQ9CuNTg= Received: by 10.48.14.19 with SMTP id 19mr950281nfn; Fri, 02 Jun 2006 10:22:09 -0700 (PDT) Received: by 10.48.215.7 with HTTP; Fri, 2 Jun 2006 10:22:09 -0700 (PDT) Message-ID: Date: Fri, 2 Jun 2006 13:22:09 -0400 From: "Matthias Clasen" To: "Petr Tomasek" In-Reply-To: <20060602070042.GA3470@ebed.etf.cuni.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1149203639.27455.9.camel@localhost.localdomain> <20060602070042.GA3470@ebed.etf.cuni.cz> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.733 tagged_above=-999 required=2 tests=[AWL=-0.691, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.558, SPF_PASS=-0.001] X-Spam-Score: -1.733 X-Spam-Level: Cc: gtk-devel-list@gnome.org Subject: Re: Print preview api X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 17:22:11 -0000 On 6/2/06, Petr Tomasek wrote: > On Thu, Jun 01, 2006 at 07:13:59PM -0400, Matthias Clasen wrote: > > Ok, after a lot of work (mostly by John and Alex), > > we finally have a proposal for a print preview > > api that will allow us to use an external viewer > > by default, but also support internal preview. > > Hi! > > I think, this is very unfortunate. Many people will > not want to use the external viewer (for reasons discused > earlier), so everyone will write his own preview > widget? Why not just have official internal > preview widget like gnome-print has and support > it by deafult? You are more than welcome to on a high-quality print preview widget and propse it for inclusion; it is a considerable amount of work though (duplicating things that are already in evince), and we are not going to hold the 2.10 release for it. Defaulting to external preview allows us to release 2.10 with preview support, which seems better than no preview support at all. In other news, Alex has just committed the preview patch with some fixes. Matthias From kris@babi-pangang.org Fri Jun 2 19:04:03 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 6F8D73B051E for ; Fri, 2 Jun 2006 19:04:03 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29568-08 for ; Fri, 2 Jun 2006 19:04:02 -0400 (EDT) Received: from nasi-goreng.babi-pangang.org (nasi-goreng.babi-pangang.org [83.166.137.20]) by menubar.gnome.org (Postfix) with ESMTP id 2B5243B04C8 for ; Fri, 2 Jun 2006 19:04:01 -0400 (EDT) Received: by nasi-goreng.babi-pangang.org (Postfix, from userid 1000) id BC1643DCA0; Sat, 3 Jun 2006 01:03:59 +0200 (CEST) Date: Sat, 3 Jun 2006 01:03:59 +0200 From: Kristian Rietveld To: Matthias Clasen Message-ID: <20060602230359.GB10757@babi-pangang.org> References: <20060531200823.GA7846@babi-pangang.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.525 tagged_above=-999 required=2 tests=[AWL=-0.003, BAYES_00=-2.599, TW_GT=0.077] X-Spam-Score: -2.525 X-Spam-Level: Cc: gtk-devel-list@gnome.org, timj@imendio.com Subject: Re: Tooltips progress X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 23:04:03 -0000 On Thu, Jun 01, 2006 at 09:33:48AM -0400, Matthias Clasen wrote: > Using x == -1 to indicate a keyboard-triggered tooltip looks a bit > odd to me; how about adding a boolean parameter for this ? Good idea, fixed this. > Regarding dedicated treeview api, I think we can do without it > (at least initially), if we have a good example in the docs. Though > lots of people will forget the selection_changed thing for keyboard > tooltips... I'll make sure some nice example code will appear in gtk-demo, where we can point people at. > Could you enhance your demo with an example of text view > tooltips on a tag ? Will do. -kris. From kris@babi-pangang.org Fri Jun 2 19:08:42 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 1CF883B11C6 for ; Fri, 2 Jun 2006 19:08:42 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29930-06 for ; Fri, 2 Jun 2006 19:08:40 -0400 (EDT) Received: from nasi-goreng.babi-pangang.org (nasi-goreng.babi-pangang.org [83.166.137.20]) by menubar.gnome.org (Postfix) with ESMTP id 89C933B11CD for ; Fri, 2 Jun 2006 19:08:40 -0400 (EDT) Received: by nasi-goreng.babi-pangang.org (Postfix, from userid 1000) id 411F73DCA0; Sat, 3 Jun 2006 01:08:37 +0200 (CEST) Date: Sat, 3 Jun 2006 01:08:37 +0200 From: Kristian Rietveld To: Tim Janik Message-ID: <20060602230837.GC10757@babi-pangang.org> References: <20060531200823.GA7846@babi-pangang.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.563 tagged_above=-999 required=2 tests=[AWL=0.036, BAYES_00=-2.599] X-Spam-Score: -2.563 X-Spam-Level: Cc: Gtk+ Developers Subject: Re: Tooltips progress X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 23:08:42 -0000 On Thu, Jun 01, 2006 at 06:21:29PM +0200, Tim Janik wrote: > On Thu, 1 Jun 2006, Matthias Clasen wrote: > the idea behind ::has-tooltip is to reduce the number of required signal > emissions to figure a tooltip. e.g. by adding a PRIVATE_GTK_* flag that > indicates if the ::query-tooltips() emission is neccessary. > maybe it'd helpt to rename that property to ::can-tooltip? Or maybe ::enable-query-tooltip? > (if you want to argue consistency with other things settable/gettable > on widgets though, then yes, you have a point for also exporting it > as a property) I would tend to add the property just for consistency. > >The example doesn't show tooltips constructed using the old tooltips > >api, but I assume those will continue to work as before, right ? > > that was the plan, i.e. you'd basically just do: I am not 100% if we can implement the complete old API using the new one, for example the public fields in the old structures and GtkTipsQuery come to mind ... I'll investigate once I get a first patch out. -kris. From exe522@hotmail.com Mon Jun 5 10:30:49 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id E7BDF3B0420 for ; Mon, 5 Jun 2006 10:30:48 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06214-09 for ; Mon, 5 Jun 2006 10:30:45 -0400 (EDT) Received: from hotmail.com (bay104-f19.bay104.hotmail.com [65.54.175.29]) by menubar.gnome.org (Postfix) with ESMTP id 81AC13B030D for ; Mon, 5 Jun 2006 10:30:44 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 5 Jun 2006 07:30:43 -0700 Message-ID: Received: from 65.54.175.200 by by104fd.bay104.hotmail.msn.com with HTTP; Mon, 05 Jun 2006 14:30:41 GMT X-Originating-IP: [83.202.13.252] X-Originating-Email: [exe522@hotmail.com] X-Sender: exe522@hotmail.com In-Reply-To: <44747D3E.8020902@imendio.com> From: "Malik NakaMura" To: richard@imendio.com Date: Mon, 05 Jun 2006 14:30:41 +0000 Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed X-OriginalArrivalTime: 05 Jun 2006 14:30:43.0753 (UTC) FILETIME=[A0A49190:01C688AC] X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-0.739 tagged_above=-999 required=2 tests=[AWL=-1.535, BAYES_05=-1.11, DNS_FROM_RFC_ABUSE=0.2, DNS_FROM_RFC_POST=1.708, MSGID_FROM_MTA_HEADER=0, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -0.739 X-Spam-Level: Cc: otaylor@redhat.com, ben2004uk@googlemail.com, scott@asofyet.org, gtk-devel-list@gnome.org Subject: Re: GTK+ >> Cocoa Native Port X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2006 14:30:49 -0000 Hi, I'm trying to implement this function : _gdk_quartz_copy_to_image (gdkimage-quartz.c) I would like to know if it is possible to get the pixels table from a GdkPixmap structure ? this is the code : GdkImage * _gdk_quartz_copy_to_image (GdkDrawable *drawable, GdkImage *image, gint src_x, gint src_y, gint dest_x, gint dest_y, gint width, gint height) { /* FIXME: Implement */ // Image Creation image = g_object_new (gdk_image_get_type (), NULL); image->width = width; image->height = height; image->byte_order = (G_BYTE_ORDER == G_LITTLE_ENDIAN) ? GDK_LSB_FIRST : GDK_MSB_FIRST; image->bpp = 4; image->bpl = image->width * image->bpp; image->bits_per_pixel = image->bpp * 8; // Get the Visual GdkColormap *colormap = gdk_drawable_get_colormap (drawable); if(colormap != NULL) { image->visual = gdk_colormap_get_visual (colormap); } // Get the depth image->depth = GDK_PIXMAP_OBJECT (drawable)->depth; // Get the pixels ??? image->mem = g_malloc (image->bpl * image->height); memset (image->mem, 0x00, image->bpl * image->height); image->mem = gdk_pixbuf_get_pixels (GDK_PIXBUF (drawable)); return image; } I think that drawable is a GdkPixmap structure, so I cant do GDK_PIXBUF (drawable), but is there a function to get the pixbuf from a pixmap ? From domlachowicz@gmail.com Mon Jun 5 10:52:51 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id B05E13B0543 for ; Mon, 5 Jun 2006 10:52:51 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08008-05 for ; Mon, 5 Jun 2006 10:52:48 -0400 (EDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.205]) by menubar.gnome.org (Postfix) with ESMTP id 0DD8B3B03E7 for ; Mon, 5 Jun 2006 10:52:47 -0400 (EDT) Received: by wx-out-0102.google.com with SMTP id i30so1182797wxd for ; Mon, 05 Jun 2006 07:52:47 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=mBHtGZClxJk0twUjUBnjIyhM/WAD6Uo9my7i+D5hoC4J+tCoUbUHFxNQxrI4rHUN+ozS7wnRgFO+uMkkEg6Pg2xZje4D8Xja5Bt7lmKFvCh6pSZMS6uV+5TpBquvMmVoaoFkNDoZEDJjdLqt3Wj9IaLQ/ggRMyfDTkEaz5x0TcU= Received: by 10.70.49.6 with SMTP id w6mr6127550wxw; Mon, 05 Jun 2006 07:52:44 -0700 (PDT) Received: by 10.70.116.12 with HTTP; Mon, 5 Jun 2006 07:52:44 -0700 (PDT) Message-ID: <2672cf4d0606050752o12a6d0d2gcb4c355cc0f35d79@mail.gmail.com> Date: Mon, 5 Jun 2006 10:52:44 -0400 From: "Dominic Lachowicz" To: "Malik NakaMura" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <44747D3E.8020902@imendio.com> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.457 tagged_above=-999 required=2 tests=[AWL=0.143, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.457 X-Spam-Level: Cc: gtk-devel-list@gnome.org Subject: Re: GTK+ >> Cocoa Native Port X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2006 14:52:51 -0000 > I think that drawable is a GdkPixmap structure, so I cant do GDK_PIXBUF > (drawable), but is there a function to get the pixbuf from a pixmap ? You might want to look at gdk_pixbuf_get_from_drawable(). Best, Dom -- Counting bodies like sheep to the rhythm of the war drums. From mclasen@redhat.com Mon Jun 5 14:15:03 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 744343B09D3; Mon, 5 Jun 2006 14:15:03 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20278-06; Mon, 5 Jun 2006 14:15:01 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id D637E3B0988; Mon, 5 Jun 2006 14:15:00 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k55IF08I024331; Mon, 5 Jun 2006 14:15:00 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k55IF0I9021827; Mon, 5 Jun 2006 14:15:00 -0400 Received: from golem.boston.redhat.com (golem.boston.redhat.com [172.16.80.24]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id k55IExAV012588; Mon, 5 Jun 2006 14:14:59 -0400 From: Matthias Clasen To: gnome-announce-list@gnome.org, gtk-devel-list@gnome.org, gtk-app-devel-list@gnome.org, gtk-list@gnome.org Content-Type: text/plain; charset=UTF-8 Date: Mon, 05 Jun 2006 14:14:59 -0400 Message-Id: <1149531299.4071.35.camel@golem.boston.redhat.com> Mime-Version: 1.0 X-Mailer: Evolution 2.7.1 (2.7.1-1) Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.543 tagged_above=-999 required=2 tests=[AWL=0.058, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.543 X-Spam-Level: Cc: Subject: GLib 2.11.2 released X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gnome-hackers@gnome.org List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2006 18:15:03 -0000 GLib 2.11.2 is now available for download at: ftp://ftp.gtk.org/pub/gtk/v2.11/ http://ftp.gnome.org/pub/GNOME/sources/glib/2.11/ glib-2.11.2.tar.bz2 md5sum: 18464b85bfd589f83897623c637a1553 glib-2.11.2.tar.gz md5sum: f728cd295ac98d4b95d850fe91c05fd5 This is a development release leading up to GLib 2.12. Notes: * This is unstable development release. While it has had a bit of testing, there are certainly plenty of bugs remaining to be found. This release should not be used in production. * Installing this version will overwrite your existing copy of GLib 2.10. If you have problems, you'll need to reinstall GLib 2.10. * GLib 2.12 will be source and binary compatible with the GLib 2.10.x series (for some caveats, see the README). At this point, the API additions in the 2.11.x series are almost finished. * Bugs should be reported to http://bugzilla.gnome.org. About GLib ========== GLib is the low-level core library that forms the basis for projects such as GTK+ and GNOME. It provides data structure handling for C, portability wrappers, and interfaces for such runtime functionality as an event loop, threads, dynamic loading, and an object system. More information about GLib is available at: http://www.gtk.org/ An installation guide for the GTK+ libraries, including GLib, can be found at: http://developer.gnome.org/doc/API/2.0/gtk/gtk-building.html Overview of Changes from GLib 2.11.1 to GLib 2.11.2 =================================================== * Add g_ascii_stroll to parse signed 64bit integers * GMarkup: add a flag to treat CDATA as text * GHashTable: add functions to remove all entries * GMainLoop: add functions to find the currently running source, and determine if it is destroyed * Bug fixes: 342563 g_atomic_thread_init() needs to be called before other _g_*_thread_init() functions 343548 Potential use after free in callers of g_string_free() 168538 Wish: Clearing contents of GHashTables 321886 GTK+ cannot be reliably used in multi-threaded applications 341826 goption.c: 'strtoll' is C99's function 343899 g_ascii_formatd dosn't work as expected for all format strings 317793 Make GEnumValue strings const 337129 Compile warnings in G_IMPLEMENT_INTERFACE 303622 What is G_TYPE_CHAR? * Updated translations (bg,dz,eu,gl,ja,nl,th,vi) A list of all bugs fixed in this release can be found at: http://bugzilla.gnome.org/buglist.cgi?bug_id=341826,342563,343548,168538,168538,321886,343899,321886,317793,337129,303622 Thanks to everybody who has contributed to this release, in the form of bug reports or patches: Peter Kjellerstedt, Kazuki Iwamoto Leonard den Ottolander, Chris Wilson, Behdad Esfahbod, Matt Barnes, ystein Johansen, Tim Janik Morten Welinder Matthias Clasen June 5, 2006 From mclasen@redhat.com Mon Jun 5 16:21:34 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 09B113B0543; Mon, 5 Jun 2006 16:21:34 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28553-01; Mon, 5 Jun 2006 16:21:32 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id 0F8903B0012; Mon, 5 Jun 2006 16:21:31 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k55KLVn7006951; Mon, 5 Jun 2006 16:21:31 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k55KLUBq020469; Mon, 5 Jun 2006 16:21:31 -0400 Received: from golem.boston.redhat.com (golem.boston.redhat.com [172.16.80.24]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id k55KLUAV025318; Mon, 5 Jun 2006 16:21:30 -0400 From: Matthias Clasen To: gnome-announce-list@gnome.org, gtk-devel-list@gnome.org, gtk-app-devel-list@gnome.org, gtk-list@gnome.org Content-Type: text/plain Date: Mon, 05 Jun 2006 16:21:30 -0400 Message-Id: <1149538890.4071.40.camel@golem.boston.redhat.com> Mime-Version: 1.0 X-Mailer: Evolution 2.7.1 (2.7.1-1) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.429 tagged_above=-999 required=2 tests=[AWL=-0.059, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, TW_GD=0.077, TW_GT=0.077, TW_XI=0.077] X-Spam-Score: -2.429 X-Spam-Level: Cc: Subject: GTK+ 2.9.2 released X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gnome-hackers@gnome.org List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2006 20:21:34 -0000 GTK+ 2.9.2 is now available for download at: http://ftp.gnome.org/pub/gnome/sources/gtk+/2.9/ gtk+-2.9.2.tar.gz md5sum: c63e7d0cf7c4e983206c3088a0fb8862 gtk+-2.9.2.tar.bz2 md5sum: 17629437af44fce03485101371c8f041 This is a development release leading up to GTK+ 2.10. Notes: * This is unstable development release. There are certainly plenty of bugs remaining to be found. This release should not be used in production. * Installing this version will overwrite your existing copy of GTK+ 2.8. If you have problems, you'll need to reinstall GTK+ 2.8. * GTK+ 2.10 will be source compatible with the GTK+ 2.8 series; the new API additions in GTK+ 2.9.0 are not yet completely finalized, so there are likely incompatibilies between this release and the final 2.10 release. * The ABI version has been bumped from 2.4.0 to 2.10.0, since the filechooser backend interface has been changed. Third-party filechooser backends need to be ported to the new interface. Other third-party modules (input methods, image loaders, etc) just need to be reinstalled in the proper location for GTK+ to find them. * Remaining issues for GTK+ 2.10 can be found with following bugzilla query: http://bugzilla.gnome.org/buglist.cgi?product=gtk%2b&target_milestone=2.10+API+Freeze&target_milestone=2.10+Freeze&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED * Bugs should be reported to http://bugzilla.gnome.org. What is GTK+ ============ GTK+ is a multi-platform toolkit for creating graphical user interfaces. Offering a complete set of widgets, GTK+ is suitable for projects ranging from small one-off tools to complete application suites. GTK+ has been designed from the ground up to support a range of languages, not only C/C++. Using GTK+ from languages such as Perl and Python (especially in combination with the Glade GUI builder) provides an effective method of rapid application development. GTK+ is free software and part of the GNU Project. However, the licensing terms for GTK+, the GNU LGPL, allow it to be used by all developers, including those developing proprietary software, without any license fees or royalties. Where to get more information about GTK+ ======================================== Information about GTK+ including links to documentation can be found at: http://www.gtk.org/ An installation guide for GTK+ 2.x is found at: http://developer.gnome.org/doc/API/2.4/gtk/gtk-building.html Common questions: http://developer.gnome.org/doc/API/2.4/gtk/gtk-question-index.html http://www.gtk.org/faq/ Overview of Changes from GTK+ 2.9.1 to 2.9.2 ============================================ * GtkPrintOperation - Support asynchronous pagination with the ::paginate signal - Add gtk_print_operation_cancel - Support application-specific widgets - Allow disabling features based on application capabilities - Optionally show progress - Change some function names in GtkPrintContext to be longer and better - Support preview, the default implementation spawns evince, but the api allows for an internal preview implementation * GtkCellView - Add a model property * GtkStatusIcon - Allow to obtain screen geometry * GtkTreeView - Many bug fixes, in particular for RTL handling - Separate sensitive and selectable properties of rows - Optionally allow rubberband selection * GtkButton - Add image-spacing style property - Add image-position property * GtkToolButton - Add icon-spacing style property * Make GTK+ work as an untrused X client * Bugs fixed: 343838 gtkprintoperationpreview.h guards 305530 Crashes while creating source code w/GtkFontSelection 341327 Memory corruption inside glib 341734 cursor blocked to dnd mode after using shift and dnd on a GtkCalendar 343453 G_DEFINE_TYPE messes up internal typenames of GdkWindow and GdkPixmap 136571 Problems running as untrusted client 168105 the right edge tab does not appear when switching tab 172535 Add support for UI builders in gtk+ 302556 GtkTreeView widget signals are badly documented 324480 Selecting first item with keyboard is difficult 340428 small cleanup 340444 don't run the custom page size dialogue 340839 Critical warnings in GtkTreeModelFilter 341898 gtk_tree_view_insert_column_with_attributes doesn't work with fixed_height_mode 342003 DnD: Conditional jump or move depends on uninitialised value 342072 Wrong drop location in GtkEntry 342096 GtkImage animation CRITICALS on switching themes 342513 widget class style property with type module 342529 gdk should set resolution on PangoCairoFontmap, not PangoCairoContext 342535 Add documentation for new GtkWidget style properties (including Since tags) 342543 can't compile gtk+ on opensolaris using sun cc 342569 Typo in decl of gdk_color_parse 342752 Need a way to specify custom tab label for custom page in Print dialog 342754 print-editor: font button dialog doesn't get focus if main window has a window group 342781 GtkPrintUnixDialog: Collate should be insensitive unless Copies is > 1 342783 GtkPrintUnixDialog: Range textinput area should be insensitive unless range radiobutton is selected 342894 Use after free inside gtk_text_view_set_buffer 342930 GtkButton should offer a way to position the image relative to the text 343088 Some typos in the PO file 343425 "grab-notify"-signal is not correctly propagated for internal children 343438 gtk_color_button_set_color() doesn't emit "color-set" signal 343475 page setup unix dialog confusion 343625 allow to get only some info from gtk_status_icon_get_geometry 343677 GtkWindow chains key-release to key-press 320431 Text too close when using East/West in a GtkToolButton 321523 GtkTreeView's test_expand_row signal emitting impractical on row expand all 342007 Warning in gtk_paned_compute_position 343233 gdk_rectangle_intersect doc 333284 expander animation not working in RTL mode 343444 change color of gtk-demo source-buffer comment color from red to DodgerBlue 343630 Small inconsistence in migration documentation 80127 Rubberbanding for GtkTreeView 341450 status icon + libnotify 341679 Allow absolute filenames in the options entries * Updated translations (bg,cy,de,el,es,et,eu,gl,gu,it,ja, nb,nl,pt_BR,th,vi) Thanks to everybody who has contributed to this release, in the form of bug reports or patches: Alexander Larsson, Behdad Esfahbod, Benjamin Berg, Caolan McNamara, Carlos Garnacho Parro, Carol Spears, Christian Persch, Chris Wilson, Claudio Saavedra, Clytie Siddall, Damon Chaplin, Daniel Lindenaar, Dan Winship, Diana Fong, Ed Catmur, Emmanuele Bassi, Havoc Pennington, Henrique Romano, Hiroyuki Ikezoe, James Moger, Johan Dahlin, Kouhei Sutou, Kristian Rietveld, Markku Vire, Mart Raudsepp, Masatake Yamato, Michael Emmel, Michael Natterer, Murray Cumming, Olexiy Avramchenko, Paolo Borelli, Patrick Monnerat, Richard Hult, Sampo Savolainen, Sebastien Bacher, Srirama Sharma, Stefan Kost, Tim Janik, Tommi Komulainen, Tor Lillqvist, Yevgen Muntyan A list of all bugs fixed in this release can be found at: http://bugzilla.gnome.org/buglist.cgi?bug_id=342072,342096,342003,341734,305530,168105,342007,342529,342535,342543,342569,341679,342752,172535,342513,342781,342783,342754,136571,341450,333284,340428,340839,341898,321523,343088,343233,324480,342894,320431,342930,343453,343425,343438,343444,340444,343475,302556,343677,343625,80127,343838,341327,168105,343630 Matthias Clasen June 5, 2006 From otaylor@redhat.com Mon Jun 5 18:10:18 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 606843B039F for ; Mon, 5 Jun 2006 18:10:18 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03967-08 for ; Mon, 5 Jun 2006 18:10:17 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id CAF5C3B0389 for ; Mon, 5 Jun 2006 18:10:16 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k55MAGwn013331; Mon, 5 Jun 2006 18:10:16 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k55MAGNr013297; Mon, 5 Jun 2006 18:10:16 -0400 Received: from localhost.localdomain (sebastian-int.corp.redhat.com [172.16.52.221]) by devserv.devel.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k55MAFJC021457; Mon, 5 Jun 2006 18:10:15 -0400 From: Owen Taylor In-Reply-To: <2672cf4d0606050752o12a6d0d2gcb4c355cc0f35d79@mail.gmail.com> References: <44747D3E.8020902@imendio.com> <2672cf4d0606050752o12a6d0d2gcb4c355cc0f35d79@mail.gmail.com> Content-Type: text/plain Date: Mon, 05 Jun 2006 15:10:09 -0400 Message-Id: <1149534609.2441.107.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 (2.6.1-1.fc5.2) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.187 tagged_above=-999 required=2 tests=[AWL=-0.199, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.478, FORGED_RCVD_HELO=0.135, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.187 X-Spam-Level: Cc: gtk-devel-list@gnome.org Subject: Re: GTK+ >> Cocoa Native Port X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2006 22:10:18 -0000 On Mon, 2006-06-05 at 10:52 -0400, Dominic Lachowicz wrote: > > I think that drawable is a GdkPixmap structure, so I cant do GDK_PIXBUF > > (drawable), but is there a function to get the pixbuf from a pixmap ? > > You might want to look at gdk_pixbuf_get_from_drawable(). Not going to help here, I think .. copy_to_image() is the backend function used to implement gdk_pixbuf_get_from_drawable(). :-) This is the point in the code where you need to figure out how to copy pixels from a native drawable into an image buffer, which is going to involve native graphics system calls. If you can find docs on how to take a screenshot of a window in OS X, that will be similar code to what is needed here. Owen From rpmcruz@clix.pt Mon Jun 5 21:41:34 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id B9E363B03FB for ; Mon, 5 Jun 2006 21:41:34 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15260-05 for ; Mon, 5 Jun 2006 21:41:33 -0400 (EDT) Received: from mailrly02.isp.novis.pt (mailrly02.isp.novis.pt [195.23.133.212]) by menubar.gnome.org (Postfix) with ESMTP id 84DA33B0076 for ; Mon, 5 Jun 2006 21:41:32 -0400 (EDT) Received: (qmail 21302 invoked from network); 6 Jun 2006 01:41:30 -0000 Received: from unknown (HELO mailfrt04.isp.novis.pt) ([195.23.133.196]) (envelope-sender ) by mailrly02.isp.novis.pt with compressed SMTP; 6 Jun 2006 01:41:30 -0000 Received: (qmail 17342 invoked from network); 6 Jun 2006 01:41:29 -0000 Received: from unknown (HELO [10.0.0.2]) (Sent_by_authenticated_user_x2476431@[87.196.74.232]) (envelope-sender ) by mailfrt04.isp.novis.pt with SMTP; 6 Jun 2006 01:41:29 -0000 From: Ricardo Cruz To: gtk-devel-list@gnome.org Date: Tue, 6 Jun 2006 02:48:21 +0100 User-Agent: KMail/1.9.1 X-Face: $29d{(U~(^/X.rR|7i6syM3jeJ}N+*%U-#Bzl5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200606060248.21205.rpmcruz@clix.pt> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.657 tagged_above=-999 required=2 tests=[AWL=-0.917, BAYES_20=-0.74] X-Spam-Score: -1.657 X-Spam-Level: Subject: GtkComboBoxEntry -- changing entry line value X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2006 01:41:34 -0000 Hi there, Is there a way to set a value for a GtkComboBoxEntry line entry? I am currently just adding an entry, set it as selected and remove it, which is a pretty nasty work-around. By the way, is it planned to add a GtkEditable interface for it? That would be really sweet and, if affirmitive, I could work on making a patch. Cheers, Ricardo -- Fourth Law of Thermodynamics: If the probability of success is not almost one, it is damn near zero. -- David Ellis From markku.vire@kolumbus.fi Tue Jun 6 04:39:15 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 5E3DD3B0C57 for ; Tue, 6 Jun 2006 04:39:15 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23318-01 for ; Tue, 6 Jun 2006 04:39:13 -0400 (EDT) Received: from fep02-app.kolumbus.fi (fep02-0.kolumbus.fi [193.229.0.44]) by menubar.gnome.org (Postfix) with ESMTP id C21BF3B0A19 for ; Tue, 6 Jun 2006 04:37:26 -0400 (EDT) Received: from smtp.kolumbus.fi ([193.229.55.124]) by fep02-app.kolumbus.fi with ESMTP id <20060606083725.NGAZ5174.fep02-app.kolumbus.fi@smtp.kolumbus.fi>; Tue, 6 Jun 2006 11:37:25 +0300 X-Mailer: Openwave WebEngine, version 2.8.12 (webedge20-101-197-20030912) X-Originating-IP: [62.236.91.3] From: To: Ricardo Cruz , Date: Tue, 6 Jun 2006 11:37:24 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <20060606083725.NGAZ5174.fep02-app.kolumbus.fi@smtp.kolumbus.fi> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.504 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, NO_REAL_NAME=0.961, SPF_PASS=-0.001] X-Spam-Score: -1.504 X-Spam-Level: X-Mailman-Approved-At: Tue, 06 Jun 2006 07:05:18 -0400 Cc: Subject: Re: GtkComboBoxEntry -- changing entry line value X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2006 08:39:15 -0000 Hi, You can get the entry by calling gtk_bin_get_child(box); and then using any methods of GtkEntry to manipulate the text. > Is there a way to set a value for a GtkComboBoxEntry line entry? I am > currently just adding an entry, set it as selected and remove it, which is a > pretty nasty work-around. -Markku- From markku.vire@kolumbus.fi Tue Jun 6 04:39:55 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 544743B0B78 for ; Tue, 6 Jun 2006 04:39:55 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23288-09 for ; Tue, 6 Jun 2006 04:39:52 -0400 (EDT) Received: from fep02-app.kolumbus.fi (fep02-0.kolumbus.fi [193.229.0.44]) by menubar.gnome.org (Postfix) with ESMTP id BD56C3B0A19 for ; Tue, 6 Jun 2006 04:39:51 -0400 (EDT) Received: from smtp.kolumbus.fi ([193.229.55.124]) by fep02-app.kolumbus.fi with ESMTP id <20060606083950.NHYK5174.fep02-app.kolumbus.fi@smtp.kolumbus.fi>; Tue, 6 Jun 2006 11:39:50 +0300 X-Mailer: Openwave WebEngine, version 2.8.12 (webedge20-101-197-20030912) X-Originating-IP: [62.236.91.3] From: To: Ricardo Cruz , Date: Tue, 6 Jun 2006 11:39:50 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <20060606083950.NHYK5174.fep02-app.kolumbus.fi@smtp.kolumbus.fi> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.504 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, NO_REAL_NAME=0.961, SPF_PASS=-0.001] X-Spam-Score: -1.504 X-Spam-Level: X-Mailman-Approved-At: Tue, 06 Jun 2006 07:05:18 -0400 Cc: Subject: Re: GtkComboBoxEntry -- changing entry line value X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2006 08:39:55 -0000 Hi, You can get the entry by calling gtk_bin_get_child(box); and then using any methods of GtkEntry to manipulate the text. > Is there a way to set a value for a GtkComboBoxEntry line entry? I am > currently just adding an entry, set it as selected and remove it, which is a > pretty nasty work-around. -Markku- From federico@ximian.com Tue Jun 6 11:45:51 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id A23E83B00FF for ; Tue, 6 Jun 2006 11:45:51 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01904-10 for ; Tue, 6 Jun 2006 11:45:35 -0400 (EDT) Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) by menubar.gnome.org (Postfix) with ESMTP id 6D4083B0ADD for ; Tue, 6 Jun 2006 11:45:33 -0400 (EDT) Received: (qmail 15590 invoked from network); 6 Jun 2006 15:45:31 -0000 Received: from localhost (HELO ?164.99.120.162?) (127.0.0.1) by localhost with SMTP; 6 Jun 2006 15:45:31 -0000 From: Federico Mena Quintero To: GTK+ development mailing list Content-Type: text/plain Date: Tue, 06 Jun 2006 10:41:22 -0500 Message-Id: <1149608483.14088.54.camel@cacharro.xalalinux.org> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.574 tagged_above=-999 required=2 tests=[AWL=0.025, BAYES_00=-2.599] X-Spam-Score: -2.574 X-Spam-Level: Cc: Michael.meeks@novell.com Subject: Default timeouts X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2006 15:45:51 -0000 In gtksettings.c we have #define DEFAULT_TIMEOUT_INITIAL 200 #define DEFAULT_TIMEOUT_REPEAT 20 for the "gtk-timeout-initial" and "gtk-timeout-repeat" settings, respectively. This means we wait for a fifth of a second before we start repeating, but then we try to repeat 50 times per second. Isn't the repeat timeout way too short? This is why clicking on a calendar arrow takes you back tens of months in no time, and also makes it hard to use spin buttons. Also, Michael Meeks has the following words of wisdom in a Novell bug about the calendar in gnome-panel's clock: > In essence the timeout is way too short for switching days; also - > in the panel applet the timeout has a higher priority than the > queued resize of the display (and hence the redraw) - so in > essence we skip days even faster since we never have to render > them. > > Lowering the priority there, and lengthening the timeouts gives > a far more reasonable, usable experience without getting rid > of the whole auto-repeat principle [...] I.e. instead of using g_timeout_add() in gtkcalendar, we would use g_timeout_add_full (G_PRIORITY_DEFAULT_IDLE, ...), or perhaps (GDK_PRIORITY_REDRAW + positive_constant): both are lower priority than GTK_PRIORITY_RESIZE. Federico From michael.meeks@novell.com Tue Jun 6 12:33:58 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 74B9F3B0197 for ; Tue, 6 Jun 2006 12:33:58 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05177-09 for ; Tue, 6 Jun 2006 12:33:57 -0400 (EDT) Received: from gwia-smtp.id2.novell.com (public.id2-vpn.continvity.gns.novell.com [195.33.99.129]) by menubar.gnome.org (Postfix) with ESMTP id 3714E3B014F for ; Tue, 6 Jun 2006 12:33:57 -0400 (EDT) Received: from [192.168.0.8] (l4-client.id2.novell.com [::ffff:149.44.117.251]) by gwia-smtp.id2.novell.com with ESMTP (TLS encrypted); Tue, 06 Jun 2006 17:33:30 +0100 From: Michael Meeks To: Federico Mena Quintero In-Reply-To: <1149608483.14088.54.camel@cacharro.xalalinux.org> References: <1149608483.14088.54.camel@cacharro.xalalinux.org> Content-Type: text/plain Organization: Novell, Inc. Date: Tue, 06 Jun 2006 17:37:54 +0100 Message-Id: <1149611874.2202.2.camel@t60p.site> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.427 tagged_above=-999 required=2 tests=[AWL=-0.028, BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2] X-Spam-Score: -2.427 X-Spam-Level: Cc: GTK+ development mailing list Subject: Re: Default timeouts X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: michael.meeks@novell.com List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2006 16:33:58 -0000 On Tue, 2006-06-06 at 10:41 -0500, Federico Mena Quintero wrote: > > In essence the timeout is way too short for switching days; also - > > in the panel applet the timeout has a higher priority than the > > queued resize of the display (and hence the redraw) - so in > > essence we skip days even faster since we never have to render > > them. Of course - this is particularly applicable for the calendar where it really makes sense to actually see the month rendered each time you switch to a different month or year. Of course with a spin-button I guess throttling the spin rate to that of the refresh rate would (perhaps) be problematic. Then again re-rendering a spin-button is presumably an extremely fast operation. HTH, Michael. -- michael.meeks@novell.com <><, Pseudo Engineer, itinerant idiot From carlosgc@gnome.org Wed Jun 7 07:48:25 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id BACA33B0C6A for ; Wed, 7 Jun 2006 07:48:25 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08136-01 for ; Wed, 7 Jun 2006 07:48:23 -0400 (EDT) Received: from localhost.localdomain (gsyc090.dat.escet.urjc.es [193.147.71.90]) by menubar.gnome.org (Postfix) with ESMTP id D0D083B01EA for ; Wed, 7 Jun 2006 07:48:22 -0400 (EDT) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 945E110F28E for ; Wed, 7 Jun 2006 13:48:19 +0200 (CEST) From: Carlos Garcia Campos To: GTK+ development mailing list Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-hBJf7M2jws0KBkd4rYip" Date: Wed, 07 Jun 2006 13:48:17 +0200 Message-Id: <1149680898.3302.9.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.285 tagged_above=-999 required=2 tests=[AWL=0.179, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.285 X-Spam-Level: Subject: Evince preview mode X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 11:48:25 -0000 --=-hBJf7M2jws0KBkd4rYip Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi,=20 since gtk+ is using evince as an external printing previewer, I'm implementing a preview mode in evince, available through the command line (--preview). It's based on the ephy printing previewer where the menubar is hidden and the toolbar contains navigation items and a close button. Here is an screenshot: http://carlosgc.linups.org/files/evince-preview-mode.png Any other thing expected by a previewer? --=20 Carlos Garcia Campos (KaL) elkalmail@yahoo.es carlosgc@gnome.org http://carlosgc.linups.org PGP key: http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0x523E6462 --=-hBJf7M2jws0KBkd4rYip Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQBEhr0BjxBOalI+ZGIRAmSgAJ9Ksy9L8QqVxpvNQCtbejp/0HRZXACeNcmq O8LT0nzkGzw+qcPFuVqZ3y8= =xZYn -----END PGP SIGNATURE----- --=-hBJf7M2jws0KBkd4rYip-- From hfiguiere@teaser.fr Wed Jun 7 08:28:18 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id AC8923B0CE2; Wed, 7 Jun 2006 08:28:18 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11220-01; Wed, 7 Jun 2006 08:28:15 -0400 (EDT) Received: from xandros.com (smtp1.xandros.com [209.87.238.70]) by menubar.gnome.org (Postfix) with ESMTP id EC3713B0CD7; Wed, 7 Jun 2006 08:28:14 -0400 (EDT) Received: from [172.18.1.132] (toronto-hs-216-138-231-194.s-ip.magma.ca [216.138.231.194]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by xandros.com (Postfix) with ESMTP id E7D80C028; Wed, 7 Jun 2006 08:28:12 -0400 (EDT) Message-ID: <4486C65A.5060800@teaser.fr> Date: Wed, 07 Jun 2006 08:28:10 -0400 From: Hubert Figuiere User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: Carlos Garcia Campos References: <1149680898.3302.9.camel@localhost.localdomain> In-Reply-To: <1149680898.3302.9.camel@localhost.localdomain> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.499 tagged_above=-999 required=2 tests=[AWL=0.100, BAYES_00=-2.599] X-Spam-Score: -2.499 X-Spam-Level: Cc: GTK+ development mailing list Subject: Re: Evince preview mode X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 12:28:19 -0000 Carlos Garcia Campos wrote: > Hi, > > since gtk+ is using evince as an external printing previewer, I'm > implementing a preview mode in evince, available through the command > line (--preview). It's based on the ephy printing previewer where the > menubar is hidden and the toolbar contains navigation items and a close > button. Here is an screenshot: > > http://carlosgc.linups.org/files/evince-preview-mode.png > > Any other thing expected by a previewer? It think it should have a menu bar, even if it is way simplier than Evince, and the button to close in the toolbar should be removed because it is "uncommon" and in fact confuse the user on what to do. Closing the window should be all that needed, or doing a file->close in the menu, Also, zoom in and zoom out are very useful. Hub From paolo.maggi@gmail.com Wed Jun 7 08:15:10 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 9C3E63B08CC for ; Wed, 7 Jun 2006 08:15:10 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10407-05 for ; Wed, 7 Jun 2006 08:15:09 -0400 (EDT) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.172]) by menubar.gnome.org (Postfix) with ESMTP id 8B7343B0303 for ; Wed, 7 Jun 2006 08:15:08 -0400 (EDT) Received: by ug-out-1314.google.com with SMTP id c2so258875ugf for ; Wed, 07 Jun 2006 05:15:07 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:subject:from:to:cc:content-type:date:message-id:mime-version:x-mailer:content-transfer-encoding; b=K90OlbUivfHjc3p7Mf7NxXYQ7dM8ZBxC+0BsgOJcKZJuB7jHCl0ZAGBW4g8105rAzePSP5EyfdcA7LlHJh+VEWxuXvCS7dbrv6RMBVJzQ/vwIPq71eGzz8nn2EwMpB2LP+LFhmJsovQOwZfLUn1MKDz4iRRATWR1zOQleW/WqEg= Received: by 10.67.105.19 with SMTP id h19mr435594ugm; Wed, 07 Jun 2006 05:15:06 -0700 (PDT) Received: from elilix.polito.it ( [130.192.16.224]) by mx.gmail.com with ESMTP id q1sm888781uge.2006.06.07.05.15.05; Wed, 07 Jun 2006 05:15:06 -0700 (PDT) From: Paolo Maggi To: carlosgc@gnome.org Content-Type: text/plain Date: Wed, 07 Jun 2006 14:15:04 +0200 Message-Id: <1149682504.5804.33.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.6 tagged_above=-999 required=2 tests=[AWL=0.000, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.6 X-Spam-Level: X-Mailman-Approved-At: Wed, 07 Jun 2006 09:03:01 -0400 Cc: gtk-devel-list@gnome.org Subject: Re: Evince preview mode X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 12:15:10 -0000 Hi, cia > since gtk+ is using evince as an external printing previewer, I'm > implementing a preview mode in evince, available through the command > line (--preview). It's based on the ephy printing previewer where the > menubar is hidden and the toolbar contains navigation items and a close > button. Here is an screenshot: > > http://carlosgc.linups.org/files/evince-preview-mode.png > > Any other thing expected by a previewer? - Zoom - Direct jump to a given page Please, look also at the gedit 2.14.x print previewer. Probably we also need a way to specify paper orientation on the command line (or is orientation already specified in the PDF file?) Ciao, Paolo From matthias.clasen@gmail.com Wed Jun 7 09:13:05 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id E24273B0D07 for ; Wed, 7 Jun 2006 09:13:04 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14781-07 for ; Wed, 7 Jun 2006 09:13:02 -0400 (EDT) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.202]) by menubar.gnome.org (Postfix) with ESMTP id 00C823B0B41 for ; Wed, 7 Jun 2006 09:13:01 -0400 (EDT) Received: by nz-out-0102.google.com with SMTP id 9so196545nzo for ; Wed, 07 Jun 2006 06:13:01 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=saqMihVje8FYa9UdpyLa1+dlefvQoIGQxKH7/1Zo60aYxymeM8Pd6GyFWAgY0o+p1vKDz7amMyAC6pjntEQBEcP8uj0rJL3yYZX1hequAVkJsd5sQslhyn8T44EZjEA/hsuQz0+1EdqmPuNMRK0Lseu0seEU88n8Ei5Ii1IMFBQ= Received: by 10.37.13.40 with SMTP id q40mr711105nzi; Wed, 07 Jun 2006 06:13:00 -0700 (PDT) Received: by 10.37.21.14 with HTTP; Wed, 7 Jun 2006 06:13:00 -0700 (PDT) Message-ID: Date: Wed, 7 Jun 2006 09:13:00 -0400 From: "Matthias Clasen" To: "Carlos Garcia Campos" In-Reply-To: <1149680898.3302.9.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1149680898.3302.9.camel@localhost.localdomain> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.508 tagged_above=-999 required=2 tests=[AWL=0.092, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.508 X-Spam-Level: Cc: GTK+ development mailing list Subject: Re: Evince preview mode X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 13:13:05 -0000 On 6/7/06, Carlos Garcia Campos wrote: > Hi, > > since gtk+ is using evince as an external printing previewer, I'm > implementing a preview mode in evince, available through the command > line (--preview). It's based on the ephy printing previewer where the > menubar is hidden and the toolbar contains navigation items and a close > button. Here is an screenshot: > > http://carlosgc.linups.org/files/evince-preview-mode.png > > Any other thing expected by a previewer? A print button. From n1huq@hotmail.com Wed Jun 7 13:11:51 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 04F873B04FC for ; Wed, 7 Jun 2006 13:11:51 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32024-05 for ; Wed, 7 Jun 2006 13:11:49 -0400 (EDT) Received: from hotmail.com (bay114-dav5.bay114.hotmail.com [65.54.169.77]) by menubar.gnome.org (Postfix) with ESMTP id 192433B00F5 for ; Wed, 7 Jun 2006 13:11:49 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 7 Jun 2006 10:11:48 -0700 Message-ID: Received: from 68.0.250.43 by BAY114-DAV5.phx.gbl with DAV; Wed, 07 Jun 2006 17:11:46 +0000 X-Originating-IP: [68.0.250.43] X-Originating-Email: [n1huq@hotmail.com] X-Sender: n1huq@hotmail.com From: "Sydney Faria" To: Date: Wed, 7 Jun 2006 13:15:56 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-OriginalArrivalTime: 07 Jun 2006 17:11:48.0135 (UTC) FILETIME=[75E3BB70:01C68A55] X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=1.984 tagged_above=-999 required=2 tests=[BAYES_50=0.001, DNS_FROM_RFC_ABUSE=0.2, DNS_FROM_RFC_POST=1.708, MSGID_FROM_MTA_HEADER=0, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, TW_GT=0.077] X-Spam-Score: 1.984 X-Spam-Level: * Subject: combo box problem X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 17:11:51 -0000 The following simple example of a gtk_combo_box compiles and works OK it the select_cb() is empty. The line marked gives a compiler error: undefined reference to gtk_combo_box_get_active_text. I am befuddled! sydney #include #include GtkWidget *window, *combo; static gboolean delete_event(GtkWidget *widget, GdkEvent *event, gpointer data) { return FALSE; } static void destroy(GtkWidget *widget, gpointer data) { gtk_main_quit(); } static void select_cb(GtkWidget *widget, gpointer data) { /* comment out following 2 lines and program compiles and works OK */ gchar *str = gtk_combo_box_get_active_text(GTK_COMBO_BOX(combo)); /* compile error */ g_print("active text: %s\n", str); } int main( int argc, char *argv[] ) { GtkWidget *button, *hbox; gtk_init (&argc, &argv); /* init gtk */ window = gtk_window_new (GTK_WINDOW_TOPLEVEL); gtk_container_set_border_width(GTK_CONTAINER(window), 10); g_signal_connect(G_OBJECT(window), "delete_event", G_CALLBACK(delete_event), NULL); g_signal_connect(G_OBJECT(window), "destroy", G_CALLBACK(destroy), NULL); hbox = gtk_hbox_new(TRUE, 20); gtk_container_add(GTK_CONTAINER(window), hbox); button = gtk_button_new_with_label("Select text"); g_signal_connect(G_OBJECT(button), "clicked", G_CALLBACK(select_cb), NULL); gtk_box_pack_start(GTK_BOX(hbox), button, FALSE, FALSE, 0); combo = gtk_combo_box_new_text(); gtk_box_pack_start(GTK_BOX(hbox), combo, FALSE, FALSE, 0); gtk_combo_box_insert_text(GTK_COMBO_BOX(combo), 0, "Astring"); gtk_combo_box_append_text(GTK_COMBO_BOX(combo), "Bstring"); gtk_combo_box_append_text(GTK_COMBO_BOX(combo), "Cstring"); gtk_combo_box_append_text(GTK_COMBO_BOX(combo), "Dstring"); gtk_combo_box_append_text(GTK_COMBO_BOX(combo), "Estring"); gtk_combo_box_insert_text(GTK_COMBO_BOX(combo), 3, "xxxxx"); gtk_widget_show_all(window); gtk_main(); return 0; } From ali@avrc.city.ac.uk Wed Jun 7 13:20:43 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id B9C6A3B0D3D for ; Wed, 7 Jun 2006 13:20:43 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32493-04 for ; Wed, 7 Jun 2006 13:20:42 -0400 (EDT) Received: from firewall.avrc.city.ac.uk (optosun2.city.ac.uk [138.40.167.2]) by menubar.gnome.org (Postfix) with ESMTP id ACA3B3B0BDC for ; Wed, 7 Jun 2006 13:20:40 -0400 (EDT) Received: from tom.avrc.city.ac.uk (IDENT:U2FsdGVkX1/zwWSA4Vc+XKbUWVXUavCLm3rPqXMMlDg@tom [192.168.137.104]) by firewall.avrc.city.ac.uk (8.9.3/8.9.3) with ESMTP id SAA27971; Wed, 7 Jun 2006 18:10:27 +0100 Received: from tom.avrc.city.ac.uk (localhost.localdomain [127.0.0.1]) by tom.avrc.city.ac.uk (8.13.1/8.13.1) with ESMTP id k57HTT2Y031243; Wed, 7 Jun 2006 18:29:29 +0100 Date: Wed, 07 Jun 2006 17:29:28 +0000 From: "J. Ali Harlow" To: Sydney Faria References: In-Reply-To: (from n1huq@hotmail.com on Wed Jun 7 18:15:56 2006) X-Mailer: Balsa 2.2.6 Message-Id: <1149701368l.5713l.3l@tom.avrc.city.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; DelSp=Yes; Format=Flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.525 tagged_above=-999 required=2 tests=[AWL=-0.003, BAYES_00=-2.599, TW_GT=0.077] X-Spam-Score: -2.525 X-Spam-Level: Cc: gtk-devel-list@gnome.org Subject: Re: combo box problem X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 17:20:43 -0000 On 07/06/06 18:15:56, Sydney Faria wrote: > The following simple example of a gtk_combo_box compiles and works OK > it the select_cb() is empty. The line marked gives a compiler error: =20 > undefined reference to gtk_combo_box_get_active_text. gtk_combo_box_get_active_text was added in Gtk+ v2.6 Ali. From carlosgc@gnome.org Wed Jun 7 14:37:47 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id D45D43B0546 for ; Wed, 7 Jun 2006 14:37:47 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05339-08 for ; Wed, 7 Jun 2006 14:37:46 -0400 (EDT) Received: from localhost.localdomain (gsyc090.dat.escet.urjc.es [193.147.71.90]) by menubar.gnome.org (Postfix) with ESMTP id 3EC7D3B03F7 for ; Wed, 7 Jun 2006 14:37:46 -0400 (EDT) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 0ABE610F28E for ; Wed, 7 Jun 2006 20:37:40 +0200 (CEST) From: Carlos Garcia Campos To: gtk-devel-list@gnome.org In-Reply-To: References: <1149680898.3302.9.camel@localhost.localdomain> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-WdU94ldj/PvL1mhYRti9" Date: Wed, 07 Jun 2006 20:37:39 +0200 Message-Id: <1149705460.3302.25.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.354 tagged_above=-999 required=2 tests=[AWL=0.110, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.354 X-Spam-Level: Subject: Re: Evince preview mode X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 18:37:48 -0000 --=-WdU94ldj/PvL1mhYRti9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable El mi=C3=A9, 07-06-2006 a las 09:13 -0400, Matthias Clasen escribi=C3=B3: > On 6/7/06, Carlos Garcia Campos wrote: > > Hi, > > > > since gtk+ is using evince as an external printing previewer, I'm > > implementing a preview mode in evince, available through the command > > line (--preview). It's based on the ephy printing previewer where the > > menubar is hidden and the toolbar contains navigation items and a close > > button. Here is an screenshot: > > > > http://carlosgc.linups.org/files/evince-preview-mode.png > > > > Any other thing expected by a previewer? >=20 > A print button. >=20 hmm, when the user selects preview from the print dialog, the dialog disappears and evince is launched, so that if evince has a print button we should print the document directly without showing the print dialog again. I see several problems in this approach. First of all we can't know the print settings selected by the user from evince. And, should we close evince or keep it opened after clicking on print? Is it possible to print a pdf file with the new gtk+ api without showing any dialog?=20 I think it's very confused. The best solution would be not to hide the dialog when the previewer is launched, so that once the user is happy with the results showed in evince, he simply clicks on print button.=20 --=20 Carlos Garcia Campos (KaL) elkalmail@yahoo.es carlosgc@gnome.org http://carlosgc.linups.org PGP key: http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0x523E6462 --=-WdU94ldj/PvL1mhYRti9 Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQBEhxzzjxBOalI+ZGIRAsatAJ4+rfTQPQwp9+YtbRKpPmVlDuEG9ACfclx7 9c9NhlEvkjGZjMS42o6vmHM= =TbYL -----END PGP SIGNATURE----- --=-WdU94ldj/PvL1mhYRti9-- From matthias.clasen@gmail.com Wed Jun 7 19:34:00 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 62A323B036A for ; Wed, 7 Jun 2006 19:34:00 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23001-06 for ; Wed, 7 Jun 2006 19:33:56 -0400 (EDT) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.203]) by menubar.gnome.org (Postfix) with ESMTP id A86BE3B0E6E for ; Wed, 7 Jun 2006 19:33:56 -0400 (EDT) Received: by nz-out-0102.google.com with SMTP id o37so261498nzf for ; Wed, 07 Jun 2006 16:33:55 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=LpgZtLrjc9Sc3giRUzuWDX2naMTMsbgrizT1aggkQjCN27Pm9kFPU1c5Bra0LikmJaw1sDQO0paAD7N3OQwY1+3Y9JTdMwkT9YBnlgCbMohSYLzhRt6yPFasRtdkLK24rM8sI5l8EdJ/+dpxDSU/+GFlNbztpO8kky973RVbTmY= Received: by 10.36.103.6 with SMTP id a6mr1426226nzc; Wed, 07 Jun 2006 16:33:53 -0700 (PDT) Received: by 10.37.21.14 with HTTP; Wed, 7 Jun 2006 16:33:52 -0700 (PDT) Message-ID: Date: Wed, 7 Jun 2006 19:33:52 -0400 From: "Matthias Clasen" To: "Carlos Garcia Campos" In-Reply-To: <1149705460.3302.25.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1149680898.3302.9.camel@localhost.localdomain> <1149705460.3302.25.camel@localhost.localdomain> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.509 tagged_above=-999 required=2 tests=[AWL=0.091, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.509 X-Spam-Level: Cc: gtk-devel-list@gnome.org Subject: Re: Evince preview mode X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 23:34:00 -0000 On 6/7/06, Carlos Garcia Campos wrote: > hmm, when the user selects preview from the print dialog, the dialog > disappears and evince is launched, so that if evince has a print button > we should print the document directly without showing the print dialog > again. I see several problems in this approach. First of all we can't > know the print settings selected by the user from evince. And, should we > close evince or keep it opened after clicking on print? Is it possible > to print a pdf file with the new gtk+ api without showing any dialog? Sure, figuring out the best way to transfer the print settings to evince is part of this. And yes, printing preformatted pdf is supported. > > I think it's very confused. The best solution would be not to hide the > dialog when the previewer is launched, so that once the user is happy > with the results showed in evince, he simply clicks on print button. > Apple does it too, so it can't be all bad... Matthias From hfiguiere@teaser.fr Wed Jun 7 21:05:56 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 3CAD23B051D for ; Wed, 7 Jun 2006 21:05:56 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27783-02 for ; Wed, 7 Jun 2006 21:05:53 -0400 (EDT) Received: from xandros.com (smtp1.xandros.com [209.87.238.70]) by menubar.gnome.org (Postfix) with ESMTP id 31DC43B0414 for ; Wed, 7 Jun 2006 21:05:53 -0400 (EDT) Received: from [172.18.1.132] (toronto-hs-216-138-231-194.s-ip.magma.ca [216.138.231.194]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by xandros.com (Postfix) with ESMTP id A37413E02E; Wed, 7 Jun 2006 21:05:51 -0400 (EDT) Message-ID: <448777ED.1020804@teaser.fr> Date: Wed, 07 Jun 2006 21:05:49 -0400 From: Hubert Figuiere User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: Matthias Clasen References: <1149680898.3302.9.camel@localhost.localdomain> <1149705460.3302.25.camel@localhost.localdomain> In-Reply-To: X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.506 tagged_above=-999 required=2 tests=[AWL=0.093, BAYES_00=-2.599] X-Spam-Score: -2.506 X-Spam-Level: Cc: gtk-devel-list@gnome.org Subject: Re: Evince preview mode X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 01:05:56 -0000 >> I think it's very confused. The best solution would be not to hide the >> dialog when the previewer is launched, so that once the user is happy >> with the results showed in evince, he simply clicks on print button. >> > > Apple does it too, so it can't be all bad... That is the kind of blind thinking that lead to nowhere. Remember just one thing: if it does not please Steve Jobs, it does not goes. That how it works at Apple. Bottom line: wrong argument. Hub From alexl@redhat.com Thu Jun 8 08:09:59 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 5B8C83B0EF5; Thu, 8 Jun 2006 08:09:59 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32659-09; Thu, 8 Jun 2006 08:09:58 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id B35BC3B075A; Thu, 8 Jun 2006 08:09:57 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k58C9u9M020757; Thu, 8 Jun 2006 08:09:56 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k58C9u0T021240; Thu, 8 Jun 2006 08:09:56 -0400 Received: from [127.0.0.1] (sebastian-int.corp.redhat.com [172.16.52.221]) by devserv.devel.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k58C9tGO011054; Thu, 8 Jun 2006 08:09:56 -0400 From: Alexander Larsson To: Matthias Clasen In-Reply-To: References: <1149680898.3302.9.camel@localhost.localdomain> <1149705460.3302.25.camel@localhost.localdomain> Content-Type: text/plain Date: Thu, 08 Jun 2006 14:09:55 +0200 Message-Id: <1149768596.3023.11.camel@greebo> Mime-Version: 1.0 X-Mailer: Evolution 2.7.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.587 tagged_above=-999 required=2 tests=[AWL=0.014, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.587 X-Spam-Level: Cc: gtk-devel-list@gnome.org Subject: Re: Evince preview mode X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 12:09:59 -0000 On Wed, 2006-06-07 at 19:33 -0400, Matthias Clasen wrote: > On 6/7/06, Carlos Garcia Campos wrote: > > > hmm, when the user selects preview from the print dialog, the dialog > > disappears and evince is launched, so that if evince has a print button > > we should print the document directly without showing the print dialog > > again. I see several problems in this approach. First of all we can't > > know the print settings selected by the user from evince. And, should we > > close evince or keep it opened after clicking on print? Is it possible > > to print a pdf file with the new gtk+ api without showing any dialog? > > Sure, figuring out the best way to transfer the print settings to evince > is part of this. And yes, printing preformatted pdf is supported. This is tricky. What if the preview was launched without even showing the dialog, or if the user hadn't picked the right printer yet when clicking on preview. Also, it will print differently by generating pdf and then converting that to postscript, instead of generating postscript directly. Ideally this should produce as-good output, but thats not really guaranteed. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl@redhat.com alla@lysator.liu.se He's an immortal umbrella-wielding cyborg with no name. She's a tortured green-skinned Hell's Angel from a different time and place. They fight crime! From lists@nabble.com Thu Jun 8 21:35:27 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id BFE263B0E9B for ; Thu, 8 Jun 2006 21:35:27 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18339-04 for ; Thu, 8 Jun 2006 21:35:26 -0400 (EDT) Received: from talk.nabble.com (www.nabble.com [72.21.53.35]) by menubar.gnome.org (Postfix) with ESMTP id 602DC3B05AC for ; Thu, 8 Jun 2006 21:35:26 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=talk.nabble.com) by talk.nabble.com with esmtp (Exim 4.50) id 1FoVuE-0000rb-3p for gtk-devel-list@gnome.org; Thu, 08 Jun 2006 18:35:24 -0700 Message-ID: <4785900.post@talk.nabble.com> Date: Thu, 8 Jun 2006 18:35:22 -0700 (PDT) From: darknecro To: gtk-devel-list@gnome.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-Sender: darknecromancer@dodgeit.com X-Nabble-From: darknecro X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-0.316 tagged_above=-999 required=2 tests=[AWL=2.285, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -0.316 X-Spam-Level: Subject: GTK Masks X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2006 01:35:27 -0000 I am attempting to create a single mask that would cover several items with in the GUI. There will by 16 circles created with gdk_pixmap_create_from_xpm_d, and I can currently do this, but only one item would be 'created' in the mask, so when i apply the mask to the window, only one of the items will be visible. I have done a lot of searching, and I have only been able to come up with that you can xor 2 masks together somehow and create one that contains both. Any help that anyone could shed on this would be greatly appreciated. -- View this message in context: http://www.nabble.com/GTK-Masks-t1759366.html#a4785900 Sent from the Gtk+ - Dev - General forum at Nabble.com. From mitch@gimp.org Fri Jun 9 06:31:35 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id D2D0C3B0216 for ; Fri, 9 Jun 2006 06:31:34 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14877-07 for ; Fri, 9 Jun 2006 06:31:33 -0400 (EDT) Received: from mitch.gimp.org (p549C9439.dip0.t-ipconnect.de [84.156.148.57]) by menubar.gnome.org (Postfix) with ESMTP id EB4033B01DA for ; Fri, 9 Jun 2006 06:31:30 -0400 (EDT) Received: from mitch by mitch.gimp.org with local (Exim 3.36 #1 (Debian)) id 1FoeIj-0003cx-00; Fri, 09 Jun 2006 12:33:13 +0200 From: Michael Natterer To: Federico Mena Quintero In-Reply-To: <1149608483.14088.54.camel@cacharro.xalalinux.org> References: <1149608483.14088.54.camel@cacharro.xalalinux.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Fri, 09 Jun 2006 12:33:12 +0200 Message-Id: <1149849193.3010.23.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=1.06 tagged_above=-999 required=2 tests=[AWL=-0.545, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, RCVD_IN_NJABL_DUL=1.946, RCVD_IN_SORBS_DUL=2.046, TW_GT=0.077] X-Spam-Score: 1.06 X-Spam-Level: * Cc: GTK+ development mailing list , Michael.meeks@novell.com Subject: Re: Default timeouts X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2006 10:31:35 -0000 On Tue, 2006-06-06 at 10:41 -0500, Federico Mena Quintero wrote: > In gtksettings.c we have > > #define DEFAULT_TIMEOUT_INITIAL 200 > #define DEFAULT_TIMEOUT_REPEAT 20 > > for the "gtk-timeout-initial" and "gtk-timeout-repeat" settings, > respectively. This means we wait for a fifth of a second before we > start repeating, but then we try to repeat 50 times per second. > > Isn't the repeat timeout way too short? This is why clicking on a > calendar arrow takes you back tens of months in no time, and also makes > it hard to use spin buttons. Yes, that's way too short. When doing the settings patch, I unified timeouts without actually changing them (the 20 ms was there before). However in some places I introduced a factor of 5 so all existing timeouts could be done with the two values from GtkSettings. See comment #10 of http://bugzilla.gnome.org/show_bug.cgi?id=142582 Actually, it may make sense to simply use the user's configured key repeat and delay for these two setting values. What do you think? ciao, --mitch > Also, Michael Meeks has the following words of wisdom in a Novell bug > about the calendar in gnome-panel's clock: > > > In essence the timeout is way too short for switching days; also - > > in the panel applet the timeout has a higher priority than the > > queued resize of the display (and hence the redraw) - so in > > essence we skip days even faster since we never have to render > > them. > > > > Lowering the priority there, and lengthening the timeouts gives > > a far more reasonable, usable experience without getting rid > > of the whole auto-repeat principle [...] > > I.e. instead of using g_timeout_add() in gtkcalendar, we would use > g_timeout_add_full (G_PRIORITY_DEFAULT_IDLE, ...), or perhaps > (GDK_PRIORITY_REDRAW + positive_constant): both are lower priority than > GTK_PRIORITY_RESIZE. > > Federico > > _______________________________________________ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-devel-list From ross@burtonini.com Fri Jun 9 07:15:10 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 1192B3B0099 for ; Fri, 9 Jun 2006 07:15:10 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18418-03 for ; Fri, 9 Jun 2006 07:15:08 -0400 (EDT) Received: from smtp.nildram.co.uk (smtp.nildram.co.uk [195.112.4.54]) by menubar.gnome.org (Postfix) with ESMTP id 279213B0081 for ; Fri, 9 Jun 2006 07:15:07 -0400 (EDT) Received: from burtonini.com (althur.gotadsl.co.uk [84.12.135.175]) by smtp.nildram.co.uk (Postfix) with ESMTP id 1DDA833C3F2; Fri, 9 Jun 2006 12:11:26 +0100 (BST) Received: from 127.0.0.1 (ident=unknown) by burtonini.com with esmtp (masqmail 0.2.21) id 1Foetj-17d-00; Fri, 09 Jun 2006 12:11:27 +0100 From: Ross Burton To: Michael Natterer In-Reply-To: <1149849193.3010.23.camel@localhost> References: <1149608483.14088.54.camel@cacharro.xalalinux.org> <1149849193.3010.23.camel@localhost> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-DKvhrUfzvCjsapgkUotZ" Date: Fri, 09 Jun 2006 12:11:27 +0100 Message-Id: <1149851487.2333.2.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.456 tagged_above=-999 required=2 tests=[AWL=0.008, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.456 X-Spam-Level: Cc: Federico Mena Quintero , GTK+ development mailing list , Michael.meeks@novell.com Subject: Re: Default timeouts X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2006 11:15:10 -0000 --=-DKvhrUfzvCjsapgkUotZ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2006-06-09 at 12:33 +0200, Michael Natterer wrote: > Actually, it may make sense to simply use the user's configured > key repeat and delay for these two setting values. What do you > think? That's probably a very good idea, on the grounds that people set the keyboard delay/repeat to values they can handle (i.e. my Dad has slowed them down as he isn't as fast as he used to be). What are the system defaults for the keyboard delay/repeat? Ross --=20 Ross Burton mail: ross@burtonini.com jabber: ross@burtonini.com www: http://www.burtonini.com./ PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF --=-DKvhrUfzvCjsapgkUotZ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQBEiVdeLQnkR9C0M98RAp+DAJ9s9H2qD2A4AQ6kXwgB+B6ka0ve8QCfZcQL IPi9sLP/fY2zOVLCX+eSrvo= =LNZu -----END PGP SIGNATURE----- --=-DKvhrUfzvCjsapgkUotZ-- From timj@gtk.org Fri Jun 9 13:30:55 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 1CAD23B00E9 for ; Fri, 9 Jun 2006 13:30:55 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10186-10 for ; Fri, 9 Jun 2006 13:30:52 -0400 (EDT) Received: from webmail.hansenet.de (mail03.hansenet.de [213.191.73.10]) by menubar.gnome.org (Postfix) with ESMTP id E3A183B011B for ; Fri, 9 Jun 2006 13:30:51 -0400 (EDT) Received: from birnet.org (80.171.4.161) by webmail.hansenet.de (7.2.059) id 4487A06D0006D98F; Fri, 9 Jun 2006 19:30:40 +0200 Received: from master.birnet.private (localhost [127.0.0.1]) by birnet.org (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k59HUdVg010604 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 9 Jun 2006 19:30:39 +0200 Received: (from timj@localhost) by master.birnet.private (8.13.4/8.13.4/Submit) id k59HUPEO010599; Fri, 9 Jun 2006 19:30:25 +0200 Date: Fri, 9 Jun 2006 19:30:25 +0200 (CEST) From: Tim Janik X-X-Sender: timj@master.birnet.private To: "Kaveh R. Ghazi" In-Reply-To: <200606091630.k59GUaES013244@caipclassic.rutgers.edu> Message-ID: References: <20060609152646.GE20719@space.twc.de> <200606091630.k59GUaES013244@caipclassic.rutgers.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.469 tagged_above=-999 required=2 tests=[AWL=0.130, BAYES_00=-2.599] X-Spam-Score: -2.469 X-Spam-Level: Cc: gcc@gcc.gnu.org, Gtk+ Developers Subject: Re: Problem with type safety and the "sentinel" attribute X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2006 17:30:55 -0000 thanks for the quick response Kaveh. On Fri, 9 Jun 2006, Kaveh R. Ghazi wrote: > > > void print_string_array (const char *array_name, > > const char *string, ...) __attribute__ > > ((__sentinel__)); > > > > print_string_array ("empty_array", NULL); /* gcc warns, but shouldn't */ > > > > The only way out for keeping the sentinel attribute and avoiding the > > warning is using > > > > static void print_string_array (const char *array_name, ...) > > __attribute__ ((__sentinel__)); > > I think you could maintain typesafety and silence the warning by > keeping the more specific prototype and adding an extra NULL, e.g.: > > print_string_array ("empty_array", NULL, NULL); > > Doesn't seem elegant, but it does the job. this is an option for a limited set of callers, yes. > > By the way, there is already an existing gcc bug, which is about the > > same thing (NULL passed within named args), but wants to have it the > > way it works now: > > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21911 > > Correct, the feature as I envisioned it expected the sentinel to > appear in the variable arguments only. This PR reflects when I found > out it didn't do that and got around to fixing it. Note the "buggy" > behavior wasn't exactly what you wanted either because GCC got fooled > by a sentinel in *any* of the named arguments, not just the last one. > > > > so if it gets changed, then gcc might need to support both > > - NULL termination within the last named parameter allowed > > - NULL termination only allowed within varargs parameters (like it is > > now) > > I'm not against this enhancement, but you need to specify a syntax > that allows the old behavior but also allows doing it your way. > > Hmm, perhaps we could check for attribute "nonnull" on the last named > argument, if it exists then that can't be the sentinel, if it's not > there then it does what you want. This is not completely backwards > compatible because anyone wanting the existing behavior has to add the > attribute nonnull. But there's precedent for this when attribute > printf split out whether the format specifier could be null... > > We could also create a new attribute name for the new behavior. This > would preserve backwards compatibility. I like this idea better. i agree here. as far as the majority of the GLib and Gtk+ APIs are concerned, we don't really need the flexibility of the sentinel attribute but rather a compiler check on whether the last argument used in a function call is NULL or 0 (regardless of whether it's the last named arg or already part of the varargs list). that's also why the actual sentinel wrapper in GLib looks like this: #define G_GNUC_NULL_TERMINATED __attribute__((__sentinel__)) so, if i was to make a call on this issue, i'd either introduce __attribute__((__null_terminated__)) with the described semantics, or have __attribute__((__sentinel__(-1))) work essentially like __attribute__((__sentinel__(0))) while also accepting 0 in the position of the last named argument. > Next you need to recruit someone to implement this enhancement, or > submit a patch. :-) Although given that you can silence the warning by > adding an extra NULL at the call site, I'm not sure it's worth it. i would say this is definitely worth it, because the issue also shows up in other code that is widely used: gpointer g_object_new (GType object_type, const gchar *first_property_name, ...); that's for instance a function which is called in many projects. putting the burden on the caller is clearly the wrong trade off here. so please take this as a vote for the worthiness of a fix ;) > --Kaveh > -- > Kaveh R. Ghazi ghazi@caip.rutgers.edu --- ciaoTJ From nshmyrev@yandex.ru Sat Jun 10 02:06:32 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 347973B00D0 for ; Sat, 10 Jun 2006 02:06:32 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12492-03 for ; Sat, 10 Jun 2006 02:06:28 -0400 (EDT) Received: from chen.mtu.ru (chen.mtu.ru [195.34.34.232]) by menubar.gnome.org (Postfix) with ESMTP id 78AC43B0126 for ; Sat, 10 Jun 2006 02:06:28 -0400 (EDT) Received: from gnome.local (ppp83-237-50-138.pppoe.mtu-net.ru [83.237.50.138]) by smtp.MTU.RU (Postfix) with ESMTP id D51B453DA7E; Sat, 10 Jun 2006 10:06:25 +0400 (MSD) (envelope-from nshmyrev@yandex.ru) From: "Nickolay V. Shmyrev" To: gtk-devel-list@gnome.org, gnome-i18n@gnome.org Content-Type: text/plain Date: Sat, 10 Jun 2006 10:06:30 +0400 Message-Id: <1149919590.2305.18.camel@gnome.local> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 (2.6.2-1.fc5.3) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.758 tagged_above=-999 required=2 tests=[AWL=-0.440, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, SPF_NEUTRAL=1.069, TW_GT=0.077] X-Spam-Score: -1.758 X-Spam-Level: Cc: Subject: Translation of gtk tuturial X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2006 06:06:32 -0000 Hello all. I now there was done quite amazing work about translation of gtk tutorial and I know there were some other translations http://linfoline.homedns.org/gtk/book1.html http://kldp.org/KoreanDoc/html/GtkTutorial/GtkTutorial.html What about making gtk tutorial translatable with docutils like all user documentation and merging those translations upstream? I don't ask about reference manual translation but it's also interesting, although not realistic. Probably it's not sensible to distribute tutorial with gtk package itself but use something like a web-based Rosetta. From matthias.clasen@gmail.com Sat Jun 10 10:02:35 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id A74883B0280 for ; Sat, 10 Jun 2006 10:02:35 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06778-09 for ; Sat, 10 Jun 2006 10:02:33 -0400 (EDT) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.200]) by menubar.gnome.org (Postfix) with ESMTP id 1C56D3B01C3 for ; Sat, 10 Jun 2006 10:02:33 -0400 (EDT) Received: by nz-out-0102.google.com with SMTP id z3so947001nzf for ; Sat, 10 Jun 2006 07:02:32 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=jUGG9w5BYrTkFmK4uobvwaXzJ1w3H4k8DuZIFGIHoBjFn1kgtf//lWo+engDAz0ImbOYOsKrWjvA9YAXvpwCcamcXXpE51E09vtpA8lmZKxAt+RA6AWeMX4blO5srWeestsf+E6dRd0OwZUmD3OCksEXAdLAjQcGBJBiKLVKPnQ= Received: by 10.37.15.76 with SMTP id s76mr5772218nzi; Sat, 10 Jun 2006 07:02:32 -0700 (PDT) Received: by 10.37.21.6 with HTTP; Sat, 10 Jun 2006 07:02:32 -0700 (PDT) Message-ID: Date: Sat, 10 Jun 2006 10:02:32 -0400 From: "Matthias Clasen" To: "Nickolay V. Shmyrev" In-Reply-To: <1149919590.2305.18.camel@gnome.local> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1149919590.2305.18.camel@gnome.local> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.471 tagged_above=-999 required=2 tests=[AWL=0.052, BAYES_00=-2.599, SPF_PASS=-0.001, TW_GT=0.077] X-Spam-Score: -2.471 X-Spam-Level: Cc: gnome-i18n@gnome.org, gtk-devel-list@gnome.org Subject: Re: Translation of gtk tuturial X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2006 14:02:35 -0000 On 6/10/06, Nickolay V. Shmyrev wrote: > Hello all. > > I now there was done quite amazing work about translation of gtk > tutorial and I know there were some other translations > > http://linfoline.homedns.org/gtk/book1.html > > http://kldp.org/KoreanDoc/html/GtkTutorial/GtkTutorial.html > > What about making gtk tutorial translatable with docutils like all > user documentation and merging those translations upstream? > > I don't ask about reference manual translation but it's also interesting, > although not realistic. Probably it's not sensible to distribute tutorial > with gtk package itself but use something like a web-based Rosetta. > The first step towards making the tutorial more useful would be updating its 2.0 era content, remove deprecated apis, and cover at least some of the important new apis. From lists@nabble.com Sat Jun 10 13:20:05 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id BB53E3B01B8 for ; Sat, 10 Jun 2006 13:20:05 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16672-08 for ; Sat, 10 Jun 2006 13:20:04 -0400 (EDT) Received: from talk.nabble.com (www.nabble.com [72.21.53.35]) by menubar.gnome.org (Postfix) with ESMTP id 2730A3B01D7 for ; Sat, 10 Jun 2006 13:20:04 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=talk.nabble.com) by talk.nabble.com with esmtp (Exim 4.50) id 1Fp77z-0000O0-FG for gtk-devel-list@gnome.org; Sat, 10 Jun 2006 10:20:03 -0700 Message-ID: <4809607.post@talk.nabble.com> Date: Sat, 10 Jun 2006 10:20:03 -0700 (PDT) From: mikecorn To: gtk-devel-list@gnome.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-Sender: mikecorn@t-online.de X-Nabble-From: mikecorn X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.565 tagged_above=-999 required=2 tests=[AWL=0.036, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.565 X-Spam-Level: Subject: GTK window edge detection sensitivity X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2006 17:20:05 -0000 To: GTK developers The resizable windows in Gnome are slick, but I often have a minor problem: After the mouse cursor changes form, indicating that the window edge is in-range for dragging, I often find myself dragging across the window behind, because the edge range was lost shortly after it was found. I ask you to consider possible improvements to make this work more reliably and with less precision required (which also means faster for the user). 1. increase the edge-detection threshold by 2x or more, or make it user-adjustable. 2. once the edge is detected, increase the threshold for losing it (time or distance). regards Mike C. -- View this message in context: http://www.nabble.com/GTK-window-edge-detection-sensitivity-t1767067.html#a4809607 Sent from the Gtk+ - Dev - General forum at Nabble.com. From marcel@telka.sk Sat Jun 10 23:05:18 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 2D8C03B05D2 for ; Sat, 10 Jun 2006 23:05:18 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06780-08 for ; Sat, 10 Jun 2006 23:05:16 -0400 (EDT) Received: from tortuga.telka.sk (unknown [193.86.173.20]) by menubar.gnome.org (Postfix) with SMTP id 7D8283B0543 for ; Sat, 10 Jun 2006 23:05:15 -0400 (EDT) Received: (qmail 14272 invoked by uid 0); 11 Jun 2006 02:57:43 -0000 Date: 11 Jun 2006 02:57:43 -0000 Message-ID: <20060611025743.14269.qmail@tortuga.telka.sk> To: From: Marcel Telka X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.443 tagged_above=-999 required=2 tests=[AWL=0.156, BAYES_00=-2.599] X-Spam-Score: -2.443 X-Spam-Level: Subject: gtk+: Missing translatable files X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jun 2006 03:05:18 -0000 Hi. I have tested module gtk+ (CVS branch HEAD) which lives in GNOME CVS for missing translatable files with `intltool-update -m` command. Here is a content of the 'missing' file: gtk/gtkfilechoosersettings.c gtk/gtkprintoperationpreview.c Please put these files into POTFILES.in or POTFILES.skip files. Thanks. Note: This report is generated automatically and you are not required to reply to this mail. If you are not maintainer of the 'gtk+' module or this CVS branch is obsolete or you don't want similar report in future, tell me and I will stop this report generation. Regards. -- +-------------------------------------------+ | Marcel Telka e-mail: marcel@telka.sk | | homepage: http://telka.sk/ | | jabber: marcel@jabber.sk | +-------------------------------------------+ From easy-b@freesurf.ch Sun Jun 11 16:22:48 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id ABE753B0159 for ; Sun, 11 Jun 2006 16:22:48 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32516-10 for ; Sun, 11 Jun 2006 16:22:46 -0400 (EDT) Received: from mail-fs.sunrise.ch (mta-fs-be-04.sunrise.ch [194.158.229.33]) by menubar.gnome.org (Postfix) with ESMTP id A306E3B00CA for ; Sun, 11 Jun 2006 16:22:45 -0400 (EDT) Received: from [10.0.1.2] (84.227.173.50) by mail-fs.sunrise.ch (7.2.073) id 44858C490024803A; Sun, 11 Jun 2006 22:21:55 +0200 In-Reply-To: References: <20060522160033.F1A8E3B1CE4@menubar.gnome.org> <772588ED-500A-4A11-8829-DA80B9A35D1F@freesurf.ch> <44720B8C.3080903@imendio.com> <0A34FCC9-6650-4737-B86D-1B503D8A9072@freesurf.ch> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7D6367DC-8689-453B-8FD7-217632BC1DAE@freesurf.ch> Content-Transfer-Encoding: 7bit From: Easy B Date: Sun, 11 Jun 2006 22:21:54 +0200 To: Gregor Riepl X-Mailer: Apple Mail (2.749.3) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.312 tagged_above=-999 required=2 tests=[AWL=-0.787, BAYES_00=-2.599, DNS_FROM_RFC_POST=1.708, FORGED_RCVD_HELO=0.135, TW_BG=0.077, TW_GD=0.077, TW_GT=0.077] X-Spam-Score: -1.312 X-Spam-Level: Cc: gtk-devel-list@gnome.org Subject: Mac OS X Framework X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jun 2006 20:22:48 -0000 Hoi Gregor Thanx for the Tips. This would make the Framework more like one. The ability to include it into the application bundle would be very handy. If I look at other Frameworks I always find a single library in the top directory, for example: /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ Frameworks/ImageIO.framework/ImageIO If I do "otool -L /System/Library/Frameworks/ ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/ ImageIO", I get references to many other libraries that are located inside the framework bundle: /System/Library/Frameworks/ApplicationServices.framework/ Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/ libJPEG.dylib (compatibility version 1.0.0, current version 1.0.0) /System/Library/Frameworks/ApplicationServices.framework/ Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/ libJP2.dylib (compatibility version 1.0.0, current version 1.0.0) /System/Library/Frameworks/ApplicationServices.framework/ Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/ libGIF.dylib (compatibility version 1.0.0, current version 1.0.0) /System/Library/Frameworks/ApplicationServices.framework/ Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/ libRaw.dylib (compatibility version 1.0.0, current version 1.0.0) /System/Library/Frameworks/ApplicationServices.framework/ Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/ libTIFF.dylib (compatibility version 1.0.0, current version 1.0.0) /System/Library/Frameworks/ApplicationServices.framework/ Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/ libPng.dylib (compatibility version 1.0.0, current version 1.0.0) /System/Library/Frameworks/ApplicationServices.framework/ Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/ libRadiance.dylib (compatibility version 1.0.0, current version 1.0.0) In my Gtk+.framework I have tons of libraries. Would it be possible to create something like the above for gtk? Would it make sense? Right now I just use pkg-config to find the libraries and the result looks like this: /Applications/Shity Apps/Gtk-Demo.app/Contents/MacOS/gtk-demo: /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libgdk_pixbuf-2.0.0.dylib (compatibility version 902.0.0, current version 902.0.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libgdk-quartz-2.0.0.dylib (compatibility version 902.0.0, current version 902.0.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libgtk-quartz-2.0.0.dylib (compatibility version 902.0.0, current version 902.0.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libpangocairo-1.0.0.dylib (compatibility version 1301.0.0, current version 1301.1.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libpangoft2-1.0.0.dylib (compatibility version 1301.0.0, current version 1301.1.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libpango-1.0.0.dylib (compatibility version 1301.0.0, current version 1301.1.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libatk-1.0.0.dylib (compatibility version 1115.0.0, current version 1115.0.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libgobject-2.0.0.dylib (compatibility version 1102.0.0, current version 1102.0.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libgmodule-2.0.0.dylib (compatibility version 1102.0.0, current version 1102.0.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libglib-2.0.0.dylib (compatibility version 1102.0.0, current version 1102.0.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libcairo.2.dylib (compatibility version 9.0.0, current version 9.0.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libpng12.0.dylib (compatibility version 11.0.0, current version 11.0.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libfontconfig.1.dylib (compatibility version 2.0.0, current version 2.4.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libfreetype.6.dylib (compatibility version 10.0.0, current version 10.8.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libxml2.2.dylib (compatibility version 9.0.0, current version 9.24.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libintl.3.dylib (compatibility version 8.0.0, current version 8.3.0) What do you think? Cheers, Ezra. On 11.06.2006, at 10:22, Gregor Riepl wrote: > Hi Ezra > >> Well it's looking better now. I even ended up with ready to use >> Installers. I still got my pkg-config/headers problem though so >> the script still has some ugly hard links in it., besides all the >> other debugging ugliness. I'm also not sure if the framework is >> usable the way it's now. I will first have to try to compile some >> apps against it. I'll definitely come with more problems soon. > > To make a framework fully usable, it's dynamic library paths need > to be adapted with install_name_tool. > For example, its the self-reference should be > @executable_path/../Frameworks/.framework/ > Versions/A/ > This makes the library includable in application bundles, instead > of having to install it. > But you may of course also use /Library/Frameworks/ framework>.framework/Versions/A/ > Have a look at the output of otool -L for some system and user- > installed libraries, i.e. > > $ otool -L /System/Library/Frameworks/Cocoa.framework/Cocoa > /System/Library/Frameworks/Cocoa.framework/Cocoa: > /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa > (compatibility version 1.0.0, current version 11.0.0) > /System/Library/Frameworks/AppKit.framework/Versions/C/ > AppKit (compatibility version 45.0.0, current version 822.0.0) > /System/Library/Frameworks/CoreData.framework/Versions/A/ > CoreData (compatibility version 1.0.0, current version 46.0.0) > /System/Library/Frameworks/Foundation.framework/Versions/C/ > Foundation (compatibility version 300.0.0, current version 566.0.0) > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, > current version 88.0.0) > > or > > $ otool -L /Library/Frameworks/SDL_image.framework/SDL_image > /Library/Frameworks/SDL_image.framework/SDL_image: > @executable_path/../Frameworks/SDL_image.framework/Versions/ > A/SDL_image (compatibility version 1.0.0, current version 1.0.0) > @executable_path/../Frameworks/SDL.framework/Versions/A/SDL > (compatibility version 1.0.0, current version 1.0.0) > /usr/lib/libz.1.dylib (compatibility version 1.0.0, current > version 1.0.0) > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, > current version 71.1.1) > > If a library has a lot of dependencies, you may run into a problem > here: The Mach-O header's area for library references isn't of > variable size, and install_name_tool may refuse to change all > paths. There's afaik no other way then to relink the binary with > the option -headerpad_max_install_names (see man ld). > From mclasen@redhat.com Mon Jun 12 12:04:32 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 41C3B3B000C; Mon, 12 Jun 2006 12:04:32 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09149-04; Mon, 12 Jun 2006 12:04:29 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id 7270D3B009D; Mon, 12 Jun 2006 12:04:29 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5CG3bc9030255; Mon, 12 Jun 2006 12:03:37 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5CG3bc3007778; Mon, 12 Jun 2006 12:03:37 -0400 Received: from golem.boston.redhat.com (golem.boston.redhat.com [172.16.80.24]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id k5CG3blQ018463; Mon, 12 Jun 2006 12:03:37 -0400 From: Matthias Clasen To: gnome-announce-list@gnome.org, gtk-devel-list@gnome.org, gtk-app-devel-list@gnome.org, gtk-list@gnome.org Content-Type: text/plain Date: Mon, 12 Jun 2006 12:03:36 -0400 Message-Id: <1150128216.15532.14.camel@golem.boston.redhat.com> Mime-Version: 1.0 X-Mailer: Evolution 2.7.1 (2.7.1-1) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.426 tagged_above=-999 required=2 tests=[AWL=-0.056, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, TW_LQ=0.077, TW_RX=0.077, TW_TR=0.077] X-Spam-Score: -2.426 X-Spam-Level: Cc: Subject: GLib 2.11.3 released X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gome-hackers@gnome.org List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2006 16:04:32 -0000 GLib 2.11.3 is now available for download at: ftp://ftp.gtk.org/pub/gtk/v2.11/ http://ftp.gnome.org/pub/GNOME/sources/glib/2.11/ glib-2.11.3.tar.bz2 md5sum: 41931c4965f7e1848f81b800914905cd glib-2.11.3.tar.gz md5sum: cd78ebc535e29cdef0fed9487aa21dac This is a development release leading up to GLib 2.12. Notes: * This is unstable development release. While it has had a bit of testing, there are certainly plenty of bugs remaining to be found. This release should not be used in production. * Installing this version will overwrite your existing copy of GLib 2.10. If you have problems, you'll need to reinstall GLib 2.10. * GLib 2.12 will be source and binary compatible with the GLib 2.10.x series (for some caveats, see the README). At this point, the API additions in the 2.11.x series are almost finished. * Bugs should be reported to http://bugzilla.gnome.org. About GLib ========== GLib is the low-level core library that forms the basis for projects such as GTK+ and GNOME. It provides data structure handling for C, portability wrappers, and interfaces for such runtime functionality as an event loop, threads, dynamic loading, and an object system. More information about GLib is available at: http://www.gtk.org/ An installation guide for the GTK+ libraries, including GLib, can be found at: http://developer.gnome.org/doc/API/2.0/gtk/gtk-building.html Overview of Changes from GLib 2.11.2 to GLib 2.11.3 =================================================== * GBookmarkFile: - g_bookmark_file_move_item: Return TRUE in case of an empty target * Bugs fixed: 343919 gunicollate.c: strxfrm bug on VC8 * Updated translations (fi) A list of all bugs fixed in this release can be found at: http://bugzilla.gnome.org/buglist.cgi?bug_id=343919 Thanks to everybody who has contributed to this release, in the form of bug reports or patches: Emmanuele Bassi, Kazuki Iwamoto, Tor Lillqvist Matthias Clasen June 12, 2006 From mclasen@redhat.com Mon Jun 12 15:43:04 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 851123B00E5; Mon, 12 Jun 2006 15:43:04 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27729-06; Mon, 12 Jun 2006 15:43:02 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id 5B16F3B0010; Mon, 12 Jun 2006 15:43:02 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5CJZWav007572; Mon, 12 Jun 2006 15:35:32 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5CJZWUd001833; Mon, 12 Jun 2006 15:35:32 -0400 Received: from golem.boston.redhat.com (golem.boston.redhat.com [172.16.80.24]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id k5CJZWlQ009694; Mon, 12 Jun 2006 15:35:32 -0400 From: Matthias Clasen To: gnome-announce-list@gnome.org, gtk-devel-list@gnome.org, gtk-app-devel-list@gnome.org, gtk-list@gnome.org Content-Type: text/plain Date: Mon, 12 Jun 2006 15:35:31 -0400 Message-Id: <1150140931.15532.18.camel@golem.boston.redhat.com> Mime-Version: 1.0 X-Mailer: Evolution 2.7.1 (2.7.1-1) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.541 tagged_above=-999 required=2 tests=[AWL=0.060, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.541 X-Spam-Level: Cc: Subject: GTK+ 2.8.19 released X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gnome-hackers@gnome.org List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2006 19:43:04 -0000 GTK+ 2.8.19 is now available for download at: ftp://ftp.gtk.org/pub/gtk/v2.8/ http://ftp.gnome.org/pub/GNOME/sources/gtk+/2.8/ gtk+-2.8.19.tar.bz2 md5sum: 1a03dbed4b794194a610e9d7eb175b06 gtk+-2.8.19.tar.gz md5sum: 604d3263498994c58af378f0ec076e6f This is a bugfix release in the 2.8.x series. It fixes a rare memory corruption issue when using the deprecated GdkFont API. What is GTK+ ============ GTK+ is a multi-platform toolkit for creating graphical user interfaces. Offering a complete set of widgets, GTK+ is suitable for projects ranging from small one-off tools to complete application suites. GTK+ has been designed from the ground up to support a range of languages, not only C/C++. Using GTK+ from languages such as Perl and Python (especially in combination with the Glade GUI builder) provides an effective method of rapid application development. GTK+ is free software and part of the GNU Project. However, the licensing terms for GTK+, the GNU LGPL, allow it to be used by all developers, including those developing proprietary software, without any license fees or royalties. Where to get more information about GTK+ ======================================== Information about GTK+ including links to documentation can be found at: http://www.gtk.org/ An installation guide for GTK+ 2.8 is found at: http://developer.gnome.org/doc/API/2.0/gtk/gtk-building.html Common questions: http://developer.gnome.org/doc/API/2.0/gtk/gtk-question-index.html http://www.gtk.org/faq/ Overview of Changes from GTK+ 2.8.18 to GTK+ 2.8.19 =================================================== Bugs fixed: 341327 Memory corruption inside glib 337491 _gdk_win32_drawable_release_dc: DeleteDC() called on a GetDC() handle 343425 "grab-notify"-signal is not correctly propagated for internal children 344244 Window resizing not working when keeping the aspect fixed 344496 CRLF converting via Clipboard Updated translations (ne) A list of all bugs fixed in this release can be found at: http://bugzilla.gnome.org/buglist.cgi?bug_id=343425,341327,344244,337491,344496 Thanks to everybody who has contributed to this release, in the form of bug reports or patches: Markku Vire, Sampo Savolainen, Tim Janik, Tor Lillqvist, Chris Wilson June 12, 2006 Matthias Clasen From mclasen@redhat.com Tue Jun 13 02:09:16 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 72FE93B00AF; Tue, 13 Jun 2006 02:09:16 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12183-04; Tue, 13 Jun 2006 02:09:13 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id B2F773B000C; Tue, 13 Jun 2006 02:09:13 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5D681s3022181; Tue, 13 Jun 2006 02:08:01 -0400 Received: from lacrosse.corp.redhat.com (lacrosse.corp.redhat.com [172.16.52.154]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5D67uRP017686; Tue, 13 Jun 2006 02:07:56 -0400 Received: from [172.16.83.145] (vpn83-145.boston.redhat.com [172.16.83.145]) by lacrosse.corp.redhat.com (8.12.11.20060308/8.11.6) with ESMTP id k5D67tQC015619; Tue, 13 Jun 2006 02:07:56 -0400 From: Matthias Clasen To: gnome-announce-list@gnome.org, gtk-devel-list@gnome.org, gtk-app-devel-list@gnome.org, gtk-list@gnome.org Content-Type: text/plain; charset=UTF-8 Organization: Red Hat Date: Tue, 13 Jun 2006 02:09:42 -0400 Message-Id: <1150178982.4081.13.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.7.2.1 (2.7.2.1-4) Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.426 tagged_above=-999 required=2 tests=[AWL=-0.056, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, TW_GD=0.077, TW_GT=0.077, TW_KB=0.077] X-Spam-Score: -2.426 X-Spam-Level: Cc: Subject: GTK+ 2.9.3 released X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gnome-hackers@gnome.org List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2006 06:09:16 -0000 GTK+ 2.9.3 is now available for download at: ftp://ftp.gtk.org/pub/gtk/v2.9/ http://ftp.gnome.org/pub/gnome/sources/gtk+/2.9/ gtk+-2.9.3.tar.bz2 md5sum: d73039a3b5847c352f5740ac908be7d2 gtk+-2.9.3.tar.gz md5sum: 0156eef91d2bbb23f1b6ccb49335fae5 This is a development release leading up to GTK+ 2.10. Notes: * This is unstable development release. There are certainly plenty of bugs remaining to be found. This release should not be used in production. * Installing this version will overwrite your existing copy of GTK+ 2.8. If you have problems, you'll need to reinstall GTK+ 2.8. * GTK+ 2.10 will be source compatible with the GTK+ 2.8 series; the new API additions in GTK+ 2.9.0 are not yet completely finalized, so there are likely incompatibilies between this release and the final 2.10 release. * The ABI version has been bumped from 2.4.0 to 2.10.0, since the filechooser backend interface has been changed. Third-party filechooser backends need to be ported to the new interface. Other third-party modules (input methods, image loaders, etc) just need to be reinstalled in the proper location for GTK+ to find them. * Remaining issues for GTK+ 2.10 can be found with following bugzilla query: http://bugzilla.gnome.org/buglist.cgi?product=gtk%2b&target_milestone=2.10+API+Freeze&target_milestone=2.10+Freeze&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED * Bugs should be reported to http://bugzilla.gnome.org. What is GTK+ ============ GTK+ is a multi-platform toolkit for creating graphical user interfaces. Offering a complete set of widgets, GTK+ is suitable for projects ranging from small one-off tools to complete application suites. GTK+ has been designed from the ground up to support a range of languages, not only C/C++. Using GTK+ from languages such as Perl and Python (especially in combination with the Glade GUI builder) provides an effective method of rapid application development. GTK+ is free software and part of the GNU Project. However, the licensing terms for GTK+, the GNU LGPL, allow it to be used by all developers, including those developing proprietary software, without any license fees or royalties. Where to get more information about GTK+ ======================================== Information about GTK+ including links to documentation can be found at: http://www.gtk.org/ An installation guide for GTK+ 2.x is found at: http://developer.gnome.org/doc/API/2.4/gtk/gtk-building.html Common questions: http://developer.gnome.org/doc/API/2.4/gtk/gtk-question-index.html http://www.gtk.org/faq/ Overview of Changes from GTK+ 2.9.2 to 2.9.3 ============================================ * GtkPrintOperation: - Introduce an allow-async property - Introduce a GtkPrintOperationAction enumeration - Rename pdf_target to export_filename - Allow to hide "Print to PDF" in the low-level API * GtkNotebook: - Add a destroy notify to gtk_notebook_set_window_creation_hook. * GtkTreeView: - Support grid lines * GtkRange: - Add a number of new stle properties which allow more fexible stepper theming * Bugs fixed: 153212 Have the Paste kbd shortcut jump to the location in the buffer 337491 _gdk_win32_drawable_release_dc: DeleteDC() called on a GetDC() handle 339739 gtk/gtkprintoperation-win32.c: 3 compile error 342339 GtkRange::stepper-spacing style property not implemented correctly 343945 Buttons of a GtkAssistant are not accessible 344148 Wrong reqs for ATK 344209 gtk_notebook_set_window_creation_hook() has no destroy func. 344232 GtkEntry's "Delete" context menu item is sensitive on a non-editable GtkEntry 344244 Window resizing not working when keeping the aspect fixed 344288 gtk_print_operation_preview_is_selected must return a value 344386 gdk-2.0-uninstalled.pc.in and gdkconfig.h 344496 CRLF converting via Clipboard 344504 GtkPrintCapabilities not in gtktypebuiltins.h 344505 Wrong signal registration for create_custom_widget 344512 cvs build issue 344513 pdf print module's print_stream not calling destroy notify 344518 NULL unref in page setup dialogue 344543 gtk_progress_bar_pulse calls gtk_progress_bar_paint directly 344560 gtk_print_settings_[sg]et_scale shouldn't be in percent 344607 memory leaks in gtkrecentchooserdefault.c and gtkrecentchoosermenu.c 344624 Memory leak in gtk_tree_model_filter_finalize: User data not freed 337603 Possible off-by-one in gdk_pango_layout_line_get_clip_region 344239 Wrong filename for gtk-find stock item. 344528 comma at end of GtkPrintOperationAction enum causes mozilla compilation error 344290 horizontal-padding not take into account when placing submenus 344558 document print dialogue response codes 339592 Add print-to-postscript 342249 Allow to draw upper and lower sides of GtkRange's trough differently 344530 gtk_recent_chooser_widget_new_for_manager and gtk_recent_chooser_menu_new_for_manager should allow NULL manager arg * Updated translations (es,fi,gu,ko,th,wa) A list of all bugs fixed in this release can be found at: http://bugzilla.gnome.org/buglist.cgi?bug_id=153212,337491,339739,342339,343945,344148,344209,344232,344244,344288,344386,344496,344504,344505,344512,344513,344518,344543,344560,344607,344624,337603,344239,344528,344290,344558,339592,342249,344530 Thanks to everybody who has contributed to this release, in the form of bug reports or patches: Behdad Esfahbod, Bastian Nocera, Alexander Larsson, Jrg Billeter, Murray Cumming, Milosz Derezynski, Tor Lillqvist, Kazuki Iwamoto, Chris Wilson, Michael Natterer, Benjamin Berg, Marko Anastasov, Christian Persch, Masatake Yamamoto, Elijah Newren, John Finlay, Emmanuele Bassi, David Malcolm, John Darrington, Christian Weiske, Yvgen Muntyan, Martyn Russell, Kristian Rietveld June 13, 2006 Matthias Clasen From exe522@hotmail.com Tue Jun 13 09:17:01 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 1FF7B3B000A for ; Tue, 13 Jun 2006 09:17:01 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24109-07 for ; Tue, 13 Jun 2006 09:17:00 -0400 (EDT) Received: from hotmail.com (bay104-f2.bay104.hotmail.com [65.54.175.12]) by menubar.gnome.org (Postfix) with ESMTP id 4C4843B00AF for ; Tue, 13 Jun 2006 09:17:00 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 13 Jun 2006 06:16:02 -0700 Message-ID: Received: from 65.54.175.200 by by104fd.bay104.hotmail.msn.com with HTTP; Tue, 13 Jun 2006 13:15:57 GMT X-Originating-IP: [86.212.127.235] X-Originating-Email: [exe522@hotmail.com] X-Sender: exe522@hotmail.com In-Reply-To: <2672cf4d0606050752o12a6d0d2gcb4c355cc0f35d79@mail.gmail.com> From: "Malik NakaMura" To: domlachowicz@gmail.com Date: Tue, 13 Jun 2006 13:15:57 +0000 Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed X-OriginalArrivalTime: 13 Jun 2006 13:16:02.0831 (UTC) FILETIME=[851C21F0:01C68EEB] X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-0.736 tagged_above=-999 required=2 tests=[AWL=-1.532, BAYES_05=-1.11, DNS_FROM_RFC_ABUSE=0.2, DNS_FROM_RFC_POST=1.708, MSGID_FROM_MTA_HEADER=0, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -0.736 X-Spam-Level: Cc: gtk-devel-list@gnome.org Subject: Re: GTK+ >> Cocoa Native Port X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2006 13:17:01 -0000 This is my first version of _gdk_quartz_copy_to_image. The only problem is that I didnt succeed in getting the color map from "drawable"... so the image is displayed without its original colors GdkImage * _gdk_quartz_copy_to_image (GdkDrawable *drawable, GdkImage *image, gint src_x, gint src_y, gint dest_x, gint dest_y, gint width, gint height) { GdkPixbuf *pixbuf; //printf("_gdk_quartz_copy_to_image : To Implement\n"); pixbuf = NULL; image = g_object_new (gdk_image_get_type (), NULL); image->type = GDK_TYPE_IMAGE; image->width = width; image->height = height; image->byte_order = (G_BYTE_ORDER == G_LITTLE_ENDIAN) ? GDK_LSB_FIRST : GDK_MSB_FIRST; image->bpp = 4; image->bpl = image->width * image->bpp; image->bits_per_pixel = image->bpp * 8; image->colormap = (GdkColormap *)g_malloc(sizeof(GdkColormap)); memcpy(image->colormap, GDK_DRAWABLE_IMPL_QUARTZ (&(GDK_PIXMAP_IMPL_QUARTZ (drawable)->parent_instance))->colormap, sizeof(GdkColormap)); if(image->colormap != NULL) { image->visual = (GdkVisual *)g_malloc(sizeof(GdkVisual)); memcpy(image->visual, gdk_colormap_get_visual (image->colormap), sizeof(GdkVisual)); if (image->visual) { void *data; int x, y; guint32 *pix, *pixels; image->depth = image->visual->depth; image->mem = g_malloc (image->bpl * image->height); memset (image->mem, 0x00, image->bpl * image->height); data = GDK_PIXMAP_IMPL_QUARTZ (drawable)->data; pixels = (guint32 *)data; for (y = 0; y < image->height; y++) { pix = pixels+((image->height - 1 - y)*width); for (x = 0; xwidth; x++) { gdk_image_put_pixel (image, x, y, *pix); pix++; } } return image; } } g_free(image); image = NULL; return NULL; } From kloczek@rudy.mif.pg.gda.pl Tue Jun 13 09:41:41 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 2C9B33B008F for ; Tue, 13 Jun 2006 09:41:41 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24974-03 for ; Tue, 13 Jun 2006 09:41:37 -0400 (EDT) Received: from rudy.mif.pg.gda.pl (rudy.mif.pg.gda.pl [153.19.42.16]) by menubar.gnome.org (Postfix) with ESMTP id 59FF13B000C for ; Tue, 13 Jun 2006 09:41:37 -0400 (EDT) X-Virus-Scanned: at rudy.mif.pg.gda.pl Received: by rudy.mif.pg.gda.pl (plum, from userid 2732) id 39ED2233B7; Tue, 13 Jun 2006 15:40:54 +0200 (CEST) Date: Tue, 13 Jun 2006 15:40:53 +0200 (CEST) From: =?ISO-8859-2?Q?Tomasz_K=B3oczko?= To: gtk-devel-list@gnome.org Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1270146782-1150206053=:31655" X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.579 tagged_above=-999 required=2 tests=[AWL=0.022, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.579 X-Spam-Level: Subject: gtk+ 2.9.3 compilation fail X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2006 13:41:41 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1270146782-1150206053=:31655 Content-Type: TEXT/PLAIN; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 8BIT gcc -DG_DISABLE_DEPRECATED -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -o .libs/gtk-query-immodules-2.0 queryimmodules.o ./.libs/libgtk-x11-2.0.so -L/lib64 /home/users/prac/nd/kloczek/rpm/BUILD/gtk+-2.9.3/gdk/.libs/libgdk-x11-2.0.so -latk-1.0 ../gdk-pixbuf/.libs/libgdk_pixbuf-2.0.so ../gdk/.libs/libgdk-x11-2.0.so -lpangocairo-1.0 -lpango-1.0 -lcairo -lfontconfig -lXext -lXrender -lX11 -lXinerama -lXi -lXrandr -lXcursor -lXfixes /home/users/prac/nd/kloczek/rpm/BUILD/gtk+-2.9.3/gdk-pixbuf/.libs/libgdk_pixbuf-2.0.so -lgmodule-2.0 -ldl -lgobject-2.0 -lglib-2.0 -lm ./.libs/libgtk-x11-2.0.so: undefined reference to `cairo_surface_set_fallback_resolution' collect2: ld returned 1 exit status make[4]: *** [gtk-query-immodules-2.0] Error 1 make[4]: Leaving directory `/home/users/prac/nd/kloczek/rpm/BUILD/gtk+-2.9.3/gtk' $ rpm -q cairo cairo-1.1.6-6 kloczek -- ----------------------------------------------------------- *Ludzie nie maj problemw, tylko sobie sami je stwarzaj* ----------------------------------------------------------- Tomasz Koczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek@rudy.mif.pg.gda.pl* --0-1270146782-1150206053=:31655-- From federico@ximian.com Tue Jun 13 12:13:42 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 31B0B3B0071 for ; Tue, 13 Jun 2006 12:13:42 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29632-05 for ; Tue, 13 Jun 2006 12:13:41 -0400 (EDT) Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) by menubar.gnome.org (Postfix) with ESMTP id 9C36B3B000A for ; Tue, 13 Jun 2006 12:13:40 -0400 (EDT) Received: (qmail 22968 invoked from network); 13 Jun 2006 16:11:48 -0000 Received: from localhost (HELO 164-99-120-90.boston.ximian.com) (127.0.0.1) by localhost with SMTP; 13 Jun 2006 16:11:48 -0000 From: Federico Mena Quintero To: Michael Natterer In-Reply-To: <1149849193.3010.23.camel@localhost> References: <1149608483.14088.54.camel@cacharro.xalalinux.org> <1149849193.3010.23.camel@localhost> Content-Type: text/plain Date: Tue, 13 Jun 2006 11:07:30 -0500 Message-Id: <1150214850.17566.118.camel@cacharro.xalalinux.org> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.574 tagged_above=-999 required=2 tests=[AWL=0.025, BAYES_00=-2.599] X-Spam-Score: -2.574 X-Spam-Level: Cc: GTK+ development mailing list , Michael.meeks@novell.com Subject: Re: Default timeouts X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2006 16:13:42 -0000 On Fri, 2006-06-09 at 12:33 +0200, Michael Natterer wrote: > However in some places I introduced a factor of 5 so all existing > timeouts could be done with the two values from GtkSettings. > > See comment #10 of http://bugzilla.gnome.org/show_bug.cgi?id=142582 > > Actually, it may make sense to simply use the user's configured > key repeat and delay for these two setting values. What do you > think? Yeah, it makes perfect sense to make it the same as the key repeat rate. You'll then get the same rate of change whether you use the mouse or the keyboard. Federico From stefan@space.twc.de Tue Jun 13 14:33:13 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id A37933B02D9 for ; Tue, 13 Jun 2006 14:33:13 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01854-06 for ; Tue, 13 Jun 2006 14:33:08 -0400 (EDT) Received: from space.twc.de (port-83-236-178-131.static.qsc.de [83.236.178.131]) by menubar.gnome.org (Postfix) with ESMTP id 1C3EE3B00C9 for ; Tue, 13 Jun 2006 14:33:07 -0400 (EDT) Received: from stefan by space.twc.de with local (Exim 4.50) id 1FqEOs-0007KV-NR; Tue, 13 Jun 2006 21:18:06 +0200 Date: Tue, 13 Jun 2006 21:18:06 +0200 To: Tim Janik Message-ID: <20060613191806.GA28032@space.twc.de> References: <20060609152646.GE20719@space.twc.de> <200606091630.k59GUaES013244@caipclassic.rutgers.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i From: Stefan Westerfeld X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.305 tagged_above=-999 required=2 tests=[AWL=0.159, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.305 X-Spam-Level: Cc: "Kaveh R. Ghazi" , Gtk+ Developers , gcc@gcc.gnu.org Subject: Re: Problem with type safety and the "sentinel" attribute X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2006 18:33:13 -0000 Hi! On Fri, Jun 09, 2006 at 07:30:25PM +0200, Tim Janik wrote: > On Fri, 9 Jun 2006, Kaveh R. Ghazi wrote: > >> void print_string_array (const char *array_name, > >> const char *string, ...) __attribute__ > >> ((__sentinel__)); > >> > >> print_string_array ("empty_array", NULL); /* gcc warns, but shouldn't > >*/ > >> > >> The only way out for keeping the sentinel attribute and avoiding the > >> warning is using > >> > >> static void print_string_array (const char *array_name, ...) > >> __attribute__ ((__sentinel__)); > > > >I think you could maintain typesafety and silence the warning by > >keeping the more specific prototype and adding an extra NULL, e.g.: > > > >print_string_array ("empty_array", NULL, NULL); > > > >Doesn't seem elegant, but it does the job. > > this is an option for a limited set of callers, yes. For the statistics, by adding the __sentinel__ attribute to the beast codebase, I have about 50 of those sentinel warnings that I don't need. So the double NULL termination would make quite some code more messy than it should be. > >> By the way, there is already an existing gcc bug, which is about the > >> same thing (NULL passed within named args), but wants to have it the > >> way it works now: > >> > >> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21911 > > > >Correct, the feature as I envisioned it expected the sentinel to > >appear in the variable arguments only. This PR reflects when I found > >out it didn't do that and got around to fixing it. Note the "buggy" > >behavior wasn't exactly what you wanted either because GCC got fooled > >by a sentinel in *any* of the named arguments, not just the last one. Ah, I see. > >> so if it gets changed, then gcc might need to support both > >> - NULL termination within the last named parameter allowed > >> - NULL termination only allowed within varargs parameters (like it is > >> now) > > > >I'm not against this enhancement, but you need to specify a syntax > >that allows the old behavior but also allows doing it your way. > > > >Hmm, perhaps we could check for attribute "nonnull" on the last named > >argument, if it exists then that can't be the sentinel, if it's not > >there then it does what you want. This is not completely backwards > >compatible because anyone wanting the existing behavior has to add the > >attribute nonnull. But there's precedent for this when attribute > >printf split out whether the format specifier could be null... > > > >We could also create a new attribute name for the new behavior. This > >would preserve backwards compatibility. I like this idea better. > > i agree here. as far as the majority of the GLib and Gtk+ APIs are > concerned, > we don't really need the flexibility of the sentinel attribute but rather > a compiler check on whether the last argument used in a function call > is NULL or 0 (regardless of whether it's the last named arg or already part > of the varargs list). > that's also why the actual sentinel wrapper in GLib looks like this: > > #define G_GNUC_NULL_TERMINATED __attribute__((__sentinel__)) > > so, if i was to make a call on this issue, i'd either introduce > __attribute__((__null_terminated__)) with the described semantics, > or have __attribute__((__sentinel__(-1))) work essentially like > __attribute__((__sentinel__(0))) while also accepting 0 in the position > of the last named argument. I also like the backwards compatible way better than trying to somehow modifying the attribute; it may break something now, or - which would also be bad - it may make something that somebody will want to check with the sentinel attribute in some future program impossible. The only case that I ever needed was NULL termination, so I think implementing one of the two proposals Tim made would be sufficient. Personally I like __attribute__((__null_terminated__)) better, because a -1 sentinel may be less intuitive to read in the source code. So this would be my suggestion for a "syntax specification". > >Next you need to recruit someone to implement this enhancement, or > >submit a patch. :-) Although given that you can silence the warning by > >adding an extra NULL at the call site, I'm not sure it's worth it. > > i would say this is definitely worth it, because the issue also shows up in > other code that is widely used: > gpointer g_object_new (GType object_type, > const gchar *first_property_name, > ...); > that's for instance a function which is called in many projects. > putting the burden on the caller is clearly the wrong trade off here. > > so please take this as a vote for the worthiness of a fix ;) Good. Of course I would be happy if somebody with knowledge of the compiler source could implement it. I never hacked gcc code before. But since you suggested sending a patch, I'll at least try to implement a new __null_terminated__ attribute, and ask for help if I can't figure out what to do. Cu... Stefan -- Stefan Westerfeld, Hamburg/Germany, http://space.twc.de/~stefan From easy-b@freesurf.ch Tue Jun 13 16:37:46 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 1FEC53B03CF for ; Tue, 13 Jun 2006 16:37:46 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05861-06 for ; Tue, 13 Jun 2006 16:37:45 -0400 (EDT) Received: from mail-fs.sunrise.ch (mta-fs-be-01.sunrise.ch [194.158.229.16]) by menubar.gnome.org (Postfix) with ESMTP id B948D3B00C8 for ; Tue, 13 Jun 2006 16:37:44 -0400 (EDT) Received: from [10.0.1.2] (84.226.131.17) by mail-fs.sunrise.ch (7.2.073) id 44795C850064786C; Tue, 13 Jun 2006 22:36:45 +0200 In-Reply-To: <89C1D6F0-EDC8-495C-B76B-9909E6388E62@freesurf.ch> References: <20060522160033.F1A8E3B1CE4@menubar.gnome.org> <772588ED-500A-4A11-8829-DA80B9A35D1F@freesurf.ch> <44720B8C.3080903@imendio.com> <0A34FCC9-6650-4737-B86D-1B503D8A9072@freesurf.ch> <7D6367DC-8689-453B-8FD7-217632BC1DAE@freesurf.ch> <89C1D6F0-EDC8-495C-B76B-9909E6388E62@freesurf.ch> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2B5653F8-341D-440C-9D5C-F166B296F94E@freesurf.ch> Content-Transfer-Encoding: 7bit From: Easy B Date: Tue, 13 Jun 2006 22:36:44 +0200 To: Gregor Riepl X-Mailer: Apple Mail (2.749.3) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-0.997 tagged_above=-999 required=2 tests=[AWL=-0.549, BAYES_00=-2.599, DNS_FROM_RFC_POST=1.708, FORGED_RCVD_HELO=0.135, TW_BG=0.077, TW_GD=0.077, TW_GT=0.077, TW_PK=0.077] X-Spam-Score: -0.997 X-Spam-Level: Cc: gtk-devel-list@gnome.org Subject: Re: Mac OS X Framework X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2006 20:37:46 -0000 Hi So i understand that we only need to link against one library that is linked to all the other ones, right? If I look at libgtk-quartz-2.0.dylib I see following: libgtk-quartz-2.0.dylib: /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libgtk-quartz-2.0.0.dylib (compatibility version 902.0.0, current version 902.0.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libgdk_pixbuf-2.0.0.dylib (compatibility version 902.0.0, current version 902.0.0) /usr/lib/libiconv.2.dylib (compatibility version 5.0.0, current version 5.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.1.5) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libgdk-quartz-2.0.0.dylib (compatibility version 902.0.0, current version 902.0.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libpangoft2-1.0.0.dylib (compatibility version 1301.0.0, current version 1301.1.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libpng12.0.dylib (compatibility version 11.0.0, current version 11.0.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libfontconfig.1.dylib (compatibility version 2.0.0, current version 2.4.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libfreetype.6.dylib (compatibility version 10.0.0, current version 10.8.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libxml2.2.dylib (compatibility version 9.0.0, current version 9.24.0) /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.3) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libpangocairo-1.0.0.dylib (compatibility version 1301.0.0, current version 1301.1.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libpango-1.0.0.dylib (compatibility version 1301.0.0, current version 1301.1.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libatk-1.0.0.dylib (compatibility version 1115.0.0, current version 1115.0.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libgobject-2.0.0.dylib (compatibility version 1102.0.0, current version 1102.0.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libgmodule-2.0.0.dylib (compatibility version 1102.0.0, current version 1102.0.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libglib-2.0.0.dylib (compatibility version 1102.0.0, current version 1102.0.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libcairo.2.dylib (compatibility version 9.0.0, current version 9.0.0) /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ libintl.3.dylib (compatibility version 8.0.0, current version 8.3.0) So I guess everything what we need is there. But I don't really get how to satisfy configure of a gtk app so that it only uses "- framework Gtk+". Sorry for my ignorance I'm pretty much a newbe on these things. Cheers, Ezra. On 12.06.2006, at 08:47, Gregor Riepl wrote: >> Thanx for the Tips. This would make the Framework more like one. >> The ability to include it into the application bundle would be >> very handy. >> >> If I look at other Frameworks I always find a single library in >> the top directory, for example: >> >> /System/Library/Frameworks/ApplicationServices.framework/Versions/ >> A/Frameworks/ImageIO.framework/ImageIO > that's right, this is the dynamic library itself. it doesn't have > the dylib suffix, but you may specify one if you like. > executables need to be linked against that, then, just -framework X > doesn't work. on the other hand, it's a good idea to either make > the "main" library (like libgtk-2.0.0.dylib) the framework (and > include all dependent libraries as either frameworks on their own > or dylibs) or just create an empty stub library that links against > those libraries or frameworks. to do that, make an empty .c source, > compile and link it against all the dylibs/frameworks you need. but > i can't tell if that's a good idea. > >> If I do "otool -L /System/Library/Frameworks/ >> ApplicationServices.framework/Versions/A/Frameworks/ >> ImageIO.framework/ImageIO", I get references to many other >> libraries that are located inside the framework bundle: > i guess that would be such a stub library, but maybe there's other > functionality contained? > otool can help you getting the symbols from mach-o binaries, much > like objdump. > >> In my Gtk+.framework I have tons of libraries. Would it be >> possible to create something like the above for gtk? Would it make >> sense? Right now I just use pkg-config to find the libraries and >> the result looks like this: >> >> /Applications/Shity Apps/Gtk-Demo.app/Contents/MacOS/gtk-demo: >> /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ >> libgdk_pixbuf-2.0.0.dylib (compatibility version 902.0.0, current >> version 902.0.0) >> ....... >> /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ >> libintl.3.dylib (compatibility version 8.0.0, current version 8.3.0) >> >> What do you think? > you should use /Library/Frameworks/Gtk+.framework/Versions/2.9.1/Gtk > + as the main library. it doesn't matter if that's just a stub or > the last library in the build chain (yes, i don't see > libgtk-2.0.0.dylib anywhere?). binaries then wouldn't require to be > linked against all those libs mentioned above. > this way you can also link gtk software with -framework Gtk+ and > nothing else, which you could even move into the pkconfig file and > thus facilitate porting. > i did something similar with the readily-available SDL framework > fpr mac os x, but it doesn't work very well because of the missing > startup code. with gtk it's easier i guess. > > have a nice day > gregor > > p.s.: on second thought, there could be a problem. afaik if a > binary loads a dylib, only that dylib's symbols become available > for it. the dependent symbols from libs that dylib's linked against > stay local for that dylib... maybe there's a workaround for this or > you come up with a better idea? From ntd@users.sourceforge.net Thu Jun 15 04:25:32 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 382C53B0324 for ; Thu, 15 Jun 2006 04:25:32 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22415-07 for ; Thu, 15 Jun 2006 04:25:29 -0400 (EDT) Received: from mailout01.albacom.net (mailout01.albacom.net [217.220.34.13]) by menubar.gnome.org (Postfix) with SMTP id 0694D3B0311 for ; Thu, 15 Jun 2006 04:25:28 -0400 (EDT) Received: (qmail 13668 invoked by uid 508); 15 Jun 2006 08:25:00 -0000 Received: from ntd@users.sourceforge.net by mailout01.albacom.net with qmail-scanner (spamassassin: ???. Clear:RC:1(217.221.76.9):SA:0(0.0/15.0):. Processed in 0.697195 secs); 15 Jun 2006 08:25:00 -0000 Received: from unknown (HELO sviluppo.internet.local) (postmaster@effe-gi.it@217.221.76.9) by mailout01.albacom.net with SMTP; 15 Jun 2006 08:24:59 -0000 Content-Disposition: inline From: Fontana Nicola Organization: Elettronica EFFE-GI s.n.c. To: gtk-devel-list@gnome.org Subject: GObject extension propose (GContainer) Date: Thu, 15 Jun 2006 11:01:12 +0000 User-Agent: KMail/1.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200606151101.12868.ntd@users.sourceforge.net> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.599 tagged_above=-999 required=2 tests=[BAYES_00=-2.599] X-Spam-Score: -2.599 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 08:25:32 -0000 Hi all, I'm a GObject based libraries (for UI purpose and not) user and I often need a generic container to derive my own types. In my opinion, I think this generic container must be included inside the GObject library ... it could be used by a lot of derived libraries providing a common approach. I published my solution - that is, what I am currently using - on sourceforge. http://sourceforge.net/projects/gcontainer/ Is it a good idea? Is something planned in this direction? Am I totally wrong? I need feedbacks ... Nicola From mclasen@redhat.com Thu Jun 15 09:54:37 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 88F2B3B00F3 for ; Thu, 15 Jun 2006 09:54:37 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14500-10 for ; Thu, 15 Jun 2006 09:54:36 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id 12BF23B0261 for ; Thu, 15 Jun 2006 09:54:36 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5FDsZ1W022208 for ; Thu, 15 Jun 2006 09:54:35 -0400 Received: from lacrosse.corp.redhat.com (lacrosse.corp.redhat.com [172.16.52.154]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5FDsZa4019641 for ; Thu, 15 Jun 2006 09:54:35 -0400 Received: from [172.16.83.98] (dhcp83-98.boston.redhat.com [172.16.83.98]) by lacrosse.corp.redhat.com (8.12.11.20060308/8.11.6) with ESMTP id k5FDsZL7008811 for ; Thu, 15 Jun 2006 09:54:35 -0400 Subject: GTK+ 2.10, the endgame From: Matthias Clasen To: gtk-devel-list@gnome.org Content-Type: text/plain Organization: Red Hat Date: Thu, 15 Jun 2006 09:56:26 -0400 Message-Id: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> Mime-Version: 1.0 X-Mailer: Evolution 2.7.3 (2.7.3-2) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.542 tagged_above=-999 required=2 tests=[AWL=0.059, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.542 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 13:54:37 -0000 I want to have GTK+ 2.10 ready at or immediately after GUADEC. I did not declare 2.9.3 api frozen in the release announcement, because we were still holding the door open for Kris' work on the new tooltips api. But he has run into some difficulties with the implementation which will take some time to overcome, so we have decided to punt this feature and try to get it into 2.12 early. Therefore, I want to consider 2.9.3 api frozen, and take a look at what still needs to happen before 2.10. Here are some things I personally would like get worked on (not sure how much time I can free to look into these myself): - I think the async filechooser conversion has caused some regressions, I noticed that .hidden support seems broken and autocompletion also behaved badly for me recently. - There is a number of FIXMEs and unimplemented bits in the print code. - The print backends need a careful look wrt to memory leaks and error reporting. Are there other important bugs or regressions that need attention before 2.10 ? Another thing I have slacked off about is organizing a GTK+ team meeting at GUADEC. So, who of the GTK+ team is there and at what times ? Should we try to find a free hour during the core days, or does everybody stay for the after hours ? If so, it may be easier to do a team meeting on Thursday... Matthias From timj@gtk.org Thu Jun 15 10:53:17 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id BBF963B04EA for ; Thu, 15 Jun 2006 10:53:17 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17592-10 for ; Thu, 15 Jun 2006 10:53:16 -0400 (EDT) Received: from holken.mikan.net (holken.mikan.net [83.145.56.183]) by menubar.gnome.org (Postfix) with ESMTP id 035EF3B04E7 for ; Thu, 15 Jun 2006 10:53:15 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by holken.mikan.net (Postfix) with ESMTP id C0DB83352B4; Thu, 15 Jun 2006 16:52:21 +0200 (CEST) Received: from holken.mikan.net ([127.0.0.1]) by localhost (holken.mikan.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16765-03; Thu, 15 Jun 2006 16:52:18 +0200 (CEST) Received: from birnet.org (c152167.adsl.hansenet.de [213.39.152.167]) by holken.mikan.net (Postfix) with ESMTP id E3B0433529D; Thu, 15 Jun 2006 16:52:17 +0200 (CEST) Received: from master.birnet.private (localhost.localdomain [127.0.0.1]) by birnet.org (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k5FEqH2d008152 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 15 Jun 2006 16:52:18 +0200 Received: (from timj@localhost) by master.birnet.private (8.13.4/8.13.4/Submit) id k5FEqHpN008151; Thu, 15 Jun 2006 16:52:17 +0200 Date: Thu, 15 Jun 2006 16:52:17 +0200 (CEST) From: Tim Janik X-X-Sender: timj@master.birnet.private To: Fontana Nicola Subject: Re: GObject extension propose (GContainer) In-Reply-To: <200606151101.12868.ntd@users.sourceforge.net> Message-ID: References: <200606151101.12868.ntd@users.sourceforge.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at holken.mikan.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.38 tagged_above=-999 required=2 tests=[AWL=0.084, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.38 X-Spam-Level: Cc: Gtk+ Developers X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 14:53:17 -0000 On Thu, 15 Jun 2006, Fontana Nicola wrote: > Hi all, > > I'm a GObject based libraries (for UI purpose and not) user and I often need > a generic container to derive my own types. In my opinion, I think this > generic container must be included inside the GObject library ... it could > be used by a lot of derived libraries providing a common approach. > > I published my solution - that is, what I am currently using - on > sourceforge. > > http://sourceforge.net/projects/gcontainer/ > > Is it a good idea? Is something planned in this direction? Am I totally > wrong? > > I need feedbacks ... hi. your gcontainer-1.0.0 looks like an interesting approach to me, but i'm not sure it's generally good to put that into stock libgobject. the main reason is that container needs are probably pretty variable out there (i've come across at least 4 different gobject container implementations in free software projects i'm woorking on) and that both, making too little assumptions in the child/container interface isn't going to be very helpful, albeit making too many has the same problem. i guess we could add a link to your project from the libgobject docs (it should probably have a Contrib section), for people possibly looking for a GObject container implementation. that way, gcontainer-1.0.0 gets a chance of being reused and maybe extended to something generally usefull for GObject applications out there. > Nicola --- ciaoTJ From timj@gtk.org Thu Jun 15 11:31:19 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 642E33B02ED for ; Thu, 15 Jun 2006 11:31:19 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19431-03 for ; Thu, 15 Jun 2006 11:31:18 -0400 (EDT) Received: from holken.mikan.net (holken.mikan.net [83.145.56.183]) by menubar.gnome.org (Postfix) with ESMTP id 2E9543B0155 for ; Thu, 15 Jun 2006 11:31:18 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by holken.mikan.net (Postfix) with ESMTP id B5DB533524B; Thu, 15 Jun 2006 16:32:01 +0200 (CEST) Received: from holken.mikan.net ([127.0.0.1]) by localhost (holken.mikan.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16412-10; Thu, 15 Jun 2006 16:31:58 +0200 (CEST) Received: from birnet.org (c152167.adsl.hansenet.de [213.39.152.167]) by holken.mikan.net (Postfix) with ESMTP id D5D7E335256; Thu, 15 Jun 2006 16:31:57 +0200 (CEST) Received: from master.birnet.private (localhost.localdomain [127.0.0.1]) by birnet.org (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k5FEVrL1007682 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 15 Jun 2006 16:31:53 +0200 Received: (from timj@localhost) by master.birnet.private (8.13.4/8.13.4/Submit) id k5FEVis7007681; Thu, 15 Jun 2006 16:31:45 +0200 Date: Thu, 15 Jun 2006 16:31:44 +0200 (CEST) From: Tim Janik X-X-Sender: timj@master.birnet.private To: Matthias Clasen Subject: GTK+ meeting at GUADEC (Re: GTK+ 2.10, the endgame) In-Reply-To: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> Message-ID: References: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at holken.mikan.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.381 tagged_above=-999 required=2 tests=[AWL=0.083, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.381 X-Spam-Level: Cc: Gtk+ Developers X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 15:31:19 -0000 On Thu, 15 Jun 2006, Matthias Clasen wrote: > I want to have GTK+ 2.10 ready at or immediately after GUADEC. > Another thing I have slacked off about is organizing a GTK+ > team meeting at GUADEC. So, who of the GTK+ team is there > and at what times ? Should we try to find a free hour during > the core days, or does everybody stay for the after hours ? > If so, it may be easier to do a team meeting on Thursday... i think i volounteered to take on arrangement of that to some extend. at least, we intended to have a meeting on GTK+ linking issues, and could probably merge that with the GTK+ team meeting during guadec. the plan for that was to send out en email next friday/saturday (i.e right at the guadec start) to figure/suggest dates suitable for everyone to attend. > Matthias --- ciaoTJ From hfiguiere@teaser.fr Thu Jun 15 11:52:14 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C00CA3B0261 for ; Thu, 15 Jun 2006 11:52:14 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20706-05 for ; Thu, 15 Jun 2006 11:52:13 -0400 (EDT) Received: from xandros.com (smtp1.xandros.com [209.87.238.70]) by menubar.gnome.org (Postfix) with ESMTP id 6D7663B053A for ; Thu, 15 Jun 2006 11:52:13 -0400 (EDT) Received: from [172.16.1.95] (unknown [209.87.238.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by xandros.com (Postfix) with ESMTP id 4B02239025; Thu, 15 Jun 2006 11:51:30 -0400 (EDT) Message-ID: <44918201.6010605@teaser.fr> Date: Thu, 15 Jun 2006 11:51:29 -0400 From: Hubert Figuiere User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: Matthias Clasen Subject: Re: GTK+ 2.10, the endgame References: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> In-Reply-To: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.54 tagged_above=-999 required=2 tests=[AWL=0.059, BAYES_00=-2.599] X-Spam-Score: -2.54 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 15:52:14 -0000 Matthias Clasen wrote: > I want to have GTK+ 2.10 ready at or immediately after GUADEC. Can somebody summarize the Mac port status? Hub From tristan.van.berkom@gmail.com Thu Jun 15 12:44:57 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 0A0273B05DC for ; Thu, 15 Jun 2006 12:44:57 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23203-02 for ; Thu, 15 Jun 2006 12:44:56 -0400 (EDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.200]) by menubar.gnome.org (Postfix) with ESMTP id 0AD9C3B007F for ; Thu, 15 Jun 2006 12:44:55 -0400 (EDT) Received: by wx-out-0102.google.com with SMTP id i30so312681wxd for ; Thu, 15 Jun 2006 09:44:14 -0700 (PDT) Received: by 10.70.100.8 with SMTP id x8mr2494520wxb; Thu, 15 Jun 2006 09:44:14 -0700 (PDT) Received: from ?66.48.170.37? ( [66.48.170.37]) by mx.gmail.com with ESMTP id i39sm1649326wxd.2006.06.15.09.44.12; Thu, 15 Jun 2006 09:44:14 -0700 (PDT) Message-ID: <44919246.8060301@gnome.org> Date: Thu, 15 Jun 2006 13:00:54 -0400 User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Janik Subject: Re: GObject extension propose (GContainer) References: <200606151101.12868.ntd@users.sourceforge.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit From: Tristan Van Berkom X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.481 tagged_above=-999 required=2 tests=[AWL=-0.414, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=1.456, SPF_PASS=-0.001, TW_GT=0.077] X-Spam-Score: -1.481 X-Spam-Level: Cc: Gtk+ Developers X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 16:44:57 -0000 Tim Janik wrote: >On Thu, 15 Jun 2006, Fontana Nicola wrote: > > > >>Hi all, >> >>I'm a GObject based libraries (for UI purpose and not) user and I often need >>a generic container to derive my own types. In my opinion, I think this >>generic container must be included inside the GObject library ... it could >>be used by a lot of derived libraries providing a common approach. >> >>I published my solution - that is, what I am currently using - on >>sourceforge. >> >>http://sourceforge.net/projects/gcontainer/ >> >>Is it a good idea? Is something planned in this direction? Am I totally >>wrong? >> >>I need feedbacks ... >> >> As a side note... I've been working on container --> child relationships and honing them down inside the glade builder... objects may for example have object delagates that are "owned" and in turn may "own" other delagates... this is all functional with libglade facilities and the future gtk builder also (from the design as of yet...)... this concept of "types of container relationships" is also usefull for GtkMenuShell --> GtkMenu for example (not just any GtkWidget can be added to a menushell). All of that just to say... I cannot count the times I've thought to myself that GtkContainer should really just be GContainerIface, and implemented by whatever interested objects that want to parent other objects... I think that what we need is not really "yet another container api", but a container api that is a unified front for generic handling of the GTK object hierarchy at runtime. Cheers, -Tristan From federico@ximian.com Thu Jun 15 12:56:13 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 0DAD63B03FF for ; Thu, 15 Jun 2006 12:56:13 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23665-06 for ; Thu, 15 Jun 2006 12:56:06 -0400 (EDT) Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) by menubar.gnome.org (Postfix) with ESMTP id 688823B0613 for ; Thu, 15 Jun 2006 12:56:05 -0400 (EDT) Received: (qmail 25104 invoked from network); 15 Jun 2006 16:54:53 -0000 Received: from localhost (HELO 164-99-120-38.boston.ximian.com) (127.0.0.1) by localhost with SMTP; 15 Jun 2006 16:54:53 -0000 Subject: Re: GTK+ 2.10, the endgame From: Federico Mena Quintero To: Matthias Clasen In-Reply-To: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> References: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> Content-Type: text/plain Date: Thu, 15 Jun 2006 11:50:29 -0500 Message-Id: <1150390229.17566.191.camel@cacharro.xalalinux.org> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.575 tagged_above=-999 required=2 tests=[AWL=0.024, BAYES_00=-2.599] X-Spam-Score: -2.575 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 16:56:13 -0000 On Thu, 2006-06-15 at 09:56 -0400, Matthias Clasen wrote: > Therefore, I want to consider 2.9.3 api frozen, and take a > look at what still needs to happen before 2.10. Here are some > things I personally would like get worked on (not sure > how much time I can free to look into these myself): > > - I think the async filechooser conversion has caused some > regressions, I noticed that .hidden support seems broken > and autocompletion also behaved badly for me recently. Yes, it's quite broken at the moment. I don't think we can do any more productive debugging (fixing something breaks something else) until we have a good set of automated tests for the basic behaviors. > - There is a number of FIXMEs and unimplemented bits in > the print code. > > - The print backends need a careful look wrt to memory leaks > and error reporting. I'm rather worried of declaring the printing API as stable and just unleashing it to the world. Is any software *really* using it? Does it contemplate things like - sites with thousands of printers - sites which want to lock-down certain printers - color management for apps that need it > Another thing I have slacked off about is organizing a GTK+ > team meeting at GUADEC. So, who of the GTK+ team is there > and at what times ? Should we try to find a free hour during > the core days, or does everybody stay for the after hours ? > If so, it may be easier to do a team meeting on Thursday... I'll be there since Sunday morning. Thursday is the Advisory Board meeting, so I'm afraid I won't have that day free for the GTK+ meeeting. Federico From mclasen@redhat.com Thu Jun 15 13:15:33 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id BC2163B0187 for ; Thu, 15 Jun 2006 13:15:33 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24531-03 for ; Thu, 15 Jun 2006 13:15:29 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id DCC933B0227 for ; Thu, 15 Jun 2006 13:15:28 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5FHDjVa014384; Thu, 15 Jun 2006 13:13:45 -0400 Received: from lacrosse.corp.redhat.com (lacrosse.corp.redhat.com [172.16.52.154]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5FHDjmo017834; Thu, 15 Jun 2006 13:13:45 -0400 Received: from [172.16.83.98] (dhcp83-98.boston.redhat.com [172.16.83.98]) by lacrosse.corp.redhat.com (8.12.11.20060308/8.11.6) with ESMTP id k5FHDjGC025752; Thu, 15 Jun 2006 13:13:45 -0400 Subject: Re: GTK+ 2.10, the endgame From: Matthias Clasen To: Federico Mena Quintero In-Reply-To: <1150390229.17566.191.camel@cacharro.xalalinux.org> References: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> <1150390229.17566.191.camel@cacharro.xalalinux.org> Content-Type: text/plain Organization: Red Hat Date: Thu, 15 Jun 2006 13:15:37 -0400 Message-Id: <1150391737.3187.33.camel@dhcp83-98.boston.redhat.com> Mime-Version: 1.0 X-Mailer: Evolution 2.7.3 (2.7.3-2) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.542 tagged_above=-999 required=2 tests=[AWL=0.059, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.542 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 17:15:33 -0000 On Thu, 2006-06-15 at 11:50 -0500, Federico Mena Quintero wrote: > On Thu, 2006-06-15 at 09:56 -0400, Matthias Clasen wrote: > > > Therefore, I want to consider 2.9.3 api frozen, and take a > > look at what still needs to happen before 2.10. Here are some > > things I personally would like get worked on (not sure > > how much time I can free to look into these myself): > > > > - I think the async filechooser conversion has caused some > > regressions, I noticed that .hidden support seems broken > > and autocompletion also behaved badly for me recently. > > Yes, it's quite broken at the moment. I don't think we can do any more > productive debugging (fixing something breaks something else) until we > have a good set of automated tests for the basic behaviors. Quite unfortunate. We spent too much time working on finetuning the filechooser behaviour to leave it broken now... > > - There is a number of FIXMEs and unimplemented bits in > > the print code. > > > > - The print backends need a careful look wrt to memory leaks > > and error reporting. > > I'm rather worried of declaring the printing API as stable and just > unleashing it to the world. Is any software *really* using it? Does it > contemplate things like Typical chicken and egg problem that won't be solved by keeping it unreleased for another year. There is no way to get any software _really_ using it without releasing it first. We got quite a bit of feedback from people looking at porting real apps to it (e.g gedit, OOo and epiphany), so it is not as if we release it straight from the whiteboard. > - sites with thousands of printers > > - sites which want to lock-down certain printers > > - color management for apps that need it No doubt that we may have to add new api in 2.12 to accomodate things like this, but all of these are special cases. From muntyan@tamu.edu Thu Jun 15 15:05:44 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 9364F3B0605 for ; Thu, 15 Jun 2006 15:05:44 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28754-04 for ; Thu, 15 Jun 2006 15:05:41 -0400 (EDT) Received: from smtp103.vzn.mail.mud.yahoo.com (smtp103.vzn.mail.mud.yahoo.com [68.142.203.47]) by menubar.gnome.org (Postfix) with SMTP id 568873B05C3 for ; Thu, 15 Jun 2006 15:05:40 -0400 (EDT) Received: (qmail 34334 invoked from network); 15 Jun 2006 19:05:00 -0000 Received: from unknown (HELO ?192.168.3.9?) (muntyan@verizon.net@71.113.224.59 with plain) by smtp103.vzn.mail.mud.yahoo.com with SMTP; 15 Jun 2006 19:04:59 -0000 Message-ID: <4491AF5A.2050702@tamu.edu> Date: Thu, 15 Jun 2006 14:04:58 -0500 From: Yevgen Muntyan User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20060216 Debian/1.7.12-1.1ubuntu2 X-Accept-Language: en MIME-Version: 1.0 To: GTK Devel List Subject: Printing and blocking ui Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.552 tagged_above=-999 required=2 tests=[AWL=0.047, BAYES_00=-2.599] X-Spam-Score: -2.552 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 19:05:44 -0000 Hi there, I print a text document from GtkTextView here. There is a problem with pagination: pagination is potentially slow, so some sort of progress dialog should be shown during it. From the other hand, the text buffer must not be modified during pagination. How to solve it? Should I show my own modal dialog and make sure user doesn't modify the buffer, or GtkPrintOperation can take care of it? Actually, it would be good to ensure printing blocks the text widget too, since in this case it wouldn't be necessary to calculate and store all the pango layouts in begin-print. Maybe just show a modal dialog between begin-print and end-print. Thanks, Yevgen From richard@imendio.com Thu Jun 15 15:08:15 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C90B13B02BF for ; Thu, 15 Jun 2006 15:08:15 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28754-07 for ; Thu, 15 Jun 2006 15:08:14 -0400 (EDT) Received: from holken.mikan.net (holken.mikan.net [83.145.56.183]) by menubar.gnome.org (Postfix) with ESMTP id 47EFB3B018C for ; Thu, 15 Jun 2006 15:08:14 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by holken.mikan.net (Postfix) with ESMTP id 418C111EB4; Thu, 15 Jun 2006 21:07:02 +0200 (CEST) Received: from holken.mikan.net ([127.0.0.1]) by localhost (holken.mikan.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04160-07; Thu, 15 Jun 2006 21:06:58 +0200 (CEST) Received: from [192.168.100.5] (c83-248-134-21.bredband.comhem.se [83.248.134.21]) by holken.mikan.net (Postfix) with ESMTP id E679E1459D; Thu, 15 Jun 2006 21:06:57 +0200 (CEST) Message-ID: <4491AFD0.5000408@imendio.com> Date: Thu, 15 Jun 2006 21:06:56 +0200 From: Richard Hult Organization: Imendio AB User-Agent: Thunderbird 1.5.0.4 (Macintosh/20060530) MIME-Version: 1.0 To: Hubert Figuiere Subject: Re: GTK+ 2.10, the endgame References: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> <44918201.6010605@teaser.fr> In-Reply-To: <44918201.6010605@teaser.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at holken.mikan.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.543 tagged_above=-999 required=2 tests=[AWL=0.056, BAYES_00=-2.599] X-Spam-Score: -2.543 X-Spam-Level: Cc: gtk-devel-list@gnome.org, Matthias Clasen X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 19:08:16 -0000 Hubert Figuiere skrev: > Matthias Clasen wrote: >> I want to have GTK+ 2.10 ready at or immediately after GUADEC. > > Can somebody summarize the Mac port status? The basic functionality is implemented and what's next in the pipeline is bug fixing, and after that looking into tighter integration with the platform in various areas. /Richard From muntyan@tamu.edu Thu Jun 15 15:12:58 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 9FC7E3B063D for ; Thu, 15 Jun 2006 15:12:58 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29079-06 for ; Thu, 15 Jun 2006 15:12:57 -0400 (EDT) Received: from smtp101.vzn.mail.mud.yahoo.com (smtp101.vzn.mail.mud.yahoo.com [68.142.203.45]) by menubar.gnome.org (Postfix) with SMTP id E72693B0613 for ; Thu, 15 Jun 2006 15:12:56 -0400 (EDT) Received: (qmail 97288 invoked from network); 15 Jun 2006 19:11:44 -0000 Received: from unknown (HELO ?192.168.3.9?) (muntyan@verizon.net@71.113.224.59 with plain) by smtp101.vzn.mail.mud.yahoo.com with SMTP; 15 Jun 2006 19:11:43 -0000 Message-ID: <4491B0EE.3040900@tamu.edu> Date: Thu, 15 Jun 2006 14:11:42 -0500 From: Yevgen Muntyan User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20060216 Debian/1.7.12-1.1ubuntu2 X-Accept-Language: en MIME-Version: 1.0 To: gtk-devel-list@gnome.org Subject: Re: GTK+ 2.10, the endgame References: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> <1150390229.17566.191.camel@cacharro.xalalinux.org> In-Reply-To: <1150390229.17566.191.camel@cacharro.xalalinux.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.514 tagged_above=-999 required=2 tests=[AWL=0.008, BAYES_00=-2.599, TW_GT=0.077] X-Spam-Score: -2.514 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 19:12:58 -0000 Federico Mena Quintero wrote: >On Thu, 2006-06-15 at 09:56 -0400, Matthias Clasen wrote: > > >>- The print backends need a careful look wrt to memory leaks >> and error reporting. >> >> > >I'm rather worried of declaring the printing API as stable and just >unleashing it to the world. Is any software *really* using it? > > Yes, there is software which is going to use gtk printing as soon as gtk-2.10 is released. And there will be much more when gtk has printing. Just think for a moment about gtk-but-not-gnome applications (win32 comes to mind too). > - sites with thousands of printers > > - sites which want to lock-down certain printers > > - color management for apps that need it > > If gtk can print to a single user's printer, it's already worth releasing. Again, there are applications which do not have printing, because they can't use gnomeprint, and developers don't feel like implement their own printing while gtk is going to get it. IMHO, etc., you know. Best regards, Yevgen From gnome-gtk-devel-list@m.gmane.org Thu Jun 15 16:40:15 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 2360D3B00D0 for ; Thu, 15 Jun 2006 16:40:15 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32360-05 for ; Thu, 15 Jun 2006 16:40:13 -0400 (EDT) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by menubar.gnome.org (Postfix) with ESMTP id 3B9113B0237 for ; Thu, 15 Jun 2006 16:40:13 -0400 (EDT) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1FqydG-0004Vk-6i for gtk-devel-list@gnome.org; Thu, 15 Jun 2006 22:40:02 +0200 Received: from cpe0004e2d9f884-cm0013718690da.cpe.net.cable.rogers.com ([70.24.212.140]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 15 Jun 2006 22:40:02 +0200 Received: from jasonspiro4+news by cpe0004e2d9f884-cm0013718690da.cpe.net.cable.rogers.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 15 Jun 2006 22:40:02 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gtk-devel-list@gnome.org From: Jason Spiro Subject: Imagine: what if points in Bugzilla had a significant effect? Date: Thu, 15 Jun 2006 19:15:34 +0000 (UTC) Lines: 15 Message-ID: X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cpe0004e2d9f884-cm0013718690da.cpe.net.cable.rogers.com User-Agent: slrn/0.9.8.1pl1 (Debian) Sender: news X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.601 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.601 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 20:40:15 -0000 Imagine: what if points did something in Bugzilla, like, the more points you have, the more votes you get? I think this would encourage people to file more bug reports, both good bug reports and not-so-good ones. Would that be a net gain or a net loss for GTK+? Regards, Jason Spiro -- Jason Spiro: computer consulting with a smile. Specializing in Linux: Red Hat AS / ES, Debian, and others. Serving homes and companies globally via remote access tools. Fair rates. Just email jasonspiro4@gmail.com or call Skype ID jasonspiro. From murrayc@murrayc.com Fri Jun 16 04:53:13 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id D68413B0007 for ; Fri, 16 Jun 2006 04:53:12 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23115-03 for ; Fri, 16 Jun 2006 04:53:08 -0400 (EDT) Received: from swarthymail-a5.dreamhost.com (sd-green-bigip-176.dreamhost.com [208.97.132.176]) by menubar.gnome.org (Postfix) with ESMTP id 7FA303B006C for ; Fri, 16 Jun 2006 04:53:08 -0400 (EDT) Received: from noname (p5497E1BF.dip.t-dialin.net [84.151.225.191]) by swarthymail-a5.dreamhost.com (Postfix) with ESMTP id 69FE4109E8B; Fri, 16 Jun 2006 01:52:14 -0700 (PDT) Subject: Re: GTK+ 2.10, the endgame From: Murray Cumming To: Matthias Clasen In-Reply-To: <1150391737.3187.33.camel@dhcp83-98.boston.redhat.com> References: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> <1150390229.17566.191.camel@cacharro.xalalinux.org> <1150391737.3187.33.camel@dhcp83-98.boston.redhat.com> Content-Type: text/plain Date: Fri, 16 Jun 2006 10:52:10 +0200 Message-Id: <1150447930.5806.4.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.481 tagged_above=-999 required=2 tests=[AWL=0.118, BAYES_00=-2.599] X-Spam-Score: -2.481 X-Spam-Level: Cc: Federico Mena Quintero , gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2006 08:53:13 -0000 I'm also concerned about the recent files stuff. Do we now have UIManager integration of that? -- Murray Cumming murrayc@murrayc.com www.murrayc.com www.openismus.com From murrayc@murrayc.com Fri Jun 16 05:06:58 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id A76AC3B0076 for ; Fri, 16 Jun 2006 05:06:58 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23550-01 for ; Fri, 16 Jun 2006 05:06:57 -0400 (EDT) Received: from kungfu.dreamhost.com (kungfu.dreamhost.com [66.33.216.126]) by menubar.gnome.org (Postfix) with ESMTP id D099D3B006B for ; Fri, 16 Jun 2006 05:06:57 -0400 (EDT) Received: from swarthymail-a4.dreamhost.com (sd-green-bigip-62.dreamhost.com [208.97.132.62]) by kungfu.dreamhost.com (Postfix) with ESMTP id 708B51F0265 for ; Fri, 16 Jun 2006 01:28:47 -0700 (PDT) Received: from noname (p5497E1BF.dip.t-dialin.net [84.151.225.191]) by swarthymail-a4.dreamhost.com (Postfix) with ESMTP id 0D51A129A83; Fri, 16 Jun 2006 01:28:10 -0700 (PDT) Subject: Re: GTK+ 2.10, the endgame From: Murray Cumming To: Matthias Clasen In-Reply-To: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> References: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> Content-Type: text/plain Date: Thu, 15 Jun 2006 23:20:27 +0200 Message-Id: <1150406427.30234.1.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.068 tagged_above=-999 required=2 tests=[AWL=-0.296, BAYES_00=-2.599, DATE_IN_PAST_06_12=0.827] X-Spam-Score: -2.068 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2006 09:06:58 -0000 On Thu, 2006-06-15 at 09:56 -0400, Matthias Clasen wrote: > I want to have GTK+ 2.10 ready at or immediately after GUADEC. [snip] I'd rather it was after rather than before. That gives us just a little more time to get everything wrapped quickly for gtkmm, which might show some small problems that need fixing. Maybe I haven't been paying attention, but I'm surprised (again) by the freeze announcement. -- Murray Cumming murrayc@murrayc.com www.murrayc.com www.openismus.com From mgiannakidis@gmail.com Thu Jun 15 11:24:35 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id B7BE73B0211 for ; Thu, 15 Jun 2006 11:24:35 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19150-09 for ; Thu, 15 Jun 2006 11:24:34 -0400 (EDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.188]) by menubar.gnome.org (Postfix) with ESMTP id AAD863B04FC for ; Thu, 15 Jun 2006 11:24:33 -0400 (EDT) Received: by nf-out-0910.google.com with SMTP id c2so90382nfe for ; Thu, 15 Jun 2006 08:23:41 -0700 (PDT) Received: by 10.48.47.15 with SMTP id u15mr674329nfu; Thu, 15 Jun 2006 08:23:39 -0700 (PDT) Received: from ?213.140.137.120? ( [213.140.137.120]) by mx.gmail.com with ESMTP id n22sm2029009nfc.2006.06.15.08.23.38; Thu, 15 Jun 2006 08:23:39 -0700 (PDT) From: Michalis Giannakidis To: gtk-devel-list@gnome.org Subject: gslice allocator: general impresions. Date: Thu, 15 Jun 2006 18:27:45 +0300 User-Agent: KMail/1.8.3 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200606151827.45477.mgiannakidis@gmail.com> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.6 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.6 X-Spam-Level: X-Mailman-Approved-At: Fri, 16 Jun 2006 05:29:57 -0400 X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 15:24:35 -0000 Dear Glib team, I have recently used the glib-glice allocator in a very malloc intensive application, and I would like to share a few observations I made, with you. The typical size I send to g_slice_alloc is 20 and 76 bytes (32 bit build). The total memory consumed by my application has decreased - which is great! However it `seems' to me, that this decrease in size is larger for the 64bit build compared to the 32bit build. (I have modified gslice to align a chunk to its own size so that I don't have unused memory between chunks eg: request 20 and get 24...) In my application now I use both g_slice_alloc and malloc.Testing the new allocator in linux I came accross the following: After using g_slice_alloc to alloc a great amount of data (eg 1500mb), each of them being 20 or 76 bytes in size, subsequent calls to malloc(8*1024) or similar sizes take much longer (the allocation does _not_ got to the swap). Also if I chage the min_page_size from 128 to 4096, then the subsequent calls to malloc(8*1024) or similar sizes take even longer. It takes for ever in the 64 bit build! Moreover, even with min_page_size set to 128, the calls to malloc take for ever on a Linux 2.4.20 glibc-2.2.4(glibc up to 2.2.5 has a broken posix_memalign so I fallback to memalign). In all of the cases above, malloc responds much faster when the gslice allocator is turned off. I know I should be providing sample code and test programms here to back up my observations. I also understand that I should provide execution times instead of just stating that the calls to malloc take for ever. I would like to ask you, if there are any known issues in mixing gslice and malloc calls in malloc intensive applications. Any suggested readings would be most welcome. Regards Michalis -- Michalis Giannakidis From timj@gtk.org Fri Jun 16 07:30:05 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id EEDE23B0011 for ; Fri, 16 Jun 2006 07:30:04 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26976-06 for ; Fri, 16 Jun 2006 07:30:04 -0400 (EDT) Received: from holken.mikan.net (holken.mikan.net [83.145.56.183]) by menubar.gnome.org (Postfix) with ESMTP id DA78D3B0007 for ; Fri, 16 Jun 2006 07:30:03 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by holken.mikan.net (Postfix) with ESMTP id BDFA43352B0; Fri, 16 Jun 2006 13:28:54 +0200 (CEST) Received: from holken.mikan.net ([127.0.0.1]) by localhost (holken.mikan.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29662-08; Fri, 16 Jun 2006 13:28:48 +0200 (CEST) Received: from birnet.org (d003098.adsl.hansenet.de [80.171.3.98]) by holken.mikan.net (Postfix) with ESMTP id DFB2633525A; Fri, 16 Jun 2006 13:28:47 +0200 (CEST) Received: from master.birnet.private (localhost.localdomain [127.0.0.1]) by birnet.org (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k5GBSi9S008066 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 16 Jun 2006 13:28:44 +0200 Received: (from timj@localhost) by master.birnet.private (8.13.4/8.13.4/Submit) id k5GBSZMj008064; Fri, 16 Jun 2006 13:28:35 +0200 Date: Fri, 16 Jun 2006 13:28:35 +0200 (CEST) From: Tim Janik X-X-Sender: timj@master.birnet.private To: "Gustavo J. A. M. Carneiro" Subject: Re: GObject extension propose (GContainer) In-Reply-To: <1150456522.5305.12.camel@localhost.localdomain> Message-ID: References: <200606151101.12868.ntd@users.sourceforge.net> <44919246.8060301@gnome.org> <1150456522.5305.12.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="656239-2144330416-1150457315=:7955" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at holken.mikan.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.677 tagged_above=-999 required=2 tests=[AWL=-0.669, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, RCVD_IN_SORBS_WEB=1.456] X-Spam-Score: -1.677 X-Spam-Level: Cc: Gtk+ Developers X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2006 11:30:05 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --656239-2144330416-1150457315=:7955 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Fri, 16 Jun 2006, Gustavo J. A. M. Carneiro wrote: > Qui, 2006-06-15 =E0s 13:00 -0400, Tristan Van Berkom escreveu: >> All of that just to say... I cannot count the times I've thought to >> myself that >> GtkContainer should really just be GContainerIface, and implemented by >> whatever interested objects that want to parent other objects... > > That's interesting, but I wonder what is the runtime penalty of > interface lookup compared to normal class structure lookup? Is it > really OK to use an interface for this, or is it better just to add a > new virtual methods to the GObject class? the lookup penalties are negligible. type node/class lookups and is_a checks are O(1); interface class lookups and conforms_to checks are O(ld(N)), where N is the number of interfaces a type node conforms to. > Gustavo J. A. M. Carneiro --- ciaoTJ --656239-2144330416-1150457315=:7955-- From gjc@inescporto.pt Fri Jun 16 07:34:21 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 74BCC3B000B for ; Fri, 16 Jun 2006 07:34:21 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26977-07 for ; Fri, 16 Jun 2006 07:34:20 -0400 (EDT) Received: from animal.inescn.pt (correio.inescn.pt [194.117.24.9]) by menubar.gnome.org (Postfix) with ESMTP id 5B7183B0011 for ; Fri, 16 Jun 2006 07:34:19 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by animal.inescn.pt (8.13.6/8.13.6/7) with ESMTP id k5GBFdIJ028014; Fri, 16 Jun 2006 12:15:39 +0100 (WEST) Received: from pong.inescporto.pt (pong.inescn.pt [194.117.26.74]) by animal.inescn.pt (8.13.6/8.13.6/5) with ESMTP id k5GBFT0a027999; Fri, 16 Jun 2006 12:15:29 +0100 (WEST) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by pong.inescporto.pt (Postfix) with ESMTP id AE13A39D8; Fri, 16 Jun 2006 12:12:16 +0100 (WEST) Subject: Re: GObject extension propose (GContainer) From: "Gustavo J. A. M. Carneiro" To: Tristan Van Berkom In-Reply-To: <44919246.8060301@gnome.org> References: <200606151101.12868.ntd@users.sourceforge.net> <44919246.8060301@gnome.org> Content-Type: text/plain; charset=UTF-8 Date: Fri, 16 Jun 2006 12:15:21 +0100 Message-Id: <1150456522.5305.12.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at inescporto.pt X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.39 tagged_above=-999 required=2 tests=[AWL=-0.002, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, SPF_PASS=-0.001, TW_GT=0.077] X-Spam-Score: -2.39 X-Spam-Level: Cc: Gtk+ Developers , Tim Janik X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2006 11:34:21 -0000 Qui, 2006-06-15 s 13:00 -0400, Tristan Van Berkom escreveu: > Tim Janik wrote: > > >On Thu, 15 Jun 2006, Fontana Nicola wrote: > > > > > > > >>Hi all, > >> > >>I'm a GObject based libraries (for UI purpose and not) user and I often need > >>a generic container to derive my own types. In my opinion, I think this > >>generic container must be included inside the GObject library ... it could > >>be used by a lot of derived libraries providing a common approach. > >> > >>I published my solution - that is, what I am currently using - on > >>sourceforge. > >> > >>http://sourceforge.net/projects/gcontainer/ > >> > >>Is it a good idea? Is something planned in this direction? Am I totally > >>wrong? > >> > >>I need feedbacks ... > >> > >> > As a side note... I've been working on container --> child relationships and > honing them down inside the glade builder... objects may for example have > object delagates that are "owned" and in turn may "own" other delagates... > this is all functional with libglade facilities and the future gtk > builder also > (from the design as of yet...)... this concept of "types of container > relationships" > is also usefull for GtkMenuShell --> GtkMenu for example (not just any > GtkWidget > can be added to a menushell). > > All of that just to say... I cannot count the times I've thought to > myself that > GtkContainer should really just be GContainerIface, and implemented by > whatever interested objects that want to parent other objects... That's interesting, but I wonder what is the runtime penalty of interface lookup compared to normal class structure lookup? Is it really OK to use an interface for this, or is it better just to add a new virtual methods to the GObject class? > I think > that what we need is not really "yet another container api", but a container > api that is a unified front for generic handling of the GTK object > hierarchy at runtime. Actually, for the python language bindings we could use a generic GObject container interface. See http://bugzilla.gnome.org/show_bug.cgi?id=303266 Regards. -- Gustavo J. A. M. Carneiro The universe is always one step beyond logic From alan@clueserver.org Fri Jun 16 12:57:14 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 502C63B0336 for ; Fri, 16 Jun 2006 12:57:14 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06317-07 for ; Fri, 16 Jun 2006 12:57:08 -0400 (EDT) Received: from clueserver.org (216-99-213-120.dsl.aracnet.com [216.99.213.120]) by menubar.gnome.org (Postfix) with ESMTP id 7529F3B041B for ; Fri, 16 Jun 2006 12:54:18 -0400 (EDT) Received: by clueserver.org (Postfix, from userid 500) id 2985BF50BE2; Fri, 16 Jun 2006 09:53:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by clueserver.org (Postfix) with ESMTP id 26461F50BE1; Fri, 16 Jun 2006 09:53:44 -0700 (PDT) Date: Fri, 16 Jun 2006 09:53:44 -0700 (PDT) From: alan X-X-Sender: alan@blackbox.fnordora.org To: Jason Spiro Subject: Re: Imagine: what if points in Bugzilla had a significant effect? In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.45 tagged_above=-999 required=2 tests=[AWL=0.014, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.45 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2006 16:57:14 -0000 On Thu, 15 Jun 2006, Jason Spiro wrote: > Imagine: what if points did something in Bugzilla, like, the more points > you have, the more votes you get? Slashzilla? -- "Waiter! This lambchop tastes like an old sock!" - Sheri Lewis From ntd@users.sourceforge.net Fri Jun 16 14:08:36 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 39BE13B03E1 for ; Fri, 16 Jun 2006 14:08:36 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11017-04 for ; Fri, 16 Jun 2006 14:08:34 -0400 (EDT) Received: from mailout02.albacom.net (mailout02.albacom.net [217.220.34.14]) by menubar.gnome.org (Postfix) with SMTP id E2E913B00E4 for ; Fri, 16 Jun 2006 14:08:33 -0400 (EDT) Received: (qmail 21669 invoked by uid 507); 16 Jun 2006 18:08:08 -0000 Received: from ntd@users.sourceforge.net by mailout02.albacom.net with qmail-scanner (spamassassin: ???. Clear:RC:1(217.221.76.9):SA:0(0.0/15.0):. Processed in 0.841774 secs); 16 Jun 2006 18:08:08 -0000 Received: from unknown (HELO sviluppo.internet.local) (postmaster@effe-gi.it@217.221.76.9) by mailout02.albacom.net with SMTP; 16 Jun 2006 18:08:07 -0000 From: Fontana Nicola Organization: Elettronica EFFE-GI s.n.c. To: Tim Janik Subject: Re: GObject extension propose (GContainer) Date: Fri, 16 Jun 2006 20:44:11 +0000 User-Agent: KMail/1.9.1 References: <200606151101.12868.ntd@users.sourceforge.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200606162044.11716.ntd@users.sourceforge.net> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.526 tagged_above=-999 required=2 tests=[AWL=-0.004, BAYES_00=-2.599, TW_GT=0.077] X-Spam-Score: -2.526 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2006 18:08:36 -0000 > On Thu, 15 Jun 2006, Fontana Nicola wrote: > > Hi all, > > > > I'm a GObject based libraries (for UI purpose and not) user and I often > > need a generic container to derive my own types. In my opinion, I think > > this generic container must be included inside the GObject library ... it > > could be used by a lot of derived libraries providing a common approach. > > > > I published my solution - that is, what I am currently using - on > > sourceforge. > > > > http://sourceforge.net/projects/gcontainer/ > > > > Is it a good idea? Is something planned in this direction? Am I totally > > wrong? > > > > I need feedbacks ... > > hi. your gcontainer-1.0.0 looks like an interesting approach to me, but > i'm not sure it's generally good to put that into stock libgobject. > the main reason is that container needs are probably pretty variable > out there (i've come across at least 4 different gobject container > implementations in free software projects i'm woorking on) and that > both, making too little assumptions in the child/container interface > isn't going to be very helpful, albeit making too many has the > same problem. Some time ago I've started a communication library based on libgobject and I feeled the need of two things: a base object with floating reference and a container. After some time, I started an experimental cairo canvas and I had the same needs. In both cases, no gtk dependency was requested. Briefly, I'm not talking about a container that cover all needs and tastes but instead about "moving the GtkContainer logic and complexity" from gtk to gobject, something similar to what was done for GtkObject and its floating reference. I wrote gcontainer with this in mind (the GContainerable interface is "compatible" with GtkContainer and GChildable with GtkWidget). Anyway, my solution presents some serious problems: I'm misusing the interface to hide as much technical details as possible to the implementing objects. I know it is a huge task but consider this as an idea or a looooong term project: I don't think to be the only one with these needs. > > i guess we could add a link to your project from the libgobject docs > (it should probably have a Contrib section), for people possibly looking > for a GObject container implementation. that way, gcontainer-1.0.0 gets > a chance of being reused and maybe extended to something generally > usefull for GObject applications out there. > > > Nicola > > --- > ciaoTJ Of course I'll be glad to have a link in the gobject documentation. Thank you for your availability. Nicola From tristan.van.berkom@gmail.com Fri Jun 16 14:26:50 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id E38F43B0139 for ; Fri, 16 Jun 2006 14:26:49 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12245-08 for ; Fri, 16 Jun 2006 14:26:49 -0400 (EDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.197]) by menubar.gnome.org (Postfix) with ESMTP id DB55F3B0179 for ; Fri, 16 Jun 2006 14:26:48 -0400 (EDT) Received: by wx-out-0102.google.com with SMTP id i30so517779wxd for ; Fri, 16 Jun 2006 11:26:15 -0700 (PDT) Received: by 10.70.83.9 with SMTP id g9mr4369121wxb; Fri, 16 Jun 2006 11:20:03 -0700 (PDT) Received: from ?66.48.170.68? ( [66.48.170.68]) by mx.gmail.com with ESMTP id h39sm2692858wxd.2006.06.16.11.20.01; Fri, 16 Jun 2006 11:20:03 -0700 (PDT) Message-ID: <4492FA3C.5060106@gmail.com> Date: Fri, 16 Jun 2006 14:36:44 -0400 From: Tristan Van Berkom User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Fontana Nicola Subject: Re: GObject extension propose (GContainer) References: <200606151101.12868.ntd@users.sourceforge.net> <200606162044.11716.ntd@users.sourceforge.net> In-Reply-To: <200606162044.11716.ntd@users.sourceforge.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.497 tagged_above=-999 required=2 tests=[AWL=-0.353, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=1.456, SPF_PASS=-0.001] X-Spam-Score: -1.497 X-Spam-Level: Cc: gtk-devel-list@gnome.org, Tim Janik X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2006 18:26:50 -0000 Fontana Nicola wrote: [...] >I wrote gcontainer with this in mind (the GContainerable interface is >"compatible" with GtkContainer and GChildable with GtkWidget). Anyway, my >solution presents some serious problems: I'm misusing the interface to hide >as much technical details as possible to the implementing objects. > >I know it is a huge task but consider this as an idea or a looooong term >project: I don't think to be the only one with these needs. > > I think you may be overcomplicating things, if for example; the GContainerable or GContainerIface were implemented by GtkContainer; then nothing in GtkContainer derivatives would really have to change (unless the api was drasticly different... but I doubt that). Then this could be extended to other object sets and other needs without having to rewrite large pieces of code. Cheers, -Tristan From behdad.esfahbod@gmail.com Fri Jun 16 15:04:20 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 611EA3B00F8 for ; Fri, 16 Jun 2006 15:04:20 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15384-03 for ; Fri, 16 Jun 2006 15:04:18 -0400 (EDT) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.228]) by menubar.gnome.org (Postfix) with ESMTP id 566D33B007C for ; Fri, 16 Jun 2006 15:04:18 -0400 (EDT) Received: by wr-out-0506.google.com with SMTP id i4so618991wra for ; Fri, 16 Jun 2006 12:03:42 -0700 (PDT) Received: by 10.54.142.9 with SMTP id p9mr3126451wrd; Fri, 16 Jun 2006 11:57:25 -0700 (PDT) Received: from ?192.168.190.5? ( [72.136.156.47]) by mx.gmail.com with ESMTP id 10sm2200187wrl.2006.06.16.11.57.23; Fri, 16 Jun 2006 11:57:24 -0700 (PDT) Subject: Re: Imagine: what if points in Bugzilla had a significant effect? From: Behdad Esfahbod To: gtk-devel-list@gnome.org In-Reply-To: References: Content-Type: text/plain Date: Fri, 16 Jun 2006 14:57:22 -0400 Message-Id: <1150484242.15469.17.camel@home> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 (2.6.1-1.fc5.2) Content-Transfer-Encoding: 7bit Sender: Behdad Esfahbod X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.561 tagged_above=-999 required=2 tests=[AWL=-0.038, BAYES_00=-2.599, SPF_PASS=-0.001, TW_GT=0.077] X-Spam-Score: -2.561 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2006 19:04:20 -0000 On Thu, 2006-06-15 at 15:15 -0400, Jason Spiro wrote: > Imagine: what if points did something in Bugzilla, like, the more points > you have, the more votes you get? > > I think this would encourage people to file more bug reports, both good > bug reports and not-so-good ones. Would that be a net gain or a net loss > for GTK+? It has evolved to be like that already. The more points one has, the more he (or she, in the near future) respects bugs/comments from high-point others. Or at least that's been my experience. behdad > Regards, > Jason Spiro > > -- > Jason Spiro: computer consulting with a smile. > Specializing in Linux: Red Hat AS / ES, Debian, and others. > Serving homes and companies globally via remote access tools. Fair rates. > Just email jasonspiro4@gmail.com or call Skype ID jasonspiro. > > _______________________________________________ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-devel-list -- behdad http://behdad.org/ "Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill" -- Dan Bern, "New American Language" From grakic@devbase.net Fri Jun 16 16:12:39 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 7B9EC3B025A for ; Fri, 16 Jun 2006 16:12:39 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19416-03 for ; Fri, 16 Jun 2006 16:12:38 -0400 (EDT) Received: from mxout-04.mxes.net (mxout-04.mxes.net [205.237.194.35]) by menubar.gnome.org (Postfix) with ESMTP id 07A823B02B4 for ; Fri, 16 Jun 2006 16:12:37 -0400 (EDT) Received: from limun.local (unknown [87.116.163.93]) by smtp.mxes.net (Postfix) with ESMTP id C5307A3292; Fri, 16 Jun 2006 16:11:35 -0400 (EDT) Subject: Re: Imagine: what if points in Bugzilla had a significant effect? From: Goran Rakic To: Jason Spiro In-Reply-To: References: Content-Type: text/plain; charset=utf-8 Date: Fri, 16 Jun 2006 22:11:33 +0200 Message-Id: <1150488693.2273.3.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.6 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, SPF_HELO_PASS=-0.001] X-Spam-Score: -2.6 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2006 20:12:39 -0000 Lary Osterman has a nice writing on this topic titled "Measuring testers by test metrics doesn't." У čet, 15. 06 2006. у 19:15 +0000, Jason Spiro пише: > Imagine: what if points did something in Bugzilla, like, the more points > you have, the more votes you get? > > I think this would encourage people to file more bug reports, both good > bug reports and not-so-good ones. Would that be a net gain or a net loss > for GTK+? > > Regards, > Jason Spiro From ame1@extratech.com Fri Jun 16 17:02:33 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 2F9013B018C for ; Fri, 16 Jun 2006 17:02:33 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21327-05 for ; Fri, 16 Jun 2006 17:02:32 -0400 (EDT) Received: from portal2.extratech.com (portal.extratech.com [67.105.201.210]) by menubar.gnome.org (Postfix) with ESMTP id BB3BD3B01C8 for ; Fri, 16 Jun 2006 17:02:31 -0400 (EDT) Received: from zosma.extratech.com (zosma.extratech.com [192.168.0.41]) by portal2.extratech.com (8.12.11/8.12.11) with ESMTP id k5GL1Quq030485 for ; Fri, 16 Jun 2006 14:01:26 -0700 Subject: Re: GObject extension propose (GContainer) From: "Alan M. Evans" To: Gtk+ Developers In-Reply-To: References: <200606151101.12868.ntd@users.sourceforge.net> <44919246.8060301@gnome.org> <1150456522.5305.12.camel@localhost.localdomain> Content-Type: text/plain; charset=UTF-8 Message-Id: <1150491686.19405.355.camel@zosma.extratech.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 16 Jun 2006 14:01:26 -0700 Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV 0.86.1/1544/Fri Jun 16 02:19:15 2006 on portal2.extratech.com X-Virus-Status: Clean X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.556 tagged_above=-999 required=2 tests=[AWL=0.044, BAYES_00=-2.599] X-Spam-Score: -2.556 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2006 21:02:33 -0000 On Fri, 2006-06-16 at 04:28, Tim Janik wrote: > On Fri, 16 Jun 2006, Gustavo J. A. M. Carneiro wrote: > > > Qui, 2006-06-15 s 13:00 -0400, Tristan Van Berkom escreveu: > > >> All of that just to say... I cannot count the times I've thought to > >> myself that > >> GtkContainer should really just be GContainerIface, and implemented by > >> whatever interested objects that want to parent other objects... > > > > That's interesting, but I wonder what is the runtime penalty of > > interface lookup compared to normal class structure lookup? Is it > > really OK to use an interface for this, or is it better just to add a > > new virtual methods to the GObject class? > > the lookup penalties are negligible. > type node/class lookups and is_a checks are O(1); > interface class lookups and conforms_to checks are O(ld(N)), where > N is the number of interfaces a type node conforms to. Your assertion that the penalties are negligable is not really supported by your response, unless the constant is also known for both orders. From ebassi@gmail.com Fri Jun 16 20:14:03 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 3E95D3B069B for ; Fri, 16 Jun 2006 20:14:03 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28883-03 for ; Fri, 16 Jun 2006 20:14:00 -0400 (EDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.185]) by menubar.gnome.org (Postfix) with ESMTP id 969133B015A for ; Fri, 16 Jun 2006 20:13:59 -0400 (EDT) Received: by nf-out-0910.google.com with SMTP id c2so667512nfe for ; Fri, 16 Jun 2006 17:13:07 -0700 (PDT) Received: by 10.49.72.13 with SMTP id z13mr2277195nfk; Fri, 16 Jun 2006 17:05:51 -0700 (PDT) Received: from ?192.168.1.74? ( [86.136.65.180]) by mx.gmail.com with ESMTP id y23sm3836170nfb.2006.06.16.17.05.51; Fri, 16 Jun 2006 17:05:51 -0700 (PDT) Subject: Re: GTK+ 2.10, the endgame From: Emmanuele Bassi To: gtk-devel-list@gnome.org In-Reply-To: <1150447930.5806.4.camel@localhost.localdomain> References: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> <1150390229.17566.191.camel@cacharro.xalalinux.org> <1150391737.3187.33.camel@dhcp83-98.boston.redhat.com> <1150447930.5806.4.camel@localhost.localdomain> Content-Type: text/plain Date: Sat, 17 Jun 2006 01:05:50 +0100 Message-Id: <1150502750.2668.12.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.34 tagged_above=-999 required=2 tests=[AWL=0.260, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.34 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2006 00:14:03 -0000 Hi Murray, On Fri, 2006-06-16 at 10:52 +0200, Murray Cumming wrote: > I'm also concerned about the recent files stuff. Do we now have > UIManager integration of that? No, and I am to blame because I had less time to spend on fixing this issue. Mostly, I've been stuck on how to implement an action for both the menu and toolbars using the same tag. In the meantime, a nice and clean way to integrate the GtkRecentChooserMenu inside a GtkUIManager is to subclass GtkAction into a custom action that automatically adds a recent chooser menu to the menu item it creates, and use a placeholder in the UI definition (most applications using EggRecentViewUIManager already have that placeholder present). A working example is available here: http://www.gnome.org/~ebassi/test-uimanager.c The action code itself is one hundred lines long and can easily be hidden inside an helper file; it's approximately how GtkRecentAction would be implemented, anyway. I hereby give permission to do whatever you want to do with it. I understand that it's sub-optimal, and hopefully this should really go away once there's an action inside GTK. Ciao, Emmanuele. -- Emmanuele Bassi, E: ebassi@gmail.com W: http://www.emmanuelebassi.net B: http://log.emmanuelebassi.net From behdad.esfahbod@gmail.com Mon Jun 12 17:52:45 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 162C73B02CD for ; Mon, 12 Jun 2006 17:52:45 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00303-05 for ; Mon, 12 Jun 2006 17:52:43 -0400 (EDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.206]) by menubar.gnome.org (Postfix) with ESMTP id 643023B0010 for ; Mon, 12 Jun 2006 17:52:43 -0400 (EDT) Received: by wx-out-0102.google.com with SMTP id h26so956965wxd for ; Mon, 12 Jun 2006 14:51:27 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:subject:from:to:content-type:date:message-id:mime-version:x-mailer:sender; b=HkVpdki0/g3XkGcHUm613LiH99RNWp83QpOiB04twtI9/oyY5QJs7xgUW9ugXUYWTW0FQESua3SiFes9GpwcHFnulMB+jmu6Frg1gjSTz94Z0WNKazKYJCx/0yCrKVvi+sIhO9793kd+R7hBbKFWLBqlIyo5yetvED1gx6HIjnc= Received: by 10.70.36.1 with SMTP id j1mr6891335wxj; Mon, 12 Jun 2006 14:44:52 -0700 (PDT) Received: from to-dhcp26.toronto.redhat.com ( [63.250.163.171]) by mx.gmail.com with ESMTP id h18sm3879342wxd.2006.06.12.14.44.50; Mon, 12 Jun 2006 14:44:51 -0700 (PDT) Subject: Pango-1.13.2 released [unstable] From: Behdad Esfahbod To: Pango Release Lists , gtk-app-devel-list@gnome.org, gtk-devel-list@gnome.org, gtk-i18n-list@gnome.org, gtk-list@gnome.org Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-HZBsNn3KdPR3jVVwB9gO" Date: Mon, 12 Jun 2006 17:44:37 -0400 Message-Id: <1150148678.10765.8.camel@home> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 (2.6.1-1.fc5.2) Sender: Behdad Esfahbod X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.6 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.6 X-Spam-Level: X-Mailman-Approved-At: Fri, 16 Jun 2006 05:27:53 -0400 X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2006 21:52:45 -0000 --=-HZBsNn3KdPR3jVVwB9gO Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Pango-1.13.2 is now available for download at: ftp://ftp.gtk.org/pub/gtk/v2.11/ or http://download.gnome.org/sources/pango/1.13/ 28a6ea9d43c4cd398e7352032f775401 pango-1.13.2.tar.bz2 17d78473c05fece044c6a3b44519b61f pango-1.13.2.tar.gz This is a development release leading up to Pango-1.14.0, which will be released just in time for GNOME-2.16. Notes: * This is unstable development release. While it has had fairly extensive testing, there are likely bugs remaining to be found. This release should not be used in production. * Installing this version will overwrite your existing copy of Pango-1.12. If you have problems, you'll need to reinstall Pango-1.12.x * Bugs should be reported to http://bugzilla.gnome.org. About Pango =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Pango is a library for layout and rendering of text, with an emphasis on internationalization. Pango can be used anywhere that text layout is needed, though most of the work on Pango so far has been done in the context of the GTK+ widget toolkit. Pango forms the core of text and font handling for GTK+-2.x. Pango is designed to be modular; the core Pango layout engine can be used with different font backends. There are three basic backends, with multiple options for rendering with each. - Client side fonts using the FreeType and fontconfig libraries. Rendering can be with with Cairo or Xft libraries, or directly to an in-memory buffer with no additional libraries. - Native fonts on Microsoft Windows. (Optionally using Uniscribe for complex-text handling). Rendering can be done via Cairo or directly using the native Win32 API. - Native fonts on MacOS X, rendering via Cairo. The integration of Pango with Cairo (http://cairographics.org) provides a complete solution with high quality text handling and graphics rendering. Dynamically loaded modules then handle text layout for particular combinations of script and font backend. Pango ships with a wide selection of modules, including modules for Hebrew, Arabic, Hangul, Thai, and a number of Indic scripts. Virtually all of the world's major scripts are supported. As well as the low level layout rendering routines, Pango includes PangoLayout, a high level driver for laying out entire blocks of text, and routines to assist in editing internationalized text. More information about Pango is available from http://www.pango.org/. Pango 1.13.2 depends on version 2.10.0 or newer of the GLib library and version 1.1.2 or newer of the cairo library (if the cairo backend is desired); more information about GLib and cairo can be found at http://www.gtk.org/ and http://cairographics.org/ respectively. Overview of changes between 1.13.1 and 1.13.2 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D * Improved hexbox drawing, and font metrics calculations. * Synthesize italic variants on win32 [Hans Breuer] * New public API: - pango_cairo_show_error_underline - pango_cairo_error_underline_path - pango_font_describe_with_absolute_size * Misc fixes. * Bugs fixed in this release: Bug 326960 =E2=80=93 hex box drawing for win32 and atsui backends of cairo Bug 343717 =E2=80=93 License information in unclear. Bug 343355 =E2=80=93 Add pango_cairo_show_error_underline & pango_cairo_error_underline_path Bug 343966 =E2=80=93 pango Cygwin build fixes Patch from Cygwin Ports maintainer. Bug 343796 =E2=80=93 Italic Chinese character can't be show correctly in Win32. Bug 314114 =E2=80=93 max_x_advance not appropriate for approximate_(char|digit)_width Bug 341138 =E2=80=93 Using TTC font, Gtk2 programs begin to eating big mem= ory and have many cpu usage. Patch from Yong Li. Bug 336153 =E2=80=93 Mark to mark positioning (Lookup Type 6) isn't correc= t when using MarkAttchmentType Patch from Tin Myo Htet. Bug 333984 =E2=80=93 pango_language_from_string improvements Bug 125378 =E2=80=93 Better underline thickness handling Bug 339730 =E2=80=93 Pango needlessly falls back away from a Type 1 font i= nto a TTF font Bug 342562 =E2=80=93 Support absolute sizes in pango_font_description_to/from_string Bug 341922 =E2=80=93 pango should handle more characters as zero width Patch from Roozbeh Pournader Bug 342525 =E2=80=93 With PangoFc and PangoWin32, approximate digit width = is not what it says Bug 342079 =E2=80=93 pangoatsui-private.h missing from release Behdad Esfahbod 12 June 2006 --=-HZBsNn3KdPR3jVVwB9gO Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQBEjeBFn+4E5dNTERURApTwAJ9OvqbaG1xnQYzGPC9u0WPi30b6ggCfXNvZ oFfMwctzkAaKRETc/0aDRj0= =Wl7j -----END PGP SIGNATURE----- --=-HZBsNn3KdPR3jVVwB9gO-- From Klaus.Stengel@asamnet.de Tue Jun 13 06:57:05 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 1BD1E3B008F for ; Tue, 13 Jun 2006 06:57:05 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20572-03 for ; Tue, 13 Jun 2006 06:57:03 -0400 (EDT) Received: from mail.asamnet.de (mail.asamnet.de [194.25.81.18]) by menubar.gnome.org (Postfix) with ESMTP id A52473B000C for ; Tue, 13 Jun 2006 06:57:03 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.asamnet.de (Asamnet e.V. Mailserver) with ESMTP id D01E8A7076 for ; Tue, 13 Jun 2006 12:56:24 +0200 (CEST) Received: from mail.asamnet.de ([127.0.0.1]) by localhost (mail.asamnet.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00951-06 for ; Tue, 13 Jun 2006 12:56:24 +0200 (CEST) Received: from aquarian.nathanet.lan (p5492D6A6.dip.t-dialin.net [84.146.214.166]) by mail.asamnet.de (Asamnet e.V. Mailserver) with ESMTP id 6350FA7066 for ; Tue, 13 Jun 2006 12:56:24 +0200 (CEST) Subject: Pango memory leak in get_ruleset() in modules/basic/basic-fc.c From: Klaus Stengel To: gtk-devel-list@gnome.org Content-Type: text/plain Date: Tue, 13 Jun 2006 12:56:34 +0200 Message-Id: <1150196194.9594.16.camel@aquarian.nathanet.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at asamnet.de X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.464 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.464 X-Spam-Level: X-Mailman-Approved-At: Fri, 16 Jun 2006 05:27:53 -0400 X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2006 10:57:05 -0000 Hi, while working with the diagram editor "dia" I noticed a major memory leak when editing text objects. I tracked this down to a problem in the above function. From what I understand the function looks for an ruleset associated with the given font face and in case there is none, the ruleset is created with pango_ot_ruleset_new() and finally attached to the font face. The g_object_unref() is given as "notification callback" so that the ruleset is destroyed when the font face is finalized. In theory this should work, but unfortunately it doesn't in practice, because pango_ot_ruleset_new() internally references "info" itself, thus creating a circular dependency that keeps the objects alive indefinitely. Unfortunately I don't see an simple solution, except to drop that kind of caching again... Bye, Klaus. P.S.: Please reply to my email address as well, as I'm not subscribed to the list. From newren@gmail.com Sat Jun 17 01:54:29 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 7F2843B066E for ; Sat, 17 Jun 2006 01:54:29 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08609-05 for ; Sat, 17 Jun 2006 01:54:28 -0400 (EDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.198]) by menubar.gnome.org (Postfix) with ESMTP id 354E43B050E for ; Sat, 17 Jun 2006 01:54:28 -0400 (EDT) Received: by wx-out-0102.google.com with SMTP id h26so603851wxd for ; Fri, 16 Jun 2006 22:53:32 -0700 (PDT) Received: by 10.70.24.3 with SMTP id 3mr5192323wxx; Fri, 16 Jun 2006 22:53:32 -0700 (PDT) Received: by 10.70.102.9 with HTTP; Fri, 16 Jun 2006 22:53:32 -0700 (PDT) Message-ID: <51419b2c0606162253pfe0e7edsba8af3f8a1573477@mail.gmail.com> Date: Fri, 16 Jun 2006 23:53:32 -0600 From: "Elijah Newren" To: "Jason Spiro" Subject: Re: Imagine: what if points in Bugzilla had a significant effect? In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.572 tagged_above=-999 required=2 tests=[AWL=0.028, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.572 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2006 05:54:29 -0000 On 6/15/06, Jason Spiro wrote: > Imagine: what if points did something in Bugzilla, like, the more points > you have, the more votes you get? > > I think this would encourage people to file more bug reports, both good > bug reports and not-so-good ones. Would that be a net gain or a net loss > for GTK+? This isn't the right list for this email; bugzilla-devel or filed in bugzilla (against the bugzilla.gnome.org module) would be much better. Thanks, Elijah From timj@gtk.org Sat Jun 17 10:12:11 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id CD5003B00A6 for ; Sat, 17 Jun 2006 10:12:11 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23968-01 for ; Sat, 17 Jun 2006 10:12:08 -0400 (EDT) Received: from holken.mikan.net (holken.mikan.net [83.145.56.183]) by menubar.gnome.org (Postfix) with ESMTP id 34EA13B00D5 for ; Sat, 17 Jun 2006 10:12:07 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by holken.mikan.net (Postfix) with ESMTP id AC6413352A5; Sat, 17 Jun 2006 13:44:21 +0200 (CEST) Received: from holken.mikan.net ([127.0.0.1]) by localhost (holken.mikan.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07456-06; Sat, 17 Jun 2006 13:44:16 +0200 (CEST) Received: from birnet.org (d003096.adsl.hansenet.de [80.171.3.96]) by holken.mikan.net (Postfix) with ESMTP id 7CD8233524F; Sat, 17 Jun 2006 13:44:16 +0200 (CEST) Received: from master.birnet.private (localhost.localdomain [127.0.0.1]) by birnet.org (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k5HBiART015834 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 17 Jun 2006 13:44:11 +0200 Received: (from timj@localhost) by master.birnet.private (8.13.4/8.13.4/Submit) id k5HBhvjK015833; Sat, 17 Jun 2006 13:43:57 +0200 Date: Sat, 17 Jun 2006 13:43:57 +0200 (CEST) From: Tim Janik X-X-Sender: timj@master.birnet.private To: Michalis Giannakidis Subject: Re: gslice allocator: general impresions. In-Reply-To: <200606151827.45477.mgiannakidis@gmail.com> Message-ID: References: <200606151827.45477.mgiannakidis@gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at holken.mikan.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.339 tagged_above=-999 required=2 tests=[AWL=0.048, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, TW_TX=0.077] X-Spam-Score: -2.339 X-Spam-Level: Cc: Gtk+ Developers X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2006 14:12:12 -0000 On Thu, 15 Jun 2006, Michalis Giannakidis wrote: > Dear Glib team, > > I have recently used the glib-glice allocator in a very malloc intensive > application, and I would like to share a few observations I made, with you. > > The typical size I send to g_slice_alloc is 20 and 76 bytes (32 bit build). > The total memory consumed by my application has decreased - which is great! > However it `seems' to me, that this decrease in size is larger for the 64bit > build compared to the 32bit build. (I have modified gslice to align a chunk > to its own size so that I don't have unused memory between chunks eg: request > 20 and get 24...) you mean you've set P2ALIGNMENT to 1 * sizeof(void*) to get better granularity of the slices? have you left NATIVE_MALLOC_PADDING at 2*sizeof(void*) at least? (if not, memory fragmentation on some glibc systems and on all 64bit systems can become etxremely bad). > In my application now I use both g_slice_alloc and malloc.Testing the new > allocator in linux I came accross the following: > After using g_slice_alloc to alloc a great amount of data (eg 1500mb), each of > them being 20 or 76 bytes in size, subsequent calls to malloc(8*1024) or > similar sizes take much longer (the allocation does _not_ got to the swap). this is a magnitude of memory allocations where gslice hasn't been well tested. (my machine only has 1GB of memory for instance). while gslice should perform well even much beyond 1GB, i'd suspect that malloc()/memalign() don't, and thus could result in *some* GSlice slowdown as well. > Also if I chage the min_page_size from 128 to 4096, then the subsequent calls > to malloc(8*1024) or similar sizes take even longer. It takes for ever in the > 64 bit build! maybe due to your alignment tweaks. but maybe also because some malloc() buckets will have even longer lists that way. > Moreover, even with min_page_size set to 128, the calls to malloc take for > ever on a Linux 2.4.20 glibc-2.2.4(glibc up to 2.2.5 has a broken > posix_memalign so I fallback to memalign). broken in what way? > In all of the cases above, malloc responds much faster when the gslice > allocator is turned off. aparently some malloc implementations aren't too good at handling large numbers of page allocations. if modifying GSlice is an option for you, you could try to work around this at the expense of read-only allocation of the memory used by GSlice. to do that, you need to disable the HAVE_COMPLIANT_POSIX_MEMALIGN, HAVE_MEMALIGN and HAVE_VALLOC branches in allocator_memalign() and allocator_memfree() so the read-only malloc()-based fallback allocator is enabled. on 32bit systems, that'll by default allocate 16*4096=64k areas to allocate pages from. by doing: - const guint n_pages = 16; + const guint n_pages = 2560; you'll instead allocate 10MB areas, which should put far less stress on the system malloc() (that way, to fill 1GB, a maximum of 100 allocations are required). > I know I should be providing sample code and test programms here to back up > my observations. I also understand that I should provide execution times > instead of just stating that the calls to malloc take for ever. test programs would be great. allthough this kind of stress test can only be run and examined on a limited set of machines. e.g. the development machines i use have just 1GB and normally have only 30%-40% of free memory to spare for tests during runs like make check -C glib/test ;) > I would like to ask you, if there are any known issues in mixing gslice and > malloc calls in malloc intensive applications. > Any suggested readings would be most welcome. you've already seen the two papers cited in the big comment block at the start of gslice.c? it links to: http://citeseer.ist.psu.edu/bonwick94slab.html http://citeseer.ist.psu.edu/bonwick01magazines.html the first of which describes a kernel page allocator which isn't implemented by GSlice. we use memalign() instead, on the assumption that this is good enough for the vast majority of applications out there. if malloc is too stressed out by the aligned allocations gslice makes in your scenario, implementing this page allocator on top of mmap() and using that as a base allocator for gslice may be another option. > Regards > Michalis --- ciaoTJ From tristan.van.berkom@gmail.com Sat Jun 17 12:09:06 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 2E2D13B013A for ; Sat, 17 Jun 2006 12:09:06 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26133-07 for ; Sat, 17 Jun 2006 12:09:03 -0400 (EDT) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.239]) by menubar.gnome.org (Postfix) with ESMTP id DEE4F3B0061 for ; Sat, 17 Jun 2006 12:09:02 -0400 (EDT) Received: by wr-out-0506.google.com with SMTP id 57so940143wri for ; Sat, 17 Jun 2006 09:07:30 -0700 (PDT) Received: by 10.54.116.7 with SMTP id o7mr3977729wrc; Sat, 17 Jun 2006 09:00:41 -0700 (PDT) Received: from ?66.48.170.156? ( [66.48.170.156]) by mx.gmail.com with ESMTP id 44sm2844499wri.2006.06.17.09.02.05; Sat, 17 Jun 2006 09:02:06 -0700 (PDT) Message-ID: <44942B5F.2090903@gnome.org> Date: Sat, 17 Jun 2006 12:18:39 -0400 User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Alan M. Evans" Subject: Re: GObject extension propose (GContainer) References: <200606151101.12868.ntd@users.sourceforge.net> <44919246.8060301@gnome.org> <1150456522.5305.12.camel@localhost.localdomain> <1150491686.19405.355.camel@zosma.extratech.com> In-Reply-To: <1150491686.19405.355.camel@zosma.extratech.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit From: Tristan Van Berkom X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.208 tagged_above=-999 required=2 tests=[AWL=0.392, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.208 X-Spam-Level: Cc: Gtk+ Developers X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2006 16:09:06 -0000 Alan M. Evans wrote: [...] >>the lookup penalties are negligible. >>type node/class lookups and is_a checks are O(1); >>interface class lookups and conforms_to checks are O(ld(N)), where >>N is the number of interfaces a type node conforms to. >> >> > >Your assertion that the penalties are negligable is not really supported >by your response, unless the constant is also known for both orders. > > From my swift glance at gtype.c, it seems that in the case of an interface, the implementing interface is searched on that class's list of implementing interfaces... so when classes implement hundreds of interfaces it might be a performance hit. I dont think we've yet reached the day that we have to ditch good design and avoid using interfaces because of performance woes, that would be sorry day indeed... (I also dont think GTK+ code will be the only OO code needing major refactoring in those areas too... if these interface lookups weren't negligable) Cheers, -Tristan From chris@gnome-de.org Sat Jun 17 12:59:38 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 89E3F3B00A7 for ; Sat, 17 Jun 2006 12:59:38 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27929-06 for ; Sat, 17 Jun 2006 12:59:35 -0400 (EDT) Received: from mail.bytecamp.net (mail.bytecamp.net [212.204.60.9]) by menubar.gnome.org (Postfix) with SMTP id DF0E93B000D for ; Sat, 17 Jun 2006 12:59:34 -0400 (EDT) Received: (qmail 40076 invoked by uid 85); 17 Jun 2006 16:58:00 -0000 Received: from chris@gnome-de.org by mail.bytecamp.net by uid 88 with qmail-scanner-1.20 (clamscan: 0.88.1 Clear:RC:0(84.150.174.158):. Processed in 0.431315 secs); 17 Jun 2006 16:58:00 -0000 Received: from p5496ae9e.dip0.t-ipconnect.de (HELO ?192.168.123.112?) (chris@gnome-de.org@84.150.174.158) by mail.bytecamp.net with RC4-MD5 encrypted SMTP; 17 Jun 2006 16:57:59 -0000 Subject: GtkFileChooser/GnomeVFS backend still messing up authentication manager? (was: GTK+ 2.10, the endgame) From: Christian Neumair To: Matthias Clasen In-Reply-To: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> References: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> Content-Type: text/plain Date: Sat, 17 Jun 2006 18:57:54 +0200 Message-Id: <1150563475.24534.12.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.586 tagged_above=-999 required=2 tests=[AWL=0.013, BAYES_00=-2.599] X-Spam-Score: -2.586 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2006 16:59:38 -0000 Am Donnerstag, den 15.06.2006, 09:56 -0400 schrieb Matthias Clasen: > I want to have GTK+ 2.10 ready at or immediately after GUADEC. > > I did not declare 2.9.3 api frozen in the release announcement, > because we were still holding the door open for Kris' work on > the new tooltips api. But he has run into some difficulties > with the implementation which will take some time to overcome, > so we have decided to punt this feature and try to get it > into 2.12 early. > > Therefore, I want to consider 2.9.3 api frozen, and take a > look at what still needs to happen before 2.10. Here are some > things I personally would like get worked on (not sure > how much time I can free to look into these myself): > > - I think the async filechooser conversion has caused some > regressions, I noticed that .hidden support seems broken > and autocompletion also behaved badly for me recently. > > - There is a number of FIXMEs and unimplemented bits in > the print code. > > - The print backends need a careful look wrt to memory leaks > and error reporting. > > Are there other important bugs or regressions that need > attention before 2.10 ? Some months ago I investigated an issue where the GtkFileChooser requested file info for all shortcuts and caused mass login requests for all bookmarked remote locations on startup that require login with the GnomeVFS backend. I think the issue was that the file chooser has no way of requesting file info, but signalling at the same time that failure due to unavailability of resources or access constraints isn't fatal, allowing the GnomeVFS backend to not request login data when it is invoked through gtkfilechooserdefault.c:shortcuts_reload_icons. In that case, we may want to fall back to a folder icon. >From reading the GTK+ HEAD source code, the shortcut code still doesn't seem to pass any special flags, so it still seems to be relevant. -- Christian Neumair From gcottenc@gmail.com Sat Jun 17 13:23:55 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 81FC83B000D for ; Sat, 17 Jun 2006 13:23:55 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30389-08 for ; Sat, 17 Jun 2006 13:23:54 -0400 (EDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.197]) by menubar.gnome.org (Postfix) with ESMTP id 01A153B010F for ; Sat, 17 Jun 2006 13:23:53 -0400 (EDT) Received: by wx-out-0102.google.com with SMTP id h26so659270wxd for ; Sat, 17 Jun 2006 10:22:54 -0700 (PDT) Received: by 10.70.116.8 with SMTP id o8mr5867050wxc; Sat, 17 Jun 2006 10:22:54 -0700 (PDT) Received: by 10.70.19.4 with HTTP; Sat, 17 Jun 2006 10:22:54 -0700 (PDT) Message-ID: Date: Sat, 17 Jun 2006 19:22:54 +0200 From: "Guillaume Cottenceau" To: "Matthias Clasen" Subject: Re: GTK+ 2.10, the endgame In-Reply-To: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.6 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.6 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2006 17:23:55 -0000 On 6/15/06, Matthias Clasen wrote: > Therefore, I want to consider 2.9.3 api frozen, and take a Does this mean that http://developer.gnome.org/doc/API/2.0/gtk/ix07.html (and equivalents for gdk, pango, atk) is now a fully stable source for bindings which want to support new features of 2.10? -- Guillaume Cottenceau - http://zarb.org/~gc/ From timj@gtk.org Sun Jun 18 07:31:59 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id D384A3B0316 for ; Sun, 18 Jun 2006 07:31:59 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21403-07 for ; Sun, 18 Jun 2006 07:31:57 -0400 (EDT) Received: from holken.mikan.net (holken.mikan.net [83.145.56.183]) by menubar.gnome.org (Postfix) with ESMTP id 5988B3B09AB for ; Sun, 18 Jun 2006 07:31:57 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by holken.mikan.net (Postfix) with ESMTP id D1B0818461; Sun, 18 Jun 2006 13:31:12 +0200 (CEST) Received: from holken.mikan.net ([127.0.0.1]) by localhost (holken.mikan.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16166-04; Sun, 18 Jun 2006 13:31:09 +0200 (CEST) Received: from birnet.org (d003096.adsl.hansenet.de [80.171.3.96]) by holken.mikan.net (Postfix) with ESMTP id DE31E14571; Sun, 18 Jun 2006 13:31:08 +0200 (CEST) Received: from master.birnet.private (localhost.localdomain [127.0.0.1]) by birnet.org (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k5IBV5n9025330 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 18 Jun 2006 13:31:05 +0200 Received: (from timj@localhost) by master.birnet.private (8.13.4/8.13.4/Submit) id k5IBUuX0025320; Sun, 18 Jun 2006 13:30:56 +0200 Date: Sun, 18 Jun 2006 13:30:56 +0200 (CEST) From: Tim Janik X-X-Sender: timj@master.birnet.private To: Tristan Van Berkom Subject: Re: GObject extension propose (GContainer) In-Reply-To: <44942B5F.2090903@gnome.org> Message-ID: References: <200606151101.12868.ntd@users.sourceforge.net> <44919246.8060301@gnome.org> <1150456522.5305.12.camel@localhost.localdomain> <1150491686.19405.355.camel@zosma.extratech.com> <44942B5F.2090903@gnome.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at holken.mikan.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.378 tagged_above=-999 required=2 tests=[AWL=0.086, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.378 X-Spam-Level: Cc: Gtk+ Developers X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jun 2006 11:32:00 -0000 On Sat, 17 Jun 2006, Tristan Van Berkom wrote: > Alan M. Evans wrote: > [...] > >>> the lookup penalties are negligible. >>> type node/class lookups and is_a checks are O(1); >>> interface class lookups and conforms_to checks are O(ld(N)), where >>> N is the number of interfaces a type node conforms to. >>> >>> >> >> Your assertion that the penalties are negligable is not really supported >> by your response, unless the constant is also known for both orders. >> >> > From my swift glance at gtype.c, it seems that in the case of > an interface, the implementing interface is searched on that class's > list of implementing interfaces... so when classes implement > hundreds of interfaces it might be a performance hit. no there won't be a performance hit. that's because gtype.c uses a binary search for the lookups (as indicated in my last email by the O(ld(N)) complexity). the function used for frequent interface lookups is: gpointer g_type_interface_peek (gpointer instance_class, GType iface_type); and in a nutshell, it does: { TypeNode *node = lookup_type_node_I (class->g_type); // O(1) TypeNode *iface = lookup_type_node_I (iface_type); // O(1) IFaceEntry *entry = type_lookup_iface_entry_L (node, iface); // O(ld(N)) return entry->vtable; } take a look at gtype.c and type_lookup_iface_entry_L() to confirm. using a binary lookup in type_lookup_iface_entry_L() means, lookups in terms of number of interfaces and node visits during the search relate like this: interfaces-per-node | visits-per-lookup 1 | 1.0 2 | 2.0 3 | 2.6 4 | 3.0 5 | 3.3 6 | 3.6 8 | 4.0 16 | 5.0 32 | 6.0 64 | 7.0 128 | 8.0 256 | 9.0 512 | 10.0 1024 | 11.0 65536 | 17.0 262144 | 19.0 1048576 | 21.0 67108864 | 27.0 268435456 | 29.0 2147483648 | 32.0 that is, for all practical purposes, interface lookups are negligible even for many thausands of interfaces implemented per node. and now, please show me the OO system that gets into the hundreds at least... > Cheers, > -Tristan --- ciaoTJ From nicola@effe-gi.it Wed Jun 14 13:42:30 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id D182C3B0003 for ; Wed, 14 Jun 2006 13:42:30 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20727-04 for ; Wed, 14 Jun 2006 13:42:29 -0400 (EDT) Received: from mailout01.albacom.net (mailout01.albacom.net [217.220.34.13]) by menubar.gnome.org (Postfix) with SMTP id 968DC3B0081 for ; Wed, 14 Jun 2006 13:42:28 -0400 (EDT) Received: (qmail 15057 invoked by uid 508); 14 Jun 2006 17:41:43 -0000 Received: from nicola@effe-gi.it by mailout01.albacom.net with qmail-scanner (spamassassin: ???. Clear:RC:1(217.221.76.9):SA:0(0.0/15.0):. Processed in 2.56365 secs); 14 Jun 2006 17:41:43 -0000 Received: from unknown (HELO sviluppo.internet.local) (postmaster@effe-gi.it@217.221.76.9) by mailout01.albacom.net with SMTP; 14 Jun 2006 17:41:40 -0000 From: Fontana Nicola Organization: Elettronica EFFE-GI s.n.c. To: gtk-devel-list@gnome.org Subject: GObject extension propose (GContainer) Date: Wed, 14 Jun 2006 20:17:53 +0000 User-Agent: KMail/1.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200606142017.53525.nicola@effe-gi.it> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.599 tagged_above=-999 required=2 tests=[BAYES_00=-2.599] X-Spam-Score: -2.599 X-Spam-Level: X-Mailman-Approved-At: Sun, 18 Jun 2006 10:56:05 -0400 X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2006 17:42:31 -0000 Hi all, I'm a GObject based libraries (for UI purpose and not) user and I often need a generic container to derive my own types. In my opinion, I think this generic container must be included inside the GObject library ... it could be used by a lot of derived libraries providing a common approach. I published my solution - that is, what I am currently using - on sourceforge. http://sourceforge.net/projects/gcontainer/ Is it a good idea? Is something planned in this direction? Am I totally wrong? I need feedbacks ... Nicola From tristan.van.berkom@gmail.com Sun Jun 18 12:43:27 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 15A9A3B0BF9 for ; Sun, 18 Jun 2006 12:43:27 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03626-01 for ; Sun, 18 Jun 2006 12:43:26 -0400 (EDT) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.225]) by menubar.gnome.org (Postfix) with ESMTP id 1D9F83B0C2D for ; Sun, 18 Jun 2006 12:43:26 -0400 (EDT) Received: by wr-out-0506.google.com with SMTP id 37so824607wra for ; Sun, 18 Jun 2006 09:42:28 -0700 (PDT) Received: by 10.54.153.8 with SMTP id a8mr5030935wre; Sun, 18 Jun 2006 09:42:28 -0700 (PDT) Received: from ?66.48.170.160? ( [66.48.170.160]) by mx.gmail.com with ESMTP id 25sm98918wra.2006.06.18.09.42.26; Sun, 18 Jun 2006 09:42:27 -0700 (PDT) Message-ID: <44958664.4050704@gmail.com> Date: Sun, 18 Jun 2006 12:59:16 -0400 From: Tristan Van Berkom User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Janik Subject: Re: GObject extension propose (GContainer) References: <200606151101.12868.ntd@users.sourceforge.net> <44919246.8060301@gnome.org> <1150456522.5305.12.camel@localhost.localdomain> <1150491686.19405.355.camel@zosma.extratech.com> <44942B5F.2090903@gnome.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.495 tagged_above=-999 required=2 tests=[AWL=-0.351, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=1.456, SPF_PASS=-0.001] X-Spam-Score: -1.495 X-Spam-Level: Cc: Gtk+ Developers X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jun 2006 16:43:27 -0000 Tim Janik wrote: [...] > no there won't be a performance hit. [...] > 268435456 | 29.0 > 2147483648 | 32.0 > > that is, for all practical purposes, interface lookups are negligible > even > for many thausands of interfaces implemented per node. > Those stats look great Tim, sorry for any confusion I may have unwillingly caused in this thread, I think its of great importance that people not fear the GInterface. Cheers, -Tristan From jnoreiko@yahoo.com Sun Jun 18 15:19:51 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id E64063B0114 for ; Sun, 18 Jun 2006 15:19:50 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08166-08 for ; Sun, 18 Jun 2006 15:19:48 -0400 (EDT) Received: from web32405.mail.mud.yahoo.com (web32405.mail.mud.yahoo.com [68.142.207.198]) by menubar.gnome.org (Postfix) with SMTP id 24E153B00E5 for ; Sun, 18 Jun 2006 15:19:47 -0400 (EDT) Received: (qmail 1542 invoked by uid 60001); 18 Jun 2006 19:19:02 -0000 Message-ID: <20060618191902.1540.qmail@web32405.mail.mud.yahoo.com> Received: from [172.213.179.4] by web32405.mail.mud.yahoo.com via HTTP; Sun, 18 Jun 2006 20:19:02 BST Date: Sun, 18 Jun 2006 20:19:02 +0100 (BST) From: Joachim Noreiko Subject: Re: GtkFileChooser/GnomeVFS backend still messing up authentication manager? (was: GTK+ 2.10, the endgame) To: gtk-devel-list@gnome.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.64 tagged_above=-999 required=2 tests=[AWL=-0.688, BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2, DNS_FROM_RFC_WHOIS=1.447] X-Spam-Score: -1.64 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jun 2006 19:19:51 -0000 > Date: Sat, 17 Jun 2006 18:57:54 +0200 > From: Christian Neumair > Subject: GtkFileChooser/GnomeVFS backend still > > Are there other important bugs or regressions that > need > > attention before 2.10 ? Yes! Please could you implement a help button in the filechooser. The documentation is already written and is ready to be linked to. ___________________________________________________________ All new Yahoo! Mail "The new Interface is stunning in its simplicity and ease of use." - PC Magazine http://uk.docs.yahoo.com/nowyoucan.html From alexl@redhat.com Mon Jun 19 05:47:41 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id AB66D3B00A4 for ; Mon, 19 Jun 2006 05:47:41 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02513-02 for ; Mon, 19 Jun 2006 05:47:40 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id 4A6763B0014 for ; Mon, 19 Jun 2006 05:47:40 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5J9Aqqj029011; Mon, 19 Jun 2006 05:10:52 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5J9AqpA029834; Mon, 19 Jun 2006 05:10:52 -0400 Received: from [127.0.0.1] (sebastian-int.corp.redhat.com [172.16.52.221]) by devserv.devel.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5J9Ap4k026344; Mon, 19 Jun 2006 05:10:51 -0400 Subject: Re: Printing and blocking ui From: Alexander Larsson To: Yevgen Muntyan In-Reply-To: <4491AF5A.2050702@tamu.edu> References: <4491AF5A.2050702@tamu.edu> Content-Type: text/plain Date: Mon, 19 Jun 2006 11:10:51 +0200 Message-Id: <1150708251.1962.23.camel@greebo> Mime-Version: 1.0 X-Mailer: Evolution 2.7.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.588 tagged_above=-999 required=2 tests=[AWL=0.013, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.588 X-Spam-Level: Cc: GTK Devel List X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2006 09:47:41 -0000 On Thu, 2006-06-15 at 14:04 -0500, Yevgen Muntyan wrote: > Hi there, > > I print a text document from GtkTextView here. There is a problem > with pagination: pagination is potentially slow, so some sort of progress > dialog should be shown during it. From the other hand, the text buffer > must not be modified during pagination. > How to solve it? Should I show my own modal dialog and make sure user > doesn't modify the buffer, or GtkPrintOperation can take care of it? This is supported now with the Gtkprintoperation::paginate signal and gtk_print_operation_set_show_progress(). > Actually, it would be good to ensure printing blocks the text widget too, > since in this case it wouldn't be necessary to calculate and store all > the pango > layouts in begin-print. Maybe just show a modal dialog between begin-print > and end-print. Locking the editing widget is probably something you have to do yourself. You could also do a snapshot of the data at print time. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl@redhat.com alla@lysator.liu.se He's an otherworldly guerilla ex-con with a secret. She's a scantily clad belly-dancing widow who can talk to animals. They fight crime! From muntyan@tamu.edu Mon Jun 19 06:17:07 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 591293B00FB for ; Mon, 19 Jun 2006 06:17:07 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04050-03 for ; Mon, 19 Jun 2006 06:17:05 -0400 (EDT) Received: from smtp101.vzn.mail.mud.yahoo.com (smtp101.vzn.mail.mud.yahoo.com [68.142.203.45]) by menubar.gnome.org (Postfix) with SMTP id 64EE03B00C8 for ; Mon, 19 Jun 2006 06:17:05 -0400 (EDT) Received: (qmail 1322 invoked from network); 19 Jun 2006 10:16:02 -0000 Received: from unknown (HELO ?192.168.3.9?) (muntyan@verizon.net@71.113.224.59 with plain) by smtp101.vzn.mail.mud.yahoo.com with SMTP; 19 Jun 2006 10:16:01 -0000 Message-ID: <44967960.3060609@tamu.edu> Date: Mon, 19 Jun 2006 05:16:00 -0500 From: Yevgen Muntyan User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20060216 Debian/1.7.12-1.1ubuntu2 X-Accept-Language: en MIME-Version: 1.0 To: Alexander Larsson Subject: Re: Printing and blocking ui References: <4491AF5A.2050702@tamu.edu> <1150708251.1962.23.camel@greebo> In-Reply-To: <1150708251.1962.23.camel@greebo> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.553 tagged_above=-999 required=2 tests=[AWL=0.046, BAYES_00=-2.599] X-Spam-Score: -2.553 X-Spam-Level: Cc: GTK Devel List X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2006 10:17:07 -0000 Alexander Larsson wrote: >On Thu, 2006-06-15 at 14:04 -0500, Yevgen Muntyan wrote: > > >>Hi there, >> >>I print a text document from GtkTextView here. There is a problem >>with pagination: pagination is potentially slow, so some sort of progress >>dialog should be shown during it. From the other hand, the text buffer >>must not be modified during pagination. >>How to solve it? Should I show my own modal dialog and make sure user >>doesn't modify the buffer, or GtkPrintOperation can take care of it? >> >> > >This is supported now with the Gtkprintoperation::paginate signal and >gtk_print_operation_set_show_progress(). > > I don't know how paginate works, but the dialog which shows up during printing is not modal, and it appears only after some delay. I can erase text in the buffer between clicking Print button and the time when progress dialog appears. >>Actually, it would be good to ensure printing blocks the text widget too, >>since in this case it wouldn't be necessary to calculate and store all >>the pango >>layouts in begin-print. Maybe just show a modal dialog between begin-print >>and end-print. >> >> > >Locking the editing widget is probably something you have to do >yourself. You could also do a snapshot of the data at print time. > > Well, locking is easy, but I have to tell user about what's happening. So I guess the solution is to have my own modal progress dialog. Regards, Yevgen From mardy@users.sourceforge.net Mon Jun 19 10:20:09 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id B4CCC3B018E for ; Mon, 19 Jun 2006 10:20:09 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14994-07 for ; Mon, 19 Jun 2006 10:20:06 -0400 (EDT) Received: from smtp008.mail.ukl.yahoo.com (smtp008.mail.ukl.yahoo.com [217.12.11.62]) by menubar.gnome.org (Postfix) with SMTP id 190673B0076 for ; Mon, 19 Jun 2006 10:20:05 -0400 (EDT) Received: (qmail 79361 invoked from network); 19 Jun 2006 14:12:00 -0000 Received: from unknown (HELO pupilla) (mardy78@151.38.48.109 with login) by smtp008.mail.ukl.yahoo.com with SMTP; 19 Jun 2006 14:12:00 -0000 Received: by pupilla (Postfix, from userid 1000) id D59DB6B883; Mon, 19 Jun 2006 16:10:17 +0200 (CEST) Date: Mon, 19 Jun 2006 16:10:17 +0200 From: Alberto Mardegan To: gtk-devel-list@gnome.org Subject: GtkLabel as a child of a windowless widget Message-ID: <20060619141017.GA31744@pupilla> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Accept-Language: it,ia,en,bg,es,fr User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.599 tagged_above=-999 required=2 tests=[BAYES_00=-2.599] X-Spam-Score: -2.599 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2006 14:20:09 -0000 Hi all! I'm creating a Widget based on GtkFrame, with little differences: 1) It's not a container 2) It has the GTK_NO_WINDOW flag set. I'm going to use this widget inside a GtkFixed container, with the only goal of having it paint its frame (and draw its label) on the screen. I want it windowless, so that I can insert other widgets which will appear to be inside it, but which will be actually be owned by the GtkFixed. I know this is not really senseful, but I need such a widget for porting lots of applications from Prolific's Panther GUI to Gtk+. The problem I have, is that the frame label isn't drawn. I'm not sure if there are any operation I should do on it... I just create it, and call gtk_widget_set_parent(). On size_allocate, I'm not sure whether the child's x and y members of the size_allocation struct should be relative to (0,0) or to the parent widget's x and y allocation (since the parent is windowless, too). But this won't work in any case... Any hints? I have no clue. -- Saluti, Mardy http://interlingua.altervista.org Chiacchiera con i tuoi amici in tempo reale! http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com From ame1@extratech.com Mon Jun 19 11:13:35 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 1E8293B03A9 for ; Mon, 19 Jun 2006 11:13:35 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16850-05 for ; Mon, 19 Jun 2006 11:13:32 -0400 (EDT) Received: from portal2.extratech.com (portal.extratech.com [67.105.201.210]) by menubar.gnome.org (Postfix) with ESMTP id BF3D93B0076 for ; Mon, 19 Jun 2006 11:13:30 -0400 (EDT) Received: from zosma.extratech.com (zosma.extratech.com [192.168.0.41]) by portal2.extratech.com (8.12.11/8.12.11) with ESMTP id k5JFBMdd004376; Mon, 19 Jun 2006 08:11:22 -0700 Subject: Re: GObject extension propose (GContainer) From: "Alan M. Evans" To: Tristan Van Berkom In-Reply-To: <44942B5F.2090903@gnome.org> References: <200606151101.12868.ntd@users.sourceforge.net> <44919246.8060301@gnome.org> <1150456522.5305.12.camel@localhost.localdomain> <1150491686.19405.355.camel@zosma.extratech.com> <44942B5F.2090903@gnome.org> Content-Type: text/plain Message-Id: <1150729881.19405.420.camel@zosma.extratech.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 19 Jun 2006 08:11:21 -0700 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.86.1/1549/Sat Jun 17 15:20:39 2006 on portal2.extratech.com X-Virus-Status: Clean X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.551 tagged_above=-999 required=2 tests=[AWL=0.048, BAYES_00=-2.599] X-Spam-Score: -2.551 X-Spam-Level: Cc: Gtk+ Developers X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2006 15:13:35 -0000 On Sat, 2006-06-17 at 09:18, Tristan Van Berkom wrote: > Alan M. Evans wrote: > >>the lookup penalties are negligible. > >>type node/class lookups and is_a checks are O(1); > >>interface class lookups and conforms_to checks are O(ld(N)), where > >>N is the number of interfaces a type node conforms to. > > > >Your assertion that the penalties are negligable is not really supported > >by your response, unless the constant is also known for both orders.> > > > From my swift glance at gtype.c, it seems that in the case of > an interface, the implementing interface is searched on that class's > list of implementing interfaces... so when classes implement > hundreds of interfaces it might be a performance hit. My impression from the original question, which I didn't ask, was not so much about access to a large number of members. If a single variable needs to be examined many times then the performance penalty of a generic interface lookup can add up. In any case, I merely observed an assertion, "the lookup penalties are negligible," and the what appeared to be supporting data, the order of the lookups. This doesn't tell us what the penalty is, only that there is a penalty that gets worse as the number of members increases. Maybe the penalty is negligible, but the data presented didn't say so. That's all I was saying. > I dont think we've yet reached the day that we have to ditch good design > and avoid using interfaces because of performance woes, that would > be sorry day indeed... (I also dont think GTK+ code will be the only OO code > needing major refactoring in those areas too... if these interface > lookups weren't negligable) Indeed. I would certainly not advocate dispensing with good design. In fact, I usually advocate the purist design in my own software, and let Moore's Law fix the performance issues. But some cases still call for direct access for essential performance. I, too, would like to know the performance penalty of the generic interface. Being lazy, I suppose I will set up some experiment to discover it pragmatically. From federico@ximian.com Mon Jun 19 13:28:06 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id B62B13B05EF for ; Mon, 19 Jun 2006 13:28:06 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23010-05 for ; Mon, 19 Jun 2006 13:28:05 -0400 (EDT) Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) by menubar.gnome.org (Postfix) with ESMTP id 163BA3B0809 for ; Mon, 19 Jun 2006 13:28:04 -0400 (EDT) Received: (qmail 29558 invoked from network); 19 Jun 2006 17:27:00 -0000 Received: from localhost (HELO 164-99-120-63.boston.ximian.com) (127.0.0.1) by localhost with SMTP; 19 Jun 2006 17:27:00 -0000 Subject: Re: GtkFileChooser/GnomeVFS backend still messing up authentication manager? (was: GTK+ 2.10, the endgame) From: Federico Mena Quintero To: Joachim Noreiko In-Reply-To: <20060618191902.1540.qmail@web32405.mail.mud.yahoo.com> References: <20060618191902.1540.qmail@web32405.mail.mud.yahoo.com> Content-Type: text/plain Date: Mon, 19 Jun 2006 12:22:31 -0500 Message-Id: <1150737751.8452.77.camel@cacharro.xalalinux.org> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.575 tagged_above=-999 required=2 tests=[AWL=0.024, BAYES_00=-2.599] X-Spam-Score: -2.575 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2006 17:28:06 -0000 On Sun, 2006-06-18 at 20:19 +0100, Joachim Noreiko wrote: > Yes! > Please could you implement a help button in the > filechooser. The documentation is already written and > is ready to be linked to. Do we have a mechanism for this? I see that GtkColorSelectionDialog creates a Help button but hides it by default, and it gives GTK_RESPONSE_HELP when pressed. Does that get captured anywhere so that it can take you to the right help page? Federico From tvb@gnome.org Mon Jun 19 14:23:28 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 8657F3B04AC for ; Mon, 19 Jun 2006 14:23:28 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25353-05 for ; Mon, 19 Jun 2006 14:23:26 -0400 (EDT) Received: from mail.touchtunes.com (mail.touchtunes.com [207.96.182.162]) by menubar.gnome.org (Postfix) with ESMTP id 74D063B03C7 for ; Mon, 19 Jun 2006 14:23:26 -0400 (EDT) Received: from [192.168.0.138] (unknown [192.168.0.138]) by mail.touchtunes.com (Postfix) with ESMTP id 1C61615AAA; Mon, 19 Jun 2006 14:22:06 -0400 (EDT) Message-ID: <4496ED9C.3090009@gnome.org> Date: Mon, 19 Jun 2006 14:31:56 -0400 From: Tristan Van Berkom User-Agent: Mozilla Thunderbird 0.8 (X11/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alberto Mardegan Subject: Re: GtkLabel as a child of a windowless widget References: <20060619141017.GA31744@pupilla> In-Reply-To: <20060619141017.GA31744@pupilla> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.517 tagged_above=-999 required=2 tests=[AWL=0.006, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, TW_GT=0.077] X-Spam-Score: -2.517 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2006 18:23:28 -0000 Alberto Mardegan wrote: [...] > > Any hints? I have no clue. This mailing list is for the discussion of GTK+ development itself, for questions related to writing applications in gtk+ please write to gtk-app-devel-list@gnome.org or gtk-list@gnome.org. FYI: Widgets do not overlap in any containers in gtk+ (I've heard that there is z-ordering in gnomecanvas... you might want to check that out). You can: - Draw the frame yourself in the GtkFixed and place a child label where the frames label would be - Add a fixed as the child widget of the frame (probably what you want anyway). Cheers, -Tristan From federico@ximian.com Mon Jun 19 22:53:07 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 955513B044F for ; Mon, 19 Jun 2006 22:53:07 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18923-10 for ; Mon, 19 Jun 2006 22:53:06 -0400 (EDT) Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) by menubar.gnome.org (Postfix) with ESMTP id E23A03B0301 for ; Mon, 19 Jun 2006 22:53:05 -0400 (EDT) Received: (qmail 30485 invoked from network); 20 Jun 2006 02:52:00 -0000 Received: from localhost (HELO 164-99-120-63.boston.ximian.com) (127.0.0.1) by localhost with SMTP; 20 Jun 2006 02:52:00 -0000 Subject: Re: GtkLabel as a child of a windowless widget From: Federico Mena Quintero To: Alberto Mardegan In-Reply-To: <20060619141017.GA31744@pupilla> References: <20060619141017.GA31744@pupilla> Content-Type: text/plain Date: Mon, 19 Jun 2006 21:47:24 -0500 Message-Id: <1150771645.8452.94.camel@cacharro.xalalinux.org> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.575 tagged_above=-999 required=2 tests=[AWL=0.024, BAYES_00=-2.599] X-Spam-Score: -2.575 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2006 02:53:07 -0000 On Mon, 2006-06-19 at 16:10 +0200, Alberto Mardegan wrote: > Hi all! > I'm creating a Widget based on GtkFrame, with little differences: > 1) It's not a container > 2) It has the GTK_NO_WINDOW flag set. > > I'm going to use this widget inside a GtkFixed container, with the only > goal of having it paint its frame (and draw its label) on the screen. > I want it windowless, so that I can insert other widgets which will > appear to be inside it, but which will be actually be owned by the > GtkFixed. First, can you simply use a GtkFrame inside a GtkFixed, and just not put a child inside the frame? > The problem I have, is that the frame label isn't drawn. I'm not sure if > there are any operation I should do on it... I just create it, and call > gtk_widget_set_parent(). > On size_allocate, I'm not sure whether the child's x and y members of > the size_allocation struct should be relative to (0,0) or to the parent > widget's x and y allocation (since the parent is windowless, too). But > this won't work in any case... Allocations are always with respect to the parent window. So if you have a windowed parent, then inside it a no-window container at (10, 20), and a child of that container which is supposed to be offset (3, 4) pixels from the container's top-left corner, then the child's allocation will be at (13, 24). Federico From mclasen@redhat.com Tue Jun 20 09:27:18 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 4C2873B02C2 for ; Tue, 20 Jun 2006 09:27:18 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17744-01 for ; Tue, 20 Jun 2006 09:27:17 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id D5CE13B0184 for ; Tue, 20 Jun 2006 09:27:16 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5KDQgQV017831 for ; Tue, 20 Jun 2006 09:26:42 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5KDQbkk003106 for ; Tue, 20 Jun 2006 09:26:37 -0400 Received: from golem.boston.redhat.com (golem.boston.redhat.com [172.16.80.24]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id k5KDQbdH021200 for ; Tue, 20 Jun 2006 09:26:37 -0400 Subject: GTK+ team meeting From: Matthias Clasen To: gtk-devel-list@gnome.org Content-Type: text/plain Date: Tue, 20 Jun 2006 09:26:36 -0400 Message-Id: <1150809996.15532.50.camel@golem.boston.redhat.com> Mime-Version: 1.0 X-Mailer: Evolution 2.7.1 (2.7.1-1) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.543 tagged_above=-999 required=2 tests=[AWL=0.058, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.543 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2006 13:27:18 -0000 After a few weeks, we should probably have a team meeting today. The meeting is intended for the GTK+ team, but everybody is welcome to come and listen. The meeting logs will be posted on the GTK+ website (http://www.gtk.org/plan/meetings). Place: irc.gnome.org:#gtk-devel Time: 19:30 UTC (15:30 EDT), Tue, Jun 20 Possible agenda items: - GUADEC meeting - 2.10 + when to release + what needs to be on the 2.10 milestone but isn't ? Matthias From mclasen@redhat.com Tue Jun 20 11:22:11 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 3B32C3B043F; Tue, 20 Jun 2006 11:22:11 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22457-09; Tue, 20 Jun 2006 11:22:09 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id 71CF13B00E7; Tue, 20 Jun 2006 11:22:09 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5KFLLnL004523; Tue, 20 Jun 2006 11:21:21 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5KFLLNA016479; Tue, 20 Jun 2006 11:21:21 -0400 Received: from golem.boston.redhat.com (golem.boston.redhat.com [172.16.80.24]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id k5KFLKdH032719; Tue, 20 Jun 2006 11:21:20 -0400 Subject: GLib 2.11.4 released From: Matthias Clasen To: gnome-announce-list@gnome.org, gtk-devel-list@gnome.org, gtk-list@gnome.org, gtk-app-devel-list@gnome.org Content-Type: text/plain Date: Tue, 20 Jun 2006 11:21:20 -0400 Message-Id: <1150816880.15532.58.camel@golem.boston.redhat.com> Mime-Version: 1.0 X-Mailer: Evolution 2.7.1 (2.7.1-1) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.543 tagged_above=-999 required=2 tests=[AWL=0.058, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.543 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: gnome-hackers@gnome.org List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2006 15:22:11 -0000 GLib 2.11.4 is now available for download at: ftp://ftp.gtk.org/pub/gtk/v2.11/ http://ftp.gnome.org/pub/GNOME/sources/glib/2.11/ glib-2.11.4.tar.bz2 md5sum: 9d3a94baa4bfcd9a579b45eea6de3a8c glib-2.11.4.tar.gz md5sum: f7768bc7ed524c6b40cb87daccb6c2b2 This is a development release leading up to GLib 2.12. Notes: * This is unstable development release. While it has had a bit of testing, there are certainly plenty of bugs remaining to be found. This release should not be used in production. * Installing this version will overwrite your existing copy of GLib 2.10. If you have problems, you'll need to reinstall GLib 2.10. * GLib 2.12 will be source and binary compatible with the GLib 2.10.x series (for some caveats, see the README). At this point, the API additions in the 2.11.x series are finished. * Bugs should be reported to http://bugzilla.gnome.org. About GLib ========== GLib is the low-level core library that forms the basis for projects such as GTK+ and GNOME. It provides data structure handling for C, portability wrappers, and interfaces for such runtime functionality as an event loop, threads, dynamic loading, and an object system. More information about GLib is available at: http://www.gtk.org/ An installation guide for the GTK+ libraries, including GLib, can be found at: http://developer.gnome.org/doc/API/2.0/gtk/gtk-building.html Overview of Changes from GLib 2.11.3 to GLib 2.11.4 =================================================== * GBookmarkFile: - g_bookmark_file_remove_item returns a boolean * g_mkstemp accepts the XXXXXX in the middle of the template * Bugs fixed: 344868 g_key_file_to_data should separate groups * Updated translations (de,es,fr,gu,hi,ko,th) A list of all bugs fixed in this release can be found at: http://bugzilla.gnome.org/buglist.cgi?bug_id=344868 Thanks to everybody who has contributed to this release, in the form of bug reports or patches: Emmanuele Bassi, Christian Persch, Federico Mena Quintero Matthias Clasen June 20, 2006 From mgiannakidis@gmail.com Mon Jun 19 08:23:48 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id E62893B0AAF for ; Mon, 19 Jun 2006 08:23:47 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10711-01 for ; Mon, 19 Jun 2006 08:23:44 -0400 (EDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.191]) by menubar.gnome.org (Postfix) with ESMTP id E721A3B089A for ; Mon, 19 Jun 2006 08:23:43 -0400 (EDT) Received: by nf-out-0910.google.com with SMTP id x30so1070652nfb for ; Mon, 19 Jun 2006 05:22:35 -0700 (PDT) Received: by 10.48.14.1 with SMTP id 1mr1206423nfn; Mon, 19 Jun 2006 05:16:27 -0700 (PDT) Received: from ?213.140.137.120? ( [213.140.137.120]) by mx.gmail.com with ESMTP id d2sm4750763nfe.2006.06.19.05.16.26; Mon, 19 Jun 2006 05:16:26 -0700 (PDT) From: Michalis Giannakidis To: gtk-devel-list@gnome.org Subject: Re: gslice allocator: general impresions. Date: Mon, 19 Jun 2006 15:20:48 +0300 User-Agent: KMail/1.8.3 References: <200606151827.45477.mgiannakidis@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200606191520.48220.mgiannakidis@gmail.com> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.526 tagged_above=-999 required=2 tests=[AWL=-0.002, BAYES_00=-2.599, SPF_PASS=-0.001, TW_TX=0.077] X-Spam-Score: -2.526 X-Spam-Level: X-Mailman-Approved-At: Tue, 20 Jun 2006 12:30:13 -0400 X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2006 12:23:48 -0000 Dear Tim > > (I have modified gslice > > to align a chunk to its own size so that I don't have unused memory > > between chunks eg: request 20 and get 24...) > > you mean you've set P2ALIGNMENT to 1 * sizeof(void*) to get better > granularity of the slices? have you left NATIVE_MALLOC_PADDING at > 2*sizeof(void*) at least? (if not, memory fragmentation on some glibc > systems and on all 64bit systems can become etxremely bad). > I didn't change P2ALIGNMENT . I modified SLAB_INDEX to (asize - 1), SLAB_CHUNK_SIZE to (ix + 1) I also modified P2ALIGN to (size) for all occurances of P2ALIGN except for SLAB_INFO_SIZE. I understand that this will create different memory pools for each size I alloc for, but this is accpeted since I only call g_slice_alloc for two sizes. The tweak seem to be OK since I don't get any segfaults. > maybe due to your alignment tweaks. but maybe also because some malloc() > buckets will have even longer lists that way. > The slowdown also occurred without the alignment tweaks. My understanding is that it is a general malloc slowdown that occurres of the many small mallocs done in the application plus the many larger mallocs done by the gslice allocator. I have read the references available in the gslice allocator comments and were very helpful. What I am looking for know is some sort of comparisons in memory usage and speed in applications changing from malloc to gslice. Also, any tweaks in the gslice allocation sizes providing a more responsive malloc would be great! Any suggestions would be very welcome. Thank you very much. Michalis -- Michalis Giannakidis From mclasen@redhat.com Wed Jun 21 09:13:22 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C2BA53B1007 for ; Wed, 21 Jun 2006 09:13:22 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07614-06 for ; Wed, 21 Jun 2006 09:13:21 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id E02C63B0FE5 for ; Wed, 21 Jun 2006 09:13:20 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5LDDKUh027657; Wed, 21 Jun 2006 09:13:20 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5LDDJnE017553; Wed, 21 Jun 2006 09:13:19 -0400 Received: from golem.boston.redhat.com (golem.boston.redhat.com [172.16.80.24]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id k5LDDJdH018065; Wed, 21 Jun 2006 09:13:19 -0400 Subject: Re: Fwd: GTK+ 2.10, the endgame From: Matthias Clasen To: Guillaume Cottenceau In-Reply-To: References: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> Content-Type: text/plain Date: Wed, 21 Jun 2006 09:13:19 -0400 Message-Id: <1150895599.15532.80.camel@golem.boston.redhat.com> Mime-Version: 1.0 X-Mailer: Evolution 2.7.1 (2.7.1-1) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.506 tagged_above=-999 required=2 tests=[AWL=0.018, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, TW_GT=0.077] X-Spam-Score: -2.506 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2006 13:13:23 -0000 On Wed, 2006-06-21 at 08:38 +0200, Guillaume Cottenceau wrote: > Hi Matthias, > > Could you just drop a line on the list about this question? > > Thanks in advance. > > ---------- Forwarded message ---------- > From: Guillaume Cottenceau > Date: Jun 17, 2006 7:22 PM > Subject: Re: GTK+ 2.10, the endgame > To: Matthias Clasen > Cc: gtk-devel-list@gnome.org > > > On 6/15/06, Matthias Clasen wrote: > > Therefore, I want to consider 2.9.3 api frozen, and take a > > Does this mean that > http://developer.gnome.org/doc/API/2.0/gtk/ix07.html (and equivalents > for gdk, pango, atk) is now a fully stable source for bindings which > want to support new features of 2.10? > > -- > Guillaume Cottenceau - http://zarb.org/~gc/ > The online documentation is still at 2.9.2. I hope to find time to update it to 2.9.4 before leaving for GUADEC tomorrow. A small number of API additions turned out to be necessary in the lowlevel printing apis after 2.9.3: gtk_enumerate_printers GTK_PRINT_CAPABILITY_CAN_GENERATE_PS GTK_PRINT_SETTINGS_OUTPUT_FILE_FORMAT GTK_PRINT_SETTINGS_OUTPUT_URI Furthermore, GTK_PRINT_SETTINGS_PRINT_TO_FILE was found to be unused and removed, together with its setter and getter. Matthias From mclasen@redhat.com Wed Jun 21 13:35:58 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id EE5983B046D for ; Wed, 21 Jun 2006 13:35:57 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25325-06 for ; Wed, 21 Jun 2006 13:35:56 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id 7ACFF3B02CE for ; Wed, 21 Jun 2006 13:35:56 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5LHZtpq012200 for ; Wed, 21 Jun 2006 13:35:55 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5LHZthC009595 for ; Wed, 21 Jun 2006 13:35:55 -0400 Received: from golem.boston.redhat.com (golem.boston.redhat.com [172.16.80.24]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id k5LHZtdH019718 for ; Wed, 21 Jun 2006 13:35:55 -0400 Subject: Looking beyond 2.10 From: Matthias Clasen To: gtk-devel-list@gnome.org Content-Type: text/plain Date: Wed, 21 Jun 2006 13:35:55 -0400 Message-Id: <1150911355.15532.100.camel@golem.boston.redhat.com> Mime-Version: 1.0 X-Mailer: Evolution 2.7.1 (2.7.1-1) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.545 tagged_above=-999 required=2 tests=[AWL=0.056, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.545 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2006 17:35:58 -0000 So, with GTK+ 2.10 on the finish line, I tried to make a quick list of things we may want to look at for 2.12, as input to GUADEC discussions. Patches almost ready to go in - libglade integration - new tooltips api Stuff that needs more work - introspection - international calendar support Stuff that we need to figure out - canvas - libsexy cherrypicking ? (Of course, bugzilla has an endless supply of feature requests and bugs that one can work on, these are just the things that came to my mind first) Matthias From hfiguiere@teaser.fr Wed Jun 21 15:04:27 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C0B713B00F6 for ; Wed, 21 Jun 2006 15:04:27 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31064-02 for ; Wed, 21 Jun 2006 15:04:19 -0400 (EDT) Received: from xandros.com (smtp1.xandros.com [209.87.238.70]) by menubar.gnome.org (Postfix) with ESMTP id 873C83B02DA for ; Wed, 21 Jun 2006 15:04:14 -0400 (EDT) Received: from [172.16.1.95] (unknown [209.87.238.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by xandros.com (Postfix) with ESMTP id 09337A030 for ; Wed, 21 Jun 2006 15:04:13 -0400 (EDT) Message-ID: <4499982C.1010004@teaser.fr> Date: Wed, 21 Jun 2006 15:04:12 -0400 From: Hubert Figuiere User-Agent: Thunderbird 1.5.0.4 (X11/20060615) MIME-Version: 1.0 To: gtk-devel-list@gnome.org Subject: Re: Looking beyond 2.10 References: <1150911355.15532.100.camel@golem.boston.redhat.com> In-Reply-To: <1150911355.15532.100.camel@golem.boston.redhat.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.542 tagged_above=-999 required=2 tests=[AWL=0.057, BAYES_00=-2.599] X-Spam-Score: -2.542 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2006 19:04:27 -0000 Matthias Clasen wrote: > Stuff that needs more work > > - introspection > - international calendar support Complete MacOS X support? I'm about to pick Qt as a toolkit for a personal project just because of that. Hub From matthias.clasen@gmail.com Wed Jun 21 18:26:02 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id A5B4E3B006C for ; Wed, 21 Jun 2006 18:26:02 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09882-05 for ; Wed, 21 Jun 2006 18:26:01 -0400 (EDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.177]) by menubar.gnome.org (Postfix) with ESMTP id 477AE3B00F8 for ; Wed, 21 Jun 2006 18:26:01 -0400 (EDT) Received: by py-out-1112.google.com with SMTP id e30so107107pya for ; Wed, 21 Jun 2006 15:26:00 -0700 (PDT) Received: by 10.35.111.14 with SMTP id o14mr363031pym; Wed, 21 Jun 2006 15:26:00 -0700 (PDT) Received: by 10.35.39.16 with HTTP; Wed, 21 Jun 2006 15:26:00 -0700 (PDT) Message-ID: Date: Wed, 21 Jun 2006 18:26:00 -0400 From: "Matthias Clasen" To: "Hubert Figuiere" Subject: Re: Looking beyond 2.10 In-Reply-To: <4499982C.1010004@teaser.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1150911355.15532.100.camel@golem.boston.redhat.com> <4499982C.1010004@teaser.fr> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.51 tagged_above=-999 required=2 tests=[AWL=0.090, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.51 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2006 22:26:02 -0000 On 6/21/06, Hubert Figuiere wrote: > Matthias Clasen wrote: > > > Stuff that needs more work > > > > - introspection > > - international calendar support > > Complete MacOS X support? Sure, if someone with access to a Mac works on it. I don't have a Mac... > I'm about to pick Qt as a toolkit for a personal project just because of > that. Good luck. Matthias From trowbrds@gmail.com Wed Jun 21 18:29:52 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 103073B0011 for ; Wed, 21 Jun 2006 18:29:52 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10124-04 for ; Wed, 21 Jun 2006 18:29:49 -0400 (EDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.185]) by menubar.gnome.org (Postfix) with ESMTP id B842D3B00E4 for ; Wed, 21 Jun 2006 18:29:48 -0400 (EDT) Received: by nf-out-0910.google.com with SMTP id h2so177759nfe for ; Wed, 21 Jun 2006 15:29:47 -0700 (PDT) Received: by 10.49.81.12 with SMTP id i12mr1011269nfl; Wed, 21 Jun 2006 15:29:47 -0700 (PDT) Received: by 10.49.36.8 with HTTP; Wed, 21 Jun 2006 15:29:47 -0700 (PDT) Message-ID: Date: Wed, 21 Jun 2006 16:29:47 -0600 From: "David Trowbridge" To: gtk-devel-list@gnome.org Subject: Re: Looking beyond 2.10 In-Reply-To: <1150911355.15532.100.camel@golem.boston.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1150911355.15532.100.camel@golem.boston.redhat.com> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.538 tagged_above=-999 required=2 tests=[AWL=0.062, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.538 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2006 22:29:52 -0000 On 6/21/06, Matthias Clasen wrote: > - libsexy cherrypicking ? The icon entry and url labels are probably robust enough (and widely useful enough) to go in. For anything else, it will require some work. -David From mclasen@redhat.com Wed Jun 21 23:10:41 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id AA4213B0172; Wed, 21 Jun 2006 23:10:41 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23030-07; Wed, 21 Jun 2006 23:10:39 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id 63BA23B0008; Wed, 21 Jun 2006 23:10:39 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5M3AclX021506; Wed, 21 Jun 2006 23:10:38 -0400 Received: from lacrosse.corp.redhat.com (lacrosse.corp.redhat.com [172.16.52.154]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5M3AcnM019751; Wed, 21 Jun 2006 23:10:38 -0400 Received: from [172.16.83.158] (vpn83-158.boston.redhat.com [172.16.83.158]) by lacrosse.corp.redhat.com (8.12.11.20060308/8.11.6) with ESMTP id k5M3AciB004961; Wed, 21 Jun 2006 23:10:38 -0400 Subject: GTK+ 2.9.4 released From: Matthias Clasen To: gnome-announce-list@gnome.org, gtk-devel-list@gnome.org, gtk-app-devel-list@gnome.org, gtk-list@gnome.org Content-Type: text/plain Organization: Red Hat Date: Wed, 21 Jun 2006 23:12:41 -0400 Message-Id: <1150945961.4457.2.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.7.3 (2.7.3-2) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.507 tagged_above=-999 required=2 tests=[AWL=0.017, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, TW_GT=0.077] X-Spam-Score: -2.507 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: gnome-hackers@gnome.org List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 03:10:42 -0000 GTK+ 2.9.4 is now available for download at: http://ftp.gnome.org/pub/gnome/sources/gtk+/2.9/ gtk+-2.9.4.tar.bz2 md5sum: c06cf2cfa66485600d90789c9e58f27c gtk+-2.9.4.tar.gz md5sum: e3fefedc7f1a89b66c71c9967168a857 This is a development release leading up to GTK+ 2.10. Notes: * This is unstable development release. There are certainly plenty of bugs remaining to be found. This release should not be used in production. * Installing this version will overwrite your existing copy of GTK+ 2.8. If you have problems, you'll need to reinstall GTK+ 2.8. * GTK+ 2.10 will be source compatible with the GTK+ 2.8 series; the new API additions in GTK+ 2.9.0 are finalized by now. * The ABI version has been bumped from 2.4.0 to 2.10.0, since the filechooser backend interface has been changed. Third-party filechooser backends need to be ported to the new interface. Other third-party modules (input methods, image loaders, etc) just need to be reinstalled in the proper location for GTK+ to find them. * Remaining issues for GTK+ 2.10 can be found with following bugzilla query: http://bugzilla.gnome.org/buglist.cgi?product=gtk%2b&target_milestone=2.10+API+Freeze&target_milestone=2.10+Freeze&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED * Bugs should be reported to http://bugzilla.gnome.org. What is GTK+ ============ GTK+ is a multi-platform toolkit for creating graphical user interfaces. Offering a complete set of widgets, GTK+ is suitable for projects ranging from small one-off tools to complete application suites. GTK+ has been designed from the ground up to support a range of languages, not only C/C++. Using GTK+ from languages such as Perl and Python (especially in combination with the Glade GUI builder) provides an effective method of rapid application development. GTK+ is free software and part of the GNU Project. However, the licensing terms for GTK+, the GNU LGPL, allow it to be used by all developers, including those developing proprietary software, without any license fees or royalties. Where to get more information about GTK+ ======================================== Information about GTK+ including links to documentation can be found at: http://www.gtk.org/ An installation guide for GTK+ 2.x is found at: http://developer.gnome.org/doc/API/2.4/gtk/gtk-building.html Common questions: http://developer.gnome.org/doc/API/2.4/gtk/gtk-question-index.html http://www.gtk.org/faq/ Overview of Changes from GTK+ 2.9.3 to 2.9.4 ============================================ * GtkPrintOperation: - UI improvements in the print dialog - Make printing work without a display connection - Replace "Print to PDF" by "Print to file" that can generate PDF or PostScript - Add a function to the low-level API to enumerate all printers * GtkNotebook tab DND has been improved * GtkProgressbar supports text in activity mode * GtkLabel allows to set the wrap mode * GtkStatusIcon supports transparency * Bugs fixed: 344850 Dragging a GtkTreeViewColumn segfaults when using certain GtkTreeViewColumnDropFunc 342458 Stock menu items without icons are broken in recent GTK+ releases. 335873 notebook DND + popup windows 337882 gtk_progress_bar_set_text() does nothing in activity mode 339456 unix print dialogue help button bug 339702 Make sure printing works without a display 341571 tabs too easily reordered 344074 New Feature: get printer list, and get default print 344743 gtk_targets_include_text() should initialize atoms 344838 Allow func to be NULL in gtk_tree_view_set_search_position_func 344891 GtkPrintOperationPreview signal defs correction 345008 Need updated cairo req 345093 print preview temp file issues 345107 Memory leak in gtk_entry_completion_finalize: User data not freed 345194 gdk_window_set_functions() docs need to be updated 345456 grid-lines property is wrongly registered and get/set. 314278 strings in gtk-update-icon-cache are not marked for translation 344707 size group with widgets in hidden container 344897 Entry completion model NULL handling should be documented 345038 gtk_print_job_set_status' status 345106 dialog button box spacings 345176 GtkIconView doc about drag and drop 345275 doc imporovements for gtk_window_move 345320 Two very similiar strings should be made equal 345321 Add meaning of "shortcut" as translator comment 320034 transparency gtkstatusicon 339592 Add print-to-postscript 344867 custom paper file could use keyfile * Updated translations (cs,de,es,fr,gl,gu,hi,ko,ta,th) A list of all bugs fixed in this release can be found at http://bugzilla.gnome.org/buglist.cgi?bug_id=344838,344743,344867,344891,345008,341571,345038,337882,345093,344707,339456,345107,345275,339702,344074,345320,345321,344897,314278,320034,344850,345194,345176,345106,335873,342458,339592,345456 Thanks to everybody who has contributed to this release, in the form of bug reports or patches: Christian Persch, John Finlay, Federico Mena Quintero, Michael Emmel, Marko Anastasov, Bastien Nocera, Carlos Garnacho, Yevgen Muntyan, Tommi Komulainen, Tim Janik, Christian Weiske, Behdad Esfahbod, Alexander Larsson, Felipe Heidrich, Hendrik Richter, Claudio Saavedra, Dan Winship, Callum McKenzie, John Palmieri, Murray Cumming, Kristian Rietveld June 21, 2006 Matthias Clasen From alexl@redhat.com Thu Jun 22 03:30:13 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id F02D73B04C8 for ; Thu, 22 Jun 2006 03:30:12 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04379-10 for ; Thu, 22 Jun 2006 03:30:11 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id 3177C3B021B for ; Thu, 22 Jun 2006 03:30:11 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5M7UAw1025719 for ; Thu, 22 Jun 2006 03:30:10 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5M7UAI5026706; Thu, 22 Jun 2006 03:30:10 -0400 Received: from [127.0.0.1] (sebastian-int.corp.redhat.com [172.16.52.221]) by devserv.devel.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5M7U90l029917; Thu, 22 Jun 2006 03:30:09 -0400 Subject: Re: Looking beyond 2.10 From: Alexander Larsson To: Matthias Clasen In-Reply-To: <1150911355.15532.100.camel@golem.boston.redhat.com> References: <1150911355.15532.100.camel@golem.boston.redhat.com> Content-Type: text/plain Date: Thu, 22 Jun 2006 09:30:09 +0200 Message-Id: <1150961409.16397.101.camel@greebo> Mime-Version: 1.0 X-Mailer: Evolution 2.7.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.588 tagged_above=-999 required=2 tests=[AWL=0.013, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.588 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 07:30:13 -0000 On Wed, 2006-06-21 at 13:35 -0400, Matthias Clasen wrote: > So, with GTK+ 2.10 on the finish line, I tried to make a quick > list of things we may want to look at for 2.12, as input to > GUADEC discussions. The EditableLable stuff would be nice to have in gtk+: http://live.gnome.org/ProjectRidley/EelEditableLabel This would mean i could drop EelEditableLabel, and i'm sure others need something like this too. For instance, GtkIconView would need it to support renaming. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl@redhat.com alla@lysator.liu.se He's a lonely hunchbacked matador on the edge. She's a radical impetuous single mother who don't take no shit from nobody. They fight crime! From mclasen@redhat.com Thu Jun 22 09:23:37 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 8880D3B0667 for ; Thu, 22 Jun 2006 09:23:37 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30015-09 for ; Thu, 22 Jun 2006 09:23:23 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id 58F4B3B03E5 for ; Thu, 22 Jun 2006 09:23:04 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5MDN3ca016505 for ; Thu, 22 Jun 2006 09:23:03 -0400 Received: from lacrosse.corp.redhat.com (lacrosse.corp.redhat.com [172.16.52.154]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5MDN3dV000789; Thu, 22 Jun 2006 09:23:03 -0400 Received: from [172.16.83.176] (vpn83-176.boston.redhat.com [172.16.83.176]) by lacrosse.corp.redhat.com (8.12.11.20060308/8.11.6) with ESMTP id k5MDN2MM012188; Thu, 22 Jun 2006 09:23:03 -0400 Subject: Re: Looking beyond 2.10 From: Matthias Clasen To: Alexander Larsson In-Reply-To: <1150961409.16397.101.camel@greebo> References: <1150911355.15532.100.camel@golem.boston.redhat.com> <1150961409.16397.101.camel@greebo> Content-Type: text/plain Organization: Red Hat Date: Thu, 22 Jun 2006 09:25:07 -0400 Message-Id: <1150982707.2966.6.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.7.3 (2.7.3-2) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.546 tagged_above=-999 required=2 tests=[AWL=0.055, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.546 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 13:23:37 -0000 On Thu, 2006-06-22 at 09:30 +0200, Alexander Larsson wrote: > On Wed, 2006-06-21 at 13:35 -0400, Matthias Clasen wrote: > > So, with GTK+ 2.10 on the finish line, I tried to make a quick > > list of things we may want to look at for 2.12, as input to > > GUADEC discussions. > > The EditableLable stuff would be nice to have in gtk+: > http://live.gnome.org/ProjectRidley/EelEditableLabel > > This would mean i could drop EelEditableLabel, and i'm sure others need > something like this too. For instance, GtkIconView would need it to > support renaming. > Not that it would not be useful, but GtkIconView uses cell renderers, and already supports editing... From alexl@redhat.com Thu Jun 22 09:33:59 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 9529C3B0748 for ; Thu, 22 Jun 2006 09:33:59 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30708-06 for ; Thu, 22 Jun 2006 09:33:54 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id B4FBD3B0559 for ; Thu, 22 Jun 2006 09:33:54 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5MDXsaJ021314 for ; Thu, 22 Jun 2006 09:33:54 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5MDXrtU004254; Thu, 22 Jun 2006 09:33:53 -0400 Received: from [127.0.0.1] (sebastian-int.corp.redhat.com [172.16.52.221]) by devserv.devel.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5MDXqt9025805; Thu, 22 Jun 2006 09:33:53 -0400 Subject: Re: Looking beyond 2.10 From: Alexander Larsson To: Matthias Clasen In-Reply-To: <1150982707.2966.6.camel@localhost.localdomain> References: <1150911355.15532.100.camel@golem.boston.redhat.com> <1150961409.16397.101.camel@greebo> <1150982707.2966.6.camel@localhost.localdomain> Content-Type: text/plain Date: Thu, 22 Jun 2006 15:33:52 +0200 Message-Id: <1150983232.16397.107.camel@greebo> Mime-Version: 1.0 X-Mailer: Evolution 2.7.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.588 tagged_above=-999 required=2 tests=[AWL=0.013, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.588 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 13:33:59 -0000 On Thu, 2006-06-22 at 09:25 -0400, Matthias Clasen wrote: > On Thu, 2006-06-22 at 09:30 +0200, Alexander Larsson wrote: > > On Wed, 2006-06-21 at 13:35 -0400, Matthias Clasen wrote: > > > So, with GTK+ 2.10 on the finish line, I tried to make a quick > > > list of things we may want to look at for 2.12, as input to > > > GUADEC discussions. > > > > The EditableLable stuff would be nice to have in gtk+: > > http://live.gnome.org/ProjectRidley/EelEditableLabel > > > > This would mean i could drop EelEditableLabel, and i'm sure others need > > something like this too. For instance, GtkIconView would need it to > > support renaming. > > > > Not that it would not be useful, but GtkIconView uses cell renderers, > and already supports editing... How does that handle labels that are several lines long? =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl@redhat.com alla@lysator.liu.se He's a war-weary moralistic waffle chef with nothing left to lose. She's an orphaned red-headed barmaid looking for love in all the wrong places. They fight crime! From mclasen@redhat.com Thu Jun 22 09:48:21 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 98DD03B04F0 for ; Thu, 22 Jun 2006 09:48:21 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31802-05 for ; Thu, 22 Jun 2006 09:48:20 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id DD2613B00DE for ; Thu, 22 Jun 2006 09:48:19 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5MDmJQS027439 for ; Thu, 22 Jun 2006 09:48:19 -0400 Received: from lacrosse.corp.redhat.com (lacrosse.corp.redhat.com [172.16.52.154]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5MDmJB6008537; Thu, 22 Jun 2006 09:48:19 -0400 Received: from [172.16.83.176] (vpn83-176.boston.redhat.com [172.16.83.176]) by lacrosse.corp.redhat.com (8.12.11.20060308/8.11.6) with ESMTP id k5MDmIjF015592; Thu, 22 Jun 2006 09:48:18 -0400 Subject: Re: Looking beyond 2.10 From: Matthias Clasen To: Alexander Larsson In-Reply-To: <1150983232.16397.107.camel@greebo> References: <1150911355.15532.100.camel@golem.boston.redhat.com> <1150961409.16397.101.camel@greebo> <1150982707.2966.6.camel@localhost.localdomain> <1150983232.16397.107.camel@greebo> Content-Type: text/plain Organization: Red Hat Date: Thu, 22 Jun 2006 09:50:23 -0400 Message-Id: <1150984223.2966.10.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.7.3 (2.7.3-2) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.546 tagged_above=-999 required=2 tests=[AWL=0.055, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.546 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 13:48:21 -0000 On Thu, 2006-06-22 at 15:33 +0200, Alexander Larsson wrote: > On Thu, 2006-06-22 at 09:25 -0400, Matthias Clasen wrote: > > On Thu, 2006-06-22 at 09:30 +0200, Alexander Larsson wrote: > > > On Wed, 2006-06-21 at 13:35 -0400, Matthias Clasen wrote: > > > > So, with GTK+ 2.10 on the finish line, I tried to make a quick > > > > list of things we may want to look at for 2.12, as input to > > > > GUADEC discussions. > > > > > > The EditableLable stuff would be nice to have in gtk+: > > > http://live.gnome.org/ProjectRidley/EelEditableLabel > > > > > > This would mean i could drop EelEditableLabel, and i'm sure others need > > > something like this too. For instance, GtkIconView would need it to > > > support renaming. > > > > > > > Not that it would not be useful, but GtkIconView uses cell renderers, > > and already supports editing... > > How does that handle labels that are several lines long? > As well as the treeview does... eventually we'll have to sit down and add multline to GtkEntry... From alexl@redhat.com Thu Jun 22 09:52:23 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 292473B081B for ; Thu, 22 Jun 2006 09:52:23 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32031-08 for ; Thu, 22 Jun 2006 09:52:21 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id 83E8E3B0811 for ; Thu, 22 Jun 2006 09:52:21 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5MDqKud029180 for ; Thu, 22 Jun 2006 09:52:21 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5MDqFg0009757; Thu, 22 Jun 2006 09:52:15 -0400 Received: from [127.0.0.1] (sebastian-int.corp.redhat.com [172.16.52.221]) by devserv.devel.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5MDqE6x027583; Thu, 22 Jun 2006 09:52:14 -0400 Subject: Re: Looking beyond 2.10 From: Alexander Larsson To: Matthias Clasen In-Reply-To: <1150984223.2966.10.camel@localhost.localdomain> References: <1150911355.15532.100.camel@golem.boston.redhat.com> <1150961409.16397.101.camel@greebo> <1150982707.2966.6.camel@localhost.localdomain> <1150983232.16397.107.camel@greebo> <1150984223.2966.10.camel@localhost.localdomain> Content-Type: text/plain Date: Thu, 22 Jun 2006 15:52:14 +0200 Message-Id: <1150984334.16397.110.camel@greebo> Mime-Version: 1.0 X-Mailer: Evolution 2.7.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.588 tagged_above=-999 required=2 tests=[AWL=0.013, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.588 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 13:52:23 -0000 On Thu, 2006-06-22 at 09:50 -0400, Matthias Clasen wrote: > On Thu, 2006-06-22 at 15:33 +0200, Alexander Larsson wrote: > > > How does that handle labels that are several lines long? > > As well as the treeview does... eventually we'll have to sit down > and add multline to GtkEntry... Thats basically what EelEditableLabel is. I'm not sure its better to combine the two into one than having a separate widget for it. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl@redhat.com alla@lysator.liu.se He's a sword-wielding Catholic gangster fleeing from a secret government programme. She's a beautiful mute snake charmer with the power to bend men's minds. They fight crime! From Bill.Haneman@Sun.COM Thu Jun 22 09:59:01 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id A04A33B06B5 for ; Thu, 22 Jun 2006 09:59:01 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32611-04 for ; Thu, 22 Jun 2006 09:58:59 -0400 (EDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by menubar.gnome.org (Postfix) with ESMTP id EC16D3B0487 for ; Thu, 22 Jun 2006 09:58:52 -0400 (EDT) Received: from phys-gadget-1 ([129.156.85.171]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k5MDwpH2016279 for ; Thu, 22 Jun 2006 07:58:52 -0600 (MDT) Received: from conversion-daemon.gadget-mail1.uk.sun.com by gadget-mail1.uk.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0J1900F01LG3TK@gadget-mail1.uk.sun.com> (original mail from Bill.Haneman@Sun.COM) for gtk-devel-list@gnome.org; Thu, 22 Jun 2006 14:58:51 +0100 (BST) Received: from [192.168.1.120] (vpn-129-150-116-130.UK.Sun.COM [129.150.116.130]) by gadget-mail1.uk.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0J1900AYWLI2KV@gadget-mail1.uk.sun.com> for gtk-devel-list@gnome.org; Thu, 22 Jun 2006 14:58:51 +0100 (BST) Date: Thu, 22 Jun 2006 15:00:03 +0100 From: Bill Haneman Subject: GtkTextBuffer serialization formats: why no "text/plain" ? To: gtk-devel-list@gnome.org Message-id: <1150984802.7100.4.camel@linux.site> MIME-version: 1.0 X-Mailer: Ximian Evolution 1.4.6.338 Content-type: text/plain Content-transfer-encoding: 7BIT X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.538 tagged_above=-999 required=2 tests=[AWL=-0.017, BAYES_00=-2.599, TW_GT=0.077, UNPARSEABLE_RELAY=0.001] X-Spam-Score: -2.538 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 13:59:01 -0000 Hi; The new serialize/deserialize API for GtkTextBuffer looks to be very useful to accessibility among other things. I am currently using it to implement AtkStreamableContent, an interface which allows objects with streamable backing data (for instance images, HTML widgets, text containers...) to advertise that fact and stream the data to remote clients such as assistive technologies. However I am somewhat surprised to see in gtk-demo's Hypertext widget that, although there's a serialization format called "application/x-gtk-rich-text", there's no "text/plain". Of course serialization via plain text would not be lossless, but why isn't there a plain text serialization available for all GtkTextBuffer instances? We certainly need it for the accessibility case - otherwise we'll have to fake one in gail, necessitating multiple code paths or at least some odd concatenation of "text/plain" if it is not among those returned by gtk_text_buffer_get_serialize_formats... regards, Bill From ebassi@gmail.com Thu Jun 22 10:02:56 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id D0CCE3B074F for ; Thu, 22 Jun 2006 10:02:56 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00339-10 for ; Thu, 22 Jun 2006 10:02:55 -0400 (EDT) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.171]) by menubar.gnome.org (Postfix) with ESMTP id CC4073B0634 for ; Thu, 22 Jun 2006 10:02:54 -0400 (EDT) Received: by ug-out-1314.google.com with SMTP id o2so482915uge for ; Thu, 22 Jun 2006 07:02:53 -0700 (PDT) Received: by 10.78.151.3 with SMTP id y3mr507751hud; Thu, 22 Jun 2006 07:02:53 -0700 (PDT) Received: from ?192.168.1.70? ( [86.136.65.180]) by mx.gmail.com with ESMTP id 8sm364730hug.2006.06.22.07.02.53; Thu, 22 Jun 2006 07:02:53 -0700 (PDT) Subject: Re: Looking beyond 2.10 From: Emmanuele Bassi To: gtk-devel-list@gnome.org In-Reply-To: <1150911355.15532.100.camel@golem.boston.redhat.com> References: <1150911355.15532.100.camel@golem.boston.redhat.com> Content-Type: text/plain Date: Thu, 22 Jun 2006 15:02:51 +0100 Message-Id: <1150984971.5346.12.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.362 tagged_above=-999 required=2 tests=[AWL=0.238, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.362 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 14:02:57 -0000 Hi; On Wed, 2006-06-21 at 13:35 -0400, Matthias Clasen wrote: > So, with GTK+ 2.10 on the finish line, I tried to make a quick > list of things we may want to look at for 2.12, as input to > GUADEC discussions. > Stuff that needs more work > > - introspection > - international calendar support - use GBookmarkFile inside GtkFileSystem and add recent files inside GtkFileChooser. > Stuff that we need to figure out > > - canvas > - libsexy cherrypicking ? - EggIconChooser. AFAIR there were issues but I can't find any pointer to those. Also, I'd like to see the thumbnailing code added to GTK, and the thumbnail helpers changed from using GConf to a lower level position in the stack. Ciao, Emmanuele. -- Emmanuele Bassi, E: ebassi@gmail.com W: http://www.emmanuelebassi.net B: http://log.emmanuelebassi.net From kris@babi-pangang.org Thu Jun 22 10:07:12 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 9474E3B07EB for ; Thu, 22 Jun 2006 10:07:12 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00887-04 for ; Thu, 22 Jun 2006 10:07:09 -0400 (EDT) Received: from nasi-goreng.babi-pangang.org (nasi-goreng.babi-pangang.org [83.166.137.20]) by menubar.gnome.org (Postfix) with ESMTP id ECDDC3B07F0 for ; Thu, 22 Jun 2006 10:07:08 -0400 (EDT) Received: by nasi-goreng.babi-pangang.org (Postfix, from userid 1000) id 5DB383DCA0; Thu, 22 Jun 2006 16:07:04 +0200 (CEST) Date: Thu, 22 Jun 2006 16:07:04 +0200 From: Kristian Rietveld To: Matthias Clasen Subject: Re: Looking beyond 2.10 Message-ID: <20060622140703.GA15275@babi-pangang.org> References: <1150911355.15532.100.camel@golem.boston.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1150911355.15532.100.camel@golem.boston.redhat.com> User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.565 tagged_above=-999 required=2 tests=[AWL=0.034, BAYES_00=-2.599] X-Spam-Score: -2.565 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 14:07:12 -0000 On Wed, Jun 21, 2006 at 01:35:55PM -0400, Matthias Clasen wrote: > Stuff that needs more work > > - introspection > - international calendar support (I want to try to do multiple row DnD in GtkTreeView for real now. But I won't promise anything :) -kris. From jnoreiko@yahoo.com Thu Jun 22 10:28:15 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id CEBD43B0110 for ; Thu, 22 Jun 2006 10:28:15 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01906-05 for ; Thu, 22 Jun 2006 10:28:15 -0400 (EDT) Received: from web32406.mail.mud.yahoo.com (web32406.mail.mud.yahoo.com [68.142.207.199]) by menubar.gnome.org (Postfix) with SMTP id DCE8B3B0251 for ; Thu, 22 Jun 2006 10:28:14 -0400 (EDT) Received: (qmail 59923 invoked by uid 60001); 22 Jun 2006 14:28:14 -0000 Message-ID: <20060622142814.59921.qmail@web32406.mail.mud.yahoo.com> Received: from [172.203.129.193] by web32406.mail.mud.yahoo.com via HTTP; Thu, 22 Jun 2006 15:28:14 BST Date: Thu, 22 Jun 2006 15:28:14 +0100 (BST) From: Joachim Noreiko Subject: Re: Looking beyond 2.10 To: gtk-devel-list@gnome.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-0.405 tagged_above=-999 required=2 tests=[AWL=-1.612, BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2, DNS_FROM_RFC_WHOIS=1.447, RCVD_IN_SORBS_SOCKS=2.159] X-Spam-Score: -0.405 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 14:28:16 -0000 > Date: Wed, 21 Jun 2006 13:35:55 -0400 > From: Matthias Clasen > Subject: Looking beyond 2.10 > So, with GTK+ 2.10 on the finish line, I tried to > make a quick > list of things we may want to look at for 2.12, as > input to > GUADEC discussions. > > (Of course, bugzilla has an endless supply of > feature requests > and bugs that one can work on, these are just the > things that > came to my mind first) > I feel like I'm talking to myself here, but please could someone look at adding a help button to the fileselector. ___________________________________________________________ Inbox full of spam? Get leading spam protection and 1GB storage with All New Yahoo! Mail. http://uk.docs.yahoo.com/nowyoucan.html From tristan.van.berkom@gmail.com Thu Jun 22 13:10:30 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id A0DBC3B0690 for ; Thu, 22 Jun 2006 13:10:30 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12156-06 for ; Thu, 22 Jun 2006 13:10:28 -0400 (EDT) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.225]) by menubar.gnome.org (Postfix) with ESMTP id 215163B0137 for ; Thu, 22 Jun 2006 13:10:28 -0400 (EDT) Received: by wr-out-0506.google.com with SMTP id i12so437125wra for ; Thu, 22 Jun 2006 10:10:27 -0700 (PDT) Received: by 10.54.153.18 with SMTP id a18mr2404093wre; Thu, 22 Jun 2006 10:10:27 -0700 (PDT) Received: from ?66.48.170.242? ( [66.48.170.242]) by mx.gmail.com with ESMTP id 7sm1704382wrl.2006.06.22.10.10.22; Thu, 22 Jun 2006 10:10:27 -0700 (PDT) Message-ID: <449AD300.3030809@gnome.org> Date: Thu, 22 Jun 2006 13:27:28 -0400 User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mclasen@redhat.com Subject: Re: Looking beyond 2.10 References: <1150911355.15532.100.camel@golem.boston.redhat.com> <1150984971.5346.12.camel@localhost> In-Reply-To: <1150984971.5346.12.camel@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit From: Tristan Van Berkom X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.216 tagged_above=-999 required=2 tests=[AWL=0.384, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.216 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 17:10:30 -0000 Emmanuele Bassi wrote: >Hi; > >On Wed, 2006-06-21 at 13:35 -0400, Matthias Clasen wrote: > > >>So, with GTK+ 2.10 on the finish line, I tried to make a quick >>list of things we may want to look at for 2.12, as input to >>GUADEC discussions. >> >> Heh, unfortunately I wont be at GAUDEC to discuss any of this (which I am sure would be a great experience), so I'll do my best from the mailing lists and irc to tag along :) In light of the new Gtk Builder code getting in, I would like to propose that we depricate UIManager completely in favour of the Gtk Builder and provide a unified front for the creation of GObjects parsed from ui descriptions (or whatever the new "glade file" is to be called). My proposals to address issues of UI merging and handling of GtkActions are described in detail in these to emails: http://mail.gnome.org/archives/gtk-devel-list/2006-May/msg00157.html http://mail.gnome.org/archives/gtk-devel-list/2006-May/msg00166.html Please let me know your thoughts on the proposition and design, if accepted; I am sure I can get all this "ui merging/action subscription" stuff working properly inside of one month... hopefully leaving time enough for it to mature before 2.12. Cheers, -Tristan From sven@gimp.org Thu Jun 22 14:23:14 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C09883B062A for ; Thu, 22 Jun 2006 14:23:14 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16777-05 for ; Thu, 22 Jun 2006 14:23:11 -0400 (EDT) Received: from buzzloop.caiaq.de (buzzloop.caiaq.de [212.112.241.133]) by menubar.gnome.org (Postfix) with ESMTP id 26D1A3B05BF for ; Thu, 22 Jun 2006 14:23:08 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by buzzloop.caiaq.de (Postfix) with ESMTP id 194427F402E; Thu, 22 Jun 2006 20:23:10 +0200 (CEST) Received: from buzzloop.caiaq.de ([127.0.0.1]) by localhost (buzzloop [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11007-03; Thu, 22 Jun 2006 20:23:09 +0200 (CEST) Received: from [192.168.3.158] (i577B6734.versanet.de [87.123.103.52]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by buzzloop.caiaq.de (Postfix) with ESMTP id A11AD7F4024; Thu, 22 Jun 2006 20:23:09 +0200 (CEST) Subject: Re: Looking beyond 2.10 From: Sven Neumann To: Joachim Noreiko In-Reply-To: <20060622142814.59921.qmail@web32406.mail.mud.yahoo.com> References: <20060622142814.59921.qmail@web32406.mail.mud.yahoo.com> Content-Type: text/plain Date: Thu, 22 Jun 2006 20:22:49 +0200 Message-Id: <1151000569.12681.22.camel@bender> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.692 tagged_above=-999 required=2 tests=[AWL=0.907, BAYES_00=-2.599] X-Spam-Score: -1.692 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 18:23:15 -0000 Hi, On Thu, 2006-06-22 at 15:28 +0100, Joachim Noreiko wrote: > I feel like I'm talking to myself here, but please > could someone look at adding a help button to the fileselector. GIMP has done that for quite a while already, so there's nothing that would keep an application from adding a Help button to the file-chooser. What's the point of adding one by default? By default it won't be connected to anything useful and what good is a help button that does nothing when the user clicks it? Sven From murrayc@murrayc.com Thu Jun 22 14:45:17 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 2C2CB3B0649 for ; Thu, 22 Jun 2006 14:45:17 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18110-06 for ; Thu, 22 Jun 2006 14:45:13 -0400 (EDT) Received: from swarthymail-a1.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by menubar.gnome.org (Postfix) with ESMTP id A79253B083A for ; Thu, 22 Jun 2006 14:45:12 -0400 (EDT) Received: from noname (p5497EA12.dip.t-dialin.net [84.151.234.18]) by swarthymail-a1.dreamhost.com (Postfix) with ESMTP id 71BF690FA6; Thu, 22 Jun 2006 11:45:00 -0700 (PDT) Subject: Re: GTK+ 2.10, the endgame From: Murray Cumming To: Emmanuele Bassi In-Reply-To: <1150502750.2668.12.camel@localhost> References: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> <1150390229.17566.191.camel@cacharro.xalalinux.org> <1150391737.3187.33.camel@dhcp83-98.boston.redhat.com> <1150447930.5806.4.camel@localhost.localdomain> <1150502750.2668.12.camel@localhost> Content-Type: text/plain Date: Thu, 22 Jun 2006 20:44:54 +0200 Message-Id: <1151001894.5804.33.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.477 tagged_above=-999 required=2 tests=[AWL=0.122, BAYES_00=-2.599] X-Spam-Score: -2.477 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 18:45:17 -0000 On Sat, 2006-06-17 at 01:05 +0100, Emmanuele Bassi wrote: > Hi Murray, > > On Fri, 2006-06-16 at 10:52 +0200, Murray Cumming wrote: > > I'm also concerned about the recent files stuff. Do we now have > > UIManager integration of that? > > No, and I am to blame because I had less time to spend on fixing this > issue. > > Mostly, I've been stuck on how to implement an action for both the menu > and toolbars using the same tag. In the meantime, a nice and clean way > to integrate the GtkRecentChooserMenu inside a GtkUIManager is to > subclass GtkAction into a custom action that automatically adds a recent > chooser menu to the menu item it creates, and use a placeholder in the > UI definition (most applications using EggRecentViewUIManager already > have that placeholder present). > > A working example is available here: > > http://www.gnome.org/~ebassi/test-uimanager.c > > The action code itself is one hundred lines long and can easily be > hidden inside an helper file; it's approximately how GtkRecentAction > would be implemented, anyway. I hereby give permission to do whatever > you want to do with it. > > I understand that it's sub-optimal, and hopefully this should really go > away once there's an action inside GTK. Do you feel that the existing API might need to be changed to add this to a future version of GTK+? For instance, would it need need existing classes to implement new interfaces, or add new signals? -- Murray Cumming murrayc@murrayc.com www.murrayc.com www.openismus.com From ebassi@gmail.com Thu Jun 22 15:19:39 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id F26233B077F for ; Thu, 22 Jun 2006 15:19:38 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20426-04 for ; Thu, 22 Jun 2006 15:19:35 -0400 (EDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.186]) by menubar.gnome.org (Postfix) with ESMTP id 2A7653B062A for ; Thu, 22 Jun 2006 15:19:35 -0400 (EDT) Received: by nf-out-0910.google.com with SMTP id h2so304101nfe for ; Thu, 22 Jun 2006 12:19:34 -0700 (PDT) Received: by 10.48.242.3 with SMTP id p3mr1697803nfh; Thu, 22 Jun 2006 12:19:34 -0700 (PDT) Received: from ?192.168.1.70? ( [86.136.65.180]) by mx.gmail.com with ESMTP id z73sm2097413nfb.2006.06.22.12.19.33; Thu, 22 Jun 2006 12:19:33 -0700 (PDT) Subject: Re: GTK+ 2.10, the endgame From: Emmanuele Bassi To: Murray Cumming In-Reply-To: <1151001894.5804.33.camel@localhost.localdomain> References: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> <1150390229.17566.191.camel@cacharro.xalalinux.org> <1150391737.3187.33.camel@dhcp83-98.boston.redhat.com> <1150447930.5806.4.camel@localhost.localdomain> <1150502750.2668.12.camel@localhost> <1151001894.5804.33.camel@localhost.localdomain> Content-Type: text/plain Date: Thu, 22 Jun 2006 20:19:32 +0100 Message-Id: <1151003972.5346.29.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.371 tagged_above=-999 required=2 tests=[AWL=0.229, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.371 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 19:19:39 -0000 Hi Murray; On Thu, 2006-06-22 at 20:44 +0200, Murray Cumming wrote: > > The action code itself is one hundred lines long and can easily be > > hidden inside an helper file; it's approximately how GtkRecentAction > > would be implemented, anyway. I hereby give permission to do whatever > > you want to do with it. > > > > I understand that it's sub-optimal, and hopefully this should really go > > away once there's an action inside GTK. > > Do you feel that the existing API might need to be changed to add this > to a future version of GTK+? For instance, would it need need existing > classes to implement new interfaces, or add new signals? The point is: I don't know. :-) The currently unresolved issue is that I can't find a way to use this UI definition:

which is the "right" way to offer a submenu and a menu inside a toolbar item. The only case where I know for sure would require adding API is the case where you want an inlined recent files list - as it would require the ability to create a list of menu items instead of a single widget with the same GtkAction. At this point, I'd like a UIManager author/guru to step in and see if I'm doing something wrong. The bug is #338843 [1]. +++ http://bugzilla.gnome.org/show_bug.cgi?id=338843 -- Emmanuele Bassi, E: ebassi@gmail.com W: http://www.emmanuelebassi.net B: http://log.emmanuelebassi.net From jnoreiko@yahoo.com Thu Jun 22 17:19:57 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 48DC33B07DC for ; Thu, 22 Jun 2006 17:19:57 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27254-05 for ; Thu, 22 Jun 2006 17:19:56 -0400 (EDT) Received: from web32404.mail.mud.yahoo.com (web32404.mail.mud.yahoo.com [68.142.207.197]) by menubar.gnome.org (Postfix) with SMTP id 6C40C3B0601 for ; Thu, 22 Jun 2006 17:19:56 -0400 (EDT) Received: (qmail 9697 invoked by uid 60001); 22 Jun 2006 21:19:55 -0000 Message-ID: <20060622211955.9695.qmail@web32404.mail.mud.yahoo.com> Received: from [172.216.98.138] by web32404.mail.mud.yahoo.com via HTTP; Thu, 22 Jun 2006 22:19:55 BST Date: Thu, 22 Jun 2006 22:19:55 +0100 (BST) From: Joachim Noreiko Subject: Re: Looking beyond 2.10 To: Sven Neumann In-Reply-To: <1151000569.12681.22.camel@bender> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.693 tagged_above=-999 required=2 tests=[AWL=-0.741, BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2, DNS_FROM_RFC_WHOIS=1.447] X-Spam-Score: -1.693 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 21:19:57 -0000 --- Sven Neumann wrote: > Hi, > > On Thu, 2006-06-22 at 15:28 +0100, Joachim Noreiko > wrote: > > > I feel like I'm talking to myself here, but please > > could someone look at adding a help button to the > fileselector. > > GIMP has done that for quite a while already, so > there's nothing that > would keep an application from adding a Help button > to the file-chooser. > What's the point of adding one by default? By > default it won't be > connected to anything useful and what good is a help > button that does > nothing when the user clicks it? The documentation for the fileselector has been in the GNOME Desktop User Guide since 2.14. I'm sure I posted on this list when I wrote it. ___________________________________________________________ All new Yahoo! Mail "The new Interface is stunning in its simplicity and ease of use." - PC Magazine http://uk.docs.yahoo.com/nowyoucan.html From scott@asofyet.org Thu Jun 22 22:52:08 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 046A73B05F9 for ; Thu, 22 Jun 2006 22:52:08 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09189-02 for ; Thu, 22 Jun 2006 22:52:06 -0400 (EDT) Received: from looneymail-a2.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by menubar.gnome.org (Postfix) with ESMTP id 39B703B071C for ; Thu, 22 Jun 2006 22:52:06 -0400 (EDT) Received: from [192.168.0.100] (unknown [74.131.115.107]) by looneymail-a2.dreamhost.com (Postfix) with ESMTP id 2C0F016E8CD for ; Thu, 22 Jun 2006 19:52:05 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v750) In-Reply-To: <20060622211955.9695.qmail@web32404.mail.mud.yahoo.com> References: <20060622211955.9695.qmail@web32404.mail.mud.yahoo.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: muppet Subject: Re: Looking beyond 2.10 Date: Thu, 22 Jun 2006 22:51:48 -0400 To: GTK+ development mailing list X-Mailer: Apple Mail (2.750) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.558 tagged_above=-999 required=2 tests=[AWL=0.041, BAYES_00=-2.599] X-Spam-Score: -2.558 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2006 02:52:08 -0000 On Jun 22, 2006, at 5:19 PM, Joachim Noreiko wrote: > > --- Sven Neumann wrote: > >> GIMP has done that for quite a while already, so there's nothing >> that would keep an application from adding a Help button to the >> file-chooser. What's the point of adding one by default? By >> default it won't be connected to anything useful and what good is >> a help button that does nothing when the user clicks it? > > The documentation for the fileselector has been in the GNOME > Desktop User Guide since 2.14. I'm sure I posted on this list when > I wrote it. That doesn't do much good for gtk+ environments that don't involve GNOME. -- Jolt is my co-pilot. -- Slogan on a giant paper airplane hung in Lobby 7 at MIT. http://hacks.mit.edu/ From magnusbe@algonet.se Fri Jun 23 05:33:19 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 0D0353B0591 for ; Fri, 23 Jun 2006 05:33:19 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31880-05 for ; Fri, 23 Jun 2006 05:33:17 -0400 (EDT) Received: from pne-smtpout2-sn2.hy.skanova.net (pne-smtpout2-sn2.hy.skanova.net [81.228.8.164]) by menubar.gnome.org (Postfix) with ESMTP id 294473B041F for ; Fri, 23 Jun 2006 05:33:16 -0400 (EDT) Received: from feathers (83.252.145.175) by pne-smtpout2-sn2.hy.skanova.net (7.2.072.1) (authenticated as u73906364) id 449A811D0002C366 for gtk-devel-list@gnome.org; Fri, 23 Jun 2006 11:33:15 +0200 Date: Fri, 23 Jun 2006 12:31:05 +0200 From: Magnus Bergman To: GTK+ devel list Subject: Problems making loaders for header-less images Message-ID: <20060623123105.1589fed8@feathers> X-Mailer: Sylpheed-Claws 2.3.0 (GTK+ 2.8.16; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.522 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, TW_GD=0.077] X-Spam-Score: -2.522 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2006 09:33:19 -0000 I've made a couple of gdk-pixbuf loaders for formats that cannot be finger printed using a pattern, because they totaly lack some kind of header or that information is located at the end of the file. This has causes me the following problems: * If one loader handles several (similar) formats that cannot be distinguished from each other by looking at the first bytes. Then gdk-pixbuf uses other means to distinguish between them (extension or mime-type) but the information about what the match was based on is unavailable to loader (or am I missing something). Can this be solved is some way (except by making a different loader for each variant)? Example: There is an image format called pi1 (the most common format on the Atari ST). It consists of one word telling about the resolution, the palette and a copy of the screen memory. A variant of the format is called pc1 and has the only difference that the screen memory image is compressed. It is easy to distinguish between them using the extension or by looking at the file size (pi1 has a fixed size of 32066 bytes while pc1 is always smaller). * If a loader doesn't provide any fingerprinting pattern gdk-pixbuf causes a segfault at runtime then trying to load a picture in any format. Is the loader required to provide at least one pattern or is this a bug? * If the only thing that is known about the format is that it starts with one or more zeros, then gdk-pixbuf-query-loaders will refuse to register the loader because it considers the pattern to be empty. This could be avoided to checking the length of the mask field instead to the prefix field. A bug? From gcottenc@gmail.com Fri Jun 23 07:57:54 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id DA1E43B0678 for ; Fri, 23 Jun 2006 07:57:54 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08025-10 for ; Fri, 23 Jun 2006 07:57:53 -0400 (EDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.192]) by menubar.gnome.org (Postfix) with ESMTP id 7D8543B01A4 for ; Fri, 23 Jun 2006 07:57:53 -0400 (EDT) Received: by wx-out-0102.google.com with SMTP id s6so466104wxc for ; Fri, 23 Jun 2006 04:57:53 -0700 (PDT) Received: by 10.70.103.17 with SMTP id a17mr4494204wxc; Fri, 23 Jun 2006 04:57:52 -0700 (PDT) Received: by 10.70.46.6 with HTTP; Fri, 23 Jun 2006 04:57:52 -0700 (PDT) Message-ID: Date: Fri, 23 Jun 2006 13:57:52 +0200 From: "Guillaume Cottenceau" To: "Matthias Clasen" Subject: Re: Fwd: GTK+ 2.10, the endgame In-Reply-To: <1150895599.15532.80.camel@golem.boston.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> <1150895599.15532.80.camel@golem.boston.redhat.com> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.564 tagged_above=-999 required=2 tests=[AWL=0.036, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.564 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2006 11:57:55 -0000 Hi Matthias, > The online documentation is still at 2.9.2. I hope to find time > to update it to 2.9.4 before leaving for GUADEC tomorrow. Please warn us when the online API documentation regarding new symbols is fully freezed for 2.10 so that we can start working on adding the new symbols in bindings. Thanks! -- Guillaume Cottenceau - http://zarb.org/~gc/ From hfiguiere@teaser.fr Fri Jun 23 11:50:42 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 100083B04A7 for ; Fri, 23 Jun 2006 11:50:42 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21632-05 for ; Fri, 23 Jun 2006 11:50:39 -0400 (EDT) Received: from xandros.com (smtp1.xandros.com [209.87.238.70]) by menubar.gnome.org (Postfix) with ESMTP id 83AC63B0907 for ; Fri, 23 Jun 2006 11:50:33 -0400 (EDT) Received: from [172.16.1.95] (unknown [209.87.238.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by xandros.com (Postfix) with ESMTP id 6A6F223033 for ; Fri, 23 Jun 2006 11:50:32 -0400 (EDT) Message-ID: <449C0DC7.60502@teaser.fr> Date: Fri, 23 Jun 2006 11:50:31 -0400 From: Hubert Figuiere User-Agent: Thunderbird 1.5.0.4 (X11/20060615) MIME-Version: 1.0 To: gtk-devel-list@gnome.org Subject: Re: Looking beyond 2.10 References: <20060622142814.59921.qmail@web32406.mail.mud.yahoo.com> <1151000569.12681.22.camel@bender> In-Reply-To: <1151000569.12681.22.camel@bender> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.544 tagged_above=-999 required=2 tests=[AWL=0.055, BAYES_00=-2.599] X-Spam-Score: -2.544 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2006 15:50:42 -0000 Sven Neumann wrote: > GIMP has done that for quite a while already, so there's nothing that > would keep an application from adding a Help button to the file-chooser. > What's the point of adding one by default? By default it won't be > connected to anything useful and what good is a help button that does > nothing when the user clicks it? Why not putting it in only if the signal is connected ? (a signal like "help_requested"). Hub From gjc@inescporto.pt Fri Jun 23 18:23:20 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 9B8D83B0847 for ; Fri, 23 Jun 2006 18:23:20 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08741-04 for ; Fri, 23 Jun 2006 18:23:19 -0400 (EDT) Received: from animal.inescn.pt (animal.inescn.pt [194.117.24.9]) by menubar.gnome.org (Postfix) with ESMTP id AC38C3B0971 for ; Fri, 23 Jun 2006 18:23:18 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by animal.inescn.pt (8.13.6/8.13.6/7) with ESMTP id k5NMNG4Z018417; Fri, 23 Jun 2006 23:23:17 +0100 (WEST) Received: from pong.inescporto.pt (pong.inescn.pt [194.117.26.74]) by animal.inescn.pt (8.13.6/8.13.6/5) with ESMTP id k5NMN5ql018402; Fri, 23 Jun 2006 23:23:05 +0100 (WEST) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by pong.inescporto.pt (Postfix) with ESMTP id 31501155721; Fri, 23 Jun 2006 23:19:37 +0100 (WEST) Subject: Re: Looking beyond 2.10 From: "Gustavo J. A. M. Carneiro" To: Matthias Clasen In-Reply-To: <1150911355.15532.100.camel@golem.boston.redhat.com> References: <1150911355.15532.100.camel@golem.boston.redhat.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-2prtuoBhNnmmz3lcPkNU" Date: Fri, 23 Jun 2006 23:22:59 +0100 Message-Id: <1151101379.5189.5.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 X-Virus-Scanned: by amavisd-new at inescporto.pt X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.428 tagged_above=-999 required=2 tests=[AWL=0.038, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] X-Spam-Score: -2.428 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2006 22:23:20 -0000 --=-2prtuoBhNnmmz3lcPkNU Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Qua, 2006-06-21 =C3=A0s 13:35 -0400, Matthias Clasen escreveu: > So, with GTK+ 2.10 on the finish line, I tried to make a quick > list of things we may want to look at for 2.12, as input to > GUADEC discussions. >=20 > Patches almost ready to go in >=20 > - libglade integration > - new tooltips api >=20 >=20 > Stuff that needs more work >=20 > - introspection I'm willing to do some work in introspection. However, if you say it needs more work then I think you should identify precisely what work needs to be done. I could try guessing, but that usually leads to patches sitting in bugzilla for whole release cycles (e.g. #313268). Regards. --=20 Gustavo J. A. M. Carneiro The universe is always one step beyond logic --=-2prtuoBhNnmmz3lcPkNU Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta =?ISO-8859-1?Q?=E9?= uma parte de mensagem assinada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQBEnGnD2XoHyMdS6TARAk0JAJ95rFWntIs1xJ0hPTYMBwXdg26PgACeJo0x DrkoftT0jbf/hSym/poi0Uo= =WVRK -----END PGP SIGNATURE----- --=-2prtuoBhNnmmz3lcPkNU-- From jnoreiko@yahoo.com Sat Jun 24 03:40:19 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id EBA9B3B00F5 for ; Sat, 24 Jun 2006 03:40:18 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30651-07 for ; Sat, 24 Jun 2006 03:40:17 -0400 (EDT) Received: from web32401.mail.mud.yahoo.com (web32401.mail.mud.yahoo.com [68.142.207.194]) by menubar.gnome.org (Postfix) with SMTP id BD1E03B0194 for ; Sat, 24 Jun 2006 03:40:16 -0400 (EDT) Received: (qmail 229 invoked by uid 60001); 24 Jun 2006 07:40:15 -0000 Message-ID: <20060624074015.227.qmail@web32401.mail.mud.yahoo.com> Received: from [172.212.40.3] by web32401.mail.mud.yahoo.com via HTTP; Sat, 24 Jun 2006 08:40:15 BST Date: Sat, 24 Jun 2006 08:40:15 +0100 (BST) From: Joachim Noreiko Subject: Re: Looking beyond 2.10 To: gtk-devel-list@gnome.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.681 tagged_above=-999 required=2 tests=[AWL=-0.729, BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2, DNS_FROM_RFC_WHOIS=1.447] X-Spam-Score: -1.681 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2006 07:40:19 -0000 Message: 6 Date: Thu, 22 Jun 2006 22:51:48 -0400 From: muppet Subject: Re: Looking beyond 2.10 > The documentation for the fileselector has been in the GNOME > Desktop User Guide since 2.14. I'm sure I posted on this list when > I wrote it. That doesn't do much good for gtk+ environments that don't involve GNOME. -------------- Then figure out some way for it to detect whether it's on GNOME or not, maybe? Dialog boxes used in GNOME required help buttons, especially ones with as many features as the fileselector. Please could somebody look into this? I put a lot of work into writing the docs, and that's not a huge amount of use until it's linked to. ___________________________________________________________ Inbox full of spam? Get leading spam protection and 1GB storage with All New Yahoo! Mail. http://uk.docs.yahoo.com/nowyoucan.html From macfreesoft@free.fr Sat Jun 24 05:56:35 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C31133B02D5 for ; Sat, 24 Jun 2006 05:56:35 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05338-06 for ; Sat, 24 Jun 2006 05:56:33 -0400 (EDT) Received: from smtp010.mail.ukl.yahoo.com (smtp010.mail.ukl.yahoo.com [217.12.11.79]) by menubar.gnome.org (Postfix) with SMTP id 3D48E3B02B2 for ; Sat, 24 Jun 2006 05:56:33 -0400 (EDT) Received: (qmail 6982 invoked from network); 24 Jun 2006 09:56:32 -0000 Received: from unknown (HELO ?192.168.1.10?) (a?gillaizeau@217.66.126.141 with plain) by smtp010.mail.ukl.yahoo.com with SMTP; 24 Jun 2006 09:56:32 -0000 Message-ID: <449D0C4E.504@free.fr> Date: Sat, 24 Jun 2006 11:56:30 +0200 From: Aymeric GILLAIZEAU User-Agent: Thunderbird 1.5 (Macintosh/20051201) MIME-Version: 1.0 To: Easy B Subject: Gtk+.framework snapshot Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.033 tagged_above=-999 required=2 tests=[BAYES_05=-1.11, TW_GT=0.077] X-Spam-Score: -1.033 X-Spam-Level: X-Mailman-Approved-At: Sat, 24 Jun 2006 06:24:14 -0400 Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2006 09:56:36 -0000 > Hi guys > > Well I wasn't that happy with the result I got from the mono scripts > so I pretty much rewrote them. I now install everything into one > framework. I still don't have libtiff and jpeg support though. How is > the best way to make the gtk configure look for libtiff 3.8.2? I saw > that it looks for 3.4. Do I have to patch configure? > > Anyway, who's interested can give my installer a try. It installs the > framework into /Library/Frameworks and Gtk-Demo into /Applications. I > managed to compile one of my small apps by setting PKG_CONFIG_PATH to > /Library/Frameworks/Gtk+.framework/Libraries/pkgconfig/ and > ./configure, make. > > To make an application bundles I use this script: > http://www.easyb.ch/files/bundleApp.sh > > The Installer you can download here: > http://www.easyb.ch/files/Gtk%2B-2.9.1%20Framework%20snapshot.pkg.zip > > Cheers, > Ezra. Why to not use the already built Frameworks used by Scribus ? Instead of having many times the same things, it is present once and used by anyone. The problem with OpenSource is that everyone makes his cooking in his place without never taking consideration in the work others has already done. It could save time, also use less space on the drive, and so save room. http://www.scribus.net/index.php?name=Sections&req=viewarticle&artid=3&page=1 > ome support libraries, which should be moved to /Library/Frameworks : > Qt.framework > Freetype.framework > Fontconfig2.framework > libart.framework > libexpat.framework > libjpeg.framework > liblcms.framework > libpng.framework > libtiff.framework ___________________________________________________________________________ Yahoo! Mail rinvente le mail ! Dcouvrez le nouveau Yahoo! Mail et son interface rvolutionnaire. http://fr.mail.yahoo.com From alex@halogen-dg.com Sat Jun 24 08:41:32 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 92B9B3B013A for ; Sat, 24 Jun 2006 08:41:32 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13862-09 for ; Sat, 24 Jun 2006 08:41:31 -0400 (EDT) Received: from appserver.halogen.kharkov.ua (appserver.halogen.kharkov.ua [217.144.70.65]) by menubar.gnome.org (Postfix) with ESMTP id 256C33B00FB for ; Sat, 24 Jun 2006 08:41:31 -0400 (EDT) Received: (qmail 29949 invoked from network); 24 Jun 2006 15:41:32 +0300 Received: from dom.koval.kharkov.ua (217.144.70.182) by alex.halogen.kharkov.ua with AES256-SHA encrypted SMTP; 24 Jun 2006 15:41:32 +0300 Date: Sat, 24 Jun 2006 15:45:30 +0300 (EEST) From: alex@halogen-dg.com X-X-Sender: alex@dom.koval.kharkov.ua To: gtk-devel-list@gnome.org Subject: gtk file open dialog usability. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-0.858 tagged_above=-999 required=2 tests=[AWL=-0.709, BAYES_05=-1.11, NO_REAL_NAME=0.961] X-Spam-Score: -0.858 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2006 12:41:32 -0000 Anyone except me also disappointed by it? Any way how we can have old file open dialog back? I really find it very frustating and explained why, with some images here: http://www.halogen-dg.com/alex/file_selection_dialog/GtkFileOpenBadUsability -- Alex V. Koval http://www.halogen-dg.com/ http://www.zwarehouse.org/ From gnome-gtk-devel-list@m.gmane.org Sat Jun 24 08:49:58 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id F15263B00A8 for ; Sat, 24 Jun 2006 08:49:57 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14302-05 for ; Sat, 24 Jun 2006 08:49:55 -0400 (EDT) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by menubar.gnome.org (Postfix) with ESMTP id 402703B00FB for ; Sat, 24 Jun 2006 08:49:55 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Fu7a8-0004yS-Mc for gtk-devel-list@gnome.org; Sat, 24 Jun 2006 14:49:48 +0200 Received: from 84.52.165.220 ([84.52.165.220]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 24 Jun 2006 14:49:48 +0200 Received: from jernej.listsonly by 84.52.165.220 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 24 Jun 2006 14:49:48 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gtk-devel-list@gnome.org From: Jernej =?utf-7?Q?Simon+AQ0-i+AQ0-?= Subject: Re: gtk file open dialog usability. Date: Sat, 24 Jun 2006 14:49:37 +0200 Lines: 9 Message-ID: <10umqokepyu8y.10vhe4alqj04.dlg@40tude.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset="utf-7" Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 84.52.165.220 User-Agent: 40tude_Dialog/2.0.15.84 (cfc06cd9.460.419) X-Face: BOCQpf4)pfW>6Ya?'@oBT]=LBF; <6`_r[6pwqLggP!RG:*D)^Fz; O(I'n(FwJ{]5lo>g.H. _,Z:_`nLsfz]]8V'&9OmX)o-bXd?(P|CO=@5}[y\0rH9!AN&Qt:GXC(r!1}$q@@C]x`](7+#C]WRzw L|0W}vdFR/b@AFWIw~ X-Ultimate-Answer: 42 Sender: news X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.008 tagged_above=-999 required=2 tests=[AWL=0.016, BAYES_00=-2.599, FROM_EXCESS_QP=0, RCVD_NUMERIC_HELO=1.5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, TW_GT=0.077] X-Spam-Score: -1.008 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2006 12:49:58 -0000 On Sat, 24 Jun 2006 15:45:30 +-0300 (EEST), alex@halogen-dg.com wrote: > Anyone except me also disappointed by it? Search the archives, you're far from being the only one. -- < Jernej Simon+AQ0-i+AQ0- >< http://deepthought.ena.si/ > < Contact address: >< jernej simoncic at isg si > From alex@halogen-dg.com Sat Jun 24 09:01:55 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id F3A283B00A8 for ; Sat, 24 Jun 2006 09:01:54 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15013-06 for ; Sat, 24 Jun 2006 09:01:54 -0400 (EDT) Received: from appserver.halogen.kharkov.ua (appserver.halogen.kharkov.ua [217.144.70.65]) by menubar.gnome.org (Postfix) with ESMTP id 388713B0490 for ; Sat, 24 Jun 2006 09:01:53 -0400 (EDT) Received: (qmail 32296 invoked from network); 24 Jun 2006 16:01:54 +0300 Received: from dom.koval.kharkov.ua (217.144.70.182) by alex.halogen.kharkov.ua with AES256-SHA encrypted SMTP; 24 Jun 2006 16:01:54 +0300 Date: Sat, 24 Jun 2006 16:05:52 +0300 (EEST) From: alex@halogen-dg.com X-X-Sender: alex@dom.koval.kharkov.ua To: gtk-devel-list@gnome.org Subject: Re: gtk file open dialog usability. In-Reply-To: <10umqokepyu8y.10vhe4alqj04.dlg@40tude.net> Message-ID: References: <10umqokepyu8y.10vhe4alqj04.dlg@40tude.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.533 tagged_above=-999 required=2 tests=[AWL=0.028, BAYES_00=-2.599, NO_REAL_NAME=0.961, TW_GT=0.077] X-Spam-Score: -1.533 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2006 13:01:55 -0000 Hi Jernej On Sat, 24 Jun 2006, Jernej Simon+AQ0-i+AQ0- wrote: > On Sat, 24 Jun 2006 15:45:30 +-0300 (EEST), alex@halogen-dg.com wrote: > >> Anyone except me also disappointed by it? I am happy that people noticed that, too. The question is what can we do to fix this? My feeling is that at least 2 things could be done: 1. Make automatic selection of file optional (like its being done in KDE, in grey) 2. Do not display additional file open dialog when I *already* typed file name. > > Search the archives, you're far from being the only one. > BTW, before doing this post I've tried to search for "file dialog usability GTK". To my regret mail.gnome.org mailman search is not working ("The requested URL /mailman/search was not found on this server."),so I searched google a little, did not found any good results and posted here... Althrough this search returns more results: http://www.google.com.ua/search?q=gtk+file+open+usability&start=0&ie=utf-8&oe=utf-8&client=firefox-a&rls=org.mozilla:en-US:official Alex From g.tagliaretti@gmail.com Sat Jun 24 09:53:34 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 2C1C83B02E0 for ; Sat, 24 Jun 2006 09:53:34 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17447-04 for ; Sat, 24 Jun 2006 09:53:33 -0400 (EDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.178]) by menubar.gnome.org (Postfix) with ESMTP id 054D13B0228 for ; Sat, 24 Jun 2006 09:53:32 -0400 (EDT) Received: by py-out-1112.google.com with SMTP id i49so1099450pyi for ; Sat, 24 Jun 2006 06:52:59 -0700 (PDT) Received: by 10.35.99.14 with SMTP id b14mr3541165pym; Sat, 24 Jun 2006 06:52:56 -0700 (PDT) Received: by 10.35.132.18 with HTTP; Sat, 24 Jun 2006 06:52:56 -0700 (PDT) Message-ID: <35bf41160606240652s3da0fe6brd3915cd84c601114@mail.gmail.com> Date: Sat, 24 Jun 2006 15:52:56 +0200 From: "Gian Mario Tagliaretti" To: "alex@halogen-dg.com" Subject: Re: gtk file open dialog usability. In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.257 tagged_above=-999 required=2 tests=[AWL=0.066, BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2, SPF_PASS=-0.001, TW_GT=0.077] X-Spam-Score: -2.257 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2006 13:53:34 -0000 2006/6/24, alex@halogen-dg.com : > > Anyone except me also disappointed by it? > Any way how we can have old file open dialog back? code not complain :) > I really find it very frustating and explained > why, with some images here: > http://www.halogen-dg.com/alex/file_selection_dialog/GtkFileOpenBadUsability are you using gtk+ 2.9.x ? ciao -- Gian Mario Tagliaretti http://www.parafernalia.org/pygtk/ http://pygstdocs.berlios.de From timj@gtk.org Sat Jun 24 13:36:49 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 6B4403B006E; Sat, 24 Jun 2006 13:36:49 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27591-06; Sat, 24 Jun 2006 13:36:45 -0400 (EDT) Received: from holken.mikan.net (holken.mikan.net [83.145.56.183]) by menubar.gnome.org (Postfix) with ESMTP id C28AD3B06ED; Sat, 24 Jun 2006 13:36:44 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by holken.mikan.net (Postfix) with ESMTP id 59BF93352A5; Sat, 24 Jun 2006 19:36:26 +0200 (CEST) Received: from holken.mikan.net ([127.0.0.1]) by localhost (holken.mikan.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27952-05; Sat, 24 Jun 2006 19:36:22 +0200 (CEST) Received: from birnet.org (c135173.adsl.hansenet.de [213.39.135.173]) by holken.mikan.net (Postfix) with ESMTP id E12711844A; Sat, 24 Jun 2006 19:36:21 +0200 (CEST) Received: from master.birnet.private (localhost.localdomain [127.0.0.1]) by birnet.org (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k5OHaLjt023300 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 24 Jun 2006 19:36:21 +0200 Received: (from timj@localhost) by master.birnet.private (8.13.4/8.13.4/Submit) id k5OHZcXs023295; Sat, 24 Jun 2006 19:35:38 +0200 Date: Sat, 24 Jun 2006 19:35:38 +0200 (CEST) From: Tim Janik X-X-Sender: timj@master.birnet.private To: Gtk+ Developers Subject: Re: GTK+ meeting at GUADEC (Re: GTK+ 2.10, the endgame) In-Reply-To: Message-ID: References: <1150379787.3187.21.camel@dhcp83-98.boston.redhat.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at holken.mikan.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.637 tagged_above=-999 required=2 tests=[AWL=-0.662, BAYES_05=-1.11, FORGED_RCVD_HELO=0.135] X-Spam-Score: -1.637 X-Spam-Level: X-Mailman-Approved-At: Sat, 24 Jun 2006 13:47:30 -0400 Cc: Federico Mena Quintero , Jonathan Blandford , Tim Janik , sandmann@daimi.au.dk, cworth@cworth.org, Komulainen Tommi , Alex Larsson , Michael Natterer , Kristian Rietveld , Matthias Clasen , Richard Hult , johan@gnome.org, michael meeks X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2006 17:36:49 -0000 On Thu, 15 Jun 2006, Tim Janik wrote: > the plan for that was to send out en email next friday/saturday (i.e > right at the guadec start) to figure/suggest dates suitable for > everyone to attend. we have gotten a room for the Gtk+ meeting now. it's on Sunday the 25th from 16:00-18:00 in the blue room (at the conference facility, second floor). --- ciaoTJ From torriem@chem.byu.edu Sun Jun 25 01:08:26 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id EA0E73B0079 for ; Sun, 25 Jun 2006 01:08:25 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17289-04 for ; Sun, 25 Jun 2006 01:08:22 -0400 (EDT) Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [63.240.77.83]) by menubar.gnome.org (Postfix) with ESMTP id ACB1F3B00A6 for ; Sun, 25 Jun 2006 01:08:22 -0400 (EDT) Received: from enterprise.local.lan (c-24-2-75-5.hsd1.ut.comcast.net[24.2.75.5]) by comcast.net (sccrmhc13) with ESMTP id <2006062505073001300me7qte>; Sun, 25 Jun 2006 05:07:31 +0000 Received: from enterprise.local.lan (enterprise.local.lan [127.0.0.1]) by enterprise.local.lan (8.13.1/8.12.8) with ESMTP id k5P57TFs002388 for ; Sat, 24 Jun 2006 23:07:29 -0600 Received: (from torriem@localhost) by enterprise.local.lan (8.13.1/8.13.1/Submit) id k5P57T1Z002387 for gtk-devel-list@gnome.org; Sat, 24 Jun 2006 23:07:29 -0600 X-Authentication-Warning: enterprise.local.lan: torriem set sender to torriem@chem.byu.edu using -f Subject: Re: Looking beyond 2.10 From: Michael Torrie To: gtk-devel-list@gnome.org In-Reply-To: References: <1150911355.15532.100.camel@golem.boston.redhat.com> <4499982C.1010004@teaser.fr> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Sat, 24 Jun 2006 23:07:29 -0600 Message-Id: <1151212049.32440.11.camel@enterprise.local.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-7) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.377 tagged_above=-999 required=2 tests=[AWL=0.010, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, TW_GT=0.077] X-Spam-Score: -2.377 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jun 2006 05:08:26 -0000 On Wed, 2006-06-21 at 18:26 -0400, Matthias Clasen wrote: > > I'm about to pick Qt as a toolkit for a personal project just because of > > that. > > Good luck. I was in the same boat as Hubert. I also ended up picking Qt. Although I like GTK much better, Qt was the best choice given the circumstances. I have not regretted it. But, as soon as GTK is fully supported on OS X, I will abandon Qt entirely, as GTK is cleaner, a little easier to work with, and, ironically, has better C++ bindings than Qt. > > Matthias > _______________________________________________ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-devel-list > From torriem@chem.byu.edu Sun Jun 25 01:21:50 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 36FD43B01F4 for ; Sun, 25 Jun 2006 01:21:50 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18141-02 for ; Sun, 25 Jun 2006 01:21:47 -0400 (EDT) Received: from sccrmhc14.comcast.net (sccrmhc14.comcast.net [204.127.200.84]) by menubar.gnome.org (Postfix) with ESMTP id DD6353B02BD for ; Sun, 25 Jun 2006 01:21:46 -0400 (EDT) Received: from enterprise.local.lan (c-24-2-75-5.hsd1.ut.comcast.net[24.2.75.5]) by comcast.net (sccrmhc14) with ESMTP id <2006062505211801400apa3je>; Sun, 25 Jun 2006 05:21:19 +0000 Received: from enterprise.local.lan (enterprise.local.lan [127.0.0.1]) by enterprise.local.lan (8.13.1/8.12.8) with ESMTP id k5P5LHWa002930; Sat, 24 Jun 2006 23:21:17 -0600 Received: (from torriem@localhost) by enterprise.local.lan (8.13.1/8.13.1/Submit) id k5P5LH4T002929; Sat, 24 Jun 2006 23:21:17 -0600 X-Authentication-Warning: enterprise.local.lan: torriem set sender to torriem@chem.byu.edu using -f Subject: Re: gtk file open dialog usability. From: Michael Torrie To: Gian Mario Tagliaretti In-Reply-To: <35bf41160606240652s3da0fe6brd3915cd84c601114@mail.gmail.com> References: <35bf41160606240652s3da0fe6brd3915cd84c601114@mail.gmail.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Sat, 24 Jun 2006 23:21:16 -0600 Message-Id: <1151212877.32440.24.camel@enterprise.local.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-7) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.378 tagged_above=-999 required=2 tests=[AWL=0.009, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, TW_GT=0.077] X-Spam-Score: -2.378 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jun 2006 05:21:50 -0000 On Sat, 2006-06-24 at 15:52 +0200, Gian Mario Tagliaretti wrote: > 2006/6/24, alex@halogen-dg.com : > > > > Anyone except me also disappointed by it? > > Any way how we can have old file open dialog back? > > code not complain :) BS. Before anyone can code anything, especially in the framework of GTK, the design has to be worked out. You can't just willy-nilly code up some pseudo-compatible widget. The problem is that every time this is discussed there is never any consensus on what the problems are, why they are problems, and how to fix them. And without this, we cannot convince developers to do anything about the problem. Now having said that, if someone wants to prototype a better widget (one that is API compatible with the current one), maybe that would jump- start the process. Myself, I fear that inertia guarantees we're stuck with this bad design for the duration. > > > I really find it very frustating and explained > > why, with some images here: > > http://www.halogen-dg.com/alex/file_selection_dialog/GtkFileOpenBadUsability > > are you using gtk+ 2.9.x ? > > ciao From dan@entropy.homelinux.org Mon Jun 26 21:13:46 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id D7F733B029A for ; Mon, 26 Jun 2006 21:13:46 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27746-05 for ; Mon, 26 Jun 2006 21:13:44 -0400 (EDT) Received: from screamer.nusconsulting.com.au (mail.nusconsulting.com.au [203.191.186.114]) by menubar.gnome.org (Postfix) with ESMTP id 5E0173B00FE for ; Mon, 26 Jun 2006 21:13:43 -0400 (EDT) Received: from [10.146.1.25] (dkasak.nusconsulting.com.au [10.146.1.25]) by screamer.nusconsulting.com.au (8.13.6/8.13.6) with ESMTP id k5R1FSwU022408 for ; Tue, 27 Jun 2006 11:15:28 +1000 Message-ID: <44A08654.1090208@entropy.homelinux.org> Date: Tue, 27 Jun 2006 11:13:56 +1000 From: Daniel Kasak User-Agent: Thunderbird 1.5.0.2 (X11/20060531) MIME-Version: 1.0 To: gtk-devel-list@gnome.org Subject: Custom Cell Renderers in a TreeView that requires scrolling broken in gtk+-2.8.18 and 2.8.19 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Canit-Stats-ID: 464197 - 7afdf0e072d5 X-Antispam-Training: Train as spam: http://screamer.nusconsulting.com.au/internal/canit/b.php?c=s&i=464197&m=7afdf0e072d5 X-Antispam-Training: Train as non-spam: http://screamer.nusconsulting.com.au/internal/canit/b.php?c=n&i=464197&m=7afdf0e072d5 X-Antispam-Training: Cancel training: http://screamer.nusconsulting.com.au/internal/canit/b.php?c=f&i=464197&m=7afdf0e072d5 X-Scanned-By: CanIt (www . roaringpenguin . com) on 10.146.0.254 X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.564 tagged_above=-999 required=2 tests=[AWL=0.035, BAYES_00=-2.599] X-Spam-Score: -2.564 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2006 01:13:47 -0000 Hi all. I've just noticed a very strange bug in my TreeViews since updating gtk. I have some apps that use a custom cell renderer to provide a pop-up GtkCalender. When I insert a row in the model, the custom cell renderer pops up ( begins editing ) as it's the 1st column. After I select a date and accept changes AND IF THERE ARE MORE ROWS THAN WILL FIT IN THE TREEVIEW WITHOUT SCROLLING, the new row DISAPPEARS from the TreeView. I scroll right from top to bottom - the new row certainly *looks* like it's gone. However if I insert *another* row, my previous missing row appears ( momentarily ) at the bottom again ... until I accept changes from the custom cell renderer on the newest row, and then they both ( or ALL, if I've inserted a number of rows ) disappear. For completeness ( partial anyway - it's a pretty complicated beast, but I can post an entire working example if required - please reply and request this if necessary, but note that it will be in Perl ), I'm pasting the entire CellRendererDate.pm module that provides the custom cell renderer at the bottom, however I note again that everything has worked properly for every version of gtk+ prior to 2.8.18. I initially updated from 2.8.17 to 2.8.19, and then when I found the bug, reverted to 2.8.17 ... tested some more ( no such bug here ), and then updated to 2.8.18 and did some more testing. It definitely arrived in 2.8.18. Has anyone noticed this behaviour with custom cell renderers? I have tested many other TreeViews that *don't* have a custom cell renderer, and have also tried moving the custom cell renderer to another position ( column ). I am almost positive that something is broken with displaying rows with a custom cell renderer when scrolling is required. I would greatly appreciate some help / suggests / confirmations / etc. Dan --- use strict; use Gtk2 -init; package Gtk2::Ex::Datasheet::DBI::CellRendererDate; use Glib::Object::Subclass "Gtk2::CellRenderer", signals => { edited => { flags => [qw(run-last)], param_types => [qw(Glib::String Glib::Scalar)], }, }, properties => [ Glib::ParamSpec -> boolean("editable", "Editable", "Can I change that?", 0, [qw(readable writable)]), Glib::ParamSpec -> string("date", "Date", "What's the date again?", "", [qw(readable writable)]), ] ; use constant x_padding => 2; use constant y_padding => 3; use constant arrow_width => 15; use constant arrow_height => 15; sub hide_popup { my ($cell) = @_; Gtk2 -> grab_remove($cell -> { _popup }); $cell -> { _popup } -> hide(); } sub get_today { my ($cell) = @_; my ($day, $month, $year) = (localtime())[3, 4, 5]; $year += 1900; $month += 1; return ($year, $month, $day); } sub get_date { my ($cell) = @_; my $text = $cell -> get("date"); my ($year, $month, $day) = $text ? split(/[\/-]/, $text) : $cell -> get_today(); return ($year, $month, $day); } sub add_padding { my ($cell, $year, $month, $day) = @_; return ($year, sprintf("%02d", $month), sprintf("%02d", $day)); } sub INIT_INSTANCE { my ($cell) = @_; my $popup = Gtk2::Window -> new ('popup'); my $vbox = Gtk2::VBox -> new(0, 0); my $calendar = Gtk2::Calendar -> new(); my $hbox = Gtk2::HBox -> new(0, 0); my $today = Gtk2::Button -> new('Today'); my $none = Gtk2::Button -> new('None'); $cell -> {_arrow} = Gtk2::Arrow -> new("down", "none"); # We can't just provide the callbacks now because they might need access to # cell-specific variables. And we can't just connect the signals in # START_EDITING because we'd be connecting many signal handlers to the same # widgets. $today -> signal_connect(clicked => sub { $cell -> { _today_clicked_callback } -> (@_) if (exists($cell -> { _today_clicked_callback })); }); $none -> signal_connect(clicked => sub { $cell -> { _none_clicked_callback } -> (@_) if (exists($cell -> { _none_clicked_callback })); }); $calendar -> signal_connect(day_selected_double_click => sub { $cell -> { _day_selected_double_click_callback } -> (@_) if (exists($cell -> { _day_selected_double_click_callback })); }); $calendar -> signal_connect(month_changed => sub { $cell -> { _month_changed } -> (@_) if (exists($cell -> { _month_changed })); }); $hbox -> pack_start($today, 1, 1, 0); $hbox -> pack_start($none, 1, 1, 0); $vbox -> pack_start($calendar, 1, 1, 0); $vbox -> pack_start($hbox, 0, 0, 0); # Find out if the click happended outside of our window. If so, hide it. # Largely copied from Planner (the former MrProject). # Implement via Gtk2::get_event_widget? $popup -> signal_connect(button_press_event => sub { my ($popup, $event) = @_; if ($event -> button() == 1) { my ($x, $y) = ($event -> x_root(), $event -> y_root()); my ($xoffset, $yoffset) = $popup -> window() -> get_root_origin(); my $allocation = $popup -> allocation(); my $x1 = $xoffset + 2 * $allocation -> x(); my $y1 = $yoffset + 2 * $allocation -> y(); my $x2 = $x1 + $allocation -> width(); my $y2 = $y1 + $allocation -> height(); unless ($x > $x1 && $x < $x2 && $y > $y1 && $y < $y2) { $cell -> hide_popup(); return 1; } } return 0; }); $popup -> add($vbox); $cell -> { _popup } = $popup; $cell -> { _calendar } = $calendar; } sub START_EDITING { my ($cell, $event, $view, $path, $background_area, $cell_area, $flags) = @_; my $popup = $cell -> { _popup }; my $calendar = $cell -> { _calendar }; # Specify the callbacks. Will be called by the signal handlers set up in # INIT_INSTANCE. $cell -> { _today_clicked_callback } = sub { my ($button) = @_; my ($year, $month, $day) = $cell -> get_today(); $cell -> signal_emit(edited => $path, join("-", $cell -> add_padding($year, $month, $day))); $cell -> hide_popup(); }; $cell -> { _none_clicked_callback } = sub { my ($button) = @_; $cell -> signal_emit(edited => $path, ""); $cell -> hide_popup(); }; $cell -> { _day_selected_double_click_callback } = sub { my ($calendar) = @_; my ($year, $month, $day) = $calendar -> get_date(); $cell -> signal_emit(edited => $path, join("-", $cell -> add_padding($year, ++$month, $day))); $cell -> hide_popup(); }; $cell -> { _month_changed } = sub { my ($calendar) = @_; my ($selected_year, $selected_month) = $calendar -> get_date(); my ($current_year, $current_month, $current_day) = $cell -> get_today(); if ($selected_year == $current_year && ++$selected_month == $current_month) { $calendar -> mark_day($current_day); } else { $calendar -> unmark_day($current_day); } }; my ($year, $month, $day) = $cell -> get_date(); $calendar -> select_month($month - 1, $year); $calendar -> select_day($day); # Necessary to get the correct allocation of the popup. $popup -> move(-500, -500); $popup -> show_all(); # Figure out where to put the popup - ie don't put it offscreen, # as it's not movable ( by the user ) my $screen_height = $popup->get_screen->get_height; my $requisition = $popup->size_request(); my $popup_width = $requisition->width; my $popup_height = $requisition->height; my ($x_origin, $y_origin) = $view -> get_bin_window() -> get_origin(); my ($popup_x, $popup_y); $popup_x = $x_origin + $cell_area->x() + $cell_area->width() - $popup_width; $popup_x = 0 if $popup_x < 0; $popup_y = $y_origin + $cell_area -> y() + $cell_area -> height(); if ( $popup_y + $popup_height > $screen_height ) { $popup_y = $y_origin + $cell_area -> y() - $popup_height; } $popup -> move( $popup_x, $popup_y ); # Grab the focus and the pointer. Gtk2 -> grab_add($popup); $popup -> grab_focus(); Gtk2::Gdk -> pointer_grab($popup -> window(), 1, [qw(button-press-mask button-release-mask pointer-motion-mask)], undef, undef, 0); return; } sub get_date_string { my $cell = shift; return $cell->get ('date'); } sub calc_size { my ($cell, $layout) = @_; my ($width, $height) = $layout -> get_pixel_size(); return (0, 0, $width + x_padding * 2 + arrow_width, $height + y_padding * 2); } sub GET_SIZE { my ($cell, $widget, $cell_area) = @_; my $layout = $cell -> get_layout($widget); $layout -> set_text( $cell -> get_date_string() || '' ); return $cell -> calc_size($layout); } sub get_layout { my ($cell, $widget) = @_; return $widget -> create_pango_layout(""); } sub RENDER { my ($cell, $window, $widget, $background_area, $cell_area, $expose_area, $flags) = @_; my $state; if ($flags & 'selected') { $state = $widget -> has_focus() ? 'selected' : 'active'; } else { $state = $widget -> state() eq 'insensitive' ? 'insensitive' : 'normal'; } my $layout = $cell -> get_layout($widget); $layout -> set_text( $cell -> get_date_string() || '' ); my ($x_offset, $y_offset, $width, $height) = $cell -> calc_size($layout); $widget -> get_style -> paint_layout($window, $state, 1, $cell_area, $widget, "cellrenderertext", $cell_area -> x() + $x_offset + x_padding, $cell_area -> y() + $y_offset + y_padding, $layout); $widget -> get_style -> paint_arrow ($window, $widget->state, 'none', $cell_area, $cell -> { _arrow }, "", "down", 1, $cell_area -> x + $cell_area -> width - arrow_width, $cell_area -> y + $cell_area -> height - arrow_height - 2, arrow_width - 3, arrow_height); } 1; From mail2karuna@hotmail.com Tue Jun 27 05:53:25 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 0ECA43B00E4 for ; Tue, 27 Jun 2006 05:53:25 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21270-07 for ; Tue, 27 Jun 2006 05:53:11 -0400 (EDT) Received: from hotmail.com (bay123-f24.bay123.hotmail.com [207.46.11.104]) by menubar.gnome.org (Postfix) with ESMTP id 2C7C03B0104 for ; Tue, 27 Jun 2006 05:53:11 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 27 Jun 2006 02:53:10 -0700 Message-ID: Received: from 207.46.11.123 by by123fd.bay123.hotmail.msn.com with HTTP; Tue, 27 Jun 2006 09:53:09 GMT X-Originating-IP: [62.193.236.100] X-Originating-Email: [mail2karuna@hotmail.com] X-Sender: mail2karuna@hotmail.com From: "karuna karan" To: gtk-devel-list@gnome.org Subject: Re: Failed building GTK with the DFB backend Date: Tue, 27 Jun 2006 09:53:09 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 27 Jun 2006 09:53:10.0427 (UTC) FILETIME=[7F932EB0:01C699CF] X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-0.958 tagged_above=-999 required=2 tests=[BAYES_05=-1.11, MSGID_FROM_MTA_HEADER=0, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, TW_BG=0.077, TW_GT=0.077] X-Spam-Score: -0.958 X-Spam-Level: Cc: skar@tataelxsi.co.in X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2006 09:53:25 -0000 Hi all, I tried to build gtk 2.9.1 with directFB backend with following dependencies, glib 2.11.1 atk 1.10.1 cairo 1.1.6 pango 1.13.1 directfb 0.9.25.1 while building gtk with, 1 ./configure --prefix=/opt/gtkdfb/ --without-x --with-gdktarget=directfb --enable-debug=no 2 make the buld fails and throws the error as, queryimmodules.c: In function `query_module': queryimmodules.c:116: warning: dereferencing type-punned pointer will break strict-aliasing rules queryimmodules.c:117: warning: dereferencing type-punned pointer will break strict-aliasing rules queryimmodules.c:118: warning: dereferencing type-punned pointer will break strict-aliasing rules queryimmodules.c:119: warning: dereferencing type-punned pointer will break strict-aliasing rules /bin/sh ../libtool --mode=link gcc -g -O2 -Wall -o gtk-query-immodules-2.0 queryimmodules.o libgtk-directfb-2.0.la .../gdk-pixbuf/libgdk_pixbuf-2.0.la ../gdk/libgdk-directfb-2.0.la gcc -g -O2 -Wall -o .libs/gtk-query-immodules-2.0 queryimmodules.o ../.libs/libgtk-directfb-2.0.so -L/opt/gtkdfb/lib /root/gtk+-2.9.1/gdk/.libs/libgdk-directfb-2.0.so /opt/gtkdfb/lib/libatk-1.0.so ../gdk-pixbuf/.libs/libgdk_pixbuf-2.0.so .../gdk/.libs/libgdk-directfb-2.0.so /opt/gtkdfb/lib/libpangocairo-1.0.so /opt/gtkdfb/lib/libpangoft2-1.0.so /opt/gtkdfb/lib/libpango-1.0.so /opt/gtkdfb/lib/libcairo.so -lpng12 /opt/gtkdfb/lib/libdirectfb.so /opt/gtkdfb/lib/libfusion.so /opt/gtkdfb/lib/libdirect.so -lfontconfig /usr/lib/libfreetype.so /usr/lib/libxml2.so -lpthread -lz /root/gtk+-2.9.1/gdk-pixbuf/.libs/libgdk_pixbuf-2.0.so /opt/gtkdfb/lib/libgmodule-2.0.so -ldl /opt/gtkdfb/lib/libgobject-2.0.so /opt/gtkdfb/lib/libglib-2.0.so -lm -Wl,--rpath -Wl,/opt/gtkdfb/lib ../.libs/libgtk-directfb-2.0.so: undefined reference to `gdk_screen_is_composited' /root/gtk+-2.9.1/gdk/.libs/libgdk-directfb-2.0.so: undefined reference to `IA__gdk_screen_is_composited' collect2: ld returned 1 exit status make[4]: *** [gtk-query-immodules-2.0] Error 1 make[4]: Leaving directory `/root/gtk+-2.9.1/gtk' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/root/gtk+-2.9.1/gtk' make[2]: *** [all] Error 2 make[2]: Leaving directory `/root/gtk+-2.9.1/gtk' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/root/gtk+-2.9.1' make: *** [all] Error 2 help me out in this.. Thanks, Karunakaran A. _________________________________________________________________ Dont just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/ From fiandro@tiscali.it Tue Jun 27 06:05:04 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C52653B0010 for ; Tue, 27 Jun 2006 06:05:04 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22230-02 for ; Tue, 27 Jun 2006 06:05:02 -0400 (EDT) Received: from polito.it (anacreon.polito.it [130.192.3.82]) by menubar.gnome.org (Postfix) with ESMTP id 1B1113B0088 for ; Tue, 27 Jun 2006 06:05:00 -0400 (EDT) X-ExtScanner: Niversoft's FindAttachments (free) Received: from [130.192.31.127] (HELO [130.192.31.127]) by anacreon.polito.it (CommuniGate Pro SMTP 5.0.9) with ESMTP id 39350329; Tue, 27 Jun 2006 12:04:58 +0200 Message-ID: <44A103E0.8000000@tiscali.it> Date: Tue, 27 Jun 2006 12:09:36 +0200 From: Attilio Fiandrotti User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.13) Gecko/20060620 Debian/1.7.13-0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: karuna karan Subject: Re: Failed building GTK with the DFB backend References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.224 tagged_above=-999 required=2 tests=[AWL=-0.337, BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2, FORGED_RCVD_HELO=0.135, SPF_NEUTRAL=1.069, TW_DF=0.077, TW_GT=0.077, TW_KD=0.077, TW_TK=0.077] X-Spam-Score: -1.224 X-Spam-Level: Cc: gtk-devel-list@gnome.org, skar@tataelxsi.co.in X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2006 10:05:05 -0000 karuna karan wrote: > Hi all, > > I tried to build gtk 2.9.1 with directFB backend with following > dependencies, DFB support in was broken: you should try 2.9.4 or follow instructions in the wiki page to build from sratch. If you're a debian user, you can also use precompiled i386 official packages that were built this week http://download.dajobe.org/debian/experimental/ <-cairodfb http://people.debian.org/~joss/packages/ <-gtkdfb Attilio From kris@babi-pangang.org Tue Jun 27 08:43:52 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 623A53B00AE for ; Tue, 27 Jun 2006 08:43:52 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29028-04 for ; Tue, 27 Jun 2006 08:43:48 -0400 (EDT) Received: from nasi-goreng.babi-pangang.org (nasi-goreng.babi-pangang.org [83.166.137.20]) by menubar.gnome.org (Postfix) with ESMTP id 5BA363B008D for ; Tue, 27 Jun 2006 08:43:48 -0400 (EDT) Received: by nasi-goreng.babi-pangang.org (Postfix, from userid 1000) id C52593DCA0; Tue, 27 Jun 2006 14:42:09 +0200 (CEST) Date: Tue, 27 Jun 2006 14:42:09 +0200 From: Kristian Rietveld To: gtk-devel-list@gnome.org Subject: Minutes of the GTK+ meeting at GUADEC Message-ID: <20060627124209.GA23474@babi-pangang.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.564 tagged_above=-999 required=2 tests=[AWL=0.035, BAYES_00=-2.599] X-Spam-Score: -2.564 X-Spam-Level: X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2006 12:43:52 -0000 Hey, We had a GTK+ meeting in person at GUADEC last Sunday. Below are the minutes (or really just the notes I took). -kris. ---- GTK+ Meeting, 25 June 2006, GUADEC7 ----------------------------------- * 2.10 is basically done, we are aiming for a release next week. * Tommi asks whether the GTK+ development/maintainer team is big enough. Matthias and Tim both answer that the team has been too small for the last few years, everybody else seems to agree. * Planning 2.12, possible new features: - Canvas, and we need off-screen rendering for that. # At least 3 different candidate canvases around. # Some ideas from Soeren; immediate mode, callbacks. He will write up his ideas and send it to the list for discussion. # Defining the feature set for a canvas is really difficult, though most people agreed that GnomeCanvas does cover most of the features needed by general applications. # Might want to look at the new canvas in Qt 4.1. - Introspection - GtkBuilder, the libglade integration into GTK+. - The new tooltips API. - Maemo.org patches # Menu patches, # Input method, # Tap and hold. - International calendar support # GLib patch is about ready, # After that the GTK+ widget (GtkCalendar) needs some fixing up. - Support for editable multi-line labels, probably by extending GtkEntry. - libsexy cherrypicking # Support having an icon in the entry. # Input masks. - Recent file code updates # GtkRecentAction. # GtkFileChooser integration. * Matthias continues on Tommi's previous question on maintenance, mentioning the OS X backend. Micke and Richard explain that the backend is mostly working, but does need some bug fixing. It's marked as still experimental. * The file chooser API does have some issues. For example the backend API is private, and getting the model from the file chooser dialog is impossible. Also the code for supporting the pluggability of the UI does not work/has not been tested at all. * We decided to target the GTK+ 2.12 release on January '07. This should give us enough time to put all new features in. If we decide to include a canvas with GTK+ 2.12, we might have to depend on a new release of Cairo. According to Carl Worth the next releases of Cairo are pretty much "open". They will probably focus on performance for the next release. Making a new release for supporting some special canvas features should be feasible. * We get interrupted by some guys of the board. Jeff speaks about having the GTK+ project join the GNOME foundation. The foundation can provide help to the GTK+ project with financial and administrative tasks. It has been doing this for the GIMP project already, which has been working fine so far. The foundation does not get any influence on the technical decisions made by the GTK+ team. Also, the plan is to get a press release out on this. * The board leaves and the core team pretty much decides that doing this is not bad at all, and the only thing that needs work is the wording in the press release. Nobody appears to be against. * The topic of GTK+ 3.0 was brought up after this. 3.0 would be an API and ABI breaking release. The team decided that we would like to avoid breaking API since a lot of companies invested into GTK+ 2.x and expect that it'll be supported for some more years. Most of the team seems to agree that we want to get rid of the cruft in the 2.x series, some of which is still sticking around from the 1.x series. Matthias mentions that FC6 will not ship with GTK+ 1.x. (People cheered and Tim complained about he won't be able to run xmms then). The idea of introducing compiling subsets was brought up. We could set up a make system where the full library or only a subset is built, for example omitting all the old stuff and the printing support. The people using GTK+ on embedded devices would be really happy if we implemented something like this. If we want the compiling subsets to work, we need to make sure that none of the internal code is using deprecated widgets. Breaking API is not really something we really want to do soon. If we ever do it, we want to do it right so it can last for at least a couple of years. Also, we would prefer the development on 3.0 to happen in parallel with 2.x development. Alex brought up the idea of creating a bug which we can use to track all issues which require breaking the API, so we get a formalized list of stuff which needs API breakage. According to Tim breaking the ABI is not a real problem, since distributions and also for example the Maemo.org platform can just be recompiled. * Tim also mentioned that Michael Meeks has been working on optimizing shared library loading optimization in OpenOffice.org. We wondered if there's anything we can do to improve GTK+'s performance in this area. As Michael was unable to attend Tim and/or Matthias will try to have a talk with Michael about this. As there was nothing left discuss, we decided to close the meeting. From skar@tataelxsi.co.in Tue Jun 27 07:22:44 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 665AF3B0072 for ; Tue, 27 Jun 2006 07:22:44 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25789-03 for ; Tue, 27 Jun 2006 07:22:43 -0400 (EDT) Received: from mail.tataelxsi.co.in (mail.tataelxsi.co.in [203.200.1.48]) by menubar.gnome.org (Postfix) with ESMTP id 1DFEF3B0011 for ; Tue, 27 Jun 2006 07:22:41 -0400 (EDT) Received: from skar (tataelxsi.co.in [203.197.169.80] (may be forged)) by mail.tataelxsi.co.in (MOS 3.7.4b-GA) with ESMTP id BRG33699 (AUTH skar); Tue, 27 Jun 2006 16:52:16 +0530 (IST) From: Suman Kar To: "'Attilio Fiandrotti'" , "'karuna karan'" Subject: RE: Failed building GTK with the DFB backend Date: Tue, 27 Jun 2006 16:51:13 +0530 Message-ID: <002301c699db$cd352ea0$381b320a@telxsi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal In-Reply-To: <44A103E0.8000000@tiscali.it> X-Junkmail: Blacklisted X-Mirapoint-Sig: mail.tataelxsi.co.in X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=0.386 tagged_above=-999 required=2 tests=[BAYES_50=0.001, TW_DF=0.077, TW_GD=0.077, TW_GT=0.077, TW_KD=0.077, TW_TK=0.077] X-Spam-Score: 0.386 X-Spam-Level: X-Mailman-Approved-At: Tue, 27 Jun 2006 10:07:05 -0400 Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: Suman Kar List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2006 11:22:44 -0000 Hello Attilio, Thanks for the quick update. However, the problem goes away when we added the following: gboolean gdk_screen_is_composited (GdkScreen *screen) { g_return_val_if_fail (GDK_IS_SCREEN (screen), NULL); return FALSE; } is added to gdkscreen-directfb.c (from http://mail.gnome.org/archives/gtk-devel-list/2006-May/msg00210.html ). We will definitely try building gtk+2.9.4 and will get back in case there are any issues. One more thing: we would be really interested in gtk+-2.10. Any idea when this will be out? Regards, Suman. -----Original Message----- From: Attilio Fiandrotti [mailto:fiandro@tiscali.it] Sent: Tuesday, June 27, 2006 3:40 PM To: karuna karan Cc: gtk-devel-list@gnome.org; skar@tataelxsi.co.in Subject: Re: Failed building GTK with the DFB backend karuna karan wrote: > Hi all, > > I tried to build gtk 2.9.1 with directFB backend with following > dependencies, DFB support in was broken: you should try 2.9.4 or follow instructions in the wiki page to build from sratch. If you're a debian user, you can also use precompiled i386 official packages that were built this week http://download.dajobe.org/debian/experimental/ <-cairodfb http://people.debian.org/~joss/packages/ <-gtkdfb Attilio The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s)and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender or administrator@tataelxsi.co.in From mail2karuna@hotmail.com Wed Jun 28 01:21:49 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 761EF3B002A for ; Wed, 28 Jun 2006 01:21:49 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27811-08 for ; Wed, 28 Jun 2006 01:21:48 -0400 (EDT) Received: from hotmail.com (bay123-f28.bay123.hotmail.com [207.46.11.108]) by menubar.gnome.org (Postfix) with ESMTP id 40EF13B000F for ; Wed, 28 Jun 2006 01:21:48 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 27 Jun 2006 22:19:26 -0700 Message-ID: Received: from 207.46.11.123 by by123fd.bay123.hotmail.msn.com with HTTP; Wed, 28 Jun 2006 05:19:23 GMT X-Originating-IP: [62.193.236.96] X-Originating-Email: [mail2karuna@hotmail.com] X-Sender: mail2karuna@hotmail.com In-Reply-To: <002301c699db$cd352ea0$381b320a@telxsi.com> From: "karuna karan" To: fiandro@tiscali.it, skar@tataelxsi.co.in, amirthakaruna@tataelxsi.co.in Subject: RE: Failed building GTK with the DFB backend Date: Wed, 28 Jun 2006 05:19:23 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 28 Jun 2006 05:19:26.0977 (UTC) FILETIME=[6CD95710:01C69A72] X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-0.502 tagged_above=-999 required=2 tests=[AWL=-1.829, BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2, DNS_FROM_RFC_POST=1.708, MSGID_FROM_MTA_HEADER=0, RCVD_IN_BL_SPAMCOP_NET=1.558, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, TW_DF=0.077, TW_DK=0.077, TW_GD=0.077, TW_GT=0.077, TW_KD=0.077, TW_TK=0.077] X-Spam-Score: -0.502 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2006 05:21:49 -0000 Hi, we have tried to build gtk+ 2.9.4 with backend dfb. we got the follwing error while building, gdkwindow-directfb.c: In function `gdk_directfb_create_child_window': gdkwindow-directfb.c:2508: error: structure has no member named `GetPosition' make[4]: *** [gdkwindow-directfb.lo] Error 1 make[4]: Leaving directory `/root/new/gtk+-2.9.4/gdk/directfb' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/root/new/gtk+-2.9.4/gdk' make[2]: *** [all] Error 2 make[2]: Leaving directory `/root/new/gtk+-2.9.4/gdk' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/root/new/gtk+-2.9.4' make: *** [all] Error 2 so kindly give feedback on this issue.. Thanks, Karunakaran A. >From: Suman Kar >Reply-To: Suman Kar >To: "'Attilio Fiandrotti'" , "'karuna karan'" > >CC: >Subject: RE: Failed building GTK with the DFB backend >Date: Tue, 27 Jun 2006 16:51:13 +0530 > >Hello Attilio, > >Thanks for the quick update. However, the problem goes away when we added >the following: > >gboolean >gdk_screen_is_composited (GdkScreen *screen) >{ > g_return_val_if_fail (GDK_IS_SCREEN (screen), NULL); > return FALSE; >} > > >is added to gdkscreen-directfb.c (from >http://mail.gnome.org/archives/gtk-devel-list/2006-May/msg00210.html ). > >We will definitely try building gtk+2.9.4 and will get back in case there >are any issues. > >One more thing: we would be really interested in gtk+-2.10. Any idea when >this will be out? > >Regards, >Suman. > >-----Original Message----- >From: Attilio Fiandrotti [mailto:fiandro@tiscali.it] >Sent: Tuesday, June 27, 2006 3:40 PM >To: karuna karan >Cc: gtk-devel-list@gnome.org; skar@tataelxsi.co.in >Subject: Re: Failed building GTK with the DFB backend > > >karuna karan wrote: > > Hi all, > > > > I tried to build gtk 2.9.1 with directFB backend with following > > dependencies, > >DFB support in was broken: you should try 2.9.4 or follow instructions >in the wiki page to build from sratch. >If you're a debian user, you can also use precompiled i386 official >packages that were built this week > >http://download.dajobe.org/debian/experimental/ <-cairodfb >http://people.debian.org/~joss/packages/ <-gtkdfb > >Attilio > >The information contained in this electronic message and any attachments to >this message are intended for the exclusive use of the addressee(s)and may >contain confidential or privileged information. If you are not the intended >recipient, please notify the sender or administrator@tataelxsi.co.in _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today - it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ From matthias.clasen@gmail.com Wed Jun 28 03:10:14 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 5BEF93B002C for ; Wed, 28 Jun 2006 03:10:14 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30060-02 for ; Wed, 28 Jun 2006 03:10:12 -0400 (EDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.183]) by menubar.gnome.org (Postfix) with ESMTP id 603903B009C for ; Wed, 28 Jun 2006 03:10:12 -0400 (EDT) Received: by py-out-1112.google.com with SMTP id c30so2171621pyc for ; Wed, 28 Jun 2006 00:09:17 -0700 (PDT) Received: by 10.35.83.6 with SMTP id k6mr338054pyl; Wed, 28 Jun 2006 00:09:17 -0700 (PDT) Received: by 10.35.39.16 with HTTP; Wed, 28 Jun 2006 00:09:17 -0700 (PDT) Message-ID: Date: Wed, 28 Jun 2006 03:09:17 -0400 From: "Matthias Clasen" To: "Suman Kar" Subject: Re: Failed building GTK with the DFB backend In-Reply-To: <002301c699db$cd352ea0$381b320a@telxsi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <44A103E0.8000000@tiscali.it> <002301c699db$cd352ea0$381b320a@telxsi.com> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.41 tagged_above=-999 required=2 tests=[AWL=-0.010, BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2, SPF_PASS=-0.001] X-Spam-Score: -2.41 X-Spam-Level: Cc: gtk-devel-list@gnome.org, karuna karan X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2006 07:10:14 -0000 On 6/27/06, Suman Kar wrote: > One more thing: we would be really interested in gtk+-2.10. Any idea when > this will be out? > I'll start working on the release when I'm back from Guadec next week. From fiandro@tiscali.it Wed Jun 28 03:57:13 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 3E6E73B0002 for ; Wed, 28 Jun 2006 03:57:13 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31177-01 for ; Wed, 28 Jun 2006 03:57:10 -0400 (EDT) Received: from aa003msr.fastwebnet.it (aa003msr.fastwebnet.it [85.18.95.66]) by menubar.gnome.org (Postfix) with ESMTP id 4417B3B0005 for ; Wed, 28 Jun 2006 03:57:10 -0400 (EDT) Received: from [192.168.2.2] (41.255.136.50) by aa003msr.fastwebnet.it (7.2.070.1) id 44965DC20058C56D; Wed, 28 Jun 2006 09:55:45 +0200 Message-ID: <44A23718.3020008@tiscali.it> Date: Wed, 28 Jun 2006 10:00:24 +0200 From: Attilio Fiandrotti User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.13) Gecko/20060620 Debian/1.7.13-0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: karuna karan Subject: Re: Failed building GTK with the DFB backend References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=1.347 tagged_above=-999 required=2 tests=[AWL=-0.215, BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2, RCVD_IN_WHOIS_BOGONS=2.43, SPF_NEUTRAL=1.069, TW_DF=0.077, TW_DK=0.077, TW_GD=0.077, TW_GT=0.077, TW_KD=0.077, TW_TK=0.077] X-Spam-Score: 1.347 X-Spam-Level: * Cc: gtk-devel-list@gnome.org, skar@tataelxsi.co.in, amirthakaruna@tataelxsi.co.in X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2006 07:57:13 -0000 A couple of days ago mike checked in the patch that excludes from compilation some extra code that requires DFB 0.9.25 in the case DFN 0.9.24 is used. Use CVS sources or apply to GTK 2.9.4 gdkdirectfb.h and gdkwindow-directfb.c from current SVN. If you're a Debian user and run on i386, simply install cairodfb and gtkdfb packages [1] which were made recently available (other archs will follow soon). Attilio [1] http://mail.directfb.org/pipermail/directfb-dev/2006-June/001973.html karuna karan wrote: > Hi, > > we have tried to build gtk+ 2.9.4 with backend dfb. > we got the follwing error while building, > > gdkwindow-directfb.c: In function `gdk_directfb_create_child_window': > gdkwindow-directfb.c:2508: error: structure has no member named > `GetPosition' > make[4]: *** [gdkwindow-directfb.lo] Error 1 > make[4]: Leaving directory `/root/new/gtk+-2.9.4/gdk/directfb' > make[3]: *** [all-recursive] Error 1 > make[3]: Leaving directory `/root/new/gtk+-2.9.4/gdk' > make[2]: *** [all] Error 2 > make[2]: Leaving directory `/root/new/gtk+-2.9.4/gdk' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/root/new/gtk+-2.9.4' > make: *** [all] Error 2 > > so kindly give feedback on this issue.. > > Thanks, > Karunakaran A. > > > > >> From: Suman Kar >> Reply-To: Suman Kar >> To: "'Attilio Fiandrotti'" , "'karuna >> karan'" >> CC: >> Subject: RE: Failed building GTK with the DFB backend >> Date: Tue, 27 Jun 2006 16:51:13 +0530 >> >> Hello Attilio, >> >> Thanks for the quick update. However, the problem goes away when we added >> the following: >> >> gboolean >> gdk_screen_is_composited (GdkScreen *screen) >> { >> g_return_val_if_fail (GDK_IS_SCREEN (screen), NULL); >> return FALSE; >> } >> >> >> is added to gdkscreen-directfb.c (from >> http://mail.gnome.org/archives/gtk-devel-list/2006-May/msg00210.html ). >> >> We will definitely try building gtk+2.9.4 and will get back in case there >> are any issues. >> >> One more thing: we would be really interested in gtk+-2.10. Any idea when >> this will be out? >> >> Regards, >> Suman. >> >> -----Original Message----- >> From: Attilio Fiandrotti [mailto:fiandro@tiscali.it] >> Sent: Tuesday, June 27, 2006 3:40 PM >> To: karuna karan >> Cc: gtk-devel-list@gnome.org; skar@tataelxsi.co.in >> Subject: Re: Failed building GTK with the DFB backend >> >> >> karuna karan wrote: >> > Hi all, >> > >> > I tried to build gtk 2.9.1 with directFB backend with following >> > dependencies, >> >> DFB support in was broken: you should try 2.9.4 or follow instructions >> in the wiki page to build from sratch. >> If you're a debian user, you can also use precompiled i386 official >> packages that were built this week >> >> http://download.dajobe.org/debian/experimental/ <-cairodfb >> http://people.debian.org/~joss/packages/ <-gtkdfb >> >> Attilio >> >> The information contained in this electronic message and any >> attachments to this message are intended for the exclusive use of the >> addressee(s)and may contain confidential or privileged information. If >> you are not the intended recipient, please notify the sender or >> administrator@tataelxsi.co.in > > > _________________________________________________________________ > Express yourself instantly with MSN Messenger! Download today - it's > FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ > > From mail2karuna@hotmail.com Wed Jun 28 04:51:51 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 8EFB63B0079 for ; Wed, 28 Jun 2006 04:51:51 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00776-08 for ; Wed, 28 Jun 2006 04:51:50 -0400 (EDT) Received: from hotmail.com (bay123-f31.bay123.hotmail.com [207.46.11.111]) by menubar.gnome.org (Postfix) with ESMTP id 2CB433B0005 for ; Wed, 28 Jun 2006 04:51:50 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 28 Jun 2006 01:50:10 -0700 Message-ID: Received: from 207.46.11.123 by by123fd.bay123.hotmail.msn.com with HTTP; Wed, 28 Jun 2006 08:50:07 GMT X-Originating-IP: [62.193.226.74] X-Originating-Email: [mail2karuna@hotmail.com] X-Sender: mail2karuna@hotmail.com In-Reply-To: <44A23718.3020008@tiscali.it> From: "karuna karan" To: fiandro@tiscali.it Subject: Re: Failed building GTK with the DFB backend Date: Wed, 28 Jun 2006 08:50:07 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 28 Jun 2006 08:50:10.0376 (UTC) FILETIME=[DCE6EC80:01C69A8F] X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=1.17 tagged_above=-999 required=2 tests=[AWL=-3.240, BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2, DNS_FROM_RFC_POST=1.708, MSGID_FROM_MTA_HEADER=0, RCVD_IN_BL_SPAMCOP_NET=1.558, RCVD_IN_SBL=3.16, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, TW_DF=0.077, TW_GD=0.077, TW_GT=0.077, TW_KD=0.077, TW_TK=0.077] X-Spam-Score: 1.17 X-Spam-Level: * Cc: gtk-devel-list@gnome.org, skar@tataelxsi.co.in, amirthakaruna@tataelxsi.co.in X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2006 08:51:51 -0000 hi, we are already working with DirectFB 0.9.25.1 and GTK 2.9.4(released) we will start work with GTK 2.9.4 from CVS as suggested by you. we will get back if any issue arises. Thanks, Karunakaran A. >From: Attilio Fiandrotti >A couple of days ago mike checked in the patch that excludes from >compilation some extra code that requires DFB 0.9.25 in the case DFN 0.9.24 >is used. >Use CVS sources or apply to GTK 2.9.4 gdkdirectfb.h and >gdkwindow-directfb.c from current SVN. >If you're a Debian user and run on i386, simply install cairodfb and gtkdfb >packages [1] which were made recently available (other archs will follow >soon). > >Attilio > >[1] http://mail.directfb.org/pipermail/directfb-dev/2006-June/001973.html > >karuna karan wrote: >>Hi, >> >>we have tried to build gtk+ 2.9.4 with backend dfb. >>we got the follwing error while building, >> >>gdkwindow-directfb.c: In function `gdk_directfb_create_child_window': >>gdkwindow-directfb.c:2508: error: structure has no member named >>`GetPosition' >>make[4]: *** [gdkwindow-directfb.lo] Error 1 >>make[4]: Leaving directory `/root/new/gtk+-2.9.4/gdk/directfb' >>make[3]: *** [all-recursive] Error 1 >>make[3]: Leaving directory `/root/new/gtk+-2.9.4/gdk' >>make[2]: *** [all] Error 2 >>make[2]: Leaving directory `/root/new/gtk+-2.9.4/gdk' >>make[1]: *** [all-recursive] Error 1 >>make[1]: Leaving directory `/root/new/gtk+-2.9.4' >>make: *** [all] Error 2 >> >>so kindly give feedback on this issue.. >> >>Thanks, >>Karunakaran A. >> >> >> >> >>>From: Suman Kar >>>Reply-To: Suman Kar >>>To: "'Attilio Fiandrotti'" , "'karuna karan'" >>> >>>CC: >>>Subject: RE: Failed building GTK with the DFB backend >>>Date: Tue, 27 Jun 2006 16:51:13 +0530 >>> >>>Hello Attilio, >>> >>>Thanks for the quick update. However, the problem goes away when we added >>>the following: >>> >>>gboolean >>>gdk_screen_is_composited (GdkScreen *screen) >>>{ >>> g_return_val_if_fail (GDK_IS_SCREEN (screen), NULL); >>> return FALSE; >>>} >>> >>> >>>is added to gdkscreen-directfb.c (from >>>http://mail.gnome.org/archives/gtk-devel-list/2006-May/msg00210.html ). >>> >>>We will definitely try building gtk+2.9.4 and will get back in case there >>>are any issues. >>> >>>One more thing: we would be really interested in gtk+-2.10. Any idea when >>>this will be out? >>> >>>Regards, >>>Suman. >>> >>>-----Original Message----- >>>From: Attilio Fiandrotti [mailto:fiandro@tiscali.it] >>>Sent: Tuesday, June 27, 2006 3:40 PM >>>To: karuna karan >>>Cc: gtk-devel-list@gnome.org; skar@tataelxsi.co.in >>>Subject: Re: Failed building GTK with the DFB backend >>> >>> >>>karuna karan wrote: >>> > Hi all, >>> > >>> > I tried to build gtk 2.9.1 with directFB backend with following >>> > dependencies, >>> >>>DFB support in was broken: you should try 2.9.4 or follow instructions >>>in the wiki page to build from sratch. >>>If you're a debian user, you can also use precompiled i386 official >>>packages that were built this week >>> >>>http://download.dajobe.org/debian/experimental/ <-cairodfb >>>http://people.debian.org/~joss/packages/ <-gtkdfb >>> >>>Attilio >>> >>>The information contained in this electronic message and any attachments >>>to this message are intended for the exclusive use of the addressee(s)and >>>may contain confidential or privileged information. If you are not the >>>intended recipient, please notify the sender or >>>administrator@tataelxsi.co.in >> >> >>_________________________________________________________________ >>Express yourself instantly with MSN Messenger! Download today - it's FREE! >>http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ >> >> > _________________________________________________________________ Dont just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/ From mail2karuna@hotmail.com Wed Jun 28 04:57:44 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id EB6A23B00A2 for ; Wed, 28 Jun 2006 04:57:43 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01098-06 for ; Wed, 28 Jun 2006 04:57:42 -0400 (EDT) Received: from bay0-omc3-s25.bay0.hotmail.com (bay0-omc3-s25.bay0.hotmail.com [65.54.246.225]) by menubar.gnome.org (Postfix) with ESMTP id 8E64F3B0002 for ; Wed, 28 Jun 2006 04:57:42 -0400 (EDT) Received: from hotmail.com ([207.46.11.110]) by bay0-omc3-s25.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Jun 2006 01:57:15 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 28 Jun 2006 01:57:15 -0700 Message-ID: Received: from 207.46.11.123 by by123fd.bay123.hotmail.msn.com with HTTP; Wed, 28 Jun 2006 08:57:12 GMT X-Originating-IP: [62.193.235.46] X-Originating-Email: [mail2karuna@hotmail.com] X-Sender: mail2karuna@hotmail.com In-Reply-To: <006101c69a90$871e5d00$361b320a@telxsi.com> From: "karuna karan" To: gtk-devel-list@gnome.org Subject: RE: Failed building GTK with the DFB backend Date: Wed, 28 Jun 2006 08:57:12 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 28 Jun 2006 08:57:15.0331 (UTC) FILETIME=[DA31E930:01C69A90] X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-0.194 tagged_above=-999 required=2 tests=[AWL=-1.445, BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2, DNS_FROM_RFC_POST=1.708, MSGID_FROM_MTA_HEADER=0, RCVD_IN_BL_SPAMCOP_NET=1.558, SPF_PASS=-0.001, TW_DF=0.077, TW_GD=0.077, TW_GT=0.077, TW_KD=0.077, TW_TK=0.077] X-Spam-Score: -0.194 X-Spam-Level: Cc: amirthakaruna@tataelxsi.co.in, skar@tataelxsi.co.in X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2006 08:57:44 -0000 hi, we are already working with DirectFB 0.9.25.1 and GTK 2.9.4(released) we will start work with GTK 2.9.4 from CVS as suggested by you. we will get back if any issue arises. Thanks, Karunakaran A. >From: Attilio Fiandrotti >A couple of days ago mike checked in the patch that excludes from >compilation some extra code that requires DFB 0.9.25 in the case DFN 0.9.24 >is used. >Use CVS sources or apply to GTK 2.9.4 gdkdirectfb.h and >gdkwindow-directfb.c from current SVN. >If you're a Debian user and run on i386, simply install cairodfb and gtkdfb >packages [1] which were made recently available (other archs will follow >soon). > >Attilio > >[1] http://mail.directfb.org/pipermail/directfb-dev/2006-June/001973.html > >karuna karan wrote: >>Hi, >> >>we have tried to build gtk+ 2.9.4 with backend dfb. >>we got the follwing error while building, >> >>gdkwindow-directfb.c: In function `gdk_directfb_create_child_window': >>gdkwindow-directfb.c:2508: error: structure has no member named >>`GetPosition' >>make[4]: *** [gdkwindow-directfb.lo] Error 1 >>make[4]: Leaving directory `/root/new/gtk+-2.9.4/gdk/directfb' >>make[3]: *** [all-recursive] Error 1 >>make[3]: Leaving directory `/root/new/gtk+-2.9.4/gdk' >>make[2]: *** [all] Error 2 >>make[2]: Leaving directory `/root/new/gtk+-2.9.4/gdk' >>make[1]: *** [all-recursive] Error 1 >>make[1]: Leaving directory `/root/new/gtk+-2.9.4' >>make: *** [all] Error 2 >> >>so kindly give feedback on this issue.. >> >>Thanks, >>Karunakaran A. >> >> >> >> >>>From: Suman Kar >>>Reply-To: Suman Kar >>>To: "'Attilio Fiandrotti'" , "'karuna karan'" >>> >>>CC: >>>Subject: RE: Failed building GTK with the DFB backend >>>Date: Tue, 27 Jun 2006 16:51:13 +0530 >>> >>>Hello Attilio, >>> >>>Thanks for the quick update. However, the problem goes away when we added >>>the following: >>> >>>gboolean >>>gdk_screen_is_composited (GdkScreen *screen) >>>{ >>> g_return_val_if_fail (GDK_IS_SCREEN (screen), NULL); >>> return FALSE; >>>} >>> >>> >>>is added to gdkscreen-directfb.c (from >>>http://mail.gnome.org/archives/gtk-devel-list/2006-May/msg00210.html ). >>> >>>We will definitely try building gtk+2.9.4 and will get back in case there > >>>are any issues. > >>> > >>>One more thing: we would be really interested in gtk+-2.10. Any idea >when > >>>this will be out? > >>> > >>>Regards, > >>>Suman. > >>> > >>>-----Original Message----- > >>>From: Attilio Fiandrotti [mailto:fiandro@tiscali.it] > >>>Sent: Tuesday, June 27, 2006 3:40 PM > >>>To: karuna karan > >>>Cc: gtk-devel-list@gnome.org; skar@tataelxsi.co.in > >>>Subject: Re: Failed building GTK with the DFB backend > >>> > >>> > >>>karuna karan wrote: > >>> > Hi all, > >>> > > >>> > I tried to build gtk 2.9.1 with directFB backend with following > >>> > dependencies, > >>> > >>>DFB support in was broken: you should try 2.9.4 or follow instructions > >>>in the wiki page to build from sratch. > >>>If you're a debian user, you can also use precompiled i386 official > >>>packages that were built this week > >>> > >>>http://download.dajobe.org/debian/experimental/ <-cairodfb > >>>http://people.debian.org/~joss/packages/ <-gtkdfb > >>> > >>>Attilio > >>> > >>>The information contained in this electronic message and any >attachments > >>>to this message are intended for the exclusive use of the >addressee(s)and > >>>may contain confidential or privileged information. If you are not the > >>>intended recipient, please notify the sender or > >>>administrator@tataelxsi.co.in > >> > >> > >>_________________________________________________________________ > >>Express yourself instantly with MSN Messenger! Download today - it's >FREE! > >>http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ > >> > >> > > > >_________________________________________________________________ >Dont just search. Find. Check out the new MSN Search! >http://search.msn.click-url.com/go/onm00200636ave/direct/01/ > >The information contained in this electronic message and any attachments to >this message are intended for the exclusive use of the addressee(s)and may >contain confidential or privileged information. If you are not the intended >recipient, please notify the sender or administrator@tataelxsi.co.in _________________________________________________________________ Dont just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/ From dave.foster@gmail.com Tue Jun 27 23:09:46 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id A42223B0010 for ; Tue, 27 Jun 2006 23:09:46 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25505-01 for ; Tue, 27 Jun 2006 23:09:45 -0400 (EDT) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.225]) by menubar.gnome.org (Postfix) with ESMTP id CEB183B0005 for ; Tue, 27 Jun 2006 23:09:44 -0400 (EDT) Received: by wr-out-0506.google.com with SMTP id i4so303425wra for ; Tue, 27 Jun 2006 20:08:24 -0700 (PDT) Received: by 10.54.80.7 with SMTP id d7mr394957wrb; Tue, 27 Jun 2006 20:08:24 -0700 (PDT) Received: from ?192.168.1.107? ( [68.0.246.8]) by mx.gmail.com with ESMTP id 64sm2194346wra.2006.06.27.20.08.24; Tue, 27 Jun 2006 20:08:24 -0700 (PDT) Subject: gdk_display_close segfault? From: Dave Foster To: gtk-devel-list@gnome.org Content-Type: text/plain Date: Wed, 28 Jun 2006 01:01:55 -0400 Message-Id: <1151470915.4791.3.camel@neptune.minuslab.net> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.6 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.6 X-Spam-Level: X-Mailman-Approved-At: Wed, 28 Jun 2006 07:11:10 -0400 X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2006 03:09:46 -0000 Hi, I've been trying to write a small section of code in my program which makes a second connection to the X display, using gtkmm.. I kept having problems, after rewriting it about 5 or 6 times, I tried writing it in straight gdk, and STILL got the problems. I seem to get a segfault whenever I call gdk_display_close(). Here is a rediculously simple example that gives the problem: Glib::ustring disp = ":0.0"; GdkDisplay* gdisp = gdk_display_open(disp.c_str()); if (!gdisp) ... gdk_display_close(gdisp); /* Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1224202560 (LWP 5689)] 0xb7b413d0 in gdk_display_x11_dispose () from /usr/lib/libgdk-x11-2.0.so.0 (gdb) bt #0 0xb7b413d0 in gdk_display_x11_dispose () from /usr/lib/libgdk-x11-2.0.so.0 #1 0xb7a11f2b in g_object_unref () from /usr/lib/libgobject-2.0.so.0 #2 0xb7b20c04 in gdk_display_close () from /usr/lib/libgdk-x11-2.0.so.0 #3 0x080571d5 in SetBG::set_bg (disp=@0xbfe1b2b0, file=@0xbfe1b2ac, mode=SetBG::SET_SCALE, bgcolor=@0xbfe1b2a8) at SetBG.cc:67 ... */ The display is opening fine. I'm running: gtk: 2.8.17-1 glib: 2.10.2-1 (hmm, didn't notice that before,t he 2.8 vs 2.10 thing, could that be it?) Anyway, I've spent all night trying to debug this and weeks trying to sort this problem out in my program. What is up with this, what can I do? thanks all. dave From fiandro@tiscali.it Wed Jun 28 07:47:12 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id EF7893B0087 for ; Wed, 28 Jun 2006 07:47:11 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08611-03 for ; Wed, 28 Jun 2006 07:47:10 -0400 (EDT) Received: from polito.it (anacreon.polito.it [130.192.3.82]) by menubar.gnome.org (Postfix) with ESMTP id AEB163B00A0 for ; Wed, 28 Jun 2006 07:47:09 -0400 (EDT) X-ExtScanner: Niversoft's FindAttachments (free) Received: from [130.192.31.127] (HELO [130.192.31.127]) by anacreon.polito.it (CommuniGate Pro SMTP 5.0.9) with ESMTP id 39386694; Wed, 28 Jun 2006 13:46:14 +0200 Message-ID: <44A26D1D.9090905@tiscali.it> Date: Wed, 28 Jun 2006 13:50:53 +0200 From: Attilio Fiandrotti User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.13) Gecko/20060620 Debian/1.7.13-0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Suman Kar Subject: Re: Failed building GTK with the DFB backend References: <000101c69aa6$6547c9d0$381b320a@telxsi.com> In-Reply-To: <000101c69aa6$6547c9d0$381b320a@telxsi.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.35 tagged_above=-999 required=2 tests=[AWL=-0.540, BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2, FORGED_RCVD_HELO=0.135, SPF_NEUTRAL=1.069, TW_DF=0.077, TW_GD=0.077, TW_GT=0.077, TW_KD=0.077, TW_TK=0.077] X-Spam-Score: -1.35 X-Spam-Level: Cc: gtk-devel-list@gnome.org, amirthakaruna@tataelxsi.co.in X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2006 11:47:12 -0000 I apologize for my mistake: only now i realize taht getposition() and getsize() were introduced *after* DFB 0.9.25 was released! Yesterday mike checked in a patch ("Added ifdef to compile with 0.9.24 removes creating a child GdkWindow since it u...") that allows GTK+ to be compiled against DFB >= 0.9.24 (so, also 0.9.25 will do) The correct recipe is: DFB >= 0.9.24 GTK+ HEAD from CVS Attilio Suman Kar wrote: > Hello Attilio, > > Let me try to explain Karuna's problem: we are using the > downloadable source tarball from > http://directfb.org/index.php?path=Main%2FDownloads: > DirectFB-0.9.25.1.tar.gz > > Also, this was released on 03-May-2006. Mike's checkin has happened > on 11-June-2006. Moreover, we could not find the GetPosition() > member in either the http://directfb.org/index.php?path=Main%2FNews > page or in the source files Mike has mentioned in the mail to > the directFB list. > > These indicates to me that this is not really an issue with some path > variable as you suggested. Your inputs are awaited. > > Regards, > Suman. > > -----Original Message----- > From: Attilio Fiandrotti [mailto:fiandro@tiscali.it] > Sent: Wednesday, June 28, 2006 3:03 PM > To: karuna karan > Cc: skar@tataelxsi.co.in; amirthakaruna@tataelxsi.co.in > Subject: Re: Failed building GTK with the DFB backend > > > the symbol GetPosition (and getsize, too) were introduced in DFB 0.9.25 > : if you're trying to compile GTKDFB against DFB 0.9.25, then you must > have provided wrong pkg_config_path or ld_library_path > > Attilio > > karuna karan wrote: > >>hi, >> >>we are already working with DirectFB 0.9.25.1 and GTK 2.9.4(released) >> >>we will start work with GTK 2.9.4 from CVS as suggested by you. >> >>we will get back if any issue arises. >> >>Thanks, >>Karunakaran A. >> >> >> >> >From: Attilio Fiandrotti >> >> >A couple of days ago mike checked in the patch that excludes from >> >compilation some extra code that requires DFB 0.9.25 in the case DFN >>0.9.24 >> >is used. >> >Use CVS sources or apply to GTK 2.9.4 gdkdirectfb.h and >> >gdkwindow-directfb.c from current SVN. >> >If you're a Debian user and run on i386, simply install cairodfb and >>gtkdfb >> >packages [1] which were made recently available (other archs will follow >> >soon). >> > >> >Attilio >> > >> >[1] > > http://mail.directfb.org/pipermail/directfb-dev/2006-June/001973.html > >> > >> >karuna karan wrote: >> >>Hi, >> >> >> >>we have tried to build gtk+ 2.9.4 with backend dfb. >> >>we got the follwing error while building, >> >> >> >>gdkwindow-directfb.c: In function `gdk_directfb_create_child_window': >> >>gdkwindow-directfb.c:2508: error: structure has no member named >> >>`GetPosition' >> >>make[4]: *** [gdkwindow-directfb.lo] Error 1 >> >>make[4]: Leaving directory `/root/new/gtk+-2.9.4/gdk/directfb' >> >>make[3]: *** [all-recursive] Error 1 >> >>make[3]: Leaving directory `/root/new/gtk+-2.9.4/gdk' >> >>make[2]: *** [all] Error 2 >> >>make[2]: Leaving directory `/root/new/gtk+-2.9.4/gdk' >> >>make[1]: *** [all-recursive] Error 1 >> >>make[1]: Leaving directory `/root/new/gtk+-2.9.4' >> >>make: *** [all] Error 2 >> >> >> >>so kindly give feedback on this issue.. >> >> >> >>Thanks, >> >>Karunakaran A. >> >> >> >> >> >> >> >> >> >>>From: Suman Kar >> >>>Reply-To: Suman Kar >> >>>To: "'Attilio Fiandrotti'" , "'karuna >>karan'" >> >>> >> >>>CC: >> >>>Subject: RE: Failed building GTK with the DFB backend >> >>>Date: Tue, 27 Jun 2006 16:51:13 +0530 >> >>> >> >>>Hello Attilio, >> >>> >> >>>Thanks for the quick update. However, the problem goes away when we >>added >> >>>the following: >> >>> >> >>>gboolean >> >>>gdk_screen_is_composited (GdkScreen *screen) >> >>>{ >> >>> g_return_val_if_fail (GDK_IS_SCREEN (screen), NULL); >> >>> return FALSE; >> >>>} >> >>> >> >>> >> >>>is added to gdkscreen-directfb.c (from >> >> >>>>>http://mail.gnome.org/archives/gtk-devel-list/2006-May/msg00210.html ). >> >> >>> >> >>>We will definitely try building gtk+2.9.4 and will get back in case >>there >> >> >>>>>>are any issues. >>>>>> >>>>>>One more thing: we would be really interested in gtk+-2.10. Any >>> >>>idea when >>> >>>>>>this will be out? >>>>>> >>>>>>Regards, >>>>>>Suman. >>>>>> >>>>>>-----Original Message----- >>>>>>From: Attilio Fiandrotti [mailto:fiandro@tiscali.it] >>>>>>Sent: Tuesday, June 27, 2006 3:40 PM >>>>>>To: karuna karan >>>>>>Cc: gtk-devel-list@gnome.org; skar@tataelxsi.co.in >>>>>>Subject: Re: Failed building GTK with the DFB backend >>>>>> >>>>>> >>>>>>karuna karan wrote: >>>>>> >>>>>>>Hi all, >>>>>>> >>>>>>>I tried to build gtk 2.9.1 with directFB backend with following >>>>>>>dependencies, >>>>>> >>>>>>DFB support in was broken: you should try 2.9.4 or follow instructions >>>>>>in the wiki page to build from sratch. >>>>>>If you're a debian user, you can also use precompiled i386 official >>>>>>packages that were built this week >>>>>> >>>>>>http://download.dajobe.org/debian/experimental/ <-cairodfb >>>>>>http://people.debian.org/~joss/packages/ <-gtkdfb >>>>>> >>>>>>Attilio >>>>>> >>>>>>The information contained in this electronic message and any >>> >>>attachments >>> >>>>>>to this message are intended for the exclusive use of the >>> >>>addressee(s)and >>> >>>>>>may contain confidential or privileged information. If you are not the >>>>>>intended recipient, please notify the sender or >>>>>>administrator@tataelxsi.co.in >>>>> >>>>> >>>>>_________________________________________________________________ >>>>>Express yourself instantly with MSN Messenger! Download today - it's >>> >>>FREE! >>> >>>>>http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ >>>>> >>>>> >>>> >>>_________________________________________________________________ >>>Dont just search. Find. Check out the new MSN Search! >>>http://search.msn.click-url.com/go/onm00200636ave/direct/01/ >>> >>>The information contained in this electronic message and any >>>attachments to this message are intended for the exclusive use of the >>>addressee(s)and may contain confidential or privileged information. If >>>you are not the intended recipient, please notify the sender or >>>administrator@tataelxsi.co.in >> >> >>_________________________________________________________________ >>Dont just search. Find. Check out the new MSN Search! >>http://search.msn.click-url.com/go/onm00200636ave/direct/01/ >> >> >> >> >>------------------------------------------------------------------------ >> >>The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s)and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender or administrator@tataelxsi.co.in From skar@tataelxsi.co.in Wed Jun 28 07:31:56 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id B3F193B006C for ; Wed, 28 Jun 2006 07:31:56 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07955-07 for ; Wed, 28 Jun 2006 07:31:55 -0400 (EDT) Received: from mail.tataelxsi.co.in (mail.tataelxsi.co.in [203.200.1.48]) by menubar.gnome.org (Postfix) with ESMTP id 0CA9D3B00F3 for ; Wed, 28 Jun 2006 07:31:53 -0400 (EDT) Received: from skar (tataelxsi.co.in [203.197.169.80] (may be forged)) by mail.tataelxsi.co.in (MOS 3.7.4b-GA) with ESMTP id BRJ72122 (AUTH skar); Wed, 28 Jun 2006 17:02:27 +0530 (IST) From: Suman Kar To: "'Attilio Fiandrotti'" , Subject: RE: Failed building GTK with the DFB backend Date: Wed, 28 Jun 2006 17:01:26 +0530 Message-ID: <000101c69aa6$6547c9d0$381b320a@telxsi.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <44A24CDC.4070707@tiscali.it> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Junkmail: Blacklisted Content-Type: multipart/mixed; boundary="MIRAPOINT_PART1_44a268cc" X-Mirapoint-Sig: mail.tataelxsi.co.in X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.291 tagged_above=-999 required=2 tests=[AWL=-0.635, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.558, TW_DF=0.077, TW_GD=0.077, TW_GT=0.077, TW_KD=0.077, TW_TK=0.077] X-Spam-Score: -1.291 X-Spam-Level: X-Mailman-Approved-At: Wed, 28 Jun 2006 08:28:51 -0400 Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: Suman Kar List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2006 11:31:56 -0000 --MIRAPOINT_PART1_44a268cc Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 8bit Hello Attilio, Let me try to explain Karuna's problem: we are using the downloadable source tarball from http://directfb.org/index.php?path=Main%2FDownloads: DirectFB-0.9.25.1.tar.gz Also, this was released on 03-May-2006. Mike's checkin has happened on 11-June-2006. Moreover, we could not find the GetPosition() member in either the http://directfb.org/index.php?path=Main%2FNews page or in the source files Mike has mentioned in the mail to the directFB list. These indicates to me that this is not really an issue with some path variable as you suggested. Your inputs are awaited. Regards, Suman. -----Original Message----- From: Attilio Fiandrotti [mailto:fiandro@tiscali.it] Sent: Wednesday, June 28, 2006 3:03 PM To: karuna karan Cc: skar@tataelxsi.co.in; amirthakaruna@tataelxsi.co.in Subject: Re: Failed building GTK with the DFB backend the symbol GetPosition (and getsize, too) were introduced in DFB 0.9.25 : if you're trying to compile GTKDFB against DFB 0.9.25, then you must have provided wrong pkg_config_path or ld_library_path Attilio karuna karan wrote: > hi, > > we are already working with DirectFB 0.9.25.1 and GTK 2.9.4(released) > > we will start work with GTK 2.9.4 from CVS as suggested by you. > > we will get back if any issue arises. > > Thanks, > Karunakaran A. > > > > >From: Attilio Fiandrotti > > >A couple of days ago mike checked in the patch that excludes from > >compilation some extra code that requires DFB 0.9.25 in the case DFN > 0.9.24 > >is used. > >Use CVS sources or apply to GTK 2.9.4 gdkdirectfb.h and > >gdkwindow-directfb.c from current SVN. > >If you're a Debian user and run on i386, simply install cairodfb and > gtkdfb > >packages [1] which were made recently available (other archs will follow > >soon). > > > >Attilio > > > >[1] http://mail.directfb.org/pipermail/directfb-dev/2006-June/001973.html > > > >karuna karan wrote: > >>Hi, > >> > >>we have tried to build gtk+ 2.9.4 with backend dfb. > >>we got the follwing error while building, > >> > >>gdkwindow-directfb.c: In function `gdk_directfb_create_child_window': > >>gdkwindow-directfb.c:2508: error: structure has no member named > >>`GetPosition' > >>make[4]: *** [gdkwindow-directfb.lo] Error 1 > >>make[4]: Leaving directory `/root/new/gtk+-2.9.4/gdk/directfb' > >>make[3]: *** [all-recursive] Error 1 > >>make[3]: Leaving directory `/root/new/gtk+-2.9.4/gdk' > >>make[2]: *** [all] Error 2 > >>make[2]: Leaving directory `/root/new/gtk+-2.9.4/gdk' > >>make[1]: *** [all-recursive] Error 1 > >>make[1]: Leaving directory `/root/new/gtk+-2.9.4' > >>make: *** [all] Error 2 > >> > >>so kindly give feedback on this issue.. > >> > >>Thanks, > >>Karunakaran A. > >> > >> > >> > >> > >>>From: Suman Kar > >>>Reply-To: Suman Kar > >>>To: "'Attilio Fiandrotti'" , "'karuna > karan'" > >>> > >>>CC: > >>>Subject: RE: Failed building GTK with the DFB backend > >>>Date: Tue, 27 Jun 2006 16:51:13 +0530 > >>> > >>>Hello Attilio, > >>> > >>>Thanks for the quick update. However, the problem goes away when we > added > >>>the following: > >>> > >>>gboolean > >>>gdk_screen_is_composited (GdkScreen *screen) > >>>{ > >>> g_return_val_if_fail (GDK_IS_SCREEN (screen), NULL); > >>> return FALSE; > >>>} > >>> > >>> > >>>is added to gdkscreen-directfb.c (from > >>>> http://mail.gnome.org/archives/gtk-devel-list/2006-May/msg00210.html ). > > >>> > >>>We will definitely try building gtk+2.9.4 and will get back in case > there > >> >>>are any issues. >> >>> >> >>>One more thing: we would be really interested in gtk+-2.10. Any >> idea when >> >>>this will be out? >> >>> >> >>>Regards, >> >>>Suman. >> >>> >> >>>-----Original Message----- >> >>>From: Attilio Fiandrotti [mailto:fiandro@tiscali.it] >> >>>Sent: Tuesday, June 27, 2006 3:40 PM >> >>>To: karuna karan >> >>>Cc: gtk-devel-list@gnome.org; skar@tataelxsi.co.in >> >>>Subject: Re: Failed building GTK with the DFB backend >> >>> >> >>> >> >>>karuna karan wrote: >> >>> > Hi all, >> >>> > >> >>> > I tried to build gtk 2.9.1 with directFB backend with following >> >>> > dependencies, >> >>> >> >>>DFB support in was broken: you should try 2.9.4 or follow instructions >> >>>in the wiki page to build from sratch. >> >>>If you're a debian user, you can also use precompiled i386 official >> >>>packages that were built this week >> >>> >> >>>http://download.dajobe.org/debian/experimental/ <-cairodfb >> >>>http://people.debian.org/~joss/packages/ <-gtkdfb >> >>> >> >>>Attilio >> >>> >> >>>The information contained in this electronic message and any >> attachments >> >>>to this message are intended for the exclusive use of the >> addressee(s)and >> >>>may contain confidential or privileged information. If you are not the >> >>>intended recipient, please notify the sender or >> >>>administrator@tataelxsi.co.in >> >> >> >> >> >>_________________________________________________________________ >> >>Express yourself instantly with MSN Messenger! Download today - it's >> FREE! >> >>http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ >> >> >> >> >> > >> >> _________________________________________________________________ >> Dont just search. Find. Check out the new MSN Search! >> http://search.msn.click-url.com/go/onm00200636ave/direct/01/ >> >> The information contained in this electronic message and any >> attachments to this message are intended for the exclusive use of the >> addressee(s)and may contain confidential or privileged information. If >> you are not the intended recipient, please notify the sender or >> administrator@tataelxsi.co.in > > > _________________________________________________________________ > Dont just search. Find. Check out the new MSN Search! > http://search.msn.click-url.com/go/onm00200636ave/direct/01/ > > --MIRAPOINT_PART1_44a268cc Content-Disposition: inline The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s)and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender or administrator@tataelxsi.co.in --MIRAPOINT_PART1_44a268cc-- From skar@tataelxsi.co.in Wed Jun 28 08:09:32 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id B55753B016E for ; Wed, 28 Jun 2006 08:09:32 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09711-02 for ; Wed, 28 Jun 2006 08:09:31 -0400 (EDT) Received: from mail.tataelxsi.co.in (mail.tataelxsi.co.in [203.200.1.48]) by menubar.gnome.org (Postfix) with ESMTP id B45AB3B01C1 for ; Wed, 28 Jun 2006 08:09:29 -0400 (EDT) Received: from skar (tataelxsi.co.in [203.197.169.80] (may be forged)) by mail.tataelxsi.co.in (MOS 3.7.4b-GA) with ESMTP id BRJ80256 (AUTH skar); Wed, 28 Jun 2006 17:40:28 +0530 (IST) From: Suman Kar To: "'Attilio Fiandrotti'" Subject: RE: Failed building GTK with the DFB backend Date: Wed, 28 Jun 2006 17:39:28 +0530 Message-ID: <000801c69aab$b5138bc0$381b320a@telxsi.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <44A26D1D.9090905@tiscali.it> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Junkmail: Blacklisted Content-Type: multipart/mixed; boundary="MIRAPOINT_PART1_44a271b6" X-Mirapoint-Sig: mail.tataelxsi.co.in X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.227 tagged_above=-999 required=2 tests=[AWL=-0.571, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.558, TW_DF=0.077, TW_GD=0.077, TW_GT=0.077, TW_KD=0.077, TW_TK=0.077] X-Spam-Score: -1.227 X-Spam-Level: X-Mailman-Approved-At: Wed, 28 Jun 2006 08:29:04 -0400 Cc: gtk-devel-list@gnome.org, amirthakaruna@tataelxsi.co.in X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: Suman Kar List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2006 12:09:32 -0000 --MIRAPOINT_PART1_44a271b6 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 8bit Can you please post a link to Mike's change? URL to the CVS will do. I am a little confused as the GNOME cvs did not show any results when searching for entries by memmel and the directFB CVS did not throw up a check-in in the last two days. Regards, Suman. -----Original Message----- From: Attilio Fiandrotti [mailto:fiandro@tiscali.it] Sent: Wednesday, June 28, 2006 5:21 PM To: Suman Kar Cc: amirthakaruna@tataelxsi.co.in; gtk-devel-list@gnome.org Subject: Re: Failed building GTK with the DFB backend I apologize for my mistake: only now i realize taht getposition() and getsize() were introduced *after* DFB 0.9.25 was released! Yesterday mike checked in a patch ("Added ifdef to compile with 0.9.24 removes creating a child GdkWindow since it u...") that allows GTK+ to be compiled against DFB >= 0.9.24 (so, also 0.9.25 will do) The correct recipe is: DFB >= 0.9.24 GTK+ HEAD from CVS Attilio Suman Kar wrote: > Hello Attilio, > > Let me try to explain Karuna's problem: we are using the > downloadable source tarball from > http://directfb.org/index.php?path=Main%2FDownloads: > DirectFB-0.9.25.1.tar.gz > > Also, this was released on 03-May-2006. Mike's checkin has happened > on 11-June-2006. Moreover, we could not find the GetPosition() > member in either the http://directfb.org/index.php?path=Main%2FNews > page or in the source files Mike has mentioned in the mail to > the directFB list. > > These indicates to me that this is not really an issue with some path > variable as you suggested. Your inputs are awaited. > > Regards, > Suman. > > -----Original Message----- > From: Attilio Fiandrotti [mailto:fiandro@tiscali.it] > Sent: Wednesday, June 28, 2006 3:03 PM > To: karuna karan > Cc: skar@tataelxsi.co.in; amirthakaruna@tataelxsi.co.in > Subject: Re: Failed building GTK with the DFB backend > > > the symbol GetPosition (and getsize, too) were introduced in DFB 0.9.25 > : if you're trying to compile GTKDFB against DFB 0.9.25, then you must > have provided wrong pkg_config_path or ld_library_path > > Attilio > > karuna karan wrote: > >>hi, >> >>we are already working with DirectFB 0.9.25.1 and GTK 2.9.4(released) >> >>we will start work with GTK 2.9.4 from CVS as suggested by you. >> >>we will get back if any issue arises. >> >>Thanks, >>Karunakaran A. >> >> >> >> >From: Attilio Fiandrotti >> >> >A couple of days ago mike checked in the patch that excludes from >> >compilation some extra code that requires DFB 0.9.25 in the case DFN >>0.9.24 >> >is used. >> >Use CVS sources or apply to GTK 2.9.4 gdkdirectfb.h and >> >gdkwindow-directfb.c from current SVN. >> >If you're a Debian user and run on i386, simply install cairodfb and >>gtkdfb >> >packages [1] which were made recently available (other archs will follow >> >soon). >> > >> >Attilio >> > >> >[1] > > http://mail.directfb.org/pipermail/directfb-dev/2006-June/001973.html > >> > >> >karuna karan wrote: >> >>Hi, >> >> >> >>we have tried to build gtk+ 2.9.4 with backend dfb. >> >>we got the follwing error while building, >> >> >> >>gdkwindow-directfb.c: In function `gdk_directfb_create_child_window': >> >>gdkwindow-directfb.c:2508: error: structure has no member named >> >>`GetPosition' >> >>make[4]: *** [gdkwindow-directfb.lo] Error 1 >> >>make[4]: Leaving directory `/root/new/gtk+-2.9.4/gdk/directfb' >> >>make[3]: *** [all-recursive] Error 1 >> >>make[3]: Leaving directory `/root/new/gtk+-2.9.4/gdk' >> >>make[2]: *** [all] Error 2 >> >>make[2]: Leaving directory `/root/new/gtk+-2.9.4/gdk' >> >>make[1]: *** [all-recursive] Error 1 >> >>make[1]: Leaving directory `/root/new/gtk+-2.9.4' >> >>make: *** [all] Error 2 >> >> >> >>so kindly give feedback on this issue.. >> >> >> >>Thanks, >> >>Karunakaran A. >> >> >> >> >> >> >> >> >> >>>From: Suman Kar >> >>>Reply-To: Suman Kar >> >>>To: "'Attilio Fiandrotti'" , "'karuna >>karan'" >> >>> >> >>>CC: >> >>>Subject: RE: Failed building GTK with the DFB backend >> >>>Date: Tue, 27 Jun 2006 16:51:13 +0530 >> >>> >> >>>Hello Attilio, >> >>> >> >>>Thanks for the quick update. However, the problem goes away when we >>added >> >>>the following: >> >>> >> >>>gboolean >> >>>gdk_screen_is_composited (GdkScreen *screen) >> >>>{ >> >>> g_return_val_if_fail (GDK_IS_SCREEN (screen), NULL); >> >>> return FALSE; >> >>>} >> >>> >> >>> >> >>>is added to gdkscreen-directfb.c (from >> >> >>>>>http://mail.gnome.org/archives/gtk-devel-list/2006-May/msg00210.html ). >> >> >>> >> >>>We will definitely try building gtk+2.9.4 and will get back in case >>there >> >> >>>>>>are any issues. >>>>>> >>>>>>One more thing: we would be really interested in gtk+-2.10. Any >>> >>>idea when >>> >>>>>>this will be out? >>>>>> >>>>>>Regards, >>>>>>Suman. >>>>>> >>>>>>-----Original Message----- >>>>>>From: Attilio Fiandrotti [mailto:fiandro@tiscali.it] >>>>>>Sent: Tuesday, June 27, 2006 3:40 PM >>>>>>To: karuna karan >>>>>>Cc: gtk-devel-list@gnome.org; skar@tataelxsi.co.in >>>>>>Subject: Re: Failed building GTK with the DFB backend >>>>>> >>>>>> >>>>>>karuna karan wrote: >>>>>> >>>>>>>Hi all, >>>>>>> >>>>>>>I tried to build gtk 2.9.1 with directFB backend with following >>>>>>>dependencies, >>>>>> >>>>>>DFB support in was broken: you should try 2.9.4 or follow instructions >>>>>>in the wiki page to build from sratch. >>>>>>If you're a debian user, you can also use precompiled i386 official >>>>>>packages that were built this week >>>>>> >>>>>>http://download.dajobe.org/debian/experimental/ <-cairodfb >>>>>>http://people.debian.org/~joss/packages/ <-gtkdfb >>>>>> >>>>>>Attilio >>>>>> >>>>>>The information contained in this electronic message and any >>> >>>attachments >>> >>>>>>to this message are intended for the exclusive use of the >>> >>>addressee(s)and >>> >>>>>>may contain confidential or privileged information. If you are not the >>>>>>intended recipient, please notify the sender or >>>>>>administrator@tataelxsi.co.in >>>>> >>>>> >>>>>_________________________________________________________________ >>>>>Express yourself instantly with MSN Messenger! Download today - it's >>> >>>FREE! >>> >>>>>http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ >>>>> >>>>> >>>> >>>_________________________________________________________________ >>>Dont just search. Find. Check out the new MSN Search! >>>http://search.msn.click-url.com/go/onm00200636ave/direct/01/ >>> >>>The information contained in this electronic message and any >>>attachments to this message are intended for the exclusive use of the >>>addressee(s)and may contain confidential or privileged information. If >>>you are not the intended recipient, please notify the sender or >>>administrator@tataelxsi.co.in >> >> >>_________________________________________________________________ >>Dont just search. Find. Check out the new MSN Search! >>http://search.msn.click-url.com/go/onm00200636ave/direct/01/ >> >> >> >> >>------------------------------------------------------------------------ >> >>The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s)and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender or administrator@tataelxsi.co.in --MIRAPOINT_PART1_44a271b6 Content-Disposition: inline The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s)and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender or administrator@tataelxsi.co.in --MIRAPOINT_PART1_44a271b6-- From skar@tataelxsi.co.in Wed Jun 28 08:23:02 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 0B3E43B00B1 for ; Wed, 28 Jun 2006 08:23:02 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10159-01 for ; Wed, 28 Jun 2006 08:23:01 -0400 (EDT) Received: from mail.tataelxsi.co.in (mail.tataelxsi.co.in [203.200.1.48]) by menubar.gnome.org (Postfix) with ESMTP id 8F3FE3B006C for ; Wed, 28 Jun 2006 08:23:00 -0400 (EDT) Received: from skar (tataelxsi.co.in [203.197.169.80] (may be forged)) by mail.tataelxsi.co.in (MOS 3.7.4b-GA) with ESMTP id BRJ83266 (AUTH skar); Wed, 28 Jun 2006 17:53:15 +0530 (IST) From: Suman Kar To: "'Matthias Clasen'" Subject: RE: Failed building GTK with the DFB backend Date: Wed, 28 Jun 2006 17:52:15 +0530 Message-ID: <000a01c69aad$7e2b6270$381b320a@telxsi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Junkmail: Blacklisted X-Mirapoint-Sig: mail.tataelxsi.co.in X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-0.029 tagged_above=-999 required=2 tests=[AWL=-1.665, BAYES_50=0.001, RCVD_IN_BL_SPAMCOP_NET=1.558, TW_GT=0.077] X-Spam-Score: -0.029 X-Spam-Level: X-Mailman-Approved-At: Wed, 28 Jun 2006 08:29:19 -0400 Cc: gtk-devel-list@gnome.org, Karunakaran A X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: Suman Kar List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2006 12:23:02 -0000 Matthias, Thanks for the update! Regards, Suman. -----Original Message----- From: Matthias Clasen [mailto:matthias.clasen@gmail.com] Sent: Wednesday, June 28, 2006 12:39 PM To: Suman Kar Cc: Attilio Fiandrotti; karuna karan; gtk-devel-list@gnome.org Subject: Re: Failed building GTK with the DFB backend On 6/27/06, Suman Kar wrote: > One more thing: we would be really interested in gtk+-2.10. Any idea when > this will be out? > I'll start working on the release when I'm back from Guadec next week. The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s)and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender or administrator@tataelxsi.co.in From matthias.clasen@gmail.com Wed Jun 28 09:56:21 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id A02133B0238 for ; Wed, 28 Jun 2006 09:56:21 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14093-02 for ; Wed, 28 Jun 2006 09:56:20 -0400 (EDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.183]) by menubar.gnome.org (Postfix) with ESMTP id 9B78C3B017A for ; Wed, 28 Jun 2006 09:56:20 -0400 (EDT) Received: by py-out-1112.google.com with SMTP id c30so2229313pyc for ; Wed, 28 Jun 2006 06:55:43 -0700 (PDT) Received: by 10.35.63.2 with SMTP id q2mr140094pyk; Wed, 28 Jun 2006 06:55:43 -0700 (PDT) Received: by 10.35.39.16 with HTTP; Wed, 28 Jun 2006 06:55:43 -0700 (PDT) Message-ID: Date: Wed, 28 Jun 2006 09:55:43 -0400 From: "Matthias Clasen" To: "Dave Foster" Subject: Re: gdk_display_close segfault? In-Reply-To: <1151470915.4791.3.camel@neptune.minuslab.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1151470915.4791.3.camel@neptune.minuslab.net> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.41 tagged_above=-999 required=2 tests=[AWL=-0.010, BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2, SPF_PASS=-0.001] X-Spam-Score: -2.41 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2006 13:56:21 -0000 On 6/28/06, Dave Foster wrote: > Hi, > > I've been trying to write a small section of code in my program which > makes a second connection to the X display, using gtkmm.. I kept having > problems, after rewriting it about 5 or 6 times, I tried writing it in > straight gdk, and STILL got the problems. > > I seem to get a segfault whenever I call gdk_display_close(). Here is a > rediculously simple example that gives the problem: > > Glib::ustring disp = ":0.0"; > GdkDisplay* gdisp = gdk_display_open(disp.c_str()); > if (!gdisp) ... > gdk_display_close(gdisp); > > /* > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread -1224202560 (LWP 5689)] > 0xb7b413d0 in gdk_display_x11_dispose () from /usr/lib/libgdk-x11-2.0.so.0 > (gdb) bt > #0 0xb7b413d0 in gdk_display_x11_dispose () from /usr/lib/libgdk-x11-2.0.so.0 > #1 0xb7a11f2b in g_object_unref () from /usr/lib/libgobject-2.0.so.0 > #2 0xb7b20c04 in gdk_display_close () from /usr/lib/libgdk-x11-2.0.so.0 > #3 0x080571d5 in SetBG::set_bg (disp=@0xbfe1b2b0, file=@0xbfe1b2ac, > mode=SetBG::SET_SCALE, bgcolor=@0xbfe1b2a8) at SetBG.cc:67 > ... > */ > > The display is opening fine. I'm running: > > gtk: 2.8.17-1 > glib: 2.10.2-1 > > (hmm, didn't notice that before,t he 2.8 vs 2.10 thing, could that be it?) > > Anyway, I've spent all night trying to debug this and weeks trying to > sort this problem out in my program. What is up with this, what can I > do? gdk_display_close has been fixed in GTK+ 2.10, which should be available soon. From dave.foster@gmail.com Wed Jun 28 10:19:15 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 006DC3B02CA for ; Wed, 28 Jun 2006 10:19:15 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15554-01 for ; Wed, 28 Jun 2006 10:19:14 -0400 (EDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.193]) by menubar.gnome.org (Postfix) with ESMTP id 907993B02D3 for ; Wed, 28 Jun 2006 10:19:13 -0400 (EDT) Received: by wx-out-0102.google.com with SMTP id s15so69257wxc for ; Wed, 28 Jun 2006 07:18:46 -0700 (PDT) Received: by 10.70.49.13 with SMTP id w13mr1383280wxw; Wed, 28 Jun 2006 07:18:46 -0700 (PDT) Received: by 10.70.6.9 with HTTP; Wed, 28 Jun 2006 07:18:46 -0700 (PDT) Message-ID: Date: Wed, 28 Jun 2006 10:18:46 -0400 From: "Dave Foster" To: "Matthias Clasen" Subject: Re: gdk_display_close segfault? In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_68848_11799959.1151504326383" References: <1151470915.4791.3.camel@neptune.minuslab.net> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.399 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2, HTML_MESSAGE=0.001, SPF_PASS=-0.001] X-Spam-Score: -2.399 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2006 14:19:15 -0000 ------=_Part_68848_11799959.1151504326383 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline ok, thank you Matthias. dave On 6/28/06, Matthias Clasen wrote: > > On 6/28/06, Dave Foster wrote: > > Hi, > > > > I've been trying to write a small section of code in my program which > > makes a second connection to the X display, using gtkmm.. I kept having > > problems, after rewriting it about 5 or 6 times, I tried writing it in > > straight gdk, and STILL got the problems. > > > > I seem to get a segfault whenever I call gdk_display_close(). Here is a > > rediculously simple example that gives the problem: > > > > Glib::ustring disp = ":0.0"; > > GdkDisplay* gdisp = gdk_display_open(disp.c_str()); > > if (!gdisp) ... > > gdk_display_close(gdisp); > > > > /* > > Program received signal SIGSEGV, Segmentation fault. > > [Switching to Thread -1224202560 (LWP 5689)] > > 0xb7b413d0 in gdk_display_x11_dispose () from /usr/lib/libgdk- > x11-2.0.so.0 > > (gdb) bt > > #0 0xb7b413d0 in gdk_display_x11_dispose () from /usr/lib/libgdk- > x11-2.0.so.0 > > #1 0xb7a11f2b in g_object_unref () from /usr/lib/libgobject-2.0.so.0 > > #2 0xb7b20c04 in gdk_display_close () from /usr/lib/libgdk-x11-2.0.so.0 > > #3 0x080571d5 in SetBG::set_bg (disp=@0xbfe1b2b0, file=@0xbfe1b2ac, > > mode=SetBG::SET_SCALE, bgcolor=@0xbfe1b2a8) at SetBG.cc:67 > > ... > > */ > > > > The display is opening fine. I'm running: > > > > gtk: 2.8.17-1 > > glib: 2.10.2-1 > > > > (hmm, didn't notice that before,t he 2.8 vs 2.10 thing, could that be > it?) > > > > Anyway, I've spent all night trying to debug this and weeks trying to > > sort this problem out in my program. What is up with this, what can I > > do? > > gdk_display_close has been fixed in GTK+ 2.10, which should be > available soon. > ------=_Part_68848_11799959.1151504326383 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline ok, thank you Matthias.

dave

On 6/28/06, Matthias Clasen <matthias.clasen@gmail.com> wrote:
On 6/28/06, Dave Foster <dave.foster@gmail.com > wrote:
> Hi,
>
> I've been trying to write a small section of code in my program which
> makes a second connection to the X display, using gtkmm.. I kept having
> problems, after rewriting it about 5 or 6 times, I tried writing it in
> straight gdk, and STILL got the problems.
>
> I seem to get a segfault whenever I call gdk_display_close().  Here is a
> rediculously simple example that gives the problem:
>
> Glib::ustring disp = ": 0.0";
> GdkDisplay* gdisp = gdk_display_open(disp.c_str());
> if (!gdisp) ...
> gdk_display_close(gdisp);
>
> /*
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread -1224202560 (LWP 5689)]
> 0xb7b413d0 in gdk_display_x11_dispose () from /usr/lib/libgdk-x11-2.0.so.0
> (gdb) bt
> #0  0xb7b413d0 in gdk_display_x11_dispose () from /usr/lib/libgdk-x11-2.0.so.0
> #1  0xb7a11f2b in g_object_unref () from /usr/lib/libgobject- 2.0.so.0
> #2  0xb7b20c04 in gdk_display_close () from /usr/lib/libgdk-x11-2.0.so.0
> #3  0x080571d5 in SetBG::set_bg (disp=@0xbfe1b2b0, file=@0xbfe1b2ac,
>     mode=SetBG::SET_SCALE, bgcolor=@0xbfe1b2a8) at SetBG.cc:67
> ...
> */
>
> The display is opening fine.  I'm running:
>
> gtk: 2.8.17-1
> glib: 2.10.2-1
>
> (hmm, didn't notice that before,t he 2.8 vs 2.10 thing, could that be it?)
>
> Anyway, I've spent all night trying to debug this and weeks trying to
> sort this problem out in my program.  What is up with this, what can I
> do?

gdk_display_close has been fixed in GTK+ 2.10, which should  be
available soon.

------=_Part_68848_11799959.1151504326383-- From amirthakaruna@tataelxsi.co.in Wed Jun 28 10:30:48 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 6BE0F3B00A7 for ; Wed, 28 Jun 2006 10:30:48 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15942-08 for ; Wed, 28 Jun 2006 10:30:47 -0400 (EDT) Received: from mail.tataelxsi.co.in (mail.tataelxsi.co.in [203.200.1.48]) by menubar.gnome.org (Postfix) with ESMTP id 2C7823B00B0 for ; Wed, 28 Jun 2006 10:30:46 -0400 (EDT) Received: from amirthakaruna (tataelxsi.co.in [203.197.169.80] (may be forged)) by mail.tataelxsi.co.in (MOS 3.7.4b-GA) with ESMTP id BRK15473 (AUTH amirthakaruna); Wed, 28 Jun 2006 20:00:59 +0530 (IST) From: Karunakaran A To: "'Attilio Fiandrotti'" , "'Suman Kar'" Subject: RE: Failed building GTK with the DFB backend Date: Wed, 28 Jun 2006 20:00:01 +0530 Message-ID: <000601c69abf$5747eb80$361b320a@telxsi.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <44A26D1D.9090905@tiscali.it> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Junkmail: Blacklisted Content-Type: multipart/mixed; boundary="MIRAPOINT_PART1_44a292a6" X-Mirapoint-Sig: mail.tataelxsi.co.in X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-0.656 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.558, TW_DF=0.077, TW_GD=0.077, TW_GT=0.077, TW_KD=0.077, TW_TK=0.077] X-Spam-Score: -0.656 X-Spam-Level: X-Mailman-Approved-At: Thu, 29 Jun 2006 03:02:46 -0400 Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2006 14:30:48 -0000 --MIRAPOINT_PART1_44a292a6 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 8bit Hi all, We also tried to build gtk 2.8.18 with patch( gtk+-directfb.patch downloaded from https://debian.polito.it/downloads/gtk+-directfb.tar.bzip ) with DFB as a backend on a different machine. In that, the patch file alters only configure.in file, not the Makefile.in. so while building,it throws error in the directory `/root/gtkdfb/gtk+-2.8.18/gdk' as, make[4]: *** No rule to make target `libgdk-directfb-2.0.la',needed by `all-am'. help me out in this. Karunakaran A. -----Original Message----- From: Attilio Fiandrotti [mailto:fiandro@tiscali.it] Sent: Wednesday, June 28, 2006 5:21 PM To: Suman Kar Cc: amirthakaruna@tataelxsi.co.in; gtk-devel-list@gnome.org Subject: Re: Failed building GTK with the DFB backend I apologize for my mistake: only now i realize taht getposition() and getsize() were introduced *after* DFB 0.9.25 was released! Yesterday mike checked in a patch ("Added ifdef to compile with 0.9.24 removes creating a child GdkWindow since it u...") that allows GTK+ to be compiled against DFB >= 0.9.24 (so, also 0.9.25 will do) The correct recipe is: DFB >= 0.9.24 GTK+ HEAD from CVS Attilio Suman Kar wrote: > Hello Attilio, > > Let me try to explain Karuna's problem: we are using the > downloadable source tarball from > http://directfb.org/index.php?path=Main%2FDownloads: > DirectFB-0.9.25.1.tar.gz > > Also, this was released on 03-May-2006. Mike's checkin has happened > on 11-June-2006. Moreover, we could not find the GetPosition() > member in either the http://directfb.org/index.php?path=Main%2FNews > page or in the source files Mike has mentioned in the mail to > the directFB list. > > These indicates to me that this is not really an issue with some path > variable as you suggested. Your inputs are awaited. > > Regards, > Suman. > > -----Original Message----- > From: Attilio Fiandrotti [mailto:fiandro@tiscali.it] > Sent: Wednesday, June 28, 2006 3:03 PM > To: karuna karan > Cc: skar@tataelxsi.co.in; amirthakaruna@tataelxsi.co.in > Subject: Re: Failed building GTK with the DFB backend > > > the symbol GetPosition (and getsize, too) were introduced in DFB 0.9.25 > : if you're trying to compile GTKDFB against DFB 0.9.25, then you must > have provided wrong pkg_config_path or ld_library_path > > Attilio > > karuna karan wrote: > >>hi, >> >>we are already working with DirectFB 0.9.25.1 and GTK 2.9.4(released) >> >>we will start work with GTK 2.9.4 from CVS as suggested by you. >> >>we will get back if any issue arises. >> >>Thanks, >>Karunakaran A. >> >> >> >> >From: Attilio Fiandrotti >> >> >A couple of days ago mike checked in the patch that excludes from >> >compilation some extra code that requires DFB 0.9.25 in the case DFN >>0.9.24 >> >is used. >> >Use CVS sources or apply to GTK 2.9.4 gdkdirectfb.h and >> >gdkwindow-directfb.c from current SVN. >> >If you're a Debian user and run on i386, simply install cairodfb and >>gtkdfb >> >packages [1] which were made recently available (other archs will follow >> >soon). >> > >> >Attilio >> > >> >[1] > > http://mail.directfb.org/pipermail/directfb-dev/2006-June/001973.html > >> > >> >karuna karan wrote: >> >>Hi, >> >> >> >>we have tried to build gtk+ 2.9.4 with backend dfb. >> >>we got the follwing error while building, >> >> >> >>gdkwindow-directfb.c: In function `gdk_directfb_create_child_window': >> >>gdkwindow-directfb.c:2508: error: structure has no member named >> >>`GetPosition' >> >>make[4]: *** [gdkwindow-directfb.lo] Error 1 >> >>make[4]: Leaving directory `/root/new/gtk+-2.9.4/gdk/directfb' >> >>make[3]: *** [all-recursive] Error 1 >> >>make[3]: Leaving directory `/root/new/gtk+-2.9.4/gdk' >> >>make[2]: *** [all] Error 2 >> >>make[2]: Leaving directory `/root/new/gtk+-2.9.4/gdk' >> >>make[1]: *** [all-recursive] Error 1 >> >>make[1]: Leaving directory `/root/new/gtk+-2.9.4' >> >>make: *** [all] Error 2 >> >> >> >>so kindly give feedback on this issue.. >> >> >> >>Thanks, >> >>Karunakaran A. >> >> >> >> >> >> >> >> >> >>>From: Suman Kar >> >>>Reply-To: Suman Kar >> >>>To: "'Attilio Fiandrotti'" , "'karuna >>karan'" >> >>> >> >>>CC: >> >>>Subject: RE: Failed building GTK with the DFB backend >> >>>Date: Tue, 27 Jun 2006 16:51:13 +0530 >> >>> >> >>>Hello Attilio, >> >>> >> >>>Thanks for the quick update. However, the problem goes away when we >>added >> >>>the following: >> >>> >> >>>gboolean >> >>>gdk_screen_is_composited (GdkScreen *screen) >> >>>{ >> >>> g_return_val_if_fail (GDK_IS_SCREEN (screen), NULL); >> >>> return FALSE; >> >>>} >> >>> >> >>> >> >>>is added to gdkscreen-directfb.c (from >> >> >>>>>http://mail.gnome.org/archives/gtk-devel-list/2006-May/msg00210.html ). >> >> >>> >> >>>We will definitely try building gtk+2.9.4 and will get back in case >>there >> >> >>>>>>are any issues. >>>>>> >>>>>>One more thing: we would be really interested in gtk+-2.10. Any >>> >>>idea when >>> >>>>>>this will be out? >>>>>> >>>>>>Regards, >>>>>>Suman. >>>>>> >>>>>>-----Original Message----- >>>>>>From: Attilio Fiandrotti [mailto:fiandro@tiscali.it] >>>>>>Sent: Tuesday, June 27, 2006 3:40 PM >>>>>>To: karuna karan >>>>>>Cc: gtk-devel-list@gnome.org; skar@tataelxsi.co.in >>>>>>Subject: Re: Failed building GTK with the DFB backend >>>>>> >>>>>> >>>>>>karuna karan wrote: >>>>>> >>>>>>>Hi all, >>>>>>> >>>>>>>I tried to build gtk 2.9.1 with directFB backend with following >>>>>>>dependencies, >>>>>> >>>>>>DFB support in was broken: you should try 2.9.4 or follow instructions >>>>>>in the wiki page to build from sratch. >>>>>>If you're a debian user, you can also use precompiled i386 official >>>>>>packages that were built this week >>>>>> >>>>>>http://download.dajobe.org/debian/experimental/ <-cairodfb >>>>>>http://people.debian.org/~joss/packages/ <-gtkdfb >>>>>> >>>>>>Attilio >>>>>> >>>>>>The information contained in this electronic message and any >>> >>>attachments >>> >>>>>>to this message are intended for the exclusive use of the >>> >>>addressee(s)and >>> >>>>>>may contain confidential or privileged information. If you are not the >>>>>>intended recipient, please notify the sender or >>>>>>administrator@tataelxsi.co.in >>>>> >>>>> >>>>>_________________________________________________________________ >>>>>Express yourself instantly with MSN Messenger! Download today - it's >>> >>>FREE! >>> >>>>>http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ >>>>> >>>>> >>>> >>>_________________________________________________________________ >>>Dont just search. Find. Check out the new MSN Search! >>>http://search.msn.click-url.com/go/onm00200636ave/direct/01/ >>> >>>The information contained in this electronic message and any >>>attachments to this message are intended for the exclusive use of the >>>addressee(s)and may contain confidential or privileged information. If >>>you are not the intended recipient, please notify the sender or >>>administrator@tataelxsi.co.in >> >> >>_________________________________________________________________ >>Dont just search. Find. Check out the new MSN Search! >>http://search.msn.click-url.com/go/onm00200636ave/direct/01/ >> >> >> >> >>------------------------------------------------------------------------ >> >>The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s)and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender or administrator@tataelxsi.co.in --MIRAPOINT_PART1_44a292a6 Content-Disposition: inline The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s)and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender or administrator@tataelxsi.co.in --MIRAPOINT_PART1_44a292a6-- From jalaganapathy@tataelxsi.co.in Thu Jun 29 03:08:28 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 62B543B03EF for ; Thu, 29 Jun 2006 03:08:28 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24602-01 for ; Thu, 29 Jun 2006 03:08:26 -0400 (EDT) Received: from mail.tataelxsi.co.in (mail.tataelxsi.co.in [203.200.1.48]) by menubar.gnome.org (Postfix) with ESMTP id 1B5DF3B03B2 for ; Thu, 29 Jun 2006 03:08:25 -0400 (EDT) Received: (from mail.tataelxsi.co.in [203.197.169.20]) by mail.tataelxsi.co.in (MOS 3.7.4b-GA) with HTTP/1.1 id BRM16267 (AUTH jalaganapathy); Thu, 29 Jun 2006 12:39:37 +0530 (IST) From: Jalagandeswari G Subject: Installing GTK+2.9.1 in Fedora core2 To: gtk-devel-list@gnome.org X-Mailer: Mirapoint Webmail Direct 3.7.4b-GA MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20060629123937.BRM16267@mail.tataelxsi.co.in> Date: Thu, 29 Jun 2006 12:39:37 +0530 (IST) X-Junkmail: Blacklisted X-Mirapoint-Sig: mail.tataelxsi.co.in X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.599 tagged_above=-999 required=2 tests=[BAYES_00=-2.599] X-Spam-Score: -2.599 X-Spam-Level: X-Mailman-Approved-At: Thu, 29 Jun 2006 07:31:44 -0400 X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2006 07:08:28 -0000 Hello All, Iam trying to install gtk+2.9.1 in fedora core2. i am using glib-1.10.1, cairo-1.1.6,atk-1.0.1 and pango-1.13.1 my configure options are ./configure --prefix=/exp/ffox Confugure works fine. While running make i am getting the following errors. gcc -DHAVE_CONFIG_H -I. -I. -I.. -DG_LOG_DOMAIN=\"Gtk\" -DGTK_LIBDIR=\"/exp/ffox/lib\" -DGTK_DATADIR=\"/exp/ffox/share\" -DGTK_DATA_PREFIX=\"/exp/ffox\" -DGTK_SYSCONFDIR=\"/exp/ffox/etc\" -DGTK_VERSION=\"2.9.1\" -DGTK_BINARY_VERSION=\"2.10.0\" -DGTK_HOST=\"i686-pc-linux-gnu\" -DGTK_COMPILATION -DGTK_PRINT_BACKENDS=\"pdf,cups\" -I../gtk -I.. -I../gdk -I../gdk -I../gdk-pixbuf -I../gdk-pixbuf -DGDK_PIXBUF_DISABLE_DEPRECATED -DGDK_DISABLE_DEPRECATED -DGTK_DISABLE_DEPRECATED -DGTK_FILE_SYSTEM_ENABLE_UNSUPPORTED -DGTK_PRINT_BACKEND_ENABLE_UNSUPPORTED -DG_ENABLE_DEBUG -pthread -I/exp/ffox//include/glib-2.0 -I/exp/ffox//lib/glib-2.0/include -I/exp/ffox//include/pango-1.0 -I/exp/ffox//include/cairo -I/exp/ffox//include/atk-1.0 -I/exp/ffox/include -I/usr/X11R6/include -DG_DISABLE_DEPRECATED -g -O2 -g -Wall -MT gtkrecentmanager.lo -MD -MP -MF .deps/gtkrecentmanager.Tpo -c gtkrecentmanager.c -fPIC -DPIC -o .libs/gtkrecentmanager.o gtkrecentmanager.c:109: error: syntax error before "GBookmarkFile" gtkrecentmanager.c:109: warning: no semicolon at end of struct or union gtkrecentmanager.c:113: error: syntax error before '}' token gtkrecentmanager.c: In function `gtk_recent_manager_class_init': gtkrecentmanager.c:274: error: invalid application of `sizeof' to an incomplete type gtkrecentmanager.c: In function `gtk_recent_manager_init': gtkrecentmanager.c:286: error: dereferencing pointer to incomplete type gtkrecentmanager.c:290: error: dereferencing pointer to incomplete type gtkrecentmanager.c:291: error: dereferencing pointer to incomplete type gtkrecentmanager.c:293: error: dereferencing pointer to incomplete type gtkrecentmanager.c:294: error: dereferencing pointer to incomplete type gtkrecentmanager.c:295: error: dereferencing pointer to incomplete type gtkrecentmanager.c:296: error: dereferencing pointer to incomplete type gtkrecentmanager.c:298: error: dereferencing pointer to incomplete type gtkrecentmanager.c: In function `gtk_recent_manager_get_property': gtkrecentmanager.c:336: error: dereferencing pointer to incomplete type gtkrecentmanager.c:339: error: dereferencing pointer to incomplete type gtkrecentmanager.c:342: error: dereferencing pointer to incomplete type gtkrecentmanager.c: In function `gtk_recent_manager_finalize': gtkrecentmanager.c:357: error: dereferencing pointer to incomplete type gtkrecentmanager.c:358: error: dereferencing pointer to incomplete type gtkrecentmanager.c:360: error: dereferencing pointer to incomplete type gtkrecentmanager.c:361: error: dereferencing pointer to incomplete type gtkrecentmanager.c:363: error: dereferencing pointer to incomplete type gtkrecentmanager.c:364: warning: implicit declaration of function `g_bookmark_file_free' gtkrecentmanager.c:364: error: dereferencing pointer to incomplete type gtkrecentmanager.c: In function `gtk_recent_manager_real_changed': gtkrecentmanager.c:377: error: dereferencing pointer to incomplete type gtkrecentmanager.c:385: error: dereferencing pointer to incomplete type gtkrecentmanager.c:387: error: dereferencing pointer to incomplete type gtkrecentmanager.c:392: error: dereferencing pointer to incomplete type gtkrecentmanager.c:394: error: dereferencing pointer to incomplete type gtkrecentmanager.c:394: warning: implicit declaration of function `g_bookmark_file_new' gtkrecentmanager.c:395: error: dereferencing pointer to incomplete type gtkrecentmanager.c:399: warning: implicit declaration of function `g_bookmark_file_to_file' gtkrecentmanager.c:399: error: dereferencing pointer to incomplete type gtkrecentmanager.c:400: error: dereferencing pointer to incomplete type gtkrecentmanager.c:406: error: dereferencing pointer to incomplete type gtkrecentmanager.c:415: error: dereferencing pointer to incomplete type gtkrecentmanager.c:419: error: dereferencing pointer to incomplete type gtkrecentmanager.c:422: error: dereferencing pointer to incomplete type gtkrecentmanager.c:429: error: dereferencing pointer to incomplete type gtkrecentmanager.c:432: error: dereferencing pointer to incomplete type gtkrecentmanager.c: In function `gtk_recent_manager_poll_timeout': gtkrecentmanager.c:458: error: dereferencing pointer to incomplete type gtkrecentmanager.c:458: error: dereferencing pointer to incomplete type gtkrecentmanager.c:461: error: dereferencing pointer to incomplete type gtkrecentmanager.c:470: error: dereferencing pointer to incomplete type gtkrecentmanager.c:477: error: dereferencing pointer to incomplete type gtkrecentmanager.c: In function `gtk_recent_manager_set_filename': gtkrecentmanager.c:498: error: dereferencing pointer to incomplete type gtkrecentmanager.c:500: error: dereferencing pointer to incomplete type gtkrecentmanager.c:502: error: dereferencing pointer to incomplete type gtkrecentmanager.c:503: error: dereferencing pointer to incomplete type gtkrecentmanager.c:506: error: dereferencing pointer to incomplete type gtkrecentmanager.c:507: error: dereferencing pointer to incomplete type gtkrecentmanager.c:514: error: dereferencing pointer to incomplete type gtkrecentmanager.c: In function `build_recent_items_list': gtkrecentmanager.c:534: error: dereferencing pointer to incomplete type gtkrecentmanager.c:536: error: dereferencing pointer to incomplete type gtkrecentmanager.c:538: error: dereferencing pointer to incomplete type gtkrecentmanager.c:539: error: dereferencing pointer to incomplete type gtkrecentmanager.c:542: error: dereferencing pointer to incomplete type gtkrecentmanager.c:555: error: dereferencing pointer to incomplete type gtkrecentmanager.c:563: error: dereferencing pointer to incomplete type gtkrecentmanager.c:565: error: dereferencing pointer to incomplete type gtkrecentmanager.c:571: warning: implicit declaration of function `g_bookmark_file_load_from_file' gtkrecentmanager.c:571: error: dereferencing pointer to incomplete type gtkrecentmanager.c:572: error: dereferencing pointer to incomplete type gtkrecentmanager.c:578: error: dereferencing pointer to incomplete type gtkrecentmanager.c:581: error: dereferencing pointer to incomplete type gtkrecentmanager.c:582: error: dereferencing pointer to incomplete type gtkrecentmanager.c:587: warning: implicit declaration of function `g_bookmark_file_get_size' gtkrecentmanager.c:587: error: dereferencing pointer to incomplete type gtkrecentmanager.c:588: error: dereferencing pointer to incomplete type gtkrecentmanager.c:590: error: dereferencing pointer to incomplete type gtkrecentmanager.c:595: error: dereferencing pointer to incomplete type gtkrecentmanager.c:596: error: dereferencing pointer to incomplete type gtkrecentmanager.c: In function `IA__gtk_recent_manager_get_for_screen': gtkrecentmanager.c:683: error: dereferencing pointer to incomplete type gtkrecentmanager.c: In function `display_closed': gtkrecentmanager.c:697: error: dereferencing pointer to incomplete type gtkrecentmanager.c:698: error: dereferencing pointer to incomplete type gtkrecentmanager.c:703: error: dereferencing pointer to incomplete type gtkrecentmanager.c: In function `unset_screen': gtkrecentmanager.c:718: error: dereferencing pointer to incomplete type gtkrecentmanager.c:720: error: dereferencing pointer to incomplete type gtkrecentmanager.c:726: error: dereferencing pointer to incomplete type gtkrecentmanager.c: In function `IA__gtk_recent_manager_set_screen': gtkrecentmanager.c:759: error: dereferencing pointer to incomplete type gtkrecentmanager.c: In function `IA__gtk_recent_manager_set_limit': gtkrecentmanager.c:786: error: dereferencing pointer to incomplete type gtkrecentmanager.c: In function `IA__gtk_recent_manager_get_limit': gtkrecentmanager.c:808: error: dereferencing pointer to incomplete type gtkrecentmanager.c: In function `IA__gtk_recent_manager_add_full': gtkrecentmanager.c:977: error: dereferencing pointer to incomplete type gtkrecentmanager.c:979: error: dereferencing pointer to incomplete type gtkrecentmanager.c:980: error: dereferencing pointer to incomplete type gtkrecentmanager.c:984: warning: implicit declaration of function `g_bookmark_file_set_title' gtkrecentmanager.c:984: error: dereferencing pointer to incomplete type gtkrecentmanager.c:987: warning: implicit declaration of function `g_bookmark_file_set_description' gtkrecentmanager.c:987: error: dereferencing pointer to incomplete type gtkrecentmanager.c:989: warning: implicit declaration of function `g_bookmark_file_set_mime_type' gtkrecentmanager.c:989: error: dereferencing pointer to incomplete type gtkrecentmanager.c:996: warning: implicit declaration of function `g_bookmark_file_add_group' gtkrecentmanager.c:996: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1003: warning: implicit declaration of function `g_bookmark_file_add_application' gtkrecentmanager.c:1003: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1007: warning: implicit declaration of function `g_bookmark_file_set_is_private' gtkrecentmanager.c:1007: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1013: error: dereferencing pointer to incomplete type gtkrecentmanager.c: In function `IA__gtk_recent_manager_remove_item': gtkrecentmanager.c:1048: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1050: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1051: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1061: warning: implicit declaration of function `g_bookmark_file_remove_item' gtkrecentmanager.c:1061: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1069: error: dereferencing pointer to incomplete type gtkrecentmanager.c: In function `IA__gtk_recent_manager_has_item': gtkrecentmanager.c:1098: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1100: warning: implicit declaration of function `g_bookmark_file_has_item' gtkrecentmanager.c:1100: error: dereferencing pointer to incomplete type gtkrecentmanager.c: At top level: gtkrecentmanager.c:1104: error: syntax error before '*' token gtkrecentmanager.c: In function `build_recent_info': gtkrecentmanager.c:1110: error: `bookmarks' undeclared (first use in this function) gtkrecentmanager.c:1110: error: (Each undeclared identifier is reported only once gtkrecentmanager.c:1110: error: for each function it appears in.) gtkrecentmanager.c:1111: error: `info' undeclared (first use in this function) gtkrecentmanager.c:1113: warning: implicit declaration of function `g_bookmark_file_get_title' gtkrecentmanager.c:1114: warning: implicit declaration of function `g_bookmark_file_get_description' gtkrecentmanager.c:1115: warning: implicit declaration of function `g_bookmark_file_get_mime_type' gtkrecentmanager.c:1117: warning: implicit declaration of function `g_bookmark_file_get_is_private' gtkrecentmanager.c:1119: warning: implicit declaration of function `g_bookmark_file_get_added' gtkrecentmanager.c:1120: warning: implicit declaration of function `g_bookmark_file_get_modified' gtkrecentmanager.c:1121: warning: implicit declaration of function `g_bookmark_file_get_visited' gtkrecentmanager.c:1123: warning: implicit declaration of function `g_bookmark_file_get_groups' gtkrecentmanager.c:1123: warning: assignment makes pointer from integer without a cast gtkrecentmanager.c:1133: warning: implicit declaration of function `g_bookmark_file_get_applications' gtkrecentmanager.c:1133: warning: assignment makes pointer from integer without a cast gtkrecentmanager.c:1144: warning: implicit declaration of function `g_bookmark_file_get_app_info' gtkrecentmanager.c: In function `IA__gtk_recent_manager_lookup_item': gtkrecentmanager.c:1196: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1198: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1199: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1209: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1224: error: dereferencing pointer to incomplete type gtkrecentmanager.c: In function `IA__gtk_recent_manager_move_item': gtkrecentmanager.c:1268: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1278: warning: implicit declaration of function `g_bookmark_file_move_item' gtkrecentmanager.c:1278: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1287: error: dereferencing pointer to incomplete type gtkrecentmanager.c: In function `IA__gtk_recent_manager_get_items': gtkrecentmanager.c:1317: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1320: warning: implicit declaration of function `g_bookmark_file_get_uris' gtkrecentmanager.c:1320: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1320: warning: assignment makes pointer from integer without a cast gtkrecentmanager.c:1327: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1344: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1345: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1349: error: dereferencing pointer to incomplete type gtkrecentmanager.c: In function `purge_recent_items_list': gtkrecentmanager.c:1370: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1373: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1374: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1376: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1377: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1378: error: dereferencing pointer to incomplete type gtkrecentmanager.c: In function `IA__gtk_recent_manager_purge_items': gtkrecentmanager.c:1406: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1409: error: dereferencing pointer to incomplete type gtkrecentmanager.c:1415: error: dereferencing pointer to incomplete type make[4]: *** [gtkrecentmanager.lo] Error 1 make[4]: Leaving directory `/exp/ffox/gtk+-2.9.1/gtk' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/exp/ffox/gtk+-2.9.1/gtk' make[2]: *** [all] Error 2 make[2]: Leaving directory `/exp/ffox/gtk+-2.9.1/gtk' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/exp/ffox/gtk+-2.9.1' make: *** [all] Error 2 Pls help me out to find a solution. regards, Jala The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s)and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender or administrator@tataelxsi.co.in From mitch@gimp.org Fri Jun 30 13:17:37 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 4D29A3B00D8 for ; Fri, 30 Jun 2006 13:17:37 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02485-01 for ; Fri, 30 Jun 2006 13:17:35 -0400 (EDT) Received: from mitch.gimp.org (unknown [88.134.98.187]) by menubar.gnome.org (Postfix) with ESMTP id 96E4C3B00FF for ; Fri, 30 Jun 2006 13:17:35 -0400 (EDT) Received: from mitch by mitch.gimp.org with local (Exim 3.36 #1 (Debian)) id 1FvZfn-00022M-00; Wed, 28 Jun 2006 15:01:39 +0200 Subject: Re: gdk_display_close segfault? From: Michael Natterer To: Dave Foster In-Reply-To: <1151470915.4791.3.camel@neptune.minuslab.net> References: <1151470915.4791.3.camel@neptune.minuslab.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Wed, 28 Jun 2006 15:01:39 +0200 Message-Id: <1151499699.4451.0.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-0.219 tagged_above=-999 required=2 tests=[AWL=-2.068, BAYES_00=-2.599, DATE_IN_PAST_48_96=0.379, RCVD_IN_NJABL_DUL=1.946, RCVD_IN_SORBS_DUL=2.046, TW_GT=0.077] X-Spam-Score: -0.219 X-Spam-Level: Cc: gtk-devel-list@gnome.org X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jun 2006 17:17:37 -0000 Hi, you can stop debugging right away. Display closing *only* works in GTK+ 2.9.x (upcoming 2.10). No way of making this work in any earlier version. ciao, --mitch On Wed, 2006-06-28 at 01:01 -0400, Dave Foster wrote: > Hi, > > I've been trying to write a small section of code in my program which > makes a second connection to the X display, using gtkmm.. I kept having > problems, after rewriting it about 5 or 6 times, I tried writing it in > straight gdk, and STILL got the problems. > > I seem to get a segfault whenever I call gdk_display_close(). Here is a > rediculously simple example that gives the problem: > > Glib::ustring disp = ":0.0"; > GdkDisplay* gdisp = gdk_display_open(disp.c_str()); > if (!gdisp) ... > gdk_display_close(gdisp); > > /* > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread -1224202560 (LWP 5689)] > 0xb7b413d0 in gdk_display_x11_dispose () from /usr/lib/libgdk-x11-2.0.so.0 > (gdb) bt > #0 0xb7b413d0 in gdk_display_x11_dispose () from /usr/lib/libgdk-x11-2.0.so.0 > #1 0xb7a11f2b in g_object_unref () from /usr/lib/libgobject-2.0.so.0 > #2 0xb7b20c04 in gdk_display_close () from /usr/lib/libgdk-x11-2.0.so.0 > #3 0x080571d5 in SetBG::set_bg (disp=@0xbfe1b2b0, file=@0xbfe1b2ac, > mode=SetBG::SET_SCALE, bgcolor=@0xbfe1b2a8) at SetBG.cc:67 > ... > */ > > The display is opening fine. I'm running: > > gtk: 2.8.17-1 > glib: 2.10.2-1 > > (hmm, didn't notice that before,t he 2.8 vs 2.10 thing, could that be it?) > > Anyway, I've spent all night trying to debug this and weeks trying to > sort this problem out in my program. What is up with this, what can I > do? > > thanks all. > dave > > > > _______________________________________________ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-devel-list From jalaganapathy@tataelxsi.co.in Fri Jun 30 02:45:45 2006 Return-Path: X-Original-To: gtk-devel-list@gnome.org Delivered-To: gtk-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id DF5083B0105 for ; Fri, 30 Jun 2006 02:45:44 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30527-07 for ; Fri, 30 Jun 2006 02:45:41 -0400 (EDT) Received: from mail.tataelxsi.co.in (mail.tataelxsi.co.in [203.200.1.48]) by menubar.gnome.org (Postfix) with ESMTP id 39FF93B00B8 for ; Fri, 30 Jun 2006 02:45:39 -0400 (EDT) Received: from jalaganapathy (tataelxsi.co.in [203.197.169.80] (may be forged)) by mail.tataelxsi.co.in (MOS 3.7.4b-GA) with ESMTP id BRR48672 (AUTH jalaganapathy); Fri, 30 Jun 2006 12:17:02 +0530 (IST) From: Jalagandeswari G To: Subject: Installing Cairo1.1.6 Date: Fri, 30 Jun 2006 12:16:06 +0530 Message-ID: <006301c69c10$ddbbf3d0$321b320a@telxsi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal X-Junkmail: Blacklisted X-Mirapoint-Sig: mail.tataelxsi.co.in X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-0.964 tagged_above=-999 required=2 tests=[BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.558, TW_BP=0.077] X-Spam-Score: -0.964 X-Spam-Level: X-Mailman-Approved-At: Fri, 30 Jun 2006 18:07:05 -0400 X-BeenThere: gtk-devel-list@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: Development of GTK+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jun 2006 06:45:45 -0000 Hello All, While installing cairo-1.1.6 on FC3 i am getting following errors during configure I am using glib-2.11.1 $./configure checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking whether to enable maintainer-specific portions of Makefiles... no checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for style of include used by make... GNU checking dependency style of gcc... gcc3 checking how to run the C preprocessor... gcc -E checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking for a sed that does not truncate output... /bin/sed checking for egrep... grep -E checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking dependency style of g++... gcc3 checking how to run the C++ preprocessor... g++ -E checking for g77... g77 checking whether we are using the GNU Fortran 77 compiler... yes checking whether g77 accepts -g... yes checking the maximum length of command line arguments... 32768 checking command to parse /usr/bin/nm -B output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc supports -fno-rtti -fno-exceptions... no checking for gcc option to produce PIC... -fPIC checking if gcc PIC flag -fPIC works... yes checking if gcc static flag -static works... yes checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by g++... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking for g++ option to produce PIC... -fPIC checking if g++ PIC flag -fPIC works... yes checking if g++ static flag -static works... yes checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate appending configuration tag "F77" to libtool checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes checking for g77 option to produce PIC... -fPIC checking if g77 PIC flag -fPIC works... yes checking if g77 static flag -static works... yes checking if g77 supports -c -o file.o... yes checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking for ANSI C header files... (cached) yes checking whether byte ordering is bigendian... no checking for vasnprintf... no checking for cos in -lm... yes checking for pkg-config... /usr/bin/pkg-config checking pkg-config is at least version 0.9.0... yes checking for cairo's xlib backend... checking for XRENDER... Package xrender was not found in the pkg-config search path. Perhaps you should add the directory containing `xrender.pc' to the PKG_CONFIG_PATH environment variable No package 'xrender' found checking X11/extensions/Xrender.h usability... no checking X11/extensions/Xrender.h presence... no checking for X11/extensions/Xrender.h... no checking for XrmFinalize... no checking whether cairo's xlib backend could be enabled... no (requires Xrender http://freedesktop.org/Software/xlibs) checking for cairo's win32 backend... checking whether cairo's win32 backend could be enabled... no (the Microsoft Windows backend requires a Win32 platform) checking for cairo's png backend... configure: WARNING: Could not find libpng in the pkg-config Can any one please post a solution for this. regards, Jala The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s)and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender or administrator@tataelxsi.co.in