Re: An alternative to gdk-pixbuf
On Wed, 2018-09-05 at 17:28 +0100, Emmanuele Bassi via gtk-devel-list wrote: > In the near future, I'll very likely deprecate most of GdkPixbuf's > API, except for the I/O operations; I'd also be happy to seal off > most of its internals, within the ABI stability promise, to avoid > leakage of internal state. Related to this - I just wrote a braindump on gdk-pixbuf issues and historical baggage. I hope it's useful for people trying to clean up this swamp: https://people.gnome.org/~federico/blog/my-gdk-pixbuf-braindump.html Magnus - thanks for showing us Abydos. The parts of the API that intersect with gdk-pixbuf's look okay. I think you may find this useful: https://developer.gnome.org/programming-guidelines/stable/index.html.en I think your API could improve with some of the material there around memory management and error reporting. Internally, the code needs checks in all the malloc()-like functions; some of the arithmetic (especially in assertions) needs to avoid overflows. I couldn't find any tests. The SVG plug-in needs to handle error results from librsvg. The Magick plug-in for PNG and JPEG has no error handling; also you may want to call cairo_surface_mark_dirty() when you are done writing pixels to it. The netpbm plugin does a bunch of system calls and doesn't check for errors. The parts of your API that deal with pagination / variants / animation frames - I'm not sure if a gdk-pixbuf replacement would need them, but I'm coming from the viewpoint of my braindump above. Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Filechooser bug day/weekend/week/month idea
On Mon, 2013-06-03 at 15:02 -0700, Timothy Arceri wrote: I have managed to help get the count down from 359 only a couple of weeks ago through a combination of patches, making duplicates and bumping old bugs and patches. I have even found a couple of unreported issue along the way. However I've come to the conclusion that if I want to make a serious dent to these bugs I need some help. So... For the record, I want to publically thank Timothy for the stellar work he has been doing in weeding the file chooser's bug list. Closing old bugs, filing patches, what more would one want? :) I have started working my way through all the outstanding bugs and categorising them into groups based on the next action that should (in my opinion, I'm open to corrections) be taken. This is the right way to go! Once a complete list of these issues has been created we could advertise a bug day/week/etc for these to be worked on retested etc. For me a month-long fixing spree would work well, I think. Of course I'll gladly guide people through the code if needed. I upload the Libre Office documents I've used to categories these bugs here: http://www.itsqueeze.com/wp-content/uploads/2013/06/Filechooser-bugs.tar.gz but I would like to put all this on the Gnome wiki somewhere if that's possible?? This is really good! Thanks so much for compiling the list of categorized bugs! By now the list I had in https://live.gnome.org/GtkFileChooser is highly obsolete. Feel free to replace it with your list of bugs. An alternative is to put little strings in the Status Whiteboard field of each bug (filechooser-easy, filechooser-crash, filechooser-retest, etc.) and put URLs for the corresponding bug queries in the wiki. Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GSlice vs. tcmalloc vs. jemalloc
On Wed, 2013-05-08 at 15:32 +0200, stefan skoglund(agj) wrote: It is an improper term but yes it is cache coloring functionality. Yes, GSlice implements cache coloring; it works automatically. Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GSlice vs. tcmalloc vs. jemalloc
On Sat, 2013-05-04 at 22:10 +0200, stefan skoglund(agj) wrote: Do GSlice use the Solaris feature for memory usage levelling (an important feauture because of the fact that the SPARCCenter 2000 had striped RAM.) Important that in this case that if you hit multiple structs of the same type for example a tree-walk you should avoid hitting the same memory bank multiple times in a row. U, do you mean the cache coloring stuff? I.e. so that structs of the same size get put in different cache lines. I don't recall mentions of memory usage levelling; to what does that refer? Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GSlice vs. tcmalloc vs. jemalloc
On Mon, 2013-04-22 at 19:23 +0700, Hieu Trung Le wrote: Have you ever compare the GSlice allocator with other malloc library like tcmalloc or jemalloc? I'm not aware of any such benchmarks or comparisons, but it would definitely be interesting to see some! Also, as far as I remember, GSlice is pretty much a straight-up implementation of Bonwick's slab allocator plus the subsequent changes for using magazines for threading/multicore performance. I don't think GSlice has been updated with all the work that has been done in e.g. the Linux kernel for slab-like allocators. (Also, GSlice doesn't really use all the features of the original slab/magazine allocator - for example, blocks of memory are not recycled by resetting them to a just initialized state; instead, blocks are freed and re-allocated / re-initialized as needed.) Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: hackfest preparations
On Mon, 2013-04-15 at 14:17 -0400, Matthias Clasen wrote: I have now confirmed that we can use the OLPC office; lets meet there Friday morning around 10am and get started.The address is on the wiki Is anyone up for massive amounts of seafood on Friday, in Chinatown? I can arrange reservations. If we have too few seafood eaters, GTK+ is certainly doomed. Err, I mean, in that case, we can go to the Chinatown eatery and have other kinds of awesome food. Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Composite GtkBuilder template
On Thu, 2013-04-11 at 17:49 -0500, Federico Mena Quintero wrote: I'll do something like this. First, revert the commit. Then, merge my branch. Doing a straight rebase is not trivial, as places-sidebar has gotten master merged into it a few times to keep up with general development. And finally, apply your commit again with lots of changes. So I went ahead and did this. I learned why you don't support binding widgets to fields in public structures (it's done on the class private structure). I refactored your patch to use priv-foo instead of impl-priv-foo everywhere, and it is much nicer that way. I may end up doing this to gtk-2-24 as well for consistency. Tristan, the composite templates stuff is *excellent* work. The file chooser's code is much cleaner now that all the silly widgetry is editable in Glade! I guess the next thing would be to have GtkPlacesSidebar set up its internal GtkTreeView using Glade. I'll investigate that later, but if you already have a good pattern for doing this... :) Thanks for this massively useful work - doing megawidgets in Glade is really nice this way. Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Composite GtkBuilder template
On Thu, 2013-04-11 at 13:36 +0900, Tristan Van Berkom wrote:
First, let me apologize for the rather harsh tone in my message
yesterday. I had a big WTF moment when I saw how the composite
templates patches played badly with my branch. Your message made things
look easier to fix than I expected.
So, this is how I propose we handle the situation:
o First, you rebase your branch in such a way
that the filechooserdefault is reverted as
the first commit in your branch.
I'll do something like this. First, revert the commit. Then, merge my
branch. Doing a straight rebase is not trivial, as places-sidebar has
gotten master merged into it a few times to keep up with general
development. And finally, apply your commit again with lots of changes.
o Second, I know you wont like this part but
I need you to put the instance members on
a private structure.
We do not support automatically assigning
component pointers to public structure offsets.
And frankly, using a public structure defined
openly in gtkfilechooserprivate.h is an open
invitation for other components to access
the components of GtkFileChooserDefault directly
(which I think we both feel is unintended).
I totally agree with this for *public* widgets, those that go into the
public API.
But for GtkFileChooserDefault, I have two objections:
1. It's a private, internal widget, never meant to be exported.
2. I'd really really really like to keep the file chooser's code as
similar as possible between gtk2 and gtk3. Otherwise, cherry-picking
fixes becomes much harder.
I do appreciate having the private stuff in the .c file. And I
definitely don't like the current state (well, before your patches)
where the GtkFileChooserDefault struct is not in
gtkfilechooserdefault.h, but in a gtkfilechooserprivate.h file. I don't
remember why it ended up there; probably so that the unit tests would be
able to poke at internal widgets. *That* is not the right thing to do,
anyway, so I'm happy to see the struct move elsewhere. But the
objections still stand.
I haven't even seen how the code for composite templates pokes at
structs... but why does it have to care whether the struct is private or
public? Could we have:
gtkfilechooserdefault.h:
/* no struct definitions at all */
typedef struct GtkFileChooserDefault *GtkFileChooserDefault;
typedef struct GtkFileChooserDefaultClass *GtkFileChooserDefaultClass;
gtkfilechooserdefault.c:
/* complete structure definitions */
struct GtkFileChooserDefault {
GtkBox parent;
blah blah;
}
?
o If you have made any changes to the UI, i.e.
changes like spacing settings, expand/align
settings of any widgets in the filechooser,
any newly added widgets, anything that actually
changes the UI components, I would like you
to list those changes to me so I can make
the changes while splitting up gtkfilechooserdefault.ui
into 2 .ui files.
Sorry, you lost me - what would those two files be for?
(GtkPlacesSidebar is a self-contained thing which is mostly a
GtkTreeView...)
Federico
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Composite GtkBuilder template
On Tue, 2013-04-02 at 17:59 +0900, Tristan Van Berkom wrote: And while it's a huge list of changes, any thorough peer reviews would be greatly appreciated of course. This work makes merging my places-sidebar branch completely impossible. There is a highly nontrivial amount of work in that branch and I really don't feel like essentially rewriting the whole file due to merge conflicts. I'm going to ask you to do these: 1. Revert the commits that modify gtkfilechooserdefault.*, and ensure that the code compiles. 2. Tell me about it, and I'll merge places-sidebar into master. 3. Then you can go back and re-do your changes for gtkfilechooserdefault, BUT do not use a -priv field. GtkFileChooserDefault *is* a private widget, and it doesn't need a priv structure. Having it also makes the code unreadable. (I'd like the other internal widgets in GtkFileChooser to be the same, but I can live with just the main gtkfilechooserdefault being clean). I can only imagine how much work it was to complete the composite templates branch; please think that the places-sidebar branch is a similar investment on my part :) Thanks, Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Some shortcomings in gtestutils
On Thu, 2013-02-21 at 11:12 +, Philip Withnall wrote: Add the following in your Makefile.am: TESTS_ENVIRONMENT = libtool --mode=execute gdb Then run `make check` as normal, and magically all of your tests will be run under gdb. If you just want to run a specific test binary under gdb, use `make check TESTS=my-test-binary` Damn, this is why I love you, people. Thanks! Clearly I have to read the automake manual more thoroughly... Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Some shortcomings in gtestutils
Hi, everyone, I've been writing some tests for GtkFileChooserButton and putting them in gtk+/gtk/tests/filechooser.c - this is the old test suite, resurrected and alive. So, I've been learning what gtestutils provides. It is not bad, but it seems pretty pedestrian on some counts. These are some things I'd like to change, or at least for someone to point me in the right way of doing them: * Tests abort as soon as a test fails, since tests ultimately depend on variations of g_assert(). This is fine in that it makes the ensure things are okay code look the same as generic sanity check code. However, it also means that a test suite aborts as soon as it encounters the first test that doesn't pass. There is g_test_fail(), but the documentation pretty much only says, You can use this function if your test failed in a recoverable way. I don't know if that means that the test couldn't find a data file (but can continue anyway), or if it means call this if you want the test to fail but want the test suite to continue running. * It's hard to get a debugger up in the middle of make check. I can't think of a way to do it other than manually inserting code to sleep in the middle of the faulty test, and then attaching with a debugger manually. Maybe having an environment variable or something, so that I could run $ G_PAUSE_ON_FAILED_TESTS=1 make check when a test fails, I would get told, attach to $pid now or somthing. Maybe even have a G_NAME_OF_TEST_TO_PAUSE_IN variable to pause for a specific test, not any one that fails. * The documentation on gtestutils is far from stellar :) * Now that the a11y infrastructure is included in-the-box with GTK+, it sounds like a good idea to start putting an a11y-based testing infrastructure in GTK+ itself. For the file chooser's tests, I had to do some manual hacks to simulate, click this button, find the dialog, click the dialog's button... this is tricky C code that assumes too much knowledge of the internals of the toolkit, and I'd love to write some higher-level stuff instead for such tests. (Feel free to reply about this in a different thread - this could derail *this* thread pretty fast) :) Thoughts? We have a useful battery of tests now, and it only seems that improving the testing infrastructure could lead to people actually wanting to write more test code. Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Notebook tab not correctly drawn if tab pos = BOTTOM (gtk 3.5.4, win32)
On Tue, 2013-02-19 at 18:39 +0100, th-pitsc...@uni.de wrote: I was putting a GtkNotebook on a main window widget (using glade) and set the tab position to BOTTOM. This looks alright in glade. However, running the application itself one sees that the tabs are not drawn correctly (they retain round corners and the highlighting orange at the _top_ edge of the tab, while it should be at the bottom). see attach link. Please file a bug about this. If you have time, file it with a minimal test case - a little program and the corresponding .ui file, or a little program with the Glade stuff embedded and using gtk_builder_add_from_string(). Federco ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkWidget::visible
On Tue, 2013-01-08 at 16:04 +0100, Benjamin Otte wrote: - containers don't know what to do Should they skip invisible widgets when allocating? Or still reserve space for them? Tag, you are it! :) A couple years ago I totally failed in fixing this bug in GtkTable (I just made things worse and never committed anything): https://mail.gnome.org/archives/gtk-devel-list/2010-April/msg00062.html I have no idea if GtkGrid has the same bug - but if you are fixing this kind of thing, taking care of this would be greatly appreciated. Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: File chooser recent-files
On Mon, 2012-11-19 at 10:52 +, Simon McVittie wrote: If this sort of change is important, it sounds to me as though Gtk 2 should continue to have (short!) branches corresponding to a GNOME release when necessary? GTK+ 2.24.x still has releases! Do you mean that they should appear in sync with Gnome releases? That would certainly be nice, to keep things rolling. Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Sharing settings between Nautilus and Filechooser
On Wed, 2012-11-21 at 09:56 +0100, Bastien Nocera wrote: What do you think of org.gnome.file-view-preferences? Add a schema to GTK+: org.gtk.file-chooser show-hidden-files Yup, this is the way to go. Currently the file chooser uses org.gtk.Settings.FileChooser and a few keys; the source for them is in gtk+/gtk/org.gtk.Settings.FileChooser.gschema.xml The easiest thing would be to modify Nautilus to use the file chooser's equivalent keys. Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
File chooser recent-files (was: Re: Guidelines for stable branch changes in GLib/Gtk)
On Sun, 2012-11-11 at 15:24 -0500, Ryan Lortie wrote:
3) The file chooser recent folder changes that landed in 3.0 and also
on 2.x.
I consider the last case to be particularly egregious because nothing
was broken to start with and the changes were highly visible from a UI
standpoint. As I understand it, GNOME enters UI freeze at a particular
point in time and never leaves it (on a given stable release). We can
argue that Gtk is not GNOME, of course...
Mea culpa.
In retrospect, I completely agree with you: the changes to make the
file chooser start up in recently-used mode when no starting folder is
specified, should have gone into master only, not in the stable
branches.
I think I got the wrong impression of just how bad the previous
situation was: apps didn't suggest a default folder and they came up in
$HOME (because $CWD tends to be just $HOME if users launch apps from the
desktop shell); apps sometimes suggested a default folder, sometimes
saved from their last instance, sometimes not... I thought it was
pretty inconsistent, and wanted to make that situation better.
But yes, it was a big change, and it should not have gone into the
stable branches.
(The file chooser is a bit peculiar; I've wanted to keep it as much in
sync as possible between GTK+ 2.24 and GTK+ 3.x, because Big Important
Apps(tm) still use 2.24. I didn't want a situation where the main apps
use a shitty file chooser and only small/new Gnome utilities use the
improved file chooser.)
In [1] I wrote a detailed reasoning for starting up in recently-used
mode. I still think that reasoning is correct. However, you and other
people clearly don't like the resulting behavior.
Still, I've had even other people tell me that they like the new
behavior.
At the risk of introducing another preference in the file chooser, I
want to make an experiment.
The attached patch, for gtk+ master, lets you select whether to use the
current behavior (recently-used at startup unless a folder is pre-set),
the original behavior ($CWD unless a folder is pre-set), or something
that didn't really ever reach a stable version (save the last directory
you used and use it in the next invocation of a file chooser).
The way this is set is by reusing the old
~/.config/gtk-2.0/gtkfilechooser.ini file - you create a DefaultFolder
key and it can have the values cwd, last, or recent. The reason
I'm using *that* configuration file is that:
1. If we want to play with this patch on big apps that still use GTK+
2.24, they'll need to store the configuration there anyway.
2. I don't want 2.x apps and 3.x apps behaving differently.
3. Although the code to save the last-used-dir uses GSettings in GTK+
3.x, it used to use gtkfilechooser.ini in 2.24 - and if we actually keep
that code in the end, I intend to move the last-used-dir to the .ini
file so it is kept in sync.
I really hope you and other people who don't like recently-used by
default get to try this patch. I honestly don't know what the best
behavior is; maybe the best is to let people who know about filesystems
to use $cwd or whatever, and for people who are not as comfortable to be
presented with a recently-used list.
[1]
https://live.gnome.org/DocumentCentricGnome/Help%20the%20user%20choose%20a%20place%20to%20put%20a%20new%20file
Federico
From dc52c6d45d05841b916c61c454666fd99cc52372 Mon Sep 17 00:00:00 2001
From: Federico Mena Quintero feder...@gnome.org
Date: Fri, 16 Nov 2012 11:56:46 -0600
Subject: [PATCH] Allow choosing whether to open in recently-used mode,
last-used-folder mode, or
This works by having a GKeyFile, in ~/.config/gtk-2.0/gtkfilechooser.ini and reading this:
[Filechooser Settings]
DefaultFolder=cwd|last|recent
That is, the DefaultFolder key can have values of 'cwd', 'last', and 'recent'. The default, if
the key is not set, is 'recent' - this will bring up the recently-used mode as usual.
The 'cwd' mode will use instead, and 'last' will restore the folder that was used
in the last instance of the file chooser in any application.
We use that config file in ~/.config/gtk-2.0, not in gtk-3.0, so that it *is* the same config
file as used in GTK2 applications.
Signed-off-by: Federico Mena Quintero feder...@gnome.org
---
gtk/gtkfilechooserdefault.c | 86 ++-
1 file changed, 85 insertions(+), 1 deletion(-)
diff --git a/gtk/gtkfilechooserdefault.c b/gtk/gtkfilechooserdefault.c
index 09d6303..26a014a 100644
--- a/gtk/gtkfilechooserdefault.c
+++ b/gtk/gtkfilechooserdefault.c
@@ -6152,6 +6152,90 @@ get_file_for_last_folder_opened (GtkFileChooserDefault *impl)
return file;
}
+typedef enum {
+ DEFAULT_FOLDER_CWD,
+ DEFAULT_FOLDER_LAST,
+ DEFAULT_FOLDER_RECENT
+} DefaultFolder;
+
+static DefaultFolder
+get_default_folder (void)
+{
+ GKeyFile *keyfile;
+ char *filename;
+ DefaultFolder folder;
+
+ folder = DEFAULT_FOLDER_RECENT;
+
+ /* Note that this is really gtk-2.0 so that we can share the configuration
Re: Guidelines for stable branch changes in GLib/Gtk
On Sun, 2012-11-11 at 12:55 -0800, Matthew Brush wrote: Any chance of reverting/fixing those changes? Here's some related bug reports I could find: [snip] Thanks for compiling this list of bugs; it's very helpful! Please see the thread I started as a reply to Ryan - the File chooser recent-files one. It has a patch to revert to the old behavior, but I want to run this as an experiment. I've also put the patch in bug #658280. Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: Model-View-Controller
On Fri, 2011-11-11 at 15:55 +0100, Benjamin Otte wrote: [Talking about GtkButton] And it'd have those Controllers: (- Hover) - Click - Activate (- Focus) - KeyPress/Release I just took a quick look at ClutterClickAction and ClutterDragAction. They are certainly interesting. I wonder how things would look once you have widgets with complex behavior. Let me reintroduce something I talked about during the Desktop Summit - form languages and pattern languages. The way I see things, you want to encapsulate common actions as controllers, and common drawing idioms as views, so we can compose them into final widgets. I.e. you want to make the form language finer-grained and richer, so it will allow us to implement patterns more easily. Think of an app that lets you select graphical objects and move them by dragging. How would you implement something that needs both clicks (quick press/release with no movement) and drags (long press-move-release)? Do you need to somehow tie together a ClickController and a DragController, or do you have a generic PressMoveReleaseController, on top of which you implement the other two? As you said, for GTK+ it probably makes sense to start by abstracting out simple views and controllers. Exercise: do that in a branch for buttons and clicks, and refactor GtkButton and GtkScrollbar's arrow buttons to use that. See how the code looks. Then you may want to tackle GtkEntry's clickable icons in terms of the click controller as well. A much harder view/controller would be for selectable text. GtkEntry picks out the first PangoLayoutLine from the PangoLayout, and runs pango_layout_line_x_to_index() on it. However, GtkLabel does a direct pango_layout_xy_to_index(). No idea why GtkEntry does it like that; maybe it wants to explicitly ignore everything but the first line in the text. GtkEntry has scrolling offsets, but GtkLabel doesn't... etc. No idea how a SelectableTextController would look :) Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: regarding GIO
On Thu, 2011-10-20 at 10:27 -0400, Daniel Hernandez Bahr wrote: The thing is the GCancellable objects provide, as I am aware of, only the 'cancel' feature for async operations, would it be too hurtful to implement a GControllable class providing features such as 'pause'/'resume' as well as 'cancel' and maybe some other I fail to recall right now?? GIO is slightly lower-level than that. It just provides an abstraction for asynchronous I/O operations with cancellation. If you want to pause/resume transfers, you'll have to implement them yourself on top of that - you probably cannot use the predefined g_file_copy_async() and friends, but rather you'll have to do your own versions. Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK and OSX: a call to sanity
On Wed, 2011-09-07 at 08:25 +0100, Emmanuele Bassi wrote:
Windows and Linux build issues and support are handled on gnome.org: the
Quartz backend of gtk is not in any regard special and it should not
need separate resources.
One thing we have been bad at is learning to accept that sometimes, our
Gnome ecosystem breeds little niches of their own, and then some of them
turn into rightful ecosystems that *don't really need* much
communication with the mainline - they can exist on their own, with
occasional re-syncs, and with occasional pain.
I imagine that the Quartz backend is such a case: it probably started as
a let's port this and see where it takes us exercise, and then people
started writing jhbuild modulesets for apps, integration patches, etc.
It started growing and generating its own gravity and it didn't really
need to share much with Gnome or GTK+ proper - it would have been nice
to keep everything integrated from the start, in both code and
infrastructure, but it would probably have implied a lot of extra work
for both parties.
*Now* it seems to be the time where the cost of keeping things separate
is greater than just re-syncing periodically - so let that be; do the
integration and forget about the temporary split. You can think of
this work of merging as the necessary work to meld two ecosystems
together - you can't put a desert next to a jungle without a savannah in
the middle. Okay, bad analogy, but I'm only on my first coffee today.
Now, on technical matters:
I looked quickly at git diff origin/master..origin/quartz-integration
and the diff is very simple:
* A bunch of changes to gdk-quartz and gtk*-quartz.c - I imagine that
these can be merged just as they are, since they don't touch the
platform-independent code at all. I'm sure some of these bits could be
reviewed / prettified by someone who knows a lot of OSX idioms, but it's
better to have them in *now* and polish them later.
* This bit:
--- a/gdk/x11/gdkdevicemanager-xi2.c
+++ b/gdk/x11/gdkdevicemanager-xi2.c
@@ -417,10 +417,6 @@ gdk_x11_device_manager_xi2_constructed (GObject *object)
for (i = 0; i ndevices; i++)
{
dev = info[i];
-
- if (!dev-enabled)
- continue;
-
add_device (device_manager, dev, FALSE);
No idea what that's about.
* Some Makefile.am changes; these could use a quick sanity check.
* Some additions to gtkprivate.h, analogous to what it has for win32 right now.
* A bunch of #ifndef GDK_WINDOWING_QUARTZ in gtkselection.c, so that
those functions can be implemented in gtkselection-quartz.c instead.
This can probably be made prettier by moving the original functions to a
gtkselection-x11.c or something like that.
* An unused variable in gtkthemingengine.c; should be removed.
* Inconsequential whitespace changes in some .po files; should be
removed.
* A tests/testundecorated.c - no idea.
In all, it sounds like you could merge all the changes to *quartz*.[ch]
files as they are, and just give a quick look to the rest of the
changes.
As to what is in Bugzilla, is there a quick way to find all the Quartz
bugs to speed up their review? (Or are those patches already in the
quartz-integration branch? I didn't look at individual commits to see
if they had bug numbers.)
Federico
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Sharing the places sidebar between Nautilus and GTK+
Hi, everyone, There is a patch in [1], by Jon McCann, to make the shortcuts bar in GtkFileChooser be pretty much the same as the one in Nautilus. Rather than patch the wobbly edifice that is gtkfilechooserdefault.c, this sounds like the perfect time to actually pull out the shortcuts bar as a public class of its own, that is shared by both the file chooser and Nautilus. My plan is this: 1. Copy nautilus-places-sidebar.[ch] into the GTK+ sources. 2. s/nautilus/gtk 3. Remove obvious nautilus-isms like the use of nautilus_bookmark, which should be easy enough to replicate in GTK+ (or with things which already happen through the file chooser's code). 4. See what common, public interfaces we need. For example, nautilus_window_set_initiated_unmount (sidebar-window, TRUE); seems like it could be replaced with a signal on the GtkPlacesSidebar class, and then Nautilus can start a spinner or whatever when an unmount operation starts. Another common interface would be something like gtk_places_sidebar_select_path (sidebar, file:///foo/selected) to highlight a particular item. 5. See what nautilus-isms *should* be doable with plain GIO, and see if there is anything else that Nautilus needs to do about them via signals; maybe for something like nautilus_file_operations_mount_volume_full (NULL, volume, volume_mounted_cb, G_OBJECT (sidebar)); 6. See what things should be available or not in the file chooser... when dropping files on the shortcuts bar, Nautilus can do nautilus_file_operations_copy_move (uris, NULL, drop_uri, real_action, GTK_WIDGET (tree_view), NULL, NULL); Same thing for nautilus_file_operations_empty_trash (GTK_WIDGET (sidebar-window)); I'm starting a branch in GTK+, places-sidebar to do this. Comments are appreciated, especially from Nautilus hackers who may know dark places in this code well. One little caveat: that part of Nautilus is GPL, and GTK+ is LGPL, although it *seems* that the places sidebar code may initially have come from GTK+ and then reworked heavily. I haven't checked the history closely. What do we do about this? [1] https://bugzilla.gnome.org/show_bug.cgi?id=642712#c4 Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ team meeting at guadec
On Wed, 2011-07-27 at 14:41 -0400, Matthias Clasen wrote: I have been slacking off and not pushing for team meetings recently, and I haven't even looked at the guadec schedule until today. But I guess better late than never: should we aim for a gtk team meeting at guadec ? If so, what day would work best for everybody ? We have a scheduled BoF for GtkRecent and Zeitgeist, but it's until Thursday at 09:00 (WTF! 9 AM!). We could tack on the GTK+ meeting to that BoF, unless it's an inconvenient time... Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk-2-24 has new strings
On Wed, 2011-07-13 at 10:32 +0100, Bastien Nocera wrote: But why do that in stable releases? Unless there's a very very (very very) good reason to break the freeze, the stable branches should only see bug fixes. Why was this pushed to stable branches? This change makes the file chooser much more usable. I don't want this to wait until Gtk+ 3.2; apps can already benefit from the change, as it doesn't change the API. My view is that people are going to use Gnome 3.0.x for a good while, basically for as long as their distros use it, and it's better for them to be able to get these improvements than to wait until 3.2. Having the change in 2.24 as well is for the benefit of Very Important Apps(tm) that still use GTK+2 - Firefox, LibreOffice, Gimp, etc. [Lame answer: I talked to Matthias about this on IRC, and he seemed fine with the change.] Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
gtk-2-24 has new strings
Dear translators, I've just pushed some changes to the file chooser in the gtk+ module, specifically to the gtk-2-24 branch. Although right now the focus is 3.x, we will likely have another release in the 2.24.x series for GTK+. Please update your translations there :) (The idea is to have the file chooser as similar as possible between 2.24.x and 3.x, so that even apps which still require GTK+ 2 will get all the goodness - and users will get consistent behavior.) Thanks! Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
String change in gtk-3-0 branch
Dear translators, I have just merged an interesting patchset to gtk+, in the gtk-3-0 branch. This adds two or three new strings to the package; I hope that doesn't cause too much trouble for you. GTK+ hackers: this is the merge of the bgo593793-filechooser-recent-folders branch, which is described in more detail here: http://people.gnome.org/~federico/news-2011-07.html#01 I'll backport this code to GTK+ 2.x so that apps which still use GTK+ 2 can get the goodness in the file chooser. Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: I have a problem
On Sat, 2011-05-28 at 23:01 +0200, Benjamin Otte wrote: And I'm somewhat lost what to do then. Should I say yes because it's a good widget to use in general? Should I say no, because it shouldn't be used? What are the features and behaviors I have to look out for in those widgets so they end up in a consistent toolkit? We sadly have not formalized this. This is definitely one of the things that we should try to do in the new HIG. Emmanuele mentioned the visual grammar, and I think this is the key here. There is already an architectural term for this; what Emmanuele thinks of as a visual grammar is the form language of an architecture. I'm going to mix architectural terms and computer science terms, so bear with me. Think of building materials as an alphabet, and their possible interactions as the grammar in your language. The possible constructions, or the strings in the language, are those that can be built with those materials by following their particular rules. Different architectures across the world have different form languages because they use different materials in different conditions. Brick and mortar buildings, with clay roof tiles on timber frames (Italy?) have a different look, and different shapes, than Japanese houses built of timber and movable paper walls. Each of those architectures has its own form language - and yet both let you build habitable buildings. In a similar fashion, GUIs have different form languages depending mostly on the toolkit. Qt apps look different than GTK+ apps even if you change the theme, because the forms and their interactions are different (and both let you build perfectly usable and attractive interfaces). The problem you are attacking is about trying to expand the form language we have. Maybe one question we need to ask is, does this look like it could come out naturally from GTK+, or are you cutting and pasting from an iPhone screenshot? (Would you put a brick arch to frame a door in your Japanese wood-and-paper house? No, you wouldn't; it would look terribly out of place.) I usually try to understand why the current widgets don't achieve the goal the design is trying to achieve and if we should modify the widgets to include the needed features. Or do the existing widgets not work for what we want to achieve and we should deprecate them? It depends. When we added icons and placeholder texts to GtkEntry, it was because those were useful forms that were very hard to build with what we had. Sometimes we need completely new stuff, like the button-that-when-clicked-brings-up-a-menu thing that everyone tries to implement in various ways, and with various degrees of success. * The text says Highlight and symbolic icon on hover indicates that the item is actionable So far we've not had icons anywhere in GTK that only show up on hover. Is displaying symbolic icons on hover a new UI paradigm that we want to promote? Should space for those icons generally be reserved in advance or should we reflow when they become visible? Or should they be drawn on top of existing content? Do we expect to use this paradigm in other places (menuitems or buttons come to mind) or is this just for contacts? This came from highly interactive web pages, and it's a good form. It lets you present affordances for functionality without cluttering everything (as if you had the icons visible all the time). I don't think we need a special widget for this; maybe just a GtkImage that the app turns on and off by hand when another widget is hovered - that's easy enough to do. We could have a gtk_image_set_active_only_when_hovered(image, other_widget), perhaps, if the implementation turns out to have more tricks than obvious. Space for the icons should definitely be reserved in advance; otherwise you don't have a guarantee that they'll fit to be visible. * The text says only the content gets scrolled That's where the designer probably got lazy^H^H^H^Htired as he was finishing the mockup. The heading area for Angelinus Jolie could very well be slightly wider horizontally, and the scrollbar shorter, so that the scrollbar really only adjoins the scrollable area. Look at the second picture in the first column of the mockup, where it shows the contents slightly scrolled. This looks bad: the top of the scrollable area has no frame and so the widgets get clipped (the fade-to-white is a bad, cheap effect). It would look even worse in the bottom when the gray button for Add detail gets clipped in the bottom of the scrollable area. That scrollable area just needs a border around it. * There's button(s) that say ( Notes | Edit ) How are these buttons different from notebooks? Is it just visually different or is it a completely different interaction? Because from the interaction described it looks like a notebook to me, just with a different UI. But I can't really pinpoint what's missing from GtkNotebook for this. Also, should we try to get rid of
Re: I have a problem
On Tue, 2011-05-31 at 01:53 +0300, Andrew W. Nosenko wrote: 1. how I can to hover using touch screen? You may not be able to (I don't know if X on your touch screen would emit proximity events). In that case, those UIs that require hovering may indeed not be adequate for your touch screen. Touch screens and mice have very different feels; you can't just use any widget and expect that it will work correctly on both types. 2. why I (now as desktop user) should to hover anything just in case? You shouldn't have to. If you need to scrape all the widgets just to find functionality, the design is indeed broken. What the appear-on-hover icons do is to present casually useful actions, not vital ones which should be close at hand. They are intended to be, by the way, you can also do this here, not the primary way of doing things. Think of the + icons that appear on YouTube's thumbnails so that you can add videos to your playlist (and in a similar way, the X icons that appear in thumbnails already in the playlist so you can remove them). You wouldn't want those icons to show up all the time; showing them when you hover the thumbnail is much better. And the icons are not the only way of performing their actions; you can go to the pages for the videos and find a remove this or add to playlist command in there - it just takes longer. Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK and ATK
On Tue, 2011-05-10 at 16:28 +0200, Benjamin Otte wrote: The TL;DR version is this: I think the problem is the fact that we support a separate API for accessibility. Let me present my (very limited) understanding of how a11y works right now. This is for the benefit of gtk-devel-list; people on gnome-accessibility-devel are obviously already well-informed of all of this. All the a11y code we have is essentially a solution to the problem of mapping an unknown number of accessibility-specific dongles (screen readers, braille readers, sip-and-puff controls, debugging shit like accerciser and the old at-poke), to an unknown number of widgets and widget toolkits. We have: screen readers \/--- Firefox dasher -\\ // LibreOffice debugging software --- ? - GTK+ apps braille readers // \\ Qt apps sip-and-puff control ---/\--- Your Momma's toolkit This is a classic mapping problem. You don't want to write (N+M)^2 implementations so that every screen reader can talk to Firefox, LibreOffice, etc., and vice-versa. Instead, you want a central abstraction so that you only have to write (N+M) implementations. at-spi is the central abstraction. It lets you navigate a user interface in very abstract terms, read what its various parts say, and write to user-modifiable parts. What controls do you have? Oh, is that control a table? Does that cell support an editable text interface? You say that there's an image there but the user can't see - do you have a textual description for it? Stuff like that. at-spi is that set of abstract interfaces described in D-Bus parlance. Right now, the at-spi2-core module is a C binding to those D-Bus interfaces. In C you call atspi_selection_get_selected_child() and it does a D-Bus call for you. That module also has a registry, whose purpose I don't fully understand, but I think it's so that things on the left side of the diagram above can find things on the right, and vice-versa. Or something like that. You also need the converse - something that receives the D-Bus requests and marshals them to real code. You want something that receives the D-Bus requests, unpacks the arguments, and marshals them to... what? anything could be on the other side - Firefox, GTK+, Qt, LibreOffice, etc. For GTK+, there are two intermediate layers between the D-Bus glue and GTK+ itself. One is the layer that actually receives the D-Bus requests and marshals them to more concrete code. That layer is at-spi2-atk. The other layer is ATK. As far as I can tell, ATK is just a re-statement of the interfaces that at-spi gave us, but in GObject terms. Instead of a DBus interface called org.blahblah.a11y.Selection, you have an AtkSelection which is a GTypeInterface. Instead of a DBus method called SelectChild, you have a vtable slot in AtkSelection called ref_selection. It's not called the same as the DBus method because... oh, I don't know, memory management details, or something. But ATK is just interfaces and glue, not real code. You want something that will take a GtkLabel and expose it as an AtkText. This adapter is GAIL. It's just a ton of code that takes GTK+'s ad-hoc, comfortable structure, and plugs it to the bunch of abstract interfaces that come from ATK (and that in turn come from at-spi). GAIL exists for historical reasons. We didn't want to glue the experimental a11y code directly to our stable GTK+ and the GNOME libraries, so we put that glue in a separate module. Applications with custom widgetry, like Evolution, usually implement the ATK interfaces directly in their code - they don't have a separate module like GAIL. There are several problems with all of this. Nobody likes to maintain glue code. It's tedious to write and it breaks in ways that are hard to test. Having GAIL separated from GTK+ makes them tend to be out of sync. ATK is duplicated interfaces. It needs to be kept in sync with the rather axiomatic interfaces provided by at-spi. It has to deal with messy details like GTK+'s reference counting (and who knows if at-spi is amenable to that kind of detail). Various other software has seen that ATK is a convenient place to plug in, and instead of providing its own DBus-toolkit layer, it instead implements ATK interfaces in terms of calling its own toolkit, and calls it a day. This is not a problem in itself, but it makes ATK even more of a point of failure. (FIXME: is this accurate? http://accessibility.kde.org/developer/atk.php suggests that this is what Mozilla does.) One problem may be that at-spi sometimes wants to be tightly-bound to things that are far away from it, and that's bad design. For example, consider the use of numerical indices in the Selection interface. When the innermost layer (GTK+ or any other toolkit, or a custom widget) changes something in its UI, the numerical indices that you got from at-spi may no
Grabs and completions
Hi, I'm trying to understand why bug #639842 happens. It's pretty easy to reproduce on 3.0: 1. gtk+/tests/testfilechooser --action=save 2. type /home/ plus the first letter of your username 3. wait for the completion suggestion window to appear 4. hit Tab 5. The focus changes to the next widget, while it should in fact complete your username (for example). I have this stack trace of the place where the focus is changing: #0 gtk_window_focus (widget=0x80ae070, direction=GTK_DIR_TAB_FORWARD) at gtkwindow.c:5894 #1 0xb7587778 in _gtk_marshal_BOOLEAN__ENUM (closure=0x8098d98, return_value=0xbfb5c480, n_param_values=2, param_values=0x80eb540, invocation_hint=0xbfb5c49c, marshal_data=0xb77201a1) at gtkmarshalers.c:165 #2 0xb6c8f947 in g_type_class_meta_marshal (closure=0x8098d98, return_value=0xbfb5c480, n_param_values=2, param_values=0x80eb540, invocation_hint=0xbfb5c49c, marshal_data=0xb0) at gclosure.c:878 #3 0xb6c8f636 in g_closure_invoke (closure=0x8098d98, return_value=0xbfb5c480, n_param_values=2, param_values=0x80eb540, invocation_hint=0xbfb5c49c) at gclosure.c:767 #4 0xb6ca81ad in signal_emit_unlocked_R (node=0x8098df0, detail=0, instance=0x80ae070, emission_return=0xbfb5c5bc, instance_and_params=0x80eb540) at gsignal.c:3290 #5 0xb6ca73c3 in g_signal_emit_valist (instance=0x80ae070, signal_id=37, detail=0, var_args=0xbfb5c690 \244Ƶ\277\364\177\203\267\310Ƶ\277\243\300p \267) at gsignal.c:2993 #6 0xb6ca7623 in g_signal_emit (instance=0x80ae070, signal_id=37, detail=0) at gsignal.c:3040 #7 0xb770b10f in gtk_widget_child_focus (widget=0x80ae070, direction=GTK_DIR_TAB_FORWARD) at gtkwidget.c:9546 #8 0xb74fae65 in gtk_entry_completion_key_press (widget=0x81f8000, event=0x80df318, user_data=0x80a25e8) at gtkentry.c:9572 #9 0xb758758a in _gtk_marshal_BOOLEAN__BOXED (closure=0x8310430, return_value=0xbfb5c870, n_param_values=2, param_values=0x80eb590, invocation_hint=0xbfb5c88c, marshal_data=0x0) at gtkmarshalers.c:85 #10 0xb6c8f636 in g_closure_invoke (closure=0x8310430, return_value=0xbfb5c870, n_param_values=2, param_values=0x80eb590, invocation_hint=0xbfb5c88c) at gclosure.c:767 #11 0xb6ca7fe8 in signal_emit_unlocked_R (node=0x8099530, detail=0, instance=0x81f8000, emission_return=0xbfb5c9ac, instance_and_params=0x80eb590) at gsignal.c:3252 #12 0xb6ca73c3 in g_signal_emit_valist (instance=0x81f8000, signal_id=49, detail=0, var_args=0xbfb5ca80 \230ʵ\277p\t\b\001) at gsignal.c:2993 #13 0xb6ca7623 in g_signal_emit (instance=0x81f8000, signal_id=49, detail=0) at gsignal.c:3040 #14 0xb77050ae in gtk_widget_event_internal (widget=0x81f8000, event=0x80df318) at gtkwidget.c:6063 #15 0xb770493b in gtk_widget_event (widget=0x81f8000, event=0x80df318) at gtkwidget.c:5779 #16 0xb74ff16b in gtk_entry_completion_popup_key_event (widget=0x80e6150, event=0x80df318, user_data=0x80a25e8) at gtkentrycompletion.c:906 That gtk_entry_completion_popup_key_event() is gtkentrycompletion's callback for key-press-event on its little popup window. In turn, that popup window grabbed the focus and took a GTK grab for events on the keyboard device (see the end of _gtk_entry_completion_popup()). For the file chooser's purposes, I'd like to be in charge of the Tab key, instead of letting gtkentry and gtkentrycompletion decide what to do. So I'm wondering how to keep them from processing Tab at all, even within the special signal handlers for the popup window. Should I just add an internal function to let them know not to mess with Tab? That seems a bit inelegant, but if it's internals only... Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Minimum height for minimum width
On Mon, 2010-10-11 at 15:41 -0400, Havoc Pennington wrote: Uggghhh... so the h-f-w request/allocate stuff needs to be exposed to the WM ;-) Client-side decorations! :) Then we can handle everything ourselves. (Of course it's not so trivial... then we'll want to know things like snap coordinates from the WM. Or yeah, we may actually need a new protocol so that the WM and the client can work together during resizes.) Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: multiroot-filechooser ready for merging
On Thu, 2010-10-07 at 07:09 -0400, Matthias Clasen wrote: When rooted to $HOME and /tmp, I found that typing '/' would still complete all toplevel directories, while typing '/t' comes up with no completions. I would have expected just '/tmp' in both cases. Good catch, thanks. I'll take care of this. Thanks for commiting the build fixes! My GTK+ 3 build setup is hosed at the moment, so I couldn't really test it - I just wanted to push the rebased version to safe place. Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: multiroot-filechooser ready for merging
On Thu, 2010-10-07 at 00:28 +0200, Torsten Schoenfeld wrote: G_TYPE_STRV properties don't need annotations, they are handled automatically. But functions like your gtk_file_chooser_set_root_uris need to have annotations to tell gobject-introspection that 'char **roots' is actually a zero-terminated array. gtk_builder_add_objects_from_string in gtk+-3/gtk/gtkbuilder.c is an example with such an annotation. Got it, thanks. Is the list of annotations documented anywhere? The generated docs in library.gnome.org don't seem to have all the stuff from annotationparser.py (which took some code-reading to find) :) Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: multiroot-filechooser ready for merging
On Thu, 2010-10-07 at 09:59 +0100, Bastien Nocera wrote: Then I would play down the security benefits of the features in the documentation... Yeah, good point. The docs as they are just say that you can't go outside the roots, which could mean that the code tries really hard to do that. I'll fix the docs. Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: grid widget (was Re: possible removal of GtkWrapBox)
On Thu, 2010-10-07 at 09:23 -0400, Havoc Pennington wrote: Don't know if this will make sense to anyone else but I do think it's useful to take some real-world layouts and see how much typing they'd require This is a very interesting exercise, and the pseudocode for those examples *is* really nice and concise. However, who writes UIs by hand these days? Doesn't everyone just use Glade? (I know, I know; we all have a complex part in $project where you need to code the layout by hand. Or you have historical hand-coded UIs. Life is hard.) I don't know how many other examples you considered while thinking about your API, but let's see about those three: 1. Gedit's about dialog. This is just GtkAboutDialog, correct? GTK+ has all the hand-coded stuff; Gedit doesn't have to worry. 2. Calculator. It's done with .ui files! There's a .ui file for each important section or mode (advanced, financial, programming), which then get put into the window. 3. Display properties. It's done with a .ui file as well! I'd love to see a list of common UI patterns that people use, or the common quirks, or the common special-cases they need to do. Here are a few: * Our HIG-beloved sections with indented contents in dialog boxes. There is no official solution to this, and various apps do different hacks to achieve them. * Groups of widgets that need to be shown/hidden, sensitized/desensitized upon different conditions. Sometimes you can get away with sticking them in the same container and just operating on the container. Other times you need to keep a hand-build list of those widgets and really operate on them by hand. What gets painful sometimes is that windows get unexpected sizing if you hide a few widgets. * Baselines!!! I think we could make things automatically look prettier if we let certain containers hang off a label's baseline. For example: Foo bar ++ Baz beep [__] || [__] || [ ] Blah || [ ] Blih bluh ++ Those are a few labeled widgets around a list widget or something equally obtrusive. GTK+ should let you guarantee that the labels on each side are aligned on their baselines, *without* requiring you to carefully sync up the spacings on both sides. Extended-layout originally had something about baselines; I don't know if this is still in the branch, or if it works at all. * Fixing the bugs like a table with an empty row still gets both spacings around the row applied - I was in the middle of fixing that one, but didn't finish. That would help when you have to hide/show widgets at runtime. I *think* Matthias's grid widget is a GtkTable with WFH that can be used in place of GtkBox, but still intended to be used from Glade, mostly. (Having a helper API like the one you propose to fill up an existing table/grid/whatever sounds nice; I just don't know if it is a lot of complexity that won't get used much in the end. Such an API would be really for code only, not something that you expect to be a GtkBuildable.) From your other mail: One litmus test for too much redundancy is if you have to change two lines to add or remove a widget. If you are making your UIs with Glade, it would help for Glade's usability to be improved in a similar fashion. We should study what kinds of tricks people use to rearrange widgets... creating a temporary window, inserting a container, then cuttingpasting widgets into it to create a holding space, is pretty cumbersome. Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Writable array returned from gtk_tree_path_get_indices()
On Thu, 2010-10-07 at 09:18 -0500, Stef Walter wrote: Is the integer array returned from gtk_tree_path_get_indices() writable by design? Or should it be treated as readonly? It depends. Sometimes you get a GtkTreePath from the treeview API when you ask for something (e.g. gtk_icon_view_get_path_at_pos()). Since that is a newly-generated path that you own, you can do anything you want with it. People may use it as a counter and increment the index to iterate over the model, or whatever. Sometimes you get the GtkTreePath as an argument to a callback (e.g. GtkTreeModelForeachFunc). Generally you shouldn't modify the path in that case. Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: multiroot-filechooser ready for merging
On Thu, 2010-10-07 at 20:20 +0200, Torsten Schoenfeld wrote: This is the canonical place, as far as I know: http://live.gnome.org/GObjectIntrospection/Annotations. Perfect, thanks! Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: grid widget (was Re: possible removal of GtkWrapBox)
On Thu, 2010-10-07 at 15:05 -0400, Havoc Pennington wrote: It's a valid point, but I don't know that Glade is always easiest. I don't think it's a good excuse for making the actual API crappy. Oh, no, of course not. What I mean is that if few apps actually do complex layout by hand, then maybe it's better to spend effort in making Glade good. But I like a lot what you say below. (In fact I'd almost think Glade should have its own container widget that's designed to be easy to use in a builder, just as in code it's good to have a container widget that's easy to use in code. Do the same top-down exercise with Glade - what would make a container easy to work with in a UI builder - and design based on that.) This is very interesting. We should definitely ask the designers. Off the top of my head, here is what happens right now: 1. You sketch your UI in a napkin or some suitable fibrous material. Due to your extensive training in visual aesthetics, your UI is well-balanced, it has good use of whitespace, etc. 2. You fire up Glade. 3. You throw in some tables and boxes to contain the elements which are visually aligned in your sketch. 4. ... Hours pass ... 5. You give up as GTK+ plainly doesn't let you adjust whitespace in an intuitive way, and it is really hard to size widgets like treeviews, etc. Your UI looks halfway decent but squashed, like if you had run GIMP's zealous crop on your napkin sketch (that's the filter that removes all empty rows/columns of pixels, leaving effectively no whitespace). 6. At some point you actually run your UI against translations which change the length of the text labels, and you give up for the second time :) When using Glade, the problem is not usually figuring out the grid you need (you just throw in a table and insert/delete cells as appropriate). The problem is having to endlessly tweak all the parameters that modify how things respond to their cells. Then tweaking all the things that affect how things resize. Then realizing that whitespace is basically impossible to do. There's too much mousing around. Click on a widget. Move the mouse all the way to the properties area. Tweak tweak tweak. Move back to the UI to click on another widget. All that back-and-forth is very wasteful. OK, I'm just complaining here. It would be good to sit down together in the Summit and see how people use Glade. Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
multiroot-filechooser ready for merging
Hi, all,
I've been running Christian Hammond's multiroot-filechooser branch for
about a month now, with zero ill effects. This is not surprising, as no
apps actually use the multirooting functionality yet; what is nice is
that those apps haven't broken yet.
The past discussion is in bug #609886.
I took the original multiroot-filechooser-2-20 branch and rebased it on
top of master, and pushed the result as a new multiroot-filechooser
branch.
This is ready for merging into master, for 3.0.
Here's a quick summary of this branch.
* GtkFileChooser now has a root-uris property. This is a G_TYPE_STRV.
You can now do something like
char **roots = { file:///home/federico,
file:///mnt/corporate-share,
NULL };
gtk_file_chooser_set_root_uris (chooser, roots);
And then the file chooser will only show subpaths of those roots, and
not let you navigate outside of them. This will be useful for lockdown.
Christian uses it in VMware to constrain where files may be picked from
(a VM image or something, I suppose).
* Internally, the local-only flag has been reimplemented in terms of
roots. When you turn on the local-only flag, you are constrained to the
file:/// root - this means essentially the Unix filesystem, not weird
non-native GVFS mounts.
* The path bar, and the file chooser in general, is smart enough not to
let you climb up above the roots. You can't Alt-up if you are in a root
already, and the pathbar doesn't let you scroll further to the left.
* Shortcuts outside the roots are not shown. Generally stuff outside
the roots doesn't appear at all. You can't autocomplete your way out of
the roots by typing in the filename entry.
So, this mail is just to ask for feedback. Is a boxed G_TYPE_STRV
friendly enough to language bindings? Should I merge this now?
Thanks!
Federico
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Need some advice for glib developer beginer
On Thu, 2010-09-30 at 14:30 +, Alexander Kuleshov wrote: Now i learning glib codebase and where can i find TODO or something else for glib, maybe not complex bugs... For know how - to write,review and submit pathes. These days the TODO list for glib is in bugzilla; all the bugs are the TODO list. It's not *that* disorganized if you look at the bug priorities, severities, etc. https://bugzilla.gnome.org/browse.cgi?product=glib To submit patches, you can format your patch using git (see the various Git manuals for how to do this), and attach your patch to the corresponding bug. If it's a nontrivial issue that merits discussion, you may want to mail this list. Good luck! Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: multiroot-filechooser ready for merging
On Wed, 2010-10-06 at 21:01 +0100, Bastien Nocera wrote: Symbolic links? To both the filesystem itself, and to directories under ~/.gvfs/. Are those blocked as expected? Looks like we have different expectations ;) Nope, we don't try to resolve symlinks to see if they point to allowed hierarchies. This is not hard security; it's about simple lockdown, or about letting people implement a pick a file in the USB stick kind of thing. It would be interesting to desensitize symlinks to places outside the roots. I don't have enough brain cycles left today to implement this, but patches welcome, etc. I'm not sure it's worth the effort to resolve stuff inside .gvfs - if you created a mount and if your $HOME is allowed, then I see no reason to block the mount. (If your ~ is not allowed, then *probably* your lockdown scheme is highly weird anyway.) (Since the file chooser now basically has all the is this file allowed machinery internally, it would be interesting to hook it up to a real security system with really enforceable policies. I hereby declare the can of worms opened.) Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: multiroot-filechooser ready for merging
On Wed, 2010-10-06 at 22:32 +0200, Torsten Schoenfeld wrote: Yes, I think so. It's pretty common for arguments and properties, so most bindings will be able to deal with it. With proper annotations, gobject-introspection can also represent it. Excellent. Where are those annotations made? I grepped quickly in the gtk+ sources for other STRV properties, but didn't find anything that looked like an annotation for a automated generator... Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk_widget_draw()
On Thu, 2010-08-26 at 12:35 -0400, Behdad Esfahbod wrote: Just keep in mind that it's very normal for text ink to leak out of the allocation area. So even if the draw-border property is removed, we should eventually figure out how to handles these. But widgets are supposed to request a size that will fit their ink_rect, correct? Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk_widget_draw()
On Wed, 2010-08-18 at 07:56 -0400, Paul Davis wrote: its quite amusing to me how what is being described is slowly converging on something extremely close to a canvas model in many of its most fundamental aspects. am i the only one seeing this? does it matter? In my mind a canvas does two things: 1. Retained drawing. You draw something and you get a handle back to it so that you can modify it (move it, recolor it, etc.). GDK doesn't do retained drawing; it does direct drawing where you draw something but you have no way to modify it afterwards. 2. Hit detection. You get events relative to the objects that you drew. This is a lot more sophisticated than something happened inside this rectangular window :) Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk_widget_draw()
On Wed, 2010-08-18 at 09:37 +0200, Alexander Larsson wrote: [Border around windows so you can glow around a widget] There are all sorts of ways you can hack it into GtkButton or any specific widget, I'm sure. However, its hard to do in a more generic way for a theme. I was thinking the theme could just set a style property to have the widget enlarge its border, and then the theme just draws a bit outside in its normal rendering operation. No hacks, no special code, works for all widgets. Hmm. I just think it's overkill to complicate the GdkWindow abstraction just for themes' sake. Correct me if I'm wrong, but I think you imagine the glow-around-a-button to actually have allocated space around the button * +--+ * +--+ * |button| * |button| * +--+ * +--+ while I'm imagining that the glow actually overlaps anything around the widget ** * +--+ +*-+ * |button| |*utton| * +--+ +*-+ ** The latter is doable if the theme creates a temporary window as a child of the toplevel, on top of all the other subwindows. [Do we just lack the don't clip flag on windows] To fully take advantage of it we would also like to remove no-window widgets in Gtk and make getting a standard window easy via some default realize handler setup. I guess InputOnly windows are trivial when we get the transparent windows we've been talking about - you just never draw to them. Old apps could still use them to get events. Getting rid of no-window widgets would be trivial in GTK+, but it would break a lot of code that already uses that trick and does all the coordinate-munging on its own... maybe we should make no-window mean you won't know it, but you really get a cairo_t with a transformation relative to your parent widget? That way you still have to make the changes to take a cairo_t instead of a GdkWindow (for the draw() method), but you don't have to change your delicate code that deals with coordinates. Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk_widget_draw()
On Tue, 2010-08-17 at 17:28 +0200, Benjamin Otte wrote:
The biggest problem for me when reading the GdkWindow code is that I
have no idea what a window is. So I have a hard time understanding the
code and if what it does is sane.
One pattern we see a lot is when widgets want to paint themselves on
their parent container's background, but still receive events. They are
NO_WINDOW widgets, which means I want to share my parent's window, and
then they also create INPUT_ONLY windows to catch events.
This is a very useful pattern. Such widgets are basically saying:
- Just give me a nicely-prepared surface to draw on (i.e. with the
parent's contents already drawn)
- And let me catch events, too.
The funny thing is that not only non-square widgets like labels do
this; buttons also do this for aesthetic purposes.
I think it seems sane to move to a model where
1. The only native windows (with an XID) are toplevels, with a few
exceptions (see below),
2. All subwindows are all GDK-side abstractions. They define a clipping
region and a coordinate system. See below for transparency issues.
3. The exception is when you need a native window to do funky stuff
(OpenGL, plug/socket, xv, etc.). These (sub)windows are understood to
be limited - you may not be able to transform them and such.
The interesting part is (2), or what happens with subwindows.
Non-square widgets that want to paint to their parent's background would
still benefit from having a transparent window to paint on - this
would give you an already-prepared surface (with whatever the parent
painted), a clipping region and a coordinate system. That is, GtkLabel
wouldn't have to clip the text itself and add allocation-{x,y} all the
time.
Square widgets that completely cover their area are of course trivial to
implement in that model - they would just overwrite their parent's
contents with their own. I don't know if we want to be able to avoid
painting the parent's regions that we *know* will be completely
obscured. Think of a white text area over a gradient window background
- drawing that gradient may be expensive and so you certainly want to
paint only the areas that will *not* be the white text area... or maybe
not, if you can just ask the GPU to draw the whole gradient.
Do we need a window-need_parent_background flag? I.e. the paint the
parent first, don't clip to the subwindow flag?
I don't think these transparent windows should store any contents at
all to composite them later. GDK doesn't store window contents, and
starting to do that sounds painful. Keep subwindows just as an
abstraction for clipping/coordinates/initial-background.
With the model above, the repaint cycle looks pretty much like the
current one - you paint recursively, and you just set the clip region
(or not) based on a subwindow's need_parent_background flag.
- Does a GdkWindow describe a window hierarchy? Again, kinda. Mostly
you can restack and reparent windows fine, but stuffing a toplevel
into an offscreen window does not work at all.
- What's a GdkWindowType? When I restack a TOPLEVEL into a CHILD, will
it change type? Should it?
This is the core of Alex's argument for keeping the impls separate, I
think. GdkWindow exposes a public API (with a few leaks such as
gimme_the_native_window_id()); the internal impls switch in and out as
you reparent things.
Who uses reparenting, anyway?
Restacking our abstracted subwindows should be trivial; you just repaint
them in order.
- Can windows be translucent? Should they be?
See above.
- Is a GdkWindow the only way to get enter/leave events to widgets? Do
widget authors know these thing?
If they don't know offhand, they learn pretty fast :) Basically, having
a window is the *only* way to get events. Whether you do it with an
InputOutput or an InputOnly window depends on each particular widget.
- What do we do with event masks? I learned yesterday that widgets
without EXPOSURE_MASK don't get their background cleared. Is that
documented? Or should that even be the case? Do we even need event
masks?
Clearing the background or not depends on the hypothetical
is-this-window-transparent flag that we discussed above.
Event masks are an X-ism, I think... I really don't know if they matter
much with local connections (except maybe to save context switches);
they may definitely help in remote connections. Something tells me that
Owen will know more about this from when he was profiling GTK+'s X
stream.
- Shoud every widget have its own window now that we have lightweight
client-side windows? Or should almost no widget have a window because
we can synthethically create all the events widgets need? Do we have a
list for widget authors somewhere for when they want to create their
own window?
If we move to the model I described above, then it should be pretty
clear that all widgets can have windows (for convenience) and yet be
able to draw themselves as they wish.
But there are operations that
Re: cairo drawing commands to gdk_invalidate_region
On Tue, 2010-08-17 at 10:35 +0300, Dov Grobgeld wrote: Assume I have a routine: int draw(cairo_t *cr) used to draw an overlay in a GdkWindow. In order to minimize redrawing, I would like to get the minimal (up to some accuracy to be determined) set of GdkRegion's that encompasses all the drawing of draw(). You may have a different case, but let me tell you about a cute trick I had to do for iogrind [1]. One of iogrind's displays is essentially a point-cloud on which you move a crosshair with the mouse: +-+ | . . | . .. . . .| | . . . |.. . . . .| |-+---| |.. .. . |... . . . | | . . |. . .. .. | +-+ The crosshair spans the whole width and height of the widget. Drawing the points is expensive, as there may be thousands of them. With each mouse motion event, you must repaint the crosshair. My solution went like this: 1. The widget keeps a GdkPixmap where it draws the point-cloud at startup. The points don't move (thankfully), so that pixmap is basically read-only after initialization. 2. My motion-notify handler does this: invalidate_vertical_line (w-cursor_x); invalidate_horizontal_line (w-cursor_y); w-cursor_x = event-x; w-cursor_y = event-y; invalidate_vertical_line (w-cursor_x); invalidate_horizontal_line (w-cursor_y); 3. My expose handler does this: bitblt (w-pixmap_with_points, widget-window); paint_vertical_line (w-cursor_x); paint_horizontal_line (w-cursor_y); So, repaints are very fast as I can avoid regenerating the points; I basically just paint the crosshair and that's it. If your drawing can be done with mostly-static contents and an occasional rubberband rectangle, this is a good way to do it. [1] http://live.gnome.org/iogrind Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk_widget_draw()
On Tue, 2010-08-17 at 21:10 +0200, Alexander Larsson wrote: [Widgets with an InputOnly window for events] Yeah, they do it to avoid the window resize being asynchronous with respect to the repainting, etc, causing ugly looking resizes. Oh, I thought they did it to get the parent's background. So there are multiple reasons to do this :) This is exactly the current model with client side windows. Perfect, so we are on the same page and I just need to re-understand the current state of GDK :) Additionally I was thinking one could specify a border on the window such that for clipping purposes and calculation of what has to be repainted we grow the window by the border width, while for events and the rest we use the normal size. This makes it easy to implement themes that have a more organic look, for instance having a glow on an active button that extends outside the button without affecting events, etc. Do you need that? Can't you create a separate window overlaid on your button, and paint the glow on *that* one? (The window would extend past the normal window's edge; it would probably need the toplevel to be its parent so the glow can go over everything, etc. - but it sounds doable like that...) Do we need a window-need_parent_background flag? I.e. the paint the parent first, don't clip to the subwindow flag? Not sure what you mean. We need a single flag is this window transparent. If it is that means: 1) It does not add to its parents clip-region 2) When redrawing it we must draw all parents and lower stacked siblings before drawing it. Yes, that's exactly what I mean :) A single flag that does exactly that. Who uses reparenting, anyway? Dnd of toolbars items, detachable docks, putting plugs in sockets, etc. I don't think reparenting is needed for toolbar items and detachable docks - unless X forces you to do it to get really smooth painting. Plug/socket is special anyway, as you need to cross into the actual window system. [Anyway, this was about the impls being separate - if we keep reparenting, then impls may need to stay... no idea.] Event masks affect more than performance though. They are combined to decide which window gets each event. For instance, if you have a window somewhere with a bunch of child hierarchies, and the window has the event mask for mouse motion, then it will get mouse motion even over the child windows, unless the child window sets mask for mouse motion too. So, just sending everything everywhere is not a solution. Ah, OK :) I guess this is due to X not having event callbacks and the boolean means whether the callback handled the event thing... So, apart from the general pending cleanup, are we just lacking the don't clip flag discussed above for transparent windows? Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk_widget_draw()
On Mon, 2010-08-09 at 02:07 +0200, Benjamin Otte wrote: This is awesome stuff, Benjamin. I'll start with the end goal: gtk_widget_draw(GtkWidget *widget, cairo_t *cr); One thing I'd definitely like to have is the region-to-expose. Many times people have started with oh, I'll just paint everything every time, only to find later that this is too slow. Then they go and make use of the expose-rectangle or the finer expose-region, and things magically become fast. EOG uses this to good effect, for example - scaling an image is expensive, so it only scales the areas that absolutely need to be repainted. I don't know if you can get the clip path set on a cairo_t, but even if you can, getting a path is not ideal... a region made out of rectangles, like GdkRegion, seems more generally useful. 3) Resolution independence. A cairo_scale (cr, 2, 2) before calling gtk_widget_draw() smoothly scales widgets to twice the size. Of course, event translation and all that fun is needed, too, but the rendering part is there. Good drawing functions do their best to align things to the pixel grid, if it exists. Does Cairo let you know the device's resolution, or something that lets you know if the current transformation is pixel-aligned? (If I tell my resolution-independent desktop to scale itself by 1.73 times for my aging eyes, by using the friendly zoom factor slider that it provides, then I'd still like crisp widgets as best as possible.) 4) Make the window's surface gettable You might want to use a window as a source in drawing operations or do other stuff with it (like calling cairo_surface_create_similar() for the pixmap replacement) so this needs to be available. Arguably, Hmmm, is this related to GDK_NO_EXPOSE events? Such as you would get on the destination window if you gdk_draw_drawble() with the source being partially obscured. (Copying from window to window seems anachronistic these days, anyway... and if you can simply tell another widget/window to gtk_widget_draw() itself into our own temporary surface, you don't need cross-window blits.) 7) Improve repaint semantics Something like disallowing multiple being_paint_region() calls and disallowing the use of windows as a source while a repaint is happening sound very desirable to me. The code that circumvents these issues is quite extensive and buggy and noone uses these features anyway. Also, the Paintable interface should probably be folded back into GdkWindow, too. gdk_window_begin_paint_region() is just a convenient way of saying give me a temporary buffer with magic coordinates. We could very well have windows keep a stack of Cairo surfaces (or just a stack of clipping regions + transformations, etc.) that get flattened when the last gdk_window_end_paint() is called. Or maybe just make those functions basically be wrappers for cairo_save/restore() plus some clipping and coordinate-changing. Somewhat related to that is gdk_window_scroll(). Or does CSW handle that magically? You *definitely* want scrolling to be done as much in hardware as possible, at least for blitting the already-exposed region. You only want to repaint the scrolled-in area at any time. 11) Remove the expose_event from GtkWidget Now that the whole repaint handling is done in the draw signal, there's no more need for expose events. The semantics are somewhat different, as draw signals don't correspond 1:1 to expose events. But I think that change shouldn't matter for all practical purposes. And if you need it, you can just connect to the event signal of the GdkWindow. This seems very clean - native windows send you events; widgets translate that to draw signals as appropriate. Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk_widget_draw()
On Tue, 2010-08-10 at 01:59 +0200, Benjamin Otte wrote: [Widgets that own multiple windows] My current idea on how to implement it is to give the widgets a hint as to wether they are repainting a window or wether they are painting to something else. Something like gdk_cairo_get_current_window() which would return the currently invalidating GdkWindow or NULL. That would basically replace event-window and then all you need to do is check that the order of the draw calls is the window's stacking order and you're all set. If gtk_widget_draw(w, cr) really means paint thyself, then we need to make widgets with subwindows have no extra work to do. Let me throw some ideas: - If you have an event signal in GdkWindow, like you proposed, then we can make widgets responsible for connecting to their subwindows. In theory the (client-side) window system will send those signals in Z order. We may need a hint to say send me an expose for this parent window even if a child window obscures it for if you want to have transparent windows - you want the parent to paint its background, and then the child to overlay its stuff. - We can have gtk_widget_register_subwindow(w, window), called by widget implementations. Then the stock GtkWidget code magically connects to expose on those GdkWindows, and calls ::draw() as appropriate. I guess this is roughly similar to moving gdk_window_set_user_data() into GTK rather than GDK. Then the draw method would be called with a clip region set to the appropriate subwindow, or something. I like the second idea better. The summary is that even widgets with subwindows should really paint everything to whatever is on the cairo_t passed to draw(). Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Empty containers and border_width
On Wed, 2010-04-21 at 05:23 -0400, Tristan Van Berkom wrote: Containers that expect to be empty at times should simply be aware of their padding. Yeah, good points. People do use empty containers (alignments and such) to add indentation for sections in configuration dialogs. So I won't change anything, just fix GtkTable's row/column spacings as described in my other mail. Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
[Fwd: gtk+ wrong code in JPEG loading module]
This landed in my inbox - has anyone played with new versions of libjpeg
to see if this works?
Federico
---BeginMessage---
Hello all
This is a report to the authors mentioned in the gdk-pixbuf/io-jpeg.c
module of the current gtk+ 2.18.0 package,
from Guido Vollbeding, organizer Independent JPEG Group.
I'm sorry if this way is inappropriate, but I'm not involved in any
forums or mailing lists. Please forward to whom it may concern if
possible.
I have noticed various complaints about weird display of JPEG images
with applications depending on gtk+ after upgrading to the new IJG
JPEG 7 version, and I have seen faulty patches to the above mentioned
module to work around the problem.
I have now looked through the code and found the flawed code sequence
in function gdk_pixbuf__jpeg_image_load_increment.
I strongly advise to correct the code by simply inserting the statement
cinfo-scale_num = 1;
in front of the following code sequence in mentioned function:
for (cinfo-scale_denom = 2; cinfo-scale_denom = 8;
cinfo-scale_denom *= 2) {
jpeg_calc_output_dimensions (cinfo);
if (cinfo-output_width width || cinfo-output_height
height) {
cinfo-scale_denom /= 2;
break;
}
}
jpeg_calc_output_dimensions (cinfo);
This addition will work with older and newer versions of the library.
The implicit assumption of the given code that cinfo-scale_num is
initialized with 1 by the JPEG library is no longer true for versions
7 and later! Version 7 initializes this field (and the other) with 8,
and version 8 and later will initialize the fields with the (variable
from 1 to 16) block size of the given JPEG file. (Note that the
default resulting scaling factor remains 1 in any case.)
The usual recommendation for versions up to 6 has always been that
scale_num and scale_denom be set *simultaneously* by the calling
application. Applications following this recommendation will not
suffer an incompatibility with newer JPEG library versions.
Newer applications (written for JPEG library versions 7 and later)
MAY choose to set only one of both fields, because the initialization
defaults are now depending on the input file and are specified as
mentioned above.
The given correction code simply retains the same behaviour with
new JPEG library versions as with old JPEG library versions.
The code may later be revised to utilize the more flexible scaling
choices of v7 and later, but there is no need to do this now.
I have not verified other code in the module.
But this part is clearly wrong for use with newer JPEG library
versions and requires correction, as it may affect a lot of gtk+
dependent applications.
Regards
Guido Vollbeding
Organizer Independent JPEG Group
---End Message---
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: filesystemmodel branch - initial testing
On Thu, 2009-10-01 at 01:48 +0100, Bastien Nocera wrote: Not having looked at the code since the original patches, have all the concerns about the possible regressions and incremental changes been addressed? I did a *very* careful review of the code, and it seems sane. If you look at the filesystemmodel branch, you'll see essentially these commits: - one-shot rewrite of GtkFileSystemModel - Company's extra fixes, adapting GtkFileChooserDefault to use it - Cleanup of GtkFileChooserDefault to make recent/search use the model - Federico's nitpicks, cleanups, a few bug fixes - A big in-source comment explaining how the new model works Basically, I'm happy that we have a) at least two people who know how the model works; b) documentation on it, for posterity. We had neither of those with the old GtkFileSystemModel :) I hope there will be no be regressions with the file chooser's behavior; the code doesn't touch that. It's all concerned with how the file list is shown. Of course, help with testing is much appreciated. I'll merge master to the filesystemmodel branch to get in the unrelated fixes in master, and then you can test that easily. Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: filesystemmodel branch - initial testing
On Thu, 2009-10-01 at 11:20 -0400, Matthias Clasen wrote: If the improvements are as impressive as Federico makes them sound, then I think getting them into 2.18 (and thus out to users) would be a nice thing, imo. Basically, before the filesystemmodel branch, I dreaded using the file chooser to visit my ~ or ~/Downloads (two big dumpsters in my file system). Now both appear semi-instantaneously after clicking on those folders, and they are not slowed down by loading thumbnails (something which was a big problem for me before). An eyeballed test in a directory of 10K empty files showed 3 seconds for the new branch, versus 9 seconds for the old branch. I'd love it if people could test slow networked directories. Of course, there is some risk, so we need to test and review carefully. But Federico is doing that, and I'll look over the patch myself, too. Sure, thanks. You may want to start by reading the big comment near the beginning of gtkfilesystemmodel.c, and then by looking at the actual code. Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
filesystemmodel branch - initial testing
Humans from Earth, I'm finally testing Company's filesystemmodel branch. IT IS SO FAST! Really, it makes the file chooser much snappier. And the code is a pleasure to read. I haven't had crashes yet, although I haven't tested all the features in the file chooser. I guess I'll keep testing it for a week or so. Matthias mentioned that he's interested in merging this to master before the .2 release. I'm extremely happy with Company's work - he deserves a lot of beer and pats on the back. Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [patch] batch scanlines when loading JPEG...
On Fri, 2009-08-28 at 16:12 +0100, Daniel J Blueman wrote: I've written and tested a small patch that increases efficiency (particularly in small-cache systems) of loading JPEG images: override the recommended lines with what we've already allocated; increase batch size from 4 to 8 lines. Thanks for trying to make JPEG loading faster; we could certainly use that :) A few comments: First, did you actually test that patch (did you send the wrong one)? The last hunk doesn't compile: + /* batch line updates f or efficiency */ + cinfo-rec_outbuf_height = cinfo.rec_outbuf_height LINEBUF_SIZE ? cinfo.rec_outbuf_height : LINEBUF_SIZE; + That should be cinfo-blah instead of cinfo.blah. Second, that test looks wrong: cinfo.rec_outbuf_height = cinfo.rec_outbuf_height LINEBUF_SIZE ? cinfo.rec_outbuf_height : LINEBUF_SIZE; I just checked the libjpeg sources and it will never return cinfo.rec_outbuf_height larger than 4. Thus, the test is redundant. However, if libjpeg ever changes and sets rec_outbuf_height to something larger than our LINEBUF_SIZE, you'll be trampling over memory as the lines array is not big enough. Third, I ran a quick benchmark with /usr/bin/time eog image.jpg for a 39 MB JPEG (a 11299x10764-pixel satellite image which expands t o about 360 MB in RAM). Both without your patch and with the patch, it loads consistently in about 11.3 seconds. I couldn't measure any difference. Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: A tale of waiting
On Tue, 2009-06-23 at 22:16 +0200, Benjamin Otte wrote: I have been on a quest to improve performance of the file chooser First, thanks for taking on this work. Kill GtkFileSystem is a very worthwhile goal. * The sort function was called way too often. So I added the option to freeze and thaw the tree view. Now the sort function was only called once or twice. Hmm. I haven't read your branch yet, but some things I remember from profiling the file chooser a while ago: - It's pretty bad that GtkTreeModel only has row-inserted for a single row, instead of rows-inserted --- it gives you automatic insertion sort, which sucks. So for every single file we read in, the treeview has quite a bit of machinery to run. This is why (at least before the GIO work; I don't know about the current state) I made the file chooser do this: 1. Start with an empty model not hooked to the treeview. 2. Start a timer. 2. Start loading a folder and populating the model. 3. If the timer expires, put the model into the treeview. 4. If the folder finishes loading before the timer expires, put the model into the treeview. That's the LoadState enumeration, by the way. Ideally, small folders will be completely populated into the model before the timer expires. We can work on making this as fast as possible, and *then* work on what happens when the poor model actually gets put inside the treeview. What is left to do? * * reimplement directory monitoring. I did never get around adding that code. Don't worry about this. We can have a custom model, just for directory trees, once we decide to delve into that for SELECT_FOLDER mode. * evaluate fixed height mode for the tree view, it might make things even faster without losing features. Hmmm, do we use the automatic-column-widths thing? That should definitely be turned off; we can hardcode an initial starting width of N ems to avoid measuring all the rows. * port search and recent files to GtkFileSystemModel, to get rid of more special casing code and make them faster. (Woohoo!) I'm not 100% convinced that this is the right thing to do, but I'll read your branch before commenting :) * The async implementation of g_file_enumerator_next_files_async() is very suboptimal, as it stops after N files are enumerated, and waits for another call to the function to resume. See the thing above about the use of a timer. We should be able to call that function several times before the timer expires, and still avoid re-sorting because the model is not yet in the treeview. And now the obvious question: Should I just merge it to master when I'm done with the regressions? Please give me some time to review this. Will you be at GCDS? I'd love to do patch review together. Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk+ merges
On Wed, 2009-06-03 at 22:16 -0400, Matthias Clasen wrote: As a data point, I've also preferred to go with cherry-picking from master so far. It just seems closer to the way I'm working with our branches. OK, no big deal... I'll cherry-pick in the future. Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkPlug not chaining up to GtkWindow's keys_changed handler?
On Sat, 2009-04-18 at 17:22 -0400, Yu Feng wrote: In GTK 2.14.4, GtkPlug does not chain up to GtkWindow's keys_changed handler. (gtkplug.c:1043 and gtkwindow.c:7937) The effect is that the key hash in the 'gtk-window-key-hash' data member of the window is not updated whenever the mnemonic keys are changed, and any newly associated mnemonic keys are ignored. Are there any particular reasons for this behavior or it is an honest typo? It could be a typo/oversight/etc. This is not the first time that GtkPlug has had a bug due to failing to sync up with GtkWindow. Do you have a little reproducible test case for this problem? Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: fsync in glib/gio
On Fri, 2009-03-13 at 09:15 -0400, Morten Welinder wrote: F*** POSIX allows this! A program that does open-write-close- rename should not be left with an empty file in case something goes wrong. The old file, or the new file. Anything else is insane and by extension the kernel developers and their ancestors. 100% agreed. Has anyone actually debugged why this happens? The kernel must surely ensure that even if it reorders data/metadata requests, it will do so in sensible ways only, doesn't it? Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: fsync in glib/gio
On Fri, 2009-03-13 at 22:16 +0100, Alexander Larsson wrote: Its well explained in the various discussions about this. Essentially, the metadata for the rename is written to disk, but the data in the file is not (yet, due to delayed allocation) and then the system crashes. On fsck we discover the file is broken (no data) and set the file size to 0. This reminds me a lot of http://bugzilla.gnome.org/show_bug.cgi?id=562396 - a problem with Nautilus metadata. You start a copy operation, but if you do a read before the copy is done, then you get the old data. You should wait for the copy to be done first, but anyway, my point is... My point is that the kernel could perfectly well ensure that metadata operations that depend on data operations will not be reordered. Don't rename a file in a directory if we have outstanding writes for the inode, or something. (After the rename, do you need to open the directory and fsync it? You can't open directories for writing...) Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Bikeshedding the invisible-char
Fedora has a (currently unapplied?) patch in its gtk2 package which changes GtkEntry's invisible-char defualt from * to • (Unicode 0x2022 BULLET). openSUSE has a patch that changes the invisible-char to ● (Unicode 0x25CF BLACK CIRCLE). I'm arguing for committing openSUSE's patch based on the following unquestionable criteria: * The circle is bigger. This goes hand in hand with Christopher Alexander's Nature of Order principles of Strong Centers, Good Shape, and Contrast. * The circle is fatter. We should have a no-discrimination policy against Unicode glyphs with an above-average body mass index, I mean, the ink-to-area ratio. * The circle is BIGGER. Size does matter, you know. * I started the bikeshed. Really, it doesn't make sense to carry around patches like these :) OK to commit? Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Bikeshedding the invisible-char
On Tue, 2009-01-20 at 04:14 +0200, Xan Lopez wrote: How is this different from bug http://bugzilla.gnome.org/show_bug.cgi?id=83935 that was committed some months ago? It even uses your favorite character! Argh, I'm an idiot. As usual, Garnacho created the perfect patch. What happened is that someone asked me, why is openSUSE's patch not upstream yet?, and I looked... the patch is basically invisible_char = g_object_create_property (invisible-char, - *, + ●, but I didn't RTFS to see the new find_invisible_char() magic :) Sorry about the noise, Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: proposal: substantial change to keyboard-driven action handling
On Tue, 2008-05-06 at 10:47 -0400, Paul Davis wrote: Any given GtkWidget has zero or more maps that connect a key event tuple to a closure. When a key event is received by a GtkWindow, the window first allows the focus widget to look up an event in its map(s) of tuples/closures. If the event matches a given tuple, the closure is invoked. If there is no focus widget or the focus widget does not report that the key event has been handled, the GtkWindow does the lookup in its own map(s). ignorant Some people have mentioned that the DOM way of passing events first down and then up in the hierarchy (or was it the other way around?) would be very useful to GTK+. Something tells me that this should be tied to your proposal, but I'm not sure how :) /ignorant [I know I've had to do some hacks in the past to deal with keyboard accelerators that weren't being processed at the right spot in the hierarchy... no real idea if that could have been helped with the scheme above.] Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: problem finding the position of a button in the gtk dialog ( sample code inside )
On Wed, 2008-05-07 at 11:33 +0530, chirag juneja wrote:
approach i am using is :
i will find the distance of the button from its parent, and then its
parent's distance form its parent .. and so on, till i get toplevel
window.
then i am adding the decoration's height, border's width and distance
of top level window from origin of root window(0,0).
That's a lot of overkill :) You can simply do
void
get_absolute_position (GtkWidget *widget, int *ret_x, int *ret_y)
{
GdkWindow *parent;
int parent_x, parent_y;
parent = gtk_widget_get_parent_window (widget);
gdk_window_get_origin (parent, parent_x, parent_y);
*ret_x = parent_x + widget-allocation.x;
*ret_y = parent_y + widget-allocation.y;
}
Federico
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gdk patch review request
On Wed, 2008-05-14 at 15:31 +0200, Danny Baumann wrote: since a couple of weeks, I have two patches pending in Bugzilla that fix problems which seemingly are bugs in Compiz, but actually are Gdk problems. As we (== Compiz people) are getting quite some bug reports about both issues, I want to ask if anyone around here can review those patches so they can be included (and Compiz users can get happy ;-) ). Both of them should be pretty straightforward. Bugzilla links are: http://bugzilla.gnome.org/show_bug.cgi?id=522269 http://bugzilla.gnome.org/show_bug.cgi?id=524110 #524110 is on my hit list for the corresponding bug in openSUSE: https://bugzilla.novell.com/show_bug.cgi?id=342595 So please give me a few days to get to it, and I'll see if it is suitable for GDK :) Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Moving Open with to the platform
Hi, Right now, the Open with another application dialog lives in nautilus/libnautilus-private/nautilus-open-with-dialog.[ch]. This dialog uses the machinery in GIO's GAppInfo to figure out which apps can be used to open a file of a certain MIME-type. There's a long-standing annoyance in Firefox, where it implements open with by starting a file chooser in /usr/bin. Now, if you complain about the file chooser *right here* I will ignore your mail :) My point is that it would be nice if the open with GUI were available to all apps, not just Nautilus. We could do a few things: * Move nautilus-open-with-dialog.[ch] into GTK+. From a super-quick read of the code, this uses no Nautilus-only stuff except for some of libeel's convenience error dialogs, and some the MIME info changed signal. * Leave the dialog in place inside Nautilus, and provide a D-Bus service for the open with GUI. I'm 51% leaning towards this option, since then this would have a chance of working with a desktop-specific GUI, depending on your choice of desktop environment --- aside from promoting the use of D-Bus for this kind of stuff. Thoughts? Oh my god, this is a nice little project for the Summer of Code... it would involve figuring out the above, and also changing Firefox to use it :) Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: visibility-notify-event query
On Sun, 2008-03-16 at 21:06 -0700, iluvlinux wrote: i have a question regarding visibility-notify-event If i add widgets to a container than i get the signal visibility-notify-event, whenever visibility changes but if i add widgets to a scrolledwindow i donot get visibility-notify-event for the widgets that have scrolled up ie not visible nor i get unmap signal. What widgets are you putting in there? If they are no-window widgets, they may not get the visibility-notify event, as the underlying window (which belongs to the scrolled window) is still visible. Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
g_format_file_size_for_display()
Should this be called generically g_format_size_for_display()? You could use it for more than file sizes (free RAM in gnome-system-monitor, etc.). Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: g_format_file_size_for_display()
On Tue, 2007-12-18 at 16:45 -0500, David Zeuthen wrote: char *g_format_file_size_for_display (goffset size); Ideally this one needs to take another parameter indicating whether you want 1kb = 1000 bytes or 1kb = 1024 bytes. No, because then you'll have applications using either, and then someone will want to make them consistent and we'll get an option in the control center an an XSETTING, which is yet another thing we'll have to port over when moving from GConf to DConf, and it's just a big fat mess. The reason is that we want to generate nice display names in the volume monitor; for ordinary media you want 1000 (to match the label on the media); for optical discs you normally want 1024. gnome-vfs has this terrible bug where it uses 1024 so you get the label 61.2 MB media even when the media itself says 64MB. This is kinda like punching the user right in the face. It's not a mistake we should make for the new shiny gvfs stuff. Big deal :) When you see 61.2 MB you think, oh, file system overhead! ripples in the time-space continuum. Nobody cares about that. Back to my original question: should this function be called g_format_size_for_display()? It's not for files only. [Who's the nitpicker: the one who asks for file sizes versus general sizes or the one who asks about SI units vs. computer units...] Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Vertical position of text in under-allocated labels
Hi, We have a problem in gnome-main-menu which is (understandably) a corner case in GtkLabel ( https://bugzilla.novell.com/show_bug.cgi?id=310710 ) First, please see no-focus.png (attached). That is main-menu's Computer button and a button from the task list applet. You'll see that the labels don't line up, and the Computer text appears clipped (the descender of the p is gone). This happens for the following reasons: * The Computer button has normal values for focus padding and focus line width. In focus.png (attached) you can see the focused button; the button must be focusable for a11y reasons. * The task list sets the style of its buttons to have zero-width and zero-padding for the focus (and its buttons don't seem to be focusable at all). * The Computer label ends up getting an allocation which shorter than its requisition in the Y direction. When GtkLabel comes to gtklabel.c:get_layout_location(), specifically here: y = floor (widget-allocation.y + (gint)misc-ypad + MAX (((widget-allocation.height - widget-requisition.height) * misc-yalign), 0)); It ends up always positioning the label text at or below its allocation.y. This is usually the right thing, but gives bad results when the label is under-allocated *and* centered: the end result definitely doesn't *look* centered --- there's visually enough room for the text inside the button. I did a little digging and found this: http://bugzilla.gnome.org/show_bug.cgi?id=71742 That's when GtkLabel was made to show as much of the text as possible when it is under-allocated. Søren's patch indeed seems to do the right thing for the label's horizontal position, but I think for the vertical position it could very well just center the requisition within the allocation (or use whatever the alignment specifies). This may only work well for single-line labels, and it would fix the problem for the Computer button. For multi-line labels, I think the rationale of showing the top of the text is better. Does this make sense? I'll cook a patch to test it, but first I wanted to confirm with people who have given more thought to this. Federico attachment: no-focus.pngattachment: focus.png___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Vertical position of text in under-allocated labels
.. And here is a patch which fixes the problem in main-menu. Federico 2007-12-17 Federico Mena Quintero [EMAIL PROTECTED] * gtk/gtklabel.c (get_layout_location): For single-line labels, align the requisition to the allocation unconditionally, even if we are under-allocated. For multi-line labels, try to show the top of the text as before. Fixes https://bugzilla.novell.com/show_bug.cgi?id=310710 diff --git a/gtk/gtklabel.c b/gtk/gtklabel.c index cd6c5ac..6e38a7d 100644 --- a/gtk/gtklabel.c +++ b/gtk/gtklabel.c @@ -2362,9 +2362,17 @@ get_layout_location (GtkLabel *label, else x = MIN (x, widget-allocation.x + widget-allocation.width - misc-xpad); - y = floor (widget-allocation.y + (gint)misc-ypad - + MAX (((widget-allocation.height - widget-requisition.height) * misc-yalign), - 0)); + /* For single-line labels, *do* align the requisition with respect to the allocation, even + * if we are under-allocated. For multi-line labels, always show the top of the text when + * they are under-allocated. + */ + if (pango_layout_get_line_count (label-layout) == 1) +y = floor (widget-allocation.y + (gint)misc-ypad + + (widget-allocation.height - widget-requisition.height) * misc-yalign); + else +y = floor (widget-allocation.y + (gint)misc-ypad + + MAX (((widget-allocation.height - widget-requisition.height) * misc-yalign), + 0)); if (xp) *xp = x; ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GdkPixbuf vs. Cairo, new image library needed?
On Mon, 2007-10-15 at 09:04 -0700, Carl Worth wrote: On Sat, 13 Oct 2007 00:51:44 +, =?ISO-8859-1?Q?BJ=F6rn_Lindqvist?= wrote: I have played around with Cairo some more and it seems to me that it is not fully ready yet. :( Cairo blits and scales much slower than gdk-pixbuf (software that is) Do you have some simple test cases to demonstrate this so we can identify and fix anything necessary in cairo? This would be a pretty interesting benchmark. Any takers? :) and doesn't support as good-looking bilinear filtering that gdk-pixbuf does. The scaling code in cairo, (for downscaling by factors greater than 2), could definitely use some improvement, (the current result is embarrassingly ugly). But what GdkPixbuf does here is actively bad for performance. I'd like to see some middle-ground implementation. GdkPixbuf's scaling functions provide *very* nice results when downscaling with GDK_INTERP_BILINEAR, though they are slow as you say. High quality, but slow (for slow == way slower than no interpolation, or I can't do 30 FPS for an image the size of my whole screen). I don't really know if there is a good, general solution for this. There are several cases: - Downscaling things once, like when generating a bunch of thumbnails or scaling down big-wallpaper-1600x1200.png into something that fits in your puny 1024x768 screen. There's not much you can do here except profiling the heck out of your one-time scaling algorithms. - Downscaling things continuously, say, when interactively zooming in an image viewer. A stateful mip-map would help here, so you don't have to recompute everything on every change of scale. Note that you can play tricks here: EOG's beautiful zooming comes from doing a quick atomic pass with no interpolation, and then doing bilinear interpolation of small tiles in an interruptible fashion. - People forget that high quality rendering and good performance are at opposite sides of the scale :) High-quality downscaling simply requires you to look at a lot of source pixels to generate each destination pixel. Often people want to replay trivial code in their repaint functions, such as taking a huge image, downscaling it, and painting it. It's better to scale image *once* and then reuse the result when you repaint. That makes the program's logic more complicated, but that's life. Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: let g_warn_if_fail replace g_assert
On Wed, 2007-10-17 at 11:56 +0200, Tim Janik wrote: - extend the g_assert() docs to note that: 1) programmers are more likely to want to use g_warn_if_fail instead (particularly for libraries, allthough the destabilizing effects of g_assert are also worth avoiding in applicaiton code); This is the part I don't like. Making failed sanity checks not exit the program will *not* make your program more robust; it will just make people ignore broken programs. Nobody paid attention to critical warnings until we started actively crashing programs that printed them during development versions --- grep for g_log_set_always_fatal() in gnome-session/main.c. Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: turning g_assert* into warnings
On Fri, 2007-10-12 at 11:52 +0200, Tim Janik wrote:
i'd like to propose to turn g_assert and friends like g_assert_not_reached
into warnings instead of errors. i'll give a bit of background before the
details though.
the main reasons we use g_return_if_fail massively throughout the glib and
gtk+ code base is that it catches API misuses verbosely and gives programmers
a chance to fix their code. this could be achieved with either a g_warning
(mourn on stderr) or a g_error (mourn and abort).
g_return_*if_fail() is a filter: I don't want crap to come into my
library. As you said, it's intended for programmers to fix their code
when they use libraries.
g_assert(), on the other hand, is a hard pre/post-condition. It is if
this is false, then my program is fucked up. There is *nothing* you
can do... user data may already be corrupt or you will likely screw it
up soon enough. It's better to crash right there.
The idea is that you code libraries like this:
int
find_index_of_thingy (DataStructure *foo, Thingy thingy)
{
int i;
Bar bar;
g_return_val_if_fail (foo != NULL, -1);
i = 0;
bar = foo-bar;
while (bar) {
g_assert (bar-eek != NULL);
if (are_the_same (thingy == bar-eek))
return i;
i++;
bar = next_bar (bar);
}
}
I.e. if the public function gets called with bogus data, you return
immediately and print a warning, so that the programmer will fix his
code. It will probably crash anyway if the messy programmer didn't
check the return value.
On the other hand, the assertion is an internal sanity check within the
library. If the data structure contains a NULL bar-eek, it *REALLY*
means that something got fucked up earlier, and it's better to crash
right there, because you don't know *WHAT* is corrupt.
c) programs that aren't 100% bug free could possibly trigger these warnings
during production. aborting would take all the end user data with it,
created/modified images, text documents, etc.
issuing just a warnig preserves the possibility to still save crucial
data if the application logic state still permits (which is most often
the case in practice).
This is just a symptom of an unrobust program. You can't make a program
more robust by ignoring error cases, which is what your proposal is
about. You may make it more *resilient* temporarily, but by then who
knows if you'll be saving bogus data.
Programs which deal with critical data (I'd say any kind of document is
critical) should really just implement auto-save. If the bug is in
libsavemydata.so, well, life is hard...
for a few reasons:
1) allow users to save their data if still possible; i.e. (c) from above.
So... which program crashed on you, losing your unsaved data, which
caused you to start this discussion? :)
2) for glib/gtk+ unit tests (more on that later), failing but
non-aborting tests are interesting for overall report generation; and the
ability to force immediate aborts for debugging is preserved with
--g-fatal-warninngs.
*shrug*. A crashed test means the test suite failed :)
It may be mildly interesting to know the test suite failed because
test_123() would have crashed, but why would you be releasing with test
suites that don't pass, anyway?
3) assertions can help to document programmer intentions and frequent (but
regulated) use as we have it with g_return_if_fail can significantly
reduce debugging time. i have so far been fairly strict about not adding
assertions to the glib/gtk+ core though, because they also tend to make
the code and end-user experiences more brittle, especially an
occasional wrong assertions that'd have to be revoked upon closer
inspection.
A wrong assertion is just a bug like any other. It means uuh, I wasn't
sure of the state my program may be in at this point, so I'll assert()
that it has the state I think it should have, and I'll fix it if it
crashes later. It just indicates a sloppy programmer who should have
used a test suite with better code coverage :)
I've been guilty of wrong assertions in the past, and the description
above is *exactly* what happened to me --- laziness to *really* figure
out the implications of the code flow.
as a side note, it'd probably make sense to present the end users with more
prominent warnings if one of his applications ran into a glib warning/
critical/assertion, and he should be notified about needing to save
his data and exit ASAP. but that's really another topic, probably
best tackled by gnome.
That's actually a nice idea, and would help get problems like fooapp
spews thousands of the same g_warning() and .xsession-errors fills up
fixed more quickly.
Federico
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Theory of good signal/event API design?
On Sun, 2007-09-16 at 18:28 +0200, Sander Marechal wrote: My question: How do I determine what signals/events I should send out so that together they make for a nice module API? For now, I am simply building modules and adding signals to the application as I need them, but I bet there is a better way to figure out which signals I should add and where I should add them. You can think of signals in different ways: * Something happened - an informational message. Oh, the Loader object said 'finished', so it's done. You'd then process the loaded data or something. * I need something from somewhere - an actual request that must be handled. Oh, the HTMLWidget said 'load-image' and gave me a URI, so I guess I should download that image and feed it to the widget. * Something bad happened - an error in an object that handles a long-running process. Oh, the ImageDecoder emitted 'error' with a CORRUPTED_DATA argument, so that image file must be broken. * etc. So you can have signals that are hooks for expansion, actual requests for information, simple notifications, etc. One big thing to think about when you have signals is whether your object should be reentrant. What happens if someone calls a method on your object from a signal handler for that object? Should the object support it or not? Does it need to support at least minimal reentrancy (e.g. to let you call foo_delete_item() when you are inside a foo::item_inserted signal handler)? Federico ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: How to detect display speed in custom widget?
On Thu, 2007-09-06 at 20:47 -0700, Daniel Yek wrote: I'm wondering if anybody is experienced in writing smart widget that would react differently depending on whether the current display is local/fast for graphics animation or remote/slow where all animation should be kept to the minimum? What techniques are suitable for drawing speed detection? The cheapest hack is probably to see if the X server supports the MITSHM extension. If it doesn't, odds are you are on a remote display. [This assumption breaks under VNC, but I guess that's pretty hard to detect anyway.] Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Theory of good signal/event API design?
On Sun, 2007-09-16 at 18:28 +0200, Sander Marechal wrote: My question: How do I determine what signals/events I should send out so that together they make for a nice module API? For now, I am simply building modules and adding signals to the application as I need them, but I bet there is a better way to figure out which signals I should add and where I should add them. You can think of signals in different ways: * Something happened - an informational message. Oh, the Loader object said 'finished', so it's done. You'd then process the loaded data or something. * I need something from somewhere - an actual request that must be handled. Oh, the HTMLWidget said 'load-image' and gave me a URI, so I guess I should download that image and feed it to the widget. * Something bad happened - an error in an object that handles a long-running process. Oh, the ImageDecoder emitted 'error' with a CORRUPTED_DATA argument, so that image file must be broken. * etc. So you can have signals that are hooks for expansion, actual requests for information, simple notifications, etc. One big thing to think about when you have signals is whether your object should be reentrant. What happens if someone calls a method on your object from a signal handler for that object? Should the object support it or not? Does it need to support at least minimal reentrancy (e.g. to let you call foo_delete_item() when you are inside a foo::item_inserted signal handler)? Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Abstract string properties with getter/setter functions
On Thu, 2007-09-20 at 08:34 +0200, Raffaele Sandrini wrote:
Take a look at 'gtk_file_chooser_get_preview_widget'. While the hack
done there is somehow possible with objects it is not with strings.
GtkWidget *
gtk_file_chooser_get_preview_widget (GtkFileChooser *chooser)
{
GtkWidget *preview_widget;
g_return_val_if_fail (GTK_IS_FILE_CHOOSER (chooser), NULL);
g_object_get (chooser, preview-widget, preview_widget, NULL);
/* Horrid hack; g_object_get() refs returned objects but
* that contradicts the memory management conventions
* for accessors.
*/
if (preview_widget)
g_object_unref (preview_widget);
return preview_widget;
}
By the way, this is a *TERRIBLE* idea. I don't remember why I wrote the
code that way. Please don't follow that broken pattern.
[In the file chooser it works because the GtkFileChooser implementation
always holds a reference to the preview widget.]
It's much easier to write things if you always get a new reference from
accessors.
Federico
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Blacklisting themes?
On Wed, 2007-07-04 at 01:48 +0200, Milosz Derezynski wrote: Reminds me all of http://bugzilla.gnome.org/show_bug.cgi?id=326249 I'm not sure this ever got a proper audit and all themes in general could need one. Hmm, didn't that get fixed? At least for the well-known themes? Does there exist a unittest suite for theme engines (and yeah i gues i just volunteered to write one if it doesn't. heh :) ? AFAIK there's just Manu Cornet's torture test. It's not a unit test, but more of a does the engine crash when it gets passed funny values?. Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Blacklisting themes?
On Fri, 2007-06-22 at 09:20 -0400, Jody Goldberg wrote: I don't think Morten's intent was to handle the blacklist at the application level. A more practical approach would be a bugbuddy extension that would compare the current theme engine and version against a central collection of known bad engines, aka a black list. Then a user could be notified at the time of the crash that the right solution is to stop using that theme. This is certainly a nice idea --- although then people would need a newer version of BugBuddy ;) Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Blacklisting themes?
On Tue, 2007-06-19 at 15:08 -0400, Morten Welinder wrote: 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. So the sequence goes: 1. User gets a crash in gnumeric-n.m, reports it. 2. Developer determines that the crash is in the theme engine. 3. Developer blacklists the theme engine; releases gnumeric-n.m+1 4. User updates gnumeric, and can't run it anymore because it barfs on that engine. He still risks crashes in other apps. I don't think blacklisting will work due to (4). If you require the user to upgrade the app, then the user may as well update the theme engine, too. It's better to tell the user you should really update your theme engine; that will fix his problem and prevent crashes in other apps as well. It would be better to capture the thing that caused this particular bug, and to make Manu Cornet's theme engine torturer replicate it. That way people can run their theme engines through the torturer before releasing them. Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Warning about reaped children
On Tue, 2007-05-22 at 13:32 -0400, Matthias Clasen wrote: On 3/29/07, Federico Mena Quintero [EMAIL PROTECTED] wrote: Hi, I forgot to pass G_SPAWN_DO_NOT_REAP_CHILD to g_spawn_async_with_pipes() and ended up scratching my head about why my GChildWatch callback wasn't firing. After some hot strace action and RTFM, I added that flag and everything worked perfectly. Do we need a warning like the one in the attached patch? Sounds like a good idea to me. Hmm, Tim had a few objections: http://mail.gnome.org/archives/gtk-devel-list/2007-April/msg00037.html Though I think the common case is that one *isn't* doing the things that could cause waitpid() to return ECHILD --- so the warning would be adequate. Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Tap and Hold API
On Wed, 2007-05-02 at 16:34 +0200, Tim Janik wrote: [excellent analysis snipped] so i'd say that tap-and-hold expiration is one of the rarer cases, where one should always use GDK_CURRENT_TIME for menu popups. that in turn means there's no point in carrying across a time stamp (which would be outdated or misleading anyway) in the tap-and-hold API. it might make sense to add this consideration to the docs though. Yeah, very good point - I hate that constant because it makes for buggy programs, but this seems to be one of the very few cases where it is indeed the right thing :) The docs for tap-and-hold should definitely mention that you should use GDK_CURRENT_TIME for your popup's timestamp. Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Tap and Hold API
On Fri, 2007-05-04 at 12:15 +0200, Kristian Rietveld wrote: On Tue, May 01, 2007 at 07:47:25PM -0500, Federico Mena Quintero wrote: You have two tap-and-hold actions: pop up a menu and pop up a tooltip with extra info. Should those have the same I'm armed animations? Yes, I would say that for both of those actions the animations should be the same; for both of them the user is holding down the stylus and you want to show the same indication that the system is doing something with that action regardless of what will show up next. Okay, then. So you should follow the current fashion of posting a video of this in action, so that we can a) drool at your sexy handheld gadgets, and b) drool at the APIs :) tap-and-hold-keysym = FunkyKey in your ~/.gtkrc? Yes, but probably with a default key combination in GTK+ modifiable via key themes. Are there handheld thingies besides Nokias which have a similar immediate tap-and-hold key? One of those pushable-wheel thingies may let you change the focus by rotating the wheel, then immediate-tap-and-hold by pressing the wheel (then pick a menu item with the wheel again). I think I want one now. Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Fixing the GtkTreeModel::row-deleted inconsistency
On Thu, 2007-05-10 at 17:04 +0200, Kristian Rietveld wrote: There are no clear rules for this, actually. Most simple models don't have a real use for this. The filter and sort models both use this mechanism to keep track of which levels to cache and monitor. Models which reference external objects might want to use it. A node is referenced when it is visible. In the rule all expanded nodes count as visible; all nodes which are in GtkTreeView's internal rbtree are referenced. So in general - A node is referenced if it is within the scrolled-in area of the view. - A node is referenced if it is expanded, even if it is not within the scrolled-in area (i.e. everything which the rbtree mirrors is reffed). Is that correct? [Humm, toplevel nodes are always in the rbtree, I think. Does this mean that all toplevel nodes are always reffed?] I'd love to watch a little toy model that just keeps an int for each node, and printf()s the references for each node as they change. Then you could see if scrolling the view up and down indeed keeps only the required nodes reffed --- this would be good evidence that you can indeed implement a model which doesn't have all its data exploded in memory all the time. Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Tap and Hold API
On Thu, 2007-04-26 at 23:40 +0200, Kristian Rietveld wrote: I was actually planning to push in (x, y) relative to the widget-window. The new tooltips code is supposed to do the same (however that documentation says otherwise at this moment, it will be fixed RSN). If we use this, the window in question will also be known, since the coordinates will always be relative to widget-window. Most widgets handle this already and usually have code/functions to translate from widget-window to something else. If they have not, this functionatily should be added to those widgets IMHO. Hmm, if you make it relative to widget-window, I suppose it's okay. It's cumbersome when you have more than one subwindow, though (we have had this inconvenience since the DnD API was introduced). Passing a GdkEventButton instead does not really seem beneficiary to me; we cannot use the original GdkEventButton we get from the button-press since the event time and coordinates will likely be wrong, so we will end up with a synthesized event anyway. Another point: for tooltips we don't pass in motion events or something similair either ... The point is that you *do* need a timestamp that makes sense :) Let's say you tap-and-hold; the program will likely want to pop up a tooltip-like window (or popup menu or similar) and those require a timestamp. It could simply be the timestamp from the initial tap, or from the latest motion event that is still considered part of the arming period. I am not really sure if having different tap-n-hold actions for different mouse buttons is worth supporting. I think I would prefer tap-n-hold to run the same action for any button, since it's about tapping and holding something on the screen, whether this is a stylus, a finger or the back of wacom pen is left in the middle. Pen computers will likely not care since the stylus has no buttons, but for a Wacom tablet I can very well imagine a tap-and-hold action that is different for the brush than for the eraser. Maybe such sophisticated apps will be content implementing tap-and-hold by hand anyway :) I don't think having widget-specific tap-n-hold animations is a good idea; I would say that this is really a theme issue and it would be good if every tap-n-hold operation looks the same the to user. You have two tap-and-hold actions: pop up a menu and pop up a tooltip with extra info. Should those have the same I'm armed animations? Another questionable point is whether we should allow for tap-n-hold actions to be triggered via the keyboard. This is probably a good thing to do and would involve adding a gboolean triggered_by_keyboard to the signal signature, just like the new tooltips API has. Does anyone have better suggestions here? But then you would need to bind a key to the tap-and-hold action, and that gets messy. I think that depends on the way you want to implement it. For tooltips you can activate the show-help binding which will display the tooltip for the focussed widget immediately, without any delay. For tap-n-hold I was thinking of something similiar, a keyboard shortcut which will activate a binding -- this binding will trigger the tap-n-hold action immediately (iff the query succeeded of course). Oh, so this would be global? Sort of tap-and-hold-keysym = FunkyKey in your ~/.gtkrc? Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkCanvas requirements?
El lun, 23-04-2007 a las 13:44 -0400, Havoc Pennington escribió: For most Flash usage, API really is not the issue... people do it like HTML, where they write the markup then add a little bit of scripting (for Flash, it isn't literally markup, but what I mean is 'data not code'). Unlike HTML, the data part is edited in a dedicated app rather than written by hand or using templates. And a dedicated app to create the drawing content is exactly the killer feature of Flash. That's what I want to do with use Inkscape and slap the SVG into the canvas; then write some simple code to interact with it. People in the Real World need a very simple way to do interactive displays (be it with graphics or just text widgets). A few years ago in Brazil I had a gentleman ask me, why is GTK+ and Glade so complicated? I'm using a database that lets me write GUIs by typing Enter Name [] (write-your-GUI-though-ASCII-art), and it will then let me name the field, define its type, etc.. People *need* that level of simplicity. Draw something, BANG - it's there. You just write some glue code to the rest of your app. Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkCanvas requirements?
El jue, 19-04-2007 a las 15:00 -0400, Havoc Pennington escribió: I'd step back first and do use-cases instead, and also talk about at a high level what the canvas is for and when it would be used, i.e.: Havoc is on the right track here. You can pile an immense feature list on top of the canvas and still get a useless thing. We need use-cases. My use-cases for a canvas: - Interactive, pre-drawn graphical content which cannot be done with stock widgets. Think of using Inkscape instead of Glade; think of a poor man's Flash. People want to do this: canvas = new Canvas (); svg = canvas.load_svg (foo.svg); handle = svg.get_object_by_id (bouncing-ball); handle.animate (new BounceAnimation (1.5, 1.3, 2.0, 3.4)); - Interactive diagrams, generated programmatically. Think of the sexy call-graphs in kcachegrind. A static diagram is trivial, as you can just draw it with Cairo *once* and BitBlt() it when you need it. An interactive diagram is harder, since you need event handling, hit testing, painless redraw, etc. - Simple games are already covered by the points above. - I think we want to focus on simplicity and heavy use of SVG. Thousands of programmatically-generated items (music editor, flyweight items, etc.) are not very interesting and could complicate the design a lot. - Whoever does a canvas really really really needs to look at Piccolo.NET (http://www.cs.umd.edu/hcil/piccolo/). The animation API is lovely, and the support for zoomable UIs is lovely as well. If we had Piccolo.NET on top of Cairo and GTK+, we'd have 99% of our needs covered. [Side note... at this point I think doing a canvas in C is a big mistake. Interesting canvases will inevitably get cycles in the pointer graph, and reference counting becomes just too painful then. [This is irrelevant to .net or whatever; it's a general We Should Stop Writing Nontrivial Shit In C thing. People would be really really happy with the Piccolo.NET API implemented with pygtk or gtk-sharp.]] - when is a canvas item used vs. a widget? what current widgets would be replicated as canvas items? If you have a stock canvas item for editable text, you already have 95% of the cases covered --- you can compose editable mega-items out of that text item plus decoration. That's what we do in the Evolution calendar, for instance: the calendar's appointments are just a bunch of boxes and lines plus text items. Putting GtkWidgets inside a canvas is a nice gimmick, but I don't think you need to make them fully zoomable/transformable/etc. If you want GtkFixed-like layout with canvas drawings underneath, you don't need exotic transformations. (People often do diagrams which need pushable buttons, and so they want to stick a GtkButton inside a canvas. For that it may be simpler to just create a CanvasButton object which you can decorate to your heart's content with SVG.) The canvas also needs to have performance goals defined up front. We don't want the case where people avoid using the canvas because it is too slow (like what happened with the antialiased GnomeCanvas). Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Tap and Hold API
El mar, 17-04-2007 a las 12:02 +0200, Kristian Rietveld escribió:
Recently I have been working on a tap-n-hold implementation based on the
implementation found in Maemo. Tap-n-hold allows for a callback to be
called after a mouse button has been pressed for a given amount of time
This action is particularly useful on touch screen devices, since it can be
used to, for example, popup a context menu instead of using the right
mouse button which is not available on these devices.
Nice! This is always cumbersome to implement by hand.
typedef enum
{
GTK_TAP_AND_HOLD_QUERY,
GTK_TAP_AND_HOLD_TRIGGER,
GTK_TAP_AND_HOLD_CANCEL
} GtkTapAndHoldAction;
gboolean (* tap_and_hold) (GtkWidget *widget,
GtkTapAndHoldAction action,
gint x,
gint y);
[snip]
* Query: once the user presses the mouse button, this signal will be
emitted to check whether the given location (x, y) allows for executing
the tap-n-hold action. The x and y parameters are set to the location
of the mouse cursor (relative to the widget's allocation) A return
value of FALSE means no tap-n-hold action should occur.
As a widget, checking (x, y) based on your allocation is not convenient
if you have subwindows. Why not pass a complete GdkEventButton
structure to the signal? That way you can see the event-window and
deduce things more easily.
[If you have a simple stylus I guess you don't need to know about a
particular mouse button. Are there styluses for which you would need a
button number? Tap-and-hold-while-pressing-a-certain-button-
in-the-fancy-wacom-stylus?]
[Let's not repeat the mistake of having event-generated signals which
don't give you the actual event structure, like in DnD for GtkTreeView.]
* Trigger: if the application returned TRUE in response to the query
signal and the user hold the button and did not move the mouse past the
threshold (currently the drag threshold is used for this) during the
timeout period, this signal will be emitted. X and y again reflect the
position of the mouse cursor. The return value of the signal is not of
any significance and ignored.
What happens when you already have a button-press-event handler? Or is
the intention that you replace that handler with the tap-and-hold one?
[I.e. is it easy to retrofit apps to support tap-and-hold with ths new
API, or do all the event handlers need to be changed?]
A GtkSetting called gtk-tap-and-hold-timeout has been added, which is
used to set the tap-n-hold timeout.
Does this interact the Right Way with respect to widgets that already
have automatic drag handlers set up for them? I.e. you tap and hold for
a bit, then actually drag. The widget should emit tap-and-hold(cancel)
and then drag-begin.
During the timeout period between pressing the button and triggering the
tap-n-hold action the mouse cursor will be replaced by an animation,
indicating that something is happening.
I guess this has to be experienced to get a good feel, but my
spider-sense tells me that widgets will prefer to show the I'm armed
state by themselves, rather than relying on an automatic cursor. How
would the widget change the cursor itself when it gets the trigger
version of the signal? Do we need an API analogous to
gtk_drag_set_icon_*()?
Another questionable point is whether we should allow for tap-n-hold
actions to be triggered via the keyboard. This is probably a good thing
to do and would involve adding a gboolean triggered_by_keyboard to the
signal signature, just like the new tooltips API has. Does anyone have
better suggestions here?
But then you would need to bind a key to the tap-and-hold action, and
that gets messy.
I'd prefer a way to solve the Photoshop spacebar problem: say a
drawing program wants to let you scroll the view by holding down the
spacebar while you press-and-drag with the mouse. (This is to avoid
having to switch to the scroll the view tool temporarily, and it is
*very* convenient!)
If you hold down the spacebar, currently you get a fast stream of
key_press/key_release events, and you have to implement the Photoshop
spacebar by hand using timers. It would be more comfortable to just
say
static gboolean
my_key_press_event_handler (GtkWidget *widget, GdkEventKey *event)
{
MyWidget *my = MY_WIDGET (widget);
if (event-keyval == GDK_SPACE) {
gdk_dont_emit_key_release_until_user_actually_releases_the_key
(GDK_SPACE);
my-is_scrolling = TRUE;
return TRUE;
}
return FALSE;
}
static gboolean
my_key_release_event_handler (GtkWidget *widget, GdkEventKey *event)
{
MyWidget *my = MY_WIDGET (widget);
if (event-keyval == GDK_SPACE) {
my-is_scrolling = FALSE;
return TRUE;
}
return FALSE;
}
Federico
Re: ideas on improving the performance of gtk_tree_view
El jue, 29-03-2007 a las 17:43 +0300, [EMAIL PROTECTED] escribió: Using arrays in GtkTreeDataSortHeader doesn't appear to be optimal, because their length is not constant. We would end up to alloc/dealloc/copy sequence when adding new items. From a quick look at the code, the only place where _gtk_tree_data_list_header_new() gets called is from gtk_list_store_set_n_columns(), which is an internal construct-time function. So the number of headers cannot change. [Same thing for gtktreesort.c - it only creates the headers when you change the underlying model.] However, why this step is needed at all for each comparisison!! It's certainly the case that there will be more sort function calls than changes to sort criteria. This would allow us to cache the pointer to active GtkTreeDataSortHeader directly, providing us constant time O(1) access. Or did I miss something? Oh, you are completely right! You could indeed cache the current header and only refresh it when the sort_column_id changes. Who's got a patch burning a hole in their pocket? :) Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Warning about reaped children
Hi,
I forgot to pass G_SPAWN_DO_NOT_REAP_CHILD to g_spawn_async_with_pipes()
and ended up scratching my head about why my GChildWatch callback wasn't
firing. After some hot strace action and RTFM, I added that flag and
everything worked perfectly. Do we need a warning like the one in the
attached patch?
Federico
--- gmain.c~ 2007-01-22 11:12:44.0 -0600
+++ gmain.c 2007-03-29 15:38:01.0 -0600
@@ -3605,12 +3605,21 @@ check_for_child_exited (GSource *source)
if (child_watch_source-count count)
{
gint child_status;
+ GPid pid;
- if (waitpid (child_watch_source-pid, child_status, WNOHANG) 0)
+ pid = waitpid (child_watch_source-pid, child_status, WNOHANG);
+
+ if (pid 0)
{
child_watch_source-child_status = child_status;
child_watch_source-child_exited = TRUE;
}
+ else if (pid == -1 errno == ECHILD)
+ g_warning (waitpid() for process %d returned ECHILD. Did you launch the process
+ with g_spawn_async*() but forget to pass G_SPAWN_DO_NOT_REAP_CHILD?
+ The notification about child termination will not be emitted!,
+ child_watch_source-pid);
+
child_watch_source-count = count;
}
___
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
El lun, 26-03-2007 a las 00:18 +0300, [EMAIL PROTECTED] escribió: I tried this idea and changed the GtkTreeDataList to be an array instead of linked list (see the attached patch, made against svn head). The original testcase (5000x50 model) started up faster (but was still slow), but I didn't do any actual measurements yet (let's see tomorrow ;) I made the following changes: * Added dimension/index parameter to many GtkTreeDataList calls (I understood that this API was OK to be changed). The GtkTreeDataList is now an array of n elements instead of single list node. * GtkListStore and GtkTreeStore needed similar patches, including: Simpler get_value/set_value implementation, because we know that the datalist will contain n elements and they can be indexed easily. * Drag'n'drop code now uses simpler _gtk_tree_data_list_copy (I renamed _gtk_tree_data_list_node_copy, since we now have more than one element). Holy crap, you kick ass! Nicolas, can you get another profile using Markku's patch? I was looking at the GtkTreeView code and it looks like there are other places that could get the array treatment. One place in particular was the sorting machinery... GtkListStore also uses a GList of information for the sort headers, and walks the list in g_list_store_compare_func (!). Federico ___ 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
El jue, 22-03-2007 a las 16:55 +0100, Nicolas Setton escribió: Hi, Nicolas, Thanks for taking the time to profile this! Consider the subprogram attached. It shows a simple tree_view displaying a list_store (5000 columns and 50 rows containing integers). The display performance is very poor: when displaying the last columns, the vertical scollbar takes between 5 and 10 seconds to respond. Two things: 1. Yes, we abuse lists here and there. The performance would definitely be better with an array. This is reasonably easy to do, since the changes are internal and self-contained in GtkListStore and GtkTreeDataList. 2. You just created a user interface disaster :) How are your users going to be able to jump to the right column? So, it seems that we spend most of our time traversing the list of columns. Note that this explains why a tree of 5000 columns x 50 rows has such bad performance compared to a tree of 50 columns x 5000 rows. First suggestion: we'd be better off in this subprogram if the data was implemented as an array instead of as a linked list. Exactly. GtkListStore is implemented as a GSequence (a splay tree), where each node is one row in the list. Then, the data for the row's columns is stored in a linked list (GtkTreeDataList). You could reimplement GtkTreeDataList in terms of an array and get a good speedup for *all* uses of GtkListStore (i.e. you'd be replacing a dominant O(n^2) for get/set operations in the list store with a simpler O(log n) for splay tree lookups, plus the constant time to access a column within a node). Using an array instead of a linked list for GtkTreeDataList is a great idea, and we should definitely review a patch for that :) I'm not familiar with this area yet, so I'm puzzled: is the call to gtk_tree_view_column_cell_set_cell_data really needed for the purposes of gtk_tree_view_bin_expose, or is it just needed for the call to gtk_tree_view_has_special_cell? In any case, I suggest we cache this - probably there is no need to do it in every expose call, only after the model data has changed. It absolutely needs to be called for each row, so that the tree view can know how to display the focus rectangle (a cell-wide rectangle for editable/activatable cells, a row-wide rectangle for cold cells). The has_special_cell condition is particular to each row, so the benefits of caching it (say, in the GtkRBTree) would only serve for multiple exposes of the same unchanging data. But since one needs to walk the entire row to paint it, anyway, you'd simply be doing one walk instead of two. But the main problem is getting the cell's data from the model (i.e. walking the GtkTreeDataList) - fix that, and the problem with has_special_cell may simply disappear. Hacking GtkListStore/GtkTreeDataList to use an array for the row data should take one or two afternoons, and it would benefit all trees, not just your huge one. Wanna do it for fame and glory? :) [This would also save memory, since you avoid having GSlice-induced padding in each GtkTreeDataList structure and you also save a pointer per node. I'd love to see actual numbers for this.] Federico ___ 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
El vie, 23-03-2007 a las 23:19 +0100, Michael Natterer escribió: I would rather say we absolutely don't abuse lists here. There is no significant difference between list and array for a couple of items (say 50 items). The only abuse I see is creating a treeview with 5000 columns. The widget is simply not made for that. It would be the same as optimizing GtkVBox for 5000 children and asking for the internal list being replaced by an array. So, a few things: * 5000 columns is definitely abusing the *user*. Who cares about the toolkit. * A tree row has an immutable number of columns; their datums are of known sizes. This screams array. * An array would give you less memory overhead from allocator padding, better cache locality, less pressure on the allocator, and constant-time access to the columns. I bet that it will also require less code than a list :) What GTK+ needs here is a *sheet* widget, something that is optimized for organizing two-dimensional data in an efficient way. Hacking up GtkTreeView for insane use cases does no good whatsoever. Yes, we definitely need a sheet widget. I don't know why people don't just write one, or revive the old one. Maybe they are scared that it doesn't do enough for a spreadsheet --- but people are not building spreadsheets; they just want to display simple tabular data. P.S.: I do not say that optimizing treeview is a bad idea, I would just find it very unfortunate to waste developer resources in order to optimize use cases like this. I'd rather not discourage people who are actually bothering to profile our shitty code --- they don't come along very often. Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Supporting Gtk+ Maintenance
El vie, 16-03-2007 a las 20:44 +0530, मयंक जैन (makuchaku) escribió: Here's a task for you to get started. It will take you several days, but hopefully it will be fun :) Sure... onto it! That's the spirit! :) Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Adding foreign_new_xdisplay for Gdk X11
El mar, 06-02-2007 a las 16:43 +, Ricardo Cruz escribió: I am writting a Qt style that uses GTK+ to render its stuff; the inverse of gtk-qt-engine [1], and so I need to re-use the Qt Display connection. Nice! This would even help for gradually porting ancient non-GTK+ software to the new world order. Would it be possible to add a function with the following signature to Gdk X11? GdkDisplay *gdk_x11_foreign_new_xdisplay (Display *) I have made this patch for mine 2.8.18: http://www.alunos.dcc.fc.up.pt/~c0607045/trash/gdkdisplay-foreign.patch Your gdk_x11_foreign_new_xdisplay() doesn't emit display-opened on the GdkDisplayManager. The display *was* already open, but shouldn't the display manager get to know about this? GdkDisplay keeps some interesting state (last-clicked-window, button click times, etc.). If GTK+ doesn't really own the display, could these fields get out of sync with reality? Does it matter? Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk+ upstream meeting at FOSDEM
El mié, 03-01-2007 a las 11:37 +0100, Tim Janik escribió: so everyone meaning to come to FOSDEM/Bruessels on the 23rd, 24th, 25th, or 26th February 2007 and would like to join the Gtk+ meeting, please drop me a line so i can refine the proposed date to get most people on it. The meeting sounds like a very nice idea. I'll be able to make it on the days of the conference, not before that :( [I have practically zero time to contribute to GTK+ these days; I'm just going for the gossip ;) ] Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Publically exposing GtkFileChooserIface
El mié, 13-12-2006 a las 11:28 +0100, Kristian Rietveld escribió: The easiest way to solve this is probably to: * Move GtkFileChooserIface into it's own, new, header file. gtkfilechooserprivate.h also contains some data structures internal to the implementation of the default file chooser which don't make sense to install. * Add GTK_FILE_SYSTEM_ENABLE_UNSUPPORTED defines like in gtkfilesystem.h. * Get GTK+ to install it. I would really like to get this into 2.12. Objections? Suggestions? The bug for this is http://bugzilla.gnome.org/show_bug.cgi?id=382528 It's a good idea, and something that we wanted to do for 2.10, but it just fell through the cracks. However, the file chooser at this point is really buggy. I don't want to do any API work on it until the bugs are fixed. Making the Iface public is more or less orthogonal to fixing the bugs, but making it public would require documenting it, polishing the bits of the interface that are really too specific to the current implementation, etc. All that would take resources away from fixing the bugs in the default implementation. Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk+ unit tests (brainstorming)
On Wed, 2006-10-25 at 17:52 +0200, Tim Janik wrote: while analysing the need for a testing framework and whether it makes sense for GLib and Gtk+ to depend on yet another package for the sole purpose of testing, i made/had the following observations/thoughts: Wooo! Thanks for working on this, Tim; it would be *fantastic* to unify all the disparate tests that we have right now, as well as write new ones. - for reasons also mentioned in the afformentioned blog entry it might be a good idea for Gtk+ as well to split up tests into things that can quickly be checked, thoroughly be checked but take long, and into performance/benchmark tests. these can be executed by make targets check, slowcheck and perf respectively. This is a good idea. For testing the file chooser, it helped a lot to write some black box tests which are essentially smoke tests. They just test the very basic functionality of the chooser, without going into the whole test suite. The black box tests helped me fix a bug with many ramifications quickly, since at all times I could ensure that none of the basic functionality was broken. Performance tests should definitely be separate. - for time bound tasks it can also make sense to fork a test and after a certain timeout, abort and fail the test. Yes. Hans Petter uses this approach for hiw Flow testing, and it's very cool. - homogeneous or consistent test output might be desirable in some contexts. so far, i've made the experience that for simple make check runs, the most important things are that it's fast enough for people to run frequently and that it succeeds. One thing about this... it would be good to keep megawidgets in separate tests, but then to have make check run all the tests for all megawidgets. That is, I'd like a single test-all-the-stuff-in-the-treeview and a single test-all-the-stuff-in-the-file-chooser: when coding in one, I normally don't care about the other one. So if all the test-* programs spit the same output, we can collect it easily from make check. Cairo has a very nice testing framework. We can surely steal ideas from it. - GLib based test programs should never produce a CRITICAL **: or WARNING **: message and succeed. Definitely. I have some simple code in autotestfilechooser.c to catch this and fail the tests if we get warnings/criticals. 5- simple helper macros to indicate test start/progress/assertions/end. (we've at least found these useful to have in Beast.) For the file chooser tests, I just return a boolean from the test functions, which obviously indicates if the test passed or not. What sort of macros are you envisioning? - for a specific widget type, test input/output conditions of all API functions (only for valid use cases though) - similarly, test all input/output conditions of the Gdk API - try setting getting all widget properties on all widgets over the full value ranges (sparsely covered by means of random numbers for instance) - try setting getting all container child properties analogously I believe the OSDL tests do this already. We should steal that code; there's a *lot* of properties to be tested! - check layout algorithms by layouting a child widget that does nothing but checking the coordinates it's layed out at. Oh, nice idea. This would be *really* nice even for non-widget stuff, such as all the tricky layout going on in GtkTreeView and its cell renderers. - generically query all key bindings of stock Gtk+ widgets, and activate them, checking that no warnings/criticals are generated. Nice. - for all widget types, create and destroy them in a loop to: a) measure basic object setup performance b) catch obvious leaks (these would be slowcheck/perf tests) Yeah. GtkWidgetProfiler (in gtk+/perf) will help with this. Manu Cornet has improved it a lot for his theme engine torturer, so we should use *that* version :) as always, feedback is appreciated, especially objections/concerns regarding the ideas outlined ;) Again, thanks for working on this. It will be reasurring to have a good way to plug in new tests as we add new code to gtk+. After the infrastructure in autotestfilechooser was done, it was quite fun to add new tests; before that, it was extremely cumbersome to start with a blank sheet of paper every time I wanted to test something. Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GdkPixbuf and Xrender scales
On Wed, 2006-10-18 at 15:48 -0200, Carlos Eduardo Rodrigues Diógenes wrote: GdkPixbuf will start to use cairo/xrender or other library to do it's scale operations? If the answear is no, what are the reasons, since use cairo will enable hardware accelarating when glitz be finished. The answer is wrong question :) GdkPixbuf is a representation for images in your process's memory. When you scale a pixbuf, you get another pixbuf in your process's memory. So, it is like this: pixbuf-in-process - scale operation - pixbuf-in-process When you use acceleration in a video card to do scaling, you do this: image-in-process - scale operation - display memory I.e. the scaled image goes to a completely different place. You don't get that image back in your process. Every application paints things differently. Some create temporary images in memory, draw stuff to them (including scaled images), and finally paint the final image to the screen. Others create temporary pixmaps in the video card, draw everything there, and then paint the pixmap to the screen. It is this second kind of applications that would benefit from hardware acceleration in video cards. Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
