Re: Real Time Drawing
Thanks for your email and the helpful information John. After some directions from Liam (see yesterdays mailing archive) i passed my app through valgrind and found out that there are too many errors happening in the GTK / X level. I suppose that it has something to do with the way i am using the thread library in combination with GTK. I refrained from using the callback mechanism ( as you suggest) because whatever code is executed within there should execute in a time shorter than the packet length. I am dealing with a system which can not afford droping packets. So, one thread of execution reads and decodes from the serial port no matter what the rest of the app is doing, and a second thread is doing the processing. Probably a third thread will be handling display at a later stage. The threads communicate through a double linked list with mutex protection so that it is guaranteed that writting and reading is occuring at different memory addresses. You are talking about a GAsyncQueue, now thats something i havent looked at. Another thing i havent looked at is threads in glibI suspect that a lot of bad things occur when my processing thread tries to draw the signal on the widget because at some point i discovered that the thread lags and blocks (mind you there is nothing else in the processing thread except the plot code) I see the point in the structure you suggest. I also tried that yesterday (Not exactly as you describe it but the idea is the same). The ReadAndDecode thread does its stuff and the processing thread invalidates the widget where the samples are to be drawn, the expose event handler handles the rest.. (And the question now arrises, what happens if an expose event from the app collides with an expose event that had to be sent because the user minimized and maximized the application???) I also used pipes before i start coding for the main application to check that i had the decoding of the data frame correct. The decoded data was plotted through a pipe to gnuplot!!! Still there are the same problems and i am suspecting that its in the developers responsibility to take care of thread safety in GTK, is that true? (i will also be reading on that, but any suggestions / ideas are wellcome) Thanks for the suggestion of the books also, they look good. All the best. thanOS ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Getting native X Window from GtkWidget
Owen Taylor schrieb: On Mon, 2005-03-14 at 15:22 +0100, Jrg Henne wrote: } As you can see, I tried both suggested routes. However, both of them lead to the same problem: Entering Handle: 0x34000c1 (process:11392): GLib-GObject-CRITICAL **: gtype.c:1871: initialization assertion failed, use g_type_init() prior to this function Are you sure you are using WxGTK as the widget system for your python script? .. this warning would imply to me that nothing has ever initialized GTK+ or the underlying object system. (If you were using pyGTK, there are a wrapper for eggtrayicon floatng around though it's not in the standard bindings.) well, I had a good look at the wxPythonGTK code (use the source, Luke) and it turned out that the documentation is wrong, indeed: the returned handle is already an X-Windows window ID. This leaves me with the problem how to retrieve the corresponding Display, of course. And this time I see little opportunity to retrieve it, since the window handle is just an ID. It may finally be necessary to switch over to pyGTK, indeed. Thanks for your help! Joerg Henne ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
gdk_input_add() with class member as callback problem
Hi,
I'm stuck with the gdk_input_add() function and could use a hint to solve the
problem. So here goes;
The callback function I want to call is a member of a class, but g++ won't
compile this. Placing the function outside the class works, but this is not
the solution I'm looking for.
The code:
InputLirc :: InputLirc()
{
...
tag = gdk_input_add( sock,
GDK_INPUT_READ,
InputLirc::ProcessLircInput,
NULL );
...
}
void InputLirc :: ProcessLircInput( gpointer data, gint source,
GdkInputCondition condition )
{
...
}
The compile error:
input_lirc.cpp: In constructor `InputLirc::InputLirc()':
input_lirc.cpp:73: error: cannot convert `void (InputLirc::*)(void*, int,
GdkInputCondition)' to `void (*)(void*, int, GdkInputCondition)' for
argument `3' to `gint gdk_input_add(int, GdkInputCondition, void (*)(void*,
int, GdkInputCondition), void*)'
Or this one (when removing the ):
input_lirc.cpp: In constructor `InputLirc::InputLirc()':
input_lirc.cpp:73: error: no matches converting function `ProcessLircInput' to
type `void (*)(void*, int, enum GdkInputCondition)'
input_lirc.h:63: error: candidates are: void
InputLirc::ProcessLircInput(void*,
int, GdkInputCondition)
The solution is probably simple, but I just can't seem to figure it out
Any help would be appreciated!
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: gdk_input_add() with class member as callback problem
Eelco Schijf a écrit :
Hi,
I'm stuck with the gdk_input_add() function and could use a hint to solve the
problem. So here goes;
The callback function I want to call is a member of a class, but g++ won't
compile this. Placing the function outside the class works, but this is not
the solution I'm looking for.
The code:
InputLirc :: InputLirc()
{
...
tag = gdk_input_add( sock,
GDK_INPUT_READ,
InputLirc::ProcessLircInput,
NULL );
...
}
void InputLirc :: ProcessLircInput( gpointer data, gint source,
GdkInputCondition condition )
{
...
}
In C++, pointer to (class) methods are not equal to pointer to functions.
Class methods has an invisible additional argument which is the pointer
to the instance. Thus, the signature of a method is not the same as
the signature of a function (i.e: void (InputLirc::*)(...) is not
equal to void(*)(...)). So, when calling a method of an object, the
compiler needs two informations: the object and the method.
gdk_input_add expects a pointer to a function and a user data.
So you must create a dispatch function that calls the object method. It
looks from your code that you don't need the user data, so you can use
it to pass the instance of your object. The dispatch function can also
be a static method of your class, as static methods are handled as
normal functions (they do not apply to instances of the class, so they
do not use the invisible argument described previously). So one solution
would be:
class InputLirc
{
public:
static void DispatchProcessLircInput (gpointer aInputLirc, gint source,
GdkInputCondition condition)
{
InputLirc *obj = static_castInputLirc*(aInputLirc);
return obj-ProcessLircInput (NULL, source, condition);
}
InputLirc :: InputLirc()
{
...
tag = gdk_input_add( sock,
GDK_INPUT_READ,
DispatchProcessLircInput,
this );
...
}
See http://www.newty.de/fpt/functor.html for more information.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Real Time Drawing
On Wed, 16 Mar 2005 09:14:38 +, Athanasios Anastasiou [EMAIL PROTECTED] wrote: After some directions from Liam (see yesterdays mailing archive) i passed my app through valgrind and found out that there are too many errors happening in the GTK / X level. I suppose that it has something to do with the way i am using the thread library in combination with GTK. There are two ways to do threads in GTK: 1) do threads_init, then put threads_enter/threads_leave around *every* gtk/gdk call which could be called from more than one thread. There's a FAQ about this approach: http://gtk.org/faq/#AEN482 2) have a single GUI thread (ie. all gtk/gdk calls are from one thread), then background worker threads can trigger callbacks in the main thread to ask it to do work on their behalf via g_source_*() On pros and cons, (1) is painful and error prone, IMO, and very hard to use for large apps. Whereas (2) keeps threads separate with well defined synchronisation points. As I said, (2) works for me on a large (100,000 lines of C) GTK program. I refrained from using the callback mechanism ( as you suggest) because whatever code is executed within there should execute in a time shorter than the packet length. Hmm, I guess it depends how much work the consumer needs to do. If it's several ms of CPU per packet, I guess you will need a separate thread for this. I'd still recommend keeping the GUI single-threaded and having workers wake it with GAsyncQueue. You could have your producer/consumer threads communicating with your list, then the consumer sending please queue a redraw messages to the GUI down the GAsyncQueue. You are talking about a GAsyncQueue, now thats something i havent looked at. Another thing i havent looked at is threads in glibI suspect that a lot of bad things occur when my processing thread tries to draw the signal on the widget because at some point i discovered that the thread lags and blocks (mind you there is nothing else in the processing thread except the plot code) That sounds bad. You must only plot in the expose handler, things will break otherwise (maybe I misunderstand). glib threads are a very simple portability wrapper over the win32 and posix thread libraries, there's no magic there. event handler handles the rest.. (And the question now arrises, what happens if an expose event from the app collides with an expose event that had to be sent because the user minimized and maximized the application???) GTK has a complicated thing that handles this for you. All exposes, whatever their cause, go through the single expose handler in a sensible way. J ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
g_spawn_async_with_pipes and g_io_add_watch problem
Hello, I am writing a GTK/GLIB application that will basically act as an interface for existing programs, and I have run into some problems while utilizing the function calls mentioned in the subject field. My issues are described below, sorry if it is a bit long winded. I don't have experience with using these particular functions so I am not certain what to emphasize. One of the simpler operations the GUI should perform is the following: run a perl script on a file the output should be handled the following way: *stderr should go to a GtkTextView box *stdout should be input to another external program * stdout from the other external program should be redirected to a file The command line version of said setup would look like this: perlscript.pl ffilename | extprogram newfile The file (filename) in question is a huge text file (could easily be 300MB+), the perlscript makes some changes in it and extprogram is basically a formatting program that sets record lengths and remove linefeeds. Here is what I do: * create a channel for newfile using g_io_channel_new_file(filename, w+, NULL) * spawn extprogram using g_spawn_async_with_pipes * create channels for stdin and stdout on extprogram using g_io_channel_unix_new * spawn perlscript.pl using g_spawn_async_with_pipes * create channels for stdout and stderr on perlscript.pl using g_io_channel_unix_new *create watches on stderr and stdout from perlprogram.pl using g_io_add_watch -the stderr watch triggers on G_IO_IN and G_IO_HUP and calls a function that updates the GtkTextViewBox -the stdout watch triggers on G_IO_IN and G_IO_HUP and calls a function that writes to the stdin channel on extprogram *create watch on stdout from the external program using g_io_add_watch -this watch triggers on G_IO_IN and G_IO_HUP and calls a function that writes to the newfile channel Here is the problem: The above scenario almost works. The problem is that the last part of the modified file is never written to newfile. If I look at the buffers in the function that writes to stdin on the external program everything is there, right up until the end of the file. If I look at the buffers in the function that writes to newfile they will stop a bit before the end of the file. If I look at the actual newfile the content there stops even a bit before the last buffer in the function that writes to newfile. Here is some more information: If I choose to write stdout on extprogram to the same as parents (set stdout to NULL in g_spawn) everything comes out ok (apart from that I don't want it on that stdout of course) In the function that writes to newfile I read the buffers from the channel for stdout on extfile using g_io_channel_read_chars. I have a check on the return value from this and it never gets to return anything other than G_IO_STATUS_NORMAL. It appears that it suddenly is not called anymore. I have tried putting in all possible flags in the watch function but no luck. I shut down the stdin channel to extprogram when there is no more input. Checking the last buffer written to extprogram reveals that this is the correct one, but this then seem to never reach stdout on extprogram, or if it does it appears that it does not trigger the watch function that calls the write to newfile function. rgds, Ole C. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
node that change its has-child state in treemodel
Hi ! I have the following problem with my treemodel : answer to the question does this node have childs ? is time consuming. As this question is asked to every sun of a node when it is expanded, I want to have the following behaviour : When a node is expanded, tree_model_has_child allways returns TRUE. When the node is selected, or its expander is clicked, then take the time to compute and tell the view : for this node, I returned TRUE in the method tree_model_has_child but this has changed, now it is false. I tried to emit the signal row-has-child-toggled when the signal row-expanded is emitted by the view and the answer changes but this does not work : treemodel_has_child is called again and answers FALSE but tree_model_iter_children is also called which is not correct. I have put handlers on each signal I spoke of and they are emitted correctly. Can anyone tell me where I am wrong ? Thanks by advance, Denis ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: g_spawn_async_with_pipes and g_io_add_watch problem
On Wednesday 16 March 2005 21:55, Ole C. wrote: (snip a lot) I have to admit I have only quickly looked over your text and not read it in much detail, but it sounds like you might not be checking the condition in the g_io_add_watch() callback on a per-flag basis. Your callback could be called with condition = G_IO_IN | G_IO_HUP at the end, so if you just check with if (condition == G_IO_IN) etc. instead of if ((condition G_IO_IN)) you won't catch that case properly. Just a thought. If that's not it, I'd recommend you post some code somewhere for people to look at (the shorter, the better). Cheers -Tim ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
How long does it take to load a file
Hi all, I'm loading a series of jpeg images (also tried with png) and notice it takes about 1.2 seconds to load each. Is this normal? I'm using the function gdk_pixbuf_new_from_file. Is there a better (i.e faster) alternative? Thanks, ER ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
children exceeding table rows/cols
hi.
tables that are allocated smaller space than their requisition
tend to over-allocate children. that is, allocate children at
sizes that exceed the columns/rows the children are attached
to or even the table boundaries.
i'd like to suggest to make a few but very effective changes
to gtk_table_size_allocate_pass2() to properly constrain the
child allocations in such cases:
1) constrain children to col/row boundaries (and set a lower limit
for allocation dimensions of 0, the purpose of which will be
explained below):
if (child-xfill)
{
- allocation.width = MAX (1, max_width - (gint)child-xpadding * 2);
+ allocation.width = MAX (0, max_width - (gint)child-xpadding * 2);
allocation.x = x + (max_width - allocation.width) / 2;
}
else
{
- allocation.width = child_requisition.width;
+ allocation.width = MIN (child_requisition.width, max_width);
allocation.x = x + (max_width - allocation.width) / 2;
}
if (child-yfill)
{
- allocation.height = MAX (1, max_height - (gint)child-ypadding *
2);
+ allocation.height = MAX (0, max_height - (gint)child-ypadding *
2);
allocation.y = y + (max_height - allocation.height) / 2;
}
else
{
- allocation.height = child_requisition.height;
+ allocation.height = MIN (child_requisition.height, max_height);
allocation.y = y + (max_height - allocation.height) / 2;
}
here, max_width/max_height allready contain the amount of space allocated
to the child in rows and cols.
2) the allocation of rows/cols of a table may still exceed the table allocation
due to premature abortion of its shrinking process (FYI, this is due to the
condition while (total_nshrink 0 extra 0) in size_allocate_pass1()).
the simple solution to deal with mis-allocations due to this is to constrain
children to the table allocation (short of hacking a different shrinking
logic into the table):
+ /* constrain child allocation to table */
+ if (allocation.x + allocation.width widget-allocation.x + widget-allocation.width)
+ allocation.width -= allocation.x + allocation.width - widget-allocation.x - widget-allocation.width;
+ if (allocation.y + allocation.height widget-allocation.y + widget-allocation.height)
+ allocation.height -= allocation.y + allocation.height - widget-allocation.y - widget-allocation.height;
gtk_widget_size_allocate (child-widget, allocation);
3) the above changes can lead to allocation width/height = 0, which is an
invalid allocation size as far as gtk_widget_size_allocate() is concerned.
what we really want in these cases is to not show the child, since there
is no space available. setting child visibility could be a solution to this
e.g. by doing:
- gtk_widget_size_allocate (child-widget, allocation);
+ if (allocation.width 0 allocation.height 0)
+ {
+ gtk_widget_set_child_visible (child-widget, TRUE);
+ gtk_widget_size_allocate (child-widget, allocation);
+ }
+ else
+ gtk_widget_set_child_visible (child-widget, FALSE);
this does rely on the fact that child visibility may be changed during size
allocation (in particular, it shouldn't queue a resize).
META: i'm not going to make these changes myself, the ideas come from
another
code base and i justed wanted the fixes to get a chance to be folded
back into gtk+, which is also why the above is only a pseudo patch.
---
ciaoTJ
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [Inkscape-devel] Re: [cairo] Pango + cairo
[ Adding gtk-i18n-list to the CC, as more on-topic ] [ ... Various comments about SVG text requirements snipped ... ] On Thu, 2005-03-17 at 13:32 +1100, Peter Moulder wrote: I believe that there is a place for a library supporting advanced text applications, but that Pango Layout is not it. The overhead is really quite large and seems unnecessary for an API whose primary goal is laying out text in widgets. Owen, can you comment on what you see as pango's scope? Are you interested in non-rectangular text regions? Are you interested in non-greedy line breaking? (I'd guess that non-greedy line breaking would be desirable even for dialog boxes, at least from a functional point of view; the only question is whether it justifies the cost in terms of maintainability of pango code and perhaps code size.) Pango's goal is to support anything anybody wants to do with text. The scope is implicit in the fact that text is hard, and internationalized text is harder. If you start from scratch and don't use Pango, you either have to say full international coverage is never going to be interesting to me, or you have a year or two of work to do to catch up to Pango. So, the question isn't to me what is Pango's scope but rather what parts of Pango should be universal, and what parts do you replace. In particular, what about PangoLayout? It's really only a small part of Pango's code - maybe 10-15% of the total 65,000 lines of code, so maybe it's just ignorable? If you want non-rectangular line breaking, just use the low level parts of Pango My opinion is that while there may be some cases where ignoring PangoLayout and starting from scratch is right ... we really want PangoLayout to be extensible to handle almost any case where we are taking a block of text and laying it out into lines. Because of the 8000 lines of code inside PangoLayout, the part that actually lays out the text is only a small fraction ... 1000-2000 lines of code. The rest is bookkeeping, rendering, iteration over the layout and so forth. There's a big patch from Damon Chaplin outstanding to redo the line layout part of Pango to add justification. I haven't had the time to fully review it yet. It's pretty darn complex. If it turns out that we can't just replace the current code wholesale, that patch may be a good point to look at making line-layout pluggable. Non-greedy linebreaking is very challenging to do with good internationalized shaping. (I think Damon spent some time trying to figure out and then gave up.) But if someone had a spare month, I think it's definitely possible. And I wouldn't mind shipping it with Pango, as long as it was optional. As well as performance considerations, it is just the wrong behavior for most interactive applications. Non-rectangular layout, on the other hand, is pretty easy. It's not totally trivial when you have mixed fonts within a line and thus uneven line spacing, but I think the main challenge there is simply coming up with a good interface for representing the shape to Pango. Regards, Owe signature.asc Description: This is a digitally signed message part ___ gtk-i18n-list mailing list gtk-i18n-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-i18n-list
Stock icons
May I use the stock icons as icons for an application to be published under GPL written in another toolkit? Benjamin Lau __ Do You Yahoo!? Log on to Messenger with your mobile phone! http://sg.messenger.yahoo.com ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
how to find mr. matthew stucky.
I have buy book about gtk and mysql with title MySql Building User Interface with the author Mr. Matthew Stucky. And I see the last page where complete source code project can be download at http://pages.prodigy.net/stuckym/mysql_book/. But i can't found this address to download. And the book not came with cdrom source code. Help me, where I can download the complete source code or where I can contact Mr. Matthew Stucky. Last email Mr. Matthew Stucky is : [EMAIL PROTECTED] Thanks in advance. Hariyanto ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: how to find mr. matthew stucky.
Le mercredi 16 mars 2005 19:45 +0700, Hariyanto a crit : I have buy book about gtk and mysql with title MySql Building User Interface with the author Mr. Matthew Stucky. And I see the last page where complete source code project can be download at http://pages.prodigy.net/stuckym/mysql_book/. But i can't found this address to download. And the book not came with cdrom source code. Help me, where I can download the complete source code or where I can contact Mr. Matthew Stucky. Last email Mr. Matthew Stucky is : [EMAIL PROTECTED] After some googlin, I found a link: http://www.informit.com/content/images/073571049X/downloads/mysql_book.zip It might be what you are looking for. ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
fixed position, fixed size
I have a gnomecanvas object (is this the right list?). The user can move around in the object by pressing arrows that are drawn in the lower right hand corner of the object. I'm guessing when the user clicks a move arrow, I'd use gnome_canvas_scroll_to(cx, cy) to scroll on the canvas. The user can also zoom in and out on the canvas. So each time the user moves or zooms, I'd need to rerdraw those movement arrows so they stay in the same place and say the same size (in pixels on the user's screen). Is there an easy way to do this? Or do I need to delete the old arrows, figure out where in the world coordinates to draw the new arrows, and query the current zooming level to figure out how large the arrows should be? Thanks, Joe ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: fixed position, fixed size
I have a gnomecanvas object (is this the right list?). The user can move around in the object by pressing arrows that are drawn in the lower right hand corner of the object. I'm guessing when the user clicks a move arrow, I'd use gnome_canvas_scroll_to(cx, cy) to scroll on the canvas. The user can also zoom in and out on the canvas. So each time the user moves or zooms, I'd need to rerdraw those movement arrows so they stay in the same place and say the same size (in pixels on the user's screen). Is there an easy way to do this? Or do I need to delete the old arrows, figure out where in the world coordinates to draw the new arrows, and query the current zooming level to figure out how large the arrows should be? my experience of canvas zooming is that its mostly useless. as soon as you put multiple objects on the canvas whose behaviour under zoom differs from each other, using the affine transform method of zooming the whole canvas becomes more of an impediment than a benefit. your mileage may vary. and check out http://ardour.org/ for a very, very heavyduty canvas application (though we're still stuck using GtkCanvas for the next month or so). --p ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: fixed position, fixed size
On Wed, 16 Mar 2005 19:42:03 -0500, Paul Davis [EMAIL PROTECTED] wrote: I have a gnomecanvas object (is this the right list?). The user can move around in the object by pressing arrows that are drawn in the lower right hand corner of the object. I'm guessing when the user clicks a move arrow, I'd use gnome_canvas_scroll_to(cx, cy) to scroll on the canvas. The user can also zoom in and out on the canvas. So each time the user moves or zooms, I'd need to rerdraw those movement arrows so they stay in the same place and say the same size (in pixels on the user's screen). Is there an easy way to do this? Or do I need to delete the old arrows, figure out where in the world coordinates to draw the new arrows, and query the current zooming level to figure out how large the arrows should be? my experience of canvas zooming is that its mostly useless. as soon as you put multiple objects on the canvas whose behaviour under zoom differs from each other, using the affine transform method of zooming the whole canvas becomes more of an impediment than a benefit. your mileage may vary. and check out http://ardour.org/ for a very, very heavyduty canvas application (though we're still stuck using GtkCanvas for the next month or so). I'm using gnome_canvas_set_pixels_per_unit () to zoom in and out. That's not an affine transformation, is it? ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
new software Gtk2::GIS
I've just uploaded to sourceforge a set of new versions of my libral, Geo::Raster and of Gtk2::GIS which is a new Perl module. Gtk2::GIS is a simple, but hopefully powerful, GIS which builds on Perl/Gtk2, a new Gtk2 widget for displaying rasters (subclassed from ScrollableWindow), Geo::Raster, Geo::Shapefile, and libral. This release contains a lot of self-test code in Geo::Raster, and code cleanup in libral but it should still be treated as an experimental package. The Gtk2::GIS is an initial release and contains just the basic functionality. I call Gtk2::GIS a GIS but it actually is just a set of interoperating Gtk2 widgets which can be used as such in an application but can also be extended/embedded in custom applications. The packages are at http://sourceforge.net/projects/libral/ I've submitted a proposal to OSG'05 to present this software in a 90 minute session but briefly said it is a low level raster algebra library with a Perl interface and now Perl/Gtk2 GUI. I was in fact surprised to see how appealing and useful the graphical interface could be since the libral and Geo-Raster require that overlayed rasters are of same size and have the same world coordinates. In the GUI, however, since it works on only world coordinates, it is possible to visualize all kinds of rasters (and vector data) at the same time. Then, with zooming and panning the user can go to the place of interest, clip out overalyable rasters from the visible area and work on those and put the result to the GUI. Because the GUI is in Perl, it was easy to add an interactive shell which can be used side by side with the GUI. Also exteding the GIS is easy as long as one is happy with Perl. Such shell was included in Geo-Raster previously but the graphics was done with PGPLOT with only one raster at a time. I also added support for Shapefiles into Gtk2::GIS using my Geo::Shapefile (which is a Perl interface to Frank Warmerdam's shapelib). It works ok but shapefile and raster layers really need to be made equivalent, i.e., support transparency and layering (now shapefiles are rendered after rasters). By the way, does anybody know of good algorithm for rendering (including transparency) polygons as they are in Shapefiles (non-complex but having potentially holes)? And, sorry, all this is distributed only as source code and, while cross-platform in theory (C, Perl and Gtk2 are all cross-platform), is maybe not simple to build on a non-GNU environment. Ari Jolma ___ gtk-perl-list mailing list gtk-perl-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Re: non-resizable window wants to resize to be a square
On Wed, 2005-03-16 at 19:35 -0500, Jeff 'japhy' Pinyan wrote: Can other people verify this oddity for me? ... For some reason, the window allows itself to be resized vertically so it can be 200x200. Can other people verify that this happens? I'm on Windows, but non-Windows verification would make me happier. On my Debian Sarge box running 1.062 of the Perl Gtk2 bindings (under GNOME) I cannot resize that window in either direction. Cheers Grant ___ gtk-perl-list mailing list gtk-perl-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-perl-list
UI for scheduling events (appointments)
One of the apps that I am writing requires a UI to specify a recurring set of 'events' (events in the calendar sense). Like a meeting appointment for example, on all mondays and thursdays for the next 3 months. Kinda like Evolution/Outlook meeting schedule. Ripping anything from Evolution may be too heavy weight for me. So I am thinking of writing a gtk2-perl widget to meet this need. I googled around a bit and finally decided to choose Flavio's DateTime::Event::ICal as the backend spec. So my aim is now to write a UI for the DateTime::Event::ICal module. Since there is quite a bit of UI design involved, I am considering using glade and Gtk2::GladeXML. But I am wondering what is a clean approach to package the xml file in the module. For example, if I want to generate a cpan dist, is it normal to package a glade xml file along ? Or would you recommend writing widget packing perl code instead of gladexml ? Here is a sample (hollow) screenshot from my widget http://www.flickr.com/photos/[EMAIL PROTECTED]/6709345/ I am considering the name Gtk2::Ex::ICal for this module. Design suggestions / naming suggestions are welcome. If there is prior art that I could use, that'll be great too. Ofey. ___ gtk-perl-list mailing list gtk-perl-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-perl-list
