Nabble - Gtk+ - General

pango_layout_set_width() versus measured widths

2009-12-22T14:13:43Z

In working with Pango I found an oddity that I do not understand.
It may be a bug, or it might just be my misunderstanding.

As part of a table layout procedure for printing, my code wishes
to find out the width of the longest word in a Pango layout, so
it sets the width of the layout to 1, turns on word wrapping, and
measures the width of the layout, something like this:

pango_layout_set_width (layout, 1);
pango_layout_set_wrap (layout, PANGO_WRAP_WORD);
pango_layout_get_size (layout, &width, NULL);

Later on, the width of the table column might have been adjusted
upward or downward for other reasons, so it renders it with
PANGO_WRAP_WORD_CHAR to prevent overflowing the column
boundary. I was surprised to discover that, when the layout
width is set to the same value returned by
pango_layout_get_size(), this caused some words to wrap anyhow.

I'm enclosing a simple example program. You can invoke it to
measure the size of rendering "A string of text" with a width of
1 and word-wrapping, as above, e.g. showing input, output, and
an ASCII rendering of the produced foo.pdf:

# ./a.out "A string of text" 1 word
size: width=47032
extents: ink width=45416, logical width=47032
pixel extents: ink width=45, logical width=46

+------+
|A |
|string|
|of |
|text |
+------+

Then giving the exact width reported by this run, plus word-char,
yields:

# ./a.out "A string of text" 47032 word-char
size: width=36632
extents: ink width=35112, logical width=36632
pixel extents: ink width=35, logical width=36

+-----+
|A |
|strin|
|g of |
|text |
+-----+

To get word-char to produce the results that I expect, I have to
add 5208, which is the reported width of " ":

# ./a.out "A string of text" 52240 word-char
size: width=47032
extents: ink width=45416, logical width=47032
pixel extents: ink width=45, logical width=46

+------+
|A |
|string|
|of |
|text |
+------+

Any guidance would be appreciated. I can always add the width of
a space myself, but I don't understand why it is necessary.

Here is my test program:

#include <pango/pangocairo.h>
#include <cairo/cairo-pdf.h>
#include <cairo/cairo.h>
#include <stdlib.h>
#include <string.h>

int
main (int argc, char **argv)
{
cairo_t *cr;
char *filename;
cairo_status_t status;
cairo_surface_t *surface;
PangoLayout *layout;
PangoFontDescription *desc;
PangoRectangle ink, logical;
int width;

if (argc != 4)
{
g_printerr ("Usage: pangocairo STRING WIDTH WRAP_MODE\n");
return 1;
}

/* Create surface and clear to all-white. */
surface = cairo_pdf_surface_create ("foo.pdf", 200, 200);
cr = cairo_create (surface);
cairo_set_source_rgb (cr, 1.0, 1.0, 1.0);
cairo_paint (cr);

/* Create Pango layout. */
layout = pango_cairo_create_layout (cr);
desc = pango_font_description_from_string ("Sans 12");
pango_layout_set_font_description (layout, desc);
pango_font_description_free (desc);
pango_layout_set_text (layout, argv[1], -1);

/* Set Pango options according to command line. */
pango_layout_set_width (layout, atoi (argv[2]));
if (!strcmp (argv[3], "word"))
pango_layout_set_wrap (layout, PANGO_WRAP_WORD);
else if (!strcmp (argv[3], "char"))
pango_layout_set_wrap (layout, PANGO_WRAP_CHAR);
else if (!strcmp (argv[3], "word-char"))
pango_layout_set_wrap (layout, PANGO_WRAP_WORD_CHAR);
else
{
g_printerr ("WRAP_MODE must be 'word' or 'char' or 'word-char'");
return 1;
}

/* Draw layout. */
cairo_set_source_rgb (cr, 0.0, 0.0, 0.0);
cairo_move_to (cr, 0, 0);
pango_cairo_show_layout (cr, layout);

/* Print various sizes. */
pango_layout_get_size (layout, &width, NULL);
printf ("size: width=%d\n", width);

pango_layout_get_extents (layout, &ink, &logical);
printf ("extents: ink width=%d, logical width=%d\n",
ink.width, logical.width);

pango_layout_get_pixel_extents (layout, &ink, &logical);
printf ("pixel extents: ink width=%d, logical width=%d\n",
ink.width, logical.width);

/* Clean up. */
g_object_unref (layout);

cairo_destroy (cr);

cairo_surface_finish (surface);
status = cairo_surface_status (surface);
cairo_surface_destroy (surface);

if (status != CAIRO_STATUS_SUCCESS)
{
g_printerr ("Could not save pdf to '%s'\n", filename);
return 1;
}

return 0;
}
--
Ben Pfaff
http://benpfaff.org

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

Re: gtk_editable_get_position

2009-12-22T04:30:13Z

On Tue, Dec 22, 2009 at 12:46:28PM +0100, Emmanuel Rodriguez wrote:

> On Tue, Dec 22, 2009 at 11:47 AM, maxim maxim <look2004il@...> wrote:
> > I have a following question, I try to receive a cursor position in
> > GtkEntry by function gtk_editable_get_position (GTK_EDITABLE (entry)),
> > but the function returns a correct position only at expose-event, in
> > all other cases it returns a zero, how to solve this problem?
>
> You can try to access directly the property "cursor-position":
>
> gint position = -1;
> g_object_get(G_OBJECT(entry), "cursor-position", &position, NULL);

If it made a difference it would be a bug in Gtk+.

By the way, working with properties is by no reasonable metric more
direct. It does some complicated GValue trickery and at the end it
calls the same getter or setter.

Yeti

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

Re: gtk_editable_get_position

2009-12-22T04:28:00Z

On Tue, Dec 22, 2009 at 12:47:55PM +0200, maxim maxim wrote:
> I have a following question, I try to receive a cursor position in
> GtkEntry by function gtk_editable_get_position (GTK_EDITABLE (entry)),
> but the function returns a correct position only at expose-event, in
> all other cases it returns a zero,

Demonstrate. The attached program demonstrates it works as expected.

Yeti

=================================================================
#include <gtk/gtk.h>

static void
get_position(GtkEntry *entry)
{
g_print("pos: %d\n", gtk_editable_get_position(GTK_EDITABLE(entry)));
}

int
main(int argc, char *argv[])
{
GtkWidget *window, *box, *entry, *button;

gtk_init(&argc, &argv);
window = gtk_window_new(GTK_WINDOW_TOPLEVEL);
g_signal_connect(window, "destroy", G_CALLBACK(gtk_main_quit), NULL);

box = gtk_vbox_new(FALSE, 4);
gtk_container_add(GTK_CONTAINER(window), box);

entry = gtk_entry_new();
gtk_container_add(GTK_CONTAINER(box), entry);

button = gtk_button_new_with_mnemonic("_Get Position");
gtk_container_add(GTK_CONTAINER(box), button);
g_signal_connect_swapped(button, "clicked",
G_CALLBACK(get_position), entry);

gtk_widget_show_all(window);
gtk_main();

return 0;
}
=================================================================
_______________________________________________
gtk-list mailing list
gtk-list@...
http://mail.gnome.org/mailman/listinfo/gtk-list

Re: gtk_editable_get_position

2009-12-22T03:46:28Z

On Tue, Dec 22, 2009 at 11:47 AM, maxim maxim <look2004il@...> wrote:

Hi to all,

I have a following question, I try to receive a cursor position in
GtkEntry by function gtk_editable_get_position (GTK_EDITABLE (entry)),
but the function returns a correct position only at expose-event, in
all other cases it returns a zero, how to solve this problem?

You can try to access directly the property "cursor-position":

gint position = -1;
g_object_get(G_OBJECT(entry), "cursor-position", &position, NULL);

--
Emmanuel Rodriguez

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

gtk_editable_get_position

2009-12-22T02:47:55Z

Hi to all,

I have a following question, I try to receive a cursor position in
GtkEntry by function gtk_editable_get_position (GTK_EDITABLE (entry)),
but the function returns a correct position only at expose-event, in
all other cases it returns a zero, how to solve this problem?

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

Re: Gtk widget running in separate thread

2009-12-22T01:02:15Z

Thanks Tor. Is there an example that can demonstrate how this can be done on X?

Regards,

Zaheer

On Tue, Dec 22, 2009 at 2:00 PM, Tor Lillqvist <tml@...> wrote:

> Is it possible to run a GTK widget entirely in a separate thread i.e. all
> the input events on that widget are handled in that thread.

On X11, probably yes, with extreme care. Is it a good idea? NO!

(And in GTK+ on Windows, it is not really possible, not even using the
same extreme care as in GTK+ on X11. Note that this is not because the
Windows OS and Win32 API as such would be less thread-aware than Linux
or POSIX in general, but exactly because of the opposite: In Windows,
a window is associated with the thread that created it and messages
("events") for it go to the message queue for that thread, etc.
Compare to X11 which at its heart is a network protocol and has no
relation to threads (or processes, for that matter).)

--tml

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

Re: Gtk widget running in separate thread

2009-12-22T00:30:32Z

> Is it possible to run a GTK widget entirely in a separate thread i.e. all
> the input events on that widget are handled in that thread.

On X11, probably yes, with extreme care. Is it a good idea? NO!

(And in GTK+ on Windows, it is not really possible, not even using the
same extreme care as in GTK+ on X11. Note that this is not because the
Windows OS and Win32 API as such would be less thread-aware than Linux
or POSIX in general, but exactly because of the opposite: In Windows,
a window is associated with the thread that created it and messages
("events") for it go to the message queue for that thread, etc.
Compare to X11 which at its heart is a network protocol and has no
relation to threads (or processes, for that matter).)

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

Gtk widget running in separate thread

2009-12-21T23:07:26Z

hi,

Is it possible to run a GTK widget entirely in a separate thread i.e. all the input events on that widget are handled in that thread. The widget is used for zoom control on a canvas (e.g. webpage), and should independantly be responsive to updates on the canvas (which can be time consuming). so far in my search i havent found a post which answers this. The closest is http://www.cairographics.org/threaded_animation_with_cairo/ however in this case we are running a independant animation and no interaction with it.

Appreciate any inputs.

thanks,

Zzaher

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

Re: Memory leak in gtk label?

2009-12-21T23:00:10Z

On Tue, Dec 22, 2009 at 3:47 AM, Liu, Raymond <raymond.liu@...> wrote:

>
>you should read:
>
> http://live.gnome.org/Valgrind
>
>before using Valgrind with GLib or GTK+ based applications.
>

Thanks a lot ;)

With the gtk.suppression file for 2.12, 30% of the fake memory leak issues are gone.

While, still quite many of them remain. I can add more suppress rules, but I am not sure whether they are real of fake memory leak issues.

So is there any latest suppression files for gtk / glib?

You can always build your own suppression file. Follow the instructions provided by libchamplain [1] in the section "Valgrind error suppression".

The idea is to make a short hello world program that has no code leak (from the developer point of view) and to tell valgrind to build an error supression list. Then you can use that list with your programs.

[1] http://live.gnome.org/libchamplain/contributor

--
Emmanuel Rodriguez

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

GTK+ 2.19.2 released

2009-12-21T19:51:28Z

GTK+ 2.19.2 is now available for download at:

ftp://ftp.gtk.org/pub/gtk/2.19/
http://download.gnome.org/sources/gtk+/2.19/

md5 sums:
c7b4997a13f644a45349a6a22a21e577 gtk+-2.19.2.tar.bz2
c6a5c7431d610b820f8aefdb2055e178 gtk+-2.19.2.tar.gz

sha1 sums:
c4e04159f105215314933f6b9bebf4b987c51b28 gtk+-2.19.2.tar.bz2
809690522f0d6e7bb9d302ec4ff2a87c261e0be9 gtk+-2.19.2.tar.gz

This is a development release leading up to GTK+ 2.20.

Notes:

* This is an unstable development release.
It has had only little testing and there are unfinished
features and plenty of bugs in this release. It should
definitively not be used in production.

* Installing this version will overwrite your existing
copy of GTK+ 2.18. If you have problems, you'll need
to reinstall GTK+ 2.18.

* GTK+ 2.20 will be source and binary compatible with
the GTK+ 2.18 series; however, the new API additions
are not yet finalized, so there may be incompatibilities
between this release and the final 2.20 release.

* Bugs should be reported to http://bugzilla.gnome.org.

What is GTK+
============

GTK+ is a multi-platform toolkit for creating graphical user
interfaces. Offering a complete set of widgets, GTK+ is suitable for
projects ranging from small one-off tools to complete application
suites.

GTK+ has been designed from the ground up to support a range of
languages, not only C/C++. Using GTK+ from languages such as Perl and
Python (especially in combination with the Glade GUI builder) provides
an effective method of rapid application development.

GTK+ is free software and part of the GNU Project. However, the
licensing terms for GTK+, the GNU LGPL, allow it to be used by all
developers, including those developing proprietary software, without
any license fees or royalties.

Where to get more information about GTK+
========================================

Information about GTK+ including links to documentation can be
found at:

http://www.gtk.org/

An installation guide for GTK+ 2.x is found at:

http://developer.gnome.org/doc/API/2.0/gtk/gtk-building.html

Common questions:

http://developer.gnome.org/doc/API/2.0/gtk/gtk-question-index.html
http://www.gtk.org/faq/

Contributing
============

GTK+ is a large project and relies on voluntary contributions.
We are actively searching for new contributors in various areas
and invite everyone to help project development.
If you are willing to participate, please subscribe to the project
mailing lists to offer your help and read over our list of vacant
project tasks:
http://live.gnome.org/GtkTasks

Overview of Changes from GTK+ 2.19.1 to 2.19.2
==============================================

* Introspection:
- Introspection data for gdk-pixbuf, gdk and gtk is now
included in GTK+ itself. As a consequence, the atk dependency
has been bumped to 2.29.2, and a gobject-introspection dependency
has been added. configure with --disable-introspection in order
to not build introspection data.

* Client-side windows:
- Fix some issues with handling of button and motion events
- Fix damage reporting for drawing on offscreen windows
- Fix problems with handling of input extension events

* Printing:
- Add api to handle printer hard margins

* Simple IM Context:
- Sync with Xorg compose file
- Make Compose-vowel-minus combinations consistent

* GDK:
- gdk_screen_get_primary_monitor: New function to get the
'primary' monitor in a multi-monitor setup

* gdk-pixbuf has gained the ability to store and retrieve embedded
ICC color profiles in png and tiff images

* Keyboard handling:
- Mnemonic underlines can now optionally be hidden until the Alt key
is pressed, this can be turned on with the gtk-auto-mnemonics setting
- Using the Super, Meta and Hyper modifiers in accelerators is working
more reliably

* Bugs fixed:
603652 Sporadic crashes with GtkSocket
605008 the region of damage event doesn't be copied in gdk_event_copy
588554 only show the accelerator when pressing alt
601473 GDK_BUTTON?_MOTION_MASK appears to be broken
601712 Add API for determining primary monitor
50942 selection/arrow key improvement
427409 editing shortcut always fails with super key
468989 need a way to get the printer's hard margins
502266 gtk_tree_selection_get_selected_rows free example produces...
592279 Introspection support
597386 Cannot click buttons more than once without moving the mouse...
599213 Use GtkCellEditable:editing_canceled property instead...
599397 Button stuck at pressed look after screen rotation
601383 gtk_icon_view_get_selected_items: example code gives...
602099 Actions can be activatable too
603619 the colormap of offscreen's pixmap doesn't inherit...
603904 gdk_draw_line doesn't have expose area.
604117 Add info about single includes when compiling GTK+ apps
604289 Please permit progress pages to be final in a dialog
604462 gtktoolitem.c: return-value is different type
604747 Using gdk_draw_line, the expose area of damage event is wrong
604787 property-notify-event is not delivered to a non-toplevel...
604881 GtkCellEditable::editing-cancelled should be writable
591085 GtkBuilder object ID bounded to GtkWidget "name" property

* Updated translations:
Arabic
Estonian
Hebrew
Low German
Norwegian bokmål
Slovenian
Spanish
Telugu
Vietnamese

Thanks to all contributors:
Adrian Johnson
Christian Persch
Javier Jardón
Alexander Larsson
Carlos Garcia Campos
Christian Dywan
Cody Russell
Danielle Madeley
Johan Dahlin
Sven Herzberg
Matthew Barnes
Tor Lillqvist
Colin Walters
Tomeu Vizoso
Richard Hughes
Torsten Schoenfeld
Hiroyuki Ikezoe
Dan Winship
Benjamin Otte
Thomas Wood
Michael Natterer

December 21, 2009
Matthias Clasen

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

RE: Memory leak in gtk label?

2009-12-21T18:47:20Z

>
>you should read:
>
> http://live.gnome.org/Valgrind
>
>before using Valgrind with GLib or GTK+ based applications.
>

Thanks a lot ;)

With the gtk.suppression file for 2.12, 30% of the fake memory leak issues are gone.

While, still quite many of them remain. I can add more suppress rules, but I am not sure whether they are real of fake memory leak issues.

So is there any latest suppression files for gtk / glib?

>ciao,
> Emmanuele.
>

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

Glowing Treeview Row

2009-12-21T14:19:57Z

I'm trying to find a way of making an entire row "glow" to give feedback
to the user on which row has been "activated". I good example of this
feature is used in Amarok. When a row is "activated", it begins to glow
with a hazy highlight.

Is there any built in functionality like this in GTK? If not is there a
way I can use a GtkCellRendererPixbuf to engulf all text columns on a
particular row?

Or are there any better techniques to accomplishing this?

Thanks,

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

Re: Fwd: GTK+ is real object oriented?

2009-12-21T10:34:28Z

Yes I agree 100%, very nice and succinct.

One thing I would like to add; however, is that the choice to use an OO-native language or not is not simply a choice of which compiler or language constructs to use . The OO "syntactic suger" incurs a high cost, which is fine if you are running on a powerful processer with large memories. One job I did was to take a pile of C++ written on a PC and port it to a 50MHz ARM processor with only 32KB of RAM and 2MB of flash. This was a very cost sensitive application and thus "adding more menory or MHz" was unacceptable. Just compiling the C++ code as is to an ARM target produced over 512KB of binary. The memory remaing would be completely unacceptable for the large database that also needed to be stored in flash. Not to mention the processing overhead that would be untenable on a 50MHz ARM in this application. After "de-C++ifying" it into standard C, the resulting binary that resulted was about 124KB and ran much faster. Fortunately the programmer I was working with who wrote the original C++ code was very talented and made the job easier in that his code was very clean and easy to work with.

So as for the GTK code, I would say that it is with great thanks that the programmers take on the task of coding with standard C rather than the "easy way out" and using C++ which would likely make GTK untenable in embedded appliations.

Rob

Michael Natterer wrote:

On Sun, 2009-12-20 at 16:16 -0200, frederico schardong wrote:

The difference is that not a really object-oriented, is a fake object-oriented.

I call it fake object-oriented environment, maybe not the most
correctly name, but i think is true.

What do you think?


Object oriented is a programming paradigm, not a computer
language. Just because C lacks the syntactic sugar to do OO
in a more compact way says *nothing* about the possibility
to use it for OO programming. It is after all turing complete.

There is nothing "fake" here.

The fact that a gas oven has a much nicer user interface
doesn't make an old wood-fired stone oven a "fake" oven.

ciao,
--mitch


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

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

Re: Fwd: GTK+ is real object oriented?

2009-12-21T08:26:06Z

frederico schardong wrote:
> I like C sintax, but is it that create this confusion to me... Thanks
> for clearly, and I agree that GTK is OO.

Take a look at Vala[1]. I think you'd like it. It compiles to C code,
so there is zero overhead. Vala syntax itself is basically C with
object-oriented syntactical sugar. Most distros have a reasonably
updated version of Vala in their repositories.

Certainly if you want to make your own GTK widgets that derive from
other widgets, or make your own object-oriented, GObject-based code,
Vala is very handy. As OO as GTK is, creating new classes in straight C
is very ugly. Vala-generated code can be used in straight C programs
directly. If you made a new Vala class called "foo," for example, it
automatically provides the C-style methods like:

foo_new()

Vala has an advantage over C++ in that any Vala classes you create can
be used by any of the language bindings (in theory), whereas C++ classes
cannot be used easily by C code.

[1] http://live.gnome.org/Vala
_______________________________________________
gtk-list mailing list
gtk-list@...
http://mail.gnome.org/mailman/listinfo/gtk-list

GLib 2.23.1 released

2009-12-21T08:02:39Z

GLib 2.23.1 is now available for download at:

ftp://ftp.gtk.org/pub/glib/2.23/
http://download.gnome.org/sources/glib/2.23/

md5 sums:
fb637f6122690254097d0b6d470f6ed3 glib-2.23.1.tar.bz2
ea32c834a8c7b166e05aeaaa41a021f4 glib-2.23.1.tar.gz

sha1 sums:
2cf7af4f0a4ac9b4f2b9e95661d94985e64c7c5e glib-2.23.1.tar.bz2
f2341b22cddef44824a1dcbcd053ceff632c10ad glib-2.23.1.tar.gz

This is the a development release leading up to GLib 2.24.

Notes:

* This is unstable development release. While it has had
a bit of testing, there are certainly plenty of bugs
remaining to be found. This release should not be used
in production.

* Installing this version will overwrite your existing
copy of GLib 2.22. If you have problems, you'll need
to reinstall GLib 2.22.

* GLib 2.24 will be source and binary compatible with
the GLib 2.22 series; however, the new API additions
in GLib 2.23 are not yet finalized, so there may be
incompatibilities between this release and the final
2.24 release.

* Bugs should be reported to http://bugzilla.gnome.org.

About GLib
==========

GLib is the low-level core library that forms the basis for projects
such as GTK+ and GNOME. It provides data structure handling for C,
portability wrappers, and interfaces for such runtime functionality as
an event loop, threads, dynamic loading, and an object system.

More information about GLib is available at:

http://www.gtk.org/

An installation guide for the GTK+ libraries, including GLib, can
be found at:

http://developer.gnome.org/doc/API/2.0/gtk/gtk-building.html

Overview of Changes from GLib 2.23.0 to GLib 2.23.1
===================================================

* GObject performance work has landed:
- Construction of simple objects is much faster
- Interface lookup is lock-free and constant-time now
- Reduced locking overhead when dealing with types

* GType now has a G_DEFINE_INTERFACE convenience macro

* GIO gained GUtf8InputStream, an input stream that
performs utf-8 validation

* GLib now has byte-swap macros for gsize and gssize

* Bugs fixed:
557151 Determining the newly_constructed boolean in gobject.c...
557100 Performance improvements for GObjectClasses that don't...
501166 Warning message says IA__g_type_init instead of g_type_init
585375 Performance and Contention problems with g_type_class_ref...
587892 Race in GType when instantiating the same class for the...
603270 Input Stream validating utf8
603476 gioenums.h:62: error: comma at end of enumerator list
603540 g_time_val_from_iso8601 uses uninitialised variable
603982 Stack overflow when reading file async with filter
604645 G_DEFINE_INTERFACE_* documentation is not generated
604875 Use of sa_len conflicts with system header
320482 provide G_DEFINE_TYPE like macros for interfaces

* Updated translations:
Estonian
Hebrew
Norwegian bokmål
Vietnamese
Welsh

December 20, 2009
Matthias Clasen

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

Re: GTK+ is real object oriented?

2009-12-21T06:47:39Z

On Mon, 21 Dec 2009 08:34:06 -0200
frederico schardong <frede.sch@...> wrote:
> I like C sintax, but is it that create this confusion to me... Thanks
> for clearly, and I agree that GTK is OO.

It's OO with warts on, not because as you originally assumed you cannot
write object oriented code in C, but because it hasn't always been
implemented correctly. Try for example calling gtk_tooltips_set_tip()
on a GtkToolItem object. It should work, because GtkToolItem is derived
from GtkWidget, but in fact you need to call
gtk_tool_item_set_tooltip().

The same disjunction still appears to arise with the new
gtk_widget_set_tooltip_text() and gtk_tool_item_set_tooltip_text().

Yes I know why there are these separate functions for GtkToolItem
objects: the GtkToolItem version operates on the tool item's child
widget. But the interface is broken from the OO perspective. (It
could have been solved with the new tooltip interface by specialising
gtk_widget_set_tooltip_text() for tool item objects, but that does
appear to have been done.)

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

Re: Fwd: GTK+ is real object oriented?

2009-12-21T06:20:45Z

Nicely put!

On Mon, Dec 21, 2009 at 7:26 AM, Michael Natterer <mitch@...> wrote:

> On Sun, 2009-12-20 at 16:16 -0200, frederico schardong wrote:
>
>> The difference is that not a really object-oriented, is a fake object-oriented.
>>
>> I call it fake object-oriented environment, maybe not the most
>> correctly name, but i think is true.
>>
>> What do you think?
>
> Object oriented is a programming paradigm, not a computer
> language. Just because C lacks the syntactic sugar to do OO
> in a more compact way says *nothing* about the possibility
> to use it for OO programming. It is after all turing complete.
>
> There is nothing "fake" here.
>
> The fact that a gas oven has a much nicer user interface
> doesn't make an old wood-fired stone oven a "fake" oven.
>
> ciao,
> --mitch
>
>
> _______________________________________________
> gtk-list mailing list
> gtk-list@...
> http://mail.gnome.org/mailman/listinfo/gtk-list
>

--
Gerald Britton
_______________________________________________
gtk-list mailing list
gtk-list@...
http://mail.gnome.org/mailman/listinfo/gtk-list

RE: Memory leak in gtk label?

2009-12-21T04:54:53Z

hi;

On Fri, 2009-12-18 at 09:34 +0800, Liu, Raymond wrote:

> By the way, to make 100% sure, I destroy the top level window before exit. All the same ;)

you should read:

http://live.gnome.org/Valgrind

before using Valgrind with GLib or GTK+ based applications.

ciao,
Emmanuele.

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

Re: Fwd: GTK+ is real object oriented?

2009-12-21T04:26:24Z

On Sun, 2009-12-20 at 16:16 -0200, frederico schardong wrote:

> The difference is that not a really object-oriented, is a fake object-oriented.
>
> I call it fake object-oriented environment, maybe not the most
> correctly name, but i think is true.
>
> What do you think?

Object oriented is a programming paradigm, not a computer
language. Just because C lacks the syntactic sugar to do OO
in a more compact way says *nothing* about the possibility
to use it for OO programming. It is after all turing complete.

There is nothing "fake" here.

The fact that a gas oven has a much nicer user interface
doesn't make an old wood-fired stone oven a "fake" oven.

ciao,
--mitch

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

Re: Fwd: GTK+ is real object oriented?

2009-12-21T02:34:06Z

> The only difference is one of convention. Don't get hung up on where
> the "." or "->" is. One might be preferred over the other by you, but
> that does not mean that GTK is not object-oriented. If you don't like
> the C syntax used to constuct, destroy, and call methods on an object,
> then I suggest you use GTKmm with C++, Vala, or PyGTK. In each case the
> Gobject system is accessed via the native object-oriented conventions.
> Since GObject OO, the bindings are really just thin wrappers to thunk
> from one object system to another.

I like C sintax, but is it that create this confusion to me... Thanks
for clearly, and I agree that GTK is OO.

> 2009/12/21 Michael Torrie <torriem@...>:
>> frederico schardong wrote:
>>> Yes, C don't provide sintax support for do my example of method.
>>
>> Syntactical support is not required for an object-oriented system; it
>> merely makes it easier for you, the programmer.
>>
>>> In OOP such class must have self methods to set self attributes.
>>
>> Yes, and gobject certainly has this.
>>
>>> What happen is GObject (by the C limitation) just have attributes, the
>>> methods to set its attributes are functions out of the struct. Ok, is
>>> this what happen, but for this facts don't broke the OOP?
>>
>> No, GObject has both attributes and methods. Just like in C++, there is
>> a struct to hold the data members (the attributes) and a call table to
>> hold the methods. This is why you can call a GtkWidget method on an
>> instance that is a descendant of GtkWidget and it still works. For
>> example, a button:
>>
>> b=gtk_button_new()
>> gtk_widget_show(b)
>>
>> The "show" method of the GtkWidget class can be called on the instance b
>> because it descends from GtkWidget, even though it is of the GtkButton
>> class. Even more convincingly, if I overrode the "show" method in my
>> own GtkWidget-derived class, a call to gtk_widget_show(myinstance) would
>> call my own classes show because show is a virtual method. So the call
>> table tells the compiler which method to actually call. Pretty much
>> like C++, except that it's not hidden as cleanly.
>>
>> Note that there is absolutely no functional difference between using
>> this class/method/instance combination for a method call from the
>> instance/method idea. In other words:
>>
>> gtk_widget_show(instance)
>>
>> is identical to
>>
>> instance.show()
>>
>> The only difference is one of convention. Don't get hung up on where
>> the "." or "->" is. One might be preferred over the other by you, but
>> that does not mean that GTK is not object-oriented. If you don't like
>> the C syntax used to constuct, destroy, and call methods on an object,
>> then I suggest you use GTKmm with C++, Vala, or PyGTK. In each case the
>> Gobject system is accessed via the native object-oriented conventions.
>> Since GObject OO, the bindings are really just thin wrappers to thunk
>> from one object system to another.
>> _______________________________________________
>> gtk-list mailing list
>> gtk-list@...
>> http://mail.gnome.org/mailman/listinfo/gtk-list
>>
>
>
>
> --
> Thanks,
> Frederico Schardong,
> SOLIS - Open source solutions
> www.solis.coop.br
> Linux registered user #500582
>

--
Thanks,
Frederico Schardong,
SOLIS - Open source solutions
www.solis.coop.br
Linux registered user #500582
_______________________________________________
gtk-list mailing list
gtk-list@...
http://mail.gnome.org/mailman/listinfo/gtk-list

Re: Fwd: GTK+ is real object oriented?

2009-12-20T18:11:12Z

frederico schardong wrote:
> Yes, C don't provide sintax support for do my example of method.

Syntactical support is not required for an object-oriented system; it
merely makes it easier for you, the programmer.

> In OOP such class must have self methods to set self attributes.

Yes, and gobject certainly has this.

> What happen is GObject (by the C limitation) just have attributes, the
> methods to set its attributes are functions out of the struct. Ok, is
> this what happen, but for this facts don't broke the OOP?

No, GObject has both attributes and methods. Just like in C++, there is
a struct to hold the data members (the attributes) and a call table to
hold the methods. This is why you can call a GtkWidget method on an
instance that is a descendant of GtkWidget and it still works. For
example, a button:

b=gtk_button_new()
gtk_widget_show(b)

The "show" method of the GtkWidget class can be called on the instance b
because it descends from GtkWidget, even though it is of the GtkButton
class. Even more convincingly, if I overrode the "show" method in my
own GtkWidget-derived class, a call to gtk_widget_show(myinstance) would
call my own classes show because show is a virtual method. So the call
table tells the compiler which method to actually call. Pretty much
like C++, except that it's not hidden as cleanly.

Note that there is absolutely no functional difference between using
this class/method/instance combination for a method call from the
instance/method idea. In other words:

gtk_widget_show(instance)

is identical to

instance.show()

The only difference is one of convention. Don't get hung up on where
the "." or "->" is. One might be preferred over the other by you, but
that does not mean that GTK is not object-oriented. If you don't like
the C syntax used to constuct, destroy, and call methods on an object,
then I suggest you use GTKmm with C++, Vala, or PyGTK. In each case the
Gobject system is accessed via the native object-oriented conventions.
Since GObject OO, the bindings are really just thin wrappers to thunk
from one object system to another.
_______________________________________________
gtk-list mailing list
gtk-list@...
http://mail.gnome.org/mailman/listinfo/gtk-list

Re: Custom container + Child type with interface

2009-12-20T17:51:32Z

On Sun, Dec 20, 2009 at 07:47:55PM +0000, Matthew Bucknall wrote:
> Yes, it does. But as far as I can tell, implementers of the interface
> cannot override the GParamFlags of an interface property with some
> superset. Effectively, implementers can only override the property's
> getter/setter. Please let me know if I've got that wrong.

You are probably right, only the getter and setter are overridable.

I've always considered property overrding a desperate measure because if
the original getter and setter called a virtual method you could
override that and it would be the preferred solution.

Unfortunately, it would not help in your case.

> This is why it seems I could only go with the lowest common denominator
> of GParamFlag settings in the interface definition. Which I agree makes
> a total mess of the 'is-a' paradigm - which is something I'm trying to
> avoid.

Another possibility is to simply avoid the definition of properties and
define getters (in the interface) and setters (in specific classes). It
is a logical way out because the primary purpose of properties is to
enable generic manipulation. But if you cannot satisfy the
substitutability relation then you lose the generic manipulation ability
anyway.

Regards,

Yeti

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

Re: Fwd: GTK+ is real object oriented?

2009-12-20T17:50:32Z

Thanks to everybody.

You helped me to clarify the concepts of OO.

2009/12/20 David Nečas <yeti@...>:

> On Sun, Dec 20, 2009 at 05:26:20PM -0200, frederico schardong wrote:
>> Yes, C don't provide sintax support for do my example of method.
>>
>> In OOP such class must have self methods to set self attributes.
>>
>> What happen is GObject (by the C limitation) just have attributes, the
>> methods to set its attributes are functions out of the struct. Ok, is
>> this what happen, but for this facts don't broke the OOP?
>
> You have a weird definition of OO.
>
> Smalltalk people could tell you that calling methods is fake OO because
> to do real OO you must send messages to objects. Now what?
>
> To the syntax issue. In fact, virtual methods in Gtk+ are called
>
> GTK_WIDGET_GET_CLASS(widget)->show(widget)
>
> where GTK_WIDGET_GET_CLASS explicitly obtains the virtual table
> (referenced from within the object struct) because the compiler won't do
> it for you and then you can call the method.
>
> But as everyone else prefers a sane syntax to a cozy objectishy feeling,
> this is wrapped with something like gtk_widget_show() for virtual
> methods and non-virtual methods look entirely like functions.
>
> If it matters to you whether calling methods looks like
>
> object.method(arg1, arg2)
> object_method(arg1, arg2)
> (object method arg1 arg2)
> method { arg1 } { arg2 } : object
>
> then Gtk+ is fake OO by your definition but hardly anyone cares.
>
> If it matters to you in what bit of memory methods are physically
> stored, then check if Smalltalk, Ocaml, Haskel, etc. are OO according to
> your definition or not. Hopefully you are aware the methods are seldom
> actually stored in `the object struct' even though they are placed there
> in the source code of e.g. C++ because that would be a collosal waste of
> resources.
>
> If you are troubled by the fact that one can write gtk_widget_frobnicate()
> that will look exactly like a GtkWidget method but would not be, then
> you simply noticed one of the things that cannot be enforced in C. The
> rule is that you must not name functions gtk_widget_frobnicate().
>
> The object file compiled from gtkwidget.c then lists all the GtkWidget
> methods and is as good table of methods of the object as anything else.
>
> Yeti
>
>

Re: Fwd: GTK+ is real object oriented?

2009-12-20T17:25:08Z

On Sun, Dec 20, 2009 at 05:26:20PM -0200, frederico schardong wrote:
> Yes, C don't provide sintax support for do my example of method.
>
> In OOP such class must have self methods to set self attributes.
>
> What happen is GObject (by the C limitation) just have attributes, the
> methods to set its attributes are functions out of the struct. Ok, is
> this what happen, but for this facts don't broke the OOP?

You have a weird definition of OO.

Smalltalk people could tell you that calling methods is fake OO because
to do real OO you must send messages to objects. Now what?

To the syntax issue. In fact, virtual methods in Gtk+ are called

GTK_WIDGET_GET_CLASS(widget)->show(widget)

where GTK_WIDGET_GET_CLASS explicitly obtains the virtual table
(referenced from within the object struct) because the compiler won't do
it for you and then you can call the method.

But as everyone else prefers a sane syntax to a cozy objectishy feeling,
this is wrapped with something like gtk_widget_show() for virtual
methods and non-virtual methods look entirely like functions.

If it matters to you whether calling methods looks like

object.method(arg1, arg2)
object_method(arg1, arg2)
(object method arg1 arg2)
method { arg1 } { arg2 } : object

then Gtk+ is fake OO by your definition but hardly anyone cares.

If it matters to you in what bit of memory methods are physically
stored, then check if Smalltalk, Ocaml, Haskel, etc. are OO according to
your definition or not. Hopefully you are aware the methods are seldom
actually stored in `the object struct' even though they are placed there
in the source code of e.g. C++ because that would be a collosal waste of
resources.

If you are troubled by the fact that one can write gtk_widget_frobnicate()
that will look exactly like a GtkWidget method but would not be, then
you simply noticed one of the things that cannot be enforced in C. The
rule is that you must not name functions gtk_widget_frobnicate().

The object file compiled from gtkwidget.c then lists all the GtkWidget
methods and is as good table of methods of the object as anything else.

Yeti

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

Re: gtk-list Digest, Vol 68, Issue 27

2009-12-20T12:14:12Z

if u think GTK is not a oriented object programming, make it easy, modify the code until it turns OOP, and with these you'll be helping the comunity to debug the source code, simple. all the other points of view are only attacks and not constructive comments.

ESTE HA SIDO UN MENSAJE DE TU DIOS AMO Y SEÑOR MALLER.
MAS RESPETO HACIA TU DIOS, Y BORRA ESA ESTUPIDA SONRISA DE TU ROSTRO...

2009/12/20 <gtk-list-request@...>

Send gtk-list mailing list submissions to
gtk-list@...

To subscribe or unsubscribe via the World Wide Web, visit
http://mail.gnome.org/mailman/listinfo/gtk-list
or, via email, send a message with subject or body 'help' to
gtk-list-request@...

You can reach the person managing the list at
gtk-list-owner@...

When replying, please edit your Subject line so it is more specific
than "Re: Contents of gtk-list digest..."

Today's Topics:

1. Re: GTK+ is real object oriented? (David Ne?as)
2. Re: GTK+ is real object oriented? (David Ne?as)
3. Fwd: GTK+ is real object oriented? (frederico schardong)
4. Fwd: GTK+ is real object oriented? (frederico schardong)
5. Fwd: GTK+ is real object oriented? (frederico schardong)
6. Fwd: GTK+ is real object oriented? (frederico schardong)
7. Re: Custom container + Child type with interface (David Ne?as)
8. Re: Fwd: GTK+ is real object oriented? (Matthew Bucknall)

----------------------------------------------------------------------

Message: 1
Date: Sun, 20 Dec 2009 18:37:47 +0100
From: David Ne?as <yeti@...>
To: frederico schardong <frede.sch@...>
Cc: gtk-list@...
Subject: Re: GTK+ is real object oriented?
Message-ID: <20091220173746.GB8103@...>
Content-Type: text/plain; charset=us-ascii

On Sun, Dec 20, 2009 at 03:07:01PM -0200, frederico schardong wrote:
> Is GTK+ really object oriented?
>
> Or just provide a fake object oriented environment?

And what is the difference?

If it walks like an object oriented environment and quacks like an
object oriented environment, how do you call it?

Yeti

------------------------------

Message: 2
Date: Sun, 20 Dec 2009 18:54:07 +0100
From: David Ne?as <yeti@...>
To: frederico schardong <frede.sch@...>
Cc: gtk-list@...
Subject: Re: GTK+ is real object oriented?
Message-ID: <20091220175407.GC8103@...>
Content-Type: text/plain; charset=us-ascii

On Sun, Dec 20, 2009 at 03:40:34PM -0200, frederico schardong wrote:
> The difference is that not a really object-oriented, is a fake object-oriented.
>
> I call it fake object-oriented environment, maybe not the most
> correctly name, but i think is true.
>
> What do you think?

I think you still did not give any definition of what real and fake
means. At least for you since others will likely disagree whatever the
definition is.

So again, it is built around OO concepts and behaves like an OO
environment. How can you tell it is a fake?

Yeti

------------------------------

Message: 3
Date: Sun, 20 Dec 2009 16:16:11 -0200
From: frederico schardong <frede.sch@...>
To: gtk-list@...
Subject: Fwd: GTK+ is real object oriented?
Message-ID:
<c8f238750912201016r15934a82s2169b68b920b6de4@...>
Content-Type: text/plain; charset=ISO-8859-1

---------- Forwarded message ----------
From: frederico schardong <frede.sch@...>
Date: 2009/12/20
Subject: Re: GTK+ is real object oriented?
To: "Michael P. Soulier" <msoulier@...>

Real is when the language have the concepts of ?class, objects,
instance, method, inheritance, abstraction, encapsulation,
polymorphism...

In GTK+ programmin we don't have something like
widget->setVisibility(TRUE). For me it's broken the concept of object
oriented, because a attribute(visibility) of the class widget is set
by a extern function, not a method of the class widget.

2009/12/20 Michael P. Soulier <msoulier@...>:
> On 20/12/09 frederico schardong said:
>
>> Hi,
>>
>> Is GTK+ really object oriented?
>>
>> Or just provide a fake object oriented environment?
>
> Define real. Define fake.
>
> Mike
> --
> Michael P. Soulier <msoulier@...>
> "Any intelligent fool can make things bigger and more complex... It takes a
> touch of genius - and a lot of courage to move in the opposite direction."
> --Albert Einstein
>

--
Thanks,
Frederico Schardong,
SOLIS - Open source solutions
www.solis.coop.br
Linux registered user #500582

--
Thanks,
Frederico Schardong,
SOLIS - Open source solutions
www.solis.coop.br
Linux registered user #500582

------------------------------

Message: 4
Date: Sun, 20 Dec 2009 16:16:32 -0200
From: frederico schardong <frede.sch@...>
To: gtk-list@...
Subject: Fwd: GTK+ is real object oriented?
Message-ID:
<c8f238750912201016i5f2e1553w14e335d0e1f79380@...>
Content-Type: text/plain; charset=ISO-8859-1

---------- Forwarded message ----------
From: frederico schardong <frede.sch@...>
Date: 2009/12/20
Subject: Re: GTK+ is real object oriented?
To: "Michael P. Soulier" <msoulier@...>

Fake is when change a attribute (visibility) of a class (gtkwidget)
only can be changed by a function (gtk_widget_hide() or
(gtk_widget_show()) not by a method.

2009/12/20 frederico schardong <frede.sch@...>:
> Real is when the language have the concepts of ?class, objects,
> instance, method, inheritance, abstraction, encapsulation,
> polymorphism...
>
> In GTK+ programmin we don't have something like
> widget->setVisibility(TRUE). For me it's broken the concept of object
> oriented, because a attribute(visibility) of the class widget is set
> by a extern function, not a method of the class widget.
>
> 2009/12/20 Michael P. Soulier <msoulier@...>:
>> On 20/12/09 frederico schardong said:
>>
>>> Hi,
>>>
>>> Is GTK+ really object oriented?
>>>
>>> Or just provide a fake object oriented environment?
>>
>> Define real. Define fake.
>>
>> Mike
>> --
>> Michael P. Soulier <msoulier@...>
>> "Any intelligent fool can make things bigger and more complex... It takes a
>> touch of genius - and a lot of courage to move in the opposite direction."
>> --Albert Einstein
>>
>
>
>
> --
> Thanks,
> Frederico Schardong,
> SOLIS - Open source solutions
> www.solis.coop.br
> Linux registered user #500582
>

--
Thanks,
Frederico Schardong,
SOLIS - Open source solutions
www.solis.coop.br
Linux registered user #500582

--
Thanks,
Frederico Schardong,
SOLIS - Open source solutions
www.solis.coop.br
Linux registered user #500582

------------------------------

Message: 5
Date: Sun, 20 Dec 2009 16:16:51 -0200
From: frederico schardong <frede.sch@...>
To: gtk-list@...
Subject: Fwd: GTK+ is real object oriented?
Message-ID:
<c8f238750912201016y66918537i58121434875aefc4@...>
Content-Type: text/plain; charset=UTF-8

---------- Forwarded message ----------
From: frederico schardong <frede.sch@...>
Date: 2009/12/20
Subject: Re: GTK+ is real object oriented?
To: David Ne?as <yeti@...>

The difference is that not a really object-oriented, is a fake object-oriented.

I call it fake object-oriented environment, maybe not the most
correctly name, but i think is true.

What do you think?

2009/12/20 David Ne?as <yeti@...>:
> On Sun, Dec 20, 2009 at 03:07:01PM -0200, frederico schardong wrote:
>> Is GTK+ really object oriented?
>>
>> Or just provide a fake object oriented environment?
>
> And what is the difference?
>
> If it walks like an object oriented environment and quacks like an
> object oriented environment, how do you call it?
>
> Yeti
>
>

--
Thanks,
Frederico Schardong,
SOLIS - Open source solutions
www.solis.coop.br
Linux registered user #500582

--
Thanks,
Frederico Schardong,
SOLIS - Open source solutions
www.solis.coop.br
Linux registered user #500582

------------------------------

Message: 6
Date: Sun, 20 Dec 2009 16:17:12 -0200
From: frederico schardong <frede.sch@...>
To: gtk-list@...
Subject: Fwd: GTK+ is real object oriented?
Message-ID:
<c8f238750912201017y7c2b9040p10d55e7228e41154@...>
Content-Type: text/plain; charset=UTF-8

---------- Forwarded message ----------
From: frederico schardong <frede.sch@...>
Date: 2009/12/20
Subject: Re: GTK+ is real object oriented?
To: David Ne?as <yeti@...>

Maybe I had expressed wrong.

I don't wanna say that GTK+ NOT IS OO, I'm saying that the way that
GTK+ implements the concepts of OO is different. As I say before...
"change a attribute (visibility) of a class (gtkwidget) only can be
changed by a function (gtk_widget_hide() or (gtk_widget_show()) not by
a method".

Yes, GTK+ has been construct around OO concepts, buts it have all
those concepts that a say before (class, objects,
instance, method, inheritance, abstraction, encapsulation, polymorphism)?

Because this things a say that's fake (maybe not the correct word).

2009/12/20 David Ne?as <yeti@...>:
> On Sun, Dec 20, 2009 at 03:40:34PM -0200, frederico schardong wrote:
>> The difference is that not a really object-oriented, is a fake object-oriented.
>>
>> I call it fake object-oriented environment, maybe not the most
>> correctly name, but i think is true.
>>
>> What do you think?
>
> I think you still did not give any definition of what real and fake
> means. ?At least for you since others will likely disagree whatever the
> definition is.
>
> So again, it is built around OO concepts and behaves like an OO
> environment. ?How can you tell it is a fake?
>
> Yeti
>
>

--
Thanks,
Frederico Schardong,
SOLIS - Open source solutions
www.solis.coop.br
Linux registered user #500582

--
Thanks,
Frederico Schardong,
SOLIS - Open source solutions
www.solis.coop.br
Linux registered user #500582

------------------------------

Message: 7
Date: Sun, 20 Dec 2009 19:22:20 +0100
From: David Ne?as <yeti@...>
To: Matthew Bucknall <matt@...>
Cc: "gtk-list@..." <gtk-list@...>
Subject: Re: Custom container + Child type with interface
Message-ID: <20091220182220.GB17795@...>
Content-Type: text/plain; charset=us-ascii

On Sun, Dec 20, 2009 at 04:43:57PM +0000, Matthew Bucknall wrote:
> Next question - The interface I have defined basically just mandates a
> few properties. The container that requires children to implement this
> interface only ever reads these properties.
>
> Some implementers of the interface will determine the value of the
> interface properties based on various bits of internal state
> information. Other implementers will be passed the property values via
> their constructors.
>
> So as far as the container and some implementers are concerned, the
> interface properties only need to be G_PARAM_READABLE. In other cases,
> the properties might need to be (G_PARAM_READWRITE |
> G_PARAM_CONSTRUCT_ONLY).
>
> I assume that the interface definition has to go with the lowest common
> denominator, which I think is G_PARAM_READWRITE. In that case, what
> should implementers do where the properties are not settable (because
> they are derived from other state information)?

I've never had to override properties (fortunately), so just some OO
theory...

You do not go with `the least common denominator'. The is-a relation
between subclases and classes or implementations of interfaces means that
you can always say MyFoo is a GpanePanel if it implements the interface.
In other words, you must be always able to substitute the derived object
for the parent.

You can't do this if the parent has writable properties but the child
has not.

So to mandate the is-a relation in case of your properties, the parent
must have the most *restrictive* flags (typically G_PARAM_READABLE).
Subclasses can then permit more operations.

Regards,

Yeti

------------------------------

Message: 8
Date: Sun, 20 Dec 2009 19:08:31 +0000
From: Matthew Bucknall <matt@...>
To: frederico schardong <frede.sch@...>
Cc: "gtk-list@..." <gtk-list@...>
Subject: Re: Fwd: GTK+ is real object oriented?
Message-ID: <1261336111.28816.86.camel@newton>
Content-Type: text/plain; charset="UTF-8"

I think you're making way to strong a connection between language syntax
and programming paradigms. You're confusing 'what' with 'how'.

GObject, on which GTK+ is built provides all the key OOP properties and
GTK+ uses them to maximum effect:

Abstraction
Polymorphism
Inheritance
Encapsulation

C was not designed with object-oriented programming in-mind, so of
course the way GObject goes about presenting the above characteristics
in a C API may be a little awkward compared to how they are realized in
other languages. That does not detract from the fact that GObject/GTK+
provides a 'real' object-oriented environment. It just means it does so
in a way with which you might not be comfortable.

Seems to me, if you want to stick with a compiled language, you might be
better off using C++ and programming GTK+ applications via the gtkmm C++
bindings (http://www.gtkmm.org/).

Matt.

On Sun, 2009-12-20 at 16:17 -0200, frederico schardong wrote:
> ---------- Forwarded message ----------
> From: frederico schardong <frede.sch@...>
> Date: 2009/12/20
> Subject: Re: GTK+ is real object oriented?
> To: David Ne?as <yeti@...>
>
>
> Maybe I had expressed wrong.
>
> I don't wanna say that GTK+ NOT IS OO, I'm saying that the way that
> GTK+ implements the concepts of OO is different. As I say before...
> "change a attribute (visibility) of a class (gtkwidget) only can be
> changed by a function (gtk_widget_hide() or (gtk_widget_show()) not by
> a method".
>
> Yes, GTK+ has been construct around OO concepts, buts it have all
> those concepts that a say before (class, objects,
> instance, method, inheritance, abstraction, encapsulation, polymorphism)?
>
> Because this things a say that's fake (maybe not the correct word).
>
> 2009/12/20 David Ne?as <yeti@...>:
> > On Sun, Dec 20, 2009 at 03:40:34PM -0200, frederico schardong wrote:
> >> The difference is that not a really object-oriented, is a fake object-oriented.
> >>
> >> I call it fake object-oriented environment, maybe not the most
> >> correctly name, but i think is true.
> >>
> >> What do you think?
> >
> > I think you still did not give any definition of what real and fake
> > means. At least for you since others will likely disagree whatever the
> > definition is.
> >
> > So again, it is built around OO concepts and behaves like an OO
> > environment. How can you tell it is a fake?
> >
> > Yeti
> >
> >
>
>
>
> --
> Thanks,
> Frederico Schardong,
> SOLIS - Open source solutions
> www.solis.coop.br
> Linux registered user #500582
>
>
>

------------------------------

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

End of gtk-list Digest, Vol 68, Issue 27
****************************************

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

Re: Custom container + Child type with interface

2009-12-20T11:47:55Z

Yes, it does. But as far as I can tell, implementers of the interface
cannot override the GParamFlags of an interface property with some
superset. Effectively, implementers can only override the property's
getter/setter. Please let me know if I've got that wrong.

This is why it seems I could only go with the lowest common denominator
of GParamFlag settings in the interface definition. Which I agree makes
a total mess of the 'is-a' paradigm - which is something I'm trying to
avoid.

Matt.

On Sun, 2009-12-20 at 20:35 +0100, David Nečas wrote:

> On Sun, Dec 20, 2009 at 07:30:42PM +0000, Matthew Bucknall wrote:
> > Seems to me, it should be perfectly acceptable to define a property that
> > can be set at construction, but then only read during the rest of the
> > owning object's lifetime (i.e. something like G_PARAM_READABLE |
> > PARAM_CONSTRUCT_ONLY), but GObject does not allow this - at least, it
> > didn't work when I tried.
>
> That's exactly what G_PARAM_READWRITE | G_PARAM_CONSTRUCT_ONLY does if I
> am not mistaken. The terminology is a bit confusing.
>
> Yeti
>

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

Re: Custom container + Child type with interface

2009-12-20T11:35:28Z

On Sun, Dec 20, 2009 at 07:30:42PM +0000, Matthew Bucknall wrote:
> Seems to me, it should be perfectly acceptable to define a property that
> can be set at construction, but then only read during the rest of the
> owning object's lifetime (i.e. something like G_PARAM_READABLE |
> PARAM_CONSTRUCT_ONLY), but GObject does not allow this - at least, it
> didn't work when I tried.

That's exactly what G_PARAM_READWRITE | G_PARAM_CONSTRUCT_ONLY does if I
am not mistaken. The terminology is a bit confusing.

Yeti

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

Re: Custom container + Child type with interface

2009-12-20T11:30:42Z

I agree entirely. The problem has arisen because of what I consider a
flaw in the way GObject uses properties during construction (via
g_object_new() etc).

Seems to me, it should be perfectly acceptable to define a property that
can be set at construction, but then only read during the rest of the
owning object's lifetime (i.e. something like G_PARAM_READABLE |
PARAM_CONSTRUCT_ONLY), but GObject does not allow this - at least, it
didn't work when I tried.

In my opinion, an object cannot be considered to fulfil 'is-a anything'
until it has been fully constructed, so the 'is-a' pattern mandated by
an interface during the construction phase is, for the most part,
irrelevant.

I suspect, I'll have to change the interface in question to use methods
rather than properties. But that does feel like a compromise I should
not need to make - especially as I'll have to get around loosing
property change signals I would have otherwise used.

Thanks,
Matt.

On Sun, 2009-12-20 at 19:22 +0100, David Nečas wrote:

> On Sun, Dec 20, 2009 at 04:43:57PM +0000, Matthew Bucknall wrote:
> > Next question - The interface I have defined basically just mandates a
> > few properties. The container that requires children to implement this
> > interface only ever reads these properties.
> >
> > Some implementers of the interface will determine the value of the
> > interface properties based on various bits of internal state
> > information. Other implementers will be passed the property values via
> > their constructors.
> >
> > So as far as the container and some implementers are concerned, the
> > interface properties only need to be G_PARAM_READABLE. In other cases,
> > the properties might need to be (G_PARAM_READWRITE |
> > G_PARAM_CONSTRUCT_ONLY).
> >
> > I assume that the interface definition has to go with the lowest common
> > denominator, which I think is G_PARAM_READWRITE. In that case, what
> > should implementers do where the properties are not settable (because
> > they are derived from other state information)?
>
> I've never had to override properties (fortunately), so just some OO
> theory...
>
> You do not go with `the least common denominator'. The is-a relation
> between subclases and classes or implementations of interfaces means that
> you can always say MyFoo is a GpanePanel if it implements the interface.
> In other words, you must be always able to substitute the derived object
> for the parent.
>
> You can't do this if the parent has writable properties but the child
> has not.
>
> So to mandate the is-a relation in case of your properties, the parent
> must have the most *restrictive* flags (typically G_PARAM_READABLE).
> Subclasses can then permit more operations.
>
> Regards,
>
> Yeti
>

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

Re: Fwd: GTK+ is real object oriented?

2009-12-20T11:26:20Z

Yes, C don't provide sintax support for do my example of method.

In OOP such class must have self methods to set self attributes.

What happen is GObject (by the C limitation) just have attributes, the
methods to set its attributes are functions out of the struct. Ok, is
this what happen, but for this facts don't broke the OOP?

2009/12/20 Michael Torrie <torriem@...>:

> frederico schardong wrote:
>> Fake is when change a attribute (visibility) of a class (gtkwidget)
>> only can be changed by a function (gtk_widget_hide() or
>> (gtk_widget_show()) not by a method.
>
> In most languages, methods are functions.
>
> Sounds to me like you are stuck on syntax rather than the real concept.
> You can do object-oriented programming in most any language, whether it
> has syntactical support or not. C++'s objects are really structs with a
> function call table (vtable) tacked on.
>
> You might consider the Vala language, which implements a syntax more
> like what you are expecting. Under the hood, Vala is straight gobject
> (straight-C), so it's very light-weight.
>
> _______________________________________________
> gtk-list mailing list
> gtk-list@...
> http://mail.gnome.org/mailman/listinfo/gtk-list
>

Re: Fwd: GTK+ is real object oriented?

2009-12-20T11:16:13Z

frederico schardong wrote:
> Yes, GTK+ has been construct around OO concepts, buts it have all
> those concepts that a say before (class, objects,
> instance, method, inheritance, abstraction, encapsulation, polymorphism)?

Yes, it has all of those things. Inheritance is single-inheritance,
unlike C++. The fact that I can call GtkWidget methods on any GTK
object proves there is polymorphism. Classes? check. Objects and
instances? check. Abstraction? yes.

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

Re: Fwd: GTK+ is real object oriented?

2009-12-20T11:13:08Z

frederico schardong wrote:
> Fake is when change a attribute (visibility) of a class (gtkwidget)
> only can be changed by a function (gtk_widget_hide() or
> (gtk_widget_show()) not by a method.

In most languages, methods are functions.

Sounds to me like you are stuck on syntax rather than the real concept.
You can do object-oriented programming in most any language, whether it
has syntactical support or not. C++'s objects are really structs with a
function call table (vtable) tacked on.

You might consider the Vala language, which implements a syntax more
like what you are expecting. Under the hood, Vala is straight gobject
(straight-C), so it's very light-weight.

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

Re: Fwd: GTK+ is real object oriented?

2009-12-20T11:08:31Z

I think you're making way to strong a connection between language syntax
and programming paradigms. You're confusing 'what' with 'how'.

GObject, on which GTK+ is built provides all the key OOP properties and
GTK+ uses them to maximum effect:

Abstraction
Polymorphism
Inheritance
Encapsulation

C was not designed with object-oriented programming in-mind, so of
course the way GObject goes about presenting the above characteristics
in a C API may be a little awkward compared to how they are realized in
other languages. That does not detract from the fact that GObject/GTK+
provides a 'real' object-oriented environment. It just means it does so
in a way with which you might not be comfortable.

Seems to me, if you want to stick with a compiled language, you might be
better off using C++ and programming GTK+ applications via the gtkmm C++
bindings (http://www.gtkmm.org/).

Matt.

On Sun, 2009-12-20 at 16:17 -0200, frederico schardong wrote:

> ---------- Forwarded message ----------
> From: frederico schardong <frede.sch@...>
> Date: 2009/12/20
> Subject: Re: GTK+ is real object oriented?
> To: David Nečas <yeti@...>
>
>
> Maybe I had expressed wrong.
>
> I don't wanna say that GTK+ NOT IS OO, I'm saying that the way that
> GTK+ implements the concepts of OO is different. As I say before...
> "change a attribute (visibility) of a class (gtkwidget) only can be
> changed by a function (gtk_widget_hide() or (gtk_widget_show()) not by
> a method".
>
> Yes, GTK+ has been construct around OO concepts, buts it have all
> those concepts that a say before (class, objects,
> instance, method, inheritance, abstraction, encapsulation, polymorphism)?
>
> Because this things a say that's fake (maybe not the correct word).
>
> 2009/12/20 David Nečas <yeti@...>:
> > On Sun, Dec 20, 2009 at 03:40:34PM -0200, frederico schardong wrote:
> >> The difference is that not a really object-oriented, is a fake object-oriented.
> >>
> >> I call it fake object-oriented environment, maybe not the most
> >> correctly name, but i think is true.
> >>
> >> What do you think?
> >
> > I think you still did not give any definition of what real and fake
> > means. At least for you since others will likely disagree whatever the
> > definition is.
> >
> > So again, it is built around OO concepts and behaves like an OO
> > environment. How can you tell it is a fake?
> >
> > Yeti
> >
> >
>
>
>
> --
> Thanks,
> Frederico Schardong,
> SOLIS - Open source solutions
> www.solis.coop.br
> Linux registered user #500582
>
>
>

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

Re: Custom container + Child type with interface

2009-12-20T10:22:20Z

On Sun, Dec 20, 2009 at 04:43:57PM +0000, Matthew Bucknall wrote:

> Next question - The interface I have defined basically just mandates a
> few properties. The container that requires children to implement this
> interface only ever reads these properties.
>
> Some implementers of the interface will determine the value of the
> interface properties based on various bits of internal state
> information. Other implementers will be passed the property values via
> their constructors.
>
> So as far as the container and some implementers are concerned, the
> interface properties only need to be G_PARAM_READABLE. In other cases,
> the properties might need to be (G_PARAM_READWRITE |
> G_PARAM_CONSTRUCT_ONLY).
>
> I assume that the interface definition has to go with the lowest common
> denominator, which I think is G_PARAM_READWRITE. In that case, what
> should implementers do where the properties are not settable (because
> they are derived from other state information)?

I've never had to override properties (fortunately), so just some OO
theory...

You do not go with `the least common denominator'. The is-a relation
between subclases and classes or implementations of interfaces means that
you can always say MyFoo is a GpanePanel if it implements the interface.
In other words, you must be always able to substitute the derived object
for the parent.

You can't do this if the parent has writable properties but the child
has not.

So to mandate the is-a relation in case of your properties, the parent
must have the most *restrictive* flags (typically G_PARAM_READABLE).
Subclasses can then permit more operations.

Regards,

Yeti

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

Fwd: GTK+ is real object oriented?

2009-12-20T10:17:12Z

---------- Forwarded message ----------
From: frederico schardong <frede.sch@...>
Date: 2009/12/20
Subject: Re: GTK+ is real object oriented?
To: David Nečas <yeti@...>

Maybe I had expressed wrong.

I don't wanna say that GTK+ NOT IS OO, I'm saying that the way that
GTK+ implements the concepts of OO is different. As I say before...
"change a attribute (visibility) of a class (gtkwidget) only can be
changed by a function (gtk_widget_hide() or (gtk_widget_show()) not by
a method".

Yes, GTK+ has been construct around OO concepts, buts it have all
those concepts that a say before (class, objects,
instance, method, inheritance, abstraction, encapsulation, polymorphism)?

Because this things a say that's fake (maybe not the correct word).

2009/12/20 David Nečas <yeti@...>:

> On Sun, Dec 20, 2009 at 03:40:34PM -0200, frederico schardong wrote:
>> The difference is that not a really object-oriented, is a fake object-oriented.
>>
>> I call it fake object-oriented environment, maybe not the most
>> correctly name, but i think is true.
>>
>> What do you think?
>
> I think you still did not give any definition of what real and fake
> means. At least for you since others will likely disagree whatever the
> definition is.
>
> So again, it is built around OO concepts and behaves like an OO
> environment. How can you tell it is a fake?
>
> Yeti
>
>

--
Thanks,
Frederico Schardong,
SOLIS - Open source solutions
www.solis.coop.br
Linux registered user #500582

--
Thanks,
Frederico Schardong,
SOLIS - Open source solutions
www.solis.coop.br
Linux registered user #500582
_______________________________________________
gtk-list mailing list
gtk-list@...
http://mail.gnome.org/mailman/listinfo/gtk-list

Fwd: GTK+ is real object oriented?

2009-12-20T10:16:51Z

---------- Forwarded message ----------
From: frederico schardong <frede.sch@...>
Date: 2009/12/20
Subject: Re: GTK+ is real object oriented?
To: David Nečas <yeti@...>

The difference is that not a really object-oriented, is a fake object-oriented.

I call it fake object-oriented environment, maybe not the most
correctly name, but i think is true.

What do you think?

2009/12/20 David Nečas <yeti@...>:

> On Sun, Dec 20, 2009 at 03:07:01PM -0200, frederico schardong wrote:
>> Is GTK+ really object oriented?
>>
>> Or just provide a fake object oriented environment?
>
> And what is the difference?
>
> If it walks like an object oriented environment and quacks like an
> object oriented environment, how do you call it?
>
> Yeti
>
>