from:"Tim"


On Fri, 26 Sep 2008, Andrew Cowie wrote:


On Thu, 2008-09-25 at 13:06 -0400, Matthias Clasen wrote:

The important part of the assert semantics are: if the assertion
fails, the program aborts.

If you are using assertions in a way that make it important where or
how the message is reported


In the Java bindings we trap the log messages that are raised by
assertions and propagate a (quite fatal) Java Exception instead. That
quite nicely terminates the program, but in a way that a) gives the
developer some idea of where things are wrong, and b) doesn't crash the
VM in the process. Crashing VMs are rather frowned upon.

The fact that assert uses the existing log facility is lovely. Please
revert back to this!


Thanks for the feedback and use case descriptions everyone, I can definitely
see the point why people want to see g_assert() using g_log() be restored.

Similar reasons do apply in the testing framework case though, e.g. assertion
messages from test programs should be sent on to the gtester framework
executavle for logging and should usually not pollute stderr.

I'll investigate if we either:
- Restore g_assert()s old logging behaviour unless g_test_init()
  has been called; or
- Restore g_assert()s old logging behaviour unconditionally and just
  capture + redirect everything from g_log() to gtester after
  g_test_init() has been called.

I hope that should fix everyone's issues.


AfC
Sydney


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

Moving to GtkBox (Re: Minutes of the GTK+ Team Meeting - 2008-09-23)


On Thu, 25 Sep 2008, Mike Kestner wrote:


The types would essentially be
boilerplate, so it's not like they are going to be a maintenance issue.

If the motivation for removing the types is that, things aren't as
beautiful as they could be then that argument doesn't really outweigh
the pain of porting existing code.  Especially when the cost of
supporting existing code is so low.



There doesn't really need to be any pain involved for the application
developers at all here. We've previously talked about libgtk3compat
(or libgtk3graveyard) and this looks like another good example for
having it. I.e. the box changes can look as follows:

- Make GtkBox a constructable widget (effectively introducing a new
  user level widget as Mitch described)

- Add orientation switching to GtkBox:
gtk_box_set_orientation (GtkBox*, GtkOrientation);
  This effectively moves all hbox_size_request, vbox_size_request,
  hbox_size_allocate and vbox_size_allocate logic into gtkbox.c

- Make GtkHBox and GtkVBox very shallow compatibility types derived
  from GtkBox. This involves one G_DEFINE_TYPE() macro and implementing
  gtk_hbox_new and gtk_vbox_new as simple wrappers around g_object_new.
  (They'd effectively call gtk_box_set_orientation() in their _init
  functions.)

- Change the packing defaults for gtk_box_pack_start_defaults and friends
  unless old compat types are detected, i.e.:
void
gtk_box_pack_start_defaults (GtkBox *box, GtkWidget *child)
{
  gboolean compat_type =
g_type_is_named (G_OBJECT_TYPE (box), GtkHBox) ||
g_type_is_named (G_OBJECT_TYPE (box), GtkVBox);
  gboolean expand = compat_type ? TRUE : FALSE;
  gboolean fill = compat_type ? TRUE : FALSE;
  gtk_box_pack_start (box, child, expand, fill, 0);
}
  I've used a new helper function g_type_is_named() here, since adding
  that might be helpful in a couple other compat cases as well. It roughly
  amounts to g_type_is_a (type, g_type_from_name (type_name)); and doesn't
  require the checked for type to actually be registered.

- Change additional defaults as needed, e.g.:
  gtk_box_init (GtkBox *self)
  {
gboolean compat_type =
  g_type_is_named (G_OBJECT_TYPE (box), GtkHBox) ||
  g_type_is_named (G_OBJECT_TYPE (box), GtkVBox);
if (!compat_type)
  gtk_widget_show (self); // GtkBox defaults to ::visible=TRUE
  }

- The shallow compat types GtkHBox and GtkVBox could be moved into a
  libgtk3compat that allows fine grained undeprecation, e.g.:
#define GTK_DISABLE_DEPRECATED 1 // allow code cleanups
#define GTK_COMPAT_HBOX1 // still need GtkHBox though
  So as long as GTK_COMPAT_{H|V}BOX are defined, *no* existing
  application code will need changing.

- Locking the orientation for GtkHBox and GtkVBox widgets could be added
  in addition, but I don't think it's strictly neccessary. After all,
  GtkHBox and GtkVBox will continue as mere wrappers to help people in
  their porting efforts and IMHO should be kept as simple as possible.
  The officially supported box interface will be GtkBox anyway.

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

Re: Moving to GtkBox (Re: Minutes of the GTK+ Team Meeting - 2008-09-23)


On Fri, 26 Sep 2008, Peter Clifton wrote:


On Fri, 2008-09-26 at 11:44 +0200, Tim Janik wrote:



- Change additional defaults as needed, e.g.:
   gtk_box_init (GtkBox *self)
   {
 gboolean compat_type =
   g_type_is_named (G_OBJECT_TYPE (box), GtkHBox) ||
   g_type_is_named (G_OBJECT_TYPE (box), GtkVBox);
 if (!compat_type)
   gtk_widget_show (self); // GtkBox defaults to ::visible=TRUE
   }


Why not store the defaults as class struct memebers. GtkBox can
initialise the class members to the new defaults, then the shallow
compat subclasses can override them.


Because it adds complexity and memory overhead without any neccessity.


This avoids the string compare for each operation where multiple
defaults exist. (I assume from the  is necessary with the type lookup).


There is no need to avoid a string lookup here, widget packing is hardly
time critical (i.e. it totally pales compared to e.g. the time spent on
realizing, size requesting or size allocating widgets).


It also avoids leaving any trace of the names GtkHBox / GtkVBox in GTK.
It seems kindof silly remove the TINY API for using these old classes,
but have to retain lots of:

if (detect_old_class_names) {
 foo;
else
 bar;

Since the legacy is still there! Plus the code would presumably run much
faster if you could just do GTK_IS_HBOX() rather than look up the name
by string.


As i said above, there is no need at all for micro speed optimization
in these code paths. And using GTK_IS_HBOX() adds a type registration
dependency, which prevents things like moving GtkHBox/GtkVBox into a
different lib like libgtk3compat.


Peter Clifton


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

Re: Moving to GtkBox (Re: Minutes of the GTK+ Team Meeting - 2008-09-23)


On Fri, 26 Sep 2008, Peter Clifton wrote:


On Fri, 2008-09-26 at 12:57 +0200, Tim Janik wrote:



As i said above, there is no need at all for micro speed optimization
in these code paths. And using GTK_IS_HBOX() adds a type registration
dependency, which prevents things like moving GtkHBox/GtkVBox into a
different lib like libgtk3compat.


Forget the micro-optimization on the string lookups. My real point was
this:

If you're leaving all the behavioual defaults for the old widgets in Gtk
3.0, then going to pains to detect compat replacement widgets with the
old class names to change behaviour, then you might as well have just
left the compat widgets in the library.

For real cleanup, the widgets would have to be removed (including any
special-casing of behavioural defaults). If that means the base-class of
any compat widgets needs to support changing the defaults during
inheritance, that looks to me like how it should be done.


Right, but per-instance fields still aren't neccessary for this kind of
special casing. Adding a single method needs_compat_defaults() that
HBox/VBox would override to return TRUE is good enough to figure the
specialized class bahviour (and allows moving HBox/VBox out of Gtk+ still).
g_type_is_named() would just have been a lazy shorthand for this ;)


Peter Clifton


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

Re: string return result conventions

2008-09-16 Thread Tim Janik


On Mon, 15 Sep 2008, Luke Kenneth Casson Leighton wrote:


ok - can i ask people a favour?  could you kindly review e.g this:
http://lkcl.net/webkit/DerivedSources/GdomAttr.cpp



just looking at it myself, i think where i use fromUTF8 i have a
memory leak,


... but after looking at it again i don't think i have..


there, but key question: in the use of
g_value_set_string() - that takes over the memory passed in to it,
right?


... i should be using g_value_take_string(), shouldn't i?


g_value_set_string() duplicates your string internally.
g_value_take_string() takes over ownership of your string and
frees it with g_free(). That is, you might only pass in strings
that have been allocated with g_malloc/g_new/g_strdup/g_*,
because only those require a matching g_free() call.

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

Re: string return result conventions

2008-09-15 Thread Tim Janik


On Mon, 15 Sep 2008, Luke Kenneth Casson Leighton wrote:


ok - in this situation, fortunately we have control over that.  the
property getter is entirely auto-generated.  the code review of the
new webkit glib/gobject bindings brought to light the webkit
convention of not imposing any memory freeing of e.g. strings on
users of the library.  use of refcounting is done on c++ objects, for
example.

the strings in webkit are unicode (libicu).  _at the moment_ i'm
alloc-sprintf'ing strings - all of them - into utf-8 return results.

it was recommended to me that i create a string pool system, to keep a
record of strings created, and, at convenient times, destroy them all
(reminds me of apache pools and samba talloc).  exactly when is
convenient is yet to be determined, which is the bit i'm not too
keen on :)


We've done a simialr thing in beast (beast.gtk.org), where we pile up
strings in a garbage collector pool and free them, once the topmost
main loop level is reached. This works fairly well in practice, it
however does have the following downsides:

- Strings can't be kept used across main loop invocation:
  foo = get_string();
  gtk_main();
  foo; // - has been freed now

- Loops might build up extremely large temporary memory requirements:
  for (i = 0; i  100; i++)
gc_pool_add_string (123456789);
  Be aware that this loop needs 10MB. A more sophisticated GC pool
  can be able to at least deal with:
  for (i = 0; i  100; i++)
{ foo = get_string(); gc_pool_free_early (foo); }
  However that can still cause temporary bloat, if get_string() adds a
  string to the GC pool internally without early freeing.

- Recursive main loops block the GC pool:
  gtk_main();
dispatch_handler1(); // adds strings to GC pool that need freeing
gtk_main(); // recursive main loop blocks *any* GC pool freeing

So basically, there is no *convenient* time for string freeing in
C. Someone could always keep a pointer to a returned member around
somewhere. Because the event loop processing model most often recurses
down into handlers and comparatively quickly winds up the stack again,
the main loop coupled GC pool freeing tends to moderately work in
practice, but as shown above, it does come with severe potential
worst cases. Particularly the for() add_to_pool (pointer); case
is easily triggered implicitely.


clearly, the best overall thing would be to actually return the
unicode strings themselves rather than convert them (needlessly?) to
utf-8.


Strings handed out by the Gtk+ API and also strings passed in to Gtk+
API are/must be in UFT-8 format already, so there's no need for conversion
here.


if that's not possible to do, what would you recommend, in this situation?

many thanks,

l.



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

Re: string return result conventions

2008-09-14 Thread Tim Janik


On Sun, 14 Sep 2008, Luke Kenneth Casson Leighton wrote:


folks, hi,
i'm looking for advice on memory return result conventions - who is
responsible for maintaining andd/or freeing memory, in particular
strings, as return results from pproperrty getting for example.  the
webkit-glib bindings are going extremely well, pywebkitgtk has them in
use, however, the conventions for webkit are that the library
maintains responsibility for any string management, such that users of
the library do not have to worry about malloc or free.
therefore it's important for me to find out what glib / gobject memory
conventions are, for strings.


Strings querried through the property interfacem e.g.:

gchar *string = NULL;
g_object_get (label, label, string, NULL);

is always duplicated and needs to be a freed by the caller,
because the returned string might have been dynmically
constructed in the objects proeprty getter (i.e. not
correspond to memroy actually allocted for object member storage).


much appreciated your advice.
l.


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

Re: Size negotiation and initial top-window size

2008-09-11 Thread Tim Orford

On Tue, Sep 09, 2008 at 11:54:01AM +0200, Olivier Guilyardi wrote:
 Hi all,
 
 in my app, I need the top-window to have an initial size that suits the 
 content.
 It's a bit like in the Gimp, where the image window initial size is set
 accordingly to the image size, at a carefully chosen zoom level.
 
 However, this initial size is not mandatory. The user must be able to shrink 
 the
 window if he like, there are scrollbars anyway, just like in the Gimp.
 

Try removing the initial size request after the negotitations are complete:

void
new_window()
{
  void
  on_allocate(GtkWidget* window, gpointer user_data)
  {
static gboolean first_time = TRUE;
if(first_time  GTK_WIDGET_REALIZED(window)){
  //remove previous minimum size so that user can resize the window.
  gtk_widget_set_size_request(window, 20, 20);
  first_time = FALSE;
}
  }

  GtkWidget* window = gtk_window_new(GTK_WINDOW_TOPLEVEL);
  g_signal_connect(G_OBJECT(window), size-allocate, G_CALLBACK(on_allocate), 
NULL);
}


Regards
--
Tim Orford

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

Re: my ongoing fantasy of garbage collected C programming

2008-08-06 Thread Tim Janik


On Tue, 5 Aug 2008, Britton Kerin wrote:



I've tried several times now to get Hans-Boehm
(http://www.hpl.hp.com/personal/Hans_Boehm/gc/) working with gtk, but so
far no luck.  I found all the stuff about how to build glib to be GC
friendly and set env vars and such, and then I rebuild almost all of the
lib stack on top of it (except atk and the X libs themselves). I still
end up with strange failures and seg faults that go away if I just
remove -lgc from the link flags.  I don't free anything by hand so its
got to be something the GC is doing.

I'm hoping that the presence of the gc-friendly build support in glib
means that somebody knows how to make this work. I would really love to
know how to do it. I won't go into the different gc builds and such that
I've tried unless someone is interested.


AFAIK, no one has tried to make boehm GC really work with glib  gtk+
programs so far. The gc friendly mode that glib has in general just
zeros-out certain memory portions before calling free(), so GC-alike
leak detectors like e.g. valgrind can do a more accurate job.

Depending on how clever your GC implementation is, I'd actually expect
quite some real world problems with it trying to collect glib
memory. E.g. GLib only stores pointers into the _middle_ of fundamental
GType nodes (not the node start) and with GSlice provides its own
allocator that cannot be replaced with GC collection (the memory pages
allocated by gslice.c:allocator_memalign are also not pointed to
directly, a pointer to an admin structure at the page tail is kept
instead).


Thanks,
Britton


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

Re: va_list *

2008-07-31 Thread Tim Janik


On Mon, 28 Jul 2008, Ryan Lortie wrote:


ISO C99 (footnote 215, §7.15) says that this program is valid and should
print out 1, 2, 3...


Note that GLib can currently *not* rely on C99 features.
That's a pity, but no is the oucome of our last discussion
on this topic:
  http://mail.gnome.org/archives/gtk-devel-list/2006-January/msg00057.html



 Collects a variable argument value from a va_list. We have to
 implement the varargs collection as a macro, because on some systems
 va_list variables cannot be passed by reference.



AFAIR, this was at least the case on systems that implemented va_list
with an array type.


Can anyone please weigh in on whether or not these some systems have
gotten their act together yet?  Is it still necessary to go out of our
way like this in glib?


I think it's best to simply switch to C99 at *some* point (e.g. next year?
2009 - C99 will be ten years old by then). At that point we *know* we can rely
on features like va_list pointers. Before that, people are not forced to
upgrade compilers, so there'll always be an ancient setup/system that breaks
for new feature uses.


Thanks in advance.

Cheers


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

GUADEC 2008 GTK+ Meeting Minutes

2008-07-23 Thread Tim Janik



Hey All.

Kris took meetings during the GTK+ developers meeting at this
years GUADEC. It took some time to transform them into a proper
writeup, and Kris had to leave for a vacation flight before
he could finish them off.

So here are the minutes from Kris with a few finishing touchups
from me. Please keep in mind that these minutes are from our
meeting 2 weeks ago, and thus don't reflect on recent community
discussions and new tweaks to the 3.0 plans.

For an update on our latest plans, please have a look at the
summary of yesterdays IRC meeting:
  http://mail.gnome.org/archives/gtk-devel-list/2008-July/msg00187.html




GTK+ Meeting, 8 July 2008, GUADEC 2008
--

Final agenda:

1. Opening
2. 2.14 release overview
3. Planning GTK+ 2.16
   - Features
   - Schedule
4. 3.0
   - Current status
   - Schedule
5. Technical discussions
   - 3.0 policy
   - Sealing GtkRcStyle
   - Offscreen rendering event processing
   - New GDK backend that renders into image buffers
6. Closing


Notes:

1. The meeting was opened at 12:10.

2. Last year we have promised to get GTK+ 2.14 out of the door around GUADEC
2008.  We are closely approaching this date and we seem to be mostly
feature complete.  The testing framework bits have landed in GTK+, as well
has the first part of the offscreen rendering work.  Furthermore, a lot of
small API improvements, bug fixes and clean ups have been done.  The
remainder of the offscreen rendering work deals with event processing and
is hard to get right (more on this later in the meeting).  If we wait for
this to land we will most definitely not make the GUADEC 2008 release date.
Therefore the current plan amongst the core developers is to delay the
second part of the offscreen rendering work to the next release and get
GTK+ 2.14 released in its current shape.

After asking whether people have more pending features that could make it
into 2.14, nobody has something ready that could go in at this point.
Mitch still wants to get new adjustment API (accessors for it) in 2.14 if
possible.

During the next IRC meeting the team would like to propose to API freeze
the next development release and release the stable 2.14 after a few weeks
of stabilization.


3. It was mentioned that Behdad has requested us to consider renaming to
GTK+ toolkit and change the license to GPL3.  The renaming to GTK+
toolkit issue has already been handled in bug #540529 and will not be
done.  Changing the license to GPL3 (in GTK+'s case LGPL3) is a long
process and is not planned to be carried out immediately.  In any case
we do not want to block a possible GTK+ 3.0 on a license change. A
recent discussion on the mailing list left the impression that some
implications in mixing LGPL3 code with LGPL2 code still have to be
figured out.

Apart from offscreen rendering part 2, the following items are on the
agenda for GTK+ 2.16:
 * Mathias Hasselmann's extended layout work.  Plans are to start API
   review soon.
 * Mathias Hasselmann's tool palette.  The tool palette is a tool box
   as found in for example the Glade UI builder and GIMP.  It will undergo
   some more real world testing as it will be tried to replace Glade's
   toolbox with the tool palette.  After that remaining kinks in the API
   will be ironed out and a proposal send to the mailing list for
   discussion.
 * Libsexy integration.  This is something that has been on the list for
   a couple of years now.  Libsexy certainly contains some nice features
   and there are no objections if these get merged at some point.  The
   problem is that so far nobody has stepped up to actually cherry pick
   features from libsexy and get them in such a form so that inclusion in
   GTK+ can be considered.  Lately Cody Russell has been working on getting
   an icon entry going for GTK+.  If his work continues we hope to get
   a few libsexy improvements in GTK+ 2.16.
 * Simpler API to create a simple ListView, a wrapper around GtkTreeView
   to make simple list creation without MVC split easy.  Kris has been
   discussing such an API with Johan Dahlin and Emmanuele Bassi as they are
   familiar with the Python and Perl variants of simple lists APIs
   respectively.  The Python and Perl APIs seem nice and similar, we want
   to attempt to come up with something similar for C.

Further ideas that were raised:
 * Add a new signal to GtkTreeModel that inserts a given number of rows
   in one go.  Kris argues that this is only part of a bigger problem: we
   want to have a proper batch/transaction API in GtkTreeModel.  We
   shouldn't just add this single signal for now, but sit down and properly
   design this transaction based API and try to get it right for most
   use cases.
 * How to do extend the print dialog?  Tim advises to file patches
   implementing these extensions in bugzilla.
 * What is happening on the GLib foundation library front?  This
   foundation library is supposed to become a general desktop support
   abstraction

gtk-demo can't load icons on Sun Solaris 10.

2008-07-21 Thread Halliday, Tim

I've built v2.12.5 on Solaris 10 using the Sunstudio 11 compiler. Everything 
seemed to go ok. However, when I run gtk-demo it throws a bunch of errors when 
I try the Application Main Window demo. Somehow it can't find the stock icons.

Any ideas on what's wrong with my setup?

Thanks.
-tim


[69] % uname -a
SunOS 5.10 Generic_127111-06 sun4u sparc SUNW,Sun-Fire

[70] % pwd
/data/halliday/gtk+-2.12.5/demos/gtk-demo

[71] % ./gtk-demo

(gtk-demo:27500): GdkPixbuf-CRITICAL **: file gdk-pixbuf-io.c: line 836: 
assertion `filename != NULL' failed

(gtk-demo:27500): Gtk-WARNING **: Error loading theme icon 'gtk-open' for 
stock: Failed to load icon

(gtk-demo:27500): GLib-GObject-CRITICAL **: file gobject.c: line 1742: 
assertion `G_IS_OBJECT (object)' failed

(gtk-demo:27500): Gtk-CRITICAL **: file gtkstyle.c: line 2101: assertion 
`base_pixbuf != NULL' failed

(gtk-demo:27500): Gtk-CRITICAL **: file gtkstyle.c: line 1989: assertion 
`pixbuf != NULL' failed


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

Re: libgtk3deprecated (Re: About GTK+ 3.0 and deprecated things)

2008-07-17 Thread Tim Janik


On Thu, 17 Jul 2008, Sven Herzberg wrote:


Hi,

Am Donnerstag, den 17.07.2008, 20:18 +0200 schrieb Tim Janik:

On Thu, 17 Jul 2008, Martin Meyer wrote:

2) Is it entirely possible from a gtk perspective to have all that
code detached from gtk-core and placed in a different library? Are
there any deprecated things that this would *not* work for? Maybe we
can detach as many as possible and leave the rest in place for now.


Complete deprecated widgets should be fairly easy to separarte,
single deprecated functions that some components may have can be
hard to impossible to move when the implementation requires
access to internals.


But this could be worked around with a strange compile setup, right?
With something like this:
~/sources/gtk+
~/sources/gtk-deprecated
and gcc -I$(top_srcdir)/../gtk+/gtk
to access potential gtkwidgetpriv.h, right? Would mean recompile with
every source change to gtk+ but if some (many?) people depend on this,
I think they can easily distribute the burden of maintaining a parallel
version.


There is no point in having libgtk3deprecated access gtk+ internals and
not go through public interfaces only. If we did that, we'd simply preserve
the maintenance burden on Gtk+ internal definitions. We really want to
get rid of a bunch of stuff, be free to refactor structures and internal
methods to implement new things cleanly. If libgtk3deprecated kept acessing
and relying on internals it'd either constantly break or hinder us on doing
reorganisations.

Also, this'd tie release cycles and maintenance resources of libgtk3deprecated
closely to Gtk+ again. The main point in seperating deprecated code is to
load off the core team though, so application developers or distributors
that still have an interest in deprecated components can take over its
maintenance as long as that's necessary.


A closing word on the library name, since this'd be an ABI break,
such a library only makes sense for Gtk+-3.0 (or 2.99.0) and should
probably advertise that it ships deprecated Gtk+ stuff. So the best
name is probably libgtk3deprecated for this (there could possibly
be a libgtk4deprecated as well at some point).


Well, so GTK+ 4.0 could be accompanied by these two:
libgtk3deprecated-4.0.so
libgtk4deprecated-3.0.so
Right?


I'd guess that if deprecated 2.x components that landed in libgtk3deprecated
are still required when a libgtk4deprecated is released, they could
possibly need some porting and simply be included as real parts of
libgtk4deprecated. This is highly speculative though and can be considered
when we have the Gtk+-4.0 discussion. We're not quite there yet ;)


Regards,
 Sven


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

Re: Astonishing allocation bug in glib-2.16.4 compiled with gcc 2.96

2008-07-16 Thread Tim Janik


On Tue, 15 Jul 2008, Alessandro Vesely wrote:

This discussion reminds me that smc_notify_tree() does not actually check 
which thread does a chunk belong to. Could that result in misbehavior?


No, chunks may be freely passed back and forth betwen threads without
problems. Except for a few blocks that fit into 2*magazine_size, all
allocations are shared between all threads anyway.

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

Re: RFC: GProxy, Dynamic Method Invocation

2008-07-02 Thread Tim Janik


On Tue, 1 Jul 2008, Mikkel Kamstrup Erlandsen wrote:


Over the past few weeks I have been pondering a way to add dynamic
method invocation and introspection to GObjects. I am meaning to
implement this myself (unless someone else really want to do it), if
the reception is luke-warm or better :-)

You can find the draft here:
http://live.gnome.org/MikkelKamstrup/GProxyIdea you might want to
follow the links to GPlugin there, but that page is still a bit
messy...

What I would like to discuss is:

* Is this utter insanity?


In your emails and on the wiki pages you say (combined):
- your implementation shouldn't use code generation;
- you don't want to use libffi to call C methods.

How then, do you actually want to implement dynamic method invocations,
given that all you can hope to get from GModule is an opaque function
pointer once a method is found?


Cheers,
Mikkel


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

gtk-doc installation broken

2008-06-23 Thread Tim Janik


Hi Stefan.

gtk-doc continues to produce problems when compiling the gtk.modules module
from jhbuild, this time it's during installaiton:

*** Installing gtk-doc *** [5/14]
make   install
Making install in help
make[1]: Entering directory `/usr/src/gtk+head/gtk-doc/help'
Making install in manual
make[2]: Entering directory `/usr/src/gtk+head/gtk-doc/help/manual'
make[3]: Entering directory `/usr/src/gtk+head/gtk-doc/help/manual'
make[3]: Nothing to be done for `install-exec-am'.
/bin/bash /usr/src/gtk+head/gtk-doc/install-sh -d 
/usr/src/gtk+head/installation/share/gnome/help/gtk-doc-manual/C
/localhome/tjlocal/bin/install-check -m 644 C/fdl-appendix.xml 
/usr/src/gtk+head/installation/share/gnome/help/gtk-doc-manual/C/fdl-appendix.xml
/localhome/tjlocal/bin/install-check -m 644 C/gtk-doc-manual.xml 
/usr/src/gtk+head/installation/share/gnome/help/gtk-doc-manual/C/gtk-doc-manual.xml
/bin/bash /usr/src/gtk+head/gtk-doc/install-sh -d 
/usr/src/gtk+head/installation/share/omf/gtk-doc-manual
/localhome/tjlocal/bin/install-check -m 644 gtk-doc-manual-C.omf 
/usr/src/gtk+head/installation/share/omf/gtk-doc-manual/gtk-doc-manual-C.omf
scrollkeeper-update -p /var/lib/scrollkeeper -o 
/usr/src/gtk+head/installation/share/omf/gtk-doc-manual
/var/lib/scrollkeeper/scrollkeeper_docs: Permission denied
make[3]: *** [install-doc-omf] Error 1
make[3]: Leaving directory `/usr/src/gtk+head/gtk-doc/help/manual'
make[2]: *** [install-am] Error 2
make[2]: Leaving directory `/usr/src/gtk+head/gtk-doc/help/manual'
make[1]: *** [install-recursive] Error 1
make[1]: Leaving directory `/usr/src/gtk+head/gtk-doc/help'
make: *** [install-recursive] Error 1
*** error during stage install of gtk-doc: ## Error running make   
install *** [5/14]


The jhbuild runs as user tjlocal on this system and installs into
a user writable prefix. /var/lib/scrollkeeper/scrollkeeper_docs couldn't
possibly be user-writable in that setup.

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

GSEAL branch merge

2008-06-20 Thread Tim Janik


Hey All.

As discussed during previous IRC meetings:
  http://mail.gnome.org/archives/gtk-devel-list/2008-June/msg00194.html
The GSEAL branch has been merged into upstream today.

At public request, I'm attaching the resulting diff from git to
this email. A similar diff can be retrieved from upstream now with:
  svn diff -r20477:20634

---
ciaoTJ

gseal-r20477-r20634.diff.bz2
Description: gseal-r20477-r20634.diff.bz2
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Offscreen pixmap redirection available

2008-06-18 Thread Tim Janik


Hey All.

The Offscreen redirection rendering bits have been committed to upstream SVN
some while ago:
  Bug 318807 – Offscreen windows and window redirection

Note that the offscreen event processing is not in SVN yet and planned to be
worked on after GUADEC. I'd actually like to discuss some of the event
processing logic bits with other core developers during GUADEC, probably best
during our Gtk+ development BOPF on Tuesday:
  http://guadec.expectnation.com/guadec08/public/schedule/grid?date=2008-07-08

Until then, I'd like to ask everyone with an interest in the offscreen
rendering business (canvas authors, etc.) to scrutinize the current offscreen
rendering implementation and API, ideally by testing gtk_widget_get_snapshot()
for your particular uses. Anything that can be spotted now can be *fixed* now,
i.e. before the next stable Gtk+ realease, so please look into early testing
if at all possible.

/**
 * gtk_widget_get_snapshot:
 * @widget:a #GtkWidget
 * @clip_rect: a #GdkRectangle or %NULL
 *
 * Create a #GdkPixmap of the contents of the widget and its children.
 *
 * Works even if the widget is obscured. The depth and visual of the
 * resulting pixmap is dependent on the widget being snapshot and likely
 * differs from those of a target widget displaying the pixmap.
 * The function gdk_pixbuf_get_from_drawable() can be used to convert
 * the pixmap to a visual independant representation.
 *
 * The snapshot area used by this function is the @widget's allocation plus
 * any extra space occupied by additional windows belonging to this widget
 * (such as the arrows of a spin button).
 * Thus, the resulting snapshot pixmap is possibly larger than the allocation.
 *
 * If @clip_rect is non-%NULL, the resulting pixmap is shrunken to
 * match the specified clip_rect. The (x,y) coordinates of @clip_rect are
 * interpreted widget relative. If width or height of @clip_rect are 0 or
 * negative, the width or height of the resulting pixmap will be shrunken
 * by the respective amount.
 * For instance a @clip_rect literal{ +5, +5, -10, -10 }/literal will
 * chop off 5 pixels at each side of the snapshot pixmap.
 * If non-%NULL, @clip_rect will contain the exact widget-relative snapshot
 * coordinates upon return. A @clip_rect of literal{ -1, -1, 0, 0 }/literal
 * can be used to preserve the auto-grown snapshot area and use @clip_rect
 * as a pure output parameter.
 *
 * The returned pixmap can be %NULL, if the resulting @clip_area was empty.
 *
 * Return value: #GdkPixmap snapshot of the widget
 *
 * Since: 2.14
 **/
GdkPixmap* gtk_widget_get_snapshot (GtkWidget*widget,
GdkRectangle *clip_rect);


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

Re: Steps to get to GTK+ 3.0

2008-06-03 Thread Tim Janik

On Tue, 3 Jun 2008, Alberto Mardegan wrote:

 ext Kristian Rietveld wrote:
 10. Remove all structure fields from the public API.  There are two ways
 this can be done:
   a) Move object structures to private headers.
   b) Move object structures to the local C file, the rest of GTK+ will then
  also have to use accessors.

 If you go for (a), will the private headers be installed in the target
 system?

No, definitely not. private headers here means internal, in that they'll
be accessible only from within the Gtk+ source tree during the gdk and gtk
library builds.

 I've often felt that subclassing a GTK+ widget to modify its
 functionality is usually harder than creating a new widget from scratch
 (copying from the GTK+ code), as accessing the parent private members is
 impossible, and many members that could be useful for a derived class
 are in the private struct.

 I like the Python way of doing it (by mangling the members name you want
 to protect, so the client must really know what he's doing when
 accessing it); I would find it useful if private GTK+ were private but
 somehow accessible (at least from derived classes).

This would essentially make the fields part of our (semi-)public API,
and that in turn means we need to preserve their behaviour compatibly.
This is something we cannot provide and which gets us into much trouble
currently when we try to fix bugs or optimize/improve the current code
base.

However, if instead the public API is defined only in terms of function
entry points (object properties and signals are essentially provided via
functions as well):

- We can add compatibility code to those functions to emulate old
   behaviour on top of a changed code base.

- We can establish a clear migration procedure for any particular feature
   by adding new functions and deprecating old ones.

- We can provide compile time and runtime warnings for deprecated
   functions to aid developers in migration.

 Ciao,
   Alberto

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

Re: questions about g_object_unref.

2008-06-02 Thread Tim Janik

On Sun, 1 Jun 2008, Yu Feng wrote:

 Hi all, not sure if it is appropriate here, but I don't quite understand
 the code in g_object_unref:

 glib-2.16.1/gobject/gobject.c: line:1763
  /* here we want to atomically do: if (ref_count1) { ref_count--;
 return; } */
 retry_atomic_decrement1:
  old_ref = g_atomic_int_get (object-ref_count);
  if (old_ref  1)
{
  if (!g_atomic_int_compare_and_exchange (object-ref_count,
 old_ref, old_ref - 1))
goto retry_atomic_decrement1;


 How does the code achieve the goal stated in the comments? It seems to
 me that the code will loop at retry_atomic_decrement1 untill old_ref ==
 1?

no, it loops until object-ref_count == old_ref-1, which implements
the functionality outlined in the comment. you possibly want to read
up on g_atomic_int_compare_and_exchange() and maybe CAS (compare-and-swap)
algorithms in general.

 Yu

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

Re: My commit to glib and gtk+ - Bug #503071

2008-05-20 Thread Tim Janik

On Tue, 20 May 2008, Yair Hershkovitz wrote:

 Hi,

 For those who are still not familiar with the issue, you have a lot to
 read in bug #503071 comments.

 I would like to explain my view of the un-allowed commits I've done in
 glib and gtk+.

Thanks for the patch and your input Yair, but for glib and gtk+ we have
fairly simple rules, patches need review and approval before they can go
in. The changes are reverted now, please use patch submission as future
means for getting changes into GLib and Gtk+ like everyone else does.

If you're not satisfied with our current processing speed and maintenance
situation, please consider:
   http://blogs.gnome.org/timj/2008/05/16/16052008-becoming-a-gtk-maintainer/

 Thanks for reading,
 Yair.

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

Fixing 32/64 bit semantics of long (Re: GLib and 64-bit Windows)

2008-04-23 Thread Tim Janik

On Wed, 30 Jan 2008, Owen Taylor wrote:

 I'm not sure what you you are asking here. What I was saying is that
 changing vtable members is more likely to break things than changing
 function prototypes.

Ok, but then, every prototype change can be a vtable change, given a
custom vtable that has a slot expecting a certain glib API function type,
as in the g_realloc() pointer example.
(Yes, i realize that you were referring only to vtables exported by glib ;)

 if i understand you correctly, you mean to imply that we also fix the
 signatures from *long to *size as well for the following functions
 (comprehensive list of *long API in glib/glib/*.h):


 gdouble  g_timer_elapsed (GTimer  *timer,
gulong  *microseconds);
 [...]

 No, I didn't mean that, because

 gdouble  g_timer_elapsed (GTimer  *timer,
   size_t  *microseconds);

 gulong microseconds;

 g_timer_elapsed(timer, microseconds);

 Will warn in many many situations on many platforms, and MSVC will warn
 about:

 gsize g_utf8_strlen (const gchar *p,
  gssize   max);

 long value = g_utf8_strlen(p, max);

 even when compiling for 32 bits. So I don't consider changing out
 parameters and returns from long = size_t compatible.

H...

I think it makes sense to distinguish between changing long value
types and *long pointer types. The former is unlikely to
cause major breakage. The exception being custom vtables that
expect particular prototypes in GLib and possibly return type size
warnings (though a case can be made for wanting those
warnings i think).

We currently have these semantics for GLib types wrg 32/64bit
portability:

gint32  - 32bit on all platforms
gint64  - 64bit on all platforms
glong   - 32bit on 32 bit platforms  Win64, 64bit on 64 bit platforms
gsize   - 32bit on 32 bit platforms, 64bit on 64 bit platforms
ptrdiff_t   - 32bit on 32 bit platforms, 64bit on 64 bit platforms

That is, glong is pretty much useless. If a type is needed
that reliably widens size on 64bit system (usually needed
to store pointer values or larger memory offsets/sizes),
we actually have to use gsize.

These are the possibilities i see to solve this:

1) Define glong to ssize_t on Win64. This'll break the
assumption that long==glong on all platforms though.

2) Search+replace our headers for glong - gssize (i.e. what
i suggested in my previous email).

3) Introduce a new type, e.g. gwide/guwide:
#ifdef _WIN64
  typedef ssize_t gwide;
  typedef size_t  guwide;
#else /* !_WIN64 */
  typedef glong  gwide;
  typedef gulong guwide;
#endif
Then search+replace our headers for it, i.e. glong - gwide.
This preserves long-ness on all currently existing platforms,
and still allows the repsective API for Win64 to be 64bit wide.

Further notes:

- Deprecate usage of long/glong in public headers. This should
   be part of our policy in any case. Long simply has unclear
   semantics, gint32/gint64/gsize have clear semantics wrt to
   32bit/64bit platforms.
   Deprecate use of gwide in favor of gint32/gint64/gsize, this
   type is only needed in places where we used to have glong in
   public API for historical reasons.

- When i say search+replace, i'm including the types used in the
   G_TYPE_LONG API, e.g. g_value_set_long().
   Changing glong-gssize or glong-gwide there might look surprising,
   but provides clear calling semantics.
   In retrospect, i shouldn't have added support for longs to GType
   in the first place...

Out of the above, i think (1) provides potentially bad pitfalls,
because it's surprisingly inconsistent with other glib types.

The ideal solution might be (2), and i think it's worth putting it
into place in a future devel branch of GLib, with the option of
falling back to (3) if (2) turns out to cause bad breakage in
practice. I.e. (3) might be needed anyway for long pointer types
as you pointed out above, but that's the minority of API changes
(11 out of 57).

Functions with long pointers:
g_timer_elapsed
g_utf8_to_utf16
g_utf8_to_ucs4
g_utf8_to_ucs4_fast
g_utf16_to_ucs4
g_utf16_to_utf8
g_ucs4_to_utf16
g_ucs4_to_utf8
gdk_colors_alloc
gdk_colors_free
GdkEventClient

Functions/structures with long arguments and return values:
GHookList
g_hook_destroy
g_hook_get
G_STRUCT_OFFSET
G_STRUCT_MEMBER_P
GOptionEntry
g_thread_create_full
g_usleep
g_time_val_add
GTimeVal
g_utf8_offset_to_pointer
g_utf8_pointer_to_offset
g_utf8_strlen
g_snprintf
g_vsnprintf
g_bit_nth_lsf
g_bit_nth_msf
g_bit_storage
g_signal_connect_object
g_param_spec_long
g_param_spec_ulong
GParamSpecLong
GParamSpecULong
g_signal_add_emission_hook
g_signal_remove_emission_hook
g_signal_connect_closure_by_id
g_signal_connect_closure
g_signal_connect_data
g_signal_handler_block
g_signal_handler_unblock
g_signal_handler_disconnect
g_signal_handler_is_connected

Re: recurrent spam from applications developers [was: GtkListStore with GtkBuilder]

2008-04-22 Thread Tim Janik

On Tue, 22 Apr 2008, Guillaume Cottenceau wrote:

 How about renaming gtk-devel-list into gtk-core-library-devel or
 something like that?

Renaming the list would definitely take it too far,
some noise will always be present and the current off
topic emails are by no means at a critical volume.

 Also, on http://gtk.org/mailing-lists.html:

 This list is for developers of GTK+ to discuss code. General GTK+
 questions should not be asked on this list, as that is more
 appropriate for gtk-app-devel-list.

 =

 This list is for developers of the bcore/b GTK+ library to discuss
 GTK+ implementation. GTK+ applications development, and general GTK+
 questions, should bnot/b be asked on this list, as that is more
 appropriate for gtk-app-devel-list.

Thanks, i've integrated this into the list info here:
   http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Martyn, i'd be nice to have the website updated accordingly as well.

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

Re: Move to LGPL3

2008-03-16 Thread Tim Janik

On Sun, 16 Mar 2008, Bastien Nocera wrote:

 On Sat, 2008-03-15 at 21:48 +0100, Tim Janik wrote:

 Our headers currently state:
   * This library is free software; you can redistribute it and/or
   * modify it under the terms of the GNU Lesser General Public
   * License as published by the Free Software Foundation; either
   * version 2 of the License, or (at your option) any later version.

 The LGPL also says:
  To protect your rights, we need to make restrictions that forbid
 anyone to deny you these rights or to ask you to surrender the rights.

 Which means you can't add more restrictions to the license without
 effectively relicensing.

We're not retro-changing the license of anything that has been
released already, so we're not restricting rights anyone already
has.
We're talking about modifying  redistributing future versions
of GLib  Gtk+ under LGPLv3, which the license clearly allows.

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

Re: Move to LGPL3

2008-03-15 Thread Tim Janik

On Sat, 15 Mar 2008, Andrew Cowie wrote:

 This topic was discussed recently on foundation-list.

 http://mail.gnome.org/archives/foundation-list/2008-March/msg00032.html

 In summary, attempting to relicence the library would be, in practise,
 impossible.

 No further benefit is gained by discussing this topic further.

Updating the glib  gtk+ headers to LGPLv3 is not relicensing.

Our headers currently state:
  * This library is free software; you can redistribute it and/or
  * modify it under the terms of the GNU Lesser General Public
  * License as published by the Free Software Foundation; either
  * version 2 of the License, or (at your option) any later version.

So, everone is allowed to redistribute [...] under the terms of the
GNU Lesser General Public License [...] version 2 [...] or [...] later,
which LGPLv3 fullfills.

Accepting LGPLv3 submissions in the future means that the library
as a whole would effectively become LGPL = 3 licensed.
So then, we might as well adapt our headers to reflect this.

 AfC
 Berlin

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

Visions from the hackweek

2008-03-14 Thread Tim Janik

Hello Gtk+ Crowd.


Together with Sven Herzberg, I'm currently sitting in an ICE back
to Hamburg and would like to thank everyone for a really productive
week. I think, i couldn't possibly list all the achievements of the
various groups during these days, but thankfully some people have
promised to send short summaries of sessions they attended ;)
(We'll try to put more emphasis on note taking and/or recording
when we do this again.)

Monday morning we started out with a presentation of future visions
around the Gtk+ project and possible ways to enabling them.
We much appreciate the positive feedback we already got in response
and tried to channel that into a document to fill in details about
the presentation:
   
http://developer.imendio.com/sites/developer.imendio.com/files/imendio-gtk-vision.pdf
Original slides:
   http://inverted-tree.livejournal.com/58280.html

Further comments are of course welcome, we intend to keep the
document updated as new issues are raised/solved.

Again, big thanks to everyone contributing to a productive week,
especially the organizers and also sponsors that enabled us to
get together and prepare the future of the toolkit that is vital
for so many projects out there.
I sincerely hope we'll manage to realize all the constructive
plans we came up with during this. ;)

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

Re: Gtk demo look and feel

2008-03-07 Thread Tim Janik

On Fri, 7 Mar 2008, Alberto Ruiz wrote:

 Hi all,
 now that we have a new Gtk+ logo and we follow the Tango guidelines,
 wouldn't be a good time to replace the so '90s-ish images from the demo?

 On my last blogpost[0] I demoed the Gdi+ pixbuf loader animation support
 with new images using the Gtk+ logo and tango icons.

 Would it be okay to commit this stuff into trunk?

can you please file a bug report with the patch attached, so
this can go through normal review like everything else?

 [0] http://aruiz.typepad.com/siliconisland/2008/03/gtk-foo.html
 --
 Cheers,
 Alberto Ruiz


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

visible window rectangle in pixmap redirection

2008-02-12 Thread Tim Janik

hi Alex.

it'd be great if you could take a look at my latest comment on the
offscreen windows bug report, i.e.:
   http://bugzilla.gnome.org/show_bug.cgi?id=318807#c48

it adresses just the pixmap redirection portions that you split off
some while ago and lists remaining issues that need solving before
inclusion.
in particular, i'd like to know:

- gtk_widget_get_snapshot() is supposed to snapshot whole widgets
   (i.e. all of widget-allocation.width/height).
   so why is gdk_window_end_paint() calling
   _gdk_window_calculate_full_clip_region() (indirectly via
   setup_redirect_clip()) to constrain the redirected area
   to the visible widget area?

- why is _gdk_windowing_window_get_visible_rect() a backend specific
   function? couldn't we get the visible rectangle of a window from
   window-parent-width/height and window-x/y?

- i'm wondering if there is a use case at all for snapshooting *only*
   the visible area of a widget. i think the semantics of
   gtk_widget_get_snapshot() are fine if it snapshoots all of a widgets
   allocation, and i'd like to get rid of all the clip-to-visible-rect
   logic. if there is indeed a use case for snapshoting only the
   visible portion of a widget (afaics relevant in scrolled window
   contexts only), we should be able to simply provide:
 void gtk_widget_get_visible_rect (Widget*, Rect*);
   that provides coordinates for use with gtk_widget_get_snapshot().

thanks for the patch in the first place. i think the above are the last
major issues left before pixmap redirection can go in.

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

Re: GTK+ Website Review - Hosting Windows Binaries

On Thu, 24 Jan 2008, Shawn Amundson wrote:

 Martyn Russell wrote:

 no sysadmins seems to be stepping forward regarding this.

 As a result, this will have to wait.


 I'm willing to do whatever it takes to help improve gtk.org.  As
 such, I will provide my services as sysadmin.

thanks, that's much apprechiated, especially as the hardware/space situation
on gtk.org is becoming worse and worse (we're aware of HW resource shortages
for probably 3 years now, and they have been increasing).

 I think a CMS is an excellent idea.  Are there any opinions on
 what would be the best solution?  How about drupal?

i think we should approach this incrementally. i.e. it's probably best to:

1) get the new web design in place that Andreas and Martyn have been
working on.

2) setup a cloned web site on cube. (i'll drop you a line when i have time
to look into replicating the web installation setup there.)

3) switch over DNS.

4) look into any future extensions like CMSes. (currently we're fine with
using live.gnome.org, so we don't have any urgent issues to fix here.)

 Mid-march will be gtk.org's 10th birthday!

;-)

 -Shawn

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

Re: GTK+ Website Review - Final Draft

On Mon, 28 Jan 2008, Olav Vitters wrote:

 On Mon, Jan 28, 2008 at 02:30:14PM +, Martyn Russell wrote:
 http://imendio.com/~martyn/gtk/draft-final/download-linux.html
  * outdated versions

 You disagree? It might not make sense to list unsupported versions here
 I agree, but we should definitely list older versions.

 No, I mean that it doesn't show e.g. 2.12. Don't mind about older
 versions.

 http://imendio.com/~martyn/gtk/draft-final/documentation.html
  * under API, perhaps s/Library/Component/ or something?

 I prefer Library, since they are libraries.

 Shouldn't Library be used for the collection of API docs? IMO gtk+ has
 e.g. an API reference. The combination of all that stuff could be called
 a library.

gtk.org already links to library.g.o for API docs, it also redirects
faq and tutorial2.0 accesses to library.g.o now.

we still have a static version of the tutorial1.2 there though, because
it's not provided by library.g.o.

what is most unfortunate is that library.g.o only has glib development
docs, but not gtk development docs. having development docs readily
available is fairly important to talk about new stuff and get reviewers
interest. (building those can easily be automated via buildign the
gtk+.module jhbuild module.)

 -- 
 Regards,
 Olav

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

Re: GLib and 64-bit Windows

On Mon, 5 Mar 2007, Owen Taylor wrote:

 On Mon, 2007-03-05 at 12:21 -0500, Jake Goulding wrote:

 goption.c(994) : warning C4267: 'function' : conversion from 'size_t' to
 'gulong', possible loss of data
 change-allocated.array.data = g_renew (gchar *,
 change-allocated.array.data, change-allocated.array.len + 2);

 And more. It sure looks like most of them have to do with the allocation
 functions, which all seem to take ulongs as opposed to size_t.

 Hmm. I think in terms of gmem.h we probably should try to fix the
 ulong/size_t situation. There is currently no ABI for GLib/Win64, so we
 don't have to worry about a binary compatibility issue with changing the
 prototype. And on all other platforms I know of gsize and ulong are the
 same size.

agree. this exact API was actually written with sizeof(long)==8 on 64-bit
platforms in mind:

2008-01-29 14:58:31  Tim Janik  [EMAIL PROTECTED]

 * glib/gmem.[hc]: changed size argument type from gulong to gsize as
 discussed on gtk-devel-list:
   
http://mail.gnome.org/archives/gtk-devel-list/2007-March/msg00062.html
 this should be ABI compatible on all platforms except win64 for which
 no ABI binding port exists yet.

 There *are* platforms where gssize is an unsigned integer rather than an
 unsigned long, but my general feeling is that just changing the gmalloc
 prototypes is unlikely to cause problems; GMemVTable, which would be
 more likely to cause warnings already has gsize there.

i suppose you mean gsize (which is always unsigned), because gssize is
always signed.

 There are going to be other situations however, where the fix isn't so
 obvious.

 - When 64-bit proofing the Unicode string bits of GLib (years ago)
   I took the policy that:

- Counts of bytes were sized as gsize
- Counts of items sized larger than a byte are longs

   because it seemed very strange to me to use size_t for non-byte
   counts.

C++ does this all the time though (also calls it's .get_number_of_elements()
methods .size()), so you get used to it after a bit of STL fiddling.

   But that means that something like the return value from
   g_utf8_strlen() is wrong for win32. This can't be changed in a
   source-compatible fashion.

   Probably the right thing to do for g_utf8_strlen() is to compute
   things internally as 64-bit, then clamp the result to 32-bits
   on return. Without the clamp:

 long size = g_utf8_strlen(str);
 gunichar chars = g_new(gunichar, size);
 for (char *p = str, gunichar *c = chars; *p; p = g_utf8_next_char(p)) {
 *c = g_utf8_get_char(p);
 }

Is a potential buffer overflow, though a hard one to trigger.
(Actually, it's a potential overflow currently for 32-bits. We really
should make g_new0() not a g_malloc()-wrapping macro so we can protect
the multiplication.)

if i understand you correctly, you mean to imply that we also fix the
signatures from *long to *size as well for the following functions
(comprehensive list of *long API in glib/glib/*.h):


gdouble  g_timer_elapsed (GTimer  *timer,
   gulong  *microseconds);
void g_usleep(gulong   microseconds);
void g_time_val_add  (GTimeVal*time_,
   glongmicroseconds);
gchar*   g_utf8_offset_to_pointer (const gchar *str,
glongoffset) G_GNUC_PURE;
glongg_utf8_pointer_to_offset (const gchar *str,
const gchar *pos) G_GNUC_PURE;
glong g_utf8_strlen (const gchar *p,
  gssize   max) G_GNUC_PURE;
gunichar2 *g_utf8_to_utf16 (const gchar  *str,
 glong len,
 glong*items_read,
 glong*items_written,
 GError  **error) G_GNUC_MALLOC;
gunichar * g_utf8_to_ucs4  (const gchar  *str,
 glong len,
 glong*items_read,
 glong*items_written,
 GError  **error) G_GNUC_MALLOC;
gunichar * g_utf8_to_ucs4_fast (const gchar  *str,
 glong len,
 glong*items_written) 
G_GNUC_MALLOC; 
gunichar * g_utf16_to_ucs4 (const gunichar2  *str,
 glong len,
 glong*items_read,
 glong*items_written,
 GError  **error) G_GNUC_MALLOC;
gchar* g_utf16_to_utf8 (const gunichar2  *str,
 glong len,
 glong*items_read

Finally gtk.org gets a face lift (fwd)

-- Forwarded message --
Date: Tue, 29 Jan 2008 18:59:21 +
From: Martyn Russell [EMAIL PROTECTED]
To: Gtk+ Developers [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Finally gtk.org gets a face lift

Hi,

I started working on the new design for gtk.org last April and tonight
the new pages were uploaded and we now have a spiffing new look which I
am really happy with.

I want to thank Andreas Nilsson for helping out with the design and Tim
Janik for help with the final touches in getting the pages installed,
not to mention everyone who commented.

   http://www.gtk.org/

Enjoy :)

-- 
Regards,
Martyn
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list

Re: using jhbuild and gtk+ branches

2008-01-25 Thread Tim Janik

On Fri, 25 Jan 2008, Dr. Michael J. Chudobiak wrote:

 Hi all,

 Could someone explain to me how exactly people work on bleeding-edge
 gtk+ (trunk)?

 Reading the gtk+ Changelog shows that people are working on trunk, and
 merge back into 2-12 as needed. Are developers tweaking their own
 moduleset to pull in gtk+ trunk, or using a different moduleset (is
 there an all-trunk one?), or some other approach?

we just use the gtk+ module set. it doesn't build gnome, but gtk+ trunk:
modules = [ 'gtk+' ]


 Thanks for any guidance...


 - Mike

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

Re: weakref semantics

2008-01-17 Thread Tim Janik

On Thu, 17 Jan 2008, Alexander Larsson wrote:

On Wed, 2008-01-16 at 15:03 +, [EMAIL PROTECTED] wrote:
I noticed the weakref introduction says that notifies can be called many
times:

http://library.gnome.org/devel/gobject/unstable/gobject-memory.html#gobject-memory-weakref

... which is invoked when the object runs its dispose method. As such,
each weak ref can be invoked more than once upon object finalization
(since dispose can run more than once during object finalization).

I'm not sure this is right: looking at the source for gobject it seems
that the notifies are a fire-once thing, and are removed upon firing.

Should I open a docs bug on this? (or am I confused?)

you mis the facts that new weak refs can be added at any point in time,
such as after dispose, in finalize or even during weakref notifies.
(that's actually the semantics of GObject's GData mechanism which
is used to implement weakrefs)

I actually have a related question. I remember that weak refs weren't
allowed to ressurect the object. However, with the weak ref callbacks
running from dispose, and dispose being allowed to ressurect the object,
why can't weak refs ressurect?

because weakrefs will also run during finalization, and an object
can not be resurrected from finalization.

Maybe weak ref callbacks should be moved to finalization?

conceptually yes. regarding backwards compatibility, no.

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

Re: weakref semantics

2008-01-17 Thread Tim Janik

On Thu, 17 Jan 2008, Yevgen Muntyan wrote:

 Alexander Larsson wrote:
 On Thu, 2008-01-17 at 07:50 -0600, Yevgen Muntyan wrote:

 A GWeakNotify cid:part1.03020602.08010607@tamu.edu function can be added 
 to an object as a
 callback that gets triggered when the object is finalized.
 Since the object is already being finalized when the
 GWeakNotify cid:part1.03020602.08010607@tamu.edu is called, there's not 
 much you could do with
 the object, apart from e.g. using its adress as hash-index or the like.
 
 I have never seen the docs quoted in the original mail,
 and what docs say about g_object_weak_ref() implies
 that weak ref callback is called 1) exactly once; 2) after
 the object is finalized (and so I got some code which
 supposes that the callback is called exactly once). So
 what is the truth? Possibly more than once, and before
 finalize()?
 
 
 Only once (per time you register it), 

 But it contradicts with As such, each weak ref can be invoked more
 than once upon object finalization (since dispose can run more than
 once during object finalization).

that's bogus. each installed weakref can only ever be called once, just
like GData destroy handlers.
also, dispose is never called *during* finalization, the docs should
say dispose can run more than once before object finalization.

 But is consistent with what John
 said.

 So, two docs bugs?

yep.

 Best regards,
 Yevgen

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

Re: GIcon thoughts

2008-01-14 Thread Tim Janik

On Thu, 10 Jan 2008, Alexander Larsson wrote:

 On Wed, 2008-01-09 at 13:53 -0500, Matthias Clasen wrote:

 We can't implement the cache using toggle references for 2 reasons:
 a) GtkIconSize is a boxed, not an object
 b) toggle references only work for a single user, thus they have
to be reserved for bindings, at least bindable objects.
 I propose to instead turn GtkIconInfo into a refcounted boxed object,
 and then implement the caching logic for the case that the refcount
 drops to one.

 I'm not sure this is enought, cache-wise. In many cases you'd get a
 GtkIconInfo, then get the pixbuf for that, save the pixbuf (e.g. in a
 widget) and unref the info. In fact, it seems unlikely that apps would
 keep the GtkIconInfo alive for long periods of time. It would be nice if
 we could get the GtkIconInfo cached until the last ref is dropped to the
 pixbuf.

sounds like you should simply keep a reference count from the pixbuf onto
the corresponding GtkIconInfo. using object data for instance.

 Of course, this is slightly harder, as GdkPixbuf is a public GObject
 where we can't use toggle references. We could however implement this
 with some help from the GdkPixbuf implementation. For instance, if we
 add a resurrect signal to GdkPixbuf and have the dispose()
 implementation emit this then the cache could connect to this and grab a
 ref (for some time) before finalization. (The dispose call must also
 detect that the object is ressurected and avoid chaining to dispose.)

you're not free to skip chaining in dispose() implementations (just
like you aren't free to skip chaining in finalize() or anywhere else).
adding a reference count in dispose is enough to resurrect an object
though, so just do ref(self); in dispose() but don't forget to chain up.
this'll prevent finalization (finalize() is only called for objects with
ref_count==0).

 That might be useful for other pixbuf caches too.

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

Re: GIcon thoughts

2008-01-14 Thread Tim Janik

On Mon, 14 Jan 2008, Alexander Larsson wrote:

 On Mon, 2008-01-14 at 10:12 +0100, Tim Janik wrote:

 Of course, this is slightly harder, as GdkPixbuf is a public GObject
 where we can't use toggle references. We could however implement this
 with some help from the GdkPixbuf implementation. For instance, if we
 add a resurrect signal to GdkPixbuf and have the dispose()
 implementation emit this then the cache could connect to this and grab a
 ref (for some time) before finalization. (The dispose call must also
 detect that the object is ressurected and avoid chaining to dispose.)

 you're not free to skip chaining in dispose() implementations (just
 like you aren't free to skip chaining in finalize() or anywhere else).
 adding a reference count in dispose is enough to resurrect an object
 though, so just do ref(self); in dispose() but don't forget to chain up.
 this'll prevent finalization (finalize() is only called for objects with
 ref_count==0).

 Why is that forbidden? You can resurrect things by grabbing a ref, yes,
 but if you then chain up it'll free things like user data, etc, which we
 don't want in the case of a cache.

because code can do stuff like:

this-foo = acquire_resource();
class-release_resource (this);

where foo, acquire_resource, release_resource can be arbitrary names
of course, e.g. dispose.
if you break the assumption that some_class_real_method() is always being
called when class-method() is being called (either directly or via
chaining), you'll break random code portions.
(ancestor classes need to be able to make *some* assumptions about an object
in order to be implemented, and method calls working correctly is one
very fundamental assumption.)

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

Re: API break request for file monitoring

2008-01-14 Thread Tim Janik

On Mon, 14 Jan 2008, Alexander Larsson wrote:

 This bug:
 http://bugzilla.gnome.org/show_bug.cgi?id=508564

 requests and addition of a GError to g_file_monitor_directory and
 g_file_monitor_file.

 Its imho, correct, but does break API which some users have started
 using. I'd like to change this, but I'm not sure if that is acceptable
 at this point.

feel free to break API and ABI all the way throughout development versions,
as long as the next stable branch ist ABI and backwards compatible with
the last stable branch.
after all, that's what development releases are for (and what they are
named after, so no user can complain about interface breakage as long as
it's in *development*).

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

Re: dedicated machine for gtk.org website project

On Wed, 9 Jan 2008, Shawn Amundson wrote:

 Olav Vitters wrote:
 On Wed, Jan 09, 2008 at 09:25:16AM +, Martyn Russell wrote:
 I must confess, I have quite limited knowledge when it comes to our
 hosting services for GNOME and GTK+ (i.e. where machines are hosted
 physically and who looks after them, etc - is this information available
 somewhere?). Perhaps some sysadmins could comment here too.

 Probably known but in case not (from gnome-sysadmin POV): GTK does most
 things for themselves. Machines, website, DNS, mail, etc etc. The only
 slight relation is the SVN repository for the website and its
 post-commit hook to trigger an update of the site.


 Yes, but it does not have to remain that way.

 Perhaps cube.gtk.org should run the gtk.org resources but with
 the assistance of the gnome-sysadmin team.  Or maybe gtk.org should
 just be completely absorbed into gnome-sysadmin's existing
 infrastructure.

since it doesn't look like the gtk.org hardware is going to be updated
anytime soon, moving the gtk.org domain to another machine definitely
should be considered.
anything else than just moving the current content, like changing the
current sysadmin structure and/or integrating it into gnome sysadmin's
hosting sounds like it will require planning and some kind of migration
plan though. i.e. someone volunteering to do that.

 -Shawn

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

Re: GLib test framework for your own project

On Wed, 9 Jan 2008, Tommi Komulainen wrote:

 Hi,

 Here's a quick guide for setting up GLib testing framework for your own
 project. It is the result of some trial and error when integrating for
 hildon widgets the test framework from current trunk. There are some
 autotools related details that might not be immediately obvious for mere
 mortals. Thought it good to collect the details in one place. Hope it
 helps.

thanks for doing that.

 1. Copy Makefile.decl

[glib or gtk+ currently does not install any usable
Makefile.decl]

yeah, i was thinking about that when i wrote it.
once the current testing rules have stabelized and turn out to be
actually useful for testing glib/gtk+, it could make sense to install
a Makefile.gtkrules or similar for other projects to include that
provides the rather complex test framework rules. 
it'll be a bit tricky to include that though, given that the include
paths may vary. an alternative could be to provide the rules in an
automake macro, setup by AM_PATH_GTK_2_0().

Copy Makefile.decl from glib or gtk+ source directory to the
root directory of your project. The difference is that
Makefile.decl from gtk+ will run the tests in Xvfb and thus only
works for x11 backend.

right, for non-X11 targets, the tests will currently be skipped.
if people can provide alternatives to Xvfb for non-X11 platforms to
hide GUI program execution, that'd be much apprechiated.

Edit Makefile.decl so that GTESTER and GTESTER_REPORT are
correct for non-GLIB packages:

GTESTER= gtester# in $PATH for non-GLIB 
 packages
GTESTER_REPORT = gtester-report # in $PATH for non-GLIB 
 packages


When using Makefile.decl from gtk+ also add the following line
after GTESTER_REPORT. This is needed for properly starting Xvfb
for the test.

gdktarget := $(shell pkg-config --variable=target gdk-2.0)

good point. however $(shell) is a GNU-make-ism, so for projects that
need to be portable across GNU-make, it might be good to provide
@GTK_GDKTARGET@ by AM_PATH_GTK_2_0().

 2. Edit every Makefile.am

Add the following line to the top of every Makefile.am. This is
needed to enable recursive 'make test' and friends.

include $(top_srcdir)/Makefile.decl

one word about recursion here.

gtk+/Makefile.decl currently ignores and won't recurse into subdirs
with the names po or po-properties. this may or may not be appropriate
for other projects (it usually is though, because po/Makefile.in is usually
not under the project maintainers control, and so is hard to extend for
additional recursive rules).

 4. Write src/tests/testwidget.c

Make sure your normal build flags do not include -DG_DISABLE_ASSERT
(or add #undef G_DISABLE_ASSERT at the top of the file) as it will 
 disable
all checks using g_assert() -- though not any of g_assert_cmp*()

[See some other tutorial and API reference for how to organize
the C code and which functions/macros to use. Currently glib
trunk does not generate any documentation for the testing
framework.]

hm, right. the API docs are there in glib/glib/gtestutils.c, but nothing
is generated for the web atm. will have a look.

 5. Run the tests

$ make test

When running in emacs/vim the first failing test should be
recognized and the cursor should be placed on the line of
failing assertion.

[See some other tutorial/reference for how to run tests more
fine grained (./testwidget -p /foo, ./testwidget --help?)]

gtester --help works. test programs currently do not provide a --help
output, because they are programs in their own right. they do interpret
a bunch of options though, such as --g-fatal-warnings, -p=path, -m=mode,
-q, --quiet, --verbose, -l, --seed=randomseed, all of which correspond
to the respective gtester options, described by gtester --help.

given that g_test_init() parses all these args and that test programs
are unlikely to implement sophisticated argument parsing and --help
themselves though, it's probably best to hard code --help output into
g_test_init()...

 -- 
 Tommi Komulainen[EMAIL PROTECTED]

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

Re: Comments on glib testing framework

On Wed, 9 Jan 2008, Tommi Komulainen wrote:

 Hi,

 make -k test probably shouldn't abort gtester on first failing assertion

hm, currently, we have these test framework makefile rules:
test:   run all tests recursively, abort on first error
test-report:run tests in subdirs, generate report, continue on error
perf-report:run tests like test-report, include performance tests via -m 
perf
full-report:like test-report, include all tests with -m perf and -m slow

so if you want to run tests and not abort, you're probably looking for
test-report:. one rule needs to be there to abort immediately for developers
to trace test failures, and currently that is test:.
i wouldn't know of a portable way to detect make -k invocations to make
the test: rule behave differently. and, is there really a need for that,
given that you could run test-report: instead?


 glib/gtestutils.h references g_object_unref() which requires gobject.

this is hidden in a macro ;) i.e.:
   #define g_test_queue_unref(gobject) g_test_queue_destroy (g_object_unref, 
gobject)

so if you use g_test_queue_unref() on a GObject, you usually need to have
glib-object.h included already, and g_test_queue_unref() will work without
problems.
(i guess one could argue for g_test_queue_unref() to be moved to a gobject/
header for cleanliness, but then we'd have to find a proper place for it,
and probably have documentation splits as well...)

 It would be nice to have g_assert_cmpenum and g_assert_cmpflags to
 pretty print the name of enum/flags rather than plain numerical value
 (See example code for cmpenum attached, needs to be in gobject.) For
 example:

assertion failed (mode == GTK_SIZE_GROUP_HORIZONTAL): (3 
 (GTK_SIZE_GROUP_BOTH) == 1 (GTK_SIZE_GROUP_HORIZONTAL))

hm, it looks a bit cumbersome to use, since you always need to provide
to correct enum type id as well:
   g_assert_cmpenum (mode, ==, GTK_SIZE_GROUP_BOTH, GTK_TYPE_SIZE_GROUP_MODE);

judging from other gtk code errors, those type ids are easily gotten wrong
if unchecked, and in your implementation, the type id is used very seldomly,
i.e. only if the actual assertion fails...

also, g_assert_cmpint() will already provide a lot of information (in
particular the stringified assertion macro arguments):
   gint mode = GTK_SIZE_GROUP_HORIZONTAL;
   g_assert_cmpint (mode, ==, GTK_SIZE_GROUP_BOTH);
generates
   ** ERROR:(testing.c:195):main: assertion failed (mode == 
GTK_SIZE_GROUP_BOTH): (1 == 3)

i guess you're mostly aiming for cases where both macro arguments are
variables?

 While we are on this topic, does it make sense to add something like
 g_enum_get_name (GType, gint)? The g_enum_* functions can be used to do
 this, but are a bit cumbersome to use.

this has been raised a lot of times. there's one thing to keep in mind
here, like all other types, enum classes may be implemented by a plugin
that needs to be dlopen()ed. so strings provided by the enum class will
not neccessarily persist in memory, i.e. g_enum_get_name() can not return
a const char* but would have to g_strdup() the returned string.

and, adding such API will hide the fact that classes my need to be loaded,
which can lead to code like:
   gchar *name = g_enum_get_name (GTK_TYPE_SIZE_GROUP_MODE, 
GTK_SIZE_GROUP_BOTH);
   gchar *nick = g_enum_get_nick (GTK_TYPE_SIZE_GROUP_MODE, 
GTK_SIZE_GROUP_BOTH);
   gchar *blurb = g_enum_get_blurb (GTK_TYPE_SIZE_GROUP_MODE, 
GTK_SIZE_GROUP_BOTH);
   g_print (enum value: name=%s nick=%s blurb=%s\n, name, nick, blurb);
   g_free (name);
   g_free (nick);
   g_free (blurb);
which looks harmless, but behind the scenes does
   dlclose (dlopen(EnumPLugin.so));
3 times.

 gtk_test_create_widget is nice, but unfortunately won't be usable in the
 cases where a widget does more than a g_object_new call in its _new
 function (GtkSpinButton, text variants of comboboxes, GtkAspectFrame,
 any other third party widget, ...). Maybe not too important, but worth
 noting.

widgets that do more than g_object_new() in their _new() functions are
broken and need to be fixed to provide the functionality of all
_new(arguments) through the GObject property interface.
(they are also problematic for gui builders, docu generation and
language bindings).

 gtk_test_teardown. See bug #507256

 There are two technologies that could help in the creation of testcases:
  * A way to record a series of events and replay them at will.
(Already exists?)

yeah, Gerd (Gtk+ Event Recorder) does this:
   http://testbit.eu/~timj/historic/gerd/
the code is faily old though (2000), and with Gtk+/Gdk's infrastructure
will also work on X11 only.

  * A way to record either the static aspect (screenshot) or an
extended period of time (video, or series of images matched with
a checkpoint) and compare it against a pre-defined image/video.

this has been implemented in a spun off of Gerd by some solaris people
a couple years ago. doing pixel-by-pixel comparisons has some

Re: Test Framework


On Wed, 2 Jan 2008, Asbjørn wrote:


I'm checking out the Test Framework and here is my first test program:

glib/glib/tests/testingbase64.c

Output:
TEST: testingbase64... (pid=15393)
 /misc/base64/encode: OK
 /misc/base64/decode: OK
 /misc/base64/encode_decode:  OK

It's based on tests/base64-test.c .


thanks, added to SVN with coding style fixes.
can you please provide your full real name for the copyright line?

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

Re: I'd like to contribute

2007-12-29 Thread Tim Janik

On Fri, 28 Dec 2007, Cody Russell wrote:

 On Fri, 2007-12-28 at 18:35 -0800, Bobby Walters wrote:
 I would like to contribute a little to the project. Is there anything
 I could do? Let me know how to get started, and who to talk to please.

 Hey Bobby,

 Welcome!  Maybe start off by letting us know more of what kind of work
 you're interested in doing.  If you're interested in programming, the
 best thing to do is to start off by searching through Bugzilla [1] for
 bugs to work on fixing.  Or better yet, you might look at the GtkLove
 bug list [2] for starting places.

 You could also work on documentation or test/demo programs.  Maybe
 someone else can give a better idea of where to get involved with that.

here's a page with a list of contributor task descriptions:
   http://live.gnome.org/GtkTasks


 [1]. http://bugzilla.gnome.org/buglist.cgi?query=product%3Agtk%2B
 [2]. http://live.gnome.org/GtkLove

 Cheers,
  Cody

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

Test reports and commit policies

2007-12-20 Thread Tim Janik

Hey All.

A quick update on the unit test reports, a script for test report
generation has now been comitted to GLib and will be used to generate
HTML reports for the test report rules test-report, perf-report and
full-report.
The reports should render in all browsers and support colorization and
collapsed/popup details for CSS and javascript enabled browsers.
Example reports generated from today's SVN are provided here:
http://people.imendio.com/timj/examples/glib-full-report.html
http://people.imendio.com/timj/examples/gtk+-full-report.html

Percentages are reported for the amount of tests that failed or succeeded,
e.g. gtk+/tests/.libs/lt-objecttests is reported with a result of 80.39%,
because ca. 20% of our automated widget property tests fail (generate some
warnings or crash Gtk+, volounteers to look into those cases highly needed).

It'd be nice if someone in the community could set up a build machine for
jhbuild/modulesets/gtk.modules that builds, runs test-report, perf-report
and full-report and uploads the resulting test-report-html, perf-report.html
and full-report.html from GLib and Gtk+ to some public location.

About commit policies, now that we have a test framework in place that
distinguishes between slow (make full-report) and fast (make check) tests,
and allows subcomponent related tests (e.g. make check -C gtk+/gtk/), it'd
be nice to actually make ue of it.

So i'd like to suggest that we establish some basic commit/test
policies, e.g.:

1) Before committing changes in glib/subdir or gtk+/subdir, a
developer needs to ensure that make check -C glib/subdir (or
make check -C gtk+/subdir) passes.

2) For major changes (adding new components, changing lots of files,
changing Makefiles, etc.), developers should run make full-report
on the whole module and investigate the failing test cases before
committing.

The exact rules/process is open for discussion of course, the above
is meant as some initial food for thought. Please discuss! ;-)

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

Re: GLib Testframework API

2007-12-20 Thread Tim Janik

On Tue, 18 Dec 2007, Johan Dahlin wrote:

 Sorry for being late in the game for comments, but here we go.

 In general this api differs slightly from JUnit/python, which has the
 following (main) methods:

  assertEqual
  assertNotEqual
  assertTrue
  assertFalse
  assertRaises

yeah, i've looked at the JUnit API when designig the glib test API, but
didn't find those assertions to be too applicable. e.g. there's not too
much difference in:
   g_assert (condition == TRUE);
   g_assert_true (condition);
   g_assert (condition == FALSE);
   g_assert_fail (condition); // suggested by Behdad

if people strongly feel those need to be added we can do that, i just
fail to see a significant benefit.

 Perhaps the term equals could be used instead of cmp.

the existing API uses cmp because it implements memcmp(3) result semantics,
i.e. -1,0,+1 instead of eaqulity ('==') semantics.
for int/hex/float, this should obviously make sense, and for strings it
mimicks the most common comparison API, i.e. strcmp().

 I haven't looked in detail at the trap api, but having something similar to
 assertRaises for g_error  friends would be a good thing.

hm, i'd say the closest thing to assertRaises in glib *is* g_error().
maybe you meant GError? that might be useful to have, patches welcome ;)

 g_assert_cmpstr, accepts a comparison operator, while this makes sense for
 comparing floats and integers I don't think it should be included in the api
 for strings.
 Basically, the only thing you want to check if is a string is equal to
 another or not, so perhaps it could be replaced with:

   g_assert_equals_str
   g_assert_not_equals_str

 Or do you see a use case for using other operators besides == and != ?

sure, if you use strcmp() to sort a list of strings, you'd use
g_assert_cmpstr() to test the invariants. and as i wrote above, offering
'cmp' here instead of 'equals' is what C coders are most used to anyway
(and consistent with the other g_assert_cmp*() variants).
keep in mind that the g_assert_*() family is about convenience anyway,
everyone is free to fallback to g_assert() or if(...)g_error() for his
checks.

a remaining issue i see with g_assert_cmpstr() however is that we should
probably also have g_assert_casecmpstr(), similar to g_strcasecmp().

 Johan

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

Test Framework Mini Tutorial

2007-12-13 Thread Tim Janik

Hey All.

The following gives a mini tutorial on writing test programs for GLib
and Gtk+ with the new framework. We have a good number of example test
programs in SVN now and appreciate help from everyone in implementing
new tests.

First, we'll have a quick introduction into the main rationale on
test writing.

The main goals in writing tests are:
- In example (test) driven development (EDD or TDD), an example or test
   program is written first, and then the newly used API gets implemented.
   This ensures early testability and gives programmers early feedback on
   their implementation.
- For untested legacy code, new tests are written to get about to be changed
   code portions under automated tests to catch behavior changes as code is
   changed.
- Most tests are written to ensure basic functionality checks of the code
   area in change. Tests usually cannot perform comprehensive checks, but
   can check for specific known to be tricky corner cases or often test a
   representative subset of an API.

In general, working on code that is sufficiently under automated tests
makes programmers feel much more confident about their changes and helps
to spot errors shortly after introduction. So well tested code bases
tend to increase productivity and fun in working with the code.


The following list of steps is hopefully helpful when approaching the
implementation of a new test for GLib or Gtk+:

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
Also, not all tests need to go into an extra test binary. Building and
linking many test binaries can be quite time consuming, so linking
multiple .c files with tests into a single test binary can be advisable.

2) Write the test fixture setup and teardown code if necessary.
See e.g. ScannerFixture in glib/tests/scannerapi.c for a simple
example fixture that creates and sets up an object to be used
freshly in various different tests.

3) Implement the actual test function, possibly taking a fixture argument.
Tests should try to avoid duplicating logic or tests and often consist
of a series of calls and checks to use a component and verify its
behavior, e.g.:
  string = g_string_new (first);
  g_assert_cmpstr (string-str, ==, first);
  g_string_append (string, last);
  g_assert_cmpstr (string-str, ==, firstlast);
The current set of useful test assertions provided by GLib is:
  g_assert_not_reached ();
  g_assert (expression);
  g_assert_cmpstr  (s1, cmpop, s2);
  g_assert_cmpint  (n1, cmpop, n2);
  g_assert_cmpuint (n1, cmpop, n2);
  g_assert_cmphex  (n1, cmpop, n2);
  g_assert_cmpfloat(n1, cmpop, n2);
Where 'cmpop' is the compare operator, such as '==' or '='.
Of course g_error() can also be used once a test error is discovered.
Note that g_warning() will usually also abort test programs, because
tests generally run with --g-fatal-warnings enabled.

4) Verify stdout and stderr output or assert failures.
Tests can be started in a separate forked off sub process to capture
premature failure, exit status and output. Here is a sample snippet:
  if (g_test_trap_fork (0, G_TEST_TRAP_SILENCE_STDOUT |
   G_TEST_TRAP_SILENCE_STDERR))
{
  g_warning (harmless warning with parameters: %d %s %#x, 42, Boo, 
12345);
  exit (0); // should never be triggered
}
  g_test_trap_assert_failed(); // we have fatal-warnings enabled
  g_test_trap_assert_stderr (*harmless warning*);
More example uses of the test_trap API can be found in:
  glib/tests/testglib.c
  glib/tests/scannerapi.c
  glib/glib/tests/testing.c

5) Conditionalize slow or fragile tests.
While unit tests are most effective if they are fast, to allow quick
turn around times during development, slow or more thorough tests
also have their place. Test routines can be conditionalized in case
they contain fragile or slow code with the following API:
  gboolean g_test_perf ();  // TRUE to enable (slow) performance tests
  gboolean g_test_slow ();  // TRUE to execute possibly slow test code
  gboolean

Re: Suggested even/odd convention for the micro version numbers (like cairo)

2007-12-11 Thread Tim Janik

On Tue, 11 Dec 2007, Tor Lillqvist wrote:

 I humbly suggest that the versioning recommendation for the GTK+ stack
 and GNOME in general is amended for the third micro part of the
 version numbers to match the convention used in cairo.

 See http://cairographics.org/manual/cairo-Version-Information.html .

 In a nutshell, the idea is that released tarballs have an even micro
 version. The micro version is bumped both immediately before and after
 building the release tarball. The even micro number is never committed
 to SVN. In SVN the micro number is always odd.

the scheme sounds good and well applicable to glib/gtk.

 I guess one disadvantage of this is that it might take a time before
 people stop asking what happened to version x.y.z. Also, one
 probably needs to script the bump-make dist-bump sequence in order not
 to forget it, at least initially.

yeah, i think a problem in practice is that it's easily forgotten to bump
the SVN version number after distcheck. i don't quite see how a script
could solve this, because i don't see an obvious point where a script could
check/enforce the bump.

given that the release process is usually (some parts can be parallelized):
- commit development stuff to SVN
- bump version to x.y.even
- build and fix things until distcheck succeeds
- final updates (NEWS, README, ChangeLog, etc)
- final make distcheck, yields tarball x.y.even
- commit release changes to SVN
- upload tarball

the time to run a script to check/enforce x.y.odd would be
after comitting release changes, around tarball uploading...

suggestions for hooking up a script welcome.

 --tml

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

Re: Contributing to Glib

2007-12-11 Thread Tim Janik

On Mon, 26 Nov 2007, Bryan Christ wrote:

 Can anyone point me to some resources for contributing to Glib.  I
 have combed the gtk.org website looking for a FAQ or contributor guide
 but can't find anything.

people can sign up for individual tasks for contributing to glib/gtk+ hee:
   http://live.gnome.org/GtkTasks

there's also a resource for novice bug fixing:
   http://live.gnome.org/GtkLove

and you can of course pick any existing glib bug and start hacking on it:
   http://bugzilla.gnome.org/buglist.cgi?query=product:glib

other than that, it might help to know in which way you'd like to contribute.

 -- 
 Bryan
 

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

GLib and Gtk+ branched for 2.15.0

Hay all.

upstream GLib and Gtk+ have been branched now. as of this morning, both trunks
are at 2.15.0, and stable branches have been created for bugfixes:
   http://svn.gnome.org/viewvc/glib/branches/glib-2-14/
   http://svn.gnome.org/viewvc/gtk+/branches/gtk-2-12/

so the plan is to release GLib-2.16.0 and Gtk+-2.16.0 in sync again at the end
of this development phase.

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

Re: GLib and Gtk+ branched for 2.15.0

On Mon, 19 Nov 2007, Kalle Vahlman wrote:

 2007/11/19, Tim Janik [EMAIL PROTECTED]:
 Hay all.

 upstream GLib and Gtk+ have been branched now. as of this morning, both 
 trunks
 are at 2.15.0, and stable branches have been created for bugfixes:
http://svn.gnome.org/viewvc/glib/branches/glib-2-14/
http://svn.gnome.org/viewvc/gtk+/branches/gtk-2-12/

 so the plan is to release GLib-2.16.0 and Gtk+-2.16.0 in sync again at the 
 end
 of this development phase.

 Not that I'm against it, but is there a rationale/discussion for this 
 somewhere?

there is no strong technical reason either way.
having different MINOR version numbers for glib and gtk+ has been a constant
matter of confusion in emails and during meetings, so syncing them is simply
going to make things easier for humans.

 Kalle Vahlman, [EMAIL PROTECTED]

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

Re: RFC: Gtk+ testing utilities

On Sat, 17 Nov 2007, Stefan Kost wrote:

Hi,

Tim Janik schrieb:
hey All.

first, a quick update on the GLib testing framework. allmost all of it
has been implemented at this point and is available here:
http://git.imendio.com/?p=timj/glib-testing.git;a=shortlog;h=gtester2
we're currently working on finishing the documentation. and now that glib
has been branched, we'll look into integrating it into upstream next week.

below is the proposed API for Gtk+ testing utility functions.
they are mostly derived from the needs to automate user interaction
tests of dialogs and widgets.
a myriad of other functions could of course also be useful for testing,
but those are probably best found out and added to Gtk+ as time passes
and specific needs arise.
this basic set should be good enough to navigate and operate most
dialogs programatically.
the following is just a very brief API wrap up, attached is a Gtk+ program
that implements and documents this API and has a bunch of example
test cases to test this API. the attached test program is not yet dependant
on the new glib testing framework, so it's easier for people to try out.

What about Xvfb support? I have 4 funtions in buzztards check test suite:

i've setup a similar environment, albeit in the Makefile:

http://git.imendio.com/?p=timj/gtk%2B-testing.git;a=blob;f=gtk/tests/Makefile.am;hb=72227f8f808a0343cb420f09ca480fc1847b6601
hardcoding Xvfb invokation in the executable doesn't seem very fortunate
to me. e.g. depending on the system, you might want to use Xvfb, Xnest,
Xephyr, etc or for debugging the X server of the current session.
also, running Xvfb from the makefile will allow to share Xvbf invocations
between multiple test programs.

the logic from the makefile might be useful to factor out into a script
for other GUI projects though, since it involved quite some tweaking to
handle missing Xvfb gracefully, find free display ids and provide meaningful
error messages on errors.

Stefan

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

Re: RFC: Gtk+ testing utilities

On Fri, 16 Nov 2007, Tommi Komulainen wrote:

 Some quick and random comments that come to mind...

 /* syncronize rendering operations with X server rendering queue */
 voidgtk_test_xserver_render_sync(GdkWindow  *window);

 /* synthesize and send key press or release event */
 gbooleangtk_test_simulate_key   (GdkWindow  *window,

 /* synthesize and send button press or release event */
 gbooleangtk_test_simulate_button(GdkWindow  *window,

 Shouldn't the above be named gdk_test or take GtkWidget as parameter?

hmm, strictly speacking, you could argue for creating gdktestutils.h in gdk
and moving this there, yes. i wasn't sure opening up the gdk_test namespace
is really worth the hassle, but considering that we'd hopefully extend Gdk
tests and test utils in the future, your change would probably be for the
better.

   while (gtk_events_pending ())
 gtk_main_iteration ();

 The test examples had quite a few of these, adding noise.

not sure what you mean with adding noise?

 Most of them
 were related to spin buttons, so I suppose in general tests shouldn't
 have many of these? Would it make sense to flush the events in
 gtk_test_spin_button_click instead, for example?

if you do GUI interaction tests with an X server, you'll not be able to
avoid processing events from within your test programs.
here's a simplified example:

   button = create_button();
   gtk_widget_show_now (button);
   /* the above calls the main loop recursively until button is visible */

   /* button is now mapped on screen */
   gtk_test_widget_click (button, 1, 0);
   /* button click events are in the outgoing queue */
   gdk_flush(); /* force sending of button events to x server now */

   g_assert (button_clicked_callback_called == TRUE);
   /* assertion fails, because button events weren't received by the app yet */

   while (gtk_events_pending ()) /* receive x events (button clicks) */
 gtk_main_iteration ();  /* handle x events (call clicked callback */
   g_assert (button_clicked_callback_called == TRUE);
   /* assertion passes, because main loop handled button clicks now */

on top of that, the spin button code sets up its own asyncronous
main loop handlers to process event updates. so there's no way
around intermediate recursive main loop invocations to verify GUI
interaction logic. also gdk_flush() is not a suitable replacement
as it only sends events, but doesn't cause the application to
receive and process GUI events.

 Tommi Komulainen[EMAIL PROTECTED]

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

Re: RFC: Gtk+ testing utilities

On Mon, 19 Nov 2007, Stefan Kost wrote:

 Tim Janik schrieb:

 the logic from the makefile might be useful to factor out into a script
 for other GUI projects though, since it involved quite some tweaking to
 handle missing Xvfb gracefully, find free display ids and provide
 meaningful
 error messages on errors.

 Yep, My code had to pass several revision to mature. E.g. its good to cleanup
 dead display and lock files. While looking at your code, it seems you use
 display ids ranging from 101-199, is that right (did not know this would 
 work).

yes, and via shell traps, the Xvfb is killed away if everything (program,
make, etc.) crashes. so it'll efectively never leak Xvfb server processes
(which is likely to happen with if test apps spawn Xvfb away themselves and 
crash).

also, the Xvfb presence is simply checked in the makefile, so we don't need to
depend on configure time checks and could conceivably exchange it for Xnest/
Xephyr/etc via environment variables.

 Stefan


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

Re: Is g_source_remove threadsafe?

On Fri, 16 Nov 2007, Owen Taylor wrote:

 While I don't really consider
 g_source_remove(some_id_that_I_might_already_have_removed) 100% valid,
 the docs do imply that it is legal, so perhaps it would be worth fixing
 up that case (say, by having a referencing internal variant of
 find_source_by_id().)

i think such a variant really needs to be exposed as public API.
g_main_context_find_source*() is fairly pointless if it can only be used
correctly if the caller must be holding a reference to the returned source
already.
i think this API should have in the first place, either:
- returned an id, because g_source_remove(invalid_id) behaves gracefully, or
- returned a GSource* with increased reference count, to ensure the returned
   pointer is alive and valid.

 - Owen

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

Re: Is g_source_remove threadsafe?

On Fri, 16 Nov 2007, Alexander Larsson wrote:

 I'm doing something where i have one thread queueing idles and timeouts
 in a thread, and the main loop consumes this. In some cases i want to
 remove the sources (to replace a timeout with an idle). However:

 Am I missing something obvious here?

simply use g_source_remove (id) instead.

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

Re: RFC: Gtk+ testing utilities

On Fri, 16 Nov 2007, Richard Hult wrote:

 Tim Janik wrote:
 hey All.

 Hi Tim,

 [snip]

 /* syncronize rendering operations with X server rendering queue */
 voidgtk_test_xserver_render_sync(GdkWindow  *window);

 Should this be named less X-ish? I noticed that some of the event
 simulation functions are very X specific anyway, but if we have the API
 at least look generic, we can make it work on other backends later.

the API that generates button or key events should ideally be implemented
for non-X backends as well at some point, yes.

gtk_test_xserver_render_sync() however uses a technique that is only known
to work for X servers (according to keith packard), please search for
XGetImage in this email:
   http://mail.gnome.org/archives/gtk-devel-list/2006-October/msg00166.html

if there's a chance we could use and implement a similar call for other
windowing system backends though, a rename like you suggest would be good.

Tml, any input? ;)

 /Richard

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

Re: Is g_source_remove threadsafe?