Printing and blocking ui
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 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ 2.10, the endgame
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 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ 2.10, the endgame
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 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Imagine: what if points in Bugzilla had a significant effect?
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 [EMAIL PROTECTED] or call Skype ID jasonspiro. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ 2.10, the endgame
I'm also concerned about the recent files stuff. Do we now have UIManager integration of that? -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ 2.10, the endgame
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 [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GObject extension propose (GContainer)
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___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GObject extension propose (GContainer)
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 <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> The universe is always one step beyond logic ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
gslice allocator: general impresions.
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 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Imagine: what if points in Bugzilla had a significant effect?
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 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GObject extension propose (GContainer)
> 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 long 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 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Imagine: what if points in Bugzilla had a significant effect?
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 [EMAIL PROTECTED] 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" ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GObject extension propose (GContainer)
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 long 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 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Pango-1.13.2 released [unstable]
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 signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Pango memory leak in get_ruleset() in modules/basic/basic-fc.c
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. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Imagine: what if points in Bugzilla had a significant effect?
Lary Osterman has a nice writing on this topic titled "Measuring testers by test metrics doesn't." У čet, 15. 06 2006. у 19:15 +, 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 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
