Re: GTK_IS_WIDGET Errors
David Swiston wrote: Ok, one more tidbit of info. I installed GCC 3.2.2 on another computer of mine running slackware 8.1 and the exact same project runs just fine on that computer, no Gtk-CRITICAL errors. I then sent the project over to a lab computer running linux and it also ran without an error. Why would I get Gtk-CRITICAL errors on only one of my computers for entry boxes and on two others the exact same file causes none. It can't be anything wrong with the code can it? Google revealed that other people had had problems like this but I could never find info on how the problem was fixed. David, Are you running on x86? I had a subtle problem with gtkentry after switching to gcc3 from 2.9x, but it was on a Sun box. I used -m32 -mno-app-regs to compile the libraries, and the problem went away. The -m32 causes 32bit code to be generated rather than 64bit. More concerning was the -mno-app-regs, which the gcc documentation said was required for maximum compatibility with binary interfaces, and should be used for system libraries, etc. I have not figured out which of these made the difference, but plan to if the problem seems to have gotten better for good. You might look through the x86 gcc documentation for some similar item of concern. Eric ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Nary trees
etienne buxin wrote:
--- Eric M. Monsler [EMAIL PROTECTED] wrote:
A suggested structure:
struct eb_manymany {
uint node_level;
uint num_parents;
uint num_par_max;
struct eb_manymany **par_ptr_array;
uint num_children;
uint num_child_max;
struct eb_manymany **chd_ptr_array;
gpointer data;
}
(snip)
in fact, i'd like to create a structure to represent events. i investigated trees
because i need
a parent-child relationship between events, with the parent event being a
consequence of his child
events. Because one event may have several consequences, it must be able to have
many parents (of
different depht levels, moreover). i could duplicate the child for each of his
parents, but this
is not too good, because each event has _a lot_ of info carried with ( *data in
glib's Nary tree)
and this will consume a lot of ressources.
has someone an idea?
The structure I proposed above should handle it, just remove the
node-level. Do you really mean that consequences are *parents* of
events, not *children* of events? My family tree reads differently, but
whatever.
Let me call them causes and consequences, rather than parents and children.
If your set of operations is fairly limited, you should be OK. For
example, if the API was only Add(with list of causes and consequences
pointers) and Remove(severing all cause/consequence, and also removing
all unconnected nodes caused), it shouldn't be too complex. Might be OK
for creating a user-traversable set of nodes for a visualization exercise.
But, attempting to traverse the mesh is going to be a really tough problem.
Good luck.
Eric
___
gtk-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Nary trees
etienne buxin wrote:
hi,
i'd like to use a structure similar to glib's Nary tree, but with the difference
that many parent
nodes can share one or several children nodes.
any clue?
This is going to be rather difficult.
Unless you enforce a policy that only sibling-nodes can share child
nodes, you are going to have a lot of trouble. Even then, any trivial
operation on a child node (e.g., remove from tree) will require
searching over the full set of parent-siblings and checking the child
pointers against the full set of siblings for the child-node.
Don't do it.
If a fellow developer at work suggested such a data-storage approach, I
would require a tone of convincing that this was a reasonable thing to do.
If you do, I strongly suggest that you do not base it off of the current
glib n-ary tree implimentation. At a minimum, I would enforce a policy
that a node has a numbered depth N, that all children are depth N+1 and
parents are N-1. This may seem obvious, but in a multi-parent scenario
it would be easy to violate if moving a set of nodes within the tree.
A suggested structure:
struct eb_manymany {
uint node_level;
uint num_parents;
uint num_par_max;
struct eb_manymany **par_ptr_array;
uint num_children;
uint num_child_max;
struct eb_manymany **chd_ptr_array;
gpointer data;
}
That lets you reference count the parents and children, so that, for
example, when removing a node you can go to all the parents and remove
that child from their list of children.
The _max allows dynamix allocation of the pointer arrays, if you
previously allocated space for 12 children and need a 13th, you can
reallocate that array up to size 24 or somthing, with 13 places occupied.
If the above doesn't make sense after a few readings, you're not ready
to tackle this. I have done a two-level parent-child that was
many-to-many, where entities were by definitions either parents or
children, and by the time I had the appropriate API and error checking
all in place it was very cumersome.
For example, what policy do you generically implement if a the last
parent of a node is freed? In my application, that meant that the child
was now a discard and could be freed, but that may or may not be
appropriate for a generic storage library. Specify a calllback for the
child node in that situation, defaulting to freeing? Complexity!
If you do get it working as infinite level many-to-many, please post the
code. :)
Eric
___
gtk-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/gtk-list
Weird GtkEntry behavior in GTK 1.2.10
All, I am seeing a very strange behaviour with a GtkEntry widget. The application had previously been working normally; well enough that I had not done any maintenance on it in months. During that time, the compiler on the Solaris box was upgraded from gcc 2.95.x to gcc 3.2, without my knowledge. I made a minor code change, rebuilt my application, and discovered that the GtkEntry widget was not working properly. It was swallowing certain characters. In some cases, the n was never displayed, but repeated button presses would result in an n being shown. The s character was even stranger, with the keystroke sometimes working, sometimes producing no visible effect, and with sometimes a Beta characer being shown instead. Investigating, I found aout about the gcc change. I then rebuilt glib, gtk, and gtkextra with no apparent errors, and then rebuilt my application. The exact same results occurred. I tried having another user run the application, and he observed the same effect. Any ideas? Eric Monsler ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Crashing g_string_sprintf when printing invalid floats. gtk+-1.2.9 on Linux
Allin Cottrell wrote: On Tue, 13 Aug 2002, Eric M. Monsler wrote: I feel it should not crash on any input. I have a similar test case, which uses: tmp_float = (float)strtod(6.0e-44,NULL); g_string_sprintf(pGStr,%6.2f\n,tmp_float); and produces the same crash. I'd say that crashing is an acceptable response. It's up to the programmer to ensure that such functions are fed with input that is within bounds. In the example above, inspecting errno would have shown that tmp_float did not have an acceptable value. I suppose one could say that it's a quality of implementation issue, and that a nice library will try to work around invalid input so far as possible. But I wouldn't describe the crash as a bug, any more than it's a bug when fprintf() segfaults when fed a null FILE pointer. Inspecting errno when? After the cast from double to float? Because control does not return to the program after the g_string_sprintf() call, as the negative malloc causes a GLib error. Hence my description of the problem as a crash rather than failure or incorrect output. Try generating any other float of magnitude e-40 to e-43, and see the same result. I just tried f_val = 6.2e-21, f_val *= 1.0e-21, and saw the same error and crash. I did not check errno after the multiplication. Therefore, if you define the current 1.2.x behavior to be correct, I the developer must manually check the float range of every value before calling g_string_sprintf(). Did you write the routine in 1.2.x that computes how many bytes the string may need? If so, I very much appreciate your effort and contribution, but respectfully point out that you had a bug. Eric ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Crashing g_string_sprintf when printing invalid floats. gtk+-1.2.9 on Linux
Yes. I understand the limitations of strtod. Much of this thread could have been avoided if I had used: f_val = 6.2e-21; f_val *= 1.0e-21; in my example code. I used the union example because that's how I found the problem, I used the double to float cast because that's how I tested that the compiler thought I had a reasonable floating point value, and it still crashed. Can we pretend my example was: f_val = 6.2e-21; f_val *= 1.0e-21; g_string_sprtinf(pGStr,%6.2f,f_val); instead? Two valid floats, a valid operation, a valid format string of %6.2f, a call to g_string_sprintf() from which control never returns. Eric ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Crashing g_string_sprintf when printing invalid floats. gtk+-1.2.9 on Linux
Allin Cottrell wrote: Isn't that undefined behavior, trying to access the wrong member of a union? Yes. I am using that to force a bad floating point value. Here (gtk 2.0.6) it prints 0.00, but I don't see that it's obliged to. I feel it should not crash on any input. I have a similar test case, which uses: tmp_float = (float)strtod(6.0e-44,NULL); g_string_sprintf(pGStr,%6.2f\n,tmp_float); and produces the same crash. In that case, a %g\n format string returns something within precision distance of 6.0e-44. The compiler (gcc 2.95) accepts that a float can be denormalized, and operates on it in various ways, but the g_string_sprintf() function does not. The above is completely legal way to produce the crash, and an application could well convert a (very small) double to a float and then later try to print the float in a limited precision output format. That argues that the correct behavior is indeed 0.00, and nothing else. I guess the alternative would be to print nan, but I'd vote for 0.00 instead. Eric ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Crashing g_string_sprintf when printing invalid floats. gtk+-1.2.9 on Linux
All,
I'm jumping lists with this; my apologies, but it's definitely a gtk bug
and so want to followup to gtk-list.
If I try to print a denormalized float with a specific format string,
e.g. %6.2f\n, using g_string_sprintf(), the program crashes with an
error about allocating a negative number of bytes.
An example program is below, showing the error when compiled and run
under Linux. I believe that the problem is present in both 1.2.9 and
1.2.10.
If I change the format string to %g\n, I get an answer that is
something e-44, which is why I think that the denormalized is the
problem. On Solaris, I get 0.000, which is I believe the correct
response.
I think that I can work around this with additional testing, but I have
two questions:
1) Is there ongoing bugfix developement on 1.2.x GTK+?
2) Is this bug fixed in Gtk+ 2.0.x?
Eric Monsler
#include gtk/gtk.h
int main (int argc, char *argv[])
{
GString *pGStr;
union {
int i_val;
float f_val;
} the_data;
gtk_set_locale();
gtk_init(argc,argv);
the_data.i_val = 1;
pGStr = g_string_new();
g_string_sprintf(pGStr,%6.2f\n,the_data.f_val);
printf(pGStr-str);
}
Eric M. Monsler wrote:
All,
I am seeing a crash, although with GLib error message, when printing a
floating point number.
The error message is that GLib is unable to allocate -7 bytes. Which
seems reasonable enough.
The problem is that the data I am trying to print does not seem to be a
valid floating point number. My program needs to be crash-proof in this
case, as bad data is going to be encountered. I see that the value that
is bad is typically something like 6.0245e-44, which is not valid.
The fact that I can read the value means that ddd/gdb is handling it
properly, but not g_string_sprintf.
Any clues? Any suggestions as to how to clamp the floating point value?
I have tried to do so with comparisons to MAX_FLT and MIN_FLT, without
success.
As an aside, the problem has never been observed when using the Solaris
version of the program, just the Linux one.
Thanks in advance,
___
gtk-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Crashing g_string_sprintf when printing invalid floats. gtk+-1.2.9 on Linux
Sven Neumann wrote: the correct place to report this would probably have been http://bugzilla.gnome.org/. Noted. Apologies. it seems to work better with GTK+-2.0 (or actually glib-2.0): 0.00 Good news! I don't think you can reliably perform range tests on uninitialized memory since the compiler knows about the fact that the value was never initialized and may optimize the range check away. The memory is not uninitialized, it is messages received from another, potentially unreliable, program across network and potentially other, potentially unreliable, interfaces. I think I have a workaround for now, but I do want to get Glib rock-solid. If it's fixed in 2.0, that is the most important thing. Will there be a Glib 1.2.11 release? Eric ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Anyone know of a Graphical Timeline Widget?
Bradley F. Hartman wrote: Ron, Thanks for responding. You wrote: I think this falls under the implement your own widget heading. True enough. I am working under the assumption that my timeline widget does not already exist. For that reason, I am attempting to implement my own timeline widget. The graphical timeline is only one piece of this new widget, which I think needs to be implemented as a CellRenderer if I want to use it in a GtkTreeViewColumn. I'm not super-clear on what each line of the timeline represents, but somewhere in the mailing list archives is mention of the stripchart widget, suitable for relatively high speed plotting of a value over time. That might be an appropriate widget for each of the exposed rows. Just a thought. Eric ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Memory problems while using a clist
Havoc Pennington wrote: Kerber, Ulrich [EMAIL PROTECTED] writes: I wrote an app with a clist showing the contents of a log file; the clist is updated every 60 seconds. Although i do a gtk_clist_clear, the memory used is increasing with every run, even if no element is added. After a day of work the amount reaches up to 40 MB! Does anybody know a solution to this problem? You just need to debug it. Use a tool such as memprof to see where the memory is leaked. Havoc A tool I found very useful was GSK, (GNU Server Kit), which can replace the g_malloc type GLib calls with debug versions, and keeps a record of all outstanding allocations. I used essentially just the gskdebug facility, and it worked great. gsk.sourceforge.net, IIRC Eric ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: undefined reference when building gtk 1.2.9
.libs/libgtk.so: undefined reference to `gtk_menu_stop_nqvigating_submenu' Possible typo, nqvigating for navigating, in the code you're trying to compile? Assuming you pasted the errors from the window, rather than retyping them into the email. Eric ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Plot widgets
Ralph Walden wrote: Folks, Does anyone have any experience with using the GtkPlot widget (from GtkExtra) on an SGI? My first impression of GtkExtra is that it is buggy and slow. The development does not seem very active. Doesn't anyone else use GTK need plotting widgets? Is this the official package of such widgets? I use GtkExtra for an in-house data display program. It works fine for my plots, tested up to ~10k points. It will do 200 points updated twice a second with no problem, running on a Sun (forget what, 450 MHz and boatloads of RAM) and displaying on NT PC's (800 MHz typically) running Hummingbird's X server. At 5 times a second it drops occasional updates (I poll for data from a timer, so if I fall behing I just miss a poll.) I use only the GtkPlot stuff, none of the other things in the library. No bugs or memory leaks that I am aware of. There used to be, but around 99.15 to 99.16 a lot got fixed. We were using an X server from Exceed, which grew in memory usage when updating plots; no idea whether Gtk, GtkPlot, or the X-server itself was at fault, but no such memory blleding was seen with the Sun X, Linux XFree86, or the Hummingbird product. It's a little quirky, I have problems positioning axis labels, etc., such that they look nice; my app is far from commercial-level beautiful. But I did clone the gtkrealtime demo and get my application plotting in short order. My biggest beef is that the documentation is near-zero, and the code is largely uncommented. When I did have to go in and figure out something about how tick/grid spacing was handled, it was a chore to read, although once I did understand it the code seemed to make sense and be very reasonable. The primary developer, Adrian Fenguin (spelling?) has been very responsive to questions on the list (I think he's in the process of moving, though, right now). Based on the changelog, I think that there is more development than the mailing list would indicate. Maybe discussion happens on the Scigraphica list. HTH, Eric ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Plot widgets
Wanted to get his name right: Adrian E. Feiguin Also, one other consideration occurred to me, which is that GtkExtra is LGPL, rather than GPL. So, if we ever clean up my application for release and sale to customers, we could still use the GtkExtra library. Sorry for the two-post clutter. Eric ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: MacOS Classic Windows CE/PocketPC support?
Barry, 2) Since I know GIMP and GTK+ have been ported to Win32 (http://www.gimp.org/~tml/gimp/win32) and that automake and autoconf work under CygWin, (I've never tried using them from an MS-DOS prompt) I'm assuming (see #1) that I can build GLADE-produced UIs on Windows. Has anyone tried building an application for Windows CE/PocketPC using GLADE? I think WinCE is less like the other Win32 platforms than you seem to be assuming. From the cygwin.com website: The Cygwin DLL works with all versions of Windows since Windows 95, with the exception of Windows CE. Which does not mean that it is impossible, but that the GIMP and GTK+ ports to other Win32's still have a big gap before working on WinCE. Eric ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: [Fwd: Data in linked lists]
Eric, I am not sure whether you are suggesting that the pointers be constant pointers, or that they be made pointers to constant data. In either case, the only benefit that I see would be to catch at compile-time bugs in the GList and GSList implementations; the inadvertant altering of either the data pointer or its referenced data. The downside would be enforcing a default policy on every application's usage of GList or GSList. Yes, a simple cast allows the const policy to be overridden, but that forces the cast to appear in every usage. In addition, I that that this would cause perplexing and ugly code constructs in the applications. For example, a function used with a g_list_foreach() call would take as its argument a pointer to constant data, and might then immediately cast that pointer to pointing at non-constant data and begin manipulating it. While those pointers could indeed use const without disturbing the GList and GSList functionality, I feel that it would be a worse design; causing more confusion and obtuse code for minimal benefit. I would argue for the current scheme if this was a fresh implementation; the mass breakage of existing GList and GSlist code that would result from such a change seems to me to be an overwhelming argument against it. Eric M. Monsler ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: stacking pixmaps
Havoc Pennington wrote: Eric M. Monsler [EMAIL PROTECTED] writes: IIRC, GNOME is GPL, vs. the LGPL of GTK. No, this is completely untrue - GNOME libraries have always been LGPL. Well, always happy to lose a fundamental misunderstanding! ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: probelm about install
Paul Davis wrote: (snip) Hopefully, its obvious that you could also use ./configure --prefix=/some/other/place/you/can/write as well. Just wanted to add to the above: it works quite well, and is fairly easy, even if you're a relative newbie at the GNU build procedure. The key is to use "--prefix=wherever" to all of the software you are installing. I ended up with autoconf, automake, autoproject, gnome-libs, stdtypes, and of course fortune, all installed under /home/emonsler/usr/local. This is in addition to glib, gtk, glade, libglabe, gtk+extra, etc. The path modifications (in my .bashrc) required are shown below, with formatting I'm sure completely hosed: export LD_LIBRARY_PATH=/usr/lib:/usr/openwin/lib:/usr/local/lib:/home/emonsler/usr/local/lib export PATH=/home/emonsler/usr/bin:/home/emonsler/usr/local/bin:/usr/local/bin:/bin:/usr/bin:/usr/ucb:/usr/sbin:$HOME/MyTools:/usr/openwin/bin:. export MANPATH=/usr/local/man:/usr/man:/usr/openwin/man:/home/emonsler/usr/local/man Have fun with it. Eric ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Concurrent processes
One key question is, does the parameter change need to cause a
calculation restart? I would presume so, unless the computation was
convergence-based. In that case, you'll presumably need to modify
isingflip() whatever approach you take.
if you previously had:
isingflip()
{
/* setup loop code */
while(not_done)
{
/* Do calc iteration */
}
/* cleanup loop code */
/* output results code */
}
You could change it to be:
isingflip()
{
/* setup loop code */
while( not_done variables_unchanged)
{
iter = 0;
while( not_done (iter N) )
{
iter++;
/* Do calc iteration */
}
/* Allow operator interaction */
while(gtk_events_pending())
{
/* This loop is wrong, search archives for example */
gtk_main_loop_iteration();
}
}
if(not_done)
{
/* cleanup and terminate, wait for operator to hit "Simulation"
again? */
}
else
{
/* cleanup and output results */
}
}
And, finally, the callback for changing the variables need to also clear
the variables_unchanged flag, and the Simulate button needs to set it.
Tune N to trade off responsiveness vs. increased calculation time.
Eric
___
gtk-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Need help debugging Gdk-ERROR
"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. To date, while I've described my problem on that mailing list, I've never had enough data to make a useful bug report, or even to definitively say that the error is in that code. The crash only happens when I'm plotting, but there are other widgets and manipulations that I do when plotting. I've tried to look into the gtkplot code, but it is, shall we say, "sparsely" commented. 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. [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? 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. Eric ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Need help debugging Gdk-ERROR
All, My application, using gtk+ and gtkextra, eventually crashes with the message: Gdk-ERROR **: BadDrawable (invalid Pixmap or Window parameter) serial 2893853 error_code 9 request_code 64 minor_code 0 I think that the serial value changes, but I believe that the error_code and request code are always the same (they are at least usually the same). I tried running my app under xxgdb, with --sync on and a breakpoint in the gdk function that I belive reports that error. But, with '--sync' specified, my program doesn't seem to crash! 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? 2) Any other suggestions on how to track down this problem? TIA, Eric M. Monsler ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Need help debugging Gdk-ERROR
Ali, Thank you for the X.h and Xproto.h pointers. "J. Ali Harlow" wrote: (snip) 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. 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'. 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. 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? Eric M. Monsler ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Need help debugging Gdk-ERROR
"J. Ali Harlow" wrote: (snip) 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. So, given that I have never been able to produce the error when running with --sync specified, my choices are: 1) Run with --sync and never hit the breakpoint, or 2) Run without the --sync and have no idea how many X requests back the source of the error was when I do hit the breakpoint. I had kind of suspected, and based on your informative posts am now sure, that I'm doomed. I'll have to change the documentation and make it a feature. I was really hoping that there was something I misunderstood or was overlooking. 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? I realize I'm grasping at straws... Eric M. Monsler ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: vertical text w/notebooks?
Jeff Shipman wrote: (snip) I'm also open to further suggestions on saving space if anybody has any :) Keep some smaller number of tabs displayed. The leftmost is either the global "first" tab, or a movement tab. The rightmost is either the global "last" or a movement tab. Using CAPS to indicate active, i.e. tab contents displayed, my ASCII UI design starts as: _ FIRST | second | third | fourth | == | _ Then, if the operator clicks on, e.g., "third", it becomes: _ first | second | THIRD | fourth | == | _ If the operator then clicks "==", it becomes: _ == | THIRD | fourth | fifth | == | _ Another click on "==" changes it to: _ == | FOURTH | fifth | sixth | == | _ Etc. Of course, this is my UI preference, and the actual way to do this is left as an exercise... (There were some postings on hidden notebook pages not too long ago, but I didn't pay much attention) Eric M. Monsler ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Gdk-ERROR?
Help! I'm running a display from a Solaris box, on which I've built Gtk, Gdk, GLib, etc., and am developing a GUI app, onto my desktop NT box running the eXodus X-server. When I plot too many points in my gtk_plot, I receive the following error: Gdk-ERROR **: Fatal IO error 131 (Connection reset by peer) on X server 172.16.2.0:0.0. It seems to always happen at about the same number of points (8000), but I have seen postings on the gtkextra list to the effect that folks have used gtk_plots with many more points than that. Any suggestions for how to debug this? Has anyone seen this type of error before from their Gtk+ app? Eric Monsler ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Keeping program flow moving nicely
"Timothy M. Shead" wrote:
(snip)
Use gtk_timeout_add() to create a 'timeout' signal that gets called,
say, every 100 milliseconds or so. In your handler for the timeout
event you decide whose turn it is and call process_move().
What is the gtk behavior in this situation, if it takes more than 100 ms
to do process_move()? I have no idea if this game does so, but I'm
curious what would happen.
Some frameworks promise that a periodic callback function will get
called the correct number of times, even if the callback (or other code)
causes them to occur far later than they ought. In those situations, if
the periodic callback does not have sufficient state awareness to either
deinstall future calls, or do a quick-return, the result could be
disastrous (or, in this case, a UI lockup identical to the initial
problem).
Another option would be to manually allow gtk to process its events
between loops. I think it's on the order of:
while (gtk_events_pending ())
{
gtk_main_iteration ();
}
The above was from a previous post on a similar topic; I'm not sure
that's correct, but there is definitely a was to do this, basically
substituting your own loop for the main loop.
So, in the computer's-turn loop, after processing a computer move, deal
with all gtk events (which would presumably give the operator a chance
to pause or suspend the game), and then check if the next move was a
computer's. If so, loop, if not, terminate until whatever GUI callback
signals that the player has moved (or released the "Pause" feature).
Something like:
on_player_move_confirm(whatever args)
{
process_move(get_player_move(state,player_num));
while(is_computer(currentPlayer))
{
while(gtk_events_pending ())
{
gtk_main_iteration ();
}
process_move(get_computer_move(state));
while(gtk_events_pending ())
{
gtk_main_iteration ();
}
switch_players();
}
return;
}
___
gtk-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/gtk-list
