Update Gtk+3.0

[Rúben Rodrigues]

Hi guys,

I'm in trouble with gtk version i think. When i run pkg-config 
--modversion gtk+-3.0 in my Raspberry Pi that is running Raspbian OS, i 
get 3.14.5 version.

If i try to update with sudo apt-get update and sudo apt-get upgrade, i 
have the same version. How i can update to gtk+-3.20 version that is the 
lastest stable version?


Thanks guys.


---
Este e-mail foi verificado em termos de vírus pelo software antivírus Avast.
https://www.avast.com/antivirus

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

Re: more of a C question than GTK+3.0??

[Gary Kline]

=
Organization: Thought Unlimited.  Public service Unix since 1986.
Of_Interest: With 28 years  of service  to the  Unix  community.



well,  I hate to telll fibs, but I'm still at  it.  It has 
been years since  I listened to my bio;  'snot that bad>..


On Sat, Sep 06, 2014 at 09:40:50AM +0200, Gergely Polonkai wrote:
> What I would do instead is:
> 
> GtkWidget **label[1000]; // if you have a dynamic number of labels,
> consider using a GArray maybe
> int i = 0;
> 
> label[i++] = gtk_label_new("first text"); // this will be label[0]
> label[i++] = gtk_label_new("second text"); // this will be label[1]


pretty sure I tried something like this about a week ago.
maybe last monday.  it may have segv'd.  but YES in cp_text.c
is ::


if (p)
{
   fprintf (stdout, "%s", p);
   L[i++] = p;
}

here "p" is  the string or stringgs *within* /tmp/file/text.N.txt;
I planned on passing "L[]" to what you have above: "first text",
"second text".  

in my example text.1.txt files I have (e.g.) "i am bringing this
laptop to the group so I can be more easily understood."

> …
> 
> After this, instead of creating a string "label1", you just need the
> number 1, and can use this:
> 
> s = gtk_label_get_text(GTK_LABEL(label[1]));
> 
> where 1 can instead be a variable of int that holds 1:
> 
> int num = 1;
> s = gtk_label_get_text(GTK_LABEL(label[num]));


many thanks indeed.  I'm' going to save your mail and get a 
hardcopy.  tthen join the directories, &c. 


> On 6 September 2014 09:32, Gary Kline  wrote:
> > =
> > Organization: Thought Unlimited.  Public service Unix since 1986.
> > Of_Interest: With 28 years  of service  to the  Unix  community.
> >
> > On Sat, Sep 06, 2014 at 08:08:34AM +0200, Gergely Polonkai wrote:
> >> On 6 Sep 2014 03:12, "Gary Kline"  wrote:
> >> >
> >> > =
> >> > Organization: Thought Unlimited.  Public service Unix since 1986.
> >> > Of_Interest: With 28 years  of service  to the  Unix  community.
> >> >
> >> > things that I *thought* might work by using
> >> >
> >> > s = gtk_label_get_text(GTK_LABEL((GtkWidget)buf));
> >> >
> >> > fails.  (with contains the String "label1")  I have a index,
> >> > "n" that can range from 1 to 99--whatever GtkWidget *label I
> >> > need.  the next thing that occured was some kind of
> >> >
> >> > typedef struct
> >> > {
> >> >
> >> > GtkWidget  *label1,
> >> >*label2,
> >> >*label3,
> >> >...
> >> >*label999;
> >> > } Labels;
> >> >
> >> > can abybody clue on how to use my n index counter to stick
> >> > one of the "labels" so they show up on my arrow window?
> >> >
> >> > thanks much.
> >> >
> >> > --
> >> >  Gary Kline  kl...@thought.org  http://www.thought.org  Public Service
> >> Unix
> >> >  Twenty-eight years of service to the Unix community.
> >> >
> >>
> >> This definitely calls for an array:
> >>
> >> GtkWidget *label[1000];
> >>
> >> as you cannot reference to a variable with a constructed name (like $$a in
> >> PHP). If your struct holds only pointers, though, you can also cast it to
> >> an array:
> >>
> >> ((GtkWidget **)label_list)[99]
> >>
> >> but I haven't tested it, and highly discourage it.
> >
> >
> >
> > I will heed your advise!  a workaround may be in three *.c
> > files.  but first:: sleep.
> >
> > --
> >  Gary Kline  kl...@thought.org  http://www.thought.org  Public Service Unix
> >  Twenty-eight years of service to the Unix community.
> >
> >

-- 
 Gary Kline  kl...@thought.org  http://www.thought.org  Public Service Unix
 Twenty-eight years of service to the Unix community.


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

Re: more of a C question than GTK+3.0??

[Gergely Polonkai]

What I would do instead is:

GtkWidget **label[1000]; // if you have a dynamic number of labels,
consider using a GArray maybe
int i = 0;

label[i++] = gtk_label_new("first text"); // this will be label[0]
label[i++] = gtk_label_new("second text"); // this will be label[1]
…

After this, instead of creating a string "label1", you just need the
number 1, and can use this:

s = gtk_label_get_text(GTK_LABEL(label[1]));

where 1 can instead be a variable of int that holds 1:

int num = 1;
s = gtk_label_get_text(GTK_LABEL(label[num]));

On 6 September 2014 09:32, Gary Kline  wrote:
> =
> Organization: Thought Unlimited.  Public service Unix since 1986.
> Of_Interest: With 28 years  of service  to the  Unix  community.
>
> On Sat, Sep 06, 2014 at 08:08:34AM +0200, Gergely Polonkai wrote:
>> On 6 Sep 2014 03:12, "Gary Kline"  wrote:
>> >
>> > =
>> > Organization: Thought Unlimited.  Public service Unix since 1986.
>> > Of_Interest: With 28 years  of service  to the  Unix  community.
>> >
>> > things that I *thought* might work by using
>> >
>> > s = gtk_label_get_text(GTK_LABEL((GtkWidget)buf));
>> >
>> > fails.  (with contains the String "label1")  I have a index,
>> > "n" that can range from 1 to 99--whatever GtkWidget *label I
>> > need.  the next thing that occured was some kind of
>> >
>> > typedef struct
>> > {
>> >
>> > GtkWidget  *label1,
>> >*label2,
>> >*label3,
>> >...
>> >*label999;
>> > } Labels;
>> >
>> > can abybody clue on how to use my n index counter to stick
>> > one of the "labels" so they show up on my arrow window?
>> >
>> > thanks much.
>> >
>> > --
>> >  Gary Kline  kl...@thought.org  http://www.thought.org  Public Service
>> Unix
>> >  Twenty-eight years of service to the Unix community.
>> >
>>
>> This definitely calls for an array:
>>
>> GtkWidget *label[1000];
>>
>> as you cannot reference to a variable with a constructed name (like $$a in
>> PHP). If your struct holds only pointers, though, you can also cast it to
>> an array:
>>
>> ((GtkWidget **)label_list)[99]
>>
>> but I haven't tested it, and highly discourage it.
>
>
>
> I will heed your advise!  a workaround may be in three *.c
> files.  but first:: sleep.
>
> --
>  Gary Kline  kl...@thought.org  http://www.thought.org  Public Service Unix
>  Twenty-eight years of service to the Unix community.
>
>
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: more of a C question than GTK+3.0??

[Gary Kline]

=
Organization: Thought Unlimited.  Public service Unix since 1986.
Of_Interest: With 28 years  of service  to the  Unix  community.

On Sat, Sep 06, 2014 at 08:08:34AM +0200, Gergely Polonkai wrote:
> On 6 Sep 2014 03:12, "Gary Kline"  wrote:
> >
> > =
> > Organization: Thought Unlimited.  Public service Unix since 1986.
> > Of_Interest: With 28 years  of service  to the  Unix  community.
> >
> > things that I *thought* might work by using
> >
> > s = gtk_label_get_text(GTK_LABEL((GtkWidget)buf));
> >
> > fails.  (with contains the String "label1")  I have a index,
> > "n" that can range from 1 to 99--whatever GtkWidget *label I
> > need.  the next thing that occured was some kind of
> >
> > typedef struct
> > {
> >
> > GtkWidget  *label1,
> >*label2,
> >*label3,
> >...
> >*label999;
> > } Labels;
> >
> > can abybody clue on how to use my n index counter to stick
> > one of the "labels" so they show up on my arrow window?
> >
> > thanks much.
> >
> > --
> >  Gary Kline  kl...@thought.org  http://www.thought.org  Public Service
> Unix
> >  Twenty-eight years of service to the Unix community.
> >
> 
> This definitely calls for an array:
> 
> GtkWidget *label[1000];
> 
> as you cannot reference to a variable with a constructed name (like $$a in
> PHP). If your struct holds only pointers, though, you can also cast it to
> an array:
> 
> ((GtkWidget **)label_list)[99]
> 
> but I haven't tested it, and highly discourage it.



I will heed your advise!  a workaround may be in three *.c 
files.  but first:: sleep.

-- 
 Gary Kline  kl...@thought.org  http://www.thought.org  Public Service Unix
 Twenty-eight years of service to the Unix community.


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

Re: more of a C question than GTK+3.0??

[Gary Kline]

=
Organization: Thought Unlimited.  Public service Unix since 1986.
Of_Interest: With 28 years  of service  to the  Unix  community.

On Fri, Sep 05, 2014 at 09:43:00PM -0400, Chris Moller wrote:
> What do you mean, "fails?"  What happens?  And what do you want to happen?


when I try to output the const char *s by casting the buf,
with is a string, "label1", it is NULL!  Yes, no kidding.
the next msg explains why.  

s = gtk_label_get_text(GTK_LABEL(labell);



iv'e looked at the following code:

label1 = gtk_label_new("1: This is the file name named talk.1.txt");

in another directory I have text files in /tmp/files/*;  I think
the files over there grab the 10 files;  *if* I stick the
output within gtk_label_new().  I think it may be a matter of
putting these files together and grabbing the content of the
talk.N.txt and putting them into gtk_label_new().

{ I am not explaining anything to this list, but at least I know
what I want to try }
.  




> 
> On 09/05/14 21:12, Gary Kline wrote:
> >=
> >Organization: Thought Unlimited.  Public service Unix since 1986.
> >Of_Interest: With 28 years  of service  to the  Unix  community.
> >
> > things that I *thought* might work by using
> >
> >s = gtk_label_get_text(GTK_LABEL((GtkWidget)buf));
> >
> > fails.  (with contains the String "label1")  I have a index,
> > "n" that can range from 1 to 99--whatever GtkWidget *label I
> > need.  the next thing that occured was some kind of
> >
> > typedef struct
> > {
> >
> > GtkWidget  *label1,
> >*label2,
> >*label3,
> >...
> >*label999;
> > } Labels;
> >
> > can abybody clue on how to use my n index counter to stick
> > one of the "labels" so they show up on my arrow window?
> >
> > thanks much.
> >
> 
> ___
> gtk-app-devel-list mailing list
> gtk-app-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

-- 
 Gary Kline  kl...@thought.org  http://www.thought.org  Public Service Unix
 Twenty-eight years of service to the Unix community.


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

Re: more of a C question than GTK+3.0??

[Gergely Polonkai]

On 6 Sep 2014 03:12, "Gary Kline"  wrote:
>
> =
> Organization: Thought Unlimited.  Public service Unix since 1986.
> Of_Interest: With 28 years  of service  to the  Unix  community.
>
> things that I *thought* might work by using
>
> s = gtk_label_get_text(GTK_LABEL((GtkWidget)buf));
>
> fails.  (with contains the String "label1")  I have a index,
> "n" that can range from 1 to 99--whatever GtkWidget *label I
> need.  the next thing that occured was some kind of
>
> typedef struct
> {
>
> GtkWidget  *label1,
>*label2,
>*label3,
>...
>*label999;
> } Labels;
>
> can abybody clue on how to use my n index counter to stick
> one of the "labels" so they show up on my arrow window?
>
> thanks much.
>
> --
>  Gary Kline  kl...@thought.org  http://www.thought.org  Public Service
Unix
>  Twenty-eight years of service to the Unix community.
>

This definitely calls for an array:

GtkWidget *label[1000];

as you cannot reference to a variable with a constructed name (like $$a in
PHP). If your struct holds only pointers, though, you can also cast it to
an array:

((GtkWidget **)label_list)[99]

but I haven't tested it, and highly discourage it.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: more of a C question than GTK+3.0??

[Chris Moller]

What do you mean, "fails?"  What happens?  And what do you want to happen?


On 09/05/14 21:12, Gary Kline wrote:

=
Organization: Thought Unlimited.  Public service Unix since 1986.
Of_Interest: With 28 years  of service  to the  Unix  community.

things that I *thought* might work by using

s = gtk_label_get_text(GTK_LABEL((GtkWidget)buf));

fails.  (with contains the String "label1")  I have a index,
"n" that can range from 1 to 99--whatever GtkWidget *label I
need.  the next thing that occured was some kind of

typedef struct
{

GtkWidget  *label1,
   *label2,
   *label3,
   ...
   *label999;
} Labels;

can abybody clue on how to use my n index counter to stick
one of the "labels" so they show up on my arrow window?

thanks much.



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

more of a C question than GTK+3.0??

[Gary Kline]

=
Organization: Thought Unlimited.  Public service Unix since 1986.
Of_Interest: With 28 years  of service  to the  Unix  community.

things that I *thought* might work by using 

s = gtk_label_get_text(GTK_LABEL((GtkWidget)buf));

fails.  (with contains the String "label1")  I have a index, 
"n" that can range from 1 to 99--whatever GtkWidget *label I
need.  the next thing that occured was some kind of

typedef struct 
{

GtkWidget  *label1,
   *label2,
   *label3,
   ...
   *label999;
} Labels;

can abybody clue on how to use my n index counter to stick
one of the "labels" so they show up on my arrow window?

thanks much.

-- 
 Gary Kline  kl...@thought.org  http://www.thought.org  Public Service Unix
 Twenty-eight years of service to the Unix community.


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

event-after in Gtk+-3.0

[Ondrej Tuma]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi all,

i use event-after in Mind Map Architect to center map widget to root
node. In Gtk+2.0 version, I've connect to first event-after signal, to
set values on ScrolledWindow adjustments. But this not work in Gtk+-3.0
version.

Please, do you tell me, when I can do set values for adjustments ?
Setting now do not work - that means do not do anything, and get values
functions returns still zero values :(

Thanks a lot !

- -- 
Ondřej Tůma 
www: http://ipv6.mcbig.cz   jabber: mc...@jabber.cz   twitter: mcbig_cz
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlO7kdkACgkQBmNIPxOnb/KkiwCeIFZSG/tatJ5+4Ev7TZbh9twf
hDcAnj50F4dPZFjkGDyfJvpV/ukBXgjb
=rCS6
-END PGP SIGNATURE-
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

vim gtk+3.0 syntax

[Vlasov Vitaly]

Hello, all.
Is GTK3.0 Vim syntax highlighting exist?

I found in Internet python script vim-sym-gen.py, that generate symbols
from gtk-doc, but don't know how to use it. Where to find manual/how-to
to this script?

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

GTK 3.0 .....Menu=Window-Popup

[Mariano Gaudix]

Hello  ...Excuse  me   for  my question   I am
creating a combo-box with scrollbar with GTK 3.0 and VALA (gtk) .
.as  the  COMBO-BOX  in   LibreOffice that have  in the   list of FONTS
..


 I have been able to create something like a MENU ... I use
a WINDOW-POPUP (  gtk_window_new(GTK_WINDOW_POPUP); )  ..the only
problem is I need  two CLIX to hide MENU  .If the pointer is inside the
button.


¿ How i can   transfer the  grab to the popup window  ?



Best   regards   . Mariano.




Code example

http://www.mediafire.com/?xk9s3owv5ioauhb



 widget  image



http://fotos.subefotos.com/99fc8a169bccf1ec0d64e6f20f28bceao.png
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: GTK 3.0 inactive buttons (Buttons : maximize , minimize , close )

[Mariano Gaudix]

http://fotos.subefotos.com/db2e5a8be0a21c26f620bd4adde20c5fo.png

2012/6/22 Mariano Gaudix 

>  In thePOPUP MENUand  COMBOBOX ... has these effects
> ...
>
> If you activate a combo-box  or  menu ..and then   you clicked
> the button  maximize or minimize of the  window   ...
>
> this always happens
>
>
> 1). First   .Clicking the maximize or minimize button  of  the window  ...
> . The  COMBO-BOXis disabled ... and  her menu option .
>
>
> 2)Second . Then recently .  I can close the window.
>
>
>
> this always happens
>
>
>
>
>
> //
>
>  View   Example
>
>
>
>
> ///
>
>
>
>
>
> /***THE CODE/
> #include 
>
>
>
>
> int main(int argc,
>char *argv[]) {
>
>
>
>GtkWidget *window;
>
>GtkWidget *combo;
>GtkWidget *widget;
>GtkWidget *vbox;
>GtkWidget *hbox;
>
>gtk_init(&argc, &argv);
>
>window = gtk_window_new(GTK_WINDOW_TOPLEVEL);
>gtk_window_set_title(GTK_WINDOW(window), "BibMk");
>gtk_container_set_border_width(GTK_CONTAINER(window), 20);
>
>
>g_signal_connect(window, "delete-event",
>G_CALLBACK(gtk_main_quit), NULL);
>
>
>
>vbox = gtk_vbox_new(FALSE, 0);
>hbox = gtk_vbox_new(FALSE, 0);
>
>
>gtk_container_add(GTK_CONTAINER(window), hbox);
>
>
>gtk_box_pack_start(GTK_BOX(hbox), vbox, FALSE, FALSE, 0);
>
>
>
>
>
>combo = gtk_combo_box_text_new ();
>
>
>gtk_combo_box_text_append (GTK_COMBO_BOX_TEXT(combo), NULL, "  Loco  ");
>
>
>
>gtk_combo_box_text_append_text ( GTK_COMBO_BOX_TEXT(combo), "  Book
>  ");
>
>
>gtk_combo_box_text_append_text ( GTK_COMBO_BOX_TEXT(combo), "
>  Ladron  ");
>
>
>gtk_combo_box_text_append_text ( GTK_COMBO_BOX_TEXT(combo), "
>  Anibal Bigoton  ");
>
>
>gtk_widget_show(combo);
>
>
>
>
>
>gtk_box_pack_start(GTK_BOX(hbox), combo, TRUE, TRUE, 0);
>
>
>
>gtk_widget_show_all(window);
>gtk_main();
>
>
>
>
>
>
>
>
>return 0;
> }
>
>
>
> /***CODE END**/
>
>
>
>
>
>
>
> //////////
>
> ///
>
> //
>
>
>
> I am creating a combo-box with scrollbar with GTK 3.0 and VALA (gtk)
> . .as  the  COMBO-BOX  in   LibreOffice that have  in the   list of
> FONTS.
>
>
>
>
> I wrote an in GTK 3.0 widgets.
>
> If .  I  active   aPOPUP WINDOW   (POPUP WINDOW=MENU ) with a
> TOGGLEBUTTON... when you clicked the button to close the window.
>
> 1). First   . The  TOGGLEBUTTON is   off.  the  POPUP WINDOW   is
> hidden .
> 2) Then recently .  I can close the window.
> To here   all works fine.
>
>
> But I can not do the same with the buttons on the maximize and minimize
> WINDOW .. I must achieve the same effect as the widgets  ,   POPUP MENU
>  and   COMBO-BOX  ,   with  these events .
>
>
> If I  you   can help , I'll be grateful  .
>
> When  , you  have a  time. you can constestarme.
>
> Best   regards   . Mariano.
>
>
>
> this isthe code I've written in GTK 3.0.
>
>
>
>
> /
>
> //
>
>
>
>
>
> #include 
>
>
> enum
> {
>LIST_ITEM = 0,
>N_COLUMNS
> };
>
>
>
>
> static void  init_list(GtkWidget *list)
>
> {
>
>GtkCellRenderer *renderer;
>GtkTreeViewColumn *column;
>GtkListStore *store;
>
>renderer = gtk_cell_renderer_text_new();
>column = gtk_tree_view_column_new_with_attributes("List Items",
>   renderer, "text", LIST_ITEM, NULL);
>gtk_tree_view_append_column(GTK_TREE_VIEW(list), column);
>
>store = gtk_list_store_new(N_COLUMNS, G_TYPE_STRING);
>
>gtk_tree_view_set_model(GTK_TREE_VIEW(list),
>G

Re: GTK 3.0 inactive buttons (Buttons : maximize , minimize , close )

[Mariano Gaudix]

 In thePOPUP MENUand  COMBOBOX ... has these effects
...

If you activate a combo-box  or  menu ..and then   you clicked
the button  maximize or minimize of the  window   ...

this always happens


1). First   .Clicking the maximize or minimize button  of  the window  ...
. The  COMBO-BOXis disabled ... and  her menu option .


2)Second . Then recently .  I can close the window.



this always happens




//

 View   Example



///





/***THE CODE/
#include 




int main(int argc,
   char *argv[]) {



   GtkWidget *window;

   GtkWidget *combo;
   GtkWidget *widget;
   GtkWidget *vbox;
   GtkWidget *hbox;

   gtk_init(&argc, &argv);

   window = gtk_window_new(GTK_WINDOW_TOPLEVEL);
   gtk_window_set_title(GTK_WINDOW(window), "BibMk");
   gtk_container_set_border_width(GTK_CONTAINER(window), 20);


   g_signal_connect(window, "delete-event",
   G_CALLBACK(gtk_main_quit), NULL);



   vbox = gtk_vbox_new(FALSE, 0);
   hbox = gtk_vbox_new(FALSE, 0);


   gtk_container_add(GTK_CONTAINER(window), hbox);


   gtk_box_pack_start(GTK_BOX(hbox), vbox, FALSE, FALSE, 0);





   combo = gtk_combo_box_text_new ();


   gtk_combo_box_text_append (GTK_COMBO_BOX_TEXT(combo), NULL, "  Loco  ");



   gtk_combo_box_text_append_text ( GTK_COMBO_BOX_TEXT(combo), "  Book
 ");


   gtk_combo_box_text_append_text ( GTK_COMBO_BOX_TEXT(combo), "
 Ladron  ");


   gtk_combo_box_text_append_text ( GTK_COMBO_BOX_TEXT(combo), "
 Anibal Bigoton  ");


   gtk_widget_show(combo);





   gtk_box_pack_start(GTK_BOX(hbox), combo, TRUE, TRUE, 0);



   gtk_widget_show_all(window);
   gtk_main();








   return 0;
}



/***CODE END**/






//
///
//////////



I am creating a combo-box with scrollbar with GTK 3.0 and VALA (gtk)
. .as  the  COMBO-BOX  in   LibreOffice that have  in the   list of
FONTS.




I wrote an in GTK 3.0 widgets.

If .  I  active   aPOPUP WINDOW   (POPUP WINDOW=MENU ) with a
TOGGLEBUTTON... when you clicked the button to close the window.

1). First   . The  TOGGLEBUTTON is   off.  the  POPUP WINDOW   is
hidden .
2) Then recently .  I can close the window.
To here   all works fine.


But I can not do the same with the buttons on the maximize and minimize
WINDOW .. I must achieve the same effect as the widgets  ,   POPUP MENU
 and   COMBO-BOX  ,   with  these events .


If I  you   can help , I'll be grateful  .

When  , you  have a  time. you can constestarme.

Best   regards   . Mariano.



this isthe code I've written in GTK 3.0.



/
//





#include 


enum
{
   LIST_ITEM = 0,
   N_COLUMNS
};




static void  init_list(GtkWidget *list)

{

   GtkCellRenderer *renderer;
   GtkTreeViewColumn *column;
   GtkListStore *store;

   renderer = gtk_cell_renderer_text_new();
   column = gtk_tree_view_column_new_with_attributes("List Items",
  renderer, "text", LIST_ITEM, NULL);
   gtk_tree_view_append_column(GTK_TREE_VIEW(list), column);

   store = gtk_list_store_new(N_COLUMNS, G_TYPE_STRING);

   gtk_tree_view_set_model(GTK_TREE_VIEW(list),
   GTK_TREE_MODEL(store));

   g_object_unref(store);

}




static void  add_to_list(GtkWidget *list, const gchar *str)

{
   GtkListStore *store;
   GtkTreeIter iter;

   store = GTK_LIST_STORE(gtk_tree_view_get_model
   (GTK_TREE_VIEW(list)));

   gtk_list_store_append(store, &iter);
   gtk_list_store_set(store, &iter, LIST_ITEM, str, -1);
}







static void text( GtkWidget *widget , GdkEventButton *event, gpointer
buttonf)
{

   gtk_toggle_button_set_active(GTK_TOGGLE_BUTTON(buttonf),FALSE);


}





static void clicked1(GtkWindow *window, GdkEventButton *event, gpointer
buttonf)
{

   gtk_toggle_button_set_active(GTK_TOGGLE_BUTTON(buttonf),FALSE);


}



static void loc1(GtkWindow *window, GdkEventButton *event, gpointer buttonf)

{


   gtk_toggle_button_set_active(GTK_TOGGLE_BUTTON(buttonf),FALSE);


}




static void ponja2(GtkWindow *window, GdkE

Re: GTK 3.0 inactive buttons (Buttons : maximize , minimize , close )

[Tadej Borovšak]

Hello.

> Hello How I can make the buttons   are inactive  ,  the buttons  of
> the window  (Buttons : maximize , minimize , close )  or without focus when
> the pointer  isover  them ? 
> 
> I need to get the effect .   Caso 2 . View image
> 
> 
> http://fotos.subefotos.com/607c3fb8e19de4ed18357b85a33b3ab5o.png

This is not something you could do with GTK+, since window decorations
are usually handled by window manager. What window manager (desktop) are
you using? Maybe it can be themed to behave this way?

Cheers,
Tadej


-- 
Tadej Borovšak
tadej.borov...@gmail.com
tadeb...@gmail.com
tadeboro.blogspot.com

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

GTK 3.0 inactive buttons (Buttons : maximize , minimize , close )

[Mariano Gaudix]

Hello How I can make the buttons   are inactive  ,  the buttons  of
the window  (Buttons : maximize , minimize , close )  or without focus when
the pointer  isover  them ? 

I need to get the effect .   Caso 2 . View image


http://fotos.subefotos.com/607c3fb8e19de4ed18357b85a33b3ab5o.png
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: How to create irregularly shaped window with GTK+3.0

[Wen-Yen Chuang]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1,SHA512

jwm wrote:
> As far as I managed to work out, you must use cairo now which
> means the user must have desktop compositing enabled.

Ah, and the good news, the code in gcin do work on all window managers,
even on those has no compositing supported. :-)

Kind regards
 Wen-Yen Chuang (caleb)
-BEGIN PGP SIGNATURE-

iEYEARECAAYFAk6AgeoACgkQdEpXpumNYVkMwACfa3oPPaUZ9F4b5ezPY7Ri2F3D
SoUAnjF8/koNWqGfWO/4kGVJPV3pNBQXiQIcBAEBCgAGBQJOgIHqAAoJELc3H0m+
i6gZPhsP/RjHmWlv164moszHbrdo5uKRWXXbs3SXkX3lmkAs/gY9uK9sSpSQWKfx
GxclWddbMpXWTzK/CX0lZ8+Ojrp8P0SxfYKjmusUki47N9kRn4a9GpVOhNHVU5Fi
H/Hgygh/6rtHARLM4dkE85YrXnkG/GU7AijYAqnMEbPA0iRnmNyLKkg+NseepjY0
vw0ZxPaHRLxjLZg9B7ArQz4VD3WvwyjEj8y83oGwJAu+BxnYs1Kb6wKk2aMpGtWS
P2KYDm3LRu5q/ZlsLBDHi5JCQCtYYFBPy+2JRfr0rOEs/hUhd+pixAplQVXbAeHf
8PscFL7RSm6h5WhDOtp2CTyLcVUF7YMrdgXOip+lkkbW9PLwDMfpyilmCoUCi4pI
KV6n9vocLNZa1ks0cm+2kDGkRN8kdBELA2k+WnC9S/+Hdq2TVf/3Bjk7YyZ/ihP0
vtThxsd0HTOFC8+2bJ6jTUPAdEIrbgNLcJdKuLfhEfva9C0ZADDA4MyhMCnOClEM
PwbZxwHRR96lcPlQAFuaerUVXGaqztJuX3fArWO0sq3P6j9bxoXw0k9hOySjsP10
UgjxnLLNuL5vGFqpJ1UWWhC462z136aOZ6KVsiCixqKjyYHzddFmogu31m2/Nov9
QPrJnmmMC0kmaQU06zU6H8nj2Zk8EkzQ4gvso+CTC6DoNCpy8AZi
=taFv
-END PGP SIGNATURE-
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: How to create irregularly shaped window with GTK+3.0

[Wen-Yen Chuang]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1,SHA512

Weitian Leung wrote:

> I used to simply call gtk_widget_shape_combine_mask and 
> gdk_window_set_back_pixmap to create the irregularly-shaped window 
> with the png image with gtk+2.0.

I happened to know one working code snippet existed in
an input method server called "gcin".
The attached codes works for all image format that GTK+ supports,
and also works for animated gif files.

Kind regards
 Wen-Yen Chuang (caleb)
-BEGIN PGP SIGNATURE-

iEYEARECAAYFAk6AgGUACgkQdEpXpumNYVl73wCdHpK7/Tefxm02kYZJouSWm7CF
qMwAn2qDZckRct+agytpu7GDc0YhWGNtiQIcBAEBCgAGBQJOgIBlAAoJELc3H0m+
i6gZHOEQAIr/QE5QMDNKCu2G4klwor+JkiHKuBm3kpm++pixT2DAo2N0DJDkaHns
XXcirFcJxb6pYXPFoM+kPA9uZp9EdmS8xpjNAutLxi/z64LRyNDKrCFWIbVsDJvL
mqJo2nQ/McEGpTx7kL+qpYUbzu+RY7ylTQlyr8+DwnyrgNN2runrJ2qz113tl5gI
dYxGer4LaE2Pkbn/KQdgPZLy02l46HjWqqGutY13hPuASKkFPLjsVWmURvblQHEx
4tXwYcRvg7cbOp1wDjIi51UX5tGNakXcBFGOoMIULesUOLOaPGtwvBqG0TxaB3bM
7gMQVYZ2sMjVcW7EhM9UcWvutn9z4DkXB2ERovMjLSsmTQRFx1Jx+u5xm//3cddL
SXf6bk40zJ6+/q+N2PrkYDUE9smXd+xuVf07tjNbkeLljLuSeKNs1DxW4hmE7eq0
IOa+H3a2cV0mLsmvDqCnqfqaB3zBq8crI0Z2z95MDJJMDpTvLxVSygIK5f78imRT
F6XAxALPUCgBjMz/iBiNwFHs1iBRpcNZ72DHpYyxZ8n/6rZZcTwDr+O7CrEJbM1P
HjblEQbS8INfXfknGUi36CwPTi1aj0dONjIlVTxIlBNB0139C6hM9goL1ucak7SJ
9/5Rv8KnCWoAw44fJB21Kpl+IYc7NXqK316YoYHobFfkw5ICERz8
=Ucjr
-END PGP SIGNATURE-
#if GTK_CHECK_VERSION(2,91,0)
  GdkPixbuf *pixbuf = NULL;
  GdkPixbufAnimation *anime = NULL;
  switch(gtk_image_get_storage_type(GTK_IMAGE(image))) {
case GTK_IMAGE_PIXBUF:
  pixbuf = gtk_image_get_pixbuf(GTK_IMAGE(image));
  break;
case GTK_IMAGE_ANIMATION:
  anime = gtk_image_get_animation(GTK_IMAGE(image));
  pixbuf = gdk_pixbuf_animation_get_static_image(anime);
  break;
default:
  break;
  }
  cairo_surface_t *img = cairo_image_surface_create(CAIRO_FORMAT_ARGB32, 
gdk_pixbuf_get_width(pixbuf), gdk_pixbuf_get_height(pixbuf));
  cairo_t *cr = cairo_create(img);
  gdk_cairo_set_source_pixbuf(cr, pixbuf, 0, 0);
  cairo_paint(cr);
  cairo_region_t *mask = gdk_cairo_region_create_from_surface(img);
  gtk_widget_shape_combine_region(gwin_message, mask);
  cairo_region_destroy(mask);
  cairo_destroy(cr);
  cairo_surface_destroy(img);
#else
  GdkBitmap *bitmap = NULL;
  gdk_pixbuf_render_pixmap_and_mask(gdk_pixbuf_new_from_file(icon, NULL), 
NULL, &bitmap, 128);
  gtk_widget_shape_combine_mask(gwin_message, bitmap, 0, 0);
#endif
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: How to create irregularly shaped window with GTK+3.0

[jwm . art . net]

As far as I managed to work out, you must use cairo now which means the user 
must have desktop compositing enabled. Either that or you must be a gold medal 
winning low-level xlib gymnast!?!? 

This was in gtk2 with all the deprecation enabled flags. 
--Original Message--
From: Weitian Leung
Sender: gtk-app-devel-list-boun...@gnome.org
To: gtk-app-devel-list@gnome.org
Subject: How to create irregularly shaped window with GTK+3.0
Sent: 20 Sep 2011 10:16


Hi All,

I wonder how to create irregularly shaped window with gtk+3.0.

I used to simply call gtk_widget_shape_combine_mask and
gdk_window_set_back_pixmap to create the irregularly-shaped window
with the png image with gtk+2.0.

Now I can't find any useful information how with gtk+3.0.
Could any one help me out?

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


Sent using BlackBerry® from Orange
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

How to create irregularly shaped window with GTK+3.0

[Weitian Leung]

Hi All,

I wonder how to create irregularly shaped window with gtk+3.0.

I used to simply call gtk_widget_shape_combine_mask and
gdk_window_set_back_pixmap to create the irregularly-shaped window
with the png image with gtk+2.0.

Now I can't find any useful information how with gtk+3.0.
Could any one help me out?

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

Gtk 3.0 API and display issues

[Michael Cronenworth]

I tried to convert a GTK 2.0 app to GTK 3.0 and ran into a few things:

1. It was pretty nasty of the GTK/Gnome folks to, at the very last 
minute, deprecate and change gtk_combo_box_new_text() to GtkComboBoxText.


2. The GTK 3.0 API references "gtk_combo_box_text_remove_text()" but the 
compiler complains the function is undefined. This is essentially a show 
stopper for converting my app.


3. Temporarily removing the *_remove_text() calls and running the app 
shows that the default GTK 3.0 theme does not display GtkFrame widgets. 
Another show stopper.


Should I file bugs? or are these known issues? or am I doing something 
wrong?


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

Re: Gtk 3.0 Build

[Emmanuele Bassi]

On 2011-03-28 at 17:24, Craig Bakalian wrote:

> Yes, Yes.  I just read through this subject, or gleaned it.  Is there an
> code example of theme - ing in gtk3.0 anywhere in internet land?

http://library.gnome.org/devel/gtk3/stable/GtkCssProvider.html

ciao,
 Emmanuele.

-- 
W: http://www.emmanuelebassi.name
B: http://blogs.gnome.org/ebassi
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Gtk 3.0 Build

[Allin Cottrell]

On Mon, 28 Mar 2011, Craig Bakalian wrote:

> Yes, Yes.  I just read through this subject, or gleaned it.  Is there an
> code example of theme - ing in gtk3.0 anywhere in internet land?

If you want to see how the CSS works, take a look at adwaita.css.

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

Re: Gtk 3.0 Build

[Craig Bakalian]

Hi Allin,

Yes, Yes.  I just read through this subject, or gleaned it.  Is there an
code example of theme - ing in gtk3.0 anywhere in internet land?

Craig Bakalian


On Mon, 2011-03-28 at 17:05 -0400, Allin Cottrell wrote:
> On Mon, 28 Mar 2011, Craig Bakalian wrote:
> 
> > Also, I am running Ubuntu 11.04.  When the window loads it is a generic
> > theme-  It doesn't match my appearance theme choice.  Anyone know what
> > is up with that?
> 
> The GTK theming apparatus has changed quite radically between 2.N
> and 3.0. Old theme files won't work.
> 
> Allin Cottrell


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

Re: Gtk 3.0 Build

[Allin Cottrell]

On Mon, 28 Mar 2011, Craig Bakalian wrote:

> Also, I am running Ubuntu 11.04.  When the window loads it is a generic
> theme-  It doesn't match my appearance theme choice.  Anyone know what
> is up with that?

The GTK theming apparatus has changed quite radically between 2.N
and 3.0. Old theme files won't work.

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

Gtk 3.0 Build

[Craig Bakalian]

Hi,

I finally clean up my application and it builds in 3.0 with GtkBuilder
as its gui.  But there is one problem - what is causing the Gtk-WARNING
of 

menu_proxy_module_load : /home/craig/MusicEditor/musiceditor: undefined
symbol: menu_proxy_module_load

my code does not explicitly call the function, so it has to be something
in GtkBuilder and Menu Items or ?

So, anyone know what is going on here?

Also, I am running Ubuntu 11.04.  When the window loads it is a generic
theme-  It doesn't match my appearance theme choice.  Anyone know what
is up with that?




-- 
Craig Bakalian 

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

gtk_widget_set_events in gtk+-3.0

[czk]

I need a GtkProgressBar that can be drag by mouse. So I write the following
code and it work well in gtk+-2.x:

   1. #include 
   2.
   3. gboolean progress_button_release (GtkWidget *progress, GdkEvent
   *event, gpointer data);
   4. gboolean progress_button_press (GtkWidget *progress, GdkEvent *event,
   gpointer data);
   5. gboolean progress_motion_notify (GtkWidget *progress, GdkEvent *event,
   gpointer data);
   6.
   7. int main (int argc, char* argv[])
   8. {
   9.   GtkWidget *window;
   10.   GtkWidget *label;
   11.   GtkWidget *progress;
   12.   GtkWidget *vbox;
   13.
   14.   gtk_init (&argc, &argv);
   15.
   16.   window = gtk_window_new (GTK_WINDOW_TOPLEVEL);
   17.   gtk_widget_set_size_request (window, 400, 300);
   18.
   19.   label = gtk_label_new ("mouse progress bar");
   20.   gtk_widget_show (label);
   21.
   22.   progress = gtk_progress_bar_new ();
   23.   gtk_widget_show (progress);
   24.   gtk_widget_set_size_request (progress, -1, 30);
   25.   gtk_progress_bar_set_fraction (GTK_PROGRESS_BAR(progress), 0.2);
   26.
   27.   gtk_widget_add_events (progress, GDK_BUTTON_RELEASE_MASK |
   28.GDK_BUTTON_PRESS_MASK   |
   29.
   GDK_POINTER_MOTION_MASK );
   30.   g_signal_connect (progress, "button-release-event",
   31. G_CALLBACK (progress_button_release), NULL);
   32.   g_signal_connect (progress, "button-press-event",
   33. G_CALLBACK (progress_button_press), NULL);
   34.   g_signal_connect (progress, "motion-notify-event",
   35. G_CALLBACK (progress_motion_notify), NULL);
   36.
   37.
   38.   vbox = gtk_vbox_new (FALSE, 5);
   39.   gtk_widget_show (vbox);
   40.
   41.   gtk_box_pack_start (GTK_BOX(vbox), label, FALSE, FALSE, 5);
   42.   gtk_box_pack_start (GTK_BOX(vbox), progress, TRUE, FALSE, 5);
   43.
   44.   gtk_container_add (GTK_CONTAINER(window), vbox);
   45.
   46.   gtk_widget_show (window);
   47.
   48.   gtk_main ();
   49.
   50.   return 0;
   51. }
   52.
   53. gboolean
   54. progress_button_release (GtkWidget *progress, GdkEvent *event,
   gpointer data)
   55. {
   56.   GdkEventButton *eb = (GdkEventButton *)event;
   57.   GtkAllocation allocation;
   58.   gint pressed;
   59.
   60.   pressed = (gint)g_object_get_data (G_OBJECT(progress), "pressed");
   61. #if GTK_MINOR_VERSION >= 18
   62.   gtk_widget_get_allocation (progress, &allocation);
   63. #else
   64.   allocation = progress->allocation;
   65. #endif
   66.   if (pressed)
   67. gtk_progress_bar_set_fraction (GTK_PROGRESS_BAR(progress), eb->x
   / (allocation.width * 1.0));
   68.
   69.   g_object_set_data (G_OBJECT(progress), "pressed", (gpointer)0);
   70.   return FALSE;
   71. }
   72.
   73. gboolean
   74. progress_button_press (GtkWidget *progress, GdkEvent *event, gpointer
   data)
   75. {
   76.   g_object_set_data (G_OBJECT(progress), "pressed", (gpointer)1);
   77.   return FALSE;
   78. }
   79.
   80. gboolean
   81. progress_motion_notify (GtkWidget *progress, GdkEvent *event,
   gpointer data)
   82. {
   83.   GdkEventMotion *em = (GdkEventMotion *)event;
   84.   gint pressed;
   85.   GtkAllocation allocation;
   86.
   87.   pressed = (gint)g_object_get_data (G_OBJECT(progress), "pressed");
   88. #if GTK_MINOR_VERSION >= 18
   89.   gtk_widget_get_allocation (progress, &allocation);
   90. #else
   91.   allocation = progress->allocation;
   92. #endif
   93.   if (pressed)
   94.   {
   95. gdouble fraction = em->x / (allocation.width * 1.0);
   96. if (fraction > 1.0)
   97.   fraction = 1.0;
   98. if (fraction < 0.0)
   99.   fraction = 0.0;
   100. gtk_progress_bar_set_fraction (GTK_PROGRESS_BAR(progress),
   fraction);
   101.   }
   102.
   103.   return FALSE;
   104. }

But it cannot work in Gtk+-3.0, I read the souce code in gtk+-3.0 tar.bz2
($GTK_SOURCE_ROOT/tests/testinput.c), and modify my code after testinput.c:
#include 

gboolean progress_button_release (GtkWidget *progress, GdkEvent *event,
gpointer data);
gboolean progress_button_press (GtkWidget *progress, GdkEvent *event,
gpointer data);
gboolean progress_motion_notify (GtkWidget *progress, GdkEvent *event,
gpointer data);

int main (int argc, char* argv[])
{
  GtkWidget *window;
  GtkWidget *label;
  GtkWidget *progress;
  GtkWidget *vbox;
  GList *devices, *walk;
  GdkDeviceManager *device_manager;
  GdkEventMask event_mask;

  gtk_init (&argc, &argv);

  device_manager = gdk_display_get_device_manager (gdk_display_get_default
());
  devices = gdk_device_manager_list_devices (device_manager,
GDK_DEVICE_TYPE_FLOATING);

  window = gtk_window_new (GTK_WINDOW_TOPLEVEL);
  gtk_widget_set_size_request (window, 400, 300);

  label = gtk_label_new ("mouse progress bar");
  gtk

Re: GTK 3.0 / OpenGL

[Emmanuele Bassi]

On 2011-02-20 at 23:28, Carlos Pereira wrote:
 
> Are there significant changes regarding OpenGL integration with GTK
> 3.* and Cairo, when compared with GTK 2.*?

no.

ciao,
 Emmanuele.

-- 
W: http://www.emmanuelebassi.name
B: http://blogs.gnome.org/ebassi
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

GTK 3.0 / OpenGL

[Carlos Pereira]

Hi all,

Are there significant changes regarding OpenGL integration with GTK 3.* 
and Cairo,

when compared with GTK 2.*?

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

Re: drawing with GTK 3.0

[Allin Cottrell]

On Sat, 12 Feb 2011, Allin Cottrell wrote:

> I've got my app to build against gtk 3.0 but I'm having trouble
> getting some drawing code ported...

Ah, I now see what part of my problem was: I hadn't looked up the
latest signature for the GtkWidget "draw" callback. I had this as

> void plot_draw (GtkWidget *canvas, GdkRectangle *rect,
> gpointer data)

but the second argument should now be a cairo_t * (the doc
actually says a "CairoContext *", but does that type exist?).
So my revised callback looks like this:

void plot_draw (GtkWidget *widget, cairo_t *cr, gpointer data)
{
png_plot *plot = data;

gdk_cairo_set_source_pixbuf(cr, plot->pixbuf, 0, 0);
cairo_paint(cr);
}

Now my image will display, but dynamic changes to the image (e.g.
rubber-banding of a selection rectangle) that were smooth in gtk
2.24 are now jerky, and I guess this is because the above code
(re-)paints the entire image, whereas the gtk 2.24 version gets an
event rectangle from the "expose-event" signal and so redraws only
the affected area. If that diagnosis is plausible (?) how can we
avoid doing a full redraw with the new mechanism?

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

drawing with GTK 3.0

[Allin Cottrell]

I've got my app to build against gtk 3.0 but I'm having trouble
getting some drawing code ported. It was OK as of the
"transitional" state part-way through Benjamin Otte's gdk cleanup
and it works with gtk 2.24, but my attempt at gtk 3.0 code fails:
I get an empty canvas window where there's supposed to be an
image.

I'd be very grateful if anyone can tell me what I'm missing. Below
is an extract of code showing what works and what doesn't; I've
tried to keep it to the minimal relevant portion. ("plot" is just
a wrapper struct for the various bits and pieces: it has a
GdkPixmap member in the 2.24 variant and I'm struggling to figure
how exactly that should be replaced.)

0. basic setup of canvas

common to gtk 2.24, gtk 3.0 --

plot->canvas = gtk_drawing_area_new();
gtk_widget_set_size_request(GTK_WIDGET(plot->canvas),
plot->pixel_width, plot->pixel_height);
gtk_widget_set_events (plot->canvas, GDK_EXPOSURE_MASK
   | GDK_LEAVE_NOTIFY_MASK
   | GDK_BUTTON_PRESS_MASK
   | GDK_BUTTON_RELEASE_MASK
   | GDK_POINTER_MOTION_MASK
   | GDK_POINTER_MOTION_HINT_MASK);
gtk_widget_show(plot->canvas);
gtk_widget_realize(plot->canvas);

gtk 2.24 --

gdk_window_set_back_pixmap(gtk_widget_get_window(plot->canvas),
   NULL, FALSE);
plot->pixmap = gdk_pixmap_new(gtk_widget_get_window(plot->canvas),
  plot->pixel_width, plot->pixel_height,
  -1);
g_signal_connect(G_OBJECT(plot->canvas), "expose-event",
 G_CALLBACK(plot_expose), plot);

gtk 3.0 --

/* no counterpart to pixmap operations above? */
g_signal_connect(G_OBJECT(plot->canvas), "draw",
 G_CALLBACK(plot_draw), plot);

1. initialize with GdkPixbuf, pbuf, obtained from PNG file:

gtk 2.24 --

plot->cr = gdk_cairo_create(plot->pixmap);
gdk_cairo_set_source_pixbuf(plot->cr, pbuf, 0, 0);
cairo_paint(plot->cr);
cairo_destroy(plot->cr);
g_object_unref(pbuf); /* done with pbuf */

gtk 3.0 --

plot->cr = gdk_cairo_create(gtk_widget_get_window(plot->canvas));
gdk_cairo_set_source_pixbuf(plot->cr, pbuf, 0, 0);
cairo_paint(plot->cr);
cairo_destroy(plot->cr);
plot->pixbuf = pbuf; /* need to attach pbuf? */

2. "expose-event"/"draw" callback:

gtk 2.24 --

void plot_expose (GtkWidget *canvas, GdkEventExpose *event,
  gpointer data)
{
GdkWindow *window = gtk_widget_get_window(canvas);
png_plot *plot = data;

plot->cr = gdk_cairo_create(window);
gdk_cairo_set_source_pixmap(plot->cr, plot->pixmap, 0, 0);
gdk_cairo_rectangle(plot->cr, &event->area);
cairo_fill(plot->cr);
cairo_destroy(plot->cr);
}

gtk 3.0

void plot_draw (GtkWidget *canvas, GdkRectangle *rect,
gpointer data)
{
GdkWindow *window = gtk_widget_get_window(canvas);
png_plot *plot = data;

plot->cr = gdk_cairo_create(window);
/* ?? */
gdk_cairo_set_source_pixbuf(plot->cr, plot->pixbuf, 0, 0);
gdk_cairo_rectangle(plot->cr, rect);
cairo_fill(plot->cr);
cairo_destroy(plot->cr);
}

-- 
Allin Cottrell
Department of Economics
Wake Forest University

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

Re: Some questions about Gtk+3.0 2.90

[Ardhan Madras]

Why the application need to move to GTK+ 3 which still in development progress?

Ardhan


--- eba...@gmail.com wrote:

From: Emmanuele Bassi 
To: gtk-app-devel-list@gnome.org
Subject: Re: Some questions about Gtk+3.0 2.90
Date: Mon, 23 Aug 2010 13:28:25 +0100

On Mon, 2010-08-23 at 13:24 +0100, haithem rahmani wrote:

> I'm planning to move my application to gtk+3.0 2.90
> so I've some questions about it:
> 
> - Is it API compatible with gtk+2.0 ?

no.

> - does it provide a working DirectFB backend ?

no.

ciao,
 Emmanuele.

-- 
W: http://www.emmanuelebassi.name
B: http://blogs.gnome.org/ebassi

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




_
Listen to KNAC, Hit the Home page and Tune In Live! ---> http://www.knac.com
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Some questions about Gtk+3.0 2.90

[Emmanuele Bassi]

On Tue, 2010-08-24 at 22:44 -0700, Ardhan Madras wrote:

> Why the application need to move to GTK+ 3 which still in development 
> progress?

because after gtk+ 2.24 is released, in parallel with gtk+ 3.0 this
December, the 2.x branch goes into deep maintainance mode: no further
releases will be done and only patches fixing critical bugs will be
applied.

gtk+ 3.0 is the next major version: new features will only be added
there.

this is the "grace period" when application developers can still
influence the API and feature set of 3.x; after 3.0 has been released,
the API and ABI guarantees come into effect and you'll have to wait
until 4.x for another API/ABI break.

obviously, distributions will still package gtk+ 2.0 for the foreseeable
future, so you don't *have* to port your application *now*.

ciao,
 Emmanuele.

-- 
W: http://www.emmanuelebassi.name
B: http://blogs.gnome.org/ebassi

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

Re: Some questions about Gtk+3.0 2.90

[Emmanuele Bassi]

On Mon, 2010-08-23 at 13:24 +0100, haithem rahmani wrote:

> I'm planning to move my application to gtk+3.0 2.90
> so I've some questions about it:
> 
> - Is it API compatible with gtk+2.0 ?

no.

> - does it provide a working DirectFB backend ?

no.

ciao,
 Emmanuele.

-- 
W: http://www.emmanuelebassi.name
B: http://blogs.gnome.org/ebassi

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

Some questions about Gtk+3.0 2.90

[haithem rahmani]

Hi all,
I'm planning to move my application to gtk+3.0 2.90
so I've some questions about it:

- Is it API compatible with gtk+2.0 ?
- does it provide a working DirectFB backend ?

regards.

-- 
Be to GOD as he wants ,
HE'll be for you more
than what you want.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

RE: GtkGLExt (was Re: Gtk 3.0)

[Shawn Bakhtiar]

Well... this seems to turn on a few flames... so let me put some of this to 
rest.
For anyone to say OpenGL is "niche", and does not apply to everyday apps, I 
again remind you of iChat and the OS X Panel. Granted it has only recently 
found prominence in the desktop but it is quickly making way as OGL hardware 
acceleration becomes standardize (has been for some time). 
To look back at the past decade and say "look desktops are all 2D", not 
realizing it has to do with memory and CPU/GPU issues, which are no longer 
issues is simply wrong.
The next decade of desktops, more importantly GUI (Graphical USER <-- hello!!! 
Interfaces) WILL have a blinding array of 3D widgets which will be like eye 
candy to most users, and as they see it they will want it more and more. 
I do NOT work at a facility which requires 3D visualization to accomplish its 
tasks, but users are starting to ask and want. "Can I do a walkthrough of our 
warehouse to see how much material I have?", "Can we have a little computerized 
white box, with a virtualized pallet to do color matching in?" This has NOTHING 
to do with scientific engineering or "niche" market. It has to do with the 
future of interface design. I work in a ink manufacturing plant, and by that 
argument, we should mix it all by hand, since that is how they did it 5000 
years ago! 2D is NOT the end of all GUIs. It simply is not! R2 space can not 
hold as much date/widgets/whatever as R3 even if the axis were infinite! they 
(users) want 3D buttons that pop, role, jump, and wink at them too. They want 
there pictures to start bending, bouncing, and getting all organic on them. 
To say that GTK does NOT need OGL, is to say they sun is not going to rise in 
the morning. To say that GTKGLext (a great tool to be sure) is good enough, is 
to slap a hand in the face of all of use who see where this is going. 
The greatest problem with the linux community (one I myself am having to learn 
about) is this indelible ego that the data and function has to be correct and 
nothing else. Sorry if the user can not visually keep up or understand what 
you present, it won't make a difference how good the app works in the back, it 
IS the eye candy that gets the user to use it. GtkTreeview in 3D? I can thing 
of a dozen categorization applications in seconds.

FYI - OS X is a FreeBSD engin, with NextStep as its windowing system. It uses 
OGL IN the windowing system (quartz / composer), and it is the hottest desktop 
on the market. No one, and I mean no one, has even come close!
And lets not forget all the work that is being done on Compiz why? For the 
masochism of it?!? No! Because that is where the future of desktop are, in 3D 
space!
IMMHO, if Gtk is to keep up, as the cross platform interface it promises to be, 
it will need OGL to be fully modularized or integrated somehow. I don't even 
think GtkGLExt is that far, other than the OS X side of it, which with demand 
will certainly improve.
P.S.the comment: " Ah. You are such a loser. Go away.", has no business on this 
forum, the point is a good one, and your minimization of it, a poor show of 
understanding.

 EMAILING FOR THE GREATER GOOD
Join me

> Date: Sat, 5 Dec 2009 19:48:06 +0100
> From: y...@physics.muni.cz
> To: jose.carlos.pere...@ist.utl.pt
> Subject: Re: GtkGLExt (was Re: Gtk 3.0)
> CC: gtk-app-devel-list@gnome.org
> 
> On Sat, Dec 05, 2009 at 04:22:36PM +, Carlos Pereira wrote:
> > We must atract more scientifc/engineering applications for Linux and  
> > GTK, because this is exactly the kind of stuff that enterprises and  
> > universities are demanding.
> >
> > If we have fantastic operating systems and desktop environments in the  
> > free software world, but most of the scientific/engineering aplications  
> > only run in Windows/Mac OS X, people will be forced to use them, even if  
> > they would rather prefer to use Linux/BSD... I have many friends in this  
> > situation...
> 
> I'm afraid you explain it from your viewpoint.  But looking at your
> reasoning from the `desktop' viewpoint there are troubles.
> 
> 1) Objective.  There will never ever be a scientific `killer app'.
> Every little branch of science, or even an individual scientific
> problem, has specific needs.  Hence the applications are inherently
> scattered and each individual app is used only by a small group of
> people.  Even the `universal' commerical tools such as Matlab are far
> from being universally used [among scientists].  This makes hard to see
> sci/eng apps matter *at all*.
> 
> 2) Subjective.  Do your graphs have round corners and include the user's
> IM status?  Can your data acquistion software synchronize the data with
> an iPod?  Are your reports summarized to 140 characters and sent to
> Twitter?

Re: GtkGLExt (was Re: Gtk 3.0)

[David Nečas]

On Sat, Dec 05, 2009 at 04:22:36PM +, Carlos Pereira wrote:
> We must atract more scientifc/engineering applications for Linux and  
> GTK, because this is exactly the kind of stuff that enterprises and  
> universities are demanding.
>
> If we have fantastic operating systems and desktop environments in the  
> free software world, but most of the scientific/engineering aplications  
> only run in Windows/Mac OS X, people will be forced to use them, even if  
> they would rather prefer to use Linux/BSD... I have many friends in this  
> situation...

I'm afraid you explain it from your viewpoint.  But looking at your
reasoning from the `desktop' viewpoint there are troubles.

1) Objective.  There will never ever be a scientific `killer app'.
Every little branch of science, or even an individual scientific
problem, has specific needs.  Hence the applications are inherently
scattered and each individual app is used only by a small group of
people.  Even the `universal' commerical tools such as Matlab are far
from being universally used [among scientists].  This makes hard to see
sci/eng apps matter *at all*.

2) Subjective.  Do your graphs have round corners and include the user's
IM status?  Can your data acquistion software synchronize the data with
an iPod?  Are your reports summarized to 140 characters and sent to
Twitter?  No?  Does your app help people with some difficult to
understand and much more difficult to solve problems instead of
facilitating idle chit-chat while consuming power for visual effects?
Ah.  You are such a loser.  Go away.

Regards,

Yeti

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

Re: GtkGLExt (was Re: Gtk 3.0)

[Carlos Pereira]

Dear Emmanuele,

yes. and that, apart from games and scientific/technical applications, it's not 
at all common.
  


the amount of code using OpenGL is relatively limited (hence "niche") compared 
to the rest of applications in the GNOME stack (or even in the whole Linux ecosystem); 
it's *usage* is limited, not the size of the codebase.
  
If you go to Amazon and search for OpenGL books, you get this  list with 
2607 (!!!) results:


http://www.amazon.com/s/ref=nb_ss?url=search-alias%3Dstripbooks&field-keywords=opengl&x=20&y=19

Many of these books have been published in the last 5 years, some in 
2008 and even 2009.


The fact is, the OpenGL community is much larger than our GTK community. 
If scientific/engineering applications are a niche in the GTK world, 
that is not a OpenGL weakness, that is a GTK weakness.


We must atract more scientifc/engineering applications for Linux and 
GTK, because this is exactly the kind of stuff that enterprises and 
universities are demanding.


If we have fantastic operating systems and desktop environments in the 
free software world, but most of the scientific/engineering aplications 
only run in Windows/Mac OS X, people will be forced to use them, even if 
they would rather prefer to use Linux/BSD... I have many friends in this 
situation...


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

Re: GtkGLExt (was Re: Gtk 3.0)

[Ralf Corsepius]

On 12/05/2009 12:28 AM, Emmanuele Bassi wrote:

On Fri, 2009-12-04 at 18:11 -0500, Braden McDaniel wrote:

I have the impression that my message is not coming through correctly,
because I keep saying the same things. :-)


I never said that raw OperGL is not used, or not useful; I just contend
that being able to  drop into GL directly is a niche usage - and it's
not getting any more mainstream.


It is a common requirement for apps that want to do 3D rendering with a
cross-platform codebase.


yes. and that, apart from games and scientific/technical applications,
it's not at all common.


  Biting off Clutter and its dependency chain is
not something developers of such an app are likely to want to incur; and
Clutter probably won't provide adequate functionality in a lot of cases.


which dependency chain? it's the same as gtk+.


the most people care about, as I said, is being able to accelerate
drawing primitives and blending modes and hand them over to the GPU;
mostly, for 2D-inside-3D environments -- see Clutter, cairo-gl and
cairo-drm.


The volume of code currently using Clutter, cairo-gl, and cairo-drm
would be dwarfed by that using OpenGL directly.

I think your use of the term "niche" is a little unusual.


Agreed.


the amount of code using OpenGL is relatively limited

Correct - Now ask yourself why.

IMO, the causes historically have been and are:
- Lack of usable drivers, esp. on Linux.
- Demands on CPU-powers (10 years ago, even simple wire-frame graphics 
were a CPU challenge on Linux).
- For most desktop applications 2D is sufficient, even less need 
"advanced 3D".


Historically, these reasons were both causes for GUI-toolsets (such as 
Gnome) to favor other toolset libs on their low levels in favor of other 
toolset libs.


The situation would be entirely different today, if Linux had performant 
OpenGL drivers and if GUI toolchains would have based their graphics 
works directly on OpenGL (or any other performant, low level 3D graphics 
API).



Clutter is a new project, compared to OpenGL, and yet *it's* *not*
intended to cover the same usage of OpenGL. its intended use covers a
canvas for writing applications, not molecule viewers or 3D shooters.
Future will tell if this isn't much more than "yet another 3D library" 
amongst those many already existing ones ;)



that's why GtkGLExt can still be perfectly fine outside of the gtk+
codebase; it provides much more than setting up a GL context, which
would be the agreed API for gtk+ to expose, and given the amount of
applications actively requiring to drop into GL without any sort of
canvas, then it might make sense to keep GtkGLExt exactly as it is.
Agreed. Besides fixing bugs and reflecting Gtk API changes to it, I 
don't see much reasons for changing anything.


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

Re: GtkGLExt (was Re: Gtk 3.0)

[Jack Skellington]

On Fri, Dec 4, 2009 at 8:02 PM, Emmanuele Bassi  wrote:
> (Sorry, I'm sending this via my phone so it's not going to be nicely
> formatted; I apologize)
>
> I'm really not working on it - mainly for three reasons: 1) if you want to
> use GL, GtkGlExt is "good enough" and integrating it into gtk+ it's not a
> good idea; 2) cairo should get GPU acceleration for 2D drawing, which is
> what most of users really care about; 3) if you want a 3D canvas you should
> be using Clutter.

If you want to do ACTUAL 3D rendering your choises are OpenGL and OpenGL,
Clutter doesn't come anywhere near it.
It's true that the API is getting better in 3.0+ but you can still do
the same with 2.0+.
Also it's a matter of personal taste.
At the dawn of time John Carmack chose OpenGL and urged all GPU
vendors to make OpenGL drivers
because of the horrible DirectX API.
Of course DirectX has come a long way since, but if you want any form
of cross-platform support
your only choice is still OpenGL.

> Integrating raw GL inside a gtk+ application is a niche requirement enough
> that I'm not at all sure it should be moved to gtk+ itself. And if you're
> dropping into raw GL there is no way you are not a niche use case.

It may be niche as in not many apps use it, but that hardly makes it
any less important.
When companies like Autodesk ports ther many many $$$ apps
to Linux they don't have the choice of using GTK+
As far  as I can tell GTK+ is the only widget API on any PC platform
that doesn't have an OpenGL widget/view.
Not being able to use advanced 3D visualizations in modern day apps
seems rather odd IMNSHO.

Regards
Jacob Kolding

>
> On 4 Dec 2009 18:13, "Carlos Pereira" 
> wrote:
>
> Thanks Javier,
> it's good to know that EmmanueleBassi 
> is now taking care of GtkGLExt integration with GTK...
>
> Regards,
> Carlos
>
>> > Hello Carlos, > > 2009/12/3 Carlos Pereira <
> jose.carlos.pere...@ist.utl.pt>: >   >> >> That's w...
>
> ___ gtk-app-devel-list mailing
> list gtk-app-devel-l...@g...
> ___
> gtk-app-devel-list mailing list
> gtk-app-devel-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
>
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: GtkGLExt (was Re: Gtk 3.0)

[Javier Jardón]

2009/12/4 Carlos Pereira :
> 3) However GtkGlExt is not GTK-3.0 ready, because it cannot be compiled with
> SEAL_ENABLE and SINGLE_INCLUDES...

Bug and patch filled upstream for SINGLE_INCLUDES issue: [1]

Also, I've found some interesting threads about this topic here [2]
(Sept 2003) and here [3] (Jan 2004).
There was a initial RFC here: [4], attached in the bug [5] I posted in
the previous mail.

Regards.

[1] https://bugzilla.gnome.org/show_bug.cgi?id=603829
[2] http://mail.gnome.org/archives/gtk-devel-list/2003-September/msg00220.html
[3] http://mail.gnome.org/archives/gtk-devel-list/2004-January/msg00169.html
[4] http://bugzilla-attachments.gnome.org/attachment.cgi?id=22045
[5] https://bugzilla.gnome.org/show_bug.cgi?id=119189
-- 
Javier Jardón Cabezas
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: GtkGLExt (was Re: Gtk 3.0)

[Emmanuele Bassi]

On Fri, 2009-12-04 at 18:11 -0500, Braden McDaniel wrote:

I have the impression that my message is not coming through correctly,
because I keep saying the same things. :-)

> > I never said that raw OperGL is not used, or not useful; I just contend
> > that being able to  drop into GL directly is a niche usage - and it's
> > not getting any more mainstream.
> 
> It is a common requirement for apps that want to do 3D rendering with a 
> cross-platform codebase.

yes. and that, apart from games and scientific/technical applications,
it's not at all common.

>  Biting off Clutter and its dependency chain is 
> not something developers of such an app are likely to want to incur; and 
> Clutter probably won't provide adequate functionality in a lot of cases.

which dependency chain? it's the same as gtk+.

> > the most people care about, as I said, is being able to accelerate
> > drawing primitives and blending modes and hand them over to the GPU;
> > mostly, for 2D-inside-3D environments -- see Clutter, cairo-gl and
> > cairo-drm.
> 
> The volume of code currently using Clutter, cairo-gl, and cairo-drm 
> would be dwarfed by that using OpenGL directly.
> 
> I think your use of the term "niche" is a little unusual.

the amount of code using OpenGL is relatively limited (hence "niche")
compared to the rest of applications in the GNOME stack (or even in the
whole Linux ecosystem); it's *usage* is limited, not the size of the
codebase.

cairo-drm and cairo-gl are experimental surfaces that have less than 6
months each: it's obvious that the size codebase is limited.

Clutter is a new project, compared to OpenGL, and yet *it's* *not*
intended to cover the same usage of OpenGL. its intended use covers a
canvas for writing applications, not molecule viewers or 3D shooters.

that's why GtkGLExt can still be perfectly fine outside of the gtk+
codebase; it provides much more than setting up a GL context, which
would be the agreed API for gtk+ to expose, and given the amount of
applications actively requiring to drop into GL without any sort of
canvas, then it might make sense to keep GtkGLExt exactly as it is.

ciao,
 Emmanuele.


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

Re: GtkGLExt (was Re: Gtk 3.0)

[Braden McDaniel]

Emmanuele Bassi wrote:

On Fri, 2009-12-04 at 20:51 +, Carlos Pereira wrote:

Hi Emmanuele,

I'm really not working on it - mainly for three reasons: 1) if you want to
use GL, GtkGlExt is "good enough" and integrating it into gtk+ it's not a
good idea;
1) If you think GtkGlExt should not be integrated with GTK+ that's fine 
for me.


2) GtkGlExt is good enough for GTK-2.0, I never had a single problem with 
GTKGLExt.

3) However GtkGlExt is not GTK-3.0 ready, because it cannot be compiled with 
SEAL_ENABLE and SINGLE_INCLUDES...


I guess that you'll have to patch GtkGLExt, and submit patches for
integration upstream.


We're interested.

We're currently planning what might go into the next GtkGLExt release. 
We probably need to have a discussion about whether there should be 
another release targeting Gtk+ 2.x.


I'll open this up on the gtkglext-list shortly.


4) Scientific/engineering applications often use OpenGL, which is a well 
established, well documented, industry-standard with a large, vibrant 
community, as these foruns clearly show:

http://www.opengl.org/discussion_boards/


I never said that raw OperGL is not used, or not useful; I just contend
that being able to  drop into GL directly is a niche usage - and it's
not getting any more mainstream.


It is a common requirement for apps that want to do 3D rendering with a 
cross-platform codebase.  Biting off Clutter and its dependency chain is 
not something developers of such an app are likely to want to incur; and 
Clutter probably won't provide adequate functionality in a lot of cases.



people flee from OpenGL in disgust, and it's just OpenGL 3.x that's
making some progress towards fixing the insane API that it exposes -
unfortunately, no GL implementation provides the 3.x API yet.


For a lot of people using OpenGL (or various engines/wrappers like 
OpenSceneGraph and OGRE), there's no practical alternative to flee to.



the most people care about, as I said, is being able to accelerate
drawing primitives and blending modes and hand them over to the GPU;
mostly, for 2D-inside-3D environments -- see Clutter, cairo-gl and
cairo-drm.


The volume of code currently using Clutter, cairo-gl, and cairo-drm 
would be dwarfed by that using OpenGL directly.


I think your use of the term "niche" is a little unusual.


even if (and I'm saying *if*) GTK+ provided GL integration for
GdkWindows it would basically boil down to two functions:

  void gdk_window_gl_begin (GdkWindow *window);
  void gdk_window_gl_end (GdkWindow *window);

plus a way to set up the GL context. that's mostly agreed upon, if you
read the bug that Javier linked in his email. that's not even close to
the API exposed by GtkGLExt.


This is certainly a conversation that I'm interested in having.  We're 
certainly aware that there's a good deal of chaff in the GtkGLExt API 
needs culling.  On the other hand, what you're describing isn't *that* 
far from the parts of GtkGLExt that people actually use.  (Well, 
currently the API has users make_current and then do the begin/end stuff 
at the GL level.)  But I'd like to get us a bit farther along in doing 
that paring down before discussing this in depth.


--
Braden McDaniel  e-mail: 
<http://endoframe.com>   Jabber: 
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: GtkGLExt (was Re: Gtk 3.0)

[Emmanuele Bassi]

On Fri, 2009-12-04 at 22:26 +0100, David Nečas wrote:
> On Fri, Dec 04, 2009 at 08:51:54PM +, Carlos Pereira wrote:
> >> I'm really not working on it - mainly for three reasons: 1) if you want to
> >> use GL, GtkGlExt is "good enough" and integrating it into gtk+ it's not a
> >> good idea;
> >
> > 2) GtkGlExt is good enough for GTK-2.0, I never had a single problem with 
> > GTKGLExt.
> >
> > 4) Scientific/engineering applications often use OpenGL,
> 
> Exactly.  I've been using GtkGLExt in a scientific app for years and I'm
> quite happy with it.  Cutter does not cut it if you need to visualize
> scientific data in 3D.

clearly, since Clutter is a toolkit aimed at writing User
Interfaces. :-)

Clutter has a very different scope than raw OpenGL - otherwise we
wouldn't even have bothered to write it. it's also one of the non-niche
uses of OpenGL, now that the Linux graphics stack is getting more
polished and we can actually use OpenGL for writing hardware accelerated
user interfaces.

ciao,
 Emmanuele.


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

Re: GtkGLExt (was Re: Gtk 3.0)

[Emmanuele Bassi]

On Fri, 2009-12-04 at 20:51 +, Carlos Pereira wrote:
> Hi Emmanuele,
> > I'm really not working on it - mainly for three reasons: 1) if you want to
> > use GL, GtkGlExt is "good enough" and integrating it into gtk+ it's not a
> > good idea;
> 1) If you think GtkGlExt should not be integrated with GTK+ that's fine 
> for me.
> 
> 2) GtkGlExt is good enough for GTK-2.0, I never had a single problem with 
> GTKGLExt.
> 
> 3) However GtkGlExt is not GTK-3.0 ready, because it cannot be compiled with 
> SEAL_ENABLE and SINGLE_INCLUDES...

I guess that you'll have to patch GtkGLExt, and submit patches for
integration upstream.

> 4) Scientific/engineering applications often use OpenGL, which is a well 
> established, well documented, industry-standard with a large, vibrant 
> community, as these foruns clearly show:
> 
> http://www.opengl.org/discussion_boards/

I never said that raw OperGL is not used, or not useful; I just contend
that being able to  drop into GL directly is a niche usage - and it's
not getting any more mainstream.

people flee from OpenGL in disgust, and it's just OpenGL 3.x that's
making some progress towards fixing the insane API that it exposes -
unfortunately, no GL implementation provides the 3.x API yet.

the most people care about, as I said, is being able to accelerate
drawing primitives and blending modes and hand them over to the GPU;
mostly, for 2D-inside-3D environments -- see Clutter, cairo-gl and
cairo-drm.

> So all I am asking the GTK team is, please find a solution regarding OpenGL 
> support for GTK-3.0... with or without GtkGLExt...

GtkGLExt is an external project - the GTK+ team has nothing to do with
it.

even if (and I'm saying *if*) GTK+ provided GL integration for
GdkWindows it would basically boil down to two functions:

  void gdk_window_gl_begin (GdkWindow *window);
  void gdk_window_gl_end (GdkWindow *window);

plus a way to set up the GL context. that's mostly agreed upon, if you
read the bug that Javier linked in his email. that's not even close to
the API exposed by GtkGLExt.

ciao,
 Emmanuele.

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

RE: GtkGLExt (was Re: Gtk 3.0)

[Shawn Bakhtiar]

I've sort of followed this chain sorry if I am rehashing something that has 
already been covered.
IMHO I agree that GtkGLExt should be directly integrated into GTK. Most modern 
user interfaces (IE OS X (NextStep)) are integrating 3D directly into the 
windowing system. If I am not mistaken the panel is pure Open GL in OS X, and 
for sure the iChat multi session video window is pure OGL with reflection maps 
(they love to tout that). Their development toolset is chalked full of OpenGL 
examples, and composer... well I won't even go there. GTKGLext does NOT 
currently work well on OS X interface (even though there is a patch for it, 
which still needs to be changed to use the NSOpenGLView instead of the NSView 
but that is whole other story).
Open GL is not only the standard scientific toolset, it is the de facto 
hardware acceleration tool set. I don't know of ANY video card vendor that DOES 
NOT have OpenGL support. In fact I can not think of any other hardware 
accelerated tool sets (OGL has been it since the early 90's) it WILL be the 
interface choice of the future. 2D desktops will quickly give way to 3D 
widgetry, as hardware acceleration improves even further. Just look at compiz!
I've already got users asking me to make the app look more 3D, and it would be 
great to have the toolset to do so. Even though all were doing is simple EPR 
stuff. IE If I could create a 3D warehouse map that was navigable by the user 
to see where they have room to store a product, or look at a product space for 
a visual cue to order more. This is an old concept Motorola developed about its 
factories and training workers virtually. 
Of course, this is all a wish list, I can't demand of the community to do the 
work I my self have no time for, but it would be really really really 
supercalifragilisticexpialidocious-ly great to have a fully working OpenGL 
implementation in GTK for OS X, and if it is dropped for GTK 3.0, I'm afraid it 
will not serve the community well. 

I did not quite catch why it was not a good idea. Saying that is like saying it 
is not a good idea to have the printing subsystem, or input subsystem be 
exposed in GTK. GTK in essence is an abstraction layer, to hide the differences 
in interface functionality, giving the user (programer) a singe interface to 
write agains. Why should we not have the same thing for OpenGL, which is a 
component of the user interface?
Again this is all MHO, and I certainly have not invested a dime in it, so 
wether it happens or not I will work around it, but it would be nice, very, 
very nice, to have an GTKOGLWindow in GTK's base library, or at least something 
like pango/cairo, as a compiler option module.

 EMAILING FOR THE GREATER GOOD
Join me

> Date: Fri, 4 Dec 2009 22:26:05 +0100
> From: y...@physics.muni.cz
> To: eba...@gmail.com; jose.carlos.pere...@ist.utl.pt
> Subject: Re: GtkGLExt (was Re: Gtk 3.0)
> CC: gtk-app-devel-list@gnome.org
> 
> On Fri, Dec 04, 2009 at 08:51:54PM +, Carlos Pereira wrote:
> >> I'm really not working on it - mainly for three reasons: 1) if you want to
> >> use GL, GtkGlExt is "good enough" and integrating it into gtk+ it's not a
> >> good idea;
> >
> > 2) GtkGlExt is good enough for GTK-2.0, I never had a single problem with 
> > GTKGLExt.
> >
> > 4) Scientific/engineering applications often use OpenGL,
> 
> Exactly.  I've been using GtkGLExt in a scientific app for years and I'm
> quite happy with it.  Cutter does not cut it if you need to visualize
> scientific data in 3D.
> 
> Unfortunately, scientific/engineering apps seems to *be* niche use.  Look
> at how hard SourceForge tries to hide this software category even though
> it contains 50× more projects than VoIP which is promimently displayed...
> 
> So I hope something like GtkGLExt will continue to be available, whether
> it's called GtkGLExt or not and is integrated into Gtk+ or not.
> 
> Yeti
> 
> ___
> gtk-app-devel-list mailing list
> gtk-app-devel-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
  
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: GtkGLExt (was Re: Gtk 3.0)

[David Nečas]

On Fri, Dec 04, 2009 at 08:51:54PM +, Carlos Pereira wrote:
>> I'm really not working on it - mainly for three reasons: 1) if you want to
>> use GL, GtkGlExt is "good enough" and integrating it into gtk+ it's not a
>> good idea;
>
> 2) GtkGlExt is good enough for GTK-2.0, I never had a single problem with 
> GTKGLExt.
>
> 4) Scientific/engineering applications often use OpenGL,

Exactly.  I've been using GtkGLExt in a scientific app for years and I'm
quite happy with it.  Cutter does not cut it if you need to visualize
scientific data in 3D.

Unfortunately, scientific/engineering apps seems to *be* niche use.  Look
at how hard SourceForge tries to hide this software category even though
it contains 50× more projects than VoIP which is promimently displayed...

So I hope something like GtkGLExt will continue to be available, whether
it's called GtkGLExt or not and is integrated into Gtk+ or not.

Yeti

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

Re: GtkGLExt (was Re: Gtk 3.0)

[Carlos Pereira]

Hi Emmanuele,

I'm really not working on it - mainly for three reasons: 1) if you want to
use GL, GtkGlExt is "good enough" and integrating it into gtk+ it's not a
good idea;
1) If you think GtkGlExt should not be integrated with GTK+ that's fine 
for me.


2) GtkGlExt is good enough for GTK-2.0, I never had a single problem with 
GTKGLExt.

3) However GtkGlExt is not GTK-3.0 ready, because it cannot be compiled with 
SEAL_ENABLE and SINGLE_INCLUDES...

4) Scientific/engineering applications often use OpenGL, which is a well 
established, well documented, industry-standard with a large, vibrant 
community, as these foruns clearly show:

http://www.opengl.org/discussion_boards/

So all I am asking the GTK team is, please find a solution regarding OpenGL 
support for GTK-3.0... with or without GtkGLExt...

Regards,
Carlos


2) cairo should get GPU acceleration for 2D drawing, which is
what most of users really care about; 3) if you want a 3D canvas you should
be using Clutter.

Integrating raw GL inside a gtk+ application is a niche requirement enough
that I'm not at all sure it should be moved to gtk+ itself. And if you're
dropping into raw GL there is no way you are not a niche use case.

On 4 Dec 2009 18:13, "Carlos Pereira" 
wrote:

Thanks Javier,
it's good to know that EmmanueleBassi <http://live.gnome.org/EmmanueleBassi>
is now taking care of GtkGLExt integration with GTK...

Regards,
Carlos

  

Hello Carlos, > > 2009/12/3 Carlos Pereira <
  

jose.carlos.pere...@ist.utl.pt>: >   >> >> That's w...

___ gtk-app-devel-list mailing
list gtk-app-devel-l...@g...

  


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

Re: GtkGLExt (was Re: Gtk 3.0)

[Emmanuele Bassi]

(Sorry, I'm sending this via my phone so it's not going to be nicely
formatted; I apologize)

I'm really not working on it - mainly for three reasons: 1) if you want to
use GL, GtkGlExt is "good enough" and integrating it into gtk+ it's not a
good idea; 2) cairo should get GPU acceleration for 2D drawing, which is
what most of users really care about; 3) if you want a 3D canvas you should
be using Clutter.

Integrating raw GL inside a gtk+ application is a niche requirement enough
that I'm not at all sure it should be moved to gtk+ itself. And if you're
dropping into raw GL there is no way you are not a niche use case.

On 4 Dec 2009 18:13, "Carlos Pereira" 
wrote:

Thanks Javier,
it's good to know that EmmanueleBassi 
is now taking care of GtkGLExt integration with GTK...

Regards,
Carlos

> > Hello Carlos, > > 2009/12/3 Carlos Pereira <
jose.carlos.pere...@ist.utl.pt>: >   >> >> That's w...

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

Re: GtkGLExt (was Re: Gtk 3.0)

[Carlos Pereira]

Thanks Javier,
it's good to know that EmmanueleBassi 
 is now taking care of GtkGLExt 
integration with GTK...


Regards,
Carlos

Hello Carlos,

2009/12/3 Carlos Pereira :
  

That's why I asked in the first message of this thread, what are the plans
regarding GtkGLExt. To the best of my knowledge, GtkGLExt is still the
official way to bridge GTK and OpenGL:

http://gtkglext.sourceforge.net/

are there plans to integrate this via Cairo and discard GtkGLExt? that was
mentioned in this list years ago...



OpenGL integration into GTK+ is part of project Ridley [1].
Here the bug report: [2]
The project was recently moved to gnome git too [3] and seems to be
quite active.

[1] http://live.gnome.org/ProjectRidley
[2] https://bugzilla.gnome.org/show_bug.cgi?id=119189
[3] http://mail.gnome.org/archives/gtkglext-list/2009-October/msg5.html
  


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

GtkGLExt (was Re: Gtk 3.0)

[Javier Jardón]

Hello Carlos,

2009/12/3 Carlos Pereira :
> That's why I asked in the first message of this thread, what are the plans
> regarding GtkGLExt. To the best of my knowledge, GtkGLExt is still the
> official way to bridge GTK and OpenGL:
>
> http://gtkglext.sourceforge.net/
>
> are there plans to integrate this via Cairo and discard GtkGLExt? that was
> mentioned in this list years ago...

OpenGL integration into GTK+ is part of project Ridley [1].
Here the bug report: [2]
The project was recently moved to gnome git too [3] and seems to be
quite active.

[1] http://live.gnome.org/ProjectRidley
[2] https://bugzilla.gnome.org/show_bug.cgi?id=119189
[3] http://mail.gnome.org/archives/gtkglext-list/2009-October/msg5.html
-- 
Javier Jardón Cabezas
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Gtk 3.0

[Carlos Pereira]

That's why I asked in the first message of this thread, what are the 
plans regarding GtkGLExt. To the best of my knowledge, GtkGLExt is still 
the official way to bridge GTK and OpenGL:


http://gtkglext.sourceforge.net/

are there plans to integrate this via Cairo and discard GtkGLExt? that 
was mentioned in this list years ago...


Regards,
Carlos
It seems gtkglext does not work yet with SINGLE_INCLUDES. When I compile  
my app I get the following error message (gtkgkext is including  
gdkgltypes.h and this is flagged down):



GtkGLExt is not Gtk+ 3.0 ready.  There are more problems in the demos
(some still use GtkFileSelection and they fail to receive pointer motion
events in Gtk+ 2.18+).  I'm not sure how much/if GtkGLExt is mainatained
at present.

Yeti


  


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

Re: Gtk 3.0

[David Nečas]

On Thu, Dec 03, 2009 at 04:16:02PM +, Carlos Pereira wrote:
> It seems gtkglext does not work yet with SINGLE_INCLUDES. When I compile  
> my app I get the following error message (gtkgkext is including  
> gdkgltypes.h and this is flagged down):

GtkGLExt is not Gtk+ 3.0 ready.  There are more problems in the demos
(some still use GtkFileSelection and they fail to receive pointer motion
events in Gtk+ 2.18+).  I'm not sure how much/if GtkGLExt is mainatained
at present.

Yeti

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

Re: Gtk 3.0

[Carlos Pereira]

Thanks David,

It seems gtkglext does not work yet with SINGLE_INCLUDES. When I compile 
my app I get the following error message (gtkgkext is including 
gdkgltypes.h and this is flagged down):


In file included from /usr/include/gtkglext-1.0/gdk/gdkgltypes.h:22,
from /usr/include/gtkglext-1.0/gdk/gdkgl.h:27,
from /usr/include/gtkglext-1.0/gtk/gtkgl.h:22,
from ./engine/my_app_engine.h:28,
from ./engine/my_app_engine_array.c:12:
/usr/include/gtk-2.0/gdk/gdktypes.h:28:2: error: #error "Only 
 can be included directly."


I am compiling on Ubuntu 9.10 (Gtk 2.18.3, I think) with:
CFLAGS = -g -O3 -Wall -ansi
override CFLAGS += -DG_DISABLE_DEPRECATED -DGDK_DISABLE_DEPRECATED \
   -DGDK_PIXBUF_DISABLE_DEPRECATED -DGTK_DISABLE_DEPRECATED \
   -DGSEAL_ENABLE \
   -DG_DISABLE_SINGLE_INCLUDES -DATK_DISABLE_SINGLE_INCLUDES \
   -DGDK_PIXBUF_DISABLE_SINGLE_INCLUDES -DGTK_DISABLE_SINGLE_INCLUDES

Carlos


FOO_DISABLE_SINGLE_INCLUDES prevents inclusion of indvidual headers (as
opposed to library-level headers such as glib.h).  It does not affect
what symbols are defined.

Yeti

  


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

Re: Gtk 3.0

[David Nečas]

On Wed, Dec 02, 2009 at 05:52:22PM +, Carlos Pereira wrote:
> Compiling with -DGSEAL_ENABLE these macros are flagged as errors:
>
> 1) GTK_WIDGET_SET_FLAGS (removed)
> 2) GTK_WIDGET_SENSITIVE (replaced by gtk_widget_is_sensitive or  
> gtk_widget_get_sensitive)
>
> However, apparently they are not in the list of deprecated symbols.  
> Should that be changed?

This is probably an omission, they should be marked deprecated because
they access the GtkWidget struct fields directly and hence cannot work
with GSEAL.

> could you point me to a documentation page listing macros and other  
> things made obsolete with -DGSEAL_ENABLE, -DG_DISABLE_SINGLE_INCLUDES,  
> -DGTK_DISABLE_SINGLE_INCLUDES, etc. and its replacements?

GSEAL prevents accessing struct fields directly (including you doing it
e.g. by GTK_DIALOG(dialog)->vbox), I'm not sure it there's an official
list of affected macros.  Theoretically, all such are marked deprecated.

FOO_DISABLE_SINGLE_INCLUDES prevents inclusion of indvidual headers (as
opposed to library-level headers such as glib.h).  It does not affect
what symbols are defined.

Yeti

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

Re: Gtk 3.0

[Carlos Pereira]

Thanks Javier, thanks David,

Compiling with -DGSEAL_ENABLE these macros are flagged as errors:

1) GTK_WIDGET_SET_FLAGS (removed)
2) GTK_WIDGET_SENSITIVE (replaced by gtk_widget_is_sensitive or 
gtk_widget_get_sensitive)


However, apparently they are not in the list of deprecated symbols. 
Should that be changed?


could you point me to a documentation page listing macros and other 
things made obsolete with -DGSEAL_ENABLE, -DG_DISABLE_SINGLE_INCLUDES, 
-DGTK_DISABLE_SINGLE_INCLUDES, etc. and its replacements?


Thanks,
Carlos

You should try to compile your application with:

make CFLAGS+="-DGSEAL_ENABLE"



and with -DG_DISABLE_SINGLE_INCLUDES, -DGTK_DISABLE_SINGLE_INCLUDES, etc.
  


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

Re: Gtk 3.0

[David Nečas]

On Tue, Dec 01, 2009 at 01:44:52AM +0100, Javier Jardón wrote:
> 2009/12/1 Carlos Pereira :
> 
> > 1) My app is currently compiling without warnings, with Gtk 2.18.3 I believe
> > (Ubuntu 9.10), at the compilation level:
> >
> > CFLAGS = -g -O3 -Wall -ansi
> > override CFLAGS += -DG_DISABLE_DEPRECATED \ -DGDK_DISABLE_DEPRECATED \
> > -DGDK_PIXBUF_DISABLE_DEPRECATED \
> > -DGTK_DISABLE_DEPRECATED
> >
> > This means that my app is (mostly) ready for Gtk 3.0?
> 
> You should try to compile your application with:
> 
> make CFLAGS+="-DGSEAL_ENABLE"

and with -DG_DISABLE_SINGLE_INCLUDES, -DGTK_DISABLE_SINGLE_INCLUDES, etc.

Regarding the other questions, yes, GtkGLExt works on MS Windows.

Yeti

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

Re: Gtk 3.0

[Javier Jardón]

2009/12/1 Carlos Pereira :
> Dear all,

Hello Carlos

> 1) My app is currently compiling without warnings, with Gtk 2.18.3 I believe
> (Ubuntu 9.10), at the compilation level:
>
> CFLAGS = -g -O3 -Wall -ansi
> override CFLAGS += -DG_DISABLE_DEPRECATED \ -DGDK_DISABLE_DEPRECATED \
> -DGDK_PIXBUF_DISABLE_DEPRECATED \
> -DGTK_DISABLE_DEPRECATED
>
> This means that my app is (mostly) ready for Gtk 3.0?

You should try to compile your application with:

make CFLAGS+="-DGSEAL_ENABLE"

take a look here [1] for more info.

Regards

[1] http://live.gnome.org/GnomeGoals/UseGseal
-- 
Javier Jardón Cabezas
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Gtk 3.0

[Carlos Pereira]

Dear all,

1) My app is currently compiling without warnings, with Gtk 2.18.3 I 
believe (Ubuntu 9.10), at the compilation level:


CFLAGS = -g -O3 -Wall -ansi
override CFLAGS += -DG_DISABLE_DEPRECATED \ -DGDK_DISABLE_DEPRECATED \
-DGDK_PIXBUF_DISABLE_DEPRECATED \
-DGTK_DISABLE_DEPRECATED

This means that my app is (mostly) ready for Gtk 3.0?

2) GtkGLExt works on Windows?

3) It was planned long time ago, to replace entirely GtkGLExt by Cairo 
functionality. Is this going to happen in time for Gtk 3.0?


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

Re: GTK 3.0: an app developer's view

[Tor Lillqvist]

> 20 years ago, everyone was hand-coding assembly routines.

We were? I think you are generalising slightly. 20 years ago, I would
assume most programmers were happily writing Cobol, Fortran, Pascal,
C, etc high-level languages.

("high-level" compared to machine language, that is. Of course, in the
academic world, people have always been busy inventing even higher
level languages. And some of them have even eventually been used for
"Real Work".)

 >Today, more and more behaviour is moving into "higher"
> level constructs, softcode, bytecode interpreters, etc..

The bytecode concept (that specific term wasn't used though) was
invented over 40 years ago...

> 30 years ago, everyone hand-picked their registers for individual assembly 
> statements.

We did?

Please understand that many "advanced" concepts are not necessarily
that new at all. People were programming in Lisp *40* years ago, at
least. And Lisp surely is quite far from "hand-picking registers".
Smalltalk is over 30 years old. So is Prolog. Not much register
hand-picking in APL, PL/1, Fortran, Pascal, Cobol or Simula either, to
pick some old languages.

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

Re: GTK 3.0: an app developer's view

[Paul LeoNerd Evans]

On Tue, 17 Jun 2008 10:05:28 +0100
Martyn Russell <[EMAIL PROTECTED]> wrote:

> Glade has been doing this for years. It is much quicker for an
> application developer to use Glade to define menus, windows, dialogs,
> etc than it is to code then *statically*. I say statically because you
> don't need to recompile your program to change some slight detail of the
> menu layout or labelling. This bears a huge advantage as far as I am
> concerned.

It's a trend everyone has been making for years, and I very much support
it. 20 years ago, everyone was hand-coding assembly routines. 10 years
ago, C was king. Today, more and more behaviour is moving into "higher"
level constructs, softcode, bytecode interpreters, etc..

This is a good thing. CPUs get faster all the time. Memory and hard
disks get bigger and cheaper all the time. Programmers only ever get more
expensive. Engineering is always about tradeoffs between resources. The
resources we have are both computer, and programmer. Because the former
keeps getting faster and cheaper, it makes sense every so often to have a
shift of ideas, a great move where we decide the computer is "good
enough" to take on what we now decide is the boring menial tasks we
as programmers can't be bothered to do.

30 years ago, everyone hand-picked their registers for individual
assembly statements. Nowadays, I bet most programmers couldn't even
identify the register-colouring algorithm in their compiler; it's
something that's just done for them. Who's to say what, in 20 or 30 years
time, compilers and other programmer tools will be doing for us. I
suspect very strongly that building UIs automatically around some
description of the task to be solved, will fall under their remit.

-- 
Paul "LeoNerd" Evans

[EMAIL PROTECTED]
ICQ# 4135350   |  Registered Linux# 179460
http://www.leonerd.org.uk/
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: GTK 3.0: an app developer's view

[Martyn Russell]

Allin Cottrell wrote:
> Sorry for cross-posting, but I think this does cross gtk-devel and 
> gtk-app-devel: it's the thoughts of a common-or-garden app 
> developer following the dicussions on gtk-devel about what's 
> coming with GTK 3.0.
> 
> As a starting point, on June 5, in the thread "Steps to get to 
> GTK+ 3.0", Martyn Russell ([EMAIL PROTECTED]) wrote:
> 
> "Many applications didn't make the change [from GTK 1.2 to GTK 2] 
> because it meant rewriting a lot of code. Unless my applications 
> are using some evil voodoo they shouldn't be using, I don't expect 
> the transition from GTK+ 2.x to 3.x to take much time at all."
> 
> As an app developer who did take the trouble to re-write a lot of 
> code in the transition 1.2 -> 2.0, I wonder about this statement. 

I did too, I had several applications which had to make the transition
and it wasn't a quick job.

> (Note: In my understanding, one key difference between GTK 2.0 and 
> 3.0 is that all the APIs deprecated in 2.0 will be removed in 3.0; 
> If I'm wrong about that, please tell me!)
> 
> What's the status of the portion of the GTK API that was not 
> deprecated from the get-go with GTK 2.0, but joined the deprecated 
> list later, after 2.4?  I'm thinking in particular of 
> GtkItemFactory: if I'm remembering right, that was still kosher 
> when GTK 2.0 appeared.

I just put together quickly a few lists of ALL things marked as
deprecated right now. GtkItemFactory is in that list. It will be removed
(as I understand it) in 3.0 as will everything else that is marked as
deprecated.

These lists give you an idea of how much dead code is left in GTK+ right
now and why it is so hard to maintain with it lying around.

This list is in no way conclusive, it is literally those I looked up in
all .h files in the gtk/ directory. There may be others.

> Moreover, the new 
> code would be less efficient than the old (lots of strcmp as 
> opposed to just looking at integer values from an enumeration).

If you find the loading speed so bad that it is affecting performance of
your application, please file a bug. If this is not the case, I think
the benefits of a *readable* XML format outweigh the inefficiency you
talk about.

> In addition, I'm not 100% convinced of the virtues of defining a 
> UI in XML as opposed to via an array of C structs (having both 
> options would be nice).  

Glade has been doing this for years. It is much quicker for an
application developer to use Glade to define menus, windows, dialogs,
etc than it is to code then *statically*. I say statically because you
don't need to recompile your program to change some slight detail of the
menu layout or labelling. This bears a huge advantage as far as I am
concerned.

> Gtk-demo has an example where the UI is 
> defined via a chunk of XML inlined as a C string.  This really 
> sucks, and would be a maintenence nightmare in any real app.  

What kind of real application are you talking about?

I have written many in my time and I use glade for most of them (which
uses an XML format for not only the menus but all window layouts). I
don't find it a maintenance nightmare at all, in fact it is quite the
opposite.

> OK, I don't want to be too negative about GtkUIManager; it surely 
> has its advantages.  But I am concerned about the possibility that 
> GtkItemFactory will disappear: 

It is a certainty from what I can see.

> this API is not "evil voodoo", IMO, 
> and I don't suppose that mine is the only GTK 2 app that uses it 
> rather extensively.

I too have had to move from GtkItemFactory to the new GtkUIManager. It
wasn't great, but it is needed. I am not saying GtkItemFactory is "evil
voodoo" either, I am just saying there are some things in GTK+ that just
need to be removed and there are some things application developers are
*able* to do as a result of not sealing structures with proper APIs.

I should add at this point too, that the GtkItemFactory has been marked
as deprecated for some time (since GTK+ 2.4) and the documentation has
explicitly said so too. So you have had plenty of time to update your
application and/or bring your concerns forward about this.

Please do not feel like we don't care about application developers here,
many of us are application developers and know we too will have
transitions to make for our software where we switch from deprecated APIs.

-- 
Regards,
Martyn
gtk_about_dialog_get_name
gtk_about_dialog_set_name
gtk_accel_group_ref
gtk_accel_group_unref
gtk_accel_label_accelerator_width
gtk_binding_entry_add
gtk_binding_entry_add_signall
gtk_binding_entry_clear
gtk_binding_parse_binding
gtk_button_box_get_child_ipadding
gtk_button_box_get_child_size
gtk_button_box_get_spacing
gtk_button_box_set

GTK 3.0: an app developer's view

[Allin Cottrell]

Sorry for cross-posting, but I think this does cross gtk-devel and 
gtk-app-devel: it's the thoughts of a common-or-garden app 
developer following the dicussions on gtk-devel about what's 
coming with GTK 3.0.

As a starting point, on June 5, in the thread "Steps to get to 
GTK+ 3.0", Martyn Russell ([EMAIL PROTECTED]) wrote:

"Many applications didn't make the change [from GTK 1.2 to GTK 2] 
because it meant rewriting a lot of code. Unless my applications 
are using some evil voodoo they shouldn't be using, I don't expect 
the transition from GTK+ 2.x to 3.x to take much time at all."

As an app developer who did take the trouble to re-write a lot of 
code in the transition 1.2 -> 2.0, I wonder about this statement. 
(Note: In my understanding, one key difference between GTK 2.0 and 
3.0 is that all the APIs deprecated in 2.0 will be removed in 3.0; 
If I'm wrong about that, please tell me!)

What's the status of the portion of the GTK API that was not 
deprecated from the get-go with GTK 2.0, but joined the deprecated 
list later, after 2.4?  I'm thinking in particular of 
GtkItemFactory: if I'm remembering right, that was still kosher 
when GTK 2.0 appeared.

My app has a large number of menus, across several classes of 
windows, and, after checking my code in the wake of the recent 
discussion of GTK 3.0, I find I'm very heavily invested in 
GtkItemFactory.

I don't want to be a stick-in-the-mud, and I spent most of today 
working on a "trial port" to the GtkUIManager API of some of my 
GtkItemFactory code, to get a sense of the work that would be 
involved in eliminating all dependency on the older API.

Results so far: On the one hand, I can certainly see the 
attraction in the newer API.  Being able to define an "action" 
just once and then have it instantiated in various different UI 
constructions (regular menus, buttons, popups) is very nice.  But 
from my point of view the attraction is largely counterfactual: 
_If_ I had originally composed my app's UIs in this way, I could 
have saved myself some trouble.  But I didn't, and now I'd have to 
go to very considerable trouble to redo them.

I considered the possibility of writing some sort of script or 
program to translate from GtkItemFactory to GtkUIManager, but 
fairly quickly convinced myself this was not feasible in a 
reasonable amount of time: the APIs are just too different.

One key difference relates to the situation where you have several 
GUI actions that are basically similar but differ in some detail.  
In the GtkItemFactory API you can map all such actions to a common 
callback, but assign different values to the guint parameter to 
the callback. So far as I can tell, the callback signature for a 
GtkAction does not support any such (gu)int parameter.  So either 
you have to use different callbacks for each specific action, or 
you have to construct a mapping from string action names to 
specific int action values.

This is perhaps not terribly onerous if you're starting from 
scratch, but it's definitely inconvenient, and represents quite a 
major porting burden: not only would I have to rewrite all the 
menu code, but I'd also have to rewrite all the top-level callback 
code other than for simple cases where there's a one-to-one 
mapping from GUI action to callback function.  Moreover, the new 
code would be less efficient than the old (lots of strcmp as 
opposed to just looking at integer values from an enumeration).

In addition, I'm not 100% convinced of the virtues of defining a 
UI in XML as opposed to via an array of C structs (having both 
options would be nice).  Gtk-demo has an example where the UI is 
defined via a chunk of XML inlined as a C string.  This really 
sucks, and would be a maintenence nightmare in any real app.  
Reading the XML from file is preferable, but even then I'm a bit 
skeptical about offloading core stuff to separate files to be read 
at runtime.

OK, I don't want to be too negative about GtkUIManager; it surely 
has its advantages.  But I am concerned about the possibility that 
GtkItemFactory will disappear: this API is not "evil voodoo", IMO, 
and I don't suppose that mine is the only GTK 2 app that uses it 
rather extensively.

-- 
Allin Cottrell
Department of Economics
Wake Forest University, NC
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list