Re: Getting a Column Number
How do you get the column number from a GtkTreeViewColumn pointer? Is there a way to get the previous and/or next Column or column number? Use gtk_tree_view_get_columns() to get a GList of all the column and check the pointer of focus_column against the GList with g_list_index(), this will return your column number. You can also add the column number as data to your GtkTreeViewColumn objects with something like: g_object_set_data(column, colnum, GINT_TO_POINTER(X)) when you create the columns... -- Bye, Gabry ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: newbie Question
These questions were just examples. Have you read gtk tutorials? Have you looked at the gtk examples? Do you know how the glib object system (gobject) works? Have you even started writing the code? I doubt it. Don't ask the question unless you actually need the answers. When you start writing the code other problems will come up, much simpler problems. And you'll have to ask much simpler questions. The two questions I took as an example are quite advanced ones, you'll need to ask those after you have figured out the UI layout and code for it written. tom Craig Petty wrote: how to list available wireless networks and create a custom widget? --- On Tue, 7/15/08, Tomas Carnecky [EMAIL PROTECTED] wrote: From: Tomas Carnecky [EMAIL PROTECTED] Subject: Re: newbie Question To: [EMAIL PROTECTED] Cc: gtk-app-devel-list@gnome.org Date: Tuesday, July 15, 2008, 11:40 AM Craig Petty wrote: How would i make a gtk+ for a wireless networking? First read gtk tutorials. Then compile, run and modify some gtk samples, just so you get into how gtk works. Then you can read the sourcecode of other gtk applications to understand how a 'big' application is structured. And then, if you have a specific question about for example how to create a custom widget, or how to list available wireless networks, you can get back to this mailinglist and ask it. tom ___ 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: gtk_widget_set_sensitive and mouse pointer
Eric Masson @ Savant Protection wrote:
Hi All,
I had a small problem that was bugging me for a while, and I figured I'd
share the results of my findings.
The problem was this:
You have several widgets inside of a container and you call
gtk_widget_set_sensitive with false to gray out the container + all
children. If you leave your mouse positioned over a button inside that
container, and call gtk_widget_set_sensitive with true, you will no
longer be able to click on that button.
The explanation is simple, the button widget has not received an enter
signal after becoming sensitive.
To fix this, do the following after making the widget sensitive:
gint x,y;
GdkWindow *windowUnderMouse=gdk_window_at_pointer(x,y);
if(windowUnderMouse){
GdkEventCrossing e;
e.type=GDK_ENTER_NOTIFY;
e.window=windowUnderMouse;
e.send_event=1;
e.subwindow=0;
e.time=GDK_CURRENT_TIME;
e.x=0;
e.y=0;
e.x_root=0;
e.y_root=0;
e.mode=GDK_CROSSING_NORMAL;
e.detail=GDK_NOTIFY_UNKNOWN;
e.focus=true;
e.state=0;
gdk_event_put((GdkEvent *)e);
}
That big chunk of code is not required. Just hide, then show, the widget
that was set sensitive (noted as a work-around in the bug report).
--
View this message in context:
http://www.nabble.com/gtk_widget_set_sensitive-and-mouse-pointer-tp18444013p18489265.html
Sent from the Gtk+ - Apps Dev mailing list archive at Nabble.com.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Wrting to a text file in N800 /media/mmc1
Hi Nisha,
I think here is not problem of writing into file. This problem is
because of file permission. check the permission of the
respective file , does it has writing permission for the user as well? , if
not give the write permission.
as I know on maemo if your application creates a file it will not give the
write
permission to that same file ...
I also faced bit same problem on Maemo and solved by changing the permission
might be this will solve your problem.
regards
Sphurti
- Original Message
From: nisha jain [EMAIL PROTECTED]
To: gtk-app-devel-list@gnome.org
Sent: Sunday, 6 July, 2008 9:46:22 AM
Subject: Wrting to a text file in N800 /media/mmc1
Hi All,
Does any Hildon or gtk API supports writing into text files my following
code written in C is not
working for N800 which works perfectly fine under MAEMO ARMEL
mode.Please if some
one has some information let me know...
Regards,
Nisha
-- Forwarded message --
From: nisha jain [EMAIL PROTECTED]
Date: Jul 5, 2008 4:09 PM
Subject: Re: Wrting to a text file in N800 /media/mmc1
To: [EMAIL PROTECTED]
Cc: gary liquid [EMAIL PROTECTED]
Hi All,
I just checked in N800 the following program for writing into a file which
doesn't work Any clues what is going wrong? I neither get any error not
it is
creating a file and writing into it.
#includestdio.h
void main()
{
FILE *Gfile;
if ((Gfile = fopen(/media/mmc1/test.txt, w+)) == NULL)
{
printf(Error in file creation);
}
if(Gfile)
fprintf(Gfile,%02x,0x10);
fclose(Gfile);
}
Regards,
Nisha
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Get an email ID as [EMAIL PROTECTED] or [EMAIL PROTECTED] Click here
http://in.promos.yahoo.com/address
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Using g_signal_connect in class
On Tue, Jul 15, 2008 at 6:36 AM, Gabriele Greco [EMAIL PROTECTED]
wrote:
static void handle_click_cbk(GtkWidget *mywidget_, MyClass *data) {
data-handle_click(); }
You can't make a callback function intended to be used by C code be inside
of the C++ class. It will not be able to find it.
Marco, I recommend using the full gtkmm API - this mix of gtk+ and gtkmm
will lead to a lot of headaches unless you know where the boundaries of the
two are (you can use them together, but typically not in a way you are using
it now).
Read the excellent docs at http://gtkmm.org/documentation.shtml,
specifically the book at
http://gtkmm.org/docs/gtkmm-2.4/docs/tutorial/html/index.html
dave
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Justifying the GTK+ 3.0 ABI break
Hi, On Tue, 2008-07-15 at 20:22 -0400, Morten Welinder wrote: It really is the elaborate deprecation (as opposed to simply dropping in a comment and not maintaining the code any more) that is causing the burden. That's what the log say -- assuming gtkclist is representative -- which I would guess it is. It is not representative. GtkCList is long deprecated, and there's a working replacement for it. It is basically just kept around for backward compatibility. What is really a burden is how difficult it is to add new features to widgets that are still being used. And that's because forward compatibility has not always been considered well enough in the past. From what I understand the GTK+ developers are now trying to eliminate that mistake. Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
About GTK+ 3.0 and deprecated things
Hello, I've read the PDF at http://people.imendio.com/kris/gtk-state-of-the-union-2008.pdf I am wondering what the options will be for users of the GTK lib, that still use deprecated widgets? In the project I work for, we do have a lot of them: [claws-mail/src]$ grep -r GtkItemFactory *|wc -l 163 [claws-mail/src]$ grep -r GtkTooltips *|wc -l 61 [claws-mail/src]$ grep -r GtkCTree *|wc -l 670 [claws-mail/src]$ grep -r GtkCList *|wc -l 198 They're used all over the place and in very central places of the code. Rewriting them to use newer, non-deprecated widgets would require a scary number of man-hours of un-fun work, introduce new bugs, and would take all of our (we're three core developers) energy to re-do work we've already done. We went through this when migrating from GTK+ 1 to GTK+ 2 already. We don't want to do it again. What do you plan on doing for users of your toolkit who don't have time to rewrite things every four years? -- Colin ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: About GTK+ 3.0 and deprecated things
Am Mittwoch, den 16.07.2008, 09:16 +0200 schrieb Colin Leroy: What do you plan on doing for users of your toolkit who don't have time to rewrite things every four years? One obvious option would be to stay with GTK2 forever, and to take over bug fixing for it. Another **rough** idea I always had in mind is moving all that deprecated code into some libgtk-compat library: Obviously this approach would not work for structure fields, but it should be trivial for entirely deprecated classes. This approach also should be support deprecated functions. Obviously those deprecated functions would suffer from the fact, that they cannot access internal data structures anymore. So for functions that cannot be easily be ported maybe just some stub yielding linker warnings would be created in that compat library. Filling that stub would be the task of people willing to use that deprecated function (instead of porting their code). Ciao, Mathias -- Mathias Hasselmann [EMAIL PROTECTED] Openismus GmbH: http://www.openismus.com/ Personal Site: http://taschenorakel.de/ signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: About GTK+ 3.0 and deprecated things
On Wed, 2008-07-16 at 09:16 +0200, Colin Leroy wrote: Hello, I've read the PDF at http://people.imendio.com/kris/gtk-state-of-the-union-2008.pdf I am wondering what the options will be for users of the GTK lib, that still use deprecated widgets? In the project I work for, we do have a lot of them: [claws-mail/src]$ grep -r GtkItemFactory *|wc -l 163 [claws-mail/src]$ grep -r GtkTooltips *|wc -l 61 [claws-mail/src]$ grep -r GtkCTree *|wc -l 670 [claws-mail/src]$ grep -r GtkCList *|wc -l 198 snip We went through this when migrating from GTK+ 1 to GTK+ 2 already. We don't want to do it again. IMO, if you're still using GtkCTree and GtkCList, which were deprecated when GTK+ 2.0 was released 6 years ago, you're asking for trouble. The tooltips should be easy to port, the tree and list widgets less so, which is why it should have started quite some time ago... ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: About GTK+ 3.0 and deprecated things
On Wed, 16 Jul 2008 09:51:03 +0100, Bastien Nocera wrote: Hi, IMO, if you're still using GtkCTree and GtkCList, which were deprecated when GTK+ 2.0 was released 6 years ago, you're asking for trouble. Well, they do work for us. When GTK+ 2.0 was released six years ago, we were already too busy with the rest of the rewriting code-that-worked to do it. Two years and nine days, exactly, between the first commit to the GTK2 branch and the first GTK2 release after 497 commits. And we never came to replace the GtkCtrees because a) they work and b) we didn't have the time/motivation. The tooltips should be easy to port, the tree and list widgets less so, which is why it should have started quite some time ago... and the GtkItemFactory are huge to port too. And probably there is more; I've just looked at the first batch of compilation errors using GTK_DISABLE_DEPRECATED. As Mathias said, a libgtk-legacy (or -compat or whatever) seems a good idea and (in my application developer's opinion) least that can be done for the users of the GTK+ lib. There are 2017 applications on http://gnomefiles.org/ ; how many of these projects have the available manpower to rewrite their code? How many of these are projects are run by enthusiasts on their free time ? -- Colin ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: About GTK+ 3.0 and deprecated things
Colin Leroy skrev: On Wed, 16 Jul 2008 09:51:03 +0100, Bastien Nocera wrote: Hi, Hi, IMO, if you're still using GtkCTree and GtkCList, which were deprecated when GTK+ 2.0 was released 6 years ago, you're asking for trouble. Well, they do work for us. When GTK+ 2.0 was released six years ago, we were already too busy with the rest of the rewriting code-that-worked to do it. Two years and nine days, exactly, between the first commit to the GTK2 branch and the first GTK2 release after 497 commits. And we never came to replace the GtkCtrees because a) they work and b) we didn't have the time/motivation. The tooltips should be easy to port, the tree and list widgets less so, which is why it should have started quite some time ago... and the GtkItemFactory are huge to port too. And probably there is more; I've just looked at the first batch of compilation errors using GTK_DISABLE_DEPRECATED. As Mathias said, a libgtk-legacy (or -compat or whatever) seems a good idea and (in my application developer's opinion) least that can be done for the users of the GTK+ lib. Having a libgtk-compat library sounds like a good idea. We discussed it during Guadec a year or two ago but the discussion was then about whether it would be possible to move the deprecated calls into a separate library without breaking ABI which from my understanding it isn't on Linux. It sure would lessen the burden for applications still using deprecated widgets (which is the hard part of the ABI break). Cheers, Mikael -- Mikael Hallendal Imendio AB - Expert solutions in GTK+ http://www.imendio.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: About GTK+ 3.0 and deprecated things
On Wed, 16 Jul 2008 12:18:24 +0200, Mikael Hallendal wrote: Hi, It sure would lessen the burden for applications still using deprecated widgets (which is the hard part of the ABI break). Well, the hardest part in my opinion, for free software at least, is the API break :-) There's something unclear from the State of the union slides I've read (I wasn't at GUADEC...); What will happen to GTK+2 when GTK+3 is out ? If it's continuing its life as a bugfix-only branch, the problem from my (app developer's) point of view is not as important... -- Colin ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GUADEC Theming API meeting minutes
2008/7/15 Alberto Ruiz [EMAIL PROTECTED]: Oh, and spacing between widgets shouldn't be a fixed part of layout. It should all be defined in themes. No more studying the HIG and manual labour to get that right. 100% consistency and flexibility instead. That works belongs to Glade/GtkBuilder, themes define style not layout. Having HIG values by default on dialogs, buttonboxes et al is another discussion. Themes could well define layout styling (spacing etc) while the basic layout (table, hbox, whatever) is defined by something else. Layout: table with 2 columns, 4 rows and a horizontal list of buttons below it Style: Widget spacing is NN units, colour is ZZ and font used is XX, buttons have this kind of look... If you think of this as an analogy to the web, CSS *is* used to define spacing and all that. - T, back to vacation mode =) ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
squeakGtk
Hello, I'm writing a binding of Gtk+ for the smalltalk language. Most of the widgets are supported that's pretty cool. But I've a problem with : gtk_main_iteration_do (1) In fact I use this function in a thread and the squeak virtual machine also use X events for the morphs (an old user interface). Here is the problem after some events everything is frozen the morphs and the gtk widgets. Do you thing that could be a problem with the X events inside the virtual machine and the Gtk event loop problems ? Because if I use gtk_main_iteration_do (0) everything works fine but it consumes a lot of cpu time ^^ Cheers, Gwenael Casaccio ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Astonishing allocation bug in glib-2.16.4 compiled with gcc 2.96
On Tue, 15 Jul 2008, Alessandro Vesely wrote: This discussion reminds me that smc_notify_tree() does not actually check which thread does a chunk belong to. Could that result in misbehavior? No, chunks may be freely passed back and forth betwen threads without problems. Except for a few blocks that fit into 2*magazine_size, all allocations are shared between all threads anyway. --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: About GTK+ 3.0 and deprecated things
On Wed, 2008-07-16 at 11:20 +0200, Colin Leroy wrote: On Wed, 16 Jul 2008 09:51:03 +0100, Bastien Nocera wrote: Hi, IMO, if you're still using GtkCTree and GtkCList, which were deprecated when GTK+ 2.0 was released 6 years ago, you're asking for trouble. Well, they do work for us. When GTK+ 2.0 was released six years ago, we were already too busy with the rest of the rewriting code-that-worked to do it. Two years and nine days, exactly, between the first commit to the GTK2 branch and the first GTK2 release after 497 commits. And we never came to replace the GtkCtrees because a) they work and b) we didn't have the time/motivation. Hmm, strangely most code worked fine with GTK+ 2.0 with a recompile... (e.g., I remember doing that for gftp, not a trivial app.) Porting to GtkCList and GtkCTree was was the main thing that took significant work. So, I'm not really sure what you were doing for 497 commits... - Owen ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: About GTK+ 3.0 and deprecated things
On Wed, 16 Jul 2008 09:25:43 -0400, Owen Taylor wrote: Hi, Hmm, strangely most code worked fine with GTK+ 2.0 with a recompile... (e.g., I remember doing that for gftp, not a trivial app.) Probably not trivial, but 30k LOCs is much less than Claws ;) Porting to GtkCList and GtkCTree was was the main thing that took significant work. So, I'm not really sure what you were doing for 497 commits... We had work on: switch to GtkTextView, font selection, charset-related things, GtkCombo(Box(Entry)), pixmap stuff, file selector, accelerators, changed signal handlers... These 500 commits were not only porting work, there were also syncs with the gtk1 branch and bugfixes; still it took us 2 years to be confident enough to release our first GTK2 version. Anyway, I didn't come here to complain about the past, but rather to try and avoid repeating it :) -- Colin ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: squeakGtk
Hi, On Wed, Jul 16, 2008 at 6:16 AM, Gwenael Casaccio [EMAIL PROTECTED] wrote: In fact I use this function in a thread and the squeak virtual machine also use X events for the morphs (an old user interface). Here is the problem after some events everything is frozen the morphs and the gtk widgets. Do you thing that could be a problem with the X events inside the virtual machine and the Gtk event loop problems ? If you have two X display connections (or if smalltalk is using the GDK one), and threads, any number of weird bugs could be happening. You'll need to get used to debugging them... ;-) Be sure you read: http://library.gnome.org/devel/gdk/unstable/gdk-Threads.html Xlib itself is not threadsafe unless you XInitThreads() which GDK does not do, so that's something to explore. GDK relies on being the only code using Xlib so the GDK lock protects Xlib also. If one display connection does an XGrabServer() then the other display connection will lock up for the duration of the grab (as will all other X apps) Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GUADEC Theming API meeting minutes
On Mon, Jul 14, 2008 at 5:42 PM, Alberto Ruiz [EMAIL PROTECTED] wrote: Hi all, this is a summary of the issues discussed and the roadmap about a new theming API for Gtk+ at GUADEC: Current situation: Misc: * Engines are too dependent on widget implementation details * Proper color inheritance for widgets (use case: slider text on dark themes is white instead of black) * Color naming is highly confusing * Style can't be easily updated depending on different values of properties (invisible notebook background, possible merge of scrollbar and h/vbox widget) * Hard for artists to create themes right without writing an engine * Widgets are not transparent by default * The detail string is too static and once you choose one detail you can't change it without breaking the engines OS Integration: * Dynamic gtkrc properties not supported and, right now we parse snippets on code and those strings are not updated if the engine is changed which makes the current code quite hard to read and maintain. Roadmap: * Create a CSS engine to play with it and see how far can we go with flexibility in the artist side (Andreas to make mockups of the new syntax and figure out how to implement it afterwards) Thanks for the heads up. To avoid duplication of efforts, I am working on such a theme engine for some time and have been discussing issues with Benjamin, Andreas, Jakub and others. Code: http://bzr-playground.gnome.org/~robsta/gtk-css-engine/ Screenshot: http://www.gnome.org/~robsta/gtk-css-engine/01-first-roundtrip.png I think gnome-themes-list is an appropriate place to discuss it, if anyone's interested in details and/or plans. What exactly is meant by mockups of the new syntax by the way? I'm planning to use a strict CSS subset. Best, Rob ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: About GTK+ 3.0 and deprecated things
Hmm, strangely most code worked fine with GTK+ 2.0 with a recompile... (e.g., I remember doing that for gftp, not a trivial app.) That sounds like a serious case of selective memory. Or maybe gftp has the ui from hello, world. Here's a partial list of suffering that we went through. Let's see... * All widgets has to be reworked and audited. There was new reference handling and double destroy calls added to the trouble. * All glade files needed to be redone, or at the very least subjected to heavy post-translation surgery with Emacs and Perl. * All code needed to be audited for UTF-8. * All font handling had to be reworked. Drawing changed too. * Whenever something crashed, leaked, or otherwise simply did not work, we had to audit not only our own code, but glib, pango, and gtk+ too. There were piles and piles of bugs in the new code. * We had to struggle with sluggishness of the resulting gtk2 application. The above is just what I can remember off the bat and is *before* changing to use the new widgets of gtk2, some of which were only partial replacements of what they deprecated: the tree view, for example, was touted as right for all kinds of tables, but it has become clear that it cannot handle large ones. Gnumeric has about 34k lines dedicated to dialogs, not including code that implements the actions of those dialogs. Add to that 20k lines of widgets and another 20k lines of further gui code. That excludes code for graphs. You just do not audit that in a weekend or two. You want us to go through some variant of that every 3-4 years? That's insane! What, exactly, is it that is hard about maintaining 2.x that will not be hard for 3.x? I have seen nothing but unsubstantiated assertions about this. What I have observed is that sub-systems like GtkPrint get dumped in and abandoned right away. With bayesian mind that tells me that the maintenance situation will not be better for 3.x What really bothers me is that people go out of their way to break working code. Looking at svn logs tells me that the effort of keeping the old widgets and methods around is minimal. It's not just the old gtkclist -- the recently deprecated gtktooltips shows the same thing. The second unsubstantiated assertion is that the deprecated widgets cause a lot of maintenance work beyond the self-inflicted pain of deprecation. The data does not support that assertion. I would like to see all this gtk3 talk pushed 3-4 years out into the future. There are lots of things that need to be fixed and introducing new, buggy code elsewhere is not going to fix it. If that means the world will have to wait for animated, semi-transparent widgets, then that would be fine. No real work will get done of behalf of those features anyway. Morten Welinder PS: For whatever it's worth, GnuCash also took years to go gtk2. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: About GTK+ 3.0 and deprecated things
Hi, Am Mittwoch, den 16.07.2008, 18:08 -0400 schrieb Paul Davis: On Wed, 2008-07-16 at 16:51 -0400, Morten Welinder wrote: i totally agree with those who are arguing against the current notion of what GTK3 should be. i haven't seen any evidence that any of the problems that our developers face with GTK are going to be easier to address after the proposals for 3.0 are complete, with the possible exception of themeing. it is suggested that once G_SEAL etc. is complete, it will become easier to fix the problems. i've mentioned our problems before ... once again, none of the people working on GTK have ever said to me oh, once 3.0 is done that will be much easier to fix. the closest might be kris' refusal to look at the treeview DnD situation in 2.X because he has a completely new implementation of the entire widget (family) waiting in the wings. does this need G_SEAL to make it work? Paul, just in case this wasn't made clear enough already; the GTK+ team want to deploy a GTK+3 that will be API-compatible to the latest GTK+2 including all deprecation flags that are there (disable deprecated, multihead safe, single header include, etc.). There are these simple things you can do to get your app easily 3.0 compatible: 1. make sure your application compiles with these flags 2. if you use deprecated/considered-broken widgets/classes, copy them into your project and change the namespace from gtk to your project's namespace. After that, everything should be fine. Plus I heard rumors about some refactoring tools being developed so we (app developers) can easily get our code compatible for 3.0. The reference counting pains and the GtkArgs removal etc. were a REAL pain (compared to the points above), also adding lots of new code. But with GTK+3, there are no evil changes like this queued. Regards, Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: About GTK+ 3.0 and deprecated things
On Wed, Jul 16, 2008 at 4:51 PM, Morten Welinder [EMAIL PROTECTED] wrote: [ lots of whining cut out] You want us to go through some variant of that every 3-4 years? That's insane! GTK2 is not going away any time soon. Enterprise distributions will have to keep it alive in maintenance mode for a long time to come (RHEL 5 is still shipping gtk 1.2). What, exactly, is it that is hard about maintaining 2.x that will not be hard for 3.x? I have seen nothing but unsubstantiated assertions about this. What I have observed is that sub-systems like GtkPrint get dumped in and abandoned right away. With bayesian mind that tells me that the maintenance situation will not be better for 3.x Nothing that is hard about maintaining 2.x will not be hard for 3.x. The argument that the proponents of the current 3.x agenda make is that the current state of the code makes it increasingly impossible to add new features. Regarding your GtkPrint comment, I have to point out that moving increasing amounts of the platform into GTK+ does not magically grow the GTK+ maintainership at the same rate. You could improve the situation by sending a patch every once in a while...you do seem to have enough time to do statistical analysis on the GTK+ svn logs, after all :-) Matthias ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: About GTK+ 3.0 and deprecated things
On Thu, 2008-07-17 at 04:11 +0200, Sven Herzberg wrote: Paul, just in case this wasn't made clear enough already; the GTK+ team want to deploy a GTK+3 that will be API-compatible to the latest GTK+2 including all deprecation flags that are there (disable deprecated, multihead safe, single header include, etc.). if its API compatible, why a change in major version numbers? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: About GTK+ 3.0 and deprecated things
On Wed, 2008-07-16 at 23:03 -0400, Paul Davis wrote: if its API compatible, why a change in major version numbers? As I understand it, because: a) they're removing all the deprecated stuff, and b) the API sill start changing after 3.0 in ways that won't be compatible with 3.0 All good. AfC Sydney signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
