fourth type of dnd
Hello, I would like to enable a fourth type of drag+drog in a filemanager program. The first three, GDK_ACTION_COPY , GDK_ACTION_MOVE , GDK_ACTION_LINK do exactly that and are generated by combining the d+d with ctl and ctl-shift. But there is also a GDK_ACTION_PRIVATE which I would like to use. Or maybe the GDK_ACTION_ASK. With what d+d keyboard combination could these be generated? Muchos thanks in advance for your time, Edscott Wilson Garcia ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Copying bitmaps into bitmaps
I've been trying to copy a bitmap into a bitmap with gdk_draw_pixmap(), without success. Is it necesary to use XCopyPlane in lieu of some gdk routine? Basically all I want to do is a binary OR between the data in the 2 bitmaps. TIA, Edscott Wilson Garcia ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Copying bitmaps into bitmaps
On Thu 17 Jan 2002 10:01, Havoc Pennington wrote: Edscott Wilson García [EMAIL PROTECTED] writes: I've been trying to copy a bitmap into a bitmap with gdk_draw_pixmap(), without success. Is it necesary to use XCopyPlane in lieu of some gdk routine? When you say without success, what happens? It should work fine. I get messages like: xftree: Fatal XLib internal error BadMatch (invalid parameter attributes) Request 62, Error 8 when I try to use the resulting bitmap. It croaks with only one copy from existing bitmap to a bitmap created with gdk_pixmap_new(window,pix_w,pix_h,1). After looking at a book by Barkakati, (X Window System Programming, 1991) he says that bitmaps should be copied into pixmaps by XCopyPlane(), not XCopyArea() (the latter being used by gdk_draw_pixmap()). Basically all I want to do is a binary OR between the data in the 2 bitmaps. That isn't what gdk_draw_pixmap() normally does, it just copies the bits and overwrites the ones in dest. Look at gdk_gc_set_function(), I'm not sure it affects drawing a pixmap but I think it might. Basically what I want is a transparency mask resulting from the combination of two (or more) pixmaps with different transparency masks. Which would be a binary AND between the data. I'll look at gdk_gc_set_function(), and see what I can do with it. saludos, Edscott Havoc ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Copying bitmaps into bitmaps
On Thu 17 Jan 2002 13:38, Havoc Pennington wrote: Edscott Wilson García [EMAIL PROTECTED] writes: After looking at a book by Barkakati, (X Window System Programming, 1991) he says that bitmaps should be copied into pixmaps by XCopyPlane(), not XCopyArea() (the latter being used by gdk_draw_pixmap()). That's right, but I thought you were copying between two bitmaps. CopyArea() should work OK for that AFAIK. But isn't a bitmap nothing more than a pixmap of depth 1? If gdk_pixmap_new(window,pix_w,pix_h,1); is not the correct way to create an empty bitmap with gtk, how should it be created? edscott The bad match is caused by copying between two pixmaps with a different bit depth. Havoc ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Copying bitmaps into bitmaps
On Thu 17 Jan 2002 14:21, Havoc Pennington wrote:
Edscott Wilson García [EMAIL PROTECTED] writes:
But isn't a bitmap nothing more than a pixmap of depth 1? If
gdk_pixmap_new(window,pix_w,pix_h,1);
is not the correct way to create an empty bitmap with gtk, how should it
be created?
That is the right way. One of us is missing some detail.
Its as simple as the following code, where gPIM[0] is a valid and working
GdkBitmap with width pix_w and height pix_h, and h is a gtkdialog.
static GdkBitmap *gPM;
static void create_higher_bitmap(){
/* This should work, but it doesn't */
GdkGC *gc;
gPM=gdk_pixmap_new (h-window,pix_w,pix_h,1);
if (!gPIM){fprintf(stderr,xftree: error 3348\n);return;}
gc = gdk_gc_new (h-window);
gdk_draw_pixmap(gPM,gc,gPIM[0],0,0,0,0,pix_w,pix_h);
gdk_gc_destroy (gc);
return;
}
gdk_pixmap_new does not return NULL.
Maybe I'm screwing up with the gc which should have special considerations
for bitmap working.
Maybe there's something particular with src_private-xwindow or
drawable_private-xwindow:
XCopyArea (drawable_private-xdisplay,
src_private-xwindow,
drawable_private-xwindow,
gc_private-xgc,
xsrc, ysrc,
width, height,
xdest, ydest);
edscott
___
gtk-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/gtk-list
got it:bitmaps
From the docs: The created GC must always be used with drawables of the same depth as this one. The gc I am using during bitmap copy does not have depth 1. This must be the problem. I probably have to use create the gc using the original bitmap, not the window. Thank you much for your help, and I'm sorry for the wasted bandwidth Edscott On Thu 17 Jan 2002 14:21, you wrote: Edscott Wilson García [EMAIL PROTECTED] writes: But isn't a bitmap nothing more than a pixmap of depth 1? If gdk_pixmap_new(window,pix_w,pix_h,1); is not the correct way to create an empty bitmap with gtk, how should it be created? That is the right way. One of us is missing some detail. Havoc ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Gtk+ starting drags by error
Yesterday I chased a bug for several hours but could not find a workaround. I dug into the mail list archives but could not find anything related. It occurs with a program called xftree, which is a program with a CTree for dragging and dropping files for moving and copying. Binaries and sources of the program can be found at www.xfce.org or at the CVS at sourceforge.net. The bug is the following: 1-Open xftree 2-Open a second instance of xftree (not from New window, but a separate process). 3-drag a file from xftree-1 to xftree-2 and move it around quickly. Somewhere around action 3, a floating icon will get stuck somewhere on xftree-2, and will make xftree-2 think a drag event was initiated on xftree-2, and thus will sort of screw up xftree-2 until that drag is finished. The bug does not occur if: 1- Both windows belong to the same process. 2- A drag event has already been initiated and terminated on xftree-2 3- The drag is done slowly and carefully. It is apparent that some internal gtk+ variable is not initialized until after the first drag event, and this lack of initialization is causing the problem. To workaround, xftree just needs to initialize this (these) variable (s). Any ideas on what to initialize? Any suggestions would be greatly appreciated. Thanks in advance to any pointers, Edscott Wilson Garcia ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
forking heap problem fully solved FTR.
Please excuse the bandwidth I used for the problem I described previously
where the child process was invading the memory the parent was using for
GTK. It was a very stupid mistake, as you can see below in that the case
where strrchr() returning NULL is not considered, thus causing a memory error
in the child. This memory error in turn causes a X-io error in the parent.
if (stat(target,t_stat)0){ /* follow link stat() */
route=(char *)malloc(strlen(target+1));
if (route) {
strcpy(route,target);
end=strrchr(route,'/');
if (end==route) end[1]=0; /* root directory */
else end[0]=0;
stat(route,t_stat);
free(route);
}
}
Saludos
Edscott Wilson Garcia.
___
gtk-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: implementing bars in the meantime on of long work
On Wed 05 Dec 2001 02:17, Giovanni Masullo wrote: i would like to know the rite theorical way to implement a long job without losing the possibility of get user input. have i to create a secondary task to do the job, with the primary waiting for user input? is there a better way? and what if i want to implement a completion bar? there's anybody can help me? tanx in advance. Exactly what you describe is what I just implemented in the program xftree. If you download the code from the CVS at sourceforge (xfce desktop environment) have a look at the code in file xtree_cpy.c you can see that with the tubo.c code it is very easy to create a child process which will communicate with the parent via stdout and stderr. All you have to do is provide functions for the parent to process stdout, stderr, and for the child to perform during the fork. Since stdout and stderr are used, your child can even exec some command line utility if necesary. saludos Edscott Wilson Garcia ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: forking heap question
Paul Davis wrote: parent heaps totally independent, as should be. Maybe there is a way to tell gtk at the fork point whether child or parent will keep the widgets instead of leaving it up to gtk to decide? there isn't any choice. the child cannot access the widgets. end of story. i didn't even both to check your code to notice that it was doing that. if you want to operate on widgets created in a given process, you need to be inside that process. once you fork, you can't access them anymore (well, not without expecting problems). what makes you think you could do this? Because I do it in a program many people are actually using. (see below) subroutine is performed within a simple loop. I have also noticed that with gtk either the parent or the child can take over the gtk widgets, depending on who accesses them first. So I believe some error (probably what code are you looking at that makes you think it works this way? --p In the program called xfdiff, which you can find source code at CVS from sourceforge under the xfce desktop environment, after the fork I let the child process take over the widgets and the parent will _exit() after doing its thing. Why do I do this in this fashion? Because it is an easy way to get rid of zombies without having to waste cpu time on wait() calls. I probably should not do it, but since xfdiff involves two forks and an triangle pipe configuration, it's so much easier. -- saludos, Edscott ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
forking heap question
Hi, I was getting random io X error after forking and the child was not using any GTK, nor was it using exit() in stead of _exit(). I finally tracked down the problem to the child using malloc() and free(), and overwriting the GTK widget information in the parent process. By using stack memory the problem is gone. Is this possible? Should the use of heap memory be avoided at all costs when using gtk with fork()? Thanks in advance for any clue to this puzzling dilema. Edscott Wilson Garcia ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: forking heap question
Havoc Pennington wrote:
Edscott Wilson García [EMAIL PROTECTED] writes:
I was getting random io X error after forking and the child was
not using any GTK, nor was it using exit() in stead of _exit(). I
finally tracked down the problem to the child using malloc() and
free(), and overwriting the GTK widget information in the parent
process. By using stack memory the problem is gone. Is this
possible? Should the use of heap memory be avoided at all costs when
using gtk with fork()?
I don't think it's possible. There should be no relation between
parent and child address spaces.
Havoc
Neither do I think it's possible. Yet, it is so. Maybe a failed malloc()
or free() makes the child access a gtk widget it's not supposed to, via
some globally defined variable. This is the offending code executed by
the child (the complete file is xtree_cpy.c from program xftree of the
xfce desktop environment with CVS at sourceforge.net):
The recursive call makes the parent fail quickly. The non recursive call
also makes it
fail, as long as the child executes it the subroutined enough number of
times.
static gboolean SubChildTransfer(char *target,char *source){
struct stat s_stat,t_stat;
int i,rc;
if (stat(target,t_stat)0){ /* follow link stat() */
char *route,*end;
route=(char *)malloc(strlen(target+1));
if (route) {
strcpy(route,target);
end=strrchr(route,'/');
if (end==route) end[1]=0; /* root directory */
else end[0]=0;
stat(route,t_stat);
free(route);
}
}
lstat(source,s_stat); /* stat() the link itself */
/* recursivity, if src is directory:
* 1- mkdir tgt/src
* 2- glob src
* 3 foreach glob in globlist recall function.
* */
if (S_ISDIR(s_stat.st_mode)) { /* directories fall in here,
going
recursive */
glob_t dirlist;
char *globstring,*newtarget,*src;
globstring = (char *)malloc(strlen(source)+3);
if (!globstring) return FALSE;
sprintf(globstring,%s/*,source);
/* create target dir */
if (mkdir(target,(s_stat.st_mode|0700))0){
fprintf(stdout,child:%s
%s\n,strerror(errno),target);
return FALSE;
}
/*fprintf(stderr,dbg:dir created: %s\n,target);*/
/* glob source dir */
if (glob (globstring, GLOB_ERR | GLOB_TILDE, NULL,
dirlist)
!= 0) {
/*fprintf (stderr, dbg:%s: no match\n,
globstring);*/
return TRUE;
}
else for (i = 0; i dirlist.gl_pathc; i++) {
if (strstr(dirlist.gl_pathv[i],/))
src=strrchr(dirlist.gl_pathv[i],'/')+1;
else src = dirlist.gl_pathv[i];
newtarget=(char
*)malloc(strlen(target)+strlen(src)+3);
if (!newtarget) {
free(globstring);
return FALSE;
}
sprintf(newtarget,%s/%s,target,src);
/*fprintf(stderr,dbg:dirlist:
%s\n,dirlist.gl_pathv[i]);*/
if (!SubChildTransfer(newtarget,dirlist.gl_pathv[i])){
/*fprintf(stderr,dbg:dirlisterror:
%s\n,dirlist.gl_pathv[i]);*/
free(globstring);
free(newtarget);
return FALSE;
}
free(newtarget);
}
free(globstring);
/* remove old directory */
if ((child_mode TR_MOVE) (rmdir(source)0)){
process_error(RW_ERROR_WRITING_TGT);
return FALSE;
}
return TRUE;
}
... more code here that doesn't affect the appearance of the bug ...
return TRUE;
}
--
saludos,
Edscott
___
gtk-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: forking heap question
Paul Davis wrote: Neither do I think it's possible. Yet, it is so. Maybe a failed malloc() no its not. virtual address spaces make it so. children have no access to their parent's address space. global variables make no difference. or free() makes the child access a gtk widget it's not supposed to, via some globally defined variable. This is the offending code executed by the child (the complete file is xtree_cpy.c from program xftree of the xfce desktop environment with CVS at sourceforge.net): The recursive call makes the parent fail quickly. The non recursive call also makes it fail, as long as the child executes it the subroutined enough number of times. have you checked that the recursion bottoms out? if the child uses all of available RAM (physical and swap), the parent will make a malloc call that returns NULL. Yes. It does not bottom out. And the error occurs also in the non-recursive case, when the subroutine is performed within a simple loop. I have also noticed that with gtk either the parent or the child can take over the gtk widgets, depending on who accesses them first. So I believe some error (probably memory allocation stuff) is fooling gtk into thinking that the child has taken over the widgets, so when the parent tries to access them, it gets the x io error, of course. This explanation would leave child and parent heaps totally independent, as should be. Maybe there is a way to tell gtk at the fork point whether child or parent will keep the widgets instead of leaving it up to gtk to decide? -- saludos, Edscott ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: forking heap question
Ralph Walden wrote: Don't forget, that there is actually a shared memory component. That is, the widgets involve resources on the X server that are common to the parent and child... Manipulating them from two different processes is a bad idea IMHO. Most definitely a bad idea. But how can you avoid manipulating them by accident from the process which is not supposed to, as with a memory allocation error. I've already hunted down two of them in xftree, so there might be a third, and the x-io error makes the hunting much more difficult. Edscott Ralph Walden Edscott Wilson García wrote: Paul Davis wrote: Neither do I think it's possible. Yet, it is so. Maybe a failed malloc() no its not. virtual address spaces make it so. children have no access to their parent's address space. global variables make no difference. or free() makes the child access a gtk widget it's not supposed to, via some globally defined variable. This is the offending code executed by the child (the complete file is xtree_cpy.c from program xftree of the xfce desktop environment with CVS at sourceforge.net): The recursive call makes the parent fail quickly. The non recursive call also makes it fail, as long as the child executes it the subroutined enough number of times. have you checked that the recursion bottoms out? if the child uses all of available RAM (physical and swap), the parent will make a malloc call that returns NULL. Yes. It does not bottom out. And the error occurs also in the non-recursive case, when the subroutine is performed within a simple loop. I have also noticed that with gtk either the parent or the child can take over the gtk widgets, depending on who accesses them first. So I believe some error (probably memory allocation stuff) is fooling gtk into thinking that the child has taken over the widgets, so when the parent tries to access them, it gets the x io error, of course. This explanation would leave child and parent heaps totally independent, as should be. Maybe there is a way to tell gtk at the fork point whether child or parent will keep the widgets instead of leaving it up to gtk to decide? -- saludos, Edscott ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list -- Ralph E. Walden Tripos, Inc. [EMAIL PROTECTED] ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list -- saludos, Edscott ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
client/server synchronization
Hi, I've searched around but cannot find an answer to the following. In a program I am fixing (xftree), I absolutely need to synchronize the client and server before proceeding. I know that this is very easy to do using Xlib, but I can't find an equivalent in GTK+. Is there an equivalent? Is it necesary to put in xlib code? Thanks in advance to any answer or pointer or suggestion. Edscott Wilson Garcia ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Gtk+ bringing X down?
I wrote this program called xfsamba, which basically does a lot of forking around smbclient (from the samba suite). It uses a Ctree widget to create a graphical view and also has a text window where much of the text output from smbclient is displayed. This implies, theoretically of course, that the contents of the text widget will keep growing to infinity. Now I got a bug report (32Mb ram Debian GNU/Linux 2.2), saying that xfsamba crashes/hangs (and takes X11 with it) when I click any button while it retrieves data from an win98 box. Could this be the GtkText widget overflowing system memory? Is there any limit for the amount of text in a GtkText widget (or a GtkTextBuffer in Gtk+1.3)? If so, is there any recomended way for purging the text widget of the oldest data? Any pointers will be greatly appreciated. -- saludos, Edscott ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
