Re: Drawing on gtk textview
I had a same problem a while ago with expose drawing, and it turned out that the problem was this: to draw something in your handler, you must use event-window as a pointer to the window that is being drawn, not widget-window or anything else. Once I've made that change, my expose drawing started to work fine. You can see an example of this within my Notecase project source code (http://notecase.sourceforge.net/) I hope this helps. Regards, Miroslav - Original Message - From: Soren Berg [EMAIL PROTECTED] To: gtk-app-devel-list@gnome.org Sent: Friday, October 17, 2008 4:43 PM Subject: Drawing on gtk textview I am trying to draw on a gtk textview's gdk window. I have set the textview as app paintable before initialization and done the drawing in a callback for the expose event of the textview as suggested herehttp://mail.gnome.org/archives/gtk-app-devel-list/2007-June/msg00060.html( http://mail.gnome.org/archives/gtk-app-devel-list/2007-June/msg00060.html) but have not had any luck. Has this functionality been depreciated? Do I need to use composited windows somehow? The previously linked discution suggests that the OP got it working without them but he did not say how. I would appricate any advice or information you could give me. Thank you, -Soren Berg ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Passing an iter
Is it safe to pass an iter as a parameter to a function? Thanks, Dave ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
MS Windows packages and modularity
A while back some app developers who have need of GTK+ on MS Windows, yet whose apps use only a subset of the available image-loaders, requested that the build of the Windows packages be made modular (as it was in the old days). That way, one can slim down the packaging of one's app, skipping the redundant loaders along with their third-party dependencies (e.g. libtiff and libjpeg). This was done for a while (e.g. with the GTK 2.12.11 package), and I was grateful for that. But I see that the current GTK 2.14.4 package ( http://www.gtk.org/download-windows.html ) has reverted to a monolithic build, so that a gtk app won't start without having the tiff and jpeg libraries installed, even if they're never used. Was there a compelling reason for this reversion? Any chance of getting a modular build again? Thanks. -- Allin Cottrell Department of Economics Wake Forest University ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Glade (Re: What widgets in TES Construction Set?)
About Glade. I tried to create something simple (which I don't remember now) it didn't succeed. The menubar was simple, but this equally simple thing was too hard. I will check it again and post to glade lists someday. It would be nice if there would be complete examples which could be grabbed and dragged to the project. This equals to adding complete subgraph of widgets to the project. For other project, I need an audio waveform display with callbacks and with overdrawn controls (draggable selection edge) and displays (playhead time display moving with the pointer). It would be nice if I could grab an example of this kind of thing, and then modify it to my taste in Glade. Such an audio waveform display may require multiple pixmaps. If waveform is moved forward, only the new revealed waveform is drawn, and the rest are copied. One pixmap could contain the waveform and other the controls (which are widgets), the final rendering then composite of the two pixmaps. All the code making the framwork work could be part of the Glade (not the waveform drawing, not the audio reading). Then if I have an Open File dialog, I would want Glade to generate me a framework code for opening the audiofile at background thread, if necessary. If the waveform drawing LOD file is missing it needs to be generated and that may take time. At meanwhile user should be able to continue editing of other audio. Threads etc. are standard part of modern software so they should be easily available. If Glade searches for means to extends its cababilities, this would be the way. Juhana ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Glade (Re: What widgets in TES Construction Set?)
On Mon, Oct 20, 2008 at 1:50 PM, Juhana Sadeharju [EMAIL PROTECTED] wrote: About Glade. I tried to create something simple (which I don't remember now) it didn't succeed. The menubar was simple, but this equally simple thing was too hard. I will check it again and post to glade lists someday. It would be nice if there would be complete examples which could be grabbed and dragged to the project. This equals to adding complete subgraph of widgets to the project. Yeah, weve discussed such a probable feature under the terms of widget templates, we would have offered a whole bunch of composite widgets and dialogs based on the feature, and also allow users to save a template so they could access it in the palette... ofcourse nobody came around to do the work ;-) Man the possibilities would be endless if we had more than 1.5 people working on Glade ! :D For other project, I need an audio waveform display with callbacks and with overdrawn controls (draggable selection edge) and displays (playhead time display moving with the pointer). It would be nice if I could grab an example of this kind of thing, and then modify it to my taste in Glade. Such an audio waveform display may require multiple pixmaps. If waveform is moved forward, only the new revealed waveform is drawn, and the rest are copied. One pixmap could contain the waveform and other the controls (which are widgets), the final rendering then composite of the two pixmaps. All the code making the framwork work could be part of the Glade (not the waveform drawing, not the audio reading). Then if I have an Open File dialog, I would want Glade to generate me a framework code for opening the audiofile at background thread, if necessary. If the waveform drawing LOD file is missing it needs to be generated and that may take time. At meanwhile user should be able to continue editing of other audio. Threads etc. are standard part of modern software so they should be easily available. If Glade searches for means to extends its cababilities, this would be the way. Hi, Currently using glade you could conceivably edit anything you want in glade - so long as you work with GObjects that have properties and signals (you can even invent properties that are loaded and saved in custom ways, like GtkListStore data for example). Now obviously I'm not going to write your toolkit of objects and your application for you, but I can offer you a dynamic way to edit save and load all your objects from an xml description, whether your objects are waveforms contained inside a track object which asks your waveforms to draw itself at specific locations, depending on the waveform properties or data, or whether your objects represent frames in an animation, or even singleton objects that may represent devices on the embedded system your writing your application for. Nothing is stopping you from writing a GThreadedObject that runs a thread when its in active state and the thread just fires a signal for the code to implement. As glade, we dont have the resources (and its not part of our task description) to go and write all the fancy toolkits that we could support, but I would love to see the envelope pushed, for instance, I dont see any reason why GStreamer pipelines coulnt be edited in glade and loaded by GtkBuilder. Cheers, -Tristan ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Using a key to generate mouse button press?
My software uses Alt modifier but the Alt key is now blocked by Gnome. A quick solution is to use key presses for generating mouse button presses. How to generate them? A method found from the mail archives is win = gdk_window_at_pointer(wx, wy); event.type = GDK_BUTTON_PRESS; event.button.send_event = True; event.button.window = win; event.button.x = wx; event.button.y = wy; event.button.state = 0; event.button.button = Button1; event.button.source = GDK_SOURCE_MOUSE; event.button.x_root = (double)newx; event.button.y_root = (double)newy; gdk_event_put(event); Problem 1: I catch key presses at the top window because I could not get them working with a drawing area. How to get the pointer position with respect to the drawing area? How to know if the pointer is in the drawing area? There is no point in sending the event if pointer is somewhere else. Problem 2: Why I should fill the pointer position at all? I just want generate the mouse button press (with modifier Alt), and to get GTK/GDK in process of doing the rest, like checking the pointer position, the active window, and widget. Problem 3: While sending a mouse button press from the code is interesting, how my application could catch the Alt modifier? When my software is in use (focus, enter etc.) the Alt modifier flow should be guided to my software instead of Gnome. Juhana ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: MS Windows packages and modularity
On Mon, Oct 20, 2008 at 12:01 PM, Allin Cottrell [EMAIL PROTECTED] wrote: A while back some app developers who have need of GTK+ on MS Windows, yet whose apps use only a subset of the available image-loaders, requested that the build of the Windows packages be made modular (as it was in the old days). That way, one can slim down the packaging of one's app, skipping the redundant loaders along with their third-party dependencies (e.g. libtiff and libjpeg). This was done for a while (e.g. with the GTK 2.12.11 package), and I was grateful for that. But I see that the current GTK 2.14.4 package ( http://www.gtk.org/download-windows.html ) has reverted to a monolithic build, so that a gtk app won't start without having the tiff and jpeg libraries installed, even if they're never used. Was there a compelling reason for this reversion? Any chance of getting a modular build again? Thanks. The reason for this change is that the 2.14.x series uses a new GDI+ based loader instead of the previous loaders. If you run dependency walker on libgdk_pixbuf-2.0-0.dll, you'll see that it doesn't depend on the various external libraries. -D ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: MS Windows packages and modularity
On Mon, 20 Oct 2008, Daniel Atallah wrote: On Mon, Oct 20, 2008 at 12:01 PM, Allin Cottrell [EMAIL PROTECTED] wrote: But I see that the current GTK 2.14.4 package ( http://www.gtk.org/download-windows.html ) has reverted to a monolithic build, so that a gtk app won't start without having the tiff and jpeg libraries installed, even if they're never used. The reason for this change is that the 2.14.x series uses a new GDI+ based loader instead of the previous loaders. OK, thanks for the info. If you run dependency walker on libgdk_pixbuf-2.0-0.dll, you'll see that it doesn't depend on the various external libraries. Hmm, but I've tried it on Windows XP: when I use the GTK 2.14.4 package my GTK app won't start without jpeg62.dll. Allin Cottrell ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: MS Windows packages and modularity
On Mon, Oct 20, 2008 at 4:57 PM, Allin Cottrell [EMAIL PROTECTED] wrote: On Mon, 20 Oct 2008, Daniel Atallah wrote: On Mon, Oct 20, 2008 at 12:01 PM, Allin Cottrell [EMAIL PROTECTED] wrote: But I see that the current GTK 2.14.4 package ( http://www.gtk.org/download-windows.html ) has reverted to a monolithic build, so that a gtk app won't start without having the tiff and jpeg libraries installed, even if they're never used. The reason for this change is that the 2.14.x series uses a new GDI+ based loader instead of the previous loaders. OK, thanks for the info. If you run dependency walker on libgdk_pixbuf-2.0-0.dll, you'll see that it doesn't depend on the various external libraries. Hmm, but I've tried it on Windows XP: when I use the GTK 2.14.4 package my GTK app won't start without jpeg62.dll. Oh, weird. You're right. I guess I'm confused as to how the new situation works. I just ran the dependency walker and it is different than I thought it was; someone more clueful than me will have to clarify. -D ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: MS Windows packages and modularity
On Mon, Oct 20, 2008 at 4:57 PM, Allin Cottrell [EMAIL PROTECTED] wrote: On Mon, 20 Oct 2008, Daniel Atallah wrote: On Mon, Oct 20, 2008 at 12:01 PM, Allin Cottrell [EMAIL PROTECTED] wrote: But I see that the current GTK 2.14.4 package ( http://www.gtk.org/download-windows.html ) has reverted to a monolithic build, so that a gtk app won't start without having the tiff and jpeg libraries installed, even if they're never used. The reason for this change is that the 2.14.x series uses a new GDI+ based loader instead of the previous loaders. OK, thanks for the info. If you run dependency walker on libgdk_pixbuf-2.0-0.dll, you'll see that it doesn't depend on the various external libraries. Hmm, but I've tried it on Windows XP: when I use the GTK 2.14.4 package my GTK app won't start without jpeg62.dll. I had previously tried with the GTK+ 2.14.1 libgdk_pixbuf-2.0-0.dll and it only depended on libpng and not libjpeg, libtiff, etc. I wonder if this was a mistake in how the 2.14.4 binaries were built as I don't see anything in the ChangeLog related to this. -D ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: MS Windows packages and modularity
Was there a compelling reason for this reversion? Not really. As has already been said, if/when the GDI+ -based pixbuf loaders would be used, then it would hopefully be 100% clear that it makes sense to build them as built-in in the gdk-pixbuf DLL. But now when I was forced to revert to the libgpej and libtiff -based loaders, there are two more or less equivalent choices, both which have their disadvatages: either 1) build separate png, jpeg and tiff loaders, which means there are more files to distribute for people who want to minimize the number of files in the GTK+ runtime and still be able to load jpef or tiff files, or 2) build built-in loaders which means the png, jpeg and tiff DLLs are required even for a GTK+ runtime used in a situation where it doesn't use any png, jpeg and tiff files. Would the best solution be to build the png, jpeg and tiff libraries as static libraries, and link them statically into gdk-pixbuf? --tml ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: MS Windows packages and modularity
On Mon, Oct 20, 2008 at 7:20 PM, Tor Lillqvist [EMAIL PROTECTED] wrote: Was there a compelling reason for this reversion? Not really. As has already been said, if/when the GDI+ -based pixbuf loaders would be used, then it would hopefully be 100% clear that it makes sense to build them as built-in in the gdk-pixbuf DLL. But now when I was forced to revert to the libgpej and libtiff -based loaders, there are two more or less equivalent choices, both which have their disadvatages: either 1) build separate png, jpeg and tiff loaders, which means there are more files to distribute for people who want to minimize the number of files in the GTK+ runtime and still be able to load jpef or tiff files, or 2) build built-in loaders which means the png, jpeg and tiff DLLs are required even for a GTK+ runtime used in a situation where it doesn't use any png, jpeg and tiff files. Would the best solution be to build the png, jpeg and tiff libraries as static libraries, and link them statically into gdk-pixbuf? I don't particularly like the built-in loaders, and statically linking the dependent library doesn't address my concern. There are occasionally security vulnerabilities in these libraries (most recently libpng and libtiff (which is still unpatched)) - I like being able to update the library versions without changing GTK+. It is particularly handy that I can disable the tiff loader via the gdk-pixbuf.loaders file until there is an updated libtiff. -D ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: MS Windows packages and modularity
On Tue, 21 Oct 2008, Tor Lillqvist wrote: Was there a compelling reason for this reversion? Not really. As has already been said, if/when the GDI+ -based pixbuf loaders would be used, then it would hopefully be 100% clear that it makes sense to build them as built-in in the gdk-pixbuf DLL. Yes, that seems to make sense. But now when I was forced to revert to the libgpej and libtiff -based loaders... Sorry (just out of ignorance): who or what forced you to revert to the libjpeg- and libtiff-based loaders? there are two more or less equivalent choices, both which have their disadvatages: either 1) build separate png, jpeg and tiff loaders, which means there are more files to distribute for people who want to minimize the number of files in the GTK+ runtime and still be able to load jpef or tiff files, or 2) build built-in loaders which means the png, jpeg and tiff DLLs are required even for a GTK+ runtime used in a situation where it doesn't use any png, jpeg and tiff files. I'm not speaking from any great base of expertise, but just IMO: 1) ...more files to distribute for people who want to minimize the number of files in the GTK+ runtime... Why would anyone want to minimize the _number of files_ in a GTK runtime package, as opposed to the size in bytes of the package? 2) I suspect that most GTK apps (other than apps such as GIMP which traffic in images) have no use for JPEG or TIFF functionality. This is really quite specialized. Would the best solution be to build the png, jpeg and tiff libraries as static libraries, and link them statically into gdk-pixbuf? This would avoid the need for the app developer to package third-party DLLs, yet it still seems a bit awkward: it includes in the byte-count of the GTK distro specialized functionality that, I suspect, few will need. (I'd place PNG functionality in a different category since in many ways it's treated as native in GTK.) -- Allin Cottrell Department of Economics Wake Forest University ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
[REMINDER] GTK+ Team Meeting - October 21st
hi everyone; this is the usual reminder for the IRC GTK+ Team Meeting. the meeting will be held in the #gtk-devel channel on irc.gnome.org, at 20:00 UTC[1]. the points are: o Miscellaneous eventual changes will be notified on the wiki page[0]. everyone can participate, as usual. ciao, Emmanuele. +++ [0] http://live.gnome.org/GTK+/Meetings [1] http://www.timeanddate.com/worldclock/fixedtime.html?month=10day=21year=2008hour=20min=0sec=0p1=0 -- Emmanuele Bassi, W: http://www.emmanuelebassi.net B: http://log.emmanuelebassi.net ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [REMINDER] GTK+ Team Meeting - October 21st
Hi,
Emmanuele Bassi schrieb:
hi everyone;
this is the usual reminder for the IRC GTK+ Team Meeting. the meeting
will be held in the #gtk-devel channel on irc.gnome.org, at 20:00
UTC[1].
the points are:
o Miscellaneous
eventual changes will be notified on the wiki page[0].
I'd like to discuss these gobject related tickets. What do glib
maintainers think about them? Something left to do or can they go in?
http://bugzilla.gnome.org/show_bug.cgi?id=418970
Avoid trivial allocations during g_object_notify()
http://bugzilla.gnome.org/show_bug.cgi?id=536939
g_object_{set,get} has quite some overhead
http://bugzilla.gnome.org/show_bug.cgi?id=553794
Support for light-weight objects
http://bugzilla.gnome.org/show_bug.cgi?id=557047
g_object_newv() should skip notify:: handling
Stefan
everyone can participate, as usual.
ciao,
Emmanuele.
+++
[0] http://live.gnome.org/GTK+/Meetings
[1]
http://www.timeanddate.com/worldclock/fixedtime.html?month=10day=21year=2008hour=20min=0sec=0p1=0
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Non uniform scaling
Hi, I was looking into how to non uniformly scale fonts with Pango, and it seems that the only way is to use cairo_scale. This is not great, however, as it means I have to keep track of that scale to scale other transforms I do afterwards and other things like the width of a Pango layout when calculating positions. This makes it very brittle and unnecessarily complex to use. A better way would be to get Pango to allow non uniform scale. I've found the place in the Pango source where the scale is set, and it is in _pango_cairo_fc_font_new (I haven't looked for other backends, but I'm sure you'll find it faster than me). Here, the font matrix is scaled uniformly by the font size, rather than two scales. Would it be possible to expose a non uniform scale in the Pango API ? Hopefully no backends would lack the ability to do that. Thanks ___ gtk-i18n-list mailing list gtk-i18n-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-i18n-list
error while compiling glib-2.17.3
i am cross compiling glib-2.17.3 for ARM9 on a linux(fedora) system . the configuration is done but while giving make the following errors occur gatomic.c: In function `IA__g_atomic_int_compare_and_exchange': gatomic.c:66: error: impossible constraint in `asm' gatomic.c:64: warning: 'result' might be used uninitialized in this function make[4]: *** [gatomic.lo] Error 1 make[4]: Leaving directory `/root/Desktop/glib-2.17.3/glib' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/root/Desktop/glib-2.17.3/glib' make[2]: *** [all] Error 2 could anyone help me know what this is due to and how to solve it . thanks tina ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
'Gtk-WARNING **: Unable to locate theme engine in module_path: qtcurve' problem
Hello All, after upgrading my KDE version I'm getting this warning: Gtk-WARNING **: Unable to locate theme engine in module_path: qtcurve ... and the application does not look the way it used to look. I read http://www.gtk.org/api/2.6/gtk/gtk-running.html document, but it's unclear to me how to fix the problem. Unfortunately, gtk+ does not print the paths it goes through trying to locate that theme engine, otherwise I would have guessed where to put the files or to symlink them. The theme engine in question (if I understand correctly what it is) can be either of the following two files: /usr/lib/qt3/plugins/styles/qtcurve.so /usr/lib/kde4/plugins/styles/qtcurve.so - I mean, these are real location of my 'qtcurve.so' files on in my filesystem. Since I'm on KDE3, I guess I need the first of the two. So, how can I resolve this issue ? I.e. what directories/files should I create and/or what environment variables to set in order to make the application see qtcurve.so ? Also, there is /usr/share/themes/QtCurve/gtk-2.0/gtkrc file which I want to be used, in the beginning the file says: style qtcurve-default , so I guess, this is the gtkrc file I want to be used by gtk+ applications. Thanks, Sergei. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
expander label widget question
Hello, I have a GtkHBox that contains a GtkLabel and a GtkButton. If I set this HBox to be a GtkExpander label widget (gtk_expander_set_label_widget), I can't click the button. It seems like all of the X button presses are going only to the GtkExpander object. The button's clicked() handler never gets called. Any idea how to make this button clickable? Hopefully my description makes sense. If not, I can include some example code. Thanks in advance for any suggestions, -Brian. ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Perl Gtk2 simple scheduling
On Sun, 19 Oct 2008 18:17:25 -0700 (PDT)
MICHAEL MCGINN [EMAIL PROTECTED] wrote:
Hi,
I have an existing perl Gtk2 application that will run a sub-process based on
user initiation(button click) and it reports back to an output console as it
progresses. This is a consistent activity that happens every hour or so.
I'd like to maintain the 'manual' initiation but provide an 'automatic-mode'
and have it run the event at a pre-determined time (60-90 minute intervals).
What is the best way to do this with perl Gtk2?
Regards,
Michael
Use a timer.
Return 1 from the callback to keep the timer going.
Return 0 to end the timer.
I need to refresh (update) a window (in
fact a widget) every X seconds.
my $id = Glib::Timeout-add ($milliseconds, \timeout_handler);
sub timeout_handler {
do_cool_stuff ();
return $need_to_stay_installed; # return 0 or 1 to kill/keep timer going
}
http://gtk2-perl.sourceforge.net/doc/pod/Glib/MainLoop.html#integer_Glib_Timeout
http://developer.gnome.org/doc/API/2.0/glib/glib-The-Main-Event-Loop.html#g-timeout-add
zentara
--
I'm not really a human, but I play one on earth.
http://zentara.net/Remember_How_Lucky_You_Are.html
___
gtk-perl-list mailing list
gtk-perl-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Gtk2 1.20 build error
Fedora Core 3 perl 5.8.5 When building Gtk2 1.20 on Fedora Core 3 I receive the following error: Running Mkbootstrap fro Gtk2 () chmod 644 Gtk2.bs rm -f blib/arch/auto/Gtk2/Gtk2.so [ LD blib/arch/auto/Gtk2/Gtk2.so ] /usr/bin/ld: cannot find -lgtk-x11-2.0 gtk-x11-2.0 is present and located in /usr/lib. Thanks in advance!___ gtk-perl-list mailing list gtk-perl-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Re: Gtk2 1.20 build error
2008/10/20 MICHAEL MCGINN [EMAIL PROTECTED]: Fedora Core 3 perl 5.8.5 When building Gtk2 1.20 on Fedora Core 3 I receive the following error: Running Mkbootstrap fro Gtk2 () chmod 644 Gtk2.bs rm -f blib/arch/auto/Gtk2/Gtk2.so [ LD blib/arch/auto/Gtk2/Gtk2.so ] /usr/bin/ld: cannot find -lgtk-x11-2.0 gtk-x11-2.0 is present and located in /usr/lib. I don't know the package name for fedora, but you need the development libraries... In Debian/Ubuntu it's libgtk2.0-dev . cheers, -Pascal -- Homepage (http://organact.mine.nu) Debian GNU/Linux (http://www.debian.org) LACIME: École de technologie supérieure (http://lacime.etsmtl.ca) ___ gtk-perl-list mailing list gtk-perl-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Re: Moving to GNOME's SVN
Torsten Schoenfeld wrote: we're moving all our modules to GNOME's SVN server: I've just sent the cvs2svn dumps to the GNOME admins. Please consider the CVS repository read-only now. OK, Olav Vitters just completed the import. We now have the following SVN repositories: perl-Cairo perl-ExtUtils-Depends perl-ExtUtils-PkgConfig perl-Glib perl-Gnome2 perl-Gnome2-Canvas perl-Gnome2-Dia perl-Gnome2-GConf perl-Gnome2-Notify perl-Gnome2-PanelApplet perl-Gnome2-Print perl-Gnome2-Rsvg perl-Gnome2-VFS perl-Gnome2-Vte perl-Gnome2-Wnck perl-GStreamer perl-GStreamer-GConf perl-GStreamer-Interfaces perl-Gtk2 perl-Gtk2-GladeXML perl-Gtk2-GLExt perl-Gtk2-Html2 perl-Gtk2-MozEmbed perl-Gtk2-Recent perl-Gtk2-SourceView perl-Gtk2-Spell perl-Gtk2-TrayIcon perl-Gtk2-TrayManager They can all be browsed via http://svn.gnome.org/viewvc/module and fetched anonymously via svn co http://svn.gnome.org/svn/module/trunk module or svn co svn://svn.gnome.org/svn/module/trunk module If you have a GNOME account, you can use svn co svn+ssh://username@svn.gnome.org/svn/module/trunk module Please check your favorite module for glitches in its history that cvs2svn might have produced. To ease working with all those SVN repositories, I plan to add support for them to jhbuild. If anybody wanted to beat me at that, they would be very welcome. -Torsten ___ gtk-perl-list mailing list gtk-perl-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-perl-list
