Re: GTK TreeView control in Windows (DND issue)
On Thursday, September 15, 2011 1:56 PM, "John Emmas" wrote: > In gtk-win32, when 'key' == "gtk-drag-dest" (and the drag destination is > a TreeView) 'g_datalist_id_get_data()' returns NULL. This is where my > understanding of GTK comes to a halt. Obviously there's some kind of > data list which is supposed to contain some data relating to the quark. > The quark (apparently) has a valid value but the data isn't there. > > Presumably, datalists are generic containers which contain different > kinds of data in different circumstances. So I'd need to liaise with > someone who'd know what kind of data the list should contain. Hopefully, > somewhone who might be able to make a guess at why it isn't there. > Anyone know how to proceed from here...? As you say, this is a generic setting. More precisely, it's just a way to associate a particular memory address with a GObject and a key for later retrieval. I'd search the code for "gtk-drag-dest" and in particular for the matching g_object_set_data() call... Ali. ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Memory leak in gtk label?
On Thu, 17 Dec 2009 11:55 +0800, "Liu, Raymond" wrote: > Hi > > I am using valgrind to check my application, I found a lot of memory > leak issue related to GtkLabel or maybe pango staff. > > I write a small test case to make it simple: [snip] You need to destroy the toplevel widgets before you exit if you want to check for memory leaks (see gtk_widget_destroy). There is no need to destroy the button or the label since they are owned by the toplevel. Cheers, Ali. ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: I did not know this leak memory or not (gtk_object_set_data)
On 2006-07-08 02:16:14 PM, chao yeaj wrote: [please choose _one_ list and stick to it.] > Hello everyone > I use function``gtk_object_set_data'' to set data to object > > my code like this: > > > /***/ > guint *p = NULL; > p = g_malloc0(sizeof(guint)): > > gtk_object_set_data(GTK_OBJECT(button),"key",p); > /*/ > > > > > I did not know whether I should add the following code or not > /***/ > g_free(p); > /***/ You should use: p = g_malloc0(sizeof(guint)); g_object_set_data_full(G_OBJECT(button), "key", p, (GDestroyNotify)g_free); Ali. ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Why gtk_bin_get_child() does not work?
On 2006-07-08 02:26:46 AM, Micah Carrick wrote:
> This should work:
>
> GtkWidget *radio
>
> /*
> More code here to get or create 'radio' as
> a GtkRadioButton widget
> */
>
> gtk_label_set_markup(GTK_LABEL(GTK_BIN(radio)->child),
> "hello");
Can't see how accessing the child member directly is going to help
anything. I suspect his problem is that using
gtk_radio_button_new(NULL) creates a button without a child. The
solution would seem to be either to use
gtk_radio_button_new_with_label("xxx") and then modify the generated
label or create his own label and add it to the button with
gtk_container_add().
Cheers,
Ali.
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: gtk cross compile
On 08/03/06 08:11:06, rakesh p wrote: hi all, am trying to cross compile gtk+ in my powerpc-405-linux-gnu is it required to cross compile pkgconfig for that?because from mailing list i got one information that we need to check whether it is really required for our plat form.if so ,how can i check its needed?. There are two ways that you could compile pkgconfig which are both sometimes known as cross-compiling. 1. Host is native, target is powerpc-405-linux-gnu This is what you should technically use to allow you to cross-compile gtk+ for powerpc-405-linux-gnu. A quick check of pkgconfig's configure.in will quickly tell however, that the only target platform for which this makes a difference is mingw32, so you can just use a native build for powerpc-405-linux-gnu. 2. Host and target are both powerpc-405-linux-gnu This is what you would need if you wanted to be able to build libraries and applications on the powerpc-405-linux-gnu platform itself (rather than just targetting it). More information on this distinction here: http://sources.redhat.com/autobook/autobook/autobook_259.html Cheers, Ali. ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Question
On 11/24/05, ibrar ahmed <[EMAIL PROTECTED]> wrote: Thanx Ali, You know, you're likely to get a faster, and probably more accurate response if you reply to the mailing list rather than one person. I thnk it 'll helpful for me to make a wizard type application. sir if you have done some work by making that type of user interface so please give me some details information about it . As it happens, I took a proposed implementation of GtkAssistants a couple of years back and have used that ever since. Once Gtk+ 2.10 is out, I'll have to switch to the accepted version which will no doubt take some work on my part. Such is life. How we can import Gnome-Druid widget in gtk? How we can handle all issues related them? Tell me the right way to use these files and mentioned that which will be right and successful for me. I've never used GnomeDruid. Perhaps somebody else will be able to help. On 24/11/05 13:19:40, ibrar ahmed wrote: Hello sir, How we 'll compile these files which are available in your given link. I did compile these files as like gtk compilation but there were errors during compilation . Does i need to install something else to remove these errors? If you're not in a position to figure out the errors for yourself then you can telling the list exectly what error you're getting and see if anyone will have the time to help you, but I suspect you'll probably do better to wait for the code to be merged into CVS HEAD and use that when it's available. Cheers, Ali. ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Question
On 24/11/05 05:22:58, ibrar ahmed wrote: Hello All, I want to develop a wizard application using gtk+, i have't any information about it that how i can make wizard application using gtk. Which code 'll be preferable for me to explore by developing wizard application later. So i need the best attention from all of you, who know much about my problem. It's one of the things that's planned for 2.10. See: http://bugzilla.gnome.org/show_bug.cgi?id=115348 You could cheat and "borrow" the latest proposed code from that bug (make sure you rename the objects/methods etc. since it's very likely that your program will break when 2.10 comes out otherwise). It probably isn't going to be that long before it's finished so you might prefer to wait and use Gtk+ HEAD once it hits CVS. Cheers, Ali. ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Error on cross compiling glib package
On 25/08/05 02:33:16, Xyber Blue wrote: Hi people, Good day to you, I have problems cross compiling glib package ang pango so that these libraries will be used for cross compiling... [snip] /opt/cross_frv/frv-linux-gnu/local/bin/glib-genmarshal: Permission denied When cross-compiling glib, you need to provide a natively built version of glib-genmarshal. If /opt/cross_frv/frv-linux-gnu/local/bin/glib- genmarshal is built by you before starting the cross-compile then you need to check whether it works, since there appears to be a problem. If not, then you need to either find a working version or build one by compiling glib natively first and point configure at it when cross- compiling using the GLIB_GENMARSHAL environment variable. HTH, Ali. ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: that old pango problem
On 17/07/05 13:48:21, john q public wrote: Trust me folks Ive tried googling and archive searching till I can't take any more. I even checked a bug tracker that claimed it was "RESOLVED" thats fine but there was no patch and no suggestions, not very helpful in the end so could someone please either find me a cheap copy of XP on E-bay or help with this familiar thing: You don't say which version of Gtk+ you're trying to build but I'm assuming it's the current stable version (2.6.8). If this is the case then it'd be much easier to use whatever package comes with your linux distribution. lots of configure stuff --SNIP-- checking X11/extensions/XShm.h... yes checking Pango flags... -I/usr/local/include/pango-1.0 -I/usr/local/include -I/usr/X11R6/include/freetype2 -I/usr/X11R6/include -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -L/usr/local/lib -lpangoxft-1.0 -lpangox-1.0 -lpango-1.0 - lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 configure: error: *** Can't link to Pango. Pango is required to build *** GTK+. For more information see http://www.pango.org -END--- You need to look at config.log and see exactly _why_ configure failed to link to pango. Just saying that it did, tells us practically nothing. In contrast to you what you seem to believe there is no known bug that people often hit; there are just loads of ways that people can shoot themselves in the foot. this is after: ./configure --prefix=/usr --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --enable-slow-dependency-tracking --with-gnu-ld -with-x --with-cairo which gets: configuration: backends: FreeType X Xft make make install all seems fine but. firstly if I go to /usr/pango Im greeted with ../1.4.0 this is after doing my best to install 1.8.1 I'm assuming you mean $prefix/lib/pango/1.4.0 - this is expected: 1.4.0 is the ABI which pango version 1.8.1 (and many others) support. What I don't understand is where /usr/pango came from. If the prefix is /usr then there should be no such directory (or at least not from this build). Ive managed to "trick" a very old version of GTK2 to compile by setting the test for pango to TRUE but that doesn't seem quite proper and besides programs will then promply complain about my use of a backdated version of GTK2. I'm sure youv'e seen this before so try to be kind trust me Ive been very careful to avoid becoming flamebait but Im at my wits end with this. (I realize that might not be saying much but there you have it) extra stuff: lfs system (version 3.3) kernel 2.4.29 gcc 2.95.3 I'd suggest gcc 3.x might be a better choice, but I doubt very much this has anything to do with your problems. Hope this helps, Ali. ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: SIGSEGV at "gtk_init" in a Multithreaded Code
On 03/07/05 17:23:56, [EMAIL PROTECTED] wrote: Hi, I'm trying to execute the code example (about GTK and threads) at http://developer.gimp.org/api/2.0/gdk/gdk-Threads.html But whenever I execute it , it gives segmentation fault inside "gtk_init(&argc,&argv)" function. I have to mention that when I comment "g_thread_init" line, it works properly. What will be the problem? Is it my makefile: all : gcc -g -o gtkThread gtk-thread.c -lpthread `pkg-config gtk+-2.0 gthread --cflags --libs` This will pick up Gtk+ 2.x and GThread 1.x. I would try: gcc -g -o gtkThread gtk-thread.c -lpthread `pkg-config gtk+-2.0 gthread-2.0 --cflags --libs` instead (you shouldn't need the -lpthread either, but I doubt it's causing any problems). Cheers, Ali. ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: gtk and directX?
On 08/05/05 07:55:37, sinja Warnebold wrote: Hello!I am tring to design a 3D-Engine. To navigate through my menu I decided to develop a gtk GUI. Now I am not sure if I can add this GUI to my directX program or the other way round?Is it possible to call the direct X window from a GTK-GUI ? Can they interact? My problem seems to be that the one (gtk) is a win32 consol apllication and the other (directX) requires just a win32 application. Can anyone please help me?Thanks Sinja [Please don't use html in email] I tried this and it does sort of work, but I found that the GUI seemed to be missing some events in that it didn't act quite right. I solved the problem for me by having two processes (one for the GUI and one for DirectX which talk to each other). Cheers, Ali. ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Plotting, text drawing, etc.
On 07/02/05 04:46:50, James Frye wrote: Ok, dumb question #2. Is there a package that will let me do basic plotting within a GTK window? I found one called GtkPlot, but it only seems to link with GTK 1.x, and I can't find any documentation at all for it. GtkExtra - http://gtkextra.sourceforge.net/ As far as I know, the Gtk+ 2.x version (gtkextra-2) still hasn't been released so you need to build from cvs, which is a bit of a pain, but it does work. Cheers, Ali. ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: How to stop signal in the folowing case?
On 2004.05.11 14:01 Paul Davis wrote: this doesn't cause never ending recursion if MY_VALUE is a single value. gtk_spin_button_set_value (foo, val) does nothing if "val" is equal to the current value. this is a classic problem for Model-View-Controller programming, and blocking the signal is not normally the right way to deal with it. It isn't? Oh dear. I have a very similar problem at the moment with a model containing a floating point variable and two controllers: a GtkHScale and a GtkSpinButton. The controllers are added to the model as subscribers. This works fine if you use the spin button to change the variable - the hscale moves to match and it all looks very nice. Clicking in the gutter of the hscale also works. The problem is if you move the hscale by dragging it. This causes an oscillation between two values (one int and a close floating point number). I assume that the spin button is reacting to having it's adjustment set to a non-integer value by rounding it and something similar is happenind with the hscale. I was planning to simply lock the value in the model during the publishing phase to solve the problem, but it sounds as though that might not be the best approach. So, what _should_ I be doing? Cheers, -- J. Ali Harlow [EMAIL PROTECTED] ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: GTK and devices over TCP and serial ports
On 2004.05.07 09:34 Zbigniew Wasik wrote:
OK I already found reference to GSource (GLib as I thought)
but anyway I am asking whether you have maybe an example of use the
GSOurce
I don't have anything quite like you need. The closest I have is for
a TCP/IP server which uses a GSource to allow the mainloop to watch
for incoming connections. It goes something like this:
struct avgs_listen_watch {
GSource source;
GPollFD poll;
};
static gboolean avgs_listen_prepare(GSource *source,gint *timeout)
{
struct avgs_listen_watch *watch=(struct avgs_listen_watch *)source;
*timeout=-1;
#ifdef DEBUG
fprintf(stderr,"avgs_listen_prepare()=FALSE\n");
#endif
return FALSE;
}
static gboolean avgs_listen_check(GSource *source)
{
struct avgs_listen_watch *watch=(struct avgs_listen_watch *)source;
#ifdef DEBUG
fprintf(stderr,"avgs_listen_check()=%s\n",
watch->poll.revents&G_IO_IN?"TRUE":"FALSE");
#endif
return watch->poll.revents&G_IO_IN;
}
static gboolean avgs_listen_dispatch(GSource *source,GSourceFunc callback,
gpointer user_data)
{
int fd;
struct avgs_listen_watch *watch=(struct avgs_listen_watch *)source;
struct avgs_rpc_watch *rpcw;
#ifdef DEBUG
fprintf(stderr,"avgs_listen_dispatch()\n");
#endif
fd=accept(watch->poll.fd,NULL,NULL);
if (fd>=0)
{
/* deal with the incoming connection */
}
return TRUE;
}
static void avgs_listen_finalize(GSource *source)
{
}
GSourceFuncs avgs_listen_funcs = {
avgs_listen_prepare,
avgs_listen_check,
avgs_listen_dispatch,
avgs_listen_finalize,
};
int main(int argc,char **argv)
{
short *modes;
struct avgs_listen_watch *listenw;
struct addrinfo hints,*res;
char *s,*node;
int port,fd,retval;
if (argc<2)
{
fprintf(stderr,"Usage: %s \n",argv[0]);
exit(1);
}
s=strchr(argv[1],':');
if (!s)
{
fprintf(stderr,"%s: Missing port number in remote\n",argv[0]);
exit(1);
}
port=atoi(s+1);
if (port<=0 || port>65535)
{
fprintf(stderr,"%s: Illegal port number in remote
(%d)\n",argv[0],port);
exit(1);
}
node=malloc(s-argv[1]+1);
memcpy(node,argv[1],s-argv[1]);
node[s-argv[1]]='\0';
hints.ai_family=PF_UNSPEC;
hints.ai_socktype=SOCK_STREAM;
hints.ai_protocol=0;
hints.ai_flags=0;
retval=getaddrinfo(node,s+1,&hints,&res);
free(node);
if (retval)
{
fprintf(stderr,"%s: %s\n",argv[0],gai_strerror(retval));
exit(1);
}
fd=socket(res->ai_family,res->ai_socktype,res->ai_protocol);
if (fd<0)
{
perror(argv[0]);
freeaddrinfo(res);
exit(1);
}
if (bind(fd,res->ai_addr,res->ai_addrlen))
{
perror(argv[0]);
freeaddrinfo(res);
close(fd);
exit(1);
}
if (listen(fd,0))
{
perror(argv[0]);
freeaddrinfo(res);
close(fd);
exit(1);
}
freeaddrinfo(res);
listenw=(struct avgs_listen_watch *)
g_source_new(&avgs_listen_funcs,sizeof(*listenw));
if (!listenw)
{
fprintf(stderr,"%s: Not enough memory\n",argv[0]);
exit(1);
}
listenw->poll.fd=fd;
listenw->poll.events=G_IO_IN;
g_source_add_poll((GSource *)listenw,&listenw->poll);
g_source_attach((GSource *)listenw,NULL);
ml=g_main_loop_new(NULL,FALSE);
g_main_loop_run(ml);
g_main_loop_unref(ml);
exit(0);
}
Also do you have experience with showing images? If so what you think
what is better to use Gdk-Pixbuff or GdkRGB ?
I guess it depends. I use GdkRGB since that's easy for me and GdkPixbuf
is implemented using GdkRGB so it can't be any faster.
HTH,
--
J. Ali Harlow
[EMAIL PROTECTED]
___
gtk-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: GTK and devices over TCP and serial ports
On 2004.05.06 13:36 Zbigniew Wasik wrote: Hi Lately I became a user of GTK and I do not have problem with GTK GUI, libraries or whatever I think it is great. and Puxbif is quite good - either for animations I think - however I am not the expert. But Yeah alway those but I need now to write and GUI/Application (in GTK) which will connect to Pan Tilt Unit (PTU) and camera which is mounted on top of PTU. OK the problem is that the GUI need to show the image from the camera (data comes through TCP/IP) and abibilty to control/monitor the PTU (it means I need to read position of the PTU - two angles and to be able to send a command to the PTU to move camera in other direction) You need to add a GSource for each camera to the mainloop which uses a GPoll on the TCP/IP socket that is connected to the respective camera. It's also possible to do this with a GIOChannel, but I don't think there's any advantage. Cheers, -- J. Ali Harlow [EMAIL PROTECTED] ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Problems installing GTK+ 2.4
On 2004.04.24 20:00 Joe wrote: Hi everyone I'm having a problem with the installation of GTK+ 2.4. I have looked through the list archives, found a similar problem, but after following the steps to solve it found that it didn't work for me. My problem is that when running ./configure for gtk, the message 'error: pango 1.2.0 and Xft backend required' comes up. All of the supporting packages for gtk are the latest versions, including pango 1.4, xft 2.1.2. Including freetype? -- J. Ali Harlow [EMAIL PROTECTED] ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: cross compiling glib and glib-genmarshal
On 2004.04.23 23:32 Vlasios Tsiatsis wrote: Hi all, i am not sure if this is the right list to post this question so i apologize if it is not. I tried to cross compile glib for an arm-based platform uing arm-linux-gcc on a i686-linux host. The building process stopped because i didn't have the binary glib-genmarshal on the host platform. But this utility is part of the glib itself! I noticed that for some reason this binary was produced for the target platform (arm-linux) and not for the host platform (i686-linux). So what i did was the following: I built glib for the host platform (i686-linux) and installed the binaries in glib-2.4.0/obj.i686. I updated the path to include glib-2.4.0/obj.i686/bin (so that glib-genmarshal could be found). Then i configured and built glib for the target platform (arm-linux) and the process was successful. Shouldn't glib-genmarshal be compiled using the host gcc compiler instead of the target gcc compiler? You (potentially) need the arm-linux binary to build application programs and the i686-linux binary to build Gtk+. While it would be theoritically possible to build both of these in one invocation of make, in practice it's much easier to require people to do it in two seperate configure/make install operations as you have described above. HTH, -- J. Ali Harlow [EMAIL PROTECTED] ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: error: core dumped
On 2004.04.21 10:52 Sven Neumann wrote:
Your usage of GError is wrong. Please read the API documentation on it
again. The (probably) correct code is:
int
main (int argc,
char *argv[])
{
guchar*v;
GdkPixbuf *pixbuf;
GError*error = NULL;
g_type_init ();
pixbuf = gdk_pixbuf_new_from_file ("image.jpg", error);
*cough*
pixbuf = gdk_pixbuf_new_from_file ("image.jpg", &error);
if (pixbuf)
v = gdk_pixbuf_get_pixels (pixbuf);
else
/* handle error here */;
return 0;
}
___
gtk-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Gdk-WARNING: BitBlt failed
On 2004.04.15 16:20 Egon Andersen wrote: Hi, I've seen this warning on MS Windows XP: Gdk-WARNING **: gdkdrawable-win32.c1568: BitBlt failed: Handlen er ikke gyldig. (The last 4 words translated to english: "The handle is not valid.") This seems to happen when Windows XP goes into 'Screen-lock'. There are probably 100 or more occurences of this error message. The same application compiled on/for Linux do not cause this error-message, when Linux goes into 'Screen-lock'. Do anyone know what causes this problem and knows about a cure? (There is no timer signals in the application, but perhaps there are some internally in Gtk+/Gdk.) Known bug, see http://bugzilla.gnome.org/show_bug.cgi?id=137796 Cheers, Ali. ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Gimp/Windows/Tablets
On 2004.03.08 15:08 Jazelle wrote: This was posted to me on another site: Just a quick word about Gimp and tablets, to save you from any unpleasant surprises: if you're using Windows, then just be warned that the tablet support for Gimp on Windows is currently broken. This hasn't been fixed in Gimp 2 either. You can use the tablet if you turn off tablet options and just use the pen as a mouse, but then you won't be able to make use of things such as pressure sensitivity and whatnot (aww...). Apparently the problem is not really in Gimp, but in GTK, go figure. I just bought a tablet and was hoping to use it with GIMP but now I don't know. I want to be able to use all the features or why have it at all. If you are a GTK developer please address this problem for us window uses ASAP please. Bugs 81663 and 133645 would appear to apply. http://bugzilla.gnome.org/show_bug.cgi?id=81663 and http://bugzilla.gnome.org/show_bug.cgi?id=133645 Not that this helps you very much, but at least it's a known problem. Cheers, Ali. ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: [bob@brasko.net: Re: Glib]
On 2004.03.04 16:17 Sven Neumann wrote: pkg-config doesn't depend on glib. It comes with it's own copy of glib-1.2 but you shouldn't have to worry about that. In the native win32 build, it does depend on glib (which I believe is what Bob is using). But I agree, it's not important. Then, glib doesn't actually depend on pkg-config. configure only checks for it's presense since we think that pkg-config should be installed when glib is installed. This is just a convenience check to catch problems early. pkg-config is not used at all during the glib build process. If, and when, libiconv and/or gettext provide a .pc file, I would like glib's configure to use pkg-config to find them. It would make my life easier :-) Whatever, pkg-config is just a build tool. It doesn't need to be present on the target platform and it should not be a problem to install pkg-config on the build host (especially since it comes packaged with all distributions). Indeed. It runs on systems where autoconf can't run (eg., win32 without cgywin installed) and, contrary to Tristan's views, I find it invaluable when cross-compiling. This has nothing to do with the development of glib. Cheers, Ali. ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: GTK-2.3.5 installation problem
On 2004.03.04 11:12 Steffen Gutmann wrote: Hello, when I do a configure in the new gtk-2.3.5 directort I get the following error message: checking for freetype-config... /usr/bin/freetype-config checking For sufficiently new FreeType (at least 2.0.1)... no configure: error: Pango 1.2.0 and Xft backend is required for x11 target I installed latest glib and pango sucessfully. I am on RedHat 7.3. Yes, but have you installed FreeType 2.0.1 or later ? http://www.freetype.org/ (there may well be an RPM around as well). (You'll need to re-install pango once you've done this.) Cheers, Ali. ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: g_io_channel and UDP sockets
On 2004.02.24 18:50 Jeff Abrahamson wrote: I get this by calling GError *err; iostat = g_io_channel_read_to_end(source, &str_return, &length, &err); That should be GError *err = NULL; Cheers, Ali. ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Install problem with GTK+.
On 2004.02.14 14:15 Vincent Torri wrote: On Sat, 14 Feb 2004 [EMAIL PROTECTED] wrote: > First of all, greetings to all of you. :) > > To the problem. > In the directory, gtk+-2.2.4 I did the following: > > PKG_CONFIG=/usr/local/bin /* pkg-config executable is here for sure */ > export PKG_CONFIG > PKG_CONFIG_PATH=/usr/lib /* Not very sure whether the libraries are here! PKG_CONFIG_PATH=/usr/lib/pkgconfig (if it exists; otherwise, /usr/local/lib/pkgconfig) ... and PKG_CONFIG should point to the executable rather than to a dir. Cheers, -- J. Ali Harlow [EMAIL PROTECTED] ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: GTK+ for Windows
On 2003.12.29 18:01 Sriram Yadavalli wrote: Hi, Should I just install GTK+ runtime and development environment or do I need to download libiconv, glib, pango, atk, gettext, pkg-config? Am I missing any other dependency? You need the development environment to compile and link your programs and the runtime environment to test and/or use them. Both environments contain all of Gtk+'s dependencies, including the ones you mention. -- J. Ali Harlow [EMAIL PROTECTED] ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: GTK+ for Windows
On 2003.12.29 17:05 Sriram Yadavalli wrote: Hi, I am new to GTK+. I want to install it on Windows 2000 and develop applications. Is there any site where I can find the install procedure> I want to develop my applications in Microsoft Visual Studio. Any help would be appreciated. http://www.gimp.org/win32/ or for an easier life http://www.dropline.net/gtk No idea about using Microsoft Visual Studio, sorry; I use mingw. -- J. Ali Harlow [EMAIL PROTECTED] ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: why is gtk install so difficult?
On 2003.10.15 11:12 [EMAIL PROTECTED] wrote: > From: Ruben Safir Secretary NYLXS [mailto:[EMAIL PROTECTED] > GTK is only hard to compile and install by hand because the > developers have chosen to make it so. Nobody decided to make anything difficult. Quite so. A lot of the complexity comes from the fact that Gtk+ depends on so many other libraries. While I think it's unfortunate that this is the case, I really don't see that the developers could have made any better choices without sacrificing functionality. Personally, I've never had any major problems compiling Gtk+ itself under UNIX, although I have had some problems with the dependcies. Where I have found it hard is when cross-compiling under mingw32, but a lot of the problems with this are caused by autohell rather than Gtk+ itself. It used to be harder, but Owen put a lot of effort into making it easier (especially glib), for which I'm very grateful. Perhaps I have a slightly different attitude in that while I am an open source developer, I also use Gtk+ in my commercial developing so I'm under no illusions that the Gtk+ team owe me anything. Cheers, Ali. ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: gtk 2.2 for Windows with mingw32 hosted under Linux
On 2003.07.03 12:43 Andreas Kostyrka wrote: > Seems you forgot /usr/local/cross-tools/libtool/bin/libtool ;) Please find attached my scripts for building a hacked version of libtool 1.4.2. Be aware that this is a hack and that a different approach will need to be taken with libtool 1.5. Oh, and if you think I've forgotten the scripts to bulid the cross-compiler, let me know so I can remember them :-) Seriously, I'm happy to send you these as well if you want them, but you might be better off trying to get the latest version of mingw32 to build as a cross-compiler. This will make it much easier to use libtool 1.5. I think I'd start by looking at the debian cross-compiler package for ideas. Cheers, -- Ali Harlow Email: [EMAIL PROTECTED] Research programmer Tel: (020) 7040 4348 Applied Vision Research Centre Intl: +44 20 7040 4348 City University Fax: (020) 7040 5515 London Intl: +44 20 7040 5515 libtool-1.4.2-7A.tgz Description: GNU Zip compressed data
Re: gtk 2.2 for Windows with mingw32 hosted under Linux
On 2003.07.02 19:39 Andreas Kostyrka wrote: > On Wed, 2003-07-02 at 16:21, J. Ali Harlow wrote: > > > I can provide copies of my scripts, hacked > > version of libtool etc., if needed. > > Well, it would be very nice if you could share your scripts. No problem. -- Ali Harlow Email: [EMAIL PROTECTED] Research programmer Tel: (020) 7040 4348 Applied Vision Research Centre Intl: +44 20 7040 4348 City University Fax: (020) 7040 5515 London Intl: +44 20 7040 5515 gtk_scripts.tgz Description: GNU Zip compressed data
Re: gtk 2.2 for Windows with mingw32 hosted under Linux
On 2003.07.02 15:20 Andreas Kostyrka wrote: > Hi! > > I've been wondering if somebody ever tried to compile Gtk2.2 with a > crosscompiling Mingw32 hosted on Linux? If so, how does one start such > task? Yes. I do this. I started top-down (ie., with Gtk+) using Tor's binaries for the low level libraries until I managed to get each one built. It would obviously be more logical to start from the bottom if you were prepared to accept the delay before having anything working. I can provide copies of my scripts, hacked version of libtool etc., if needed. I haven't yet tried to build Gtk+ 2.2.2 which I have a vague recollection is now based on libtool 1.5 (or was that 2.3?). I know that I'm going to have some serious problems with libtool 1.5, but these may not affect you if you start from scratch. HTH, -- Ali Harlow Email: [EMAIL PROTECTED] Research programmer Tel: (020) 7040 4348 Applied Vision Research Centre Intl: +44 20 7040 4348 City University Fax: (020) 7040 5515 London Intl: +44 20 7040 5515 ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: WIN32 build of a GTK2 app
On 2003.02.05 03:26 Graham Swallow wrote: I'm trying to compile/link/run a GTK app on WIN32 (it works on Linux). I'm using: MinGW-2.0.0-3.exe MSYS-1.0.8-rc-1.exe gtk+-dev-2.2.0-20030119.zip It links, but at run time says (in a popup dialog): Gtk-ERROR Incompatible build The code using GTK+ thinks GtkBox is of different size than it actually is on this build of GTK+ On Windows ... without the -fnative-struct [or -mms-bitfields] switch, or ar using an unsupported compiler ... So I go back to using the option and get the compile error: cc1plus.exe: unrecognised option '-fnative-struct' Can someone please help me out here, what g++/msys works? MinGW 2.x (gcc 3.x) needs -mms-bitfields, MinGW 1.x (gcc 2.x) needs -fnative-struct HTH, -- Ali Harlow Email: [EMAIL PROTECTED] Research programmer Tel: (020) 7040 4348 Applied Vision Research Centre Intl: +44 20 7040 4348 City University Fax: (020) 7040 5515 London Intl: +44 20 7040 5515 ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Linux -> win32 cross-compile
On 2002.06.18 10:45 Robbert Haarman wrote: > Well, I got good news and bad news. I got my hello.c to compile (mingw > needs the libraries _after_ the object file, I had them before). That's > the good news. The bad news is that running it under wine gives the > following error: > > Gtk-ERROR **: Incompatible build! > The code using GTK+ thinks GtkBox is of different > size than it actually is in this build of GTK+. > On Windows, this probably means that you have compiled > your code with gcc without the -fnative-struct switch, > or that you are using an unsupported compiler. > aborting... > > I added the -fnative-struct switch, but to no avail. I haven't tested > the program on a real Windows box yet (I don't have one), but it seems > unlikely that it will work there. Any hints? I tried a Google search for > the error, but that didn't get me any further. Anyway, I think I have > gathered enough material for a mini-HOWTO now. :-/ The problem is almost certainly with -fnative-struct as the error message says. Did you add -fnative-struct to the compile flags and make sure that all modules were recompiled with that flag? -- Ali Harlow Email: [EMAIL PROTECTED] Research programmer Tel: (020) 7040 4348 Applied Vision Research Centre Intl: +44 20 7040 4348 City University Fax: (020) 7040 5515 London Intl: +44 20 7040 5515 ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Colors
On Sun, 08 Apr 2001, Valery Avaux wrote: > Hello, > > I use a drawing area with 2 colors red and blue. But I don't know to get > other colors . For these two I use the following defintion that were > given me. > > blue.red = 0; > blue.green = 0; > blue.blue = 0xff * 0x100; > gdk_colormap_alloc_color(colormap, &blue, FALSE, TRUE); > > red.red = 0xff * 0x100; > red.green = 0; > red.blue = 0; > > Could someone explain how to get other colors (for example white) ? Monitors are light based. Thus you create colours in exactly the way you would when mixing colours from spotlights (assuming you were taught this in physics classes where you are): Red + Green = yellow Green + Blue = cyan Blue + Red = magenta Red + Green + Blue = white If you've got a copy of rgb.txt (ie., in /usr/X11R6/lib/X11/rgb.txt) this has X11's list of colour names and values for red, green and blue. You'll want to scale these from 0-255 to 0-65535 (as you have done above by multiplying by 0x100). For example, rgb.txt contains the line: 46 139 87 SeaGreen So we might create this using: seagreen.red = 46 * 0x100; seagreen.green = 139 * 0x100; seagreen.blue = 87 * 0x100; (some people prefer to multiply by 257 rather than 0x100 (256) because it gives better scaling. ie., 255 * 257 = 65535.) -- Ali Harlow Email: [EMAIL PROTECTED] Research programmer Tel: (020) 7477 8000 X 4348 Applied Vision Research Centre Intl: +44 20 7477 8000 X 4348 City University Fax: (020) 7505 5515 London Intl: +44 20 7505 5515 ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: pixmaps and xpm-transparency
On Tue, 17 Apr 2001, Tobias Hintze wrote: > On Tue, Apr 17, 2001 at 04:50:04PM +0100, J. Ali Harlow wrote: > > > > Pixmaps don't support transparency. You have to use pixbufs. > > so i have to use GTK+2.0 API? seems so. To use Pixbuf, yes. > well, perhaps i don't need transparency but have to use my masks the > right way. (i just need one-bit-depth-transparency) > > is it possible somehow to draw pixmap2 over pixmap1 using a mask > (from pixmap2)? I've never done this myself, but why don't you try gdk_gc_set_clip_mask. > > When I get time I'll put together a test program and > > log a bug against it. And least that way I'll get a response, even if it's just > > to tell me that I've misunderstood how it's supposed to work.) > > so give me a line then...o If you want a solution using images (which works in GTK+ 1.2.x) and is nice and fast please have a look at the algorithms I use for Slash'EM at: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/slashem/slashem/win/gtk2/ gtktile.c (high level) and xshmmap.c (low level) are the files of interest. Warning: The GTK+ team don't like this method. You must make up your own mind. HTH -- Ali Harlow Email: [EMAIL PROTECTED] Research programmer Tel: (020) 7477 8000 X 4348 Applied Vision Research Centre Intl: +44 20 7477 8000 X 4348 City University Fax: (020) 7505 5515 London Intl: +44 20 7505 5515 ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: pixmaps and xpm-transparency
On Tue, 17 Apr 2001, Tobias Hintze wrote: > what am i doing wrong? Pixmaps don't support transparency. You have to use pixbufs. (Not that I can get pixbufs to work either :-) I posted here about this some time ago with no response. When I get time I'll put together a test program and log a bug against it. And least that way I'll get a response, even if it's just to tell me that I've misunderstood how it's supposed to work.) Good luck, -- Ali Harlow Email: [EMAIL PROTECTED] Research programmer Tel: (020) 7477 8000 X 4348 Applied Vision Research Centre Intl: +44 20 7477 8000 X 4348 City University Fax: (020) 7505 5515 London Intl: +44 20 7505 5515 ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
GdkPixbuf and transparency
Hi all,
I'm having problems with GdkPixbufs and source-transparency in GTK+ 1.3.3...
As a bit of background: I'm trying to persuade the GTK+ team to implement a
method of rendering directly from a pixbuf to an image (without going via a
pixmap). Their current view appears to be that this should never be neccessary
- you should be able to do everything using pixbufs. I'm almost certain that
they are mistaken and that for at least some applications pixbufs will be a lot
slower. Nevertheless, it's not much use for me to just assert that this is the
case without some hard data. Consequently, I'm trying to implement a parallel
algorithm for the application that I help develop (Slash'EM) to work with
pixbufs (an algorithm already exists for images using GdkImage).
My problem is that I can't seem to get gdk_pixbuf_composite() to work as
expected. It's entirely possible that I'm doing something stupid, but I can't
see what.
I'll use "raster" as a generic term to represent a 2D array of pixels since
image might be confusing.
The basic setup in Slash'EM is that we have a tileset which is just a large
static raster loaded from disk which contains a 2D array of tiles. When we want
to update a cell on the map window, we take two tiles (a background and a
foreground tile) and overlay them in a temporary raster before this is then
copied to the master raster (the expose handler then updates the screen from
this in due course). Actually, because both background and foreground tiles have
transparent pixels it would be more correct to say that we overlay both of them
on a black background.
My current algorithm to do this is as follows:
1. Clear the temporary raster with memset() to zero:
memset(gdk_pixbuf_get_pixels(tmp_pixbuf), 0,
gdk_pixbug_get_height(tmp_pixbuf) * gdk_pixbuf_get_rowstride(tmp_pixbuf));
2. Overlay the background tile with gdk_pixbuf_copy_area():
gdk_pixbuf_copy_area(tile_pixbuf, srcx, srcy, width, height,
tmp_pixbuf, dstx, dsty);
srcx and srcy select the correct tile from the tileset stored in tile_pixbuf.
dstx and dsty are normally zero and width and height are normally the size
of the temporary raster (the same as the tiles).
3. Force all pixels to opaque (not sure if this is neccessary):
for(j=0;junit_height;j++)
for(i=0;iunit_width;i++) {
nh_pixbuf_get_pixel(i, j, rgba);
rgba[3] = 255;
nh_pixbuf_put_pixel(i, j, rgba);
}
where rgba is an array of 4 guchars, nh_pixbuf_get_pixel() and
nh_pixbuf_put_pixel() do the obvious. unit_height and unit_width are the
sizes of the tiles.
4. Overlay the foreground tile with pdk_pixbuf_composite():
gdk_pixbuf_composite(tile_pixbuf, tmp_pixbuf, dstx, dsty, width,
height, -srcx, -srcy, 1.0, 1.0, GDK_INTERP_NEAREST, 255.0);
5. Copy to the master raster with gdk_pixbuf_copy_area():
gdk_pixbuf_copy_area(tmp_pixbuf, 0, 0, gdk_pixbug_get_width(tmp_pixbuf),
gdk_pixbug_get_height(tmp_pixbuf), xshm_map_pixbuf, dest_x, dest_y);
where xshm_map_pixbuf is the master copy of the map and dest_x and dest_y
are the coordinates of the relevant cell.
The expose handler then updates the server-side copy of the map like this:
gdk_gc_set_clip_region(gc, xshm.dirty);
gdk_pixbuf_render_to_drawable(xshm_map_pixbuf, xshm.pixmap, gc,
0, 0, 0, 0, xshm.map_width, xshm.map_height,
GDK_RGB_DITHER_NORMAL, 0, 0);
where xshm.dirty is a region consisting of the union of all cells that have
been modified since the expose handler was last called.
The problem (finally) is that the background tiles look perfect but the
foreground tiles are just silhouettes in a dithered, desaturated green.
The green looks like it could well be the colour that we use to indicate
transparancy in the tileset. The background tile is correctly visible in the
transparent parts of the foreground tile.
Note that if I replace step 4 with a call to gdk_pixbuf_copy_area() then all
works as expected (we get opaque foreground tiles).
I would be very grateful for any help you may be able to give me.
--
Ali Harlow Email: [EMAIL PROTECTED]
Research programmer Tel: (020) 7477 8000 X 4348
Applied Vision Research Centre Intl: +44 20 7477 8000 X 4348
City University Fax: (020) 7505 5515
London Intl: +44 20 7505 5515
___
gtk-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: text or clist
On Fri, 30 Mar 2001, Sylvain Trias wrote: > Hi again folks! > We want to display some text in a window for our lan chat program. > GtkText seems buggy (mail list) Clist can't do line wrap ??? > What could we use ? Use GtkTextView from the GTK+ v2.0 API (v1.3.2 is available for developing your code now). It means you won't be able to release a stable version of your app until 2.0 comes out, but that's a small price to pay in my view. -- Ali Harlow Email: [EMAIL PROTECTED] Research programmer Tel: (020) 7477 8000 X 4348 Applied Vision Research Centre Intl: +44 20 7477 8000 X 4348 City University Fax: (020) 7505 5515 London Intl: +44 20 7505 5515 ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Using GdkPixmaps for storing static image data
On Thu, 22 Mar 2001, Havoc Pennington wrote: > bugzilla.gnome.org is the place for suggestions, if you want to be > sure they don't get forgotten. Thanks. I hadn't realised this was in use for suggestions as well. -- Ali Harlow Email: [EMAIL PROTECTED] Research programmer Tel: (020) 7477 8000 X 4348 Applied Vision Research Centre Intl: +44 20 7477 8000 X 4348 City University Fax: (020) 7505 5515 London Intl: +44 20 7505 5515 ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Using GdkPixmaps for storing static image data
On Thu, 22 Mar 2001, Havoc Pennington wrote: > Well sure, but this is a non-issue for toolbars. GdkPixmap is intended > for exactly this kind of server-side buffering when performance is > important. For some little toolbar icons, there's no point > complicating things. Right. I had a feeling I'd got the wrong end of the stick. I was just worried that GdkPixmap would become depreciated. Obviously, a non-issue. > > One of the things I think Gtk is missing is a function to go from disk to > > image. You can use the API to go via pixmaps, but that's a little > > crazy :-) > > In general I don't think there's too much reason to use images - > it's just too hard to handle all the visual-specific details. > So Pixbuf is in that sense a GdkImage replacement. Except that there's no concept of a shareable Pixbuf. When you are sending large amounts of raster data from client-side to server-side on a regular basis shared images make a large difference. I've no idea whether this is a common requirement for applications. We need to do it when we start using complicated transparancy algorithms which can't be done server-side. Perhaps we're a little unusual in this regard in the GTK+ world. > > One of my remaining jobs is to write a routine to copy from pixbufs to images > > to solve this. > > This code should already be in pixbuf_render_to_drawable(), it draws > to a pixmap by first going to an image, then to the pixmap, IIRC. Thanks, I missed that. May take me a while to understand the code :-) Might I suggest that the API be expanded to provide a function to do this at some point in the life of Gdk? -- Ali Harlow Email: [EMAIL PROTECTED] Research programmer Tel: (020) 7477 8000 X 4348 Applied Vision Research Centre Intl: +44 20 7477 8000 X 4348 City University Fax: (020) 7505 5515 London Intl: +44 20 7505 5515 ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Using GdkPixmaps for storing static image data
On Thu, 22 Mar 2001, Havoc Pennington wrote: > Basically a GdkPixmap is a server-side image data buffer, and isn't > all that appropriate as a place to store image data loaded from disk, > among other reasons because it makes you think about the visual/cmap > of the workstation's video hardware. > > Anyhow, in GTK 2 the GdkPixmap code still works but you no longer need > to use it in newly-written application code. That's quite a statement! Perhaps I've missunderstood. In Slash'EM (not-yet-cvs) we maintain a drawing area which is basically a map of your surroundings, built up of tiles. These tiles are stored in a tileset, which (depending on the mode) can be stored in a Pixmap. This makes drawing to the map an efficient operation since both the tileset and the map are server-side and the drawing commands end up being a series of CopyArea requests. If we were to use Pixbufs we would presumably end up with a series of PutImage requests which would be a _lot_ slower. In other modes we store the tileset in an image and keep the map's backing store as a shared image so we render from the tileset to the image without sending any data to the server and then use whatever the gdk function is (sorry, the code's at home) to draw from an image to a pixmap and hope that this function deals efficiently with shared images. It seems to work well except that my code to copy from image to image is currently just using the pixel routines which are very slow. Where shared images aren't available, we have to do things the hard way. One of the things I think Gtk is missing is a function to go from disk to image. You can use the API to go via pixmaps, but that's a little crazy :-) One of my remaining jobs is to write a routine to copy from pixbufs to images to solve this. -- Ali Harlow Email: [EMAIL PROTECTED] Research programmer Tel: (020) 7477 8000 X 4348 Applied Vision Research Centre Intl: +44 20 7477 8000 X 4348 City University Fax: (020) 7505 5515 London Intl: +44 20 7505 5515 ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Need help debugging Gdk-ERROR
On Sun, 18 Mar 2001, Eric M. Monsler wrote: > "J. Ali Harlow" wrote: > > > (snip) > > How many places are you calling gdk_draw_points() from in your > > code anyway? > > Never. > > Well, never directly. I'm using gtkplot from the gtkextra package. A package I know nothing about ... somebody on the list must, however. [snip] > Is gdk_draw_points() the ONLY gdk call that could produce a PolyPoint > request? If so, I can start looking through the 5 or 6 gtk_plot...() > calls that I make when refreshing, and try to find a gdk_draw_points() > that is shortly after an allocation or recreation. My reading of the X11 backend to Gdk in version 1.3.2 says that the gdk_draw_points primitive is the only mechanism. It is, however, quite possible that any number of gdk calls (not to mention gtk calls) actually end up using this mechanism. gdk_draw_point() is one such, gdk_pixmap_draw_points() and gdk_window_draw_points() are two more. I don't even begin to know the Gdk source code well enough to be certain there aren't any more that I've missed in the Gdk. Again, others may. > [Brief research] > I would guess not, as gtkextra never uses gdk_draw_points, although it > does use gdk_draw_point. For that matter, only in gtkcurve.c does GTK > call gdk_draw_points(). For the most part, both use gdk_draw_point() > instead. I wonder if XFillPolygon() would cause a request code > PolyPoint? Not according to my X reference books (O'Reilly Xlib ref manual, 3rd printing). XDrawPoint and XDrawPoints are the only possibilities. XFillPolygon() uses X_FillPoly. > One new data point, it does not seem to happen when using the Solaris > Xserver. I have't done enough tests to establish "never" for a fact, > but it is "less" prone to the problem than when using the eXodus Xserver > on NT. I wonder if my Xserver is non-conforming, or if the Solaris one > is just more robust/careful/prompt in allocating. No idea. -- Ali Harlow Email: [EMAIL PROTECTED] Research programmer Tel: (020) 7477 8000 X 4348 Applied Vision Research Centre Intl: +44 20 7477 8000 X 4348 City University Fax: (020) 7505 5515 London Intl: +44 20 7505 5515 ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Need help debugging Gdk-ERROR
On Sat, 17 Mar 2001, Havoc Pennington wrote: > "Eric M. Monsler" <[EMAIL PROTECTED]> writes: > > Any guesses as to what could be occurring, that might cause different > > behavior with '--sync' or not? > > > > Maybe, creating something and trying to act on it too soon, before it is > > 'realized', but --sync causes the Xserver to allocate the resources > > immediately? > > > > Right, there's conceivably some kind of race condition. > > You can manually ensure that you're synced at a given point with > gdk_flush(), could help experiment. How many places are you calling gdk_draw_points() from in your code anyway? I don't know if any other Gdk routines call this internally, but you could certainly start by looking at your calls. A gdk_flush() immediately after the call might produce helpfull results, so might printing out the X resource ID using GDK_WINDOW_XWINDOW(drawable). You need to include to use this macro. You could even get fancy and use the internal resource tracking to see if the resource ID was ever allocated: You can get the Xdisplay with GDK_WINDOW_XDISPLAY(drawable), then dpy->resource_base is the first ID allocated by this client and dpy->resource_base + (dpy->resource_id - 1 << dpy->resource_shift) is the last. This will at least tell you whether the problem is that the window has been destroyed, never allocated or is complete rubbish. Warning: all the above is written from theory; I've never needed to do quite this, so I could easily have got it completely wrong. It's also not even vaguely portable, so might not work on your system anyway (I use Linux). -- Ali Harlow Email: [EMAIL PROTECTED] Research programmer Tel: (020) 7477 8000 X 4348 Applied Vision Research Centre Intl: +44 20 7477 8000 X 4348 City University Fax: (020) 7505 5515 London Intl: +44 20 7505 5515 ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Need help debugging Gdk-ERROR
On Fri, 16 Mar 2001, Eric M. Monsler wrote: > "J. Ali Harlow" wrote: > > > (snip) > > See Havoc's recent message: > > I tried this, actually, and should have mentioned it. > > But, after the Gdk-ERROR (there were actually two this time, same codes, > serial's differing by 1), there was the report that the application has > exited with return value 1. I tried backtrace anyway, but was told 'no > stack'. My apologies. It appears that gdk_x_error() uses fprintf if G_ENABLE_DEBUG is not defined. You should be able to just set a breakpoint on gdx_x_error in gdb before you run the program and then backtrace when it gets triggered. > One reason I didn't mention that I had tried this was that I was not > sure that the --g-fatal-warnings approach was useful for tracking down X > errors. Obviously not. Learn something new every day... > If I run without the --sync argument, my understanding is that when the > error occurs, the current state of the stack may not represent the calls > that produced the error. Is this correct? Yes. With --sync, each X call will wait for a response back from the server before returning to the application. Without --sync, the error may not be noticed until a number of X requests have been sent after the one that actually caused the error. -- Ali Harlow Email: [EMAIL PROTECTED] Research programmer Tel: (020) 7477 8000 X 4348 Applied Vision Research Centre Intl: +44 20 7477 8000 X 4348 City University Fax: (020) 7505 5515 London Intl: +44 20 7505 5515 ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Need help debugging Gdk-ERROR
On Fri, 16 Mar 2001, Eric M. Monsler wrote: > So, two questions: > > 1) I believe that "error code 9 request_code 64" are from the reporting > by X or Xlib. If this is correct, is there an online reference that I > can consult to find out what those mean? /usr/include/X11/X.h has the error codes (but Gdk has already decoded 9 for you; BadDrawable). /usr/include/X11/Xproto.h has the request codes. 64 is PolyPoint. > 2) Any other suggestions on how to track down this problem? See Havoc's recent message: > Run the app in gdb with --g-fatal-warnings: > $ gdb myapp > (gdb) run --g-fatal-warnings > [close the window, note crash] > (gdb) backtrace > > That will show where it crashes. Cheers, -- Ali Harlow Email: [EMAIL PROTECTED] Research programmer Tel: (020) 7477 8000 X 4348 Applied Vision Research Centre Intl: +44 20 7477 8000 X 4348 City University Fax: (020) 7505 5515 London Intl: +44 20 7505 5515 ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Gnomehack installation problems.
On Thu, 15 Mar 2001, Joseph Elwell wrote in [EMAIL PROTECTED]: > I just installed gnomehack using an rpm i got through > nautilus: > gnomehack-1.0.5-1 > > When I try to run the application I get this error: > Gtk-WARNING **: This process is currently running > setuid or setgid. > This is not a supported use of GTK+. You must create a > helper > program instead. For further details, see: > > http://www.gtk.org/setuid.html > > Refusing to initialize GTK+. This is a new feature of GTK+ v1.2.9 (discussed at length on gtk-list). > Both gnomehack and nethack were installed suid as > root. :( That sounds like a security hole waiting to > be exploited. chmod -s to both gnomehack and nethack > didn't help. although nethack will run just fine > anyways, gnomehack still won't run. Ouch. The recommended configuration is setgid games, but GTK+ v1.2.9 won't allow that either. You have two choices, either drop down to GTK+ v1.2.8 or configure gnomehack to run without setuid/setgid (in which case there will be nothing to prevent save file abuse, but this may not matter if you can trust every player on your system). If you decide to go for GTK+ v1.2.8, _please_ reconfigure gnomehack for setgid games. Note: You will need the source to reconfigure gnomehack. While you're at it you might consider upgrading to NetHack 3.3.1 and using the gnome interface (which was integrated from gnomehack when that went unmaintained). The same setuid/setgid issues apply. [Owen, that's one point to you I believe :-)] -- Ali Harlow Email: [EMAIL PROTECTED] Research programmer Tel: (020) 7477 8000 X 4348 Applied Vision Research Centre Intl: +44 20 7477 8000 X 4348 City University Fax: (020) 7505 5515 London Intl: +44 20 7505 5515 ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: gtk+-1.2.10
On Wed, 14 Mar 2001, [EMAIL PROTECTED] wrote: > As mentioned in the message, the game itself is owned by games (the > user) and bin (the group). The permissions on the executable are : > rwxr-xr-x. (BTW - this is the QT-hack variant) > > I won't pretend to know what's going on inside, but I know that the > saved files are owned games:user (user being the primary group of the > user) > > Unix NetHack Version 3.3.1 compiled with QT support. > > After pulling open the source code and taking a look, nethack does > actually setgid/setuid on a file save: > > nethack-3.3.1/src/files.c: line 758-759 > (void) setgid(getgid()); > (void) setuid(getuid()); These two lines drop privileges before running gzip (or whatever), as explained on lines 742-744 of that same file. > The game itself doesn't run setuid/setgid so I think this would work > under GTK since GTKs issue is only with having the permissions > setuid/setgid. I'd guess you are getting confused with the shell script which launches NetHack. If you are running a "standard" NetHack configuration (ie., not Debian, and others that conform to FHS instead), /usr/games/nethack is the shell script (about 1Kb), the executable is in /usr/games/lib/nethackdir/nethack and will be a lot bigger. In it's FHS2.0 configuration, Slash'EM puts the executable in /usr/lib/games/slashem/slashem, I imagine Debian NetHack will do something similar. Ben will no doubt tell me if I've guessed wrong. You can look inside the shell script (see what HACKDIR is set to) to check. I think you'll find that if you look a little more closely, that you've got NetHack running setuid games. If I'm right, and you install version 1.2.9 of GTK+ then attempting to use Gnome interface will cause GTK+ to abort the game for you. Of course, if you're using the Qt interface, then you will have no such worries. -- Ali Harlow Email: [EMAIL PROTECTED] Research programmer Tel: (020) 7477 8000 X 4348 Applied Vision Research Centre Intl: +44 20 7477 8000 X 4348 City University Fax: (020) 7505 5515 London Intl: +44 20 7505 5515 ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: gtk+-1.2.10
On Wed, 14 Mar 2001, [EMAIL PROTECTED] wrote: > I'd like to point out that in the case of nethack, this is already > handled by having nethack owned by games:bin. The save files end up > being owned by games and grouped by the player that invoked nethack. > > In a situation where you have unique groups for each user, this makes it > impossible for any other user to read/write someone elses player files. > > So really, in the case of gnomehack, I fail to see why you need setgid > or setuid. Pardon me if I'm being stupid, but how can the save files end up being owned by games if something, somewhere isn't setuid games (or root, I suppose)? I don't know which distribution you are referring to, but I'm not aware of any versions of NetHack (including GnomeHack) which currently have a setguid helper. -- Ali Harlow Email: [EMAIL PROTECTED] Research programmer Tel: (020) 7477 8000 X 4348 Applied Vision Research Centre Intl: +44 20 7477 8000 X 4348 City University Fax: (020) 7505 5515 London Intl: +44 20 7505 5515 ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: gtk+-1.2.10
On Wed, 14 Mar 2001, Drazen Kacar wrote: > J. Ali Harlow wrote: > > > In the meantime, we will be forced > > to ship stable versions that subvert your check if you refuse to provide a > > workaround. The code is already written and in place. The user will see > > nothing. > > Wow, we could play a game here. Owen scores a point whenever he releases > GTK source (or a patch, just to make the cycle shorter) which makes GTK > unusable with the existing game binaries. You score a point whenever you > release source or a patch which will work setgid with the existing GTK > binaries. To make it more interesting, patches don't have to be portable, > ie. a single OS on a specific architecture counts. > > And mere mortals can take whichever side they want, but they only may > select compiler, linker and assembler flags, without changing the sources. I know you're only having fun, but just in case there's any confusion: We won't do any such thing. As I said several days ago, if the GTK+ team decide to take steps to block our subversion of their check, we'll simply drop GTK+ support until we can fix the problem. My job is to get Slash'EM to compile (and run) on as many systems as practical. I'm not overly worried about 1.2.9 if 1.2.10 is due to be released soon, because I don't think many people will be running it in the real world. I am worried about the current stable version of GTK+ because this is likely to turn up in the next RedHat etc., Linux distributions. I'm also not going to start playing silly buggers over this because it stops being practical and starts getting stupid. I don't won't to clutter up Slash'EM with hacks to support GTK+ and I'm sure the GTK+ team don't want to clutter up GTK+ with hacks to prevent one application running. At the end of the day, we both want what we think is best for our users. If we can come to an agreement on what that is then we can move forward (even if it's an agreement to disagree). If not, then there will have to be an interruption of service. I know I'll get some flack from the Slash'EM user base for that, but there won't be much else I can do. We will have no choice but to wait for the proper fix to be implemented. -- Ali Harlow Email: [EMAIL PROTECTED] Research programmer Tel: (020) 7477 8000 X 4348 Applied Vision Research Centre Intl: +44 20 7477 8000 X 4348 City University Fax: (020) 7505 5515 London Intl: +44 20 7505 5515 ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: gtk+-1.2.10
On Wed, 14 Mar 2001, Ben Gertzfield wrote: > > "Owen" == Owen Taylor <[EMAIL PROTECTED]> writes: > > Owen> Please just fix your application. In the quick look I took > Owen> GTK+ frontend is only 7000 lines or so, with a strong > Owen> separation between that and the core. Splitting that apart > Owen> into a separate process is simply not that hard. > > Well, it's not that hard for a new application, but it's really hard > for something historical like Gnomehack, (based on Nethack) which > needs the ability to open files at any point during the game (if you > die, it may randomly decide to save your file as a "bones" file for > other players to come across) in the save directory. Hi Ben. Just to point out that the solution that I'm discussing with the NetHack dev-team is to develop plug-in windowing interfaces which would have other advantages rather than a setgid helper (although this also would be possible). -- Ali Harlow Email: [EMAIL PROTECTED] Research programmer Tel: (020) 7477 8000 X 4348 Applied Vision Research Centre Intl: +44 20 7477 8000 X 4348 City University Fax: (020) 7505 5515 London Intl: +44 20 7505 5515 ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: gtk+-1.2.10
On Wed, 14 Mar 2001, Owen Taylor wrote: > "J. Ali Harlow" <[EMAIL PROTECTED]> writes: > > > Good to know. Have the GTK+ team come to a view on a mechanism to override the > > setguid check? If not, is there any chance you could so before 1.2.10 is > > released. I'll happily log a bug if that would be appropriate. > > Please repeat after me: > > By making the GTK+ application run setgid, you would make the files, > and all other files and directories owned by that user > world writeable for all practical purposes. By making the GTK+ application run setgid, you would make the files, and all other files and directories owned by that GROUP world writeable for all practical purposes. > Do you still need a mechanism other than simply making the files > world writeable knowing that? Well, yes. > With the setgid operation you had with GTK+-1.2.8, any user can change > any of their saved games, any of the score files, and any of any > any other user's saved games. Sure, it would be possible. It does however create a reasonable hurdle for would-be cheats to climb. > With a change to the permissions, and no setgid operation, you > would at least remove the ability change other user's saved > games. Granted. > Please just fix your application. In the quick look I took GTK+ > frontend is only 7000 lines or so, with a strong separation between > that and the core. Splitting that apart into a separate process > is simply not that hard. We're working on it. It's isn't quite as simple as it looks however. There's a strong abstraction in the windowing interface API (so that calls from the game core to the windowing interface are few, and go through a central mechanism). There is, however, no abstraction on the callbacks (ie., windowing interfaces currently have access to the game core's data structures and utility functions. Many, including the gtk and gnome interfaces, take good advantage of this). We'll get there, but it _will_ take time. I'm currently estimating that the current Slash'EM development cycle will be six months, by the end of which I hope to have plugable interfaces in place. In the meantime, we will be forced to ship stable versions that subvert your check if you refuse to provide a workaround. The code is already written and in place. The user will see nothing. I would be delighted to delete it if 1.2.9 was the only version that needed it. As Ben Gertzfield points out in a seperate message this problem also affects NetHack. I can't speak for their dev-team, but I will note that we have been talking about this; that they have a copy of my code to subvert; and that it's been quite a while since their last release, with a number of bugs listed as fixed on their bug list. If they were to release a 3.3.2 version containing the subverting code that could be around for years to come. > Regards, > Owen > > [ The only workaround that I'd even consider is an Havoc's > suggesting of an environment variable like: > >GTK_ENABLE_SETUGID_HAXORING > > Though it would worry me that people who don't understand > setugid GTK+ is equivalent to a setugid shell would try > to set that from their source code. ] So don't document it. Spit out a warning message telling everybody just that. As a final thought, do you have any concept of what packagers are likely to do? Is it going to be like Qt, with Linux distributions shipping with 1.2.x and 2.x versions of GTK+ for some time to come? If so, you could include a workaround in the 1.2.x series but drop it from 2.x. This way we can continue to link against 1.2.x, fix the real problem before 1.2.x gets dropped and then take advantage of all the extra facilities 2.x provides. -- Ali Harlow Email: [EMAIL PROTECTED] Research programmer Tel: (020) 7477 8000 X 4348 Applied Vision Research Centre Intl: +44 20 7477 8000 X 4348 City University Fax: (020) 7505 5515 London Intl: +44 20 7505 5515 ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: gtk+-1.2.10
On Sun, 11 Mar 2001, Owen Taylor wrote: > There will be a 1.2.10 out soon with this and some other minor fixes, > and I think also a doc / configure change to tell people that > --with-xinput=gxi is use-at-your-own risk stuff. Good to know. Have the GTK+ team come to a view on a mechanism to override the setguid check? If not, is there any chance you could so before 1.2.10 is released. I'll happily log a bug if that would be appropriate. Cheers, -- Ali Harlow Email: [EMAIL PROTECTED] Research programmer Tel: (020) 7477 8000 X 4348 Applied Vision Research Centre Intl: +44 20 7477 8000 X 4348 City University Fax: (020) 7505 5515 London Intl: +44 20 7505 5515 ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: GTK+-1.2.9 Released
On Wed, 07 Mar 2001, Dave Benson wrote: > why not just insist that the users are in a special group (``slashem'' maybe) > and make the directories writable by that group? if they cannot be > bothered to do that, suggest the directory by world-writable, and never > store executables in there, and tell them not to too ;) You mean run Slash'EM non-setgid? Yes, this always an option for our users when installing Slash'EM, but many prefer to prevent abuse by going for the setgid option. You raise an important point about executables however. Obviously, these should never be writable by group games (or placed in a directory writable by group games etc.) or you really would have a security problem. -- Ali Harlow Email: [EMAIL PROTECTED] Research programmer Tel: (020) 7477 8000 X 4348 Applied Vision Research Centre Intl: +44 20 7477 8000 X 4348 City University Fax: (020) 7505 5515 London Intl: +44 20 7505 5515 ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: GTK+-1.2.9 Released
On Wed, 07 Mar 2001, [EMAIL PROTECTED] wrote: > On Mon, 05 Mar 2001 17:47:24 GMT, "J. Ali Harlow" said: > > Slash'EM can't drop privileges before calling GTK+ because it will need to > > update score files, write out saved levels, and other associated files. This > > Sure it can. Open the files, save the file descriptor in a global variable, > and then drop privs before callling GTK+. Pretty standard program > design. Look at what BIND does - if you tell it to run as non-root, it > opens port 53 and THEN tosses the privs... I'm glad you know so much about what Slash'EM can do :-) Actually, you're wrong. The reason being that it needs to create and delete files during the course of the game, the names of which cannot be determined at the start of the game. To change this would require a complete game re-design. You could use a double directory and use privileges to cd into the outer one, and allow others to create and delete files inside the inner one, but it'd be pretty gross. Alternately, you could move all the files Slash'EM currently might create into one large file (effectively re-implementing UNIX directories in Slash'EM). This would also be a lot of work, quite apart from difficulties with locking the relevant parts of the file. I'd sooner go for the helper option that either of these, for all the problems that has. -- Ali Harlow Email: [EMAIL PROTECTED] Research programmer Tel: (020) 7477 8000 X 4348 Applied Vision Research Centre Intl: +44 20 7477 8000 X 4348 City University Fax: (020) 7505 5515 London Intl: +44 20 7505 5515 ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: GTK+-1.2.9 Released
On Mon, 05 Mar 2001, Paul Davis wrote: > [ snip my rant re. setuid/setgid checks ] > > I must admit that I initially felt the same way. But I was already > aware of the deep security implications of a setuid program that > (during GTK startup) is effectively turned into a Turing machine, > capable of executing more or less any code somebody might want it > to. As a result, my programs do not use the architecture that Owen's > link describes (they cannot, because their real-time characteristics > make them even more picky than typical games). Instead, they do all > the resource acquisition they need before initializing GTK+. This > includes locking all current and future memory into physical RAM, > starting a number of threads with POSIX Real Time Scheduling priority, > and so forth. Then I drop setuid, and start GTK+. GTK doesn't (and > won't) complain, and I don't have to worry (too much) about the > security implications of GTK's various RC files and whatnot. > > Also, as I mentioned previously, setuid is not, for Linux 2.4.0 and > above, the right way to do any of this; capabilities are. My programs > require the RESOURCE capability, but nothing else (admittedly, the > RESOURCE capability will allow to do just about anything if you're > clever enough, but its not setuid). Thanks for the suggestions, Paul. Our problem is that the graphical interface to Slash'EM is just one part of a much larger program. Slash'EM can't drop privileges before calling GTK+ because it will need to update score files, write out saved levels, and other associated files. This could all be done in a helper program, but that would require major re-writing of the game core and I wouldn't be prepared to even consider that without the agreement from the NetHack dev-team (of which Slash'EM is just a variant). I think breaking the graphical interface off into a seperate process would be a better solution than this. As far as capabilities goes, you have to understand that NetHack and Slash'EM are some of the most portable programs ever written. Slash'EM has binaries for Atari, Mac, DOS, MS-Windows, RedHat & Debian and source support for a lot more. We're not going to throw that away. Btw, you do realise that if you're application is setuid root, then there already exists a mechanism to defeat the check :-) There's nothing to stop you simply setting real, effective & saved UIDs to root. Since Slash'EM is normally installed setgid games, that is not an option available to us. -- Ali Harlow Email: [EMAIL PROTECTED] Research programmer Tel: (020) 7477 8000 X 4348 Applied Vision Research Centre Intl: +44 20 7477 8000 X 4348 City University Fax: (020) 7505 5515 London Intl: +44 20 7505 5515 ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Problem with GtkCList, dynamically creating with N columns...
On Tue, 06 Mar 2001, Wrinkled Shirt wrote:
> Hey again,
>
> The original problem again was dynamically creating an array of blank
> strings to be used as an argument in creating a gtkclist widget. The point
> was to create some code that could replace:
>
> /**/
> char *blankrow[] = {"", "", ""}; // needed for three columns
> /**/
>
> ...with something else that would build dynamically, assuming I already knew
> the value of the number of columns needed.
>
> Based on Flavio's response (thanks Flavio), I did the following...
I hate to tell you this, but if Flavio recommended this he should be shot.
> /**/
>
> int *blankrow;
That should be char **blankrow.
> int ctr;
>
> blankrow = (int *)malloc(vpsql->cols); // vpsql->cols = # of cols
That should be blankrow = (char **) malloc(vpsql->cols * sizeof(*blankrow));
> for (ctr=0; ctrcols; ctr++)
> {
> (char *)blankrow[ctr] = (char *)malloc(2);
> sprintf((char *)blankrow[ctr]," ");
These two lines could be blankrow[ctr] = strdup(""), although:
blankrow[ctr] = (char *)malloc(2);
sprintf(blankrow[ctr]," ");
is also legal C it doesn't do quite what you asked for (it sets every title to
space rather than to an empty string).
> }
>
> vpsql->grid = gtk_clist_new_with_titles(vpsql->cols, (char **)blankrow);
Having fixed the above, you can drop the cast.
> /**/
>
> There's a lot of extra casting that I threw in there because of compile
> warnings, but the effect is pretty much the same with or without them. The
> thing works (thank god), although there are a couple of things that trouble
> me.
All those warnings was the compiler trying to tell you that something
was wrong.
> 1. If I substitute the declarations, mallocs and for loop with the
> hard-coded alternative above, I get no runtime error messages. However, with
> the new declarations, mallocs and for loop, I get the following error
> message repeated quite a lot. I cannot quite figure out why...
Since you've completely corrupted the heap, I'm surprised anything works.
> 2. My C skills are really rudimentary, so I have no idea how to free up the
> memory I've malloced up there. I've tried a few things, but each time I do
> it I get an error. Considering that I'm asking for a very limited amount of
> memory, it's tempting to just let it go, but I suppose that wouldn't be
> proper.
Free in reverse order:
for (ctr=0; ctrcols; ctr++)
free(blankrow[ctr]);
free(blankrow);
Cheers,
--
Ali Harlow Email: [EMAIL PROTECTED]
Research programmer Tel: (020) 7477 8000 X 4348
Applied Vision Research Centre Intl: +44 20 7477 8000 X 4348
City University Fax: (020) 7505 5515
London Intl: +44 20 7505 5515
___
gtk-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: GTK+-1.2.9 Released
On Mon, 05 Mar 2001, [EMAIL PROTECTED] wrote:
> That's a bit better. I'm still leery of using an env variable to say
> "please do it", simply because a hacker about to use an exploit WILL
> say "please".
>
> Better would be:
>
> a) the app sets a global variable saying "It's OK'.
> b) The GTK lib then does something like:
>
>if (app_set_insecure_ok) {
> /* check / isn't world/group writable */
>/* check /etc isn't world/group writable */
>/* check /etc/gtk_perms is not group/world writable */
>
>/* open /etc/gtk_perms and see if our app name is in there */
>/* if so, do it *.
>}
>
> Yes, the checks on /etc and / are needed, to prevent rename races.
Overkill. If / or /etc is writeable you have much more to worry about than
an exploit via a GTK application.
> Checking in /etc/gtk_perms for argv[0] isn't safe, an attacker could
> play execve() games. Probably better would be to store a triple in
> the file of (argv[0], filesystem, inode) as returned by stat(), and
> compare those to the results of stat'ing the currently running binary
> (which can be tricky to identify). Also, that has an annoying tendency
> to break if you apply updates and/or dump/restore the filesystem when
> the inode number changes.
Get the app to supply the key as part of your step (a). Why would the app
lie? Plus there's a good chance that it would be unique.
> I'm sure there's other attacks I haven't thought of yet, this is the
> quick off-the-top-of-my head version.
>
> And of course, what we end up is an ISO-standard band-aid, with bells,
> wistles, gauges, buttons, and supporting documentation, which still won't
> fix the problem of programmers who don't take the time to write secure
> code.
>
> You're probably better off sticking with the current code. ;)
And end up with application writers who _will_ defeat it. We have too much time
invested, and too much to loose. What does that gain anybody? That you can
stand back and say it's our fault. Well we know that. The question is how can
we provide an incentive to the application writer to fix it properly while
making as sure as we possibly can that the end-user is aware of the problem and
that as far as possible it requires a positive step by the computer owner to
make themselves vulnerable.
If I've got to tell my users that they're going to have to add Slash'EM to a
list of insecure applications and if they get a warning every time they play
telling them that their system is vulnerable, I am going to have one powerful
incentive to fix this as soon as I can. If I defeat the check, I don't even
have to tell anybody (although I would). Once I've done it, I can pretty much
forget it. I may have the best intentions in the world, but I'm going to get
distracted by this feature that would improve the game or fixing that bug
somebody has found.
--
Ali Harlow Email: [EMAIL PROTECTED]
Research programmer Tel: (020) 7477 8000 X 4348
Applied Vision Research Centre Intl: +44 20 7477 8000 X 4348
City University Fax: (020) 7505 5515
London Intl: +44 20 7505 5515
___
gtk-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: GTK+-1.2.9 Released
On Mon, 05 Mar 2001, [EMAIL PROTECTED] wrote: > > On Mon, 05 Mar 2001 14:10:29 EST, Havoc Pennington said: > > Right. Adding something like a GTK_ALLOW_INSECURE environment variable > > doesn't seem like a terrible idea, though it's too late to do so for > > 1.2.9. > > Wrong. > > A hacker can just say 'export GTK_ALLOW_INSECURE' and then run his exploit. > > A better solution would be to have a global variable inside the GTK libs > that the application itself could set if it was willing to take the risks. You're right, of course. What about if GTK_ALLOW_INSECURE pointed at a file which contained the list of insecure apps that were allowed to run and if GTK+ checked that this file was owned by root. That way only the owner of a computer system could give permission. -- Ali Harlow Email: [EMAIL PROTECTED] Research programmer Tel: (020) 7477 8000 X 4348 Applied Vision Research Centre Intl: +44 20 7477 8000 X 4348 City University Fax: (020) 7505 5515 London Intl: +44 20 7505 5515 ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: GTK+-1.2.9 Released
On Mon, 05 Mar 2001, Havoc Pennington wrote: > "J. Ali Harlow" <[EMAIL PROTECTED]> writes: > w > > I do think you are being needlessly heavy handed. Even calling > > gets(), which everybody agrees is not on, doesn't actually break the > > application. And as I say, I will subvert the check if I have to. At > > least if you supply a method of defeating the check you can still > > issue a warning to the user and everything will be out in the open. > > > > Right. Adding something like a GTK_ALLOW_INSECURE environment variable > doesn't seem like a terrible idea, though it's too late to do so for > 1.2.9. Sounds good, although it probably needs to be app specific so that the user keeps control. How about if the environment variable contained a list of apps that the user accepted were insecure. Naturally I realise that 1.2.9 is water under the bridge. Even I don't ask the impossible :-) -- Ali Harlow Email: [EMAIL PROTECTED] Research programmer Tel: (020) 7477 8000 X 4348 Applied Vision Research Centre Intl: +44 20 7477 8000 X 4348 City University Fax: (020) 7505 5515 London Intl: +44 20 7505 5515 ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: GTK+-1.2.9 Released
On Mon, 05 Mar 2001, Havoc Pennington wrote: > "J. Ali Harlow" <[EMAIL PROTECTED]> writes: > > There may be a clear argument, but I have to say that it is > > unacceptable to me for the GTK team to resort to such > > nannyisms. While it would not be impossible for the Slash'EM > > development team to comply with this (and it would also have some > > fringe benefits) it would take a huge amount of work - we would have > > to change the graphical interfaces to the game into seperate > > processes and implement a protocol for communicating with the game > > core via pipes. It is quite ridiculus for the GTK team to impose > > their priorities on us in this way. > > > > If your app fails the check, your app is a security hole. Someone > should post it to Bugtraq. The fact that fixing the hole is a lot of > work doesn't really change the fact that it's a hole. ;-) Granted. In effect, we consider that providing a hole into the games group is not serious enough for us to have fixed the problem yet. Surely, this is a matter between us and our users. By all means spew out a warning telling all and sundry that you consider the application broken and that the writers should be shot... > If the app is for custom or in-house or "not on the net" systems only, > then it should be acceptable to build a custom version of GTK with the > check removed, and that's a fine thing. But GTK as shipped protects > general users who may not be aware of security issues. Doesn't apply to Slash'EM, but I agree it might be a solution for others. > Any user who understands the security issue can trivially remove the > check from their copy of GTK. Or app authors can ship a hacked copy of > GTK and statically link, thus compromising only their app, and not > introducing the issue for other apps on the system. I suspect the vast majority of our users would find hacking GTK a bit of a challenge. I agree we could ship binaries with statically linked libraries, but the size would go up something horrid. It also wouldn't be a solution for those UNIX platforms we only provide source support for. I do think you are being needlessly heavy handed. Even calling gets(), which everybody agrees is not on, doesn't actually break the application. And as I say, I will subvert the check if I have to. At least if you supply a method of defeating the check you can still issue a warning to the user and everything will be out in the open. -- Ali Harlow Email: [EMAIL PROTECTED] Research programmer Tel: (020) 7477 8000 X 4348 Applied Vision Research Centre Intl: +44 20 7477 8000 X 4348 City University Fax: (020) 7505 5515 London Intl: +44 20 7505 5515 ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: GTK+-1.2.9 Released
On Fri, 02 Mar 2001, Owen Taylor wrote: > Drazen Kacar <[EMAIL PROTECTED]> writes: > > > Owen Taylor wrote: > > > > > Overview of Changes in GTK+ 1.2.9: > > > == > > > > > > * Refuse to initialize GTK+ when setuid (http://www.gtk.org/setuid.html) > > > > Is this just setuid or it includes setgid? There are games which are > > setgid to group games for the sole purpose of having the ability to > > manipulate high score lists which are not accessible to users. Those > > programs will break if they can't run setgid any more. > > It includes setgid, however, the check does not kick in if it > the program has already dropped setgid privileges before initializing > GTK+. > > This is the way that GNOME games works, and there is a pretty > clear argument that any setgid game game should work this way. There may be a clear argument, but I have to say that it is unacceptable to me for the GTK team to resort to such nannyisms. While it would not be impossible for the Slash'EM development team to comply with this (and it would also have some fringe benefits) it would take a huge amount of work - we would have to change the graphical interfaces to the game into seperate processes and implement a protocol for communicating with the game core via pipes. It is quite ridiculus for the GTK team to impose their priorities on us in this way. Please provide a mechanism for applications to defeat this check or I will have to resort to subverting the getresuid() & getresgid() functions to lie to GTK. Should you block this we will simply have to drop support for GTK from Slash'EM (and tell our users why) until we can justify the time required to meet with your requirements. Annoyed of London. -- Ali Harlow Email: [EMAIL PROTECTED] Research programmer Tel: (020) 7477 8000 X 4348 Applied Vision Research Centre Intl: +44 20 7477 8000 X 4348 City University Fax: (020) 7505 5515 London Intl: +44 20 7505 5515 ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: GTK v1.3.2: New text widgets
On Tue, 09 Jan 2001, Havoc Pennington wrote: > I opened this bug about it, if you want to put yourself on the cc > list: > http://bugzilla.gnome.org/show_bug.cgi?id=40304 > > Will be looking at fixing that in the near future. Done, thank you. > I've seen this from time to time, but not recently. On Dec. 1 I made a > fix that I thought would fix it. I'm not sure if that was before or > after 1.3.2 (you were using 1.3.2 right?). > > Anyhow, if it was before, it would be helpful if you can come up with > a good reliable way to duplicate the problem. Yup, I'm using 1.3.2. CVS tells me that this was released using delta 1.46 of gtktextview.c, which was commited on 16th November. Next time you checkpoint the code, I'll upgrade and make sure it works. Cheers, -- Ali Harlow Email: [EMAIL PROTECTED] Research programmer Tel: (020) 7477 8000 X 4348 Applied Vision Research Centre Intl: +44 20 7477 8000 X 4348 City University Fax: (020) 7505 5515 London Intl: +44 20 7505 5515 ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: GTK v1.3.2: New text widgets
On Mon, 08 Jan 2001, Havoc Pennington wrote: > Hrm, I'm not sure I understand the problem fully or see exactly what > is going on, but once I do I want to fix it. ;-) Sounds good to me. How can I help? > If you call scroll_to_mark() then the adjustment should immediately > (synchronously) be moved to scroll as requested. It shouldn't go > through the main loop at all. > > There may be one problem here involving the main loop. Let me explain > a bit how the view works; when you modify a line of text, the view > "invalidates" that line, which means it sets the height of the line to > zero and schedules an eventual recomputation of the line's height. It > does this recomputation in an idle handler, which means in gtk_main(). I'm not sure what you class as "modify" here. The problem occurs before the text buffer exceeds Slash'EM's nominal memory limit and so before any deletions are triggered. Thus the only modifications to the buffer are insertions of complete lines at the end of the buffer. Could the problem be that since the new lines are zero height, the mark (which is just below the new lines) is considered on-screen? > During recomputation, if your buffer is big enough you can actually > see the scroll thumb shrinking as the scrollable area expands. > However during this process the visible text should stay constant > (i.e. the top line of the view should remain the same). > > It's possible that scroll_to_mark() while the whole buffer or lots of > the buffer is invalid doesn't work, because if you have a bunch of > invalid lines with 0 height, then you can really only scroll before > all of them or after all of them, and you don't have enough "space" in > the adjustment. e.g. the range of the adjustment might be from 0 to 1, > which doesn't give you any precision. > > It doesn't make sense to me that one scroll_to_mark() would work but > not the following ones; that's kind of weird. I'm having trouble > coming up with a reason why that happens. Well it's quite possible that I've misdiagnosed the problem. As I remember, I initially thought that the problem might be that the mark was considered as being an infinitely thin line of the full height of the text and so while the top of the mark was on-screen, the line it was on was not visible. To solve this imagined problem, I added an extra blank line at the end of the buffer. Given this extra line, what I might have been seeing was scroll_to_mark() scrolling to the position of the mark before the insertions, which just happened to be one line down from where it should have been and so "worked" as long as only one line was inserted. I can have a play this evening and see if I can find out more. > How to fix it... > > One issue with a "view updated" signal is that the view is updated > incrementally in a bunch of chunks, not all at once. So I'm not sure > when to emit this. > > You also want to avoid flashing, i.e. you want the view to come up > scrolled to the mark the first time, you don't want it to start > someplace else and then scroll after it updates fully, or something > like that. Yup, this would certainly be much better. I'm not sure whether my current solution is flashing or not, although logically one would expect it to. > Another option is to make scroll_to_mark() a bit smarter. Instead of > scrolling immediately, it could store the mark to be scrolled to, and > only scroll just before drawing to the screen. This is potentially > unintuitive because you might scroll_to_mark() then delete or move the > mark; so the widget could add its own internal mark at the same > position and save that, instead of relying on the passed-in mark. > > This would also allow you to call scroll_to_mark() before the text > widget is realized/mapped, which might be convenient. > > > I'm not sure yet - thanks for doing beta testing though, please > report any other issues like this. Only other odd thing I noticed was with the coloured tags that I use. If the last-but-one line is coloured and I play around with the selection using the mouse, I can sometimes get the last line to be coloured too (scrolling the line off-screen and then back on-screen solves the problem). I didn't mention it because I feared it would cloud the issue and I haven't really had time to investigate it fully. Many thanks for your help, -- Ali Harlow Email: [EMAIL PROTECTED] Research programmer Tel: (020) 7477 8000 X 4348 Applied Vision Research Centre Intl: +44 20 7477 8000 X 4348 City University Fax: (020) 7505 5515 London Intl: +44 20 7505 5515 ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
GTK v1.3.2: New text widgets
Guys (and especially Havoc),
I got hold of a copy of GTK+ v1.3.2 over the weekend and ported my message
module to Havoc's new text widget API. (Very nice work btw, Havoc, most
impressed.) I found I had to use a bit of a hack to get it to do what I wanted
however, so I wondered if the API might need extending slightly (or if I've
just missed something).
My message module is part of a plug-in windowing interface to a roguelike game
(Slash'EM, homepage http://slashem.sourceforge.net). Because the game itself is
not event driven, gtk_main() is only called when the game requests input (and
gtk_main_quit() is called in the relevant signal handlers).
The message module is used to display textual output from the game. The
putstr() function may be called any number of times between requests for input
(and therefore calls to gtk_main). The output should be displayed in a window
which can be scrolled back by the user to see what occured a little while ago,
but should automatically revert to displaying the most recent line whenever new
text is added. The scrollbar should be displayed as fully scrolled-down at this
point, so that the user has confidence that there are no more messages
off-screen.
Text should be displayed in red if the character is considered "in danger" and
trimmed from the top so that the memory requirements don't keep on growing
indefinitely.
This was all easy to implement except for managing the scrolling. I've got my
own mark for our insertion point and so I thought I should just be able to call
scroll_to_mark() at the end of each putstr() function. This works if putstr()
is only called once between calls to gtk_main(), but fails otherwise (it seems
only the first call is actioned). I ended up having to use the adjustment
changed signal to trap when the actual view is being updated and calling
scroll_to_mark() then, but it seems a little gross.
I imagine I wouldn't be having these problems if I was in gtk_main() all the
time, but that's not an option available to me. I suggest that a signal be
added to GtkTextView which is emitted when the view is being updated, rather
than having to hijack adjustment changed for this purpose.
Many thanks,
--
Ali Harlow Email: [EMAIL PROTECTED]
Research programmer Tel: (020) 7477 8000 X 4348
Applied Vision Research Centre Intl: +44 20 7477 8000 X 4348
City University Fax: (020) 7505 5515
London Intl: +44 20 7505 5515
/*
$Id: gtkmessage.c,v 1.6 2000/12/29 17:12:53 j_ali Exp $
*/
/*
GTK+ NetHack Copyright (c) Issei Numata 1999-2000
Copyright (c) Slash'EM Development Team 2000-2001
GTK+ NetHack may be freely redistributed. See license for details.
*/
#include
#include
#include
#include
#include "winGTK.h"
static boolean in_danger(void)
{
return (u.uhpmax > 0 && (((double)u.uhp) / u.uhpmax < 0.1 || u.uhp < 5));
}
#ifdef GTK_TEXT_VIEW_H
/*
* The new implementation using GtkTextView, which should solve a number
* of problems, particuarly with the win32 port. Note that at the time of
* writing, gimpwin does not yet include GtkTextView.
*/
static GtkWidget *message_view;
static GtkWidget *message_sw;
static GtkTextBuffer *message_buffer;
static GtkTextMark *message_cursor;
static GtkTextTag *message_danger_tag;
static gint message_line_count, message_adj_line_count;
static gint message_char_count;
/*
* By delaying the scroll_to_mark until the view is actually updated
* (of which changing the vertical adjustment is a side effect), we
* optimise the case of two calls to putstr() between calls to gtk_main()
* plus also work around a slight oddity of GTK v1.3.2 which appears
* to ignore the second and subsequent calls to gtk_text_view_scroll_to_mark().
*/
static void nh_message_adjustment_changed(GtkAdjustment *adj, GtkTextView *view)
{
/* gtk_text_view_scroll_to_mark() doesn't work (and isn't needed)
* if the view isn't mapped yet.
*/
if (message_cursor && GTK_WIDGET_MAPPED(GTK_WIDGET(view))) {
gtk_text_view_scroll_to_mark(GTK_TEXT_VIEW(view), message_cursor, 0);
message_adj_line_count = message_line_count;
}
}
static void nh_message_set_scroll_adjustments(GtkTextView *view, GtkAdjustment *hadj, GtkAdjustment *vadj)
{
if (vadj)
gtk_signal_connect(GTK_OBJECT(vadj), "changed",
(GtkSignalFunc)nh_message_adjustment_changed, view);
}
GtkWidget *
nh_message_new()
{
GtkTextIter iter;
message_sw = gtk_scrolled_window_new(NULL, NULL);
GTK_WIDGET_UNSET_FLAGS(message_sw, GTK_CAN_FOCUS);
gtk_scrolled_window_set_policy(GTK_SCROLLED_WINDOW(message_sw),
GTK_POLICY_AUTOMATIC, GTK_POLICY_AUTOMATIC);
message_view = gtk_text_view_new();
GTK_WIDGET_UNSET_FLAGS(message_view, GTK_CAN_FOCUS);
gtk_text_view_set_wrap_mode(GTK_TEXT_VIEW(message_view), GTK_WRAPMODE_WORD);
gtk_text_view_set_editable(GTK_TEXT_VIEW(message_view), FALSE);
gtk_signal_conn
Re: GtkText 1.2.8 bug list
Hi Havoc, Thanks for getting back to me so fast. On Tue, 02 Jan 2001, Havoc Pennington wrote: > "J. Ali Harlow" <[EMAIL PROTECTED]> writes: > > Ok, so for those of us who already have a "product" shipping, and have used > > GtkText, what options do we have available to us? > > If you aren't having GtkText problems, then just leave it as-is; > GtkText works fine for simple stuff. Unfortunately, I am having GtkText problems. These are no doubt partly because I'm trying to support both UNIX and MS-Windows and so I have to find solutions that work both under Gtk stable and gimpwin, which I gather uses GTK+ devel code from around April 1999. > > GtkExText, which I don't think I can use, because it is under the GPL > > (incompatible with the NetHack General Public License, > > http://www.nethack.org/v331/license.html). > > Is it really? Ugh. I didn't know that. :-( Nor did I until I went and looked at it after it was mentioned here a few days ago. It was stated at the time that it was mainly a bug-fixed GtkText. My brief look suggests that this isn't the case. It looks like a major re-write to me. > > Put up with the existing bugs in GtkText. > > > > Code for 2.0? Is it available for anywhere? Is it even written yet? > > Yeah, it's written, but the text widget from there can't very easily > be backported to 1.2, so you'd have to use the whole unstable > GTK. Which will be out early this year, we certainly hope. Well, it might solve my problems. I can stay with GtkText for my UNIX ports, and assume that it's a stable GTK+ out there but use the new code under MS-Windows. If you would be prepared to publish it, I for one would be grateful. > > Roll our own. Since I only need a read-only solution, this might be possible. > > I admit, however, that while I'm an acomplished C programmer, my skills don't > > lie in this area. > > It's not that hard, if you are just displaying text not editing it > it's almost trivial. Though I would guess that GtkText works in that > case too. I've got problems with line wrap symbols being displayed that shouldn't be which look bad and with text being overwritten transiently during insertion. Neither of these are really major problems, however our users tend to be a fussy lot! Not that I'm complaining; that's how quality software is produced. It looks as though I may have to consider writing my own widget. Is there any documentation or code examples available that I can use without licensing problems? Many thanks, -- Ali Harlow Email: [EMAIL PROTECTED] Research programmer Tel: (020) 7477 8000 X 4348 Applied Vision Research Centre Intl: +44 20 7477 8000 X 4348 City University Fax: (020) 7505 5515 London Intl: +44 20 7505 5515 ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Wrap indicators in development branch
Guys, Can anyone tell me, or point me in the right direction of where to ask, if the code to hide wrap indicators in text widgets if the widget is not editable and has word wrap switched on (added by Owen Taylor in delta 1.79.2.3) is likely to make it into the development branch? And if so when. I'm happy to invest some time to achieve this if that would help. The reason I want this is that gimpwin is based off the devel branch and so is missing this feature. Many thanks, -- Ali Harlow Email: [EMAIL PROTECTED] Research programmer Tel: (020) 7477 8000 X 4348 Applied Vision Research Centre Intl: +44 20 7477 8000 X 4348 City University Fax: (020) 7505 5515 London Intl: +44 20 7505 5515 ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: How to put the GtkWidget to max screen size?
On Thu, 21 Dec 2000, Havoc Pennington wrote:
> "alan" <[EMAIL PROTECTED]> writes:
> > I set GtkWidget to max size of screen by use gtk_widget_set_usize() and
> > gtk_widget_set_uposition().
> > If I running in kde environmentis is ok.
> > but if I set widget position to (0,0), and running program in afterstop.
> > The title bar of afterstep will hide over screen.
>
> The problem is that window managers are broken in this respect. The
> new window manager spec clarifies the correct behavior; window
> managers should unbreak themselves eventually.
>
> > Have any other way to set GtkWidget to max size of screen.
> > And, How to know the border size and title bar height of window manager?
> >
>
> You can't really know this. There are some scary hacks to try to
> figure it out, but you'd have to know a lot about X.
I worked out a hack for this same problem, which seems to work.
Feel free to use it and/or comment on it's shotcomings.
Cheers,
--
Ali Harlow Email: [EMAIL PROTECTED]
Research programmer Tel: (020) 7477 8000 X 4348
Applied Vision Research Centre Intl: +44 20 7477 8000 X 4348
City University Fax: (020) 7505 5515
London Intl: +44 20 7505 5515
/* ALI
* We need to know the border width and height so that we can correctly
* clamp dialogs to the screen. Unfortunately, GDK allows us no way to
* dermine the border sizes before we map the window. We get around this
* by remembering what they were for the last dialog displayed and
* checking that they haven't changed after the window is mapped. If
* we find we're offscreen after mapping we have to re-position the
* window. Clumsy, but effective.
*
* Note: there's no way that I know of to determine the width of the
* right border or the height of the bottom border. For now, we just
* assume that these are both equal to the left border. Typically,
* only the top border is different and this is a valid assumption.
*
* This is all further complicated by the fact that, at least under
* the Enlightenment window manager, gtk_widget_set_uposition() sets
* the position of the top left pixel of the border before the window
* is mapped, but the top left pixel of the window after it is mapped.
*
* Note: If the window manager is set up such that gtk_widget_set_upostion()
* always sets the position of the left left pixel of the window, and if
* gtk_window_get_origin() returns this same position, then this code
* will fail (gracefully) and dialogs may be positioned with their borders
* just off-screen.
*/
static gint popup_dialog_bw = 0, popup_dialog_bh = 0;
volatile int popup_dialog_abandon;
static gint popup_dialog_timeout(gpointer data)
{
if (!popup_dialog_abandon)
popup_dialog_abandon++;
return FALSE;
}
static void
popup_dialog_mapped(GtkWidget *w, gpointer data)
{
gint screen_width, screen_height;
GdkWindow *window = GTK_WIDGET(w)->window;
gint x, y, nx, ny;
data = gtk_object_get_user_data(GTK_OBJECT(w));
if (data) {
x = GPOINTER_TO_UINT(data) >> 16;
y = GPOINTER_TO_UINT(data) & 0x;
/* Wait for Window Manager to place window and add borders */
popup_dialog_abandon = 0;
gtk_timeout_add(100L, popup_dialog_timeout, 0);
do
{
gtk_main_iteration();
if (popup_dialog_abandon) { /* Don't wait for ever */
if (popup_dialog_abandon++ > 1) /* One final check? */
return;
}
gdk_window_get_origin(window, &nx, &ny);
} while (nx == 0 && ny == 0 || nx == x && ny == y);
popup_dialog_bw = nx - x;
popup_dialog_bh = ny - y;
/* Do we need to re-position this window to stay on-screen? */
screen_width = gdk_screen_width();
screen_height = gdk_screen_height();
if (nx + popup_dialog_bw + w->allocation.width > screen_width)
x = screen_width - popup_dialog_bw - w->allocation.width;
else x = nx;
if (ny + popup_dialog_bw + w->allocation.height > screen_height)
/* popup_dialog_bw because we assume bottom border same as left */
y = screen_height - popup_dialog_bw - w->allocation.height;
else y = ny;
if (x != nx || y != ny)
gtk_widget_set_uposition(w, x, y);
}
}
static void
popup_dialog_realizing(GtkWidget *w, gpointer data)
{
GdkWindow *window = GTK_WIDGET(main_window)->window;
gint x, y, width, height, ox, oy;
gint screen_width = gdk_screen_width(), screen_height = gdk_screen_height();
if (w->allocation.width > screen_width ||
w->allocation.height > screen_height) {
/* This is going to look bad anyway, we can't centre it because
* a position less than 0 is not valid, so the best we can do
* is place the pop-up at the top left of the screen and accept
* that the right and/or bottom edge will be off-screen.
*/
x = y = 0;
}
else {
gdk_window_get_geometry(window, &x, &y, &width, &height, NULL);
gdk_window_get_origin(window, &ox, &oy);
x += ox + (width - w->allocation.width) / 2;
y += oy + (height - w->al
