Re: Print dialog hangs for several seconds before activating
> It appears that the only sane way to interact with CUPS in a GUI application > is to use separate threads. At last look, CUPS was not thread safe, not even if you only interact with CUPS through one thread. Morten ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [PATCH] gdk/gdkpixmap.[ch]: state constness of `data` in create pixmap routines
> The public interface for the following routines are affected by the
> patch, however this should not affect any software calling into the GDK
> library.
What do you build that assertion on?
Have a look at the program below. With "const", the
second "foo" call causes gcc to complain over types.
Also, code assigning the address of any of the affected
functions to variables will become invalid.
Morten
static void
foo (const char **x, int n)
{
const char *y = x[0];
(void)y;
}
int
main (int argc, char **argv)
{
const char *x1;
foo (&x1, 1);
char *x2;
foo (&x2, 1);
return 0;
}
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk_widget_draw()
> Here's an email detailing my thought process for what I want to do > with rendering in the master branch following the rendering-cleanup > merge. It's mostly a brain dump, so treat it as such. Assuming you managed to get all that done, how much time do you think it would be reasonable to set aside for upgrading applications? IMHO, anything less than a few months (as measured from the last significant API break to Gnome 3) is disrespectful of application writers. Morten ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: freezing for GLib 2.26
> I plan on branching glib-2-26 early next week and removing GApplication > (and related classes) from the branch. GDateTime still has API issues. g_date_time_new_full does not have enough arguments to uniquely identify a time. For example, one of these is going to be mistaken for the other: # TZ=US/Eastern perl -e 'print scalar localtime 1289109599, "\n";' Sun Nov 7 01:59:59 2010 # TZ=US/Eastern perl -e 'print scalar localtime 1289113199, "\n";' Sun Nov 7 01:59:59 2010 Morten ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkBin as a publicly derivable abstract class please.
>> Today I found '_gtk_bin_set_child()' > > what's wrong with gtk_container_add()? If _gtk_bin_set_child was needed to subclass GtkBin inside gtk+ then it is just as needed outside. So your question should really be answered with the counter question of "why is gtk+ not using gtk_container_add?" Out-of-tree widgets should not be second-class citizens. Morten ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkApplication and argc/arv
> There are many other reasons to not use single instance. I agree. d. Running on a different $DISPLAY. Look and you'll find no end of complaints over firefox' inability to do this sanely. e. Running with different locale settings. This happens for Gnumeric when people want different decimal separator for different files. f. Limiting what documents script see. > If GtkApplication can not turn off single instance, > I will not use it when I do not need single instance. Ditto. Or I'll create an id like gnumeric-$PID What actual problem was solved by all this infrastructure to keep just one instance? Morten ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkApplication and argc/arv
On Thu, Feb 24, 2011 at 5:55 PM, Colin Walters wrote: > On Thu, Feb 24, 2011 at 5:15 PM, Morten Welinder wrote: > >> What actual problem was solved by all this infrastructure to keep just >> one instance? > > Basically for any application which manipulates private files in any > form (in Firefox' case, this is the history database), it avoids data > corruption with uncontrolled access by multiple processes. That's an excellent reason for making single-process available, but not an argument (either way) for making it the default. It certainly doesn't sound like a problem experienced by, say, evince. What is the GtkApplication solution to dealing with different environment variables, including DISPLAY and LANG? I believe the single/multiple instances is a decision for the developer and not one Gnome or Gtk should have an opinion on. Morten ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Reviewing Win32 Patches
Any chance of getting reviews of patches for Win32 bugs? https://bugzilla.gnome.org/show_bug.cgi?id=614920 https://bugzilla.gnome.org/show_bug.cgi?id=619564 https://bugzilla.gnome.org/show_bug.cgi?id=617874 Morten ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkApplication and argc/arv
> What global state, for instance? locale? As a reminder, setlocale is not thread-safe. M. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkApplication and argc/arv
> Sorry, I don't understand. Could you explain in more detail? If you need to run two different windows in two different locales, then single-instance is not possible. For Gnumeric this happens regularly due to the world's decimal separator mess. The reason you cannot do this in a single instance is that (a) setlocale is not thread safe, and (b) libraries like gtk+ like to start their own threads out of your control. > Why would > two separate instances (separate processes) of the same app care if > setlocale is not thread safe? They wouldn't. I didn't mean to imply that. Morten ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
clipboard_get_timestamp
Once code starts looking like an #ifdef soup it might be time to introduce
a method on, say, the window object.
IMHO, of course.
Morten
#ifdef GDK_WINDOWING_X11
if (GDK_IS_X11_WINDOW (window))
{
timestamp = gdk_x11_get_server_time (gtk_widget_get_window
(clipboard_widget));
}
else
#endif
#if defined GDK_WINDOWING_WIN32
if (GDK_IS_WIN32_WINDOW (window))
{
timestamp = GetMessageTime ();
}
else
#endif
#if defined GDK_WINDOWING_BROADWAY
if (GDK_IS_BROADWAY_WINDOW (window))
{
timestamp = gdk_broadway_get_last_seen_time (window);
}
else
#endif
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Crashes with long words in strings passed to gtk_widget_set_tooltip_text()
> If you really want to safely pass a very long text, > you will have to know the font (family and size) then check with stuff > like pango_layout_set_text() and pango_layout_get_pixel_size(). This happened in Gnumeric at some point too. Basically, every time user supplied string make it into tooltips, this will happen. So it's probably better to fix this in gtk+. M. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: About gsettings aborting on unkown schemas
> you can say that all you want, but it's absolutely *not* a bug. Of course it is. With this bug, programs crash where they other- wise could limp on. It's like changing all g_return_if_fail calls into asserts -- after all, any time one of those hits it represents a bug somewhere. My log files suggest that "all the time" is a good approximation of how often that happens. It is absolutely not like missing your main ui file. You can't limp on from that in a meaningful way. And note, that in the gconf age handling this was not a problem at all. This bug makes it hard to keep multiple versions of a program installed without making settings per-version which has its own problems. If a setting is ever removed, the old version won't run. Morten ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: About gsettings aborting on unkown schemas
> The core principle that allows most functions to "always succeed" is
> that programming bugs are not "thrown," they just terminate the
> program.
Havoc, the data doesn't agree with that assertion.
Let's look at numbers:
glib, number of not-crashing on programmer errors:
# find glib -type f -name '*.c' -print | xargs -n100 grep -E
'g_return_(val_)?if_fail' | wc -l
1509
glib, number of crashing on programmer errors:
# find glib '(' -type f -name '*.c' -print ')' -o '(' -type d -name
tests -prune ')' | xargs -n100 grep -w -E 'g_assert|g_error' | wc -l
213
gtk+, number of not-crashing on programmer errors:
# find gtk '(' -type f -name '*.c' -print ')' -o '(' -type d -name
tests -prune ')' | xargs -n100 grep -w -E 'g_return_(val_)?if_fail' |
wc -l
5637
gtk+, number of crashing on programmer errors:
# find gtk '(' -type f -name '*.c' -print ')' -o '(' -type d -name
tests -prune ')' | xargs -n100 grep -w -E 'g_assert|g_error' | wc -l
693
So the overwhelming conclusion is that glib and gtk+ handle programmer
errors by issuing a "critical" and returning. Not by crashing.
It tips even more in that direction when you realize that a good
fraction of the crashing calls do not actually catch (library user)
programmer errors, but problems more in the memory-corruption
department.
We know that not having the schema around is not good. Going postal
and killing the program is not the solution.
Doing a g_return_val_if_fail is fine here. That will give the user a
chance of saving his work. This is in contrast to g_error which is a
sure way of eating data.
Morten
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Leakage of Toolbar-Related Menu Items
Currently Gtk applications leak quite a lot when menu items are created for GtkToolItems. This is because circular links prevent the tear-down: +---+ (menu_item)+---+ (child)+-+ |GtkToolItem|--->|GtkMenuItem|--->|GtkAccelLabel| +---++---++-+ ^ | | (accel_widget) | +-+ (That is going to look weird unless you use a fixed-width font.) GtkToolItem is not a GtkWidget, so it doesn't receive the "destroy" signal that normally helps tear down circular links. This is bug 645483 with no responses. I have contacted the author who introduced the circularity, jpeter...@openismus.com, but I have received no response. The question is what should be done about this. 1. Make the accel_widget link a weak ref. 2. Declare a destroy signal on GtkToolItem and make sure it gets sent by containers of such items, i.e., something parallel to GtkWidget's destroy. 3. Destroy the menuitem in GtkToolItem's dispose handler. (And in one other place where we disown the current menu item.) I don't really like version 1 because there are simply too many reasons why the menu item would have extra refs. That is, it would not work in general. Other options? Morten ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLib "next cycle" update
> Unfortunately this is a pragma Will C99's _Pragma help? That can be put in a macro. M. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Glib Atomic Operations
> what is the purpose of '(void) (0 ? *(atomic) ^ *(atomic) : 0)'? Poor man's type check. That expression isn't valid for every possible "atomic". M. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: experimental gtk+ 3.3.2 win32 build
> In general, we are interested in improving the situation with respect to > Windows builds. Perhaps then you could take care of bug 614920 (gtk redefines a system structure type). Obvious patch in comment 4. Morten ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: glocal - automatically freeing memory when it goes out of scope
> if (1)
> {
> glocal_object GFile *file = g_file_new_for_path ("/tmp");
> glocal_string gchar *basename = g_file_get_basename (file);
> g_debug ("Basename is '%s'", basename);
> // look ma' no leaks!
> }
This is, of course, cute but I don't think this would actually catch many of the
non-trivial leaks that make it into the code base today. Those are typically
not scope based -- possibly because the attention span of the average
programmer is long enough to cover the writing of a whole function, ;-)
The current serious leak cases I see are:
* The dispose or finalize method of an object type fails to free some
stuff. This is
quite common.
* Cyclical links. The resulting leaks are typically quite big.
A case scope-based destructors would handle is this:
* Multiple return statements, typically for error handling, where one or more
branches forget to free stuff. Cursory valgrinding doesn't catch this because
the code doesn't get exercised.
The case isn't uncommon, per se, but programs don't hit the cases often.
M.
PS: The situation where scope-based destruction is important is for languages
such as C++ with exceptions in use. C with GObject is not such a language.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GObjectClass.dispose and bringing objects back to life
> What we probably also should do is deprecate one of the two > virtual functions, so people use the same one to clean up everywhere. That would be a _really_ bad idea. _finalize gets rid of the last fragments of the object. Since random code could have obtained refs to the object, the object designer can generally not control when this happens. _dispose has two functions: (1) break reference cycles by getting rid of as many objects as it can, and (2) getting rid of externally- visible parts of the object and subobjects it owns. (2) tells you why you can't merge the two methods. Widgets, for example, really need to go away from the screen when you tell them, not whenever something else decides to release a ref. Objects that have open files really need to close them at dispose time, not next Wednesday. Gtk1 didn't have dispose in name, but it had the destroy method instead. Same thing. > [...] we [...] know that trying to support objects functioning > after dispose is like trying to make your code handle > NULL returns I don't think we know that, not do I think it's true. Making _dispose work really comes down to following one simple rule: after _dispose, the object should be as well defined as it was after _init. I.e., anything you free you set to NULL and you don't free anything that was allocated in _init[*]. M. [*] Unless you allocate a new dummy object to put in its place. That wouldn't make much sense unless you have big trouble with circular references. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GObjectClass.dispose and bringing objects back to life
Benjamin Otte wrote: > But then I looked at [gnumeric] and I realized > it doesn't do anything of that. So I'm inclined to think that what > you're talking about is more about an ideal world that you wish we all > aspired to, but is not in any way related to how people write code in > the real world. We take bug reports. We even fix bugs. I cannot really use pointing 400k lines of code for anything, so throw me a bone -- a class name, for example -- and I can actually do something. (And if you just meant to throw a few insults my way, well I hope you feel better.) M. (not quite an angel himself) ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GMenuModel has landed
Will the new api allow one to write a gui that looks and feels like it was made with the old api? Thanks, Morten ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: How GTK styling works
> 7) Ditch theme engines I like it! No more insanely weird bugs that eventually get tracked down to a theme engine doing things wrong. (Weird as in: the last thing people think of when, say, floating-point numbers get truncated, is that the theme has changed part of the locale.) I hope you realize how big a job you are getting yourself into, :-) Or that you have made sure you'll get properly paid. M. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gir stability
This seems like a minor issue compared to GtkGrid 3.0 vs GtkGrid 3.2 incompatibilities. A could of attributes got swapped in-between those two versions. Morten ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: next steps for touch support in GTK+
> === 4. Which GTK+ widgets break with touch === > The SpinButton item from above is one example of those. I really hope the solution is neither "remove anything that doesn't work with touch" or "parallel widget hierarchy". GtkSwitch bugs me. It really should just have been a styling of the toggle button since it performs the same function with a different look. But no, it is currently a totally separate widget not even derived from GtkButton. M. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: next steps for touch support in GTK+
On Sat, Aug 4, 2012 at 3:44 AM, Emmanuele Bassi wrote: >> GtkSwitch bugs me. It really should just have been a styling of the toggle >> button since it performs the same function with a different look. > > it does not "perform the same action". That is a baseless assertion. Of course it does. And stop misquoting me, please. We're talking about two widgets that are both used to turn something off or on. And nothing else. How is that not the "same function"? In other words, is there a place where one of them is used that would not function right if the other one was substituted? > as a side question: do you think that I, and everyone who reviewed > that patch, is stupid and doesn't know about the existence of > GtkButton? Nope, I don't. M. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Guidelines for stable branch changes in GLib/Gtk
The breaking of mouse wheel support in gtk+ 3.4 also comes to mind. (Bug 675089 and others, I'm sure.) Morten ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Guidelines for stable branch changes in GLib/Gtk
> If I'm not mistaken, this was a different kind of breakage that > we engage in a lot of lately: API-incompatible changes on the > unstable branch. Close, but not quite. This was a case of "user updates gtk+ to new stable 3.x and applications cease to work". No API involved, it's all a matter of ABI. The normal mechanism to signal ABI changes is to admit it and change soname. However, that is so painful[*] that people get the urge to sneak little changes in here and there. Morten [*] So painful that the g++ people backed out a change to std::list required for standards compliance in order to avoid changing soname. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Function pointer casts
> This code casts GCompareFunc to GCompareDataFunc. As I understand, casting > function pointers in C is not allowed. You're right, of course, but considering that the signal code depends heavily on casting function pointers with no obvious completely standard-sanctioned substitute, there's really no reason to single out this particular cast. In practice it works just fine anyway where you are likely to get glib/gobject to run anyway. The same problem occurs in any code using dlsym, such as GModule. To use that you need to cast a data pointer to a function pointer which isn't allowed (unless the thing you cast is a null pointer constant and then it isn't really that interesting). Morten ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: bugzilla cleanup
> It can be "easily fixed" in the sense that every application also would then > need to be fixed... Behdad, you're sitting in your ivory tower and throwing mud at suggested patches from people who suffer from this bug. What is the point of that? In the meantime, as Krzysztof points out, GOption simply doesn't work on Win32. I stand behind the original five-year old patch. The biggest complaint against that seems to be what to name one of the functions. Note, that there are other large parts of glib, such as gio, that have basically don't work on win32. And have five-year old patches in bugzilla. Morten ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Stock Items Deprecation
> Is there some way, as with GtkUIManager, to merge in, and later remove > and replace, menu items? I used this with GtkUIManager to dynamically > populate a menu with items not known at compile time. Specifically, how does one create menus like Firefox's History and Bookmarks menus which have dynamic contents? Or gedit's Documents menu? Morten ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: symbolic icon fallback failure
> rsvg-base.c:2194:5: error: implicit declaration of function > 'canonicalize_file_name' This patch (used for Win32, but there isn't anything win32 specific in there) with minimal editing should get you going. https://git.gnome.org/browse/gnumeric/tree/tools/win32/patches/librsvg-portability.patch On Sun, Nov 24, 2013 at 8:04 PM, Patrick Welche wrote: > On Sat, Nov 23, 2013 at 03:14:47PM -0500, Matthias Clasen wrote: >> On Sat, Nov 23, 2013 at 12:12 PM, Patrick Welche wrote: >> >> > On Sat, Nov 23, 2013 at 04:04:08PM +0100, Milan Bouchet-Valat wrote: >> > > Just a random guess, but are you sure Gdk was built with SVG support >> > > enabled? You need librsvg, and sometimes it happens to be missing (or >> > > not found) >> > >> > That was what I was worried about in: >> > >> > https://mail.gnome.org/archives/gtk-list/2013-November/msg00015.html >> > >> > "I have libpixbufloader-svg.so and an svg entry in loaders.cache." >> > >> > Given that there were no replies, I assume that that is the complete >> > checklist. >> > >> >> Your librsvg may be too old to render symbolic icons. See >> >> >> https://git.gnome.org/browse/librsvg/commit/?id=b864307868d3977dfa5e127ff95d7efded854850 >> >> and the bug referenced there. > > Indeed: I am using librsvg 2.36.4 as per the referenced email. I just had > a go at building 2.40.1, but: > > rsvg-base.c:2194:5: error: implicit declaration of function > 'canonicalize_file_name' > > ? > > Cheers, > > Patrick > ___ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: symbolic icon fallback failure
> Actually - what's wrong with posix realpath() ? In my case, not available. And if the aim is portability, see BUGS in the man page. M. On Mon, Nov 25, 2013 at 3:54 AM, Patrick Welche wrote: > On Sun, Nov 24, 2013 at 08:31:21PM -0500, Morten Welinder wrote: >> > rsvg-base.c:2194:5: error: implicit declaration of function >> > 'canonicalize_file_name' >> >> This patch (used for Win32, but there isn't anything win32 specific in there) >> with minimal editing should get you going. >> >> >> https://git.gnome.org/browse/gnumeric/tree/tools/win32/patches/librsvg-portability.patch > > Actually - what's wrong with posix realpath() ? > > Cheers, > > Patrick > ___ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLogLevelFlags enum and g_log
> enum GLogLevel {
>... existing, expected values ...
>_require_int = INT_MAX
> }
That actually makes the whole thing undefined rather than implementation
defined by section 7.1.3 in C99.
M.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Heads-up: Potentially breaking changes to the GDK drawing model pushed
Argh! Will the stream of ABI changes never end? Gnumeric uses this to provide a walking-ant cursor large selected areas -- areas too big for processing in the normal paint loop. Morten On Fri, Jun 20, 2014 at 9:00 PM, Jasper St. Pierre wrote: > To better support Wayland with fewer copies and less drawing artifacts, I've > pushed some potentially breaking changes to GDK, namely around > gdk_cairo_create and gdk_window_begin_paint_region. > > https://git.gnome.org/browse/gtk+/commit/?id=d48adf9cee7e340acd7f8b9a5f9716695352b848 > https://git.gnome.org/browse/gtk+/commit/?id=be30e440c350f0f3e0f2572f7f3eab54ef96af0e > > With these changes, it is now illegal to call gdk_cairo_create outside of a > begin_paint / end_paint. This was always sketchy, and would never work on > Wayland anyway. If your code does this, we will print a warning and return a > dummy surface which won't ever be composited back into the main surface. > > Additionally, it is now forbidden to call gdk_window_begin_paint_region more > than once. Previously, the code had a "paint stack" which tracked paints, > but since GTK+ never used this codepath it was never actually tested and was > indeed broken on Wayland due to the way the Wayland backend was written. > Again, we will print a warning in this case and return. > > As part of these changes, gtk_widget_set_double_buffered was deprecated and > removed. Again, it will never work on Wayland, as that is natively > double-buffered, and it would simply break there. > > I tested with some local big applications like Ardour and the GNOME > applications, but don't have a GTK+3 build of Firefox, LibreOffice, Eclipse, > or any big GTK+ apps like Inkscape or The GIMP. > > Please double-check to make sure your apps still work fine. If you have a > problem with any of this or I broke your apps by accident, please reply and > I'll try to fix it. > > Thanks! > > -- > Jasper > > ___ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/gtk-devel-list > ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Heads-up: Potentially breaking changes to the GDK drawing model pushed
For the record, the use of gdk_cairo_create outside of a begin_paint_region / end_paint pair also seems to work fine on win32. Morten On Mon, Jun 23, 2014 at 6:02 PM, Jasper St. Pierre wrote: > Hey everyone again > > I wasn't expecting this much fallout from the change. I was hoping most of > the GTK+ applications were only using widgets and draw signals. I was wrong. > > I've effectively pushed a revert of these changes: > > https://git.gnome.org/browse/gtk+/commit/?id=984e811c16891cb4945a090bea8ec9e81ce3dba6 > https://git.gnome.org/browse/gtk+/commit/?id=24b9e91f470d2f355c6e19013f302295151baacf > > Note that gtk_widget_set_double_buffered is still deprecated, and calling > gdk_cairo_create outside of a begin_paint_region / end_paint is still > considered legacy and isn't guaranteed to work on any backends other than > X11. Everything should be functioning correctly. So, we're choosing to make > these things work for X11, but new backends like Wayland, Broadway and Mir > might not work with them. > > If your application still has flickering or prints runtime warnings or > crashes, *please* let me know. We should be back to where we were > beforehand, but things do sometimes slip through the cracks. > > Thanks to everyone who gave me feedback -- it's been a frustrating past few > days for everyone, and I'm sorry for the breakage I caused. I have a much > better handle on the situation now and the way applications are using our > toolkit. > > If you have any other feedback about modern drawing in GTK+, please let us > know. We're always trying to support application developers, even if it may > not seem like it, and if our existing APIs aren't suiting your use cases, we > need to know. > > > On Fri, Jun 20, 2014 at 9:00 PM, Jasper St. Pierre > wrote: >> >> To better support Wayland with fewer copies and less drawing artifacts, >> I've pushed some potentially breaking changes to GDK, namely around >> gdk_cairo_create and gdk_window_begin_paint_region. >> >> >> https://git.gnome.org/browse/gtk+/commit/?id=d48adf9cee7e340acd7f8b9a5f9716695352b848 >> >> https://git.gnome.org/browse/gtk+/commit/?id=be30e440c350f0f3e0f2572f7f3eab54ef96af0e >> >> With these changes, it is now illegal to call gdk_cairo_create outside of >> a begin_paint / end_paint. This was always sketchy, and would never work on >> Wayland anyway. If your code does this, we will print a warning and return a >> dummy surface which won't ever be composited back into the main surface. >> >> Additionally, it is now forbidden to call gdk_window_begin_paint_region >> more than once. Previously, the code had a "paint stack" which tracked >> paints, but since GTK+ never used this codepath it was never actually tested >> and was indeed broken on Wayland due to the way the Wayland backend was >> written. Again, we will print a warning in this case and return. >> >> As part of these changes, gtk_widget_set_double_buffered was deprecated >> and removed. Again, it will never work on Wayland, as that is natively >> double-buffered, and it would simply break there. >> >> I tested with some local big applications like Ardour and the GNOME >> applications, but don't have a GTK+3 build of Firefox, LibreOffice, Eclipse, >> or any big GTK+ apps like Inkscape or The GIMP. >> >> Please double-check to make sure your apps still work fine. If you have a >> problem with any of this or I broke your apps by accident, please reply and >> I'll try to fix it. >> >> Thanks! >> >> -- >> Jasper > > > > > -- > Jasper > > ___ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/gtk-devel-list > ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: A Gtk's build system ?
I should hope not. Autotools is indeed the worst possible solution, except for all the others. (With apologies to Churchill.) But it exists and it is a known quantity. It solves problems like generation of tar balls, checking that the tar balls actually work, running test suites, checking translation completeness, handles cross- compilation (to a point), multiple architectures, parallel builds, etc. Hard stuff. (It also handles hardware last observed in the late 70s, but you aren't harmed by that.) I really do not see a need to sink time into replacing all that. Especially not if the simplification consists of using the ostrich approach -- "*I* don't have that problem so it is not important." Re your specific concerns: linux, osx, win32 all have the unix tools; there ought to be a macro provided to find glib-compile-resources; with counceling you will get over the ugliness. Morten On Tue, Aug 5, 2014 at 9:35 AM, Victor Aurélio Santos wrote: > Hi folks, > > Is there a plan to write a new build system or use another existing > build system for Gtk instead of Autotools ? > > I ask this because autotools is something "not good enough" for me. > It's syntax is ugly and bad to remember, the platform that will run > autotools requires a UNIX tool-set (sh, make, etc...), there's no > support to glib's features like resources the developer have manually > find the glib-compile-resources executable and write rules to build > the resources, and so on. > > I also think that Gtk should have something "Gtk's build system", Like > Qt's qmake. > > If not, do anyone know if GNOME plan this ? > Note that jhbuild is not a build system, it's more a "build bot". > > Thanks, I'll be happy to hear your plans and pros/cons of move to > another build system. > -- > Victor Aurélio Santos > ___ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: a new combo box
Can we keep the api -- function names, etc.? I.e., could we, for once, do such an upgrade without inflicting pain on the users? Even at the cost of some pain for developers. Morten On Sat, Dec 27, 2014 at 4:29 PM, Matthias Clasen wrote: > On Sat, Dec 27, 2014 at 12:59 PM, Tristan Van Berkom > wrote: > >> >> It's really not that bad, combobox is currently < 6k lines of code which >> is really not much for all that it does, sure we could afford to do a >> bit less (like dropping the crazy tabular menus). > > Tbh, thats only true after your shoved off 2000+ lines to gtktreemenu.c. > >> Honestly I would have rather proposed to just switch the whole internals >> of combobox to do the more modern looking thing using cell areas, which >> strikes me as the obvious way forward, bringing a new look to the combo >> without dropping any of the value of combobox, and every app using >> combobox automatically benefits - only that it would probably result in >> breaking API. >> >> Frankly I don't appreciate this let's rewrite everything from scratch >> attitude, it doesnt show a whole lot of respect to the users of our API, >> who would, I think have a justifiable expectation that their usage of >> combobox would not be labeled as obsolete at least until GTK+ 4. >> >> Sure, exceptions can be made within reason for dropping huge important >> parts of GTK+, but let's stick within reason right ? Has this been >> discussed ? Has it been concluded that there is no way forward with >> the existing API ? Where is that discussion ? What is the rationale ? > > Thats one of the hardest questions, isn't it ? > > Deciding when a codebase that you've invested a lot of time and effort > into has grown too old and complex, and it is better to start from > scratch ? I'm often struggling with this, and stick to fixing things > up to 'preserve existing investment' far too long. Of course, starting > over is not a panacea: you may end up repeating old mistakes, and do a > lot of work just to end up in the same place you started from. On the > flip side, its a chance to revisit old assumptions that are deeply > embedded in the old code, add modern features without having to > force-retrofit them into ancient code (and cause collateral damage in > the process). > > That being said, I think the case for GtkComboBox is pretty clear-cut. > It was doomed from the beginning by the mistake to force two pretty > distinct user experiences (option menus and combo boxes) into a single > widget. You've made a valiant attempt to clean this up with the > introduction of GtkTreeMenu, but it is still a mess. Another mistake > was to expose a data-driven API (with models and cell renderers) for a > widget that most of the time is used in non-data-driven scenarios. > We've later tried to patch up that mistake by adding the simplified > GtkComboBoxText. But since it is a subclass, it inherits all of the > api problems of GtkComboBox. Lastly, there's a number of ill-advised > APIs in GtkComboBox that make it very hard to do any new > implementation of the same api: tabular menus, spanning columns, etc. > Almost as if to prove the last point, your last major refactoring of > GtkComboBox already broke a bunch of those APIs (e.g. col-span-column > is not working anymore). > > You'll be happy to learn that the "buildable API" of GtkCombo is > pretty close to compatible with GtkComboBoxText (I should probably > rename the active property to active-id to get even closer), so for > most users, switching from GtkComboBoxText to GtkCombo should be as > simple as s/GtkComboBoxText/GtkCombo/ in their ui files. > > Since you are asking about discussions and conclusion, I'll state that > in my opinion, combo boxes should not use (even less expose in the > api) cell renderers and tree models. I believe that is pretty much > agreed upon between most people who regularly touch GTK+ code (with > the exception of you, possibly). Speak up if you disagree. > ___ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: a new combo box
This is the third (fourth) incarnation of a combo box and there is still opposition to keeping the API stable? That's just crazy. Matthias' awesomeness aside, why would this be the last time? Seriously, a change in a widget like this means 20+ hours[*] of extra work for me as an application writer. I have a lot of GUI to deal with, but say 10 hours is the average and look at 100 applications. 1000 hours of work that doesn't advance the functionality of the applications. If it took Matthias an extra 500 hours -- something like three months of his time -- it would still be better to use the old api. Or at least some variant for which the changes would be doable by search-and-replace. Morten [*] That's probably a low estimate. It not just finding all uses of the old and replacing with the new. It's debugging the application _and_ the new widget; filing bugs against the widget; writing work-arounds for the 2 years before fixes are made and distributed; it's tracking the API changes that are a consequence because a non-gtk library function that is based on the widget will now have new signals being fired -- no help from the compiler there. On Sun, Dec 28, 2014 at 9:07 AM, Matthias Clasen wrote: > On Sun, Dec 28, 2014 at 1:27 AM, Alberto Ruiz wrote: >> My main concern with the design is that users can't make a difference >> between a normal button and this widget (usually related to an action, >> perhaps with the exception of iconized menus like the ones we're using in >> headerbars these days). >> >> Is there any design rationale to remove the usual arrow? > > You should try the actual thing... I had the same question, and added > the arrow back > ___ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: a new combo box
> on the contrary: with a new class you'd be sure that the GtkComboBox > widget API is finally "stable" — as in "no changes, except for bug > fixes" — which is apparently what you want. There are three types of widgets in the gtk+ world: (1) active and non-deprecated, (2) deprecated, and (3) deprecated and removed. Application writers know that (2) is on the way to (3), even if gtk+ developers like to publicly say that isn't true. It's just that we have never observed anything else. So, no. I don't want the API stability in (3). And the "bug fixes" part for (2) is by and large PR. In the real world, it doesn't happen and I am regularly reminded of this when 10 year old bug reports get closed wontfix or obsolete. Emmanuele, why are you so cavalier about inflicting pain and work on application writers? Morten ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: File monitor rewrite: Solaris (and other) help wanted
> My plan is to make it a guarantee of the API that both CREATED > and CHANGED events will always be followed by a CHANGES_DONE > hint. Great plan, but you cannot get that in a meaningful way. Think creat write mmap close # Further writes by way of the mapped region I don't think you can detect the end of that write. Morten On Thu, Jan 15, 2015 at 10:42 AM, Ryan Lortie wrote: > hi Aleksander, > > On Thu, Jan 15, 2015, at 06:28, Aleksander Morgado wrote: >> Currently GFileMonitor doesn't have a unique way to know whether a file >> got closed. There is the changes-done-hint event, but that covers IIRC 2 >> things: files getting closed and also a "virtual" emission which happens >> after some time even if the files were not closed (think of a log file >> which never gets closed). The main issue is that if you want to get >> notified of when a file was fully updated *and* closed, you need to >> fallback to raw inotify. The rationale for wanting to get notified only >> when the file got closed is e.g. Tracker monitoring the Downloads/ >> directory. We may not want to extract file info for an ongoing download, >> just for when the download is fully finished (and destination file >> closed). More background here: >> https://bugzilla.gnome.org/show_bug.cgi?id=635765 > > Short story: I want to add a flag to either disable or enable emission > of virtual changes-done hints on monitor backends that can reliably > handle it themselves. > > Even for fully-capable backends, I think virtual emissions are > potentially important because, even if the file is not closed, someone > watching it may want to update their opinion of its contents > periodically. The question is only about what the default should be. > Those who favour a nice clean API would say that virtual emissions > should be off by default. Those who favour backwards compatibility > would suggest that today's behaviour of virtual emissions should be kept > as-is unless explicitly disabled. I'm not sure what we will do. > > Unfortunately, there's a longer story: None of the backends support > reliable emission of non-virtual changes-done. > > Here's why: > > My plan is to make it a guarantee of the API that both CREATED and > CHANGED events will always be followed by a CHANGES_DONE hint. That's > already enforced in the state machine logic in GFileMonitorSource in the > branch. My reason for that is that apps like Tracker should not want to > response to CREATED events until the file content is complete. > > The idea (taking your download example) is that a file is created > something like so: > > creat() > write() > write() > close() > > which sends us IN_CREATE, IN_MODIFY, IN_MODIFY, IN_CLOSE_WRITE. > > As you mention, it doesn't make sense for the app to respond to the > empty (or maybe very slightly populated) download just because it saw a > CREATED event from GFileMonitor -- it should wait for the CHANGES_DONE. > Consider this case: > > creat() > close() > > in that case, we'd see IN_CREATE, IN_CLOSE_WRITE, with no IN_MODIFY. We > still want to see a CHANGES_DONE event in that case, though so that the > app knows that the empty file is the 'final result'. This is the basis > of my opinion that CREATED should always get a CHANGES_DONE after it, > even without actual CHANGED events. > > With the new support for move and rename events, a file created by the > "write to temp and mv into place" method will be reported either as > MOVED_IN or RENAMED with no CHANGES_DONE. That's okay, because you know > that a file that was MOVED_IN or RENAMED into place is ready to be > handled immediately. > > Unfortunately, there is another set of cases. IN_CREATE is sent both > for the creat() case (in which case it will be followed by > IN_CLOSE_WRITE) but also for cases like mknod(), bind() on a unix > socket, mkdir(), etc.. In those cases, we will receive no > IN_CLOSE_WRITE. We could detect that situation by looking at the > filesystem and seeing that the newly-created file is of a special type, > but link() also produces IN_CREATE without IN_CLOSE_WRITE. > > The only thing that saves us in this second case is that we get a > virtual emission of CHANGES_DONE a couple of seconds later. At least > link() is uncommon, although it stands to become a more common way of > creating files, via O_TMPFILE. > > In short, I believe that we currently don't have any backend for which > we could safely disable emission of virtual CHANGES_DONE events. > Ideally, in the future, we will gain a mechanism in inotify to tell the > difference between "file created via open for writing, IN_CLOSE_WRITE > coming soon" and "inode appeared in the file system in complete form". > At that point we could expose a new event type in GFileMonitor > (_APPEARED?) that doesn't need CHANGES_DONE to be emitted. > > Cheers > ___ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > https://mail.gnome.o
Re: File monitor rewrite: Solaris (and other) help wanted
That does leave tracker-like software in a bad position. Although I guess one could lobby the kernel people for an inotify event when a file is mapped and use it as a kind of a hint that the file should be revisited at some later point. Morten On Thu, Jan 15, 2015 at 10:51 AM, Ryan Lortie wrote: > hi, > > On Thu, Jan 15, 2015, at 10:49, Morten Welinder wrote: >> Great plan, but you cannot get that in a meaningful way. Think >> >> creat >> write >> mmap >> close >> # Further writes by way of the mapped region >> >> I don't think you can detect the end of that write. > > > Quoting inotify(7): > >The inotify API does not report file accesses and modifications >that may >occur because of mmap(2), msync(2), and munmap(2). > > so this is a completely lost cause anyway. > > Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: disabling the consuming of Ctrl+shift+f etc keystrokes
> You can enter Unicode hex codes with Ctrl-Shift-. So, to > enter an "á", which is U+00e1, hold down Ctrl and Shift, type > "e1" (that's E One), and release Ctrl-Shift. Potentially useful, very geeky. So you hold down a magic key combination and then enter an arbitrary base-16 number assigned by an organization with "code" in its name. (Almost: before you enter said arbitrary number you must first drop leading zeros, if any.) Oh, and type carefully because backspace won't work. How did that pass UI review? Morten ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Some g_get_language_names issues
> g_get_language_names() is a little saner here, it only reads > /usr/share/locale/locale.alias Bah. sane == the world is a vax? troll:~> ls -l /usr/share/locale/locale.alias ls: /usr/share/locale/locale.alias: No such file or directory troll:~> ls -l /usr/openwin/lib/locale/locale.alias -rw-rw-r--1 root bin 5294 Feb 19 2001 /usr/openwin/lib/locale/locale.alias M. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Pushing a NULL into g_async_queue
> consider the g_async_queue_try_pop() and g_async_queue_timed_pop() > functions. They will either return a value from the queue, or NULL if no > items exist. If you can store NULLs in the queue, then the result becomes > ambiguous. Just like g_hash_table_lookup. In other words, that problem has been dealt with elsewhere by adding new functions that can distinguish the situations when needed. For better or worse. Morten ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Compilation speed on Windows (was: Re: GTK+ for Windows MSVCRT dependency?)
I'll stick my neck out and guess that this is caused by the ill-executed gtkalias.h hack. Basically, any file that uses any gtk header will depend on every single gtk header file. And that's a lot. Morten ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Compilation speed on Windows (was: Re: GTK+ for Windows MSVCRT dependency?)
I'm not the guy who'll be doing that. For one thing, I won't be using gcc4 for another few years. I might be using gcc3 soonish, though. [If I pass a car of the highway that is lying upside-down, has its wind shield shattered, and one wheel missing, then I am going to call it broken even though I have no intention of fixing it. If then a parade of people come around and start telling me that the wipers or the head lights or whatever are not working, then I am going to call the car broken again, and I might even mention that I told the driver to slow down well in advance.] Morten (Grumpy today) ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: g_file_write()
Don't expect rename to delete the target file on Win32. (There goes the atomicity.) Checking with g_file_test and unlinking is asking for a race condition and lost target file in some circumstances. On unix this type of write will interact in interesting ways with hardlinks, permissions, file ownership, and non-writable directories. fdopen is a pita portability-wise, see below. I'd say go with the simple version you started with and leave the trouble to the caller. There are reasons that Emacs has a zillion settings for what to do. Morten - AC_CHECK_DECL(fdopen, fdopen_works=yes, fdopen_works=no) if test $fdopen_works = no ; then unset ac_cv_have_decl_fdopen CFLAGS="$CFLAGS -D_POSIX_SOURCE" AC_MSG_NOTICE([adding -D_POSIX_SOURCE to CFLAGS]) AC_CHECK_DECL(fdopen, fdopen_works=yes, fdopen_works=no) if test $fdopen_works = no ; then AC_MSG_ERROR([fdopen is not available]) fi fi # Unfortunately, -D_POSIX_SOURCE turns off struct timeval on Solaris AC_MSG_CHECKING([whether struct timeval is available]) AC_TRY_COMPILE([#include ], [struct timeval tv;], struct_timeval_works=yes, struct_timeval_works=no) AC_MSG_RESULT($struct_timeval_works) if test $struct_timeval_works = no ; then CFLAGS="$CFLAGS -D__EXTENSIONS__" AC_MSG_CHECKING([whether struct timeval is available with -D__EXTENSIONS__]) AC_TRY_COMPILE([#include ], [struct timeval tv;], struct_timeval_works=yes, struct_timeval_works=no) AC_MSG_RESULT($struct_timeval_works) if test $struct_timeval_works = no ; then AC_MSG_ERROR([struct timeval is not available]) fi fi ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: g_file_write()
fchmod if available? I don't think we care about the permissions being the same as the target file's while the file is being created. In fact, might be preferred. Morten ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: g_file_write()
Ack, you did use fchmod, sorry. Two things regarding the fork approach: 1. It is hideously expensive. 2. It is quite difficult to get right in a library. Consider: you fork, the child does its thing and exits, a signal handler you didn't know about waits on the child, and you call waitpid. If you are lucky, that waitpid just returns an error (ECHILD). Your code then accesses "status" which hasn't been set. If you are less lucky (aka the OS and the application programmer are out to get you), then the waitpid will hang waiting for another process. You can probably ignore this. waitpid can also fail for other reasons. A signal could cause EINTR, for example. (And then there is the usual should-have-saved errno comment. _() could have changed it.) Why 0666 and not 0777, btw.? One could conveniently write scripts this way. Tell me again why we want this function to be anything but the simple open+write+close? Morten ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GNOME 2.11/2.12 targeting GTK+ 2.8 (ie cairo based)
> - The benefit of having cool new rendering stuff in GNOME 2.12 Being cool never got any work done. > - The benefit of getting all this stuff tested early (i.e. before > GTK+ 2.8 is released, rather than after) We are talking a serious amount of new code that I have not tested, let alone run through Purify. Here's a prediction: it is not going to be pretty. > - The extra incentive for people to help with getting the rendering > stuff optimized I read that as "performance stinks unbelievably, but don't worry -- if we bother enough people surely someone will send us a hacky patch". The resident grouch's summary: there are NO BENEFITS that helps any user get any work done. There's a lot of fluff, though. Morten ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GNOME 2.11/2.12 targeting GTK+ 2.8 (ie cairo based)
Owen, the problem with gtk+/cairo in a stable setting is that it has only seen testing and been designed for "hello world". You need to consider something bigger! Try putting 600-1000 pango layouts on the screen at once. GTK+ 2.6 is already not very snappy with that. Then make sure your X server is not local so you get to suffer the roundtrips also. I would like to hear from you that this has been considered and perhaps even tested. We still have not gotten anywhere near the screen update speed we had in the 1.2 days. Wearing my application developer hat, I would say that using GTK+ 2.8 for the next Gnome is crazy. It isn't right to enlist the unsuspecting users as guinea pigs just because you are having trouble getting people to test. The Cairo integration was done prematurely and now we suffer. Glib 2.8, on the other hand, fine. That's not a revolution. It might as well get renamed back to 2.6.whatever. And btw., we still are not near a state where the file chooser is acceptable. The "save-as" mode really stinks while the "open" mode is only marginally acceptable. See http://blogs.gnome.org/view/mortenw/2005/05/25/1 for example. Morten ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GNOME 2.11/2.12 targeting GTK+ 2.8 (ie cairo based)
> For non-local servers without Render, Cairo will allow us to eliminate > the round-trips... a huge win. "Show me the money!" Back in the real world, new code goes in and someone files a performance bug. Then you, Owen, seem to take that as a personal insult and close it as NOTABUG or WONTFIX. Exhibit 1: bug 94718. A clear, to-the-point bug report that something (namely greying of toolbars) had gotten so much slower that it was a problem. It still is. Exhibit 2: bug 123538. Pango/GtkTreeview gets very slow with lots of data, a situation that "less" handled well a decade or two ago. I routinely use "less" on files larger than 1GB or with lines that are thousands of characters wide. While you didn't actually close this bug (we kept it under "Gnumeric") you seem to think I am outside what you designed for, hence my "Hello World" poke. Exhibit 3: bug 104683. General Pango performance with a patch that at the time cut 70% of cpu usage for the all-ASCII case (such as numbers) that Gnumeric uses heavily. You NOTABUG'd it *twice* (and "futured" it once) as evidently Pango's performance cannot possibly be problematic. I am somehow reminded of the word "attitude" reading these old, but still-open, bug reports. > Rendering speed is 90% an X server issue. I would normally define rendering speed as a measure of how fast you get your pixels on the screen. With that definition in mind, look at bugs 94718 and 104683 above and see that getting pixels on the screen got much slower with constant X server. The toolkit is much, much more than 10%. > We love you too, Morten. I am all cuddly. (Think Jack-Jack from a certain, recent animated movie.) M. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Garbage collection in Gtk
You cannot do mark-and-sweep gc with languages like C (and C++). You would have restrict yourself to some subset of the language. The problem is that you need to find all live pointers. Including those printed with fprintf (foo, "%p", ptr); and emailed to Australia. You also have to find those written in binary format to a file. You also have to find those pointers what a thread is in the middle of swapping byte-by-byte. Then there is shared memory, more an OS than a C concept, though -- you can have pointers there if you want to. And you could use ptrace to peek at a process' memory. Bottom line: garbage collection in full C is a pipe dream. I.e., stick to ref-count stuff. Morten ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLib 2.9.0 released
> - The Unicode tables have been updated to Unicode 4.1, > adding several new values to the GUnicodeBreakType > enumeration. This breaks Pango <= 1.10 > [Behdad Esfahbod] Whatever happened to API/ABI stability? What kind of changes to Pango 1.8 and 1.10 are we talking about? Morten ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLib 2.9.0 released
So what happens if I upgrade my glib without upgrading Pango? [I still do not feel like being a Cairo guinea pig.] Crash? Something fundamental stops working? Nothing I will ever notice? IMHO, such an upgrade is supposed to work. If it does not, then what does API/ABI stability mean? Morten ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLib 2.9.0 released
You guys are really avoiding the issue today. Has ABI/API stability been abandoned for this release (which might as well be called 3.0 and made a free-for-all, then)? > It is a bit unfortunate, but there is not much we can do about it. Hmm... Why do none of these count? 1. Don't do the change. 2. Have g_unichar_break_type always return what it used to and make a new function with the extended and extensible interface. > The problem is that Pango versions < 1.10.1 are not prepared for > this. Not entirely. the problem is that Pango took the function signature as asserted that the function followed it, modulo an off-by-one bug. In an ABI/API stable world that's not a terribly bad thing to do. Morten ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: warnings on ignoring return value on some list operations
It's remarkably non-trivial to say what "used" mean for this
attribute when your intention is to silence the warning.
Works:
do { if (func ()); } while (0);
func () || 0;
func () ? 0 : 1;
func () == 0;
!func ();
Does not work:
(void)func ();
func () || 1;
func () ? 1 : 1;
(void)(0 + func ());
(Assuming the result type is something that can be treated as a
boolean value. Apart from full structures that should be ok.)
Since this is probably compiler version dependent, we might need
a G_NO_REALLY_I_DONT_WANT_TO_USE_IT macro.
Morten
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: libegg/recentchooser
That code also needs to be run through Valgrind or Purify. egg_recent_chooser_item_activated_cb, for example, seems to have a double free. timestamp_from_iso8601 manipulates the environment in a way that does not look po[r]table. (And it's not that hard to do using mktime-in-any-timezone, basic arithmetic, or GDate.) M. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: libegg/recentchooser
> Uhm, I'll put that code under #idef G_OS_UNIX/#endif guards for the time
> being, but the getenv("TZ")/setenv("TZ") timezone trick should work on
> any sufficiently recent POSIX-like system; users of other operating
> systems might just drop me an email.
setenv isn't POSIX. You can probably just use g_setenv although
that will leak.
But really, just do it as
((days_since_19700101 * 24 + h) * 60 + m) * 60 + s
where days_since_19700101 comes out of GDate.
M.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
g_slice_
I might be dense, but what exactly does g_slice_ buy us over
plain, old malloc?
* Don't say speed. That's a bogus argument because you cannot
possibly have tested all mallocs.
* Don't say overhead for the same reason.
What do we pay?
* We have probably killed tools like Purify that know about malloc
specifically.
* We have more overhead now since both malloc and g_slice_ will
keep their own free pools.
* More code (now malloc and g_slice_), both likely to be kept
hot by the cpu cache.
I just don't see it. Trying to outdo an unknown malloc is hubris.
If you had wanted something marginally fancy, you could have taken
goffice's pool allocator. It comes with:
* Free leak detection support. You can iterate over leaked pieces.
* You can free a whole pool without freeing the pieces (but then
you cannot detect leaks, of course).
* O(1) ability to give back memory to the system when chunks become
free.
For better [speed] or worse, it isn't currently thread safe. That
could be trivial to add, though.
Morten
-
Unrelatedly,
why drop type-safety for the non-gcc case? Something along these
lines ought to work:
#define g_slice_free(type, mem) \
do { \
if (1) g_slice_free (type, mem); else (void)((type*)0 == mem); \
} while (0);
In the gcc case you need to supply a non-macro definition of g_slice_free.
Otherewise the resulting program is not valid, regardless of that
"while (0)".
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: g_slice_
It sounds to me that you had two pieces of code that sucked: the glib mempools and the glibc malloc. Well known. Both Gnumeric and Evolution wrote their own specialized pool allocators because of that. (Why two? Because we didn't know about each other.) I don't think I should compare slices to memchunks because that is not what I have been using. I have configuring with "--disable-mem-pools --enable-gc-friendly" for ages. Add in using a less bogus malloc and you have a better baseline. So my working Purify support is now gone. So my one piece of hot allocation code is now two. So I now have two, not one, allocators keeping seperate free lists. You could have avoided the memchunk bogosity by using the malloc- wrapping you introduced in early November. That would have been an obvious improvement with none of the downsides. Improving glibc's malloc would probably be a good idea too. Which brings me to... What data structures in glib programs (existing and predicted in the next few years) are (a) used multi-threaded, and (b) used often enough to warrant performance considerations? I see GList nodes, GSList nodes, and GHashTable nodes. Maybe that leaves out one of two, but the scale is right. This had better be what you are optimizing for. Not, for example: > - if you use n CPUs (n>1), you want to be able to allocate n times the > amount of memory of a single CPU per time interval, and not just be safe > against concurrent allocations > - if you consider one allocator per thread, take into account that chunks > may be allocated in one thread and freed in another Those are fine considerations. Just not for glib. Add to that, that the number of C programmers who can write working threaded applications is even smaller than the number of C programmers who can write code that doesn't leak enough to be a problem. You are not going to see many multi=threaded C applications using glib. And if threading is taking place in a higher language, it isn't clear that malloc is where you need the smarts. Morten ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK_FLOATING broken in 2.9?
> One could conceivably modify GTK_OBJECT_SET_FLAGS to do the right thing for > floating, but > direct setting/checking of the flag is not fixable. I.e., API stability takes another hit. And ABI stability must be even more shot. In this case the set of handlers that are being called has changed, if I understand things right, and GUI-visible effects are to be expected. For the record, Gnumeric (well, goffice) has a single use of this. Morten ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK_FLOATING broken in 2.9?
> before starting to investigate in ugly hacks to continue maintaining the > current GTK_FLOATING semantics with GtkObject, i'd really like to raise > the issue that people/langauge bnindings most probably never should be > setting GTK_FLOATING with GTK_OBJECT_SET_FLAGS. besides the obvious > implementation, the only case i saw so far where this was need is > in GtkMenu. Gnumeric's use is in go_combo_popup_reparent which pretty much mirrors gtk_menu_reparent. Note, that GTK_OBJECT_SET_FLAGS is a macro. Fixing it will not help programs compiled against, say, gtk+ 2.6 headers. If the user updates gtk+, the application breaks, i.e., no ABI stability. Do we _really_ need this ABI change or can it wait for gtk+ 3? Morten ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK_FLOATING broken in 2.9?
Could we at the type-level have a flag controlling whether the glib- level should create a floating ref or a pre-sinked ref? Anything derived from GtkObject could then set it to "pre-sinked" and GTK+ could do its own floating ref handling. That ought to ensure ABI compatibility, but would it do whatever it is that people want from floating refs? Morten ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Depending on C99
> could people please speak up if they think depending on C99 would > be a bad idea for glib & gtk+ (e.g. with the next major release) and > why this would be a problem for them? "Up!" Requiring C99 will kill gcc 2.95 support and Purify works far better with 2.95. Morten ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Proposition for platform maximum filename/pathname length symbols
> There is no single maximum length of a path name or path name > component that would be valid for all machines on which the binaries > corresponding so a certain GLib header distribution could be > installed. (Consider mounting "foreign" network file systems/shares, > etc.) I.e., it would be no worse than the current situation with G_FILENAME_ENCODING. M. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gnumeric on Scientific Linux
> I recently had occasion to build gnumeric (1.4.3) on a Solaris 7 box used as > a spectrometer controller. The dependency tree is a bit daunting, but > possible. > Details available (I took careful notes) - mailto:[EMAIL PROTECTED] The only reason you were able to do that is that I have been keeping Gnumeric and all its dependencies honest. I have been compiling on Solaris 2.8 for years. > For me, the most difficult piece to resolve was a very old (ancient) X running > on solaris, and the requirement for XFt and XRender. We did not use to require XRender. Could you check what is not requiring it, as opposed to just strongly suggesting it? Morten ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Typedef inconsistency for gsize and gssize
> size_t and ssize_t are supposed to be usable to hold pointer values > without loss Eh? >From C99, Section "6.3.2.3 Pointers": [#6] Any pointer type may be converted to an integer type. Except as previously specified,theresultis implementation-defined. If the result cannot be represented in the integer type, the behavior is undefined. The result need not be in the range of values of any integer type. (The "previously" seems to refer to null pointers.) But, yes, glib uses non-standard C in lots of ways, this just being one of them. M. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk+ print support - request for feedback
What's the status of thread safety? Last I looked at cups it was not thread safe due to calling setlocale, and there was little understanding as to why that was a problem. (And recall that just about any gtk+ program is at least minimally threaded.) Morten ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk+ print support - request for feedback
> The man page for setlocale() says nothing about thread safety, but > given how all of the other standard C calls work I'm frankly shocked > that setting the locale in one thread affects the others. Is this > just a bug on Linux, or is it a general problem on other operating > systems? Solaris' man page says... - NOTES To change locale in a multithreaded application, setlocale() should be called prior to using any locale-sensitive rou- tine. Using setlocale() to query the current locale is safe and can be used anywhere in a multithreaded application. - Note, that the effect is not just that the other thread might see a locale changed. Pointers they got from localeconv or setlocale might turn invalid underneath them. Or code they were running might be unmapped. (After all, shared libraries uses as plugins are a common way of dealing with locales.) The unfortunate effect is that sscanf is not going to be useful for a library. Unless you are willing to fork() but that comes with its own set of problems. M. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: using literal zero for NULL
> There's no way for the compiler to know that the sentinel is > supposed to be a pointer. It's simply implemented as a varargs > function. Maybe we should emphasize the importance of using NULL > in our documentation. This is where it would be a bit evil to mention that NULL might be defined #define NULL 0 and that using NULL therefore doesn't really help. (I.e., NULL is a null pointer, but does not have pointer type. Yeehaa!) So -- according to the standard -- what you must do is to call with the right type: foo (arg1, arg2, ..., (char *)0); In practice, for any system that glib will ever work on, however, NULL is just fine. M. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Unloading sequence of GTK
> If now someone's interested, we can talk about this again.
> GC is one of the major points I'd like to get in into glib3 ...
That cat is dead. You cannot do GC in C. And you especially
cannot do it in the slightly-extended C that glib is written
in.
What you can do is to have GC in certain subsets of C. But
before you go there, consider how you want to do without, for
example, printf("%p",...) and GPOINTER_TO_UINT. There is a
zillion ways you can hide a C pointer from the GC system,
intentionally or otherwise.
M.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: The printing work has been merged
> I don't understand why you would need a call to get the default printer > settings. Of course the dialog comes up with the printer defaults if you > do nothing special. If you want the document to show margins, page breaks and the like, you need the default settings. Morten ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Deprecations
... -Wcast-align ... That one will give you tons of warnings on some platforms with different alignments than i386. We do lots of GTK_NOTEBOOK(widget) type casts that are perfectly fine -- because there is an implied type check -- but can very well increase alignment. (GTK_NOTEBOOK is a sample. I don't recall which ones that actually barf.) M. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Reducing space between treeview rows
> Some time ago I posted to various gtk related lists about reducing > padding between treeview rows. The official word is that it cannot be done: || You probably want to set horizontal-padding and vertical-padding (both || GtkTreeView style properties) to zero (they are not zero by default). We can't || shave more space than that off. Now, if that is not good enough for you, what you need to realize is that GtkCellRendererText reserves space not only for what is in the cell, but also what you might one day put in there. Think "accented Chinese characters with a few underlines". What you can do is to go into gtkcellrenderertext.c's get_size and change pango_layout_get_pixel_extents (layout, NULL, &rect); to pango_layout_get_pixel_extents (layout, &rect, NULL); This might not be the right thing to do for all treeviews, but it sure improves the filechooser for me. The icons are then almost touching. M. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Reducing space between treeview rows
>> change >> >> pango_layout_get_pixel_extents (layout, NULL, &rect); >> >> to >> >> pango_layout_get_pixel_extents (layout, &rect, NULL); Even better: pango_layout_get_extents (layout, &rect, NULL); rect.width = (rect.width + PANGO_SCALE - 1) / PANGO_SCALE; rect.height = (rect.height + PANGO_SCALE - 1) / PANGO_SCALE; I.e., round up. > So this means that a custom cell render can achieve the desired effect. Yes and no. Yes, you can create treeviews that look as desired, but no, the existing file chooser is not going to get better. IMHO it would make sense to support this on the existing GtkCellRendererText with an extra [style?] attribute. There are a number of things to sort out, though, such as what to do in fixed-height. M. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Deprecations
> I also like if there was a way to detect when the required > version of a module (glib and Gtk+ mainly) should be increased in > an application. But that requires marking all the API with > macros and version number that I know is not going to happen... The "poor man's version" of that would be to take your library or executable and see if there is any overlap in required symbols and gtk.symbols[HEAD] - gtk.symbols[required] This will not catch macros and constants, though. M. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Reducing space between treeview rows
> If your goal is to just increase the number of files visible in the file > chooser's list [...] It isn't. And certainly not doing it by making the file chooser even larger! But while you are mentioning it, the file chooser's default size does not grow when you add widgets (such as file type and encoding selectors), i.e., the area for files shrinks. I have the same problem for Gnumeric's text importer. The lines in the preview treeview really have to use long distance phone service to talk to each other. M. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Solaris fopen issue
How about allocating your own file descriptors above 256, then? I.e., you would allocate them as usual (not using fopen, one assumes) and then dup them up to some unused descriptor up there and close the original. Morten ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkBuilder status
When Glade is used with a recent gtk+, it will write lots of properties that old gtk+ will not understand. Now if those properties were non-default that is unavoidable, but it is irritating that one cannot readily edit a glade file on a new system without hand-patching using Emacs afterwards. Can we avoid this problem with GtkBuilder? One way would be to not write properties with default value. That should cut down the file size quite a lot too. M. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Concerns about print preview implementation
> Why would an external app be slower, greedier, whatever than an > in-memory approach? MEMORY: The external application needs to be given the entire document, or else things like NextPage won't work. An in-memory approach could get by with having one page at a time generated. That is the difference between a couple of mega-bytes and a couple of hundred mega-bytes. If you could sort-of script the external viewer you might get the same effect and gain fault-isolation. That would be nice. CPU USAGE: Depending on interface, for the external approach you will probably have to render a lot of floating-point numbers to ascii and do the other way in the viewer. An in-memory approach would not have to do that. Try printing a million random floating-point numbers to a file and see how long time that takes. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Is GStringChunk still useful?
GStringChunk is fine. The problem with the case that Jeff highlights is that the strings inserted are long compared to the chunk size. In Gnumeric, we use a chunk size of 100k and strings typically 20 characters in the text importer. (All the substrings in a csv file, for example.) The waste is trivial in that case. So basically, GStringChunk is for when you have *piles* of little strings to store and malloc overhead is your concern. If Jeff really sees strings of ~.5k then malloc overhead is not important. If the strings are generally smaller, then it is perhaps just his chunk size that needs to be upped. Morten ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: bugs regarding late g_thread_init() calls
This leaves the question as to what macros it is safe to use before calling
g_thread_init.
I can look up the current definition of MIN and see, that yes it does
not involve
a function call, but that could change without notice in the next point release.
I guess that macros that are advertised to be constant in the sense that they
can be used at the preprocessor level are safe. But all in all, this situation
is a bit of a mess.
M.
And in case you wonder. I need to run this code before threads get initialized:
#ifdef HAVE_SYS_RESOURCE_H
struct rlimit rlim;
if (getrlimit (RLIMIT_STACK, &rlim) == 0) {
rlim_t our_lim = 64 * 1024 * 1024;
if (rlim.rlim_max != RLIM_INFINITY)
our_lim = MIN (our_lim, rlim.rlim_max);
if (rlim.rlim_cur != RLIM_INFINITY &&
rlim.rlim_cur < our_lim) {
rlim.rlim_cur = our_lim;
(void)setrlimit (RLIMIT_STACK, &rlim);
}
}
#endif
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: bugs regarding late g_thread_init() calls
I am looking around and I am having trouble finding a single application that does this new (yes, new) required initialization right. Either... 1. Applications do not explicitly call g_thread_init and call gtk_init too late. 2. Applications call g_thread_init too late. 3. Applications call g_thread_init too early. Does anyone want to claim a case that is right for a non-trivial application? Something with a translated GUI. M. Note: if (!g_thread_supported ()) g_thread_init (NULL); bz! g_thread_supported called too early. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: bugs regarding late g_thread_init() calls
> Does this count: > > http://mooedit.sourceforge.net/hg/moo/?f=-1;file=medit/medit-app.opag > line 259. There seems to be no translated GUI involved. And if there had been, that g_thread_init call would have been too early. setlocale must not be called after threads have been initialized, except to query the current locale. M. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: bugs regarding late g_thread_init() calls
> This is another thing. Is this correct? If yes, then are we all completely > screwed? Certainly. Google "threads setlocale unix" and see. For example http://www.phy.ohiou.edu/cgi-bin/man-cgi.sol?setlocale+3C > To change locale in a multi-thread application setlocale > should be called prior to using any locale sensitive rou- > tine. Using setlocale to query the current locale is safe > and can be used anywhere in a multi-thread application. setlocale will happily dlclose code that another thread is running. Or worse. M. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: alternative button order: Why don't we auto-guess the alternative order by default if appropriate?
On 1/5/07, Christian Neumair <[EMAIL PROTECTED]> wrote: > I wonder why we don't check for the alternative button order in > gtk_dialog_add_button > gtk_dialog_add_action_widget > and automatically prepend the button iff > gtk_alternative_dialog_button_order > returns TRUE. > > Developers can still override the automatically determined order with > gtk_dialog_set_alternative_button_order() Goffice has code to do this, see go_dialog_guess_alternative_button_order. It doesn't work for END-packed buttons, but the fix for that shouldn't be too hard. In fact, Dom claimed to be taking a look at this. Morten ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkTreeView and fixed_height mode
> Which other resizing mode would you want to use for your column? > AUTOSIZE doesn't make any sense, the point of fixed height mode is to > speed up GtkTreeView by not measuring every row. AUTOSIZE. Or maybe GROW_ONLY. You would measure cells only as they become visible and adjust the width of the columns as needed. Morten ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkTreeView and fixed_height mode
On 2/13/07, Kristian Rietveld <[EMAIL PROTECTED]> wrote: > On Wed, Feb 07, 2007 at 10:06:13AM -0500, Morten Welinder wrote: > > You would measure cells only as they become visible and adjust the width > > of the columns as needed. > > That would probably mean that the columns will be busy resizing as you > are scrolling. I am not sure if that is really nice ... If it happened all the time it would clearly be annoying. For GROW_ONLY tt really comes down to answering the question How likely is it that the next screenfull of data contains wider data than we have seen so far? That depends on the data and how much we have seen before, but if we initially did a fair-sized sample -- last I looked we were doing 1000 rows -- then the probability is low and hence it is not annoying. Morten ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLib and 64-bit Windows
> I think a large amount of errors stem from the fact that it is assumed > that sizeof(long) == sizeof(void *) ">=", I think, but yes. You need to make sure configure defines gsize as unsigned long long, and gssize as long long. You might also want to check... * the ptrdiff_t type. If it has a different size that size_t, there might be a bit of fun hidden there too. * if NULL is an integer type. No, really. If it is defined as just "0" or "0L", you are in for a world of hurt. It should be simplest to override the definition in that case. Morten ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLib and 64-bit Windows
> Or is it more appropriate to cast strlen to an int? I would really hate to see that. It could easily mask more important problems later. Note, that if you really want to change something, it is probably safer to change it to a gssize, i.e., the signed type of the same width as size_t. You'll get far fewer surprises with C's handling of signed and unsigned types that way. IMHO, don't worry about strlen now. Morten ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Performance implications of GRegex structure
[Re PCRE] > (There is no match[er] object here, but the equivalent is in all the in > and out parameters ...) Is it? If PCRE is as glibc, there is lots of state in the compiled expression and you cannot use it threaded. However, once the match call is done, another thread can use the compiled regexp. > Neither is very appealing to me as a coder, though I could be convinced > that the second [==re-compile] is OK by suitable performance timings. Do we > have such numbers? It's hard to see what kind of numbers would make sense to use as an argument here. The numbers will depend heavily (orders of magnitude) on the regexps and the data. M. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Performance implications of GRegex structure
Is there a guarantee that for GRegex (unlike, say, GDate) multiple threads can use the same object at the same time? I.e., two threads cannot call g_date_get_weekday on the same date, so why are we expect that two threads can call g_regex_copy or anything like it? Morten ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: ideas on improving the performance of gtk_tree_view
On 3/23/07, Federico Mena Quintero <[EMAIL PROTECTED]> wrote: > * 5000 columns is definitely abusing the *user*. Who cares about the > toolkit. Federico, where you think of "foo", someone else will want to write "Supercalifragilisticexpialidocious". You seem to be making a two-step conclusion: 1. At 5000 columns (or rows for that matter), scrolling with either mouse or keyboard will be an unpleasant way to get to the point you want. 2. Therefore 5000 columns (or rows) cannot work well in a GUI. I agree with 1, but I know that 2 is wrong. I have seen it work with considerably more than 2 rows. I cannot think of a good reason to use that many columns, but I am willing to believe my imagination isn't wild enough. The case I am familiar with is a large, sorted list of names. You get to the initially interesting point by typing the first few letters and then you can scroll to nearby entries. It worked very well, even with people who were completely computer illiterate (and bad spellers at that). Whether that kind of thing works depends a bit on corpus. For example, it wouldn't work with the all-China phone book. That's how many pages of "Li ..."? :-) Morten ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: new stock icons
On 4/2/07, Jakub Steiner <[EMAIL PROTECTED]> wrote: > Hi gtk+ developers. > I propose a replacement of the current gtk stock icons with newly > created artwork[1]. True or False: if you do so, applications that use the occasional own icon will en up looking wrong with the new icons. (And if we fix the icons, then the updated look with be wrong with old gtk.) Morten ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkBuilder Public API - Last call
> Since it accepts a nick, name or number, it's using > g_enum_get_value_by_nick/name internally. ...in which case it belongs in glib. Morten ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkBuilder Public API - Last call
> user_type and user_data which I proposed doesn't make too much sense, it's
> also difficult to support since you can't (AFAICT) use a GValue as user data.
It would be marginally useful for providing constant user data like...
* Strings: "oink"
* Translated strings: _("Moo!")
* Integers: GINT_TO_POINTER(12)
Having integer arguments saves you a function if you have, for example, "Up"
and "Down" buttons that are handled almost identically.
M.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Blacklisting themes?
In light of bug 438456, is there (or should there be) a way to blacklist a certain theme engine for a certain version range? Bug 438456 causes memory corruption in any gtk+ application it is applied to. Morten ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Blacklisting themes?
> I don't see how this is different from any other memory corrupting bug > in, say, a library. >From a technical standpoint it is not. However, a theme is a library that is loaded into your application by the end-user. Even if he is not particularly aware of doing so. The application programmer has no choice in the matter and cannot really test with all kinds of themes and all kinds of versions of them. But the resulting crashes are still going to be blamed on the application and poor me. Morten ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
