Re: migrating gtk

[Kristian Rietveld]

> On 05 Feb 2018, at 11:37, Emmanuele Bassi  wrote:
> 
> Of course if we get a positive response that the bug is still there
> we're going to migrate it and keep track of it.
> 
>> With that in mind, I believe it is much nicer to just leave the old bugs 
>> there.
> 
> The old bugs will be left there, but closed, so we don't need to check
> two bug lists, and split the maintenance resources even more.


What about old bugs that will not receive a response right now / in the very 
near future? Can these still be migrated at a later point? I gather there’s a 
script to do this on a case-by-case basis?

And I assume all data in bugzilla.gnome.org will remain accessible for quite 
some time to come? This is an important archive of information.



regards,

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

Re: gtktreeview: Data for all columns is retrieved although only a small subset of 1% is visible - Why?

[Kristian Rietveld]

> On 15 Dec 2015, at 23:04, Friedrich Beckmann  
> wrote:
> 
> 
> /* we *need* to set cell data on all cells before the call
>  * to _has_can_focus_cell, else _has_can_focus_cell() does not
>  * return a correct value.
>  */
> 
> here: https://git.gnome.org/browse/gtk+/tree/gtk/gtktreeview.c#n5103
> 
> I am not sure, but I maybe this is the reason that in our case
> the data for 2000 columns is retrieved, although only 16 are visible.

Do you mean visible as in “gtk_tree_view_column_get_visible(column) == TRUE” or 
“the column is visible on the screen” ? This is an important difference.

> Does anybody
> remember the reason for this full retrieval? Is this a fundamental problem 
> which
> can not be avoided?

(If I remember correctly) it needs to verify whether any column that is visible 
(as in get_visible() == TRUE) has a “can-focus” cell. If no column has such a 
cell, the keyboard interaction model changes slightly: a cursor rectangle will 
be drawn that encompasses all columns. This check is performed in 
gtk_tree_view_has_can_focus_cell() which is called at line 5119.

Because the “can-focus” cell property can be changed dynamically through 
set_cell_data, it is close to impossible to cache this properly. This is 
typically not a problem, since we deal with < 20 columns. GtkTreeView was 
simply not designed for dealing with hundreds of columns.

Note that gtk_tree_view_has_can_focus_cell() skips columns with get_visible() 
== FALSE, so I *think* (but am really not sure) that get_visible() == FALSE 
columns can be skipped in the set_cell_data_func loop. However if in your case 
all columns are get_visible() == TRUE, this won’t help you. In that case, you 
probably want to have some function to set a has_can_focus_cell() “hint” which 
overrides and removes the need for the dynamic check.


regards,

-kris.

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

Re: a new combo box

[Kristian Rietveld]

 On 27 Dec 2014, at 18:05, Sébastien Wilmet swil...@gnome.org wrote:
 
 On Sun, Dec 28, 2014 at 12:50:24AM +0900, Tristan Van Berkom wrote:
 In any case, I think this misses the point I was trying to make, I think
 someone had to raise the obvious question: is it justified to bring in a
 whole new combo API ? Or can we / should we get the most out of the API
 we have ?
 
 Yes, it was more a side note.
 
 As a comment says at the top of gtkcombobox.c:
 /* WELCOME, to THE house of evil code */


I vaguely recall pushing a commit to remove exactly this comment, but I see it 
never made master. Sorry about that.

Anyway, in light of this discussion the comment is interesting. The comment was 
actually added right from the start of the code and not after years of adding 
new features. I believe it was born out of frustration (and immaturity).

The big problem is that GtkComboBox implements two widgets at once. Back in 
GTK+ 1.x we had a GtkOptionMenu (menu-based) and a GtkCombo (list-based). High 
on the wish list in the beginning of the GTK+ 2.x series was a widget that 
could handle both styles *and* be able to switch between these styles at 
run-time with the toggle of a style property. This became GtkComboBox and it 
essentially implemented all event handling logic and child widget rendering 
logic (for showing the “sample” (the selected item) and the arrow) twice and 
additionally had code to transform between these two at run-time. We also added 
the possibility to add another random widget as “sample widget”, not limited to 
GtkEntry.

In retrospect I believe the two-in-one approach was a bad design decision. It 
would probably have been better to implement the list-based and menu-based 
variants as specialisations of a base class and somehow implement the logic to 
switch between these two at run-time. This would also have made it easier to 
add additional styles such as the one proposed.

So in summary, GtkComboBox is highly flexible but only in terms of contents as 
you have to stick to the default list and menu styles. The proposed design 
seems to have a new style and limited possibilities for the contents. I believe 
it will be very hard to map this to GtkComboBox API as it stands now, making 
replacement pretty much inevitable as Mattias has mentioned.


On the other hand, I agree with Tristan’s approach to avoid complete 
replacements of existing code (widgets). To make this a possibility, I believe 
you need a framework to allow the existing widgets to evolve: parts have to be 
deprecated and removed, parts have to be changed (shoving in new base classes), 
and new parts are added. GTK+ does not have such a framework, because there is 
no set cycle for the change or removal of code (ABI break), you can never 
complete the required clean up to be able to implement new functionalities or 
styles. But I am touching on a controversial topic now, so I will stop right 
here ;).



regards,

-kris.

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

Re: Request for help (tracking down CairoCanvas)

[Kristian Rietveld]

Hey John,

Perhaps you meant GooCanvas?

  https://wiki.gnome.org/GooCanvas


regards,

-kris.

On Tue, Sep 3, 2013 at 11:09 AM, John Emmas john...@tiscali.co.uk wrote:
 Just a long shot but can anyone tell me where to obtain the sources for
 CairoCanvas (either git / svn / tarball or whatever).  I don't know if I'm
 typing all the wrong stuff into Google but it seems remarkably difficult to
 track down.  I found something called 'Lazarus' (which I took to be a
 project that uses CairoCanvas) but I haven't yet found CairoCanvas itself.
 Thanks.

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

Re: notifications in gtk

[Kristian Rietveld]

On Nov 6, 2012, at 4:23 PM, Matthias Clasen wrote:
 Problems with GtkStatusIcon
 
 - It is really centered around the idea that apps just export a small
 bit of their UI into the 'panel'
 
 - It assumes that all desktops want to offer a permanent place
 (system tray) for applications to present a clickable icon with a
 context menu
 
 - It requires the application to be running as long as its icon is
 present, essentially forcing a daemon mode onto applications (eg
 evolution-alarm-notify)
 
 - The X implementation uses XEmbed and can't really be made to work
 nicely in a composited environment
 
 - The win32 implementation is also problematic

I would argue the OS X implementation is also problematic. Showing the icon in 
the OS X menu bar is quite easy, however, in response we currently typically 
pop up a GtkMenu. This gives interesting problems with grabs/event handling. 
Also, it looks quite out of place because native applications show a native 
menu. The current GtkStatusIcon makes it close to impossible to automatically 
convert a GtkMenu into a native menu (e.g. custom menu items) and there's also 
the case where the status icon pops up something that's not a menu.



regards,

-kris.

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

Fully winding down my involvement in GTK+

[Kristian Rietveld]

Hi all,

I have tried to maintain GtkTreeView ever since I took over from Jonathan 
Blandford many years ago and in the more recent years the OS X backend which I 
took over from Richard Hult. During the last 1,5 years, I have been struggling 
to keep up with the development pace of GTK+. As many have likely noticed, I 
barely had time to do patch review let alone do any code writing myself. More 
than a 100% attention is currently going to my day job.

Also, I struggle to identify with the community these days -- that is, I do not 
agree how GTK+ is being developed. Discussions appear to mainly happen on IRC, 
which I can impossibly follow, contrary to on the mailing list; I have seen 
things being refactored without seriously considering the impact on 
compatibility or other platforms; and after working an entire Summer on the 
sort and filter model, a patch was committed there without even quickly 
checking for review.

So, in Open Source, either you step up and do something about it, or you back 
out. I have no spare cycles to step up, so I made the choice to back out. I 
will discontinue maintenance and patch review and move to other things. There 
are a few small OS X issues I still plan to fix, but that will be all.


I will not completely disappear and might still do an occasional contribution. 
I hope to find time for other things, also related to GTK+ and GNOME, like my 
GObject Clang plugin which I want to clean up and upload somewhere. Or some 
GIMP hacking. Also, I will be around in the fine LibreOffice community.


Best regards,

-kris.

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

Wiki page on assorted GtkTreeView ideas and old work in progress patches

[Kristian Rietveld]

Hi all,

For quite a long time now, I have been wanting to put all ideas for
improving GtkTreeView that I collected over the years at a central
place, instead of having this scattered over sheets of paper which are
not of use to others. Finally, I found time to do this. In the past, I
have also already experimented with some of these ideas, which
resulted in work in progress patches. I managed to dig up these
patches and have attached them to the wiki. Beware, the patches were
work in progress patches and are also outdated by now, but still they
bring the main ideas across.  Most notably, patches are included for a
functioning and mostly complete simple list wrapper class, my
experiment with removing validation from GtkTreeView and resorting to
estimated scrollbars (contrary to exact scrollbars), and my work in
progress of a proper multi-row DnD API.

The page can be found at GNOME Live:

 https://live.gnome.org/GTK%2B/GtkTreeView/Ideas

I no longer plan to work on these ideas and patches, so it is really
for information purposes and such that it does not get lost.  And
hopefully, also to the inspiration of others.


regards,

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

Re: gtktreeview.c

[Kristian Rietveld]

On Feb 8, 2012, at 10:05 PM, earlgrey wrote:
 --
 ...
 
 if ((anchor  !gtk_tree_path_compare (anchor, path))
 
 
 || !_gtk_tree_view_column_has_editable_cell (column))
 
 
 ...
 
 --
 
 
 What does the ! before 
 _gtk_tree_view_column_has_editable_cell
 (column) stand for  ?

It was introduced to:


* gtk/gtktreeview.c (gtk_tree_view_button_press): send cell event
on first click when cell isn't editable

to fix #77862.

However, when this fix was introduced, cursor was used in the if-statement 
instead of anchor, which might be why things changed?


regards,

-kris.

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

Re: RFC: scrolling

[Kristian Rietveld]

On Dec 6, 2011, at 6:26 AM, Benjamin Otte wrote:
 A) Don't implement it
 B) Let the scrollable do the scrolling
 C) Let the viewport do the scrolling
 In this approach, one treats the scrollable as just a large canvas and
 the viewport provides a view onto an area of the scrollable. Scrolling
 is managed completely by the viewport.
 D) Implement scrolling automatically
 Whenever a widget needs more space than is available, just
 automatically add scrollbars. This is what the overflow property of
 HTML does.

Quick comment: one thing that GtkTreeView relies on is to be able to make a 
specified item visible. This means that GtkTreeView gives a command to scroll 
to a specified position.  From a quick glance, this would be hard to implement 
with C and D.

We support such scrolling as an API to outside users, but it is also used when 
implementing keyboard navigation.  If you press up, the view has to scroll up 
as well if necessary. So other widgets rely on this as well.


regards,

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

Re: GtkTreeView changes

[Kristian Rietveld]

Hello Benjamin,

On Nov 24, 2011, at 2:57 AM, Benjamin Otte wrote:
 In case you didn't notice, I did some refactoring in the treeview code
 and pushed it to master. It's mainly meant for the accessibility
 implementation. I'll continue doing that for a bit, until the treeview
 a11y implementation is not a disaster anymore. If you don't agree with
 any of it, poke me.

I did notice, thanks for your mail.

 Highlevel overview of what I've done:
 
 1) Make GtkRBTree track the node number
 Instead of parity, we now have a total_count, which is basically like
 parity, just without modulo 2. It is used via gtk_rbtree_find_index()
 by the a11y code to be able to index rows by number.

I would have said, look at _gtk_tree_view_find_path(), until I realized that 
you need to index rows by number *including* all expanded rows and not 
excluding like is done for paths.  So I can see this change making sense.

This is very likely a non-issue, but I will mention it anyway for completeness: 
the only thing I am slightly concerned about, but really only for 32-bit 
limited-memory platforms is the increase in memory usage now that the parity 
bitfield (before nicely padded with the 14-bit flags) is a full int. For our 
current 64-bit platforms I am not concerned, since the 4 pointers in the node 
structure have doubled since 32-bit.

 2) Make GtkRBNode pointers not reference different nodes over time
 The reordering and node removal code used to swap the data from one
 node to another. I fixed that. Now a Tree/Node tuple can be used
 instead of a GtkTreeRowReference. I'm using these instead of
 GtkTreeRowReferences in the accessibilty code to have a stable mapping
 from accessibles to rows.

Makes sense, though it *could* be that there's some specific GtkTreeView code 
that depends on this behavior. For reorderings, the GtkRBNodes used to stay at 
the some (x,y) location and only have their data swapped, now they would move 
location. From a quick look, we already unset the prelight and expand_collapsed 
nodes (which care about location not content) before reodering, so we are 
likely fine.  I think we might still want to explicitly stop rubberbanding and 
unset the button_pressed node if we are going to reorder the rows in the middle 
of rubberbanding or a button press and release (similar for node removal).

 3) Add a bunch of convenience wrappers/refactors to make code more
 understandable
 Basically, I moved GtkRBTree closer to something that could be exposed
 as a public API, or at least as a semi-public API internally. The
 rbtree code is actually quite powerful (we could use it to flatten
 trees to lists in various places, also it might be interesting to
 implement TreeModelFilter with it, I might want to use it to replace
 the textview's btree implementation) and might allow a bunch of cool
 things. I almost convinced Ryan to pull it into glib already. ;)

Fine with me, but my plan was to not touch TreeModelFilter any time soon, since 
it seems to be finally working quite nicely since the refactorings over the 
Summer :)

 4) Move treeview a11y from signals to direct function calls
 Instead of signal handlers that have to work with what is available, I
 added direct function calls into the a11y code. This allows better
 control about what information we send to the treeview. And we can
 actually send private data types without having to expose it to the
 public API.
 The treeview is the first widget where I'm doing that excessively, the
 other a11y widgets should ideally follow.

Totally makes sense, I think such integration is definitely necessary if we 
want to be a first-class citizen on the a11y front.


regards,

-kris.

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

Re: RFC: Model-View-Controller

[Kristian Rietveld]

On Nov 16, 2011, at 9:22 PM, Benjamin Otte wrote:
 On Wed, Nov 16, 2011 at 9:37 AM, Kristian Rietveld k...@loopnest.org wrote:
 If there are multiple views, which are changed by which controller?  What 
 complicates thinking about this for me is that in MVC as I know it, there is 
 1 Model, 1 View and 1 Controller for each thing.
 
 I  think this is where the misunderstanding is. I probably shouldn't
 have mentioned MVC in the email and named it actions and actors and
 just used the clutter terminology.

That is very likely ;)  I now also understand that all these objects would be 
allowed to do drawing for the widget they are connected to, etc.

Still it is a very good idea to get some prototyping going to get a feel for 
this and to see how much code it would save in the end.  I like the examples 
put forward by Federico: GtkButton/GtkScrollbar and text selection.

 you'd write a GtkTreeViewView object that'd draw a treeview. That's
 indeed kinda very useless.

If one would do *real* MVC, then something like a GtkButtonView does make sense 
and is definitely not useless.  The point is then that you have different 
implementations of GtkButtonView for e.g. normal displays, small displays, 
touch screen/tablet.  You would also have different implementations of a 
GtkButtonController according to the input method used (mouse vs. touchscreen 
is a good example).


regards,

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

Re: gobject-introspection broken (?) on quartz ?

[Kristian Rietveld]

Which machine is this on?  If this is on Tiger, you need to build yourself a 
newer make (3.71, it's in MacPorts) because things break with the (old) make 
3.70 that's shipped with latest XCode for Tiger.

regards,

-kris.

On Nov 18, 2011, at 6:32 AM, Paul Davis wrote:

 make
 Makefile:2712: *** Need to define GLib_2_0_gir_LIBS or
 GLib_2_0_gir_PROGRAM.  Stop.
 *** Error during phase build of gobject-introspection: ##
 Error running make   *** [8/14]
 ___
 gtk-devel-list mailing list
 gtk-devel-list@gnome.org
 http://mail.gnome.org/mailman/listinfo/gtk-devel-list

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

Re: gobject-introspection broken (?) on quartz ?

[Kristian Rietveld]

On Nov 18, 2011, at 2:03 PM, Paul Davis wrote:

 On Fri, Nov 18, 2011 at 7:56 AM, Paul Davis p...@linuxaudiosystems.com 
 wrote:
 On Fri, Nov 18, 2011 at 3:18 AM, Kristian Rietveld k...@loopnest.org wrote:
 Which machine is this on?  If this is on Tiger, you need to build yourself 
 a newer make (3.71, it's in MacPorts) because things break with the (old) 
 make 3.70 that's shipped with latest XCode for Tiger.
 
 did you mean GNU Make? which is at version 3.82 now?

My apologies (I didn't have my Tiger machine handy), I meant that Tiger ships 
with GNU make 3.80 and you need at least GNU make 3.81.  This is due to usage 
of $(or ...) and/or $(and ...) which are only available in 3.81 onwards.


-kris.

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

Re: gobject-introspection broken (?) on quartz ?

[Kristian Rietveld]

On Nov 18, 2011, at 1:56 PM, Paul Davis wrote:
 
 yes, this is Tiger. Is there any particular reason why this has not
 been added to the bootstrap process?

I think because not that many people are building on Tiger anymore.  I stumbled 
across it this Summer and I just ended up installing GNU make from MacPorts to 
fix the issue.  Snow Leopard ships with 3.81 and thus is not affected.

 and is there a particular reason
 why this breakage has crept in for a particular, less than critical
 component of the stack when the old make has worked just fine for
 years?

The issue is caused by the GObject-introspection makefiles using $(or ...) and 
$(and ...).  These makefiles are included by projects that support 
GObject-introspection and generate GIRs at compile-time.  I would guess relying 
on GNU Make 3.81 is fair since it has been out for a while and obtaining it on 
Tiger is easy ...


regards,

-kris.

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

Re: RFC: Model-View-Controller

[Kristian Rietveld]

Hi,

I share the concerns Mitch has raised.  It is obvious that a redesign would 
help the organization of widget code and several people have thought about ways 
this can be done (e.g. Rapicorn and I also vaguely recall somebody trying to do 
pure MVC with GTK+).  Some more comments and thoughts below.


On Nov 9, 2011, at 7:12 PM, Benjamin Otte wrote:
 - widget complexity
 Our widgets - even the simple ones - are hellishly complex objects.
 Without reorganization of the code they'll get unwieldable. Here's the
 5-digit source files in the gtk sources:
 10464 gtkfilechooserdefault.c
 10482 gtkentry.c
 (10947 gdkwindow.c)
 13857 gtkwidget.c
 16439 gtktreeview.c

Of the widgets you list I don't think GtkFileChooserDefault belongs there, 
because it is a composite widget where the others are not.

 We need a way to make that code readable again. Also, those files
 generally have lots of interactions and a high cyclomatic
 complexity[1], which makes it hard to understand what they do. This in
 turn leads to people being afraid of touching them. And that starts a
 vicious cycle.

About the interactions, does the MVC approach proposed really solve this and 
doesn't it lead to people being afraid to touch the class hierarchies and 
interactions between the different views and controllers?  In the simple 
examples in your other e-mail, there are already quite some connections between 
objects involved.

 I'm proposing a Model-View-Controller split for widgets.[2]
 
 I want to split the source code for widgets into three parts. This is
 mostly an internal cleanup and should not affect applications that use
 widgets. It would however change the way widgets are coded. So this is
 mostly relevant for our own gtk/ directory, but would also be
 interesting for other widgets ike the evo calendar, EMap, the
 WebKitWebView, GtkSourceView, you name it.

So if I understand correctly, you want to re-do the implementation of widgets 
without changing the outside interface?  But you also want to expose the MVC 
objects to the outside to be used in third-party widget implementations.  I am 
wondering whether this won't get very confusing/messy.


The reasons why objects are currently so large are:

  1) View and Controller are combined in the same class, as has already been 
pointed out.
  2) Objects are often too specific to allow re-use; granularity is wrong.

If I would apply pure MVC to GtkTreeView, then we will still end up with a huge 
view and a huge controller class.  We already have the model class.  To achieve 
the desired simplification GtkTreeView will have to be split up into pieces, 
pieces which can be better re-used.  I see this transformation as a separate 
one from the transition to MVC.

So what you are actually proposing is both introducing MVC and splitting up the 
objects (albeit in an API compatible fashion).  I would argue that with just 
introducing the splitting and not doing MVC, we can already gain the majority 
of the code clean up.  I explicitly say majority, not all, because your 
approach, if feasible, would further increase code re-use. You might indeed 
want to split out rubberbanding into a separate class to not have to 
re-implement it in both an item container and somewhere else.  Whether we 
should then call this a rubberbanding Controller is something I am unsure 
about.

For GtkTreeView a start was made by pushing code into GtkCellArea, but much 
more is necessary.  In an earlier thread, I have once sketched plans to have a 
generic item container which would implement click handling, rubberbanding, 
drag and drop, keyboard handling, etc, etc.  Subclasses can then plug in 
specific layouting algorithms which make them a GtkTreeView or GtkIconView.

The other point to make here is that the above sketch for GtkTreeView is one 
possible way to do it.  The main problem with point 2) is picking the right 
granularity, there are multiple thoughts about this (e.g. the micro widget 
approach from Rapicorn) and making this decision can turn out to not be that 
easy.

 Sounds like a plan?

My feeling is that in order to come up with a solid plan, prototyping has to be 
done to figure out whether this is feasible and how things will look like.

regards,

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

Re: GTK + Clutter next step(s)

[Kristian Rietveld]

On Oct 29, 2011, at 12:36 PM, Benjamin Otte wrote:
 On Wed, Oct 12, 2011 at 12:43 PM, Robert Bragg rob...@sixbynine.org wrote:
 
 One thing worth noting here is that we don't yet have proper OSX
 support in Cogl. Currently the OSX winsys support is still in Clutter
 and we use a dummy/nop winsys in Cogl. The plan is to add proper
 support to Cogl it just hasn't happened yet.
 
 I'm not overly concerned about other backends. As long as we have a
 clear path that enables those backends to work somehow (and broadway
 is as scary as OS X here), I don't mind if nobody has walked that path
 yet. After all, GTK 3 still doesn't work too well on anything but
 Linux.

GTK+ 3 actually does work reasonably well on OS X. 

Whether or not you are concerned about other backends is a discussion that has 
been had before -- is GTK+ a cross-platform toolkit or should other backends 
not hold the X11 part from progressing? Perhaps it is time that a real decision 
is made here or that we set up an explicit matrix with features that are 
supported or not supported on the different platforms.

 Yes, I definitely think that nobody should use OpenGL in the GTK world
 unless he specifically tries to marry OpenGL based things with GTK
 widgetry. I would be very scared of anybody having a glBegin() in
 their widget's draw handler.
 But I'm running into projects on a weekly basis that have GL
 requirements and have no clue how they can achieve what they want with
 GTK 3. And I certainly want to make that possible. I definitely don't
 want to make it easy.

I find this a rather weird statement.  To me, GL support is an important 
requirement for a windowing toolkit.  There are very valid reasons to use GL in 
GTK+ applications, such as CAD and scientific visualization, as Peter Clifton 
has also pointed out in this thread.

Even though Cairo is clearly preferred for 2D drawing, I don't see a reason to 
force people who already have portable 2D drawing code (for e.g. 
visualization) to Cairo or to make it harder to use such existing code.  For 
3D, Cairo is not an option at all.

I don't believe that people would use OpenGL instead of Cairo without 
sufficient reason for newly written code or for writing widgets, so I don't 
agree with your reasoning attached to the quote of Larry Wall.


regards,

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

Re: Severe treeview performance regression (Gtk2 - gtk3)

[Kristian Rietveld]

On Oct 20, 2011, at 12:03 PM, Clemens Eisserer wrote:
 I hacked together a simple sample application which compiles under
 gtk2 as well as gtk3: http://93.83.133.214/gtklist.c
 Just maximize it (preferable on a large screen) and scroll with your
 wheel - the gtk3 version should feel a lot slower.

I have noticed that as well on GTK+ 3 a year ago or so, and I don't think this 
is specific to GtkTreeView.  Back then I got the impression that some parts of 
the drawing synchronization (i.e. draw the moved area and the newly exposed 
area at the same time instead of first drawing the moved area and drawing the 
newly exposed area later) did not make it into the client-side-windows code.  
However, I was told that such problem should not exist with client side windows 
(I was not convinced though).


regards,

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

Re: GtkComboBox with a tree view

[Kristian Rietveld]

2011/10/15 Sébastien Granjoux seb@free.fr:
 Could I rely on the fact that the GtkComboBox will display the items as a
 tree view? I means is it a bug if a theme doesn't do it correctly or it is
 rather just an hint. Does it makes sense to add a function to easily set
 this?

You should not rely on that.  It is up to theme to pick either the
tree view or the menu mode.  This feature was really added for
platform styling/integration. Back when this was being designed, the
reasoning was that a picker popup looks like a menu on UNIX and like a
list on Windows, etc.

 Is it useful that I spend time on GtkComboBox code trying to make it faster?
 As the GtkTreeView is much faster, I suppose we can reach the same
 performance with the GtkComboBox. Or do we consider that the GtkComboBox is
 designed to handle only a small number of items? As the list contains a lots

IMHO GtkComboBox has not been designed to handle thousands of items,
the UI is also not up to that. Given that you are going to need a
search feature is likely another indicator that the combo box UI will
not solve your problem.


regards,

-kris.
___
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

[Kristian Rietveld]

On Sep 12, 2011, at 9:15 PM, John Ralls wrote:
 
 I rebased a local branch off quartz-integration against master and carefully 
 went through all of the changes. There were indeed a couple that didn't have 
 bugs, so I created the bugs and attached the relevant patches. There were 
 some others that were quite old, so I updated the patches on the bugs.

That's great!  Much appreciated.  Now that I seem to have GtkTreeModelFilter 
under control, I will move back again to Quartz review.


thanks,

-kris.

___
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

[Kristian Rietveld]

On Wed, Sep 7, 2011 at 11:10 AM, Milan Bouchet-Valat nalimi...@club.fr wrote:
 Le mardi 06 septembre 2011 à 16:34 -0700, John Ralls a écrit :
 It's not a fork of Gtk+ (yet, though on days like this one I get
 really tempted). I actually revived the gtk-osx project on SF; the
 previous version was an actual fork of Gtk1.
 So let's improve things a step more, and completely merge the project.
 Sounds like the natural end of the story. :-)

 As I explained earlier, the changes *are* patches, they *are* attached
 to bugs in Bugzilla, and Kris Reitveld *has* promised to review them.
 When he has had time to do so and they have been polished to his high
 standards, they will be committed into mainline.
 If you need Kris to review your patches before committing them to
 mainline, then the usual way is to have a branch in the GTK git
 repository, and rebase it into master when it's accepted. That's much
 easier for everybody, much better than putting them on a different repo.

To clarify this, the branch is already in the GTK+ git repo and not on
SF.  As John has mentioned, all patches are attached to bugs in
Bugzilla, which I prefer above digging through a branch to find the
changes.


regards,

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

Re: Alt and Command keys in the quartz backend

[Kristian Rietveld]

On Sep 6, 2011, at 6:58 PM, Paul Davis wrote:
 this seems to be about two different things, neither of which are in
 conflict (and i think john actually agrees with this).
 
 1) whether or not the Alt key should generate MOD1 as a modifier
 2) whether or not code that wants to be cross-platform can assume that
 they can use MOD1 with its own chosen semantics

I have typically avoided the debate on modifiers/etc. since I am not very 
familiar with the X11 background of them either.

The two things you set out indeed seem to make much sense to me. The big 
question to me is around (2), if MOD1 is passed by GDK, should  GTK+ or an 
application still include cross-platform handling or should the cross-platform 
handling already been taken care of?  I get the impression that given that 
keybindings still need cross-platform porting at the GTK+ level, the former is 
perhaps not a strange assumption.  For the former, having modifiers bound to 
keys with similar labels is, I *think*, helpful for implementing the 
cross-platform handling in GTK+ and/or applications. 

 if (2) was fixed so that GTK was not an example of code that assumes
 that MOD1 is free for any interpretation on any platform, then (1) is
 moot, and it really doesn't matter what the Alt key generates on OS X
 (hence, it could be MOD1).
 
 but as long as (2) remains an issue within GTK itself, its hard to
 argue that a key that has clearly different purposes for a large body
 of platform users of OS X should be handled by GTK as if it had some
 different meaning based on another platform.

My impression is that GTK+ has to be fixed first here before we can consider 
binding the key labeled with Alt to MOD1 like is done on other platforms.



regards,

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

Merged treemodel-fix branch

[Kristian Rietveld]

Hi all,

In May of this year, I announced I would be fixing the handling of
GtkTreeModel:row-deleted in GtkTreeModelSort and GtkTreeModelFilter
together with bringing more parts of this code under unit test and
fixing/reviewing some bugs[1].  Three months later, I seem to be
finally done.  The work has been carried out in a local treemodel-fix
branch, which I just merged into master.  If no big regressions turn
up in the coming 1 to 2 months, I will consider merging this into 2-24
as well.  Unless there are objections to that of course.

So what has been done exactly?  This is easiest to grasp in categories:

Unit testing

- All GtkTreeModel.* unit tests have been put into a single binary
(named treemodel).
- Many unit test clean ups, improvements and additions in order to be
able to refactor parts of the code.
- Addition of GtkTreeModelRefCount to the gtk/tests/ directory to
help with unit testing model reference counting. GtkTreeModelRefCount
is not available in the public API nor is it intended to be in the
future.
- The reference counting mechanisms of GtkTreeModelSort and
GtkTreeModelFilter are now unit tested.

Performance
---
- Bug 611922 - gtk_tree_model_sort_ref_node() is too slow
  This affected tree models with a deep hierarchy which were wrapped
in a GtkTreeModelSort.
- Bug 616871 - GtkTreeModelFilter wasting CPU in g_array_remove_index()
  Xavier Claessens provided a patch to replace the usage of GArray in
GtkTreeModelFilter with GSequence.  This has greatly increased the
performance of the filter model, especially in cases where many rows
are being removed/added (e.g. live filtering views).
- A similar patch was written and applied to GtkTreeModelSort.

Misc.
-
- Reference counting in GtkTreeModelFilter has been reworked to
function properly.  Before, unused levels were never released from the
cache, because the implementation was flawed.
- Both GtkTreeModelSort and GtkTreeModelFilter now emit row-deleted
*after* removing the node from their internal data structures.
Furthermore, both models have been fixed to never unref an already
deleted node.
- Various large functions in GtkTreeModelFilter have been factored
into smaller ones.  Code duplication has been reduced.
- Bug 621076 - GtkTreeModelFilter does not emit all signals in some cases

Documentation
-
- General documentation has been added on the reference counting
methods of GtkTreeModel and rules that should be taken into account
when these are used. See [2].
- Also, I wrote extensive documentation about the internals of
GtkTreeModelSort [3] and GtkTreeModelFilter [4].
- In the public documentation for GtkTreeModelFilter, a section was
added about limitations that apply to visible functions [5].


Finally, I would like to thank the following people for their
contributions in the form of test cases, notes, analyses and patches:

  Xavier Claessens
  Alberto Garcia
  Federico Mena-Quintero


In the case I introduced new bugs (hopefully not ...) or if the newly
written documentation is not clear in some places, please file a bug
or send me mail so it can be fixed. I will also blog about this merge,
which will hopefully result in some more testing of the changes.


regards,

-kris.


[1] http://mail.gnome.org/archives/gtk-devel-list/2011-May/msg00036.html
[2] http://git.gnome.org/browse/gtk+/tree/gtk/gtktreemodel.c#n200
[3] http://git.gnome.org/browse/gtk+/tree/gtk/gtktreemodelsort.c#n140
[4] http://git.gnome.org/browse/gtk+/tree/gtk/gtktreemodelfilter.c#n106
[5] http://git.gnome.org/browse/gtk+/tree/gtk/gtktreemodelfilter.c#n60
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Merged treemodel-fix branch

[Kristian Rietveld]

On Mon, Aug 22, 2011 at 10:16 PM, J. Ali Harlow a...@avrc.city.ac.uk wrote:
 This sounds really great, Kris. Is there any chance the unit tests could
 be made callable on other TreeModel implementations (eg., for use in
 unit tests of other libraries). I have my own tests, but it would be
 even better to use a set of tests written by somebody who really
 understands what the requirements are.

The tests that we have now really center around unit testing the
models which are shipped with GTK+ itself.

Having an automatic tester for generic GtkTreeModels to test for
conformance is still something I would love to have and have been
thinking about before. It would be a module in which you plug your own
implementation of GtkTreeModel to have it tested.  I was wondering on
how this would look like -- but I guess it could be something like
gtk_tree_model_auto_test_new_with_model(GtkTreeModel*).  Second, I
think an interface is needed to tell the auto tester how to add/remove
rows in the custom model, since GtkTreeModel only deals with read
access.

I will think some more about it.


regards,

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

Re: CellRendererText::edited changes in GTK+ 3

[Kristian Rietveld]

On Fri, Aug 19, 2011 at 4:09 PM, Andrea Bolognani e...@kiyuko.org wrote:
 The attached program clearly shows how CellRendererText behaves differently
 in GTK+ 3 than it did in GTK+ 2: when using the latter, the edited signal
 is emitted whenever the user moves the focus from one cell to another,
 giving the program a chance to save the contents of the cell; when using the
 former, the signal is not emitted, so the cell behaves as if editing had
 been canceled, minus the emission of the editing-canceled signal.

Sounds similar to https://bugzilla.gnome.org/show_bug.cgi?id=653289 ;
it is likely some fallout from the factoring that went on under the
hood.



regards,

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

Re: gtk_tree_selection_select_iter after gtk_tree_store_append not working

[Kristian Rietveld]

On Fri, Jul 22, 2011 at 8:40 PM, Denis Washington den...@online.de wrote:
 However, this doesn't work. Removing the if conditional and printing out
 gtk_tree_selection_get_selected (selection, NULL, NULL) right after
 select_iter reveals that only the root element can be selected this way
 (printout is 1), while all others don't get selected (printout 0).

Do you mean to say that the iter you are trying to select is a child
of the root element?

 Digging a bit deeper, it seems that _gtk_tree_view_find_node(), called from
 gtk_tree_selection_select_path(), cannot find an RBNode belonging to the
 tree iter's path (it returns TRUE, which makes the next statement silently

In that case, there will be no RBNode until the root element is
expanded.  You cannot select child nodes which are invisible; that
is, their parent is in a collapsed state.


regards,

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

Re: reftests

[Kristian Rietveld]

On May 9, 2011, at 7:07 PM, Benjamin Otte wrote:
 I think this only makes sense if we want to continue to maintain this 
 division between frequently and less frequently run tests.
 
 What is a frequently run test? I can tell you that no treeview test
 qualifies as frequently run to me when I'm hacking on GtkPaned. And
 I think the same applies to you vice versa. Which reduces the
 frequently run tests to a number very close to 0 I guess.

Good point.  I agree.


-kris.

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

Re: reftests

[Kristian Rietveld]

On May 9, 2011, at 7:57 PM, Matthias Clasen wrote:
 I don't have a fear of toplevel dirs. If people insist on having tests
 outside of the source tree (I personally like things in gtk/tests
 ...), then what is wrong with just having reftests/ as a toplevel
 directory ? We already have perf/, and we can add unittests/ too.

Benjamin raised the issue that the tests are re-linked all the time if they are 
in gtk/tests/ (unless you learn yourself to use make all-am instead of a 
plain make like I did ...).

If we decide the move the tests from gtk/tests/ to somewhere else, I wouldn't 
mind a toplevel unittests/ directory.


 As
 for testgtk, I think that would be really misplaced under demos/,
 since its code is the opposite of a demo of good GTK+ coding
 practices. If we want to clean this up some more, I'd instead propose
 to move the random other pixbuf test things from demos/ to tests/, and

Good idea!  I've never understood why these pixbuf things were in demos/.

 move the new examples from examples/ to demos/. At the same time we
 can kill the old, dead examples, and the incomplete testgtk copy under
 demos.

Agreed.


regards,

-kris.

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

Fixing GtkTreeModel:row-deleted once and for all

[Kristian Rietveld]

Hi all,

The following two commits sparked my interest to look into the 
GtkTreeModel:row-deleted saga again, which has been haunting me for the last 9 
years:

  0c3da06 gtk_tree_model_filter_row_deleted: don't emit signals too early
  f632956 Fixed GtkTreeModel::row-deleted documentation

This because I have always been fully convinced that models implementing 
reference counting (which both GtkTreeModelFilter and GtkTreeModelSort do) 
could not safely emit row-deleted after deleting the node from the internal 
data structure, but rather had to do this before modifying the internal data 
structures.  This belief came from the following comment in gtktreemodelsort.c, 
added in February 2002 and see also a mailing list discussion from 2007[1]:

  /* we _need_ to emit ::row_deleted before we start unreffing the node
   * itself. This is because of the row refs, which start unreffing nodes
   * when we emit ::row_deleted
   */

Upon further investigation, this statement is false, because nodes that have 
been deleted are never unreffed after emission of row-deleted. This is 
mentioned in the documentation for gtk_tree_model_unref_node().  The issue for 
which the above comment was added, has actually been fixed for real in April 
2002 in commit 873e9ce4.  By no longer calling unref for the deleted node, this 
commit fixed the problem at hand.  Unfortunately, I did not manage to connect 
these two commits to each other back then (can't blame myself, since I was only 
17 at that time).


Fixing this
===

Based on these results, I started a local branch in which I have also fixed 
GtkTreeModelSort to emit row-deleted *after* the internal data structures have 
been updated.  All GtkTreeModel unit tests have been consolidated in a single 
binary and more tests have been added.  More importantly, GtkTreeModelFilter 
has been corrected to never call unref on deleted child nodes.

Before I merge these fixes into master, I plan to also do the following to 
verify that everything will finally work correctly within this framework:

1) Review and/or fix the following bugs, and bring them under unit test:

  - 621076  GtkTreeModelFilter does not emit all signals in some situations
  - 616871  GtkTreeModelFilter wasting CPU in g_array_remove_index()
  - 611922  gtk_tree_model_sort_ref_node() is too slow
  - 351814  GtkTreeModelFilter: row-deleted should probably emit signal first, 
then decrease visible nodes
  - 540605  Possible leak in GtkTreeModelFilter

If you know of any bug that is related to this, please let me know.

2) Bring reference counting under unit test, including the internal reference 
counting done by GtkTreeModelSort and GtkTreeModelFilter.  For this, I will 
likely write a custom model that does reference counting from which the 
reference counts of given nodes can be read out.  We can use this information 
to verify whether the parent model or parent view is referencing the correct 
nodes and also if references are released when required.

3) Document how GtkTreeModel's ref_node and unref_node are supposed to be used 
and why they are there.  This is unclear to many people.


I hope this will rid us of nasty GtkTreeModelSort/GtkTreeModelFilter bugs for a 
long while as well as increase the maintainability of this code.


regards,

-kris.



[1] http://mail.gnome.org/archives/gtk-devel-list/2007-May/msg00109.html
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: reftests

[Kristian Rietveld]

On May 5, 2011, at 6:24 PM, Benjamin Otte wrote:
 On Thu, May 5, 2011 at 10:18 AM, Kristian Rietveld k...@gtk.org wrote:
 As we've already discussed on IRC some time ago, I would really like to see 
 all
 GTK+ unit tests in one single place, instead of in several different places 
 in the
 source code.  We really need people to run the unit tests more often and thus
 this needs to be made easy (like you also mention in your enumeration above),
 I don't think putting different unit tests at different places makes this 
 easier.
 
 I do agree with putting all things in one location. However, I do not
 agree with people need to run tests more often. I think running
 tests is a job for machines.

Yes, ideally, we would have a buildbot that runs all tests after compiling a 
new revision of GTK+.  Of course in addition to people that run the tests after 
refactoring a part of the source code before committing.


 We can always distribute the unit tests as a separate tarball if that will 
 help, can't we?
 
 Well yeah, but then it still requires compilation of something. The
 approach with Here, open this in glade and Does it look like this
 screenshot? is a lot better, because it's very easy.

For testing layout and rendering it will work very well, but I do not have the 
impression that all tests can be made as easy as this.  For example, the tree 
view scrolling tests can definitely not be done in terms of creating a glade 
file and comparing screenshots.  However, it would definitely be interesting to 
include reference screenshots for a few of the tests (not all, that would be 
too much).

Which raises another question, would it be a good idea or make sense to merge 
the image differ into the GTK+ test utils so that other tests (e.g. the tree 
view scrolling test suite) can make use of it?


 Another question: why was gtk-reftest put in gtk+/tests/reftests/gtk-reftest 
 instead of in gtk+/gtk/tests/gtk-reftest, with a subdirectory reftests 
 containing the glade files?  Then on make check for the GTK+ unit tests, the 
 reftests would automatically be executed as well.  Currently, you also need 
 to compile a GTK+ checkout to use reftests, right?
 
 I never liked the idea of putting tests in the same directory tree as
 the actual source code, because in the good case it creates spam to
 stdout (about entering directories I don't care about) and in the
 worst case it actually compiles tests, so it not only spams stdout but
 it also takes lots of time relinking. If I am actively working on

The relinking annoys me as well which is why I started to compile in the gtk/ 
subdirectory with make all-am to avoid that :)

 So I do think that tests, just like documentation should live outside
 of the normal source tree. Which is why I put it there.

Makes sense and I have to add that I do not have a very strong opinion with 
regard to where exactly the tests are located.  However, it looks like there 
are two main reasons the tests were put at this location:

1) There seems to be some logic behind where frequently run and less frequently 
tests are located.  Quoting from [1]:

``
1) Figure a place for the test case. For this it's useful to keep in mind
   that make check will traverse CWD recursively. So tests that should be
   run often when glib, gdk or gtk changed should go into glib/glib/tests/,
   gtk+/gtk/tests/ or gtk+/gdk/tests/. Tests more thorough or planned to
   be run less frequently can go into glib/tests/ or gtk+/tests/. This is
   e.g. the case for the generic object property tester in
   gtk+/tests/objecttests.c. To sum up:
 glib/tests/# less frequently run GLib tests
 glib/glib/tests/   # frequent GLib testing
 glib/gobject/tests/# frequent GObject testing
 gtk+/tests/# less frequently run Gdk  Gtk+ tests
 gtk+/gdk/tests/# frequent Gdk testing
 gtk+/gtk/tests/# frequent Gtk+ testing
''

I think this only makes sense if we want to continue to maintain this division 
between frequently and less frequently run tests.

2) Tests that are maintained outside the normal source tree could be subject to 
becoming unmaintained quite quickly [2], which in turn leads to tests being run 
less often.  However, if the tests will still live under gtk+/unittest/ and are 
part of the default full build, then this might not be that big of a problem.

 These sounds like numbers I would expect.  What in GTest would need 
 improvement to realize this?
 
 GTest mainly needs usability improvements such as those you pointed
 out by those error messages. (I'm sorry if I offended you by taking a
 test written by you as the bad example, I just took a random file from
 gtk/tests as an example of why our current approach is bad.) The
 problem is that currently running tests (or a single test) manually is
 complicated and oftentimes ends up with unparsable error messages that
 often are no help in actually figuring out what got broken

Re: reftests

[Kristian Rietveld]

Hi Benjamin,

On May 3, 2011, at 10:01 PM, Benjamin Otte wrote:
 with the latest commits[1] I have added reftests to GTK. Reftests are
 my approach at getting layout and rendering behavior of gtk tested.
 I've added a bunch of tests already for the things I have fixed and
 will continue to add tests for bugs I fix. For what the test runner
 does, see the commit message in [1], for what reftests are, see [2].
 The test runner works very well, even though it is still a bit rough
 around the edges, but that's mostly because gtester needs to be made
 better to cope with generic testing. (It's way too crash-happy as-is.)

Very nice to see that we are (finally) getting testing in place for layout and 
rendering code!

 In this mail, I want to go into the motivation for writing reftests
 and why I didn't want to make use of the previous test infrastructure.
 I tried to achieve the following goals (if you think I could achieve
 them better, please speak up):
 - It should be easy to create tests
 - It should be easy to run tests
 - It should be easy to understand tests
 - It should be easy to fix problems shown by tests
 - The test infrastructure should easily scale

As we've already discussed on IRC some time ago, I would really like to see all 
GTK+ unit tests in one single place, instead of in several different places in 
the source code.  We really need people to run the unit tests more often and 
thus this needs to be made easy (like you also mention in your enumeration 
above), I don't think putting different unit tests at different places makes 
this easier.

So I think it would be good to consolidate into one location.  Some ideas below.


 - It should be easy to create tests
 Writing a test is something people hate to do. It's the #1 reason why
 Open Source projects don't write tests. Also, it's the #1 reason why
 bugs aren't fixed. If people would file bugs with easy to reproduce
 tests instead of saying in my custom application, when I do X, Y
 happens and not Z, there'd be a much higher chance developers would
 be interested in looking at it.
 This is why the reftests use stock ui files that can be created in
 Glade. So everyone that is able to use Glade can create a test file.
 And we can just use it.

Agreed.  For all different components of GTK+, we need to think on how to make 
it easy to write tests.  I did this for the filter model in the past and I 
actually receive additional tests in bugzilla now (which I am in the process of 
reviewing).


 - It should be easy to run tests
 It's quite hard to get someone to run a test. It requires compilation
 of a GTK checkout. That is not good.

We can always distribute the unit tests as a separate tarball if that will 
help, can't we?

 For a developer, too, it's quite complicated to run a test from
 someone else, say from bugzilla or a pastebin. Either you have to
 invoke gcc manually or you have to integrate it into the testsuite
 infrastructure.
 With reftests, you dump the ui file somewhere and run
 tests/reftests/gtk-reftest path/to/file.ui and that's it. You can then
 spend the rest of the day updating the testcase wherever you want, and
 pastebin or mail it back and forth with whoever you work on the test
 together.

Of course this will work fine with glade files, but I don't see how this makes 
it easier to run other kinds of tests.

Another question: why was gtk-reftest put in gtk+/tests/reftests/gtk-reftest 
instead of in gtk+/gtk/tests/gtk-reftest, with a subdirectory reftests 
containing the glade files?  Then on make check for the GTK+ unit tests, the 
reftests would automatically be executed as well.  Currently, you also need to 
compile a GTK+ checkout to use reftests, right?


 - It should be easy to understand tests
 Here's an example output from the current testsuite:
  /FilterModel/filled/hide-root-level:
  ** ERROR **: Signal queue empty
  aborting...
 It's hard to understand what might be broken. The output from current
 tests is both sparse and not very informative. If somebody came into
 IRC and said he ran make check and got this, I doubt anybody would
 know how to fix it.

This error is very easy to improve, for example, 4 lines down in the source 
code are expected this, got that error messages.

I think your actual point is that the output of GTest can be significantly 
improved.  These filter model errors are just done with separate g_error() and 
g_assert_not_reached() calls, because GTest did not provide API for outputting 
more elaborate diagnostics about test failures.  I have a similar case in the 
scrolling tests for tree view:

g_assert (allocation.y == rect.y + ((rect.height - allocation.height) / 
2));

The output of this failed assertion is not really nice to the eyes.  It would 
be nice if the assertion macros could be improved to also accept a 
human-readable string of what's going wrong together with the expected and 
received value.  But perhaps this is already present in the gtestutils and I 
missed it.

Re: tooltips and scroll events

[Kristian Rietveld]

On Tue, Apr 26, 2011 at 10:54 PM, Matthias Clasen
matthias.cla...@gmail.com wrote:
 Any objections to this change?

 Sounds right to me; of course, I haven't tried it...

Just pushed the change to master.


regards,

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

Re: tooltips and scroll events

[Kristian Rietveld]

On Apr 25, 2011, at 4:34 PM, Paul Davis wrote:
 currently, gtk2's tooltips code handles scroll events entirely
 differently to button and key press events. even though one can
 connect to the query-notify signal to get rid of a tooltip when a
 scroll event happens, the tooltip will reappear shortly thereafter. i
 haven't looked by i'm guessing that gtk3 code looks pretty similar.
 
 this is pretty problematic for widgets that want to use scroll events
 internally - they will basically display a tooltip for a substantial
 part of the time that a pointer is within their bounds. the tooltip
 won't really vanish until the user actually generates a key press or
 button press event.
 
 there are complicated patches for this, and there's a simple patch:
 treat a scroll event equivalently to a button/key press/release. does
 anyone know of a good reason not to do this?

I don't, and I think we should apply the patch you are proposing.  Currently 
scroll events are handled similar to motion/enter notify events, which means 
that when scrolling (for example) a tree view with scroll events, a tooltip 
continues to be visible.  I agree with you that this behavior does not seem to 
make much sense.

Any objections to this change?


regards,

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

Re: treeview-refactor branch has landed.

[Kristian Rietveld]

On Fri, Dec 17, 2010 at 7:57 AM, Tristan Van Berkom
trista...@openismus.com wrote:
 The 'treeview-refactor' branch has landed in GTK+ master.

I would like to take this opportunity to thank Tristan for all the
hard work done.  This refactor was badly needed and opens up a whole
lot of new opportunities.  I hope waiting for me to catch up all the
time hasn't been annoying.

Furthermore, I would encourage people who use complex tree views in
their libraries or applications to test these as soon as possible and
report any issues they find.  Although we have put significant time in
checking all the corner cases, there is a good chance we might have
missed something.


thanks,

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

Re: GtkTreeView breakage in master

[Kristian Rietveld]

On Sun, Dec 5, 2010 at 5:39 AM, Tristan Van Berkom
trista...@openismus.com wrote:
 It seems that the problem has something to do with the
 recent gdk changes, dirty areas in the treeview seem to
 miss out on getting redrawn (GdkWindow issues ?).

 Here is a screenshot of the problem:
  http://people.gnome.org/~tvb/broken-testtreeedit.png
 Usually there are supposed to be 4 rows of data, the
 other rows disappear after resizing the window (oddly,
 it seems they disappear only once the GtkCellRendererProgress
 is shown)... mousing over the rows make the rows re-appear.

Interestingly, this is a bug in the drawing path of
GtkCellRendererProgress.  This only occurs if the bar_size
GtkCellRendererProgress is about to draw is zero.  In this case, there
is actually no rectangle to be drawn (width or height will be zero)
and gtk_render_background() will screw up.

I modified GtkCellRendererProgress in master to not call
gtk_paint_box() if bar_size is zero, simply because it does not make
sense to try a draw of a zero-width or zero-height rectangle.  This
fixes the issue seen in testtreeedit.

I guess it is useful if somebody checks gtk_render_background()
though, I do not think it is intentional that an attempt to draw a
zero-width or zero-height rectangle screws up all subsequent
rendering.

 Also, it seems the buttons in the treeview columns (and
 the rendered GtkCellRendererProgress) have lost their
 etchedness, this part I am assuming is not a bug but
 probably part of the result of Carlos's style context
 work (probably I'm just seeing un-themed progress
 renderers and treeviewcolumn buttons)...

Yes, I think so too.  There are some more things wrong in the
rendering of GtkTreeView currently. Carlos mentioned to me that he has
some GtkTreeView patches in the queue, so I think we will be fixing
this in the near future.


regards,

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

Re: GtkTreeView Refactoring Considerations [was Re: Private types inside GTK+]

[Kristian Rietveld]

On Sun, Oct 31, 2010 at 7:21 AM, Tristan Van Berkom
trista...@openismus.com wrote:
 Ok so I'm pretty much finished the request/allocation code... I've got
 as far as having a list of renderers with allocated positions and sizes
 come time for -render()/-event() etc.

 If I understand correctly about cell_area vs background_area, the
 difference is basically only the focus line width... the reason for
 this is that we want cells to be allowed to fill the whole background
 area with a possible background color before we go ahead and pain a
 dotted focus line over the possibly modified background area.

That the focus line width is the only difference is true as far as
GtkTreeViewColumn is concerned.  Outside of that, there is more,
GtkTreeView will calculate cell_area from background_area taking into
account vertical-separator, horizontal-separator style properties,
depth of the current row, expander indent settings, etc.

 so currently the api on the GtkCellArea only takes a single cell_area
 when rendering, I think thats going to be fine in general and make for
 a clearer API (let me know if I missed something).

 So for this I'd like to add a focus-line-width property to the
 base class GtkCellArea, and just make the cell area implementations
 always request space for focus-line-width around cells ... then
 come time to render we just create a background/cell_area based
 on the focus-line-width and pass both areas to
 gtk_cell_renderer_render()... I'll do that part presently.

Reversing the calculation, so calculating background_area from
cell_area, will not always work as far as I can see now.  There's more
to take into account than just focus line width as I outlined above.
background_area has slightly different semantics than just cell_area +
focus line width + separators in some cases.  I cannot precisely
answer the question right now, but when reviewing the branch, I will
have to compare GtkCellAreaBox with
gtk_tree_view_column_cell_process_action() anyway, after which I can
go into more detail.  I should perhaps look into bringing this stuff
under unit test at the same time ...

 /* When an allocated width for a height for width treeview changes,
  * its important to flush out the previous results (or when we
  * allow the width of the treeview to shrink in consequence of
  * data updates and we may want to re-request the whole thing),
  * for this we have:
  */
 void gtk_cell_area_iter_flush (GtkCellAreaIter *iter);
 void gtk_cell_area_iter_flush_preferred_width (GtkCellAreaIter *iter);
 void gtk_cell_area_iter_flush_preferred_height_for_width
                                        (GtkCellAreaIter *iter,
                                        gint             for_width);
 void gtk_cell_area_iter_flush_preferred_height (GtkCellAreaIter *iter);
 void gtk_cell_area_iter_flush_preferred_width_for_height
                                        (GtkCellAreaIter *iter,
                                        gint             for_height);

Note that I haven't looked into the actual code yet (hope to get to
that during the week), but one of the questions will be how much data
is exactly cached and how?  GtkTreeView currently employs a RBTree to
efficiently cache/store height data and I think we would want to avoid
having more data structures next to that caching similar or related
data as that might not help performance.  (I am thinking 1+ row
tree views here).



regards,

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

Re: GtkTreeView Refactoring Considerations [was Re: Private types inside GTK+]

[Kristian Rietveld]

On Sun, Oct 31, 2010 at 3:17 PM, Tristan Van Berkom
trista...@openismus.com wrote:
 Whew, ok I implemented GtkCellArea-render for GtkCellAreaBox for the
 most part, however I'm still missing the GtkCellRendererState flags ;-)

 So for this part I was thinking it might make more sense to create
 a new GtkCellAreaStateFlags type with just per-row states (and add that
 as an argument to GtkCellArea-render() and also GtkCellArea-event())

Most of the states in GtkCellRendererState are actually per-row states
already (selected, focused, etc.) and are toggled by GtkTreeView and
GtkTreeViewColumn when rendering the cells.  Though one state,
sorted, is obviously per-column.  Did you mean to have a new
GtkCellAreaStateFlags that will have flags per *cell area* and thus
per *column*?

 and then somehow tidy up the code that in GtkTreeViewColumn is
 currently:

  _gtk_tree_view_column_count_special_cells (tree_column)

This function is part of implementing the key navigation behavior.  A
special cell is one that is editable or activatable.  The rule is
that if there's a single special cell in a column, a focus rectangle
is drawn spanning all cells in that column.  If there is more than one
than the focus rectangle will be drawn around single cells.  This
works fine in many cases, but can of course be awkward in a few
situations, so perhaps we want to make this configurable in the
future.  The same likely holds for a situation where you have a check
box cell renderer and text cell renderer next to each other in a
column:

   [x] [my label in a text renderer]

Akin to a GtkCheckButton, you would want the check to toggle when the
text renderer is clicked.  And it would be natural if the focus
rectangle spans the check box and the text renderer. But in other
situations, with different cell renderers, you do not want this.  This
is also something to think about and improve for the future.

I think the GtkCellArea will also allow us to get rid of
_gtk_tree_view_column_get_cell_at_pos(), which I have never really
liked for some reason.


 For focus handling and such I guess it will probably make sense to add:

  GtkCellArea-set/get_focus_cell()

That could work if there is the possibility to set focus around all
cells in the GtkCellArea as well and to disable focus for a given row
(if there are no special cells in a row, then a focus rectangle is
drawn around the entire row).

 Which is currently missing... then I suppose from -event() if the row
 for which an event is handled itself has focus, it will make sense to
 activate the focused cell.

I would follow the way GtkTreeViewColumn is currently handling this
for now.  Because when clicking on a check box renderer on a row that
does not have focus (and focus in tree view only really plays when you
are using key navigation), the click should likely activate the check
box renderer anyway.



regards,

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

Re: GtkTreeView Refactoring Considerations [was Re: Private types inside GTK+]

[Kristian Rietveld]

On Tue, Oct 26, 2010 at 6:34 PM, Tristan Van Berkom
trista...@openismus.com wrote:
 Depending on the GtkSizeRequestMode in use by the parenting
 layout widget (hfw of wfh), generally only allocate_width()
 or allocate_height() will be called. However there will be
 cases where we get to further reduce computing of sizes at
 -event()/-render() time by having both width and height
 allocated on a GtkCellArea (i.e. GtkTreeView's fixed-height-mode
 will allow us to just always know the complete allocated
 size and position of each renderer before rendering or handling
 events).

 After implementing the allocation methods, I'll move on
 to write/implement the actual -render() and -event() methods
 (which is more or less just copying what GtkTreeViewColumn
 does already).

As soon as you have implemented the allocation methods, I can also
take over and do the GtkTreeViewColumn migration, together with
merging in the refactorings I was talking about earlier.

 And finally what is still missing is a -get_bounds() method
 to return a GdkRectangle of the actual space used by cell
 renderers inside the space allocated to a GtkCellArea (i.e.
 to allow parent layout widgets to smartly do their focus
 painting).

So I take it we will not be doing focus drawing in GtkCellArea, but
rather in the parent layout widget, right?  The focus drawing code for
GtkTreeView is currently at several places, so I will also look into
properly migrating that.

Another thing what get_bounds() will be useful for is to make it
possible to start rubber banding when clicking on an area that is not
covered by cell contents (and is thus background).  See bug 350618.

 And then will come the grimy situation of pushing this all
 into GtkTreeView/GtkTreeViewColumn, looking in depth at
 validate_row again etc. (I'm sure I'll have some more
 questions and be happy to get any help in that area).

As soon as you have the allocate methods in place that you described
above, tell me and I can quickly do a tree view migration during the
evenings and see how far we can come with the current API.


regards,

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

Re: GtkTreeView Refactoring Considerations [was Re: Private types inside GTK+]

[Kristian Rietveld]

On Tue, Oct 26, 2010 at 3:28 AM, Tristan Van Berkom
trista...@openismus.com wrote:
 On Mon, 2010-10-25 at 17:26 +0200, Kristian Rietveld wrote:
 Hmm seems I didn't communicate this clearly enough, GtkCellArea
 is a base abstract class, and GtkCellAreaBox is the first concrete
 subclass of GtkCellArea... this allows treeviewcolumn (and other
 layouts) to communicate to the GtkCellArea over some generalized
 apis (i.e. a GtkCellArea does not contain any GtkCellAreaBox...
 together they contain GtkCellRenderers).

Aha! Sorry for misunderstanding.  But then what I said about
GtkCellAreaBox applies to GtkCellArea in general and thus the pull
model is indeed the easiest to go with now.  I understand how you got
into trouble with the CellDataFuncs and also this is solved by going
pull.

 Currently I have it setup so that the GtkCellArea class has
 -add()/-remove()/-forall() virtual methods that are expected
 to be implemented by concrete subclasses.

 Since I've went with the pull data from a GtkTreeModel/GtkTreeIter
 api style... already I've implemented:
  - gtk_cell_area_connect_attribute()
  - gtk_cell_area_disconnect_attribute()
  - gtk_cell_area_apply_attributes()

What exactly do these functions accomplish?  Are connect/disconnect
similar to the current add/remove attribute functions?  Typically we
work with one set of attributes per GtkCellLayout, or is this
something you want to change?

 From GtkCellArea base class which requires no cooperation from
 the subclass GtkCellAreaBox (the box only needs to manage it's
 list of renderers and some expand/GtkPackType attributes,
 then it needs to do it's geometry apis/-event()/-render() etc).

Yep, so we can move all the gory TreeViewColumn details to
GtkCellAreaBox.  I can also do that for you when the GtkCellArea API
takes shape as I am pretty familiar with the GtkTreeViewColumn code
and can perhaps also merge in some of the refactorings (that replace
gtk_tree_view_cell_process_action() with something much saner) I have
on my disk somewhere while at it.


 Also yesterday I gave alot of thought to how height-for-width
 geometry is going to play out in treeviews with regards to cell
 alignments and generally overall size of a GtkCellArea when it's
 size is requested for an arbitrary number of rows.

 I'm thinking of trying something like:

 /* Subclass creates a class specific 'GtkCellAreaIter' which
  * can be used to accumulate cell alignments and the overall
  * sizes when requested for multiple rows
  */
 GtkCellAreaIter *gtk_cell_area_create_iter (GtkCellArea *area);

 Then the request apis get an additional 'iter' context argument,
 it could be for instance that one might use a different 'iter'
 for different depths in the treeview (or to align cells in
 a combo-box menu together in a per submenu context).

 gtk_cell_area_get_preferred_width (GtkCellArea *area,
                                   GtkCellAreaIter *iter,
                                   GtkWidget *widget,
                                   gint *min_width,
                                   gint *nat_width);

 The above api would store the resulting overall requested
 width (and cell alignments) in the iter which was created
 by the specific GtkCellArea subclass... however it would
 return a *min_width and *nat_width which is only contextual
 to the GtkCellArea for the specific row-data that is currently
 applied.

Okay, so you need to make sure the specific row data is set first.
(If needed, we could have a likewise iter creation function that also
takes a range of GtkTreePath (start and end) as argument).

Thinking in TreeView terms/compatibility here: the
get_preferred_width() function will be very useful in getting an
initial width for TreeViewColumns, or get the preferred width when
doing auto size.  I think right now auto size will make sure that
all contents can be visible (so the width of each column is big
enough for each possible row), but perhaps it makes sense to change
this to the preferred width or have a mode toggle for this somehow.

Outside of that, the width of a TreeViewColumn is mostly fixed.  Also
because a width can be mandated by the user through manual resizing
(and this requirement is trickier than it might appear at first).

How exactly will height handling work?  Height is actually unbouded
in tree view, so I guess get_preferred_height() on the GtkCellArea
will not be of use for GtkTreeView, but can be of use for other
layouts of course.  Or will get_preferred_height() return the
preferred minimum height for the scrollable window?

Another idea is that we can possibly make the row validation scheme in
GtkTreeView more efficient (or at least have a slightly cleaner
implementation) by having GtkCellArea measure multiple rows at once
using your API above instead of calling validate_row() separately for
each row.  Though there is a case where we might need efficient single
row measurements from GtkCellArea.  This is in
validate_visible_area(), which as the name might

Re: GtkTreeView Refactoring Considerations [was Re: Private types inside GTK+]

[Kristian Rietveld]

On Sat, Oct 23, 2010 at 9:44 AM, Tristan Van Berkom
trista...@openismus.com wrote:
 I'm a few days into this and I've written up a GtkCellAreaClass and
 started out implementing an orientable GtkCellAreaBoxClass.

 An initial problem here has to do with pushing data to the GtkCellArea
 instead of pulling it from the model, do we really want to be able to
 use GtkCellArea to render cells for data that is not coming from a
 GtkTreeModel ? (is it worth the trouble ?)

I have always been relatively undecided on this and just meant to
bring up that you can distinguish between the two methods and one will
have to be chosen.  Adding to this that I haven't come up with a
concrete case yet wherein using GtkCellArea or GtkCellAreaBox without
a tree model could be useful.

Another thing that this depends on is whether cell renderers are
shared amongst GtkCellAreas in the same GtkCellAreaBox and whether
GtkCellArea implements GtkCellLayout.  From your e-mail I understood
that GtkCellArea indeed implements GtkCellLayout, does this mean that
each GtkCellArea will need its own GtkCellRenderers to render?

Would it be possible and make sense to share GtkCellRenderers amongst
GtkCellAreas that are contained in the same GtkCellAreaBox?  This
stays kind of close to the model that we currently have and you could
say that GtkCellAreaBox would pull the data and push this into a
GtkCellArea.  In this case GtkCellArea would not implement
GtkCellLayout, but GtkCellAreaBox would.

 Currently this presents a few problems, which are not
 insurmountable but still weird to handle since the whole thing
 is tied heavily into GtkTreeModel already:

      a.) We cant do gtk_cell_layout_set_cell_data_func() from
          inside the GtkCellArea, that stuff would have to be done
          from a GtkCellLayout implementation aside from pushing
          data to the GtkCellArea.

Right, I guess this is because data needs to be pushed to the
GtkCellArea whereas in order to be able to call the CellDataFunc you
need to pull the data (in GtkCellArea) first?  This should be the
responsibility of the pusher, and in case we decide to mark
GtkCellAreaBox to be the pusher, this is not a problem, right?

      b.) gtk_cell_renderer_activate() takes a path argument;
          I think it would be better if this were a gconstpointer
          user_data argument in any case that CellArea was rendered
          for something that is not a GtkTreeModel row... If I continue
          with the pushing data approach, this will likely turn into
          a detail string argument to gtk_cell_area_event().

 On the other hand, if we pull data from GtkTreeModel/GtkTreeIter we
 get to easily reuse/share code that actually pulls data from
 GtkTreeIter and pushes it to the underlying cells (as that would
 be handled by GtkCellArea), and also we have less api churn to deal
 with, since treepaths still make sense in GtkCellRenderer:activate
 signals.

Yes, that makes sense.

   - GtkCellLayout-pack_start()/pack_end() should be deprecated
     in favour of -add()/-set_child_property(), since those apis
     can only be implemented from a GtkCellAreaBox (but dont make
     sense for say; a GtkCellAreaTable or GtkCellAreaGrid).

Makes sense.

 All-in-all I'm not sure that the push data to the CellArea
 thing is going to be worth while, I'm considering changing
 this to a pull data from the model approach which seems to
 fit the current GTK+ codebase a lot easier.

Yes, perhaps pull is indeed the way to go, or have GtkCellAreaBox pull
and push this into GtkCellAreas as I described above.  Not sure if you
agree with that or whether that aligns with what you had in mind.  An
advantage of this could be that GtkCellAreaBox would be a
straightforward refactor of the current GtkTreeViewColumn as all the
layouting algorithms/calculations can be re-used.  For a start, we
would keep the same code/semantics for the cell_area, background_area
calculations (taking the h/v separator into account, focus line width,
etc.).This should make it easy to port GtkTreeView* to this without
breaking the current way of layouting, so that this can be feasible
material for 3.0.

Later we can start changing cell_area etc. calculations, either in the
same GtkCellAreaBox class or in a new one.  You could perhaps make
GtkTreeViewColumn use a different GtkCellAreaBox subclass for each
column.


regards,

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

Re: New rule

[Kristian Rietveld]

On Oct 22, 2010, at 11:38 AM, Richard Hughes wrote:
 On 21 October 2010 17:44, Bastien Nocera had...@hadess.net wrote:
 devhelp won't compile because WebKitGTK wasn't ported.
 
 and:
 
 dh-assistant.c: In function 'assistant_key_press_event_cb':
 dh-assistant.c:49:30: error: 'GDK_Escape' undeclared (first use in
 this function)

Easy fix, see:

http://library.gnome.org/devel/gtk/unstable/gtk-migrating-2-to-3.html#id1136975


regards,

-kris.

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

Re: GtkTreeView Refactoring Considerations [was Re: Private types inside GTK+]

[Kristian Rietveld]

On Thu, Oct 7, 2010 at 6:41 AM, Tristan Van Berkom
trista...@openismus.com wrote:
 I was thinking that a GtkCellArea would only render a single row
 (actually, a row in a treeview can be composed of several GtkCellAreas,
 each treeview column would use exactly one cell area to abstract a lot
 of the column code).

 Now that I look at this again I'm not sure if the GtkCellArea should
 store any information about previous and following rows
  - should the alignment of cells be stored by the GtkCellArea itself ?
  - or should it be externalized to some parenting code that pushes
    the alignment data to the area ?

 I think that the former seems more appropriate since only the CellArea
 knows how cells can be aligned for a particular implementation, and
 the initial width/height of cells in the area is also determined by
 the CellArea.

I agree that the former seems more appropriate.  This also paves a way
for doing more flexible layouting in tree view rows.  However, I guess
that we also want to support how cells are laid out right now in
columns and this requires some separate entity to maintain the
alignment and widths for a set of cell areas.

  - GtkCellArea (or a subclass) might also have to implement the custom 
 event-handling and focus drawing
 code that is currently in GtkTreeViewColumn.

 I think an abstraction api for event handling is simple enough and a
 good fit for a single-row handling GtkCellArea.

 gtk_cell_area_event (GtkCellArea  *cell_area,
                     GdkRectangle *area,
                     GdkEvent     *event);

 This would be implemented by CellArea implementations
 and basically forward the event to the appropriate cell
 renderer according to the area's layout.

 I suppose the method for invoking this by treeview for
 instance would be:
   - Get the appropriate GtkTreeViewColumn for the event-x
   - The GtkTreeViewColumn would then get the appropriate GtkTreeIter
     for event-y
   - The GtkTreeViewColumn would then push the data for that
     column into its delegate GtkCellArea.
   - Then the GtkTreeViewColumn calls gtk_cell_area_event().

 Sounds approximately right ?

It sounds interesting to me and will likely work.  Do note that
currently things are done differently, tree view makes the function
call to push the data (though this function is a tree view column
function, so must be possible to refactor this).  Furthermore,
currently not GdkEvents are pushed to the cell renderer, but rather
the activate or start-editing method on the cell renderer is
called.  I think this lines up well with the plan to have the GdkEvent
only reach the cell area.

 I think that focus painting in this case should be left to the treeview
 and the GtkCellArea continues to return bounds of the overall used
 space for it's dedicated GdkRectangle (because the treeview sometimes
 like's to paint focus which spans the entire treeview row... which
 may span several GtkCellAreas for each column; each of which may
 have a different bounds in height).

There's also a case in which focus is drawn around a single cell
renderer (that is part of a column together with other cell
renderers).  So this means that either the cell area can draw this
focus, or the exact coordinates of this cell can be acquired from the
cell area.

 Ok good points, you'll notice I left out GtkCellAreaManager comments
 here...

 I think you're right that the whole big picture is much and probably not
 reasonable to get done by 3.0.

 The best move I think is to break this down into iterations, since my
 immediate concerns are about actual rendering and alignment of cells
 (i.e. achieve height-for-width treeviews and alignment of cells in
 combo boxes)... hopefully I can come up with something good and
 extendable for the GtkCellArea.

Yes, we should definitely break this down into iterations.  Starting
with pushing the cell renderer lay out code from GtkTreeViewColumn
into something like a GtkCellArea sounds like a good start to me.


 The concept of row separators and group headings will need some
 thought, I'm not sure it makes sense to chose a different GtkCellArea
 class to render a different row, these cases may be better handled
 as general functionality of the base class (which could be overridden
 by subclasses to achieve a different overall look-n-feel of the
 treeview).

Definitely requires more thought and can, as far as I can see, be done
separately from GtkCellArea.

 I also wonder with some of the offscreen rendering magic recently added
 we can even get GtkButtons to be virtually embedded into a GtkCellArea
 subclass (ofcourse without allocating a separate instance of the
 GtkButton for every row of data being the challenge)... by simply
 rendering the button onto every row...

Interesting idea, and since you want to make it possible to push
GdkEvents into GtkCellArea, the button will also behave appropriately.
 (The event handling was the main issue why you couldn't do something
like a GtkButton in a 

Re: GtkTreeView Refactoring Considerations [was Re: Private types inside GTK+]

[Kristian Rietveld]

On Sep 23, 2010, at 10:56 AM, Tristan Van Berkom wrote:
 So to help stay on track without straying too too much, these
 are (my perceived) reasons for the said refactoring work:
 
  - Code sharing: A good refactoring of cell layouting logic 
into some classes that can be (more) easily reused by the 
major candidates GtkTreeView, GtkIconView and GtkComboBox[Menu]. 
 
  - Adaptation for height-for-width support (currently only
the GtkComboBox uses hfw'ness of cell renderers, big patch
pending on treeviews could be better written based on the
refactored code).
 
  - Alignment of GtkComboBox menu renderers currently cant be
done as described in bug 629133.
 
  - While we're on the topic of refactoring the cell layouting
code, I'd personally like to open up new avenues for rendering
cell layouts in more dynamic ways (as I'll describe in more 
detail below); Rationale for this is if we're going to give this
a go at all, we better be ambitious and awesome about it.

Layouting cells in more dynamic ways is one reason; for me another big reason 
is to also make column/row layouting (thus the layouting of cell layouts ;) 
more flexible.  Think of:

 - Making it easier to create widgets such as icon view, Windows-style 
columnary list view, etc.  Basically, you only want to write the algorithm 
laying out the rows and re-use the algorithms that layout cells.

 - For list and tree views, make row and column spanning possible.

 - Proper implementations of separator rows, group headings or other custom 
content.  (More on that below).

 - Possibly embedding non-cell content in list/tree views, such as custom 
widgets.  Most notably, for example a button (see mobile platforms).


 GtkCellArea
 ---
   A GtkCellArea would be an abstract class which implements 
 GtkCellLayout and acts as a collection of cells which are rendered 
 in a completely undefined way, GtkCellArea classes would be responsible 
 for handling all geometric tasks in the laying out of cells:
 
  - Allocation of cell positions inside the area 
 
  - Returning overall bounderies that the cells take up inside an
area as well as returning the bountries of a single cell inside
the area.
 
This is important for widgets like TreeView and IconView
who want to draw focus around a cell, a column or an entire row.
 
  - Returning the cell at a specified coordinate inside the area for
a given treemodel row.
 
This is needed for the sake of handling mouse-clicks so that the 
owner of the CellArea can go on to start editing a given cell, or
activate an icon in a given cell.
 
  - Responding to height-for-width/width-for-height apis for a 
collection of cells for a given treemodel row.
 
  - Actually render the GtkCellArea for a given row into a given 
space/GdkRectangle.
 
 Conceptually, the GtkCellArea is for a cell renderer what a 
 GtkContainer is for a GtkWidget. The main bonus of keeping the 
 GtkCellArea as an abstract class and responding to some generalized 
 apis is it opens up avenues for more complex implementations such as 
 a tabular CellArea, or a cell-wrapping CellArea which could be more 
 easily implemented in the future.

At first, I thought this would be an entity for rendering one row, so one set 
of cells (basically, what cell view does currently).  But I think you mean to 
have GtkCellArea manage multiple rows?  I leave whether or not GtkCellArea 
should manage one or more rows in the middle below.

An object that handles cell layout for a single row is what I kind of ended 
up with in a previous refactoring.  This was not really an object, as it was a 
set of internal functions.  What I did was refactoring the cell layouting code 
in gtktreeviewcolumn.c into a manageable set of functions that implemented an 
iteratable interface over a list of cells.  Turning something like this into a 
stand-alone class (and enable subclassing) sounds like a good idea to me.

One of my original ideas was to introduce the concept of a row renderer.  
This would be an abstract class with several subclasses.  One row renderer 
subclass for rendering a row consisting out of cell renderers, re-using the 
original cell layouting code.  Other row renderers for embedding widgets, 
separators, group headings, etc.  Layouting row renderers would then give you 
your full-featured tree view, icon view, etc.  (Though combining an icon view 
and a group heading row renderer would mean combining tabular and list layout 
-- another puzzle to solve but an interesting feature).

To go back to the proposed GtkCellArea:

 - I am not yet sure if this should be tied to GtkTreeModel.  The main 
consideration is if you want to use GtkCellArea without a GtkTreeModel.  Though 
it seems cumbersome to provide some other means to populate the properties of 
the cell renderers in this case ...

  Another consideration is whether GtkCellArea will manage one or multiple 
rows.  If only one, then you 

Re: Private types inside GTK+

[Kristian Rietveld]

(Tristan, I will be replying to your main e-mail as soon as possible.  As you 
might understand I need some more time for that :)).

On Sep 23, 2010, at 4:22 PM, Enrico Weigelt wrote:
 * Tristan Van Berkom trista...@openismus.com schrieb:
 
 Hi,
 
 big_snip /
 
 Just an naive half-OT question in the middle: are these widgets
 already capable of retrieving data on-demand, so information not
 yet visible (eg. a subtree in some filesystem view is collapsed)
 can be loaded when needed (eg. the subtree is actally opened) ?
 
 If not, this should be considered on refactoring :)

Such constructions are already possible in some cases by writing your own 
model.  There are some things in tree view that could be done to support this 
in an even better way, or even provide a default model that will handle the 
majority of on-demand loading.  Another related topic would be lazy loading, 
which would be about handling very large models (in the millions of rows) 
efficiently and also doing on-demand loading for that.  I regard both of these 
as another refactoring that would happen separately from what is being proposed 
right now (which focusses more on layouting and rendering).


regards,

-kris.

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

Re: rendering-cleanup Part 2

[Kristian Rietveld]

On Aug 29, 2010, at 9:02 PM, Benjamin Otte wrote:
 That's about it. Comments?

This morning I did an attempt to build rendering-cleanup (so not 
rendering-cleanup-next yet, I am a bit behind ...).  I have pushed fixes that 
make the thing build to completion.  Right now any test/demo crashes on start 
up, I have a fix for that to avoid the crash, but that results in fully white 
windows.  It looks like the initial expose is missing.  (Yes I have upgraded to 
cairo 1.10 :) ).  I will investigate some more later this week.


regards,

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

Re: Private types inside GTK+

[Kristian Rietveld]

Hi,

On Sep 9, 2010, at 11:28 AM, Tristan Van Berkom wrote:
 Hi,
   With all the GSEAL()ing of the whole GTK+ api we get 
 to privatize alot of things which leaves us alot more leeway
 in how we can change things under the hood in the future.
 
 However, what we have to play with is still a matter of
 basic C code implementation details and not much in 
 the sense of OOP code... so I wonder if we can make
 a mechanism at the build level to privatize entire
 object types to be used solely as delegate objects
 of widgets that are a part of the API.

I see where you are going.  I think that often such objects could make sense as 
public API.  But I guess you also want to avoid making these objects public too 
soon, since that will decrease the amount of leeway again.

 I had this idea while pondering:
   https://bugzilla.gnome.org/show_bug.cgi?id=629133

Please allow me to comment in some more detail on this exact issue.

   b.) Add some magick/logic to GtkCellView where cellviews
   can be associated with a group of cellviews and
   then align them with all the cellview's siblings.
 
   While this option seems more sound at first sight
   in terms of code readability and all, it also introduces
   some iterative overhead as each cell would have to 
   consult the size requests of every cell in each cellview
   sibling... the the allocation of each cellview in the list.
 
   (not to mention it would have to make the assumption that
   every sibling has the same type of cell renderer packed
   in the same order... and that each cell view is set to
   render a row from the same model... a kind of ugly assumption
   that you really dont want to make).

I agree, this will turn out ugly :)

   c.) What seems to me as the Right Thing to do here is to create
   a derived GtkMenu; GtkComboBoxMenu that would be responsible 
   for taking into account the width of each cell on each row
   and then effecting an allocation for every cellview in the
   menu in a single pass.

If possible, I would even get rid of the separate cell views in this case.  
Could a GtkComboBoxMenu just render itself using a set of cell renderers 
without needing instances of GtkCellView.  Though this might show troublesome 
in combination with supporting the separate menu items ...

 Vaguely, for bug 629133 my plan could be:
 
   - Privatize GtkCellView unless there are some objections (or at least
 early deprecation in 3.0 cycle). 
 
 CellView is really only an implementation detail of GtkComboBox
 and thus adds some cruft to the api that we really dont need
 (unless some applications love the cellview and then justify
 its existence and our maintenance of it).

GtkCellView has been around for some time, so it might have seen some usage.  
We would have to investigate this.  At least, I would really deprecate early in 
3.0 and not before ...

   - Create a private type GtkComboBoxMenu which could be responsible
 for allocating the private cellviews in a combo box's dropdown menu
 properly and in a single pass.
 
   - Work on refactoring GtkTreeViewColumn so that it stands alone
 and apart from GtkTreeView (somewhere along side working on
 wordwrapping cell renderers and variable row heights in treeviews).

As I also noted in the bug, I would not make GtkTreeViewColumn a stand-alone 
class, rather, I would work on getting the algorithms that do the cell and 
column layouting in separate classes and then have GtkTreeView, 
GtkTreeViewColumn and GtkComboBoxMenu re-use this.  Note that even though cell 
layouting is done in GtkTreeViewColumn, the column layouting is done in 
GtkTreeView.

I think that these layouting algorithms in separate classes might actually be 
useful public API, to reflect on the comment I made at the start of this e-mail.

There might be more components of GtkTreeView that could be useful to 
refactor into new separate classes, for example the rendering loop, selection 
handling, input event handling etc.  My goal would be to refactor GtkTreeView 
in such a way so that it (the original functionality) can be composed from 
these separate classes.  And also so that GtkIconView (and new kinds of such 
views, Windows-style columnary perhaps?) could also be re-written by a 
composition of these classes.  This will reduce the amount of code that is 
duplicated between GtkTreeView and GtkIconView, and in this case you can also 
add GtkComboBox and GtkCellView to that list.  Furthermore, the road for 
creating variations of these view widgets with more flexible and special 
layouting has then been opened.

   - Integrate GtkTreeViewColumn as a delegate of the private
 GtkComboBoxMenu which would be used to render rows into
 the allocated menu item space.

So instead of using GtkTreeViewColumn as a delegate, GtkComboBoxMenu would 
re-use the layouting algorithms and perhaps the rendering loop which are now in 
shared 

Re: rendering-cleanup-next

[Kristian Rietveld]

On Sep 13, 2010, at 6:54 AM, Havoc Pennington wrote:
 On Mon, Sep 13, 2010 at 12:05 AM, John Ralls jra...@ceridwen.us wrote:
 Could also  make it a gdk_x11 api.
 But maybe a hint that is a no-op on other backends is better.
 
 I'm in favor of keeping platform-specific stuff in platform-specific files 
 and directories, but that's in large part just because I'm a bit compulsive 
 when it comes to code organization.
 
 
 Making it gdk_x11 doesn't keep the platform-specific in
 platform-specific files. It would make all files touched by
 d3802ca8331ab09fe752407577b12d1525b5d89e now include gdkx.h and an
 #ifdef'd call to the gdk_x11 API. So textview, layout, treeview,
 viewport would all now have x11-specific code.
 
 The API need not be X specific, though the details depend on how
 Windows and Mac work and I don't know them.

I got a bit lost whether we are still going to add this API or not :)  But for 
what it's worth, as far as I can see now, this API is fine from an OS X point 
of view.  Especially with the two conditionals at the end of the function 
description there is likely enough room to do what is best suited for a given 
platform or to emulate the pieces that are required.


-kris.

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

Re: GTK+ policy (was RE:rendering-cleanup-next)

[Kristian Rietveld]

On Sep 14, 2010, at 3:48 AM, Paul Davis wrote:
 On Mon, Sep 13, 2010 at 6:27 PM, Matthias Clasen
 matthias.cla...@gmail.com wrote:
 2010/9/13 Thomas Wood t...@gnome.org:
 
 Clutter's (very detailed) coding style document may be useful here,
 since it has a very similar coding style to GTK+:
 
 http://git.clutter-project.org/clutter/tree/doc/CODING_STYLE
 
 
 Yes, I think we could basically adopt this word-by-word.
 
 i know that coding styles are, as it says in the clutter guide,
 arbitrary, but i would just like to mention one little detail that i
 find problematic when working on shared projects (and much less so on
 non-shared projects). this rule:
 
 --
 Curly braces should not be used for single statement blocks:
 
  if (condition)
single_statement ();
  else
another_single_statement (arg1);
 ---

To add to this, it does not specify how to deal with braces in nested 
if-statements.  When I start to nest if-statements (also with a 
single-statement body) I typically start adding braces, because it is a bit 
clearer and avoids the dangling else problem.


regards,

-kris.

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

Re: Questions about GTK3

[Kristian Rietveld]

Hi Benjamin,

Great that you bring this up for discussion.

I think another trade-off you want to make in this discussion is what
amount of backwards compatibility you want to have with GTK 2.x.  In
the original GTK+ 3 plans a few years ago it was argued to have a very
smooth migration path by limiting API removal to deprecated API so
that existing applications can be very easily ported.  (With an
exception for theming, since people really wanted to see that fixed).
There are obviously arguments in favor of this (easy porting), but
also against, typically: if you want to break ABI, then make a good
use of it.

The plans have seen changes and discussion and I cannot immediately
recall what has been decided in the end.  I think that the additional
clean up that is going on around GdkGC (which has been long
deprecated) is great, that this is requiring some adaptations in
non-deprecated code is something that we have to take for granted.  I
am pretty much in favor of all other rendering clean up that is being
proposed (especially as an OS X backend hacker :), since it makes the
GDK/GTK+ code base significantly easier and I think more flexible as
well.  However, each further modification that we make, will come at a
cost of making applications impacted by that harder to port.  Even
though GTK+ 2.x will not go away, it is likely in best interest of
both GTK+ developers and the application developers to have
applications make the switch to GTK+ 3 better the sooner than the
later.

So basically I am arguing that we should proceed with caution for
larger scale changes of things that currently are not deprecated, and
really think about the impact in extra work involved in porting
applications.  I am afraid that changes like removing HV classes (even
though it would be great to clean up!), removing window widgets, etc.,
will make it much more complex and time consuming to port applications
while application developers are currently not anticipating that.
Either way, if we are to make such changes, we better make it known
ASAP.

Some more comments below:

On Sat, Sep 4, 2010 at 10:56 AM, Benjamin Otte o...@gnome.org wrote:
 - Same for GtkHFoo/GkVFoo classes. They're absolutely useless now that
 we got GtkOrientable, but removing them breaks API. Do we just remove
 them? Do we only keep the functions from it that are actually used? Do
 we deprecate but keep the functions? Or do we even keep the classes?

Like I mentioned above, I think as a clean up it would be great, but
it comes at a massive cost for porting applications (unless that can
be automated somehow, but that might not always be wished).  IIRC
there have been discussions about this earlier on this mailing list.

 3) Cleanup of useless classes
 With the removal of the deprecated widgets, we now have objects in the
 widget hierarchy that make no real sense anymore (i.e. GtkItem or
 GtkEditable). Should they be removed? Should they be kept? Is anyone
 working on that or intending to?

I am wondering about the case if such a class is in the middle of a
class hierarchy (e.g. GtkMisc).  What amount of breakage would that
introduce?  Or would things continue to compile more or less fine?

 4) How to treat workarounds?
 Example: 
 http://git.gnome.org/browse/gtk+/tree/gtk/gtkentry.c?id=e6da33a302a51783777e8da41c680cdf4dc783eb#n3292
 There's sections of code that say 'work around problem foo in barapp
 and then do something very weird. We could just remove these and end
 up with clean code, but would make barapp harder to port to GTK3. Or
 we could keep weird behavior. Do we have any preferences here?

Hard one.  Fixing up such things can trigger really obscure bugs in
applications.  From what I remember, I have a couple of functions or
cases in tree view where I would also want to change behavior.  But
also such changes can trigger completely different behavior in certain
applications, which is why such changes were for me usually a big
no-no in 2.x.

If we decide to fix such cases (which might not be a bad idea when
breaking ABI, I don't know what would be a better moment to make such
changes), we should make sure to have detailed documentation on each
of these changes.

 5) How proactive are we?
 In the rendeirng-cleanup work we've talked about switching widgets to
 a no-window drawing model. Unfortunately, some APIs are not very
 helpful for that approach (i.e. GtkEntry leaking windows via
 gtk_entry_get_icon_window ()). Should we look at cleaning this up
 before 3.0? Or do we wait until we actually want to remove windows?
 I'm sure there's similar problems for other efforts. How are things
 handled there?

I think this again really depends on how much you want to get out of
the current ABI break, and whether there are plans to break ABI more
frequently in the future.  The original GTK+ 3 plans called for ABI
breaks at certain intervals (which again has arguments in favor and
against).  With that you could envision a model of operation of
deprecating the 

Re: (Style) Property review

[Kristian Rietveld]

Hi Matthias,

On Sun, Aug 29, 2010 at 5:16 AM, Matthias Clasen
matthias.cla...@gmail.com wrote:
 5) We have an indicator-size property in GtkCellRendererToggle , but
 indicator-size style-property in GtkCheckButton and GtkCheckMenuItem.
 This was unavoidable, since cell renderers are not widgets and can't
 have style properties. Maybe the style-context work will let us fix
 that.

Oh yes, if style-context makes such things possible, that would be great.


 'opt-in' style properties: These were added over time to let themes
 opt-in to some new GTK feature, typically more detailed detail
 strings.

 6) GtkEntry::state-hint
    GtkTreeView::row-ending-details

row-ending-details is indeed a property that enables richer detail
strings.  I think if we hadn't done it this way, themes would have
broken.  What's the exact plan with such properties?  The properties
are removed and themes will be expected to update to handle the
different and richer detail strings?


regards,

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

Re: Gtk-OSX (was: Website proposal for usability)

[Kristian Rietveld]

On Fri, Aug 27, 2010 at 6:35 AM, John Ralls jra...@ceridwen.us wrote:
 I don't know how many people share these views, but if I'm not
 totally out on a limb I would be willing to draft a page along the
 lines I'm talking about (recruiting help from those who are more
 knowledgeable). I'd also be willing to try making a runtime
 package if I can get some time on OS X -- though I suspect others
 are better qualified than I for that job. The R guys have
 some packages at http://r.research.att.com/libs/ and maybe one
 of them would be willing to do an official build.

For a GTK+ runtime package (GTK+ Framework), I think you should
check out what has been done in the past.  It is by no means an easy
task.  The latest code and instructions for this are at the GTK-OSX
website if I am not mistaken.

 You might not like the warnings about the quality of Gtk+ Quartz, but when I 
 wrote them a year ago, no one had touched the quartz backend for 8 months. 
 Since then, one developer (Kristian Reitveld) has fixed many of the 
 outstanding bugs, and some of the other Gtk devs have become a lot more 
 receptive to minor patches... but the general attitude remains that it's OK 
 to implement (or rewrite) features in Linux, and if it breaks Win32 and 
 Quartz, oh well. There's a list of features that aren't yet implemented, or 
 aren't implemented completely, at http://live.gnome.org/GTK%2B/OSX/.

I would say the quality has been slowly increasing, though there's
enough left to do.  I do try to track the latest developments in GTK+
master and adapt the Quartz backend wherever necessary so it does not
break.  This is also pretty time consuming, but did result in a Quartz
backend that continued to work when the XI2 and rendering-cleanup
branches where merged into the master branch.  There's some more
backend work planned I think, that will hopefully affect the Quartz
backend to a lesser extent.  In the meantime I will continue with
reviewing patches/implementing missing features to end up with a
feature-complete backend some day :)


regards,

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

Re: Hardware accelerated 2D graphics (with gtk-osx)

[Kristian Rietveld]

On Aug 9, 2010, at 1:39 PM, John Emmas wrote:
 I'm using a Mac Mini with OS-X 10.6.3.  Graphics are provided by the onboard 
 NVidia chip which is a GeForce 9400.

That's certainly pretty recent.

 This particular app is the only GTK application that I've ever run on my Mac. 
  It's an application called Mixbus which is derived from Ardour, the popular 
 open-source DAW for linux.  Mixbus is developed by an American company called 
 Harrison Inc.  I do know that they use a variety of different Macs for 
 testing but they're all displaying the same problem.


 Having said that, I might ask if they can test it on the PPC platform to see 
 if that makes a difference.  Just out ot interest, Kristian - is your Mac 
 laptop a MacBook or a PowerBook? And what graphics chipset is it using?

I have a MacBook Pro here and I use the GeForce 9400M (it also has a 9600M GT 
which I don't use).  That's pretty much the same as yours, so you would say the 
hardware/driver cannot be the issue.  I also occasionally test stuff on an 
older MacBook with Intel graphics running Tiger, with good performance.

It would be interesting to know whether I can reproduce the problem on my 
machine here.  If so, then I can also look into debugging it.  Is the 
application available somewhere?  Or is there a stand-alone test case that 
shows the same behavior (that would be even better)?


regards,

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

Re: Hardware accelerated 2D graphics (with gtk-osx)

[Kristian Rietveld]

On Aug 8, 2010, at 9:32 PM, John Emmas wrote:
 On 1 Aug 2010, at 21:49, Kristian Rietveld wrote:
 
 
 GTK+ OSX does all drawing using CoreGraphics, this should be 
 hardware-accelerated whenever possible.
 
 
 From what I've been able to tell, CoreGraphics eventually ends up using 
 QuartzGL for 2D imaging and acceleration.  QuartzGL however seems to be 
 buggy, unfinished and badly written.  On my system (and I suspect most other 
 Macs) enabling hardware acceleration for QuartzGL actually worsens 2D 
 graphics performance rather than enhancing it.

What hardware and OS revision are you using?  Do you experience this just in 
your canvas or in other GTK+ applications as well?  I am wondering if there's a 
certain code path that is badly optimized?

The slowness you are observing is interesting, since the graphics performance 
of GTK+-OSX on my Mac laptop is faster than the performance of GTK+-X11 on my 
(faster) Linux desktop.

 So another option might be to use gtk-x11 in the Mac build, instead of 
 gtk-osx.  Obviously this would require an X server to be installed but I 
 don't think that's too difficult on a Mac.  The question is whether or not X 
 (under OS-X) also uses QuartzGL or whether it interfaces with Quartz 
 Compositor directly (or via some alternative technology, such as OpenGL).  
 I'm assuming there must be an interface to Quartz Compositor at some stage.

Mac OS X actually ships with an X11 server (X11.app), you can install it from 
the extra components on the Mac OS X installation DVD.

 Anyone know where I could find out some more information about X server for 
 OS-X?

I guess this will be of interest:  http://xquartz.macosforge.org/trac/wiki


regards,

-kris.

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

Re: Hardware accelerated 2D graphics (with gtk-osx)

[Kristian Rietveld]

On Jul 28, 2010, at 9:15 AM, John Emmas wrote:

 This morning I've come across this mailing list which has got me confused:-
 
 http://sourceforge.net/mailarchive/forum.php?forum_name=gtk-osx-users

My understanding is that this mailing list is for discussion of gtk+ on osx as 
well as certain subprojects such as global menu bar support, GTK+ framework 
packaging, etc.

 Up until now I'd assumed that gtk-osx was produced / administered by 
 gnome.org but the above mailing list makes it look like it's possibly an 
 independent project.  Should I have posted my question there instead of here? 
  Or are there two different gtk-osx projects?

The most up to date GTK+ OSX backend is in GNOME git, bugs are tracked on 
bugzilla.gnome.org.


regards,

-kris.

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

Re: Hardware accelerated 2D graphics (with gtk-osx)

[Kristian Rietveld]

On Jul 27, 2010, at 10:49 AM, John Emmas wrote:
 Under Windows and Linux the (2D) scrolling display is smooth.  But under OS-X 
 it's horribly jerky and has a very 'klunky' look to it.  I happen to be 
 viewing it on a Mac Mini but other people have seen the same effect with more 
 powerful machines.  It isn't a processor issue because even with my lowly Mac 
 Mini, the cpu usage rarely gets higher than about 30 percent.

On my Macs the GTK+ graphics rendering is pretty fast.  There might have been 
issues in the past, but recent GTK+ releases should be pretty good.

That said, some people do see performance issues that cannot be reproduced on 
other machines, for example https://bugzilla.gnome.org/show_bug.cgi?id=615917.  
What exactly is causing this and whether this is hardware-specific still has to 
be found out.  We need to collect GTK+ version in use and hardware details in 
these cases.

 My guess is either that gtk-osx isn't using any technology that's compatible 
 with Quartz Compositor - or if it is, it's maybe using QuartzGL.  
 Disappointingly, QuartzGL DISABLES 2D hardware acceleration by default and 
 I'm wondering if this might explain the poor performance that we observe 
 under OS-X?  As I said earlier, Windows and Linux are both fine.

GTK+ OSX does all drawing using CoreGraphics, this should be 
hardware-accelerated whenever possible.


regards,

-kris.

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

Re: rendering-cleanup

[Kristian Rietveld]

On Jul 22, 2010, at 4:54 AM, Benjamin Otte wrote:
 The work is done and the code runs now. Well, at least testgtk and
 gtk3-demo do. On X11. I'd be happy if others could take it for a spin
 and find issues with it or even have a go at Quartz and Win32 code.

I pushed two patches that will make the Quartz backend compile again and fix 
the implementation of the new window_translate method.  There are still some 
issues with widgets that do expose but the results do not become visible on the 
screen (not related to the window_translate method).  I have not yet managed to 
put my finger on the exact issue, so I need to spend some more time debugging 
this (during GUADEC is the plan ;).  Perhaps this is a clipping issue 
somewhere, not sure.

So, to be continued.

regards,

-kris.

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

Re: rendering-cleanup

[Kristian Rietveld]

On Jul 22, 2010, at 4:54 AM, Benjamin Otte wrote:
 The work is done and the code runs now. Well, at least testgtk and
 gtk3-demo do. On X11. I'd be happy if others could take it for a spin
 and find issues with it or even have a go at Quartz and Win32 code.

The Quartz backend will need some patching to get it to compile again.  This 
seems to mainly involve ripping out the code that implements the things that 
have been removed now.  Now that removing all this old crap from the backend 
sounds like a lot of fun, I will try to have a go at this tonight or tomorrow :)

I can commit the patches to your branch when I am done, if that is fine with 
you.


regards,

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

Re: Height for width treeviews

[Kristian Rietveld]

On Jul 2, 2010, at 7:29 PM, Tristan Van Berkom wrote:
 * Toying with your 'wrapping treeview' demo, and making it as narrow
 as possible, I notice 'demonstrate' overlaps with the icon next cell.
 Shouldn't that line have determined the minimum width of that cell,
 preventing it from shrinking any further ?
 
 I'll look further into this, its probable that I introduced
 a minor bug in spacing/padding calculations.
 
 Some refactoring around those allocations was needed here because the
 column-width used to be padding/spacing inclusive (which does not make sense 
 if
 the column needs to use its width to position its renderers).

I rather not include this refactoring together with the native-layout changes 
if possible and thus first merge only the required native-layout changes and 
then look at further issues.

 * Looking at the list store example in gtk-demo, and sorting by
 clicking on the headers, there is an off-by-a-few-pixels delta
 between the header and the sort column background. The delta grows as
 you sort by columns further right, so I think this may be some missing
 per-column padding, or something.
 
 Probably also related to afore mentioned refactor... I'll look into
 that (these spacing bugs should at least be easy to fix compared
 to scrolled window).

Getting the spacing/padding/etc bugs figured out is harder than you think and 
that's why I would prefer to merge without these refactorings.


 * Using tests/testtreecolumns, and adding 2 columns to one of the
 windows, the column resizing is wonky. If I start dragging the
 separator, I have to go almost all the way to the right, then the
 column jumps. Once it jumped, it follows the pointer further to the
 right, but if I move too far left, it jumps back.
 
 
 Ok I had not viewed those effects, fixing that will be a matter
 of tracing the ever-so-stateful treeview structures during drag
 resize operations under different configurations, I'll get on that
 next chance I get.

You broke column resizing that we carefully fixed two years ago ;)  See the 
review mail I sent you earlier this evening.


In summary, let's focus on writing a patch to support native-layout in tree 
view that does as little changes as possible and fix the other issues 
separately at a later point in time.


regards,

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

Re: Minutes of the GTK+ team IRC meeting - 2010-06-22

[Kristian Rietveld]

On Jun 23, 2010, at 12:29 AM, Emmanuele Bassi wrote:
 • Potential API changes for better introspection/bindings. See Bug #621590
 - walters was asking for bending the rule of minimal compilation
 - case in point: gtk_tree_path_get_indices() is missing a length out parameter
 - pro: would make the life of introspection/bindings easier
 - con: would make porting harder
 - possible solution: add a new function, gtk_tree_path_to_indices()

I think this case has been taken care of already?  See #616990.


regards,

-kris.

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

Re: [Quartz] Gtk Selection

[Kristian Rietveld]

On Jun 8, 2010, at 5:42 PM, John Ralls wrote:
 It's too early for requirements. First we need to figure out what to 
 abstract, and whether each abstraction really belongs in Gdk or should be 
 moved up to Gtk (like clipboards) or down to Glib (like string 
 conversions). Wikis are like whiteboards: They're a useful aid to a 
 discussion but not a vehicle for the discussion itself. 
 
 So if you want to start a wiki page, maybe you start a list of what Gdk 
 abstracts, and we can discuss here where (i.e., GLib, Gdk, Gtk, or somewhere 
 else, including Cairo and Pango) each of those abstractions belong. We could 
 also consider whether there are abstractions in other libraries which would 
 fit more naturally into Gdk.

This is actually more or less what I meant.  Listing what GDK abstracts and 
start drafting how this may be improved.  I think requirements was the wrong 
choice of words on my side :)


regards,

-kris.

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

Re: [Quartz] Gtk Selection

[Kristian Rietveld]

On May 24, 2010, at 3:15 PM, Paul Davis wrote:
 On Mon, May 24, 2010 at 1:21 AM, John Ralls jra...@ceridwen.us wrote:
 
 
 The structure of that part of Gdk follows very closely the X11 way of doing 
 things, and Cocoa Foundation's way of handling selections and clipboards 
 (which they call pasteboards) doesn't line up very well with it. It seems to 
 me that it might work better to just make a gtkselection-quartz.c and 
 implement everything directly, ignoring Gdk entirely, much as Richard did 
 with gtkclipboard-quartz.c and gtkdnd-quartz.c.

John, it's really great that you are having a go at getting the selection code 
working.  If Richard has been bypassing GDK in the clipboard and DnD 
implementations as well (I have not studied that code in detail yet), then I 
guess it makes sense to do the same for selections.


 seems to me that its all about time. ideally, the design of GDK would be 
 modified to be more generic/adaptable, and all backends would continue to use 
 it as an interface. but it seems to me unlikely that this is going to happen 
 in any reasonably timely  way. so if you want this to work (i confess that 
 its not too important for ardour's functionality), i think your proposal is 
 likely right way forward.

I am really in favor of modifying the design of GDK to be more generic, not 
only for selections, but for many more areas: DnD, window management, drawing, 
etc.  Of course, this is a really a long-term goal ...


regards,

-kris.


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

Re: [Quartz] Gtk Selection

[Kristian Rietveld]

On Jun 8, 2010, at 4:02 PM, John Ralls wrote:
 Thanks for the encouragement. It's done, and a patch submitted against 
 https://bugzilla.gnome.org/show_bug.cgi?id=571582.

Ah, I missed that Bugzilla mail.  It was already on my review list.  I am a bit 
overloaded at the moment, also want to review the NSView embedding patch and 
look at the GdkPixmap/GtkImage bug.  I will do my best to get to it soon.

 Yes, I understand that redesigning Gdk would be a long term goal. Have there 
 been any discussions about what the architecture would look like on IRC? I 
 sure haven't seen any here...

Not that I know of.  Would it be interesting to start drafting requirements 
for this in the Wiki?


regards,

-kris.

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

Re: Looking to pay someone to improve gtk+ on osx.

[Kristian Rietveld]

On Sun, Jun 6, 2010 at 11:47 AM, Paul Davis p...@linuxaudiosystems.com wrote:
 the only problem we see at present may be the same as the focus issue
 you mention: menus and occasionally buttons that do not get mouse
 focus when displayed. I can't guarantee that the fix will come from

Is there a way to trigger this reliably?


regards,

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

Re: Looking to pay someone to improve gtk+ on osx.

[Kristian Rietveld]

On Jun 4, 2010, at 3:27 PM, Lucas Meijer wrote:
 My company (Unity3d.com) cares about getting MonoDevelop to run great on osx.
 
 MonoDevelop uses gtk+, which on osx has a whole array of problems, especially 
 on multi monitor setups.

Have you tried a recent version of GTK+?  Last December, a great deal of issues 
with multi monitor setups have been fixed.



regards,

-kris.

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

Re: Minutes of the gtk+ team IRC meeting - 2010-05-25

[Kristian Rietveld]

On May 31, 2010, at 12:37 PM, Emmanuele Bassi wrote:
 well, since I am the proposer of the removal:
 
  • TearoffMenuItem does complicate the Menu code - with the contents
 being copied inside a new GtkWindow, and the window mangled to appear as
 a menu but managed by the window manager.

Yes, there's a bunch of hooks in the gtkmenu.c needed for this to work properly 
as far as I know.

  • the user interaction context of having a menu floating around as a
 tool box is a clear indication of a problem in the overall user
 interaction design. I can probably ask designers to chime in here, if I
 can get them stop laughing about it.

Agreed; also one would wonder why not to use keyboard shortcuts instead.

  • and even if we remove GtkTearoffMenuItem and the tear-off support in
 gtk+, those aren't *really* gone. gtk+ 2.* will still have them, and it
 should be possible to implement a TearoffMenuItem outside of gtk+. if
 it's not possible, we should expose the API to do so.

This is the main point really -- I would say that when the main code empowering 
the tear off menus that's in gtkmenu.c is removed, then there's likely to be no 
(easy/proper) way to get this implemented outside of GTK+ for people that 
really cannot live without this in their applications. So it would be good to 
expose the API to do so as you suggested and leave any code in that's required 
for implementing that API. But then, in the end, doesn't the most 
complex/tricky code stay in GTK+ anyway?


regards,

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

Re: client side windows borkage on Gdk/Quartz

[Kristian Rietveld]

On Sun, Apr 25, 2010 at 5:53 AM, Paul Davis p...@linuxaudiosystems.com wrote:
 I have to do bit more investigation (e.g. ripping out code and adding the
 old approach back), but I'd appreciate it if either Richard or whoever may
 have worked with him on this issue could comment. Does my description make
 sense, and is it sensible that forgetting that Quartz was already recursing
 over children could have led to this?

DISCLAIMER: I was not involved in the initial port of the Quartz
backend to the client side window code.

Below my view on the issue, based on my understanding of things.

 So far, so good. What's the problem? Well, the Cocoa code that we use is a
 call to displayIfNeeded on the top level NSView in the NSWindow. This does
 a recursive descent over all the NSViews it contains, checking whether or
 not they need to be updated, and if so, calling their drawRect methods.

As far as I understand, there's only that top level NSView in GDK
applications now in the case of client side windows, that does not
contain any other NSViews.  So for each NSWindow there will only be a
single NSView for which the drawRect: method will be called.

 What does drawRect do? Well, a bit of housekeeping, and then it calls
 _gdk_window_process_updates_recurse(). Still no obvious problem. Except wait
 a second ... this takes the GdkWindow associated with the NSView, and does
 ... you guessed it ... recursive descent over all GdkWindows it has a
 children, generating exposes for each one. So what? well, the GdkWindow
 associated with the NSView is the GdkWindow corresponding to the top level
 window! Every single drawRect of an NSView causes a recursive descent
 across the entire GdkWindow heirarchy of the top level window!! Arrgh!
 Yikes!

That is because the NSView will be the content view, so it corresponds
to the toplevel GdkWindow.  Again note that drawRect will only be
called once per NSWindow (since there is only one NSView per
NSWindow).

The call to _gdk_window_process_updates_recurse()  in the drawRect
method was added in this commit:

commit 65b5644cda073928f6f9005db3e4bb27c589c165
Author: Richard Hult rich...@imendio.com
Date:   Mon Jan 26 20:29:51 2009 +0100

Call _gdk_window_process_updates_recurse() in drawRect instead of
creating our own expose events


Likely a required change because in the past an NSView mapped to each
GdkWindow, which is no longer the case.  The drawRect of the NSView of
a GdkWindow has to take into account all GdkWindows that are
contained.

 In Ardour, this means that we spend up to 0.5 seconds in a the idle redraw
 callback every time we need to redraw an NSView...

If this function really takes that much time, we need to start
thinking of a smart solution here.  Richard has also mentioned to me
the possibility that the update handling could be very slow in cases
with many subwindows and thus would need a re-visit.


 In older GDK/GTK code, the Quartz backend generated an expose for the
 GdkWindow corresponding precisely to the NSView, but apparently after the
 introduction.of client side windows, somebody decided that the relationship
 between GdkWindows and NSViews as represented by the existing Quartz backend
 was wrong, and that when drawRect was called for *this* NSView, we still had
 to do a recursive descent through all child GdkWindows of the affected
 GdkWindow. This ignores the fact that Quartz is already doing this for us.

How I understand things, the goal of the client side windows work was
to generate and manage most windows client side, that means no
native window for that will be created.  For the Quartz backend that
meant that no NSView would be created any more for each GdkWindow;
since the NSView mimicked the native window in this setup.

So yes, we have to do a recursive descent through child GdkWindows of
the affected GdkWindow, since these do not all have NSViews coupled to
them.  In this case, Quartz is not already doing that for us, since
there were no NSViews created for these.


Hope this helps.

regards,

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

Re: client side windows borkage on Gdk/Quartz

[Kristian Rietveld]

On Sun, Apr 25, 2010 at 5:23 PM, Paul Davis p...@linuxaudiosystems.com wrote:
 On Sun, Apr 25, 2010 at 5:37 AM, Kristian Rietveld k...@gtk.org wrote:
 As far as I understand, there's only that top level NSView in GDK
 applications now in the case of client side windows, that does not
 contain any other NSViews.  So for each NSWindow there will only be a
 single NSView for which the drawRect: method will be called.

 Looking at the code, I don't see this at all. Every creation of a GdkWindow
 is accompanied by the creation of a GdkQuartzView which inherits from
 NSView. This view is added to the parent view. So, I don't think that its
 the case that the client-side windows work has really propagated into the
 quartz backend at all. Thus, we have both heirarchies still inplace. I

The distinction between creating a client side or native window is
*not* made in _gdk_window_impl_new() in gdkwindow-quartz.c; this
function is called to create native windows for Quartz and thus always
creates a GdkQuartzView.  You want to look at gdk_window_new() in
gdkwindow.c as well and you will see that _gdk_window_impl_new() is
only called if native == TRUE.

Before I sent out my reply this morning, I had empirically verified
that only a single GdkQuartzView is created per NSWindow.  ObjectAlloc
agreed with me as well.

 therefore think, from a code reading at least, that this claim:

 That is because the NSView will be the content view, so it corresponds
 to the toplevel GdkWindow.  Again note that drawRect will only be
 called once per NSWindow (since there is only one NSView per
 NSWindow).

 is false.

So this claim has not been proved false.


regards,

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

Re: Minutes of the GTK+ Team Meeting - 2010-03-23

[Kristian Rietveld]

On Sat, Apr 10, 2010 at 7:00 AM, Matthias Clasen
matthias.cla...@gmail.com wrote:
 I have also started to look at the xi2 work of Carlos and got a very
 positive first impression. One thing I am a bit worried about is that
 we don't want to let our other backends fall further behind. I hear
 that Kris has patches implementing the new Device framework for the
 Quartz backend, but we need to at least have 0-level dummy
 implementation for the directfb and win32 backends.

That's correct, I have patches that port the Quartz backend to these
new Xi2 interfaces.  I have sent this patch to Carlos a while back for
some sanity checking.  Depending on at which point in time the xi2
branch will merge with master, we either commit the Quartz patch in
the xi2 branch or in the master branch after the xi2 branch has been
merged.

Be aware that a dummy implementation will not consist of only adding a
number of empty stub functions unfortunately...  I think the patch I
wrote for the Quartz backend can be used as a guide to update the
other backends.


I think what is still important to be done in the Xi2 branch is
figuring out some semantics.  Carlos has done most of this work on a
MPX powered X server where the multiple pointers always exist and are
always query-able.  I have been looking into implementing support for
the multitouch trackpads found on recent Apple laptops into the Quartz
backend with the Xi2 interfaces, but here the semantics are different
(additional pointers only become active when additional fingers are
placed on the trackpad) which caused some trouble.  Most worrisome is
that in this case the applications had to be changed.  If we could
find a way to bring such issues to a more abstract, generic level, so
that the applications don't need changes, I think that would be great.


regards,

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

Re: 2.18.8 coming

[Kristian Rietveld]

Hi Matthias,

On Sat, Mar 13, 2010 at 8:03 PM, Matthias Clasen
matthias.cla...@gmail.com wrote:
 Just wanted to let people know that I am planning to roll a 2.18.8
 release early next week. I've cherry-picked relevant bug-fixes for the
 X11 backend, but if there are fixes for win32, quartz or directfb that
 should go in this, can you (ie owners of these backends) please
 cherry-pick them yourself onto the gtk-2-18 branch ? I'll probably do
 the release Monday afternoon, so you've got the rest of the weekend to
 do it...

Thanks for the heads-up.  I saw you already committed the most
important Quartz patch to get in to a new 2.18 release (the patch for
598881).  I cherry picked two more patches that will help people on
64-bit systems.  I did a test build of the gtk-2-18 branch on my Mac
and it appears to build and run test apps just fine.


regards,

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

Re: GtkTreeView in VBox

[Kristian Rietveld]

On Thu, Jan 7, 2010 at 1:24 PM, Amol Kulkarni amolgkulka...@gmail.com wrote:
 Is it possible to add GtkTreeView inside VBox and then add that VBox to
 ScrolledWindow using gtk_scrolled_window_add_with_viewport(sw,vbox).

 Is this expected/supported use case or am i doing something wrong here?
 Thanks for your time.

No, it's not a supported use case.  GtkTreeView and other scrolling
widgets such as GtkIconView are meant to be placed directly in a
GtkScrolledWindow.  Not doing so will, for example, break scroll
commands given by GtkTreeView itself, since it is not directly
connected to the GtkScrolledWindow anymore.  Such scroll commands are
given when you are setting a cursor on a row and want to make that row
visible, automatic scrolling during drag selection, or by the
application programmer using the gtk_tree_view_scroll_to_cell() and
related functions, etc.

Another reason why this is a bad idea is memory usage, although I
cannot tell for sure whether this still holds for GTK+ 2.18 and later.
 For earlier versions of GTK+ a large X window has to be allocated if
you are placing a GtkTreeView with a large number of rows in a VBox or
similar container.


regards,

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

Re: TreeView: set_fixed_height_mode v TREE_VIEW_COLUMN_FIXED

[Kristian Rietveld]

On Dec 27, 2009, at 11:14 PM, Dr. David Alan Gilbert wrote:
 FIXED does not mean fully fixed; a FIXED column can be set to be resizable 
 by the user of the program.
 
 A solution for the future will be to sample the widths of a set of 
 rows/columns.  This will be an additional mode, as it does not comply with 
 the strict rules for AUTOSIZE/GROW_ONLY.
 
 The other way to look at this is instead of asserting when you find a
 colume that isn't marked fixed, then you just measure those rather than all 
 cells.
 That way you don't need any new modes anywhere as far as the API is concerned.

This is an interesting idea, however to satisfy the current AUTOSIZE/GROW_ONLY 
property we would still have to scan the entire tree and measure those cells.  
It is exactly the scanning of the entire tree for cell measurement (often 
referred to as validation) that the fixed height mode is looking to fully avoid.


 In this case there is a big treeview with a thousand rows or so,
 all the same height but where the width of at least one of the columns
 varies - this doesn't sound an uncommon situation, but is causing
 call backs for ~5000 data functions for every cell in the tree
 on every redraw.
 
 On a redraw, only the data functions for cells that are visible on the 
 screen should be called.  5000 calls to data functions seems unlikely to me.
 
 I'm not sure, but I think the problem is that until you've measured
 all the rows above you, then you can't be sure what it is that's
 currently visible.

I assume that the big tree view in this case does not have fixed height mode 
enabled.  The default behavior is then that there is an initial pass through 
the given model, measuring all cells.  All row heights will be known after that.



regards,

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

Re: TreeView: set_fixed_height_mode v TREE_VIEW_COLUMN_FIXED

[Kristian Rietveld]

On Dec 27, 2009, at 1:48 AM, Dr. David Alan Gilbert wrote:
 COLUMN_FIXED seems to be defined as 'Columns are a fixed numbers of pixels 
 wide.'
 but what has that got to do with height?

The COLUMN_FIXED setting is more about what should happen with the width of the 
column in response to changes in the model.  The main point is that with fixed 
height mode, we speed things up by not measuring the size required for a cell 
and its attributes to draw itself; instead we assume a fixed height.  Because 
we don't measure at all, we also do not measure width.  This renders the 
COLUMN_AUTOSIZE unusable, as well as COLUMN_GROW_ONLY (we would have to measure 
a row as soon as it is added (even when it is not visible), but we don't do 
that).  We are left with the FIXED option.

FIXED does not mean fully fixed; a FIXED column can be set to be resizable by 
the user of the program.

A solution for the future will be to sample the widths of a set of 
rows/columns.  This will be an additional mode, as it does not comply with the 
strict rules for AUTOSIZE/GROW_ONLY.


 In this case there is a big treeview with a thousand rows or so,
 all the same height but where the width of at least one of the columns
 varies - this doesn't sound an uncommon situation, but is causing
 call backs for ~5000 data functions for every cell in the tree
 on every redraw.

On a redraw, only the data functions for cells that are visible on the screen 
should be called.  5000 calls to data functions seems unlikely to me.



regards,

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

Re: Pango CoreText/ATSUI (was:Intricate changes to Quartz/OSX backend)

[Kristian Rietveld]

On Mon, Dec 21, 2009 at 6:48 PM, Paul Davis p...@linuxaudiosystems.com wrote:
 Yea, a configure thing was my plan for supporting Tiger and Leopard.  Good
 to know that you agree with that :)  I will look into fixing up that patch
 this week.

 Did anything ever happen with this?

Coincidentally, I had the time to look into this today (Christmas
holidays :).  I have completely reworked the patch, actually fully
removing the CoreText calls.  This removes the need for a nasty
configure thing and HAVE_CORETEXT macros for now.  Both Tiger and
(Snow) Leopard now use ATS calls in the ATSUI backend.  I have just
pushed the commit to Pango's master branch:

http://git.gnome.org/browse/pango/commit/?id=0f06d7758bc37a4942342d2c17a88944cbc88adb

Of course it is known that ATS has been deprecated in Mac OS Leopard.
Just adding some CoreText calls to the ATSUI backend is not the proper
way to solve this.  (Since all other parts still do deprecated ATS
calls).  In the very near feature, we will have to write a proper
CoreText backend for Pango from scratch.  But for now, usage of ATS
will suffice on all platforms.


regards,

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

Re: subclassing GtkTreeModelFilter

[Kristian Rietveld]

Hi,

On Wed, Dec 9, 2009 at 10:43 AM, Danielle Madeley
danielle.made...@collabora.co.uk wrote:
 Looking for feedback on
 https://bugzilla.gnome.org/show_bug.cgi?id=604150 which includes a patch
 I wrote to make GtkTreeModelFilter more-useful for subclassing.

I am not at all opposed to this idea; seems pretty convenient to me.

Any people with suggestions or objects?  Otherwise I think this can go
into master.


regards,

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

Re: dotted line separating table columns in GTK 2.18

[Kristian Rietveld]

On Wed, Dec 2, 2009 at 10:52 PM, Alex Ignácio da Silva
a...@ignacioalex.com wrote:
 It seems like the recent GTK 2.18 implementation of table widgets draws
 a dotted line separating the table columns, as I noticed when trying my
 application in Ubuntu Karmic. Unfortunately this makes my widget render
 incorrectly. Is there a way to tailor GTK and configure it not to draw
 such lines (perhaps setting a magical environment variable)?

See gtk_tree_view_set_grid_lines().  This is disabled by default, but
for some reason Ubuntu (or the Ubuntu theme, even though the grid
lines setting is not a style property) enables it by default.


regards,

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

Re: dotted line separating table columns in GTK 2.18

[Kristian Rietveld]

On Thu, Dec 3, 2009 at 12:38 AM, Michael Cronenworth m...@cchtml.com wrote:
 It isn't working for me though. Something is missing.

It does not work because enable-grid-lines is not a style property.


regards,

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

Re: dotted line separating table columns in GTK 2.18

[Kristian Rietveld]

On Thu, Dec 3, 2009 at 12:22 AM, Alex Ignácio da Silva
a...@ignacioalex.com wrote:
 Unfortunately from the Java side I have no easy access to the underlying
 GTK implementation widgets, only to the wrapper SWT objects.

 Isn't there a way to change this behavior via an environment variable or
 some other mechanism not involving touching the C code?

Not that I know of, but I don't have knowledge of SWT so I cannot
think of workaround in that area.  I think it is a bit stupid that
Ubuntu turned on these grid lines by default, because it is
deliberately not a theme setting.  We wanted the developers of
applications decide whether or not grid lines should be enabled for a
particular tree view.


regards,

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

Re: GTKTreeView navigation improvement

[Kristian Rietveld]

On Mon, Nov 23, 2009 at 8:18 AM, Andrey M admar...@gmail.com wrote:
 Currently the keyboard navigation of GTKTreeView is a bit cumbersome,
 collapsing nodes is frustrating because the user has to either click
 on the collapse arrow or select the parent node and Shift+Left on
 it.

Are you aware that there is a key binding bound to backspace that is
in charge of selecting the parent node?

I don't fully see how your proposed behavior greatly enhances the
usability.  Other than that you can easily collapse the entire tree by
keeping shift+left pressed.  (But, we have another key binding just
for that).  In general I think that overloading key bindings with
multiple actions is bad; when the key bindings were being designed
by the usability team, I recall that avoiding overloading was
important.

Who is in charge of GNOME usability/key bindings these days?  In the
past Calum Benson was involved in this If I remember correctly.


regards,

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

Re: Minutes of the GTK+ Team Meeting - 2009-11-27

[Kristian Rietveld]

On Tue, Nov 24, 2009 at 11:13 PM, Emmanuele Bassi eba...@gmail.com wrote:
 4. Implement finger and kinetic scrolling [jjardon]
 - Midori has a finger/kinetic scrolled window implementation
 - Hildon has one as well
 - OpenMoko had one
 - would it make sense to port the feature to GtkScrolledWindow when
  :gtk-touchscreen-mode is set to TRUE?

I don't think so.  IMHO it would be better to put this in as a
GtkScrolledWindow subclass or a new class with a shared interface.
For stylus-based devices (if these are still going to be made), the
normal scrolled window would be preferred.  But still touch screen
mode will be enabled in that case.  Then there is also a case to be
made for embedded devices with touch screens that do not have enough
CPU/GPU power for kinetic scrolling, in which case you also want to
use a normal scrolled window with touch screen mode.  (Think a touch
screen configuration panel for a copier machine, our University has
one.  Apart from CPU power, the thick coating on that screen is also
not suitable for kinetic scrolling).


regards,

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

Re: Why are no developers completing/maintaining native Gtk+ for OS X?

[Kristian Rietveld]

On Nov 10, 2009, at 12:19 AM, Allin Cottrell wrote:

Unfortunately this is not immediately clear if you google, say,
gtk osx.


Ah yes, that's very true.  I am really hidden in/behind my git  
repositories as you might understand ;)



Bottom line: If there's any way to improve the web presence of
GTK/OS X, and to provide a current pre-built GTK framework for
downloading, that could make a big difference.


Yes I understand that and it would be great to have.  Unfortunately, I  
don't have the resources to update a website and provide builds and I  
am hoping other people are willing to take care of that.  I would  
rather put as much spare time as I have in improving the code.



regards,

-kris.

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

Re: Why are no developers completing/maintaining native Gtk+ for OS X?

[Kristian Rietveld]

On Nov 10, 2009, at 12:35 AM, Jacob Juul Kolding wrote:
A framework as in  the Gtk.framework folder you add to the Xcode  
project and then build?


Yes.  It didn't work yet by just dragging in the Gtk.framework folder  
at the time.  But we provided an installer and XCode project template  
that made things work.  I think the code for that is currently  
archived here:


  http://github.com/rhult/gtk-osx-framework/


regards,

-kris.

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

Re: Why are no developers completing/maintaining native Gtk+ for OS X?

[Kristian Rietveld]

On Nov 9, 2009, at 7:10 PM, Jack Skellington wrote:

Hello All

I'm currently in charge of the development of a cross-platform OpenGL
app which uses GTk+ for it's interface.
The app runs on both *nix/X.org and win32 but when I started looking
into OS X I found that the Quartz OS X version of Gtk+ is neither
complete nor being actively developed.


No, it is not fully complete, but getting close.  Recently, I have  
been working on reviewing outstanding patches, fixing up the last few  
kinks remaining after the transition to client side windows and  
implemented proper and complete multi monitor support.  I do have  
plans on how to continue my work on the backend.  Development of the  
Mac port is actually pretty active.  I only have very ample spare time  
to work on this and I do not get paid for this at all.  Saying that  
the OS X port is not being actively developed is actually close to  
insulting to me; I have been trying my best to pick it up after the  
previous maintainer stopped working on it.



Also if a native Gtk+ OS X framework were available people who are
maintaining Gtk+ apps would have the option to extend their user base
to OS X quite quickly.


The basics for this have been worked out in the past and are available  
for everybody to pick up.  John Ralls  co have been doing a good job  
at making GTK+ easy to build and looking into scripts for simplifying  
the creation of application bundles for GTK+ applications and a  
framework.




-kris.

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

Re: Invalid GtkTreeIter

[Kristian Rietveld]

On Wed, Nov 4, 2009 at 12:42 PM, dhk dhk...@optonline.net wrote:
 In the gtk-demo program has a block as follows in the Tree View/Tree
 Store example.  This doesn't initialize the the child iter before using
 it in the gtk_tree_store_append(), but the stamp is valid.

Iterators are not valid until they have been touched by a GtkTreeModel
method.  This will set the stamp of the iterator to correspond to the
current stamp of the model.  If an iterator that has just been
declared has the same stamp as the model, then that's just luck.  In
the block that you've pasted below, child_iter is invalid until
gtk_tree_store_append() returns.  gtk_tree_store_append() sets the
stamp on the iterator and thus makes it valid.


regards,

-kris.


 /* add children */
      while (holiday-label)
        {
          GtkTreeIter child_iter;

          gtk_tree_store_append (model, child_iter, iter);
          gtk_tree_store_set (model, child_iter,
                              HOLIDAY_NAME_COLUMN, holiday-label,
                              ALEX_COLUMN, holiday-alex,
                              HAVOC_COLUMN, holiday-havoc,
                              TIM_COLUMN, holiday-tim,
                              OWEN_COLUMN, holiday-owen,
                              DAVE_COLUMN, holiday-dave,
                              VISIBLE_COLUMN, TRUE,
                              WORLD_COLUMN, holiday-world_holiday,
                              -1);

          holiday++;
        }
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: error building git head GTK on OS X ... IM symbols missing etc.

[Kristian Rietveld]

On Tue, Oct 27, 2009 at 1:50 AM, Paul Davis p...@linuxaudiosystems.com wrote:
 just tried a jhbuild of gtk on OS X (tiger). things went well until it
 got to the link stage in the input methods code. i got a large number
 of messages of this form, one for each (every?) IM module:

 does anybody have any clues what this might be? the missing symbol is
 always _res_9_init

See bug 586510.   It appears that on Tiger we need to explicitly link
against libresolv, this is not needed on Leopard and higher.  I also
reported this when I ran into it (bug 590482), there seems to be a
patch which has not been reviewed yet.  Unless the GLib maintainers
object I will review and commit a patch for this then :)


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

Re: error building git head GTK on OS X ... IM symbols missing etc.

[Kristian Rietveld]

On Oct 27, 2009, at 5:25 PM, Shawn Bakhtiar wrote:
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I.. -DG_LOG_DOMAIN= 
\GLib\ -DG_DISABLE_CAST_CHECKS -DG_DISABLE_DEPRECATED - 
DGLIB_COMPILATION -DPCRE_STATIC -I/Users/sbakhtiar/gtk/inst/include - 
DG_DISABLE_SINGLE_INCLUDES -D_REENTRANT -g -O2 -Wall -MT gatomic.lo - 
MD -MP -MF .deps/gatomic.Tpo -c gatomic.c  -fno-common -DPIC - 
o .libs/gatomic.o
/var/folders/8i/8iPY4ZafEpezLgvmjxSKSU+++TY/-Tmp-//ccNq7o6P.s: 
103:Incorrect register `%rdx' used with `l' suffix


Ah yes, I think I have stumbled on this as well.  This is probably  
caused because the default jhbuildrc for the Mac forces a build for  
the 486:


# When building on intel, force build to be 486, since glib won't
# enable asm atomic operations otherwise.
#
try:
_f = os.popen(uname -p)
if _f.read().startswith(i386):
append_autogenargs(glib, --build=i486-apple-darwin)

I changed the last line to:

 append_autogenargs(glib, --build=x86_64-apple-darwin)

And that fixed it for me.   (If you have a Mac with a Core2 processor,  
the user land will be in 64-bit in Snow Leopard).



regards,

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

Intricate changes to Quartz/OSX backend

[Kristian Rietveld]

Hi,

Over the weekend I have reworked how the Quartz backend does its
coordinate transformation.  You can imagine this is at the very core
of the backend and thus a very intricate change set.  I have just
pushed these changes to git master.  This is a call out to all GTK+ users
on Quartz to please report any issues they find so we can iron out
any regressions quickly.

These changes were needed to properly implement multi monitor support
in the Quartz backend.  The code implementing this support has also
been pushed to git master.  This includes support for emitting the
::size-changed and ::monitors-changed GdkScreen signals when appropriate.
I have tested this with a myriad of dual monitor setups on my Tiger laptop,
I will give it some testing on my Snow Leopard machine later this week.
Again, testing is appreciated and if you find issues, please let me know.


thanks,

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

Re: Intricate changes to Quartz/OSX backend

[Kristian Rietveld]

On Oct 26, 2009, at 4:23 PM, John Ralls wrote:
Oh, and unstable won't build without intervention on Tiger, because  
the latest Pango uses CoreText instead of ATSUI; CoreText wasn't  
supported before Leopard.


They didn't really port the backend to CoreText.  It is still using  
the ATSUI API and they changed two function calls.  I have an easy  
patch that puts the old calls (which were removed) back and then it  
builds and works fine on Tiger.  I will try to clean this patch up and  
push it soon (and also test it on Leopard, which I was not able to do  
before).


The real challenge will be to write a proper, real, CoreText backend  
for Pango.  I might tackle that in the future.



regards,

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

Re: Intricate changes to Quartz/OSX backend

[Kristian Rietveld]

On Oct 26, 2009, at 3:03 PM, John Ralls wrote:
I'll pull  build for SL this morning. What particular dual-monitor  
behavior should I look for?



I have verified that it builds fine on SL.  Things that might be  
broken are event delivery on the secondary monitor (or on the main  
monitor if the menubar is on the secondary), broken menus, broken  
window placement, etc.  If you find no regressions, then awesome :)



regards,

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

Re: Intricate changes to Quartz/OSX backend

[Kristian Rietveld]

On Oct 26, 2009, at 4:50 PM, John Ralls wrote:

On Oct 26, 2009, at 8:36 AM, Kristian Rietveld wrote:


On Oct 26, 2009, at 3:03 PM, John Ralls wrote:
I'll pull  build for SL this morning. What particular dual- 
monitor behavior should I look for?



I have verified that it builds fine on SL.  Things that might be  
broken are event delivery on the secondary monitor (or on the main  
monitor if the menubar is on the secondary), broken menus, broken  
window placement, etc.  If you find no regressions, then awesome :)


What do you mean by event delivery? That mouse-clicks in a window  
on the secondary monitor don't do anything?


Yes for example.  As well as missing motion and crossing events.


regards,

-kris.

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

Re: Auto-resize on table headings

[Kristian Rietveld]

Hi,

On Wed, Sep 30, 2009 at 6:52 AM, Diogo Baeder diogobae...@gmail.com wrote:
 I was using my Ubuntu Jaunty, here, and noticed something that could be
 usefull, that Windows (argh!) GUI already has: auto-resize on table
 headings. In a Windows XP system, when a user double-clicks at the table
 column separators, the column to the left resizes to fit the largest content
 of the rows.

 Wouldn't it be a usefull feature? Let me know your opinions on it...

This has already been implemented in GtkTreeView (I think since 2.0).


regards,

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

Re: Treeview Row Count

[Kristian Rietveld]

Also note that for *lists* (so no parent nodes, no children) a call
like gtk_tree_model_iter_n_children (model, NULL) will suffice.


-kris.

On Thu, Sep 24, 2009 at 1:32 PM, Tadej Borovšak tadeb...@gmail.com wrote:
 Hello.

 Is there a function to give the number of rows in a treeview?

 You probably want to know how many lines are in the GtkTreeModel that
 serves as data source for GtkTreeView. There is no simple function
 that would serve you this number, so you'll have to take one of the
 two available paths:
 1) maintain number of rows externally by increasing/decreasing it on
 additions/removals
 2) traverse the whole model and count the lines

 If you go with second option, gtk_tree_model_foreach function may be
 of help. Sample counter would look like this:

  CODE 
 ...

 gint no_rows = 0;

 gtk_tree_model_foreach( model, (GtkTreeModelForeachFunc)count, no_rows );

 ...


 static gboolean
 count( GtkTreeModel *model,
       GtkTreePath  *path,
       GtkTreeIter  *iter,
       gint         *no_rows )
 {
    *no_rows+;
    return( FALSE );
 }
  CODE 

 Tadej

 --
 Tadej Borovšak
 tadeboro.blogspot.com
 tadeb...@gmail.com
 tadej.borov...@gmail.com
 ___
 gtk-app-devel-list mailing list
 gtk-app-devel-list@gnome.org
 http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Bug in GtkTreeView or programming bug?

[Kristian Rietveld]

On Wed, Sep 16, 2009 at 10:56 PM, Daniel Leidert
daniel.leidert.s...@gmx.net wrote:
 Doh! Attached.

The program in the attachment tries to set the cursor on a path that
does not exist in the tree view.  This path does not exist in the
view, because the view is not connected to a model.  Because of this,
the call to gtk_tree_view_set_cursor() will print the assertion as an
invalid path has been provided.  And because
gtk_tree_view_set_cursor() failed to set the cursor,
gtk_tree_view_get_cursor() will return a NULL path.


regards,

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

Re: Bug in GtkTreeView or programming bug?

[Kristian Rietveld]

On Fri, Sep 18, 2009 at 6:22 PM, Daniel Leidert
daniel.leidert.s...@gmx.net wrote:
 Thanks for your hints. Yes, the code was incomplete. But I think the
 attached code should work. It still returns:

 (unknown:20960): Gtk-CRITICAL **: gtk_tree_path_to_string: assertion
 `path != NULL' failed
 path=(null)

 Am I still doing something wrong?

Setting the cursor still fails because path 1:0 is not visible in
the tree view (although the path does exist in the model).  It is not
visible in the tree view because node 1 is collapsed.  If you expand
node 1 first, then the call to gtk_tree_view_set_cursor() will
succeed as well as the call to gtk_tree_view_get_cursor().

 The problem I'm trying to reproduce is the testcase from
 http://git.gnome.org/cgit/perl-Gtk2/tree/t/GtkTreeView.t. This one fails
 in line 233 (-to_string()) on recent Debian system, because it seems
 the path returned is NULL. So I'm trying to program this in C to check,
 if the result is the same. And it seems to be the case.

The reason why this is failing now is probably because there have been
some changes in this area in trunk recently, making the behavior more
strict.


regards,

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

Re: Bug in GtkTreeView or programming bug?

[Kristian Rietveld]

2009/9/14 Daniel Leidert daniel.leidert.s...@gmx.net:
 In Debian the test suite of perl-gtk2 failed [1]. Examining the
 situation a bit further it seems, that even after setting a cursor, the
 reurned path from gtk_tree_view_get_cursor() is NULL. I tried to write s
 short program to reproduce this in C (attached). When I run it get:

Seems the attachment got dropped?


regards,

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

Re: another quartz maintainance request (patch review commit)

[Kristian Rietveld]

Hi,

On Thu, Sep 10, 2009 at 2:24 PM, Paul Davis p...@linuxaudiosystems.com wrote:
 This bug report: https://bugzilla.gnome.org/show_bug.cgi?id=594738
 contains a potentially important fix to make 2+ monitors work with
 GTK/Quartz. Those of us in the GTK/Quartz community would appreciate
 someone with commit rights (1) looking at christian's approach and
 forming a judgement on whether its the right approach to the problem
 (2) committing this or some eventual fix.

 Things are looking pretty bad for GTK/Quartz maintainance right now.
 Nobody that has commit access appears to be in a position to test
 (i.e. care) about Quartz fixes; those who care do not have commit
 access. It would be hugely preferable (IMHO) for us to not to have to
 branch to an alternate git repo ...

I agree with you that it would be preferable to have everything in the
upstream git repo and avoid having to branch to an alternate repo.
Currently my problem is that I do not have access (yet) to a machine
running Leopard or Snow Leopard, so I am basically stuck on Tiger and
can only properly test fixes on that platform.  Also, the build is
currently broken on Tiger so I have been working to fix that.  (I have
half finished patch to Pango that I also need to test on Leopard at
some point ;) I will leave that for now and carry on with other work I
can do first).  So in short: I do care about the Mac port, but I have
very little spare time.

Since I fortunately have a VGA-dongle for my MacBook I can actually
test the fix in the bug you brought up.  I will promise to do so in
the next 7 days.  Unfortunately, I cannot really keep up with bugs as
soon as they come in ...  It is probably useful if I get myself added
to the gtk-quartz-maint alias though.


regards,

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

Re: Proposal: Deprecate tab-pack child property in notebook for 2.18

[Kristian Rietveld]

On Mon, Aug 24, 2009 at 3:34 PM, Alberto Ruizar...@gnome.org wrote:
 So my proposal is to deprecate this child property for the 2.x series,
 so that we can get rid of it by 3.0, (meaning 2.18?).

 This would allow a long overdue cleanup in the notebook codebase and
 make it more manageable to include other features (tab sliding
 animations ala Google Chrome as an example?)

 Any thoughts? Am I talking crack here? Matthias? Kris? :-)

Okay I consulted Carlos on this one, because I thought the property
was operating on the contents of the tab, but apparently it is about
the tab itself.  I fully agree that this is an interesting feature
;)  I also see how this complicates the code by at least a single
order of magnitude.  When removing, the functions that Christian
pointed at should be taken into account.  (Maybe deprecate those two
functions and have separate accessors for the remaining tab-fill and
tab-expand properties?).

What I am still wondering about is the history of this feature.  Why
was it included in the first place?  Carlos says he thinks this was
included because of some effort to make all containers obey the same
child properties.


regards,

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

Re: Webkit-gtk and MacOSX

[Kristian Rietveld]

Hi,

On Sun, Aug 23, 2009 at 6:26 AM, John Rallsjra...@ceridwen.us wrote:
 I wonder, though, if that's the best approach for Gtk+ applications using
 Quartz, since Webkit is already well integrated into the system. If I were

Interesting question really.  I can see that it feels like overkill to
have a Quartz Webkit-GTK build next to the system's Webkit.

 to provide a Gtk-Carbon shim library using the approach in
 http://developer.apple.com/documentation/Cocoa/Conceptual/DisplayWebContent/Tasks/CarbonApps.html
  will it integrate OK with gdk-quartz and cairo-quartz?

What I am wondering about is how this will work with GTK+ applications
that are using Webkit.  Does Webkit-GTK have any specific APIs?  Does
font rendering look similar?  Does Webkit-GTK handle parts of GTK+
theming that are not possible using the Carbon shim approach you are
suggesting?


regards,

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

Re: Webkit-gtk and MacOSX

[Kristian Rietveld]

On Tue, Aug 25, 2009 at 9:35 PM, Xan Lopezx...@gnome.org wrote:
 WebKit is the native layer on top of WebCore offered by each port for
 their platform, so the answer to that is: yes, WebKitGTK provides
 GObject APIs which are all specific to it.

Right, so another question: does the GObject API contain stuff that is
not possible in the native layers for other platforms?

 Does font rendering look similar?

 Similar to what? The system WebKit? I believe WebKitGTK+ uses pango in
 OSX, so I suppose it depends on what pango does in OSX.

Yes, that would be CoreText on recent releases.  And I would guess
system WebKit uses that as well.  But combined with your following
point:

 Does Webkit-GTK handle parts of GTK+ theming that are not possible using the 
Carbon shim approach you are
 suggesting?

 I'm not sure of what that Carbon shim approach is or how it works, but
 WebKitGTK+ uses the current GTK+ theme for all its rendering,
 including web forms, media controls, etc.

If the Carbon shim approach does not take the GTK+ theme / fonts into
account, there is a fair chance that the WebKit control will look
kind of out-of-place in a GTK+ application.  Especially if it also
involves web form and media controls.

What do you think?


regards,

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

Re: Notes and thoughts on the GTK+ meeting at GUADEC

[Kristian Rietveld]

Hey there,

Replying to myself with a short status update:

On Fri, Aug 14, 2009 at 8:38 AM, Kristian Rietveldk...@gtk.org wrote:
 - Implement class private data, bug 521707 has been filed for this and
 contains a patch.  I will give this a review and if the patch seems
 right get Tim to review it as well.

I gave this one a pre-review and the patch got a couple of fixes done
by the original reporter. I am now harassing Tim to review it.

 - Introduce GObject convenience accessors.  Bug 541569 has a patch
 that is partly reviewed.  I will review this as well.

Reviewed, needs some more work.

 - Seal GtkStyle.  This really has to be done together with
 investigating the plans for theming, see below.

Discussion on theming possibilities is going on now, I will reply were
appropriate later on.

 - Investigate whether there is stuff to seal in GDK, GLib.  I think
 for now there won't be a GLib 3 (but please correct me if I am wrong),
 so I would say to leave out GLib for now.  GDK certainly has to be
 done.  I can look into this and write up a proposal later on.

I worked on sealing GDK, see bug 592580.  Also updated the
PendingSealings wiki page.

Mitch will be giving his thoughts on the remaining questions from this
list soonish.


regards,

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

Re: Widget states for 3.0 (and 2.18?)

[Kristian Rietveld]

Jumping in here from a practical perspective, please correct me if I am wrong ;)

On Mon, Aug 17, 2009 at 5:42 PM, Cody Russellbrats...@gnome.org wrote:
 This is not how it works in GTK+. The checked state is indicated by
 the GtkShadowType passed to the drawing function (gtk_paint_check),
 where:

 Right, but I guess that's part of the point of all this.  Wouldn't it make
 more sense if we try to move this type of information into a single location
 instead of having these kind of work-arounds?

 I'm not suggesting we change how things work in 2.18, but in 3.0.  But I'm
 bringing it up now because we're adding gtk_widget_get_state() to take over
 for the GSEAL'd widget-state member.  If we avoid this and introduce APIs
 for each widget state instead then we have time to revise how it works
 internally for 3.0 without breaking a newly-introduced API.

But still we need a compatible accessor for the old state field in
2.90 (and thus 3.0).  I think there is no other way than to add
gtk_widget_get_state() for now.  Instead introducing a function for
each widget state will result in a much more involved transition.
Could this gtk_widget_get_state() function serve as the mutually
exclusive data set as suggested by Thomas?  The non-mutually exclusive
data set would be introduced at a later stage (3.0) and next to
gtk_widget_set_state().


regards,

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

Re: Notes and thoughts on the GTK+ meeting at GUADEC

[Kristian Rietveld]

On Fri, Aug 14, 2009 at 1:40 PM, Alberto Ruizar...@gnome.org wrote:
 2009/8/14 Kristian Rietveld k...@gtk.org:
 As for theming, I've been discussing a bit with Thomas, Carlos and
 Cody. We have reached some sort of consensus that a backwards
 compatible path is possible adding a second vtable for engines,
 checking the vtable size and working out a structured way to poke the
 scene graph representation. However, we need time to try these things
 out. Thomas pointed out that working on a separate theming library
 makes a lot of sense as it would allow reaching a nice API and it
 would help the special purpose GObject baed toolkits around to have
 proper theming as well (say Nbtk, Glitter...).

 So I think that we've reached the conclusion that theming shouldn't
 get in the way of the current 3.0 plans, as we don't have time to
 deprecate GtkStyle and introduce something new all at once
 (eventhough, we all would have loved to make it).

Great to know that progress is being made here.  Trying things out
definitely sounds like a good idea.  Even though we are now not
planning to deprecate GtkStyle in 3.0, we should have an idea whether
just sealing it will provide enough flexibility to migrate to
something new at a later stage. I think one of the larger problems
has been the hard-coded array sizes of the arrays containing GdkColors
and GdkGCs (but I am not at all an expert on GtkStyle and theming),
and this limitation should disappear in a properly written accessor
function.  Are there more pitfalls that can hold us off from a
successful migration in the future?

 There's the issue of CSS though. Would it be acceptable to deprecate
 gtkrc's in the middle of the 3.0 cycle in favor of CSS theming files?
 This is an area where I'm pretty much blind, prolly Robert Staudinger
 has a better picture than me here, Robert?

Can current gtkrc's and CSS theming files co-exist?

 Now, what I'd love to see is having IRC meetings back, ebassi and
 myself talked roughly about it on IRC, seems that mclasen has a
 toughest schedule these days. Anyone up to figure out hours/date to
 have a 3.0 kickstart meeting and do some rock and roll?

Yes, I agree that would be great.  Maybe we should send out a proposal
for a meeting time and see what people come up with?  I am unsure if
the old time (I actually forgot it) still works for me.


regards,

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