Re: Binding run-time data
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Germán Diago wrote: > Hello. I'm using gtkmm to make a little program. > > The program has some entries and a button. > > When the button is clicked, I'd like to get the data inside the entries. > > So I'd like my on_button_clicked slot to be like this: > > void on_button_clicked(int data1, int data2); > > If I use bind, the data is bound at compile-time, so I can't. I don't want > to use Gtk::Entry * as arguments, because I want the slots to be > independent of the gui toolkit. > Any help here? Thanks. You can use sigc::compose() which is like sigc::bind() but takes a functor to call instead of static data. It would look like this (assuming your entries are actually SpinButtons because your on_button_clicked function takes integers as arguments): button.signal_clicked().connect( sigc::compose( sigc::ptr_fun(&on_button_clicked), sigc::mem_fun(entry1, &Gtk::SpinButton::get_value_as_int), sigc::mem_fun(entry2, &Gtk::SpinButton::get_value_as_int) ) ); Greetings, Armin -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGTuEkhOtxKlDYm6cRAuf8AJ0ekd8Vy2EymA4wkL6Ke/gVPJfIFgCgsQ3E SWXmfqSE1lgr9afe856YrsE= =MNbD -END PGP SIGNATURE- ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Overriding vfuncs with disabled vfunc API
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello list, is it possible somehow (without creating a new GObject on my own) to override vfuncs when implementing for example a custom Gtk::Container with disabled vfunc API (GLIBMM_ENABLE_VFUNCS not defined)? The documentation says the following: "However, if you really need to override a _vfunc, for instance when implementing a custom Gtk::TreeModel, you may directly access the underlying GObject via the gobj() method." However, I am not sure what I can do with the underlaying GObject in this case. I can probably use it to get a pointer to the class struct and register my vfunc there, but this is really hackish because if another one does the same thing, it will overwrite my vfunc. Armin -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGWYA8hOtxKlDYm6cRAh0kAKCBI3w8rJYeNw5ziUWd91zOKfTOrQCg0Kul 7TyqUWYKdfWMziUNqOdV/to= =icjG -END PGP SIGNATURE- ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Waiting for multiple windows
On Thu, 2007-08-30 at 22:25 +0100, Robert Pearce wrote: > On Wed, 29 Aug 2007 20:42:49 +0100 > Edd Dawson <[EMAIL PROTECTED]> wrote: > > > > Currently, when I close the main window, all the pop-ups dissappear because > > the > > event loop has finished. Is there any way to keep the initial call to > > Gtk::Main::Run() from finishing until all the popups have been closed? > > I'm not sure about this, but I think the trick is to override the main > window's on_close event so as to minimize rather than hide. It is OK to hide (or destroy) the window. Just don't call Gtk::Main::run() with the main window as its argument (there is a overload that takes no arguments). > Obviously you then need to provide some other way to make it close properly. > If you want that to be when the last pop-up closes you probably need to > maintain some sort of counter of windows so that the last pop-up knows it's > the last one and can call the method that closes the main window. > > Rob Armin ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: glibmm g_mkdir_with_parents() function/method
On Thu, 2007-08-30 at 13:21 -0400, José Alburquerque wrote:
> Hi everyone. I'm not subscribed to the gtkmm-list but I do have sort of
> a quick question on something I'm trying to accomplish which I hope any
> of you can answer. Would your answers pleased be cc'd to me? Thanks.
>
> My question is: I'm trying to create a directory (with parents) within
> a c++ program. I'm thinking of using gtkmm for the gui and looked all
> around the glibmm documentation to see if there was such a function (to
> create directories). I noticed that glib has a g_mkdir_with_parents()
> function and I was wondering if this function exists for glibmm. If so,
> can any of you point in the direction of its documentation? If it
> doesn't, do any of you have a suggestion as to what I might do to create
> a directory? Thanks so much.
If it is not wrapped in glibmm, you can always call the C function
(namely g_mkdir_with_parents()) from within your C++ code.
Also, in Gobby, we have a function that does probably the same as
g_mkdir_with_parents (which we did not use because gobby only requires
glib 2.6):
void create_path_to(const std::string& to)
{
// Directory exists, nothing to do
if(Glib::file_test(to, Glib::FILE_TEST_IS_DIR) )
return;
// Find path to the directory to create
std::string path_to = Glib::path_get_dirname(to);
// Create this path, if it doesn't exists
create_path_to(path_to);
// Create new directory
create_directory(to.c_str() );
}
> -José
Armin
> ___
> gtkmm-list mailing list
> gtkmm-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gtkmm-list
___
gtkmm-list mailing list
gtkmm-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Trying to compile gtk+ but no success cause glib
On Sun, 2007-10-07 at 10:05 +0600, asm asadujjaman wrote: > I am trying to actually compile glade3-3.4 so I need to compile loads > of other things including glib and gtk+. I have compiled and installed > glib-2.14.0 and then trying to configure gtk+. > But it says- > [CODE] > checking pkg-config is at least version 0.7... yes > checking for GLIB - version >= 2.13.5... > *** 'pkg-config --modversion glib-2.0' returned 2.14.0, but GLIB (2.12.11) > *** was found! If pkg-config was correct, then it is best > *** to remove the old version of GLib. You may also be able to fix the error > *** by modifying your LD_LIBRARY_PATH enviroment variable, or by editing > *** /etc/ld.so.conf. Make sure you have run ldconfig if that is > *** required on your system. > *** If pkg-config was wrong, set the environment variable PKG_CONFIG_PATH > *** to point to the correct configuration files > no > configure: error: > *** GLIB 2.13.5 or better is required. The latest version of > [/CODE] > Then I tried to check it by hand- > [CODE] > [EMAIL PROTECTED] src]# FLAGS=`pkg-config glib-2.0 --cflags --libs` > [EMAIL PROTECTED] src]# echo $FLAGS > -I/gtkmm/include/glib-2.0 -I/gtkmm/lib/glib-2.0/include -L/gtkmm/lib > -lglib-2.0 > [EMAIL PROTECTED] src]# cc -o glib-version glib-version.c $FLAGS > [EMAIL PROTECTED] src]# ./glib-version > 2 12 11 > [EMAIL PROTECTED] src]# pkg-config --modversion glib-2.0 > 2.14.0 > [/CODE] > I have also downloaded glib-2.14.1 but no gain. Seems those sources > are actually 2.12.11 or my wrong! Can any one help? I am feeling > desperate.. > *** GLIB is always available from ftp://ftp.gtk.org/pub/gtk/. Looks like you already have glib shared libraries installed. So you actually compile against 2.14, but (dynamically) link against 2.12. You should probably remove the installed version. A better way, however, is to use packages provided by your distribution. If they don't provide packages for glade-3.4, perhaps you can get (development versions) of its dependencies, though. Armin ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: maemomm: virtual function overrides
On Sun, 2007-11-11 at 07:50 +, John Steele Scott wrote:
> I have a Gtkmm application which uses a custom widget derived from
> Gtk::DrawingArea. This widget overrides the virtual functions of the
> parent, such as e.g.:
>
> void PlotCanvas::on_realize()
> {
> Gtk::DrawingArea::on_realize();
>
> // do some other stuff . . .
> }
>
> This works fine on my Ubuntu Gutsy machine, but when I try to compile
> this in the Maemo sandbox, it fails because there is no
> Gtk::DrawingArea::on_realize(). Similarly, other such signal handlers are
> never called, it seems that they need to be explicitly connected via
> their signal proxies.
>
> Since I'm new to Gtkmm, I'd like to know: is this difference due to the
> version of Gtkmm in Ubuntu Gutsy being much newer than the version in
> Maemo Bora, or is it a core difference between the Hildon and vanilla
> versions of Gtkmm? (I imagine it might be the latter, to save code size.)
It's exactly that. Default signal handlers are, among other API,
disabled in maemo to save code size. It shouldn't be much of a deal,
though, since you just can do something like
#ifndef GLIBMM_DEFAULT_SIGNAL_HANDLERS_ENABLED
signal_realize().connect(sigc::mem_fun(*this, &PlotCanvas::on_realize));
#endif
in your constructor. It gets trickier if you want to override GObject
vfuncs (those that end in _vfunc() in gtkmm).
Armin
> If the difference is due to the version number of Gtkmm, in which version
> did this feature (virtual functions for signals) get included in Gtkmm?
> Does the Maemo Chinook version of Gtkmm have overridable virtual
> functions?
>
> cheers,
>
> John
>
> ___
> gtkmm-list mailing list
> gtkmm-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gtkmm-list
___
gtkmm-list mailing list
gtkmm-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: gtkglextmm on Windows
On Sun, 2007-11-18 at 12:37 -0500, Bruce Sherwood wrote: > (I thought I'd sent this note a day or more ago, but it hasn't shown up > on the list; I apologize should this show up twice.) > > I'm trying to build gtkglextmm on Windows from source using MinGW. > There's a binary installer for gtkglext, but not for gtkglextmm, alas. I > thought I had previously succeeded in building on another Windows > machine starting from ./configure --prefix=/mingw, but now I get > "g++.exe: : No such file or directory" in the first phase, compiling in > tools/extra_defs_gen. > > I found instructions on building both gtkglext and gtkglextmm from source: > > http://www.mail-archive.com/[EMAIL PROTECTED]/msg00213.html > > The text describing building gtkglextmm is unfortunately a bit garbled. > Also, it says there's an error in line 113 of the Makefile, an extra > space in "LDFLAGS = -L /gtk/lib". At my line 113 I just see "LDFLAGS = > ". I don't know how to proceed. > > Can anyone give me advice on this? If it would be useful, I can supply > config.log and the output of make -d. > > It would be very nice if gtkglext and gtkglextmm were simply included in > gtk and gtkmm. I already built that some time ago: http://arbur.net/code/gtkglextmm. It might not be recent enough, but you can try it out if you want. Armin ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: wide char string literals to Glib ustring
On Sat, 2007-12-08 at 07:03 -0500, Onur Tugcu wrote:
> Hi,
> I'm writing my strings hardcoded into the program, so I want to make
> use of string literals in C++.
I think the easiest thing to do is not to use wchar_t at all but
directly encode the string literals in UTF-8.
> When I use gtkmm with vc++ 2005, sizeof(wchar_t) is 2.
> So I assumed utf-16 encoding and wrote:
>
> Glib::ustring w2ustring(std::wstring const &w)
> {
> gunichar2 const* utf16= reinterpret_cast(w.c_str());
> gchar* utf8= g_utf16_to_utf8(utf16, -1, 0, 0, 0);
> Glib::ustring u(utf8); g_free(utf8);
> return u;
> }
>
> Which seems to work great like
> Glib::ustring u(w2ustring(L"üö"));
>
> But on linux with a unicode terminal,
>
> I can just set
> std::locale::global(std::locale("en_US.UTF-8"));
> Glib::ustring u(Glib::locale_to_utf8("üö"));
>
> And the code up there doesn't work (wchar_t is actually 4 bytes)
> And even the ucs4 output warnings and the resulting ustring is garbage
> or I get a segfault.
> So no utf16 to utf8 or ucs4 to utf8 conversions.
>
> Shall I use two separate codes for these platforms?
> Is there a unified solution?
Armin
___
gtkmm-list mailing list
gtkmm-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Gtk::Entry end editing signal
On Thu, 2008-01-03 at 11:52 +, Pedro Sousa wrote: > Hi everyone, > > In project I'm involved, I need to read data changed from a Gtk::Entry, > so I need to use signals in Gtk::Entry for the following events: > - When a user press ENTER button > - When the user selects another widgets Try signal_activate and signal_focus_out_event. For the latter you perhaps have to call add_events(Gdk::FOCUS_CHANGE_MASK) on the widget first. Armin > I tried to use the signal "signal_editing_done" derived from > Gtk::Widget, but with no lucky, because I can't trigger it. When is this > signal triggered? > > For the problem that I've, the best approach (until) now is to use the > "signal_changed" event, but this is not optimal. > > What solutions can I use for this problem? > > Thanks in advance > Pedro Sousa > ___ > gtkmm-list mailing list > gtkmm-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtkmm-list ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
goocanvasmm: Item::get_items_at API
I believe the current implementation of Item::get_items_at is wrong: #m4 _CONVERSION(`GList*',`Glib::ListHandle< Glib::RefPtr >',` $2($3, Glib::OWNERSHIP_NONE)') _WRAP_METHOD(Glib::ListHandle< Glib::RefPtr > get_items_at(double x, double y, const Cairo::RefPtr& context, bool is_pointer_event, bool parent_is_visible, Glib::ListHandle< Glib::RefPtr >& found_items), goo_canvas_item_get_items_at) Since the ownership of the returned ListHandle is set to NONE, the actual GList* will be leaked. However, if we set shallow ownership, then we get memory corruption because in the C API, the returned GList* is meant to be the same as the one passed in, with perhaps some items added to the front and thus returning a new list head. If I get it right, then the ownership of the found_items ListHandle needs to be set to none, and a new ListHandle with shallow ownership needs to be returned. We can't do this though, probably, because the ownership of the ListHandle is private. I think the C++ way to handle this is to use an insert iterator such as template InsertIter get_items_at(double x, double y, const Cairo::RefPtr& context, bool is_pointer_event, bool parent_is_visible, InsertIter iter); to be used like this: std::vector > items; some_item->get_items_at(..., std::inserter(items, items.end())); This is also more powerful because items can be inserted anywhere instead of just at the beginning. However, I don't think other *mm projects do anything similar, which is why I am asking for opinions first. The corresponding vfunc still needs special consideration then, since virtual functions cannot be templatized. Probably it is enough to just pass a specific container, such as std::vector, since the only code calling it is goocanvasmm itself anyway. Any opinions? Do you think it is OK to change it this way, or do you have other ideas to tackle this? Armin ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: goocanvasmm: Item::get_items_at API
On Tue, 2008-03-11 at 18:50 +0100, Murray Cumming wrote: > On Tue, 2008-03-11 at 17:19 +0100, Armin Burgmeier wrote: > > I believe the current implementation of Item::get_items_at is wrong: > > > > #m4 _CONVERSION(`GList*',`Glib::ListHandle< Glib::RefPtr >',` > > $2($3, Glib::OWNERSHIP_NONE)') > > > > _WRAP_METHOD(Glib::ListHandle< Glib::RefPtr > get_items_at(double > > x, double y, const Cairo::RefPtr& context, bool > > is_pointer_event, bool parent_is_visible, Glib::ListHandle< > > Glib::RefPtr >& found_items), goo_canvas_item_get_items_at) > > > > Since the ownership of the returned ListHandle is set to NONE, the > > actual GList* will be leaked. However, if we set shallow ownership, then > > we get memory corruption because in the C API, the returned GList* is > > meant to be the same as the one passed in, with perhaps some items added > > to the front and thus returning a new list head. > > Can we copy the GList* to avoid that problem? Hm, yes, I think so. It's obviously not as efficient, but it's probably better to stay consistent. > > If I get it right, then the ownership of the found_items ListHandle > > needs to be set to none, and a new ListHandle with shallow ownership > > needs to be returned. We can't do this though, probably, because the > > ownership of the ListHandle is private. > > > > I think the C++ way to handle this is to use an insert iterator such as > > > > template > > InsertIter get_items_at(double x, double y, const > > Cairo::RefPtr& context, bool is_pointer_event, bool > > parent_is_visible, InsertIter iter); > > > > to be used like this: > > > > std::vector > items; > > some_item->get_items_at(..., std::inserter(items, items.end())); > > > > This is also more powerful because items can be inserted anywhere > > instead of just at the beginning. However, I don't think other *mm > > projects do anything similar, which is why I am asking for opinions > > first. > > > > The corresponding vfunc still needs special consideration then, since > > virtual functions cannot be templatized. Probably it is enough to just > > pass a specific container, such as std::vector, since the only code > > calling it is goocanvasmm itself anyway. > > > > Any opinions? Do you think it is OK to change it this way, or do you > > have other ideas to tackle this? > > > > Armin > > > > ___ > > gtkmm-list mailing list > > gtkmm-list@gnome.org > > http://mail.gnome.org/mailman/listinfo/gtkmm-list ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: goocanvasmm: Item::get_items_at API
On Tue, 2008-03-11 at 12:56 -0500, Jonathon Jongsma wrote: > On 3/11/08, Armin Burgmeier <[EMAIL PROTECTED]> wrote: > > I believe the current implementation of Item::get_items_at is wrong: > > > > #m4 _CONVERSION(`GList*',`Glib::ListHandle< Glib::RefPtr >',` > > $2($3, Glib::OWNERSHIP_NONE)') > > > > _WRAP_METHOD(Glib::ListHandle< Glib::RefPtr > get_items_at(double > > x, double y, const Cairo::RefPtr& context, bool > > is_pointer_event, bool parent_is_visible, Glib::ListHandle< > > Glib::RefPtr >& found_items), goo_canvas_item_get_items_at) > > > > Since the ownership of the returned ListHandle is set to NONE, the > > actual GList* will be leaked. However, if we set shallow ownership, then > > we get memory corruption because in the C API, the returned GList* is > > meant to be the same as the one passed in, with perhaps some items added > > to the front and thus returning a new list head. > > > > If I get it right, then the ownership of the found_items ListHandle > > needs to be set to none, and a new ListHandle with shallow ownership > > needs to be returned. We can't do this though, probably, because the > > ownership of the ListHandle is private. > > > > I think the C++ way to handle this is to use an insert iterator such as > > > > template > > InsertIter get_items_at(double x, double y, const > > Cairo::RefPtr& context, bool is_pointer_event, bool > > parent_is_visible, InsertIter iter); > > > > to be used like this: > > > > std::vector > items; > > some_item->get_items_at(..., std::inserter(items, items.end())); > > > > This is also more powerful because items can be inserted anywhere > > instead of just at the beginning. However, I don't think other *mm > > projects do anything similar, which is why I am asking for opinions > > first. > > > > The corresponding vfunc still needs special consideration then, since > > virtual functions cannot be templatized. Probably it is enough to just > > pass a specific container, such as std::vector, since the only code > > calling it is goocanvasmm itself anyway. > > > > Any opinions? Do you think it is OK to change it this way, or do you > > have other ideas to tackle this? > > > > Armin > > I haven't had time to read this proposal thoroughly yet, but I just > wanted to mention that when I was wrapping this function originally, I > thought it felt like a pretty poor API at the C level. So maybe it > would be best to try to improve the API at the C level before > attempting workarounds in the wrapper. That said, I'll try to read > your proposal more thoroughly when I get a little more time and offer > comments as well. The C API is the same as the g_list_* API. g_list_prepend, g_list_sort etc. behave the same way, so it's probably convenient for C programmers this way. Armin ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Win32: Getting size of DLLs down for redist with app
On Thu, 2008-03-27 at 21:57 -0700, Paul Goins wrote: > Hello, > > This question may be newbie-ish, but oh well, here it goes. > I've nearly got my app in good enough shape to bundle up and release, but > here's the issue that's bugging me now: my DLL sizes for GTKmm and friends > are a tad large... > > $ ls -al *mm*.dll > -rwxr-xr-x1 Vultaire Administ 2324687 Mar 25 11:28 libatkmm-1.6-1.dll > -rwxr-xr-x1 Vultaire Administ 1670572 Mar 25 10:39 libcairomm-1.0-1.dll > -rwxr-xr-x1 Vultaire Administ 3597587 Mar 25 11:29 libgdkmm-2.4-1.dll > -rwxr-xr-x1 Vultaire Administ 4373851 Mar 25 10:30 libglibmm-2.4-1.dll > -rwxr-xr-x1 Vultaire Administ 1099662 Mar 25 10:29 > libglibmm_generate_extra_defs-2.4-1.dll > -rwxr-xr-x1 Vultaire Administ 35328804 Mar 25 11:29 libgtkmm-2.4-1.dll > -rwxr-xr-x1 Vultaire Administ 2420202 Mar 25 11:28 libpangomm-1.4-1.dll > > I'm seeing 48.4MB for these dlls. Is there any way to get this down in size, > barring a recompile of all this stuff with 'CXXFLAGS=-s -O2' or something > like that? > > I know MinGW has a strip tool which works nicely on executables, but running > "strip -g *.dll" or similar seems to cause nothing but issues. What do you mean by "causes nothing but issues"? I don't have any problems stripping DLLs (though I don't use the -g flag, and I don't know what it does). I only had problems stripping .dll.a files (import libraries) for which I need to pass the --strip-unneeded flag, otherwise strip renders them unusable (as in applications linking against them get undefined references for the symbols that should be defined in the import library). > > Thanks in advance. > > - Paul Goins Armin > ___ > gtkmm-list mailing list > gtkmm-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtkmm-list ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Win32: Getting size of DLLs down for redist with app
On Sun, 2008-03-30 at 00:37 +0900, Paul Goins wrote: > Armin Burgmeier wrote: > > What do you mean by "causes nothing but issues"? I don't have any > > problems stripping DLLs (though I don't use the -g flag, and I don't > > know what it does). > > Well, if I run a strip command against *.dll to get sizes down (which > includes other GTK-but-not-GTKmm dlls), I end up with crashes on > startup. Example: "The application failed to initialize properly > (0xc07b). Click on OK to terminate the application." Ah. I remember having had similar problems when trying to strip DLLs not compiled with mingw (or at least this is what I assumed the problem was). > I just tried running the command against *mm*.dll instead, and that > -seems- to work and the app does start. However, if running strip on > the other DLLs causes problems like that, then it makes me a little > nervous "hoping" that things are gonna work right by running it on only > a few DLLs. Probably it's just my paranoia/lack of experience talking > though. > > By the way, the -g flag is specifically for stripping debug symbols. > > Thanks. > > - Paul Goins Armin ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: How does 'on_key_press_event' work in 'Gtk::Entry' ?
On Sun, 2008-03-30 at 13:36 +0200, Søren Hauberg wrote:
> Hi All,
> I'm new to GUI programming in general and specifically GTKmm, so
> bare with me...
> I'm experimenting with Gtk::Entry, and I would like the following behaviour
>
> If the user presses TAB, UP, or DOWN, print the key name to stdout.
> Otherwise act as normal, that is, show the key in the text entry.
>
> Should be simple. So my widget 'GUI_input' inherits from Gtk::Entry,
> and implements the following the 'on_key_press_event' function as
> follows:
>
> bool GUI_input::on_key_press_event (GdkEventKey* event)
> {
> bool handled = false;
> switch (event->keyval)
> {
> case GDK_Tab:
> std::cout << "TAB: " << std::endl;
> handled = true;
> break;
> case GDK_Up:
> std::cout << "UP: " << std::endl;
> handled = true;
> break;
> case GDK_Down:
> std::cout << "Down: " << std::endl;
> handled = true;
> break;
> }
>
> return handled;
> }
>
> This behaves as follows:
>
> If the user presses TAB, UP, or DOWN, print the key name to stdout.
>Otherwise don't show anything in the text entry.
>
> Can anybody give me a hint as to what I should do?
Call the Gtk::Entry's parent function if you didn't handle the event,
via 'return Gtk::Entry::on_key_press_event(event);'.
> Thanks,
> Søren
Armin
> P.S. And thanks for creating such a nice library. In general things
> are very intuitve.
> ___
> gtkmm-list mailing list
> gtkmm-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gtkmm-list
___
gtkmm-list mailing list
gtkmm-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: ComboBox/ComboBoxEntry don't inherit from CellEditable
On Thu, 2008-04-24 at 23:27 -0400, Karthik Ganesan wrote:
> Hi,
> Shouldn't ComboBox/ComboBoxEntry inherit from CellEditable : The
> following program verifies it (dynamic casting to CellEditable returns
> NULL pointers).
It should, but this would break ABI. GtkComboBox implements
GtkCellEditable since GTK+ 2.6, and we cannot add the new base class
without breaking ABI.
> I was trying to grab the combo box instance used by CellRendererCombo in
> the editing_started signal and get a NULL pointer. Any workarounds?
You can bind the ComboBox to the signal handler, like
void editing_started(Gtk::CellEditable* editable, const Glib::ustring&
path, Gtk::ComboBox& box) { ... }
crc.signal_editing_started().connect(sigc::bind(sigc::ptr_fun(&editing_started),
sigc::ref(cb)));
Armin
___
gtkmm-list mailing list
gtkmm-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: finding original cell background color in TreeView renderer
On Tue, 2008-04-29 at 08:49 -0500, Joaquim Schmidlap wrote: > I have a TreeView. Each column has a custom rendering callback > function, which I use to change the color and formatting of the text > in each cell as the data changes. > > Under certain data conditions, I change the background color of the > cell to be red, to get the user's attention. I do this with > Gtk::CellRendererText::property_background_gdk() and it works great. > > When the error condition clears, I need to set the color back to the > default, since using properties like this seems to be "sticky." In > other words, that cell will stay red until I change it. The problem I > have now is that when I have set_rules_hint(true) for the TreeView, I > need to figure out what color this cell should be based on the > alternating row colors. > > Is there a way to query the TreeView for what a given row's > background color "should" be based on the hints? Clearly, it must be > down in the implementation somewhere, but is this interface exposed > to us? > > I know I could query the background of some other cell in the row > that didn't change, or maybe stuff the color in the model somewhere, > but that feels a little funky to me. Seems like the TreeView must > know if a given row is odd or even, and therefore what the color > should be. I guess setting property_background_set() to false in the CellRenderer should do the trick. Armin ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
cluttermm: Branch before wrapping 0.7/0.8 API?
I intent to wrap new clutter API in cluttermm. The 0.7 version of clutter is not API stable with 0.6, though, meaning we need to change cluttermm API as well. Should I do this in another branch, or should I branch the current trunk before, or can this go into trunk without branching? Thanks, Armin ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: a TreeModel that's sortable and filterable?
On Fri, 2008-06-13 at 18:13 -0500, Joaquim Schmidlap wrote: > It looks like TreeModelFilter and TreeModelSort are separate > derivations from TreeModel...pity. TreeModelFilter and TreeModelSort have child models. So, if you have some TreeModel A, and you want it sorted, then create a TreeModelSort with A as child. If you want it both sorted and filtered, then create a TreeModelFilter with a TreeModelSort as child (or vice versa). Note that Gtk::ListStore and Gtk::TreeStore already support sorting (since they implement Gtk::TreeSortable), so you don't even need Gtk::TreeModelSort for them (unless you want to do things like showing a sorted and an unsorted model in different views). > If I wanted a TreeModel to be sortable and filterable, what's the > best way forward? I assume I'd have to pick one and add the > functionality of the other myself, or perhaps do something with > multiple inheritance. What is recommended here? What's easiest? > > And, I realize this calls for speculation, but can anyone say why > this design decision was made? Seems like what I want to do would be > relatively common. Armin ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
ANNOUNCE: cluttermm 0.7.0
cluttermm provides a C++ API for Clutter (a 3D canvas and items), for use with gtkmm. It is usable, and we'd like to hear about any problems or about anything that is missing. Changes: 0.7.0: * Update to new clutter-0.7 API (Armin Burgmeier, Openismus) * Wrap several remaining classes, methods, signals, properties and free functions. Coverage is still not 100%, but not much is missing. (Armin Burgmeier, Openismus) Bugs fixed: 536180 examples/actor.png not part of tarball (Denis Leroy) 536181 API_VER not used in pkgconfig files (Denis Leroy) Details: We should really put this on a web page: svn: svn.gnome.org/gnomemm/cluttermm/trunk/ http://svn.gnome.org/viewvc/gnomemm/cluttermm/trunk/ (It's in jhbuild) download: http://ftp.gnome.org/pub/GNOME/sources/cluttermm/ submit bugs: http://bugzilla.gnome.org/enter_bug.cgi?product=gnomemm&component=cluttermm view bugs: http://bugzilla.gnome.org/buglist.cgi?query=component%3Acluttermm +product%3Agnomemm+ ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Gtkmm Windows Maintainership
Hi Cedric, I would like to experiment with building gtkmm and companion libraries on Windows with mingw and MSVC, to eventually take over maintainership of the Windows installer at least temporarily and/or partially. In a mail from April 2008 [1], you proposed to put the installer script into SVN. Did this happen in the meanwhile? If not, could you please make it available somewhere, so I can play around with it? I would then also create some documentation as I go. Thanks, Armin [1] http://mail.gnome.org/archives/gtkmm-list/2008-April/msg00020.html ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Gtkmm Windows Maintainership
On Tue, 2008-07-15 at 23:12 +0200, Jens Georg wrote: > Hi Armin, > > > Hi Cedric, > > > > I would like to experiment with building gtkmm and companion libraries > > on Windows with mingw and MSVC, to eventually take over maintainership > > of the Windows installer at least temporarily and/or partially. In a > > mail from April 2008 [1], you proposed to put the installer script into > > SVN. Did this happen in the meanwhile? If not, could you please make it > > available somewhere, so I can play around with it? > > > > I would then also create some documentation as I go. > > I made libsigc++ and libcairomm compile with msvc 9, working on the rest > ;) If you need a hand, just raise yours. You should maybe add the project files into the subversion repositories, so that it is easy for others to build the libraries using the same compiler. > Regards, Jens Armin ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Glib::spawn on Windows
On Tue, 2008-08-26 at 10:30 -0300, Paulo Flabiano Smorigo wrote:
> Hi everybody,
>
> I'm trying to execute a program in my application using the Glib
> Spawning Proccess library.
> On linux works perfect but on windows I get a "No such file or
> directory" error.
>
> The command is:
> Glib::spawn_command_line_async("c:\\windows\\NOTEPAD.EXE");
>
> And the error on Windows is:
> (player.exe:1568): glibmm-CRITICAL **:
> unhandled exception (type Glib::Error) in signal handler:
> domain: g-exec-error-quark
> code : 19
> what : Failed on execute an auxiliary program (No such file or
> directory)
Asynchronous spawning needs a helper program on Windows, called
gspawn-win32-helper.exe. This is not found on your system. Where did you
install glib from? It should be included in the official glib binary
packages from ftp.gnome.org.
> Thanks in advance...
> P.F.Smorigo
Armin
> ___
> gtkmm-list mailing list
> gtkmm-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gtkmm-list
___
gtkmm-list mailing list
gtkmm-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Glib::spawn on Windows
On Tue, 2008-08-26 at 11:26 -0300, Paulo Flabiano Smorigo wrote:
> Hi Armin,
>
> Thanks for the reply. To execute my application on Windows I just
> installed gtk and gtk runtime.
>
> Where is this gspawn-win32-helper? Where do I find the installer?
I had a look at that installer, and it seems to install
gspawn-win32-helper.exe, but not gspawn-win32-helper-console.exe. I
don't know exactly which one glib uses in which case, but you could try
adding the latter from
ftp://ftp.gnome.org/pub/GNOME/binaries/win32/glib/2.16/glib-2.16.5.zip
to the same place where your glib DLL is.
> I install gtk and gtkmm from this two links:
> http://ufpr.dl.sourceforge.net/sourceforge/gladewin32/gtk-2.12.9-win32-2.exe
> http://ftp.acc.umu.se/pub/gnome/binaries/win32/gtkmm/2.10/gtkmm-win32-runtime-2.10.11-1.exe
>
> Thanks again,
> Paulo Flabiano Smorigo
Armin
> On Tue, Aug 26, 2008 at 11:11, Armin Burgmeier <[EMAIL PROTECTED]>
> wrote:
>
> On Tue, 2008-08-26 at 10:30 -0300, Paulo Flabiano Smorigo
> wrote:
> > Hi everybody,
> >
> > I'm trying to execute a program in my application using the
> Glib
> > Spawning Proccess library.
> > On linux works perfect but on windows I get a "No such file
> or
> > directory" error.
> >
> > The command is:
> > Glib::spawn_command_line_async("c:\\windows\\NOTEPAD.EXE");
> >
> > And the error on Windows is:
> > (player.exe:1568): glibmm-CRITICAL **:
> > unhandled exception (type Glib::Error) in signal handler:
> > domain: g-exec-error-quark
> > code : 19
> > what : Failed on execute an auxiliary program (No such file
> or
> > directory)
>
>
> Asynchronous spawning needs a helper program on Windows,
> called
> gspawn-win32-helper.exe. This is not found on your system.
> Where did you
> install glib from? It should be included in the official glib
> binary
> packages from ftp.gnome.org.
>
> > Thanks in advance...
> > P.F.Smorigo
>
>
> Armin
>
> > ___
> > gtkmm-list mailing list
> > gtkmm-list@gnome.org
> > http://mail.gnome.org/mailman/listinfo/gtkmm-list
>
>
>
___
gtkmm-list mailing list
gtkmm-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Glib::spawn on Windows
On Thu, 2008-08-28 at 10:07 +0200, Murray Cumming wrote: > On Wed, 2008-08-27 at 14:42 -0300, Paulo Flabiano Smorigo wrote: > > Thanks Armin!! > > I extract the glib and now works... > > If there is a problem with some installer, could one of you please make > sure that the bug is reported properly. I reported a bug: http://sourceforge.net/tracker/index.php?func=detail&aid=2080251&group_id=98754&atid=621930 Armin ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: gtkmm affected by recent changes to gtk (GdkNativeWindow, gtk_toolbar_[gs]et_tooltips)
On Tue, 2008-09-16 at 08:03 -0400, Damon Register wrote: > Murray Cumming wrote: > > Are you showing us the problem or the solution? Could you please be > > clearer about what the problem is. And if you have a solution, could you > Both, I thought... I thought it was reasonably clear but I will > attempt to present differently. > > So far I have run into two problems. The first is the GdkNativeWindow > problem. I found two functions in display.cc that gave compile errors. > These functions are > Display::selection_send_notify > Display::get_drag_protocol > They appear to be simple wrapper functions for the C versions. > I changed the parameters and return type of the C++ to match the > C. For this I was just wanting a peer review. Does what I did > seem to be the correct thing to do? I can reproduce the problems you mention when compiling gtkmm against GTK+ 2.14. I filed a bug for this: http://bugzilla.gnome.org/show_bug.cgi?id=552513. In short, I think the problem with changing the types appropriately is ABI compatibility. Feel free to attach your patch there even if it has some problems yet. It is easier to discuss such things on bugzilla. > > submit it as a patch, please? > If the answer to the above question is yes, then I will submit a > patch > > > However, I know that Armin has almost finished the new gtkmm Windows > > installer, so maybe this has already been fixed anyway. > Though the GdkNativeWindow change to gtk seems to be driven by the > Windows platform, isn't it reasonable to expect that the types in > the C++ wrapper should match the C regardless of the platform? > > >> The second tooltip problem seems to be addressed by this one. > >> http://mail.gnome.org/archives/svn-commits-list/2008-July/msg00245.html > I get a compile error related to this one too but I don't understand > until I looked at it again last night. I think I solved this one too. > In the file gtkmm-2.12.7\gtk\gtkmm\toolbar.cc (and .h) there are two > functions, set_tooltips and get_tooltips. Their gtk versions > are wrapped with #ifndef GTK_DISABLE_DEPRECATED and it seems that the] > all-in-one gtk package has that defined so, when gtkmm compiles, > the compile fails because the two gtkmm functions are wrapping > gtk functions that are disabled. > > I solved the tooltip problem by doing two things > > 1. add #ifndef GTKMM_DISABLE_DEPRECATED before functions > set_tooltips and get_tooltips > > 2. add --enable-deprecated-api=no to configure options > > Do my analysis and solution for the tooltip problem appear correct? The problem is not the all-in-one GTK+ package, but these few lines at the top of toolbar.ccg: //Define this to make sure that we don't use any of the deprecated GtkToolbar API. //Normally we just deprecate it in gtkmm too, //but the GtkToolbar compatibility system is particularly unpleasant, so we just removed it in gtkmm 2.4. murrayc. //In future, this GTK_DISABLE_DEPRECATED might be inappropriate because it might cover extra GTK+ API. Just remove it then. #define GTK_DISABLE_DEPRECATED This has already been fixed in gtkmm 2.13.8, though. > Damon Register > > ___ > gtkmm-list mailing list > gtkmm-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtkmm-list Armin ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: gtkmm affected by recent changes to gtk (GdkNativeWindow, gtk_toolbar_[gs]et_tooltips)
On Tue, 2008-09-16 at 14:37 -0400, Damon Register wrote: > Armin Burgmeier wrote: > > I can reproduce the problems you mention when compiling gtkmm against > > GTK+ 2.14. > I feel a little better > > > I filed a bug for this: > > http://bugzilla.gnome.org/show_bug.cgi?id=552513. In short, I think the > Thanks > > > problem with changing the types appropriately is ABI compatibility. Feel > > free to attach your patch there even if it has some problems yet. It is > > easier to discuss such things on bugzilla. > Ok. I assume that when you talk of ABI compatibility, you are > talking about the problems you get when running a program built with > one type while using a library built with another type? gtkmm is ABI stable, which means that it must be possible to compile a program against gtkmm 2.12 and run it with gtkmm 2.14. So if we change the signature of a function to have different parameters, then the function will not be found anymore by a program linked against the older version, and it will refuse to run. Armin ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: gtkmm affected by recent changes to gtk (GdkNativeWindow, gtk_toolbar_[gs]et_tooltips)
On Thu, 2008-09-18 at 17:20 -0400, Damon Register wrote:
> Armin Burgmeier wrote:
> > gtkmm is ABI stable, which means that it must be possible to compile a
> > program against gtkmm 2.12 and run it with gtkmm 2.14. So if we change
> > the signature of a function to have different parameters, then the
> > function will not be found anymore by a program linked against the older
> > version, and it will refuse to run.
> Now I understand more clearly. Thanks for explaining that. Perhaps
> overloading is a better solution? What is the best way to handle the
> gtk problem? I could put ifdefs into the gtkmm Toolbar::get_tooltips_object()
> to handle this gtktoolbar.h problem
>
> struct _GtkToolbar
> {
>
> #ifndef GTK_DISABLE_DEPRECATED
>GtkTooltips *GSEAL (tooltips);
> #else
>gpointer GSEAL (_tooltips);
> #endif
>
> };
>
> but wouldn't that be bad to have gtk defs mixed in with the gtkmm or is
> that normal? I can understand why someone might want to change a data
> type but why the member name? Is that for program readability, so it
> is easier to tell which type is being used? Wouldn't it make more
> sense to have a typedef in gtk for tooltips so then it just uses the
> typedef? Perhaps like this?
>
> #ifndef GTK_DISABLE_DEPRECATED
>typedef GtkTooltips* GtkTooltips_type;
> #else
>typedef gpointer GtkTooltips_type;
> #endif
>
>
> struct _GtkToolbar
> {
>GtkTooltips_type GSEAL (tooltips);
> };
>
>
> Looking at my own idea, I am not sure if this would have that binary
> backward compatibility problem you mentioned :-(
> What do you think?
Again, this problem has been fixed already in recent gtkmm versions. The
Toolbar::get_tooltips_object returns simply 0 now. See
http://svn.gnome.org/viewvc/gtkmm/trunk/gtk/src/toolbar.ccg?view=markup.
The simplest thing for you to do would probably be to use a recent
enough gtkmm tarball, from
http://ftp.gnome.org/pub/GNOME/sources/gtkmm/2.13/.
> Damon Register
Armin
___
gtkmm-list mailing list
gtkmm-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Errors building gtkmm 2.12.7 with Visual Studio 2008 (Visual C++ 9.0, vc9)
On Fri, 2008-09-19 at 14:07 +0200, "André Heynatz" wrote: > Hi all, > > I have tried to build gtkmm with MS Visual C++ 9.0 (vc9, Visual Studio 2008). > I am using the Visual Studio 2008 Team System Development Edition (behavior > similar to the Standard Edition or better for this purpose), but without > success! There were several smaller problems until I have come to this stage. > It should build out of the box (no errors, no warnings). > > There are errors during linking phase when building the gtkmm-2.4 project: > > -- Build started: Project: gtkmm-2.4, Configuration: Release Win32 -- > Generate gtkmm def file > Microsoft (R) COFF/PE Dumper Version 9.00.21022.08 > Copyright (C) Microsoft Corporation. All rights reserved. > dumpbin /SYMBOLS /OUT:dumpbin.out Release\*.obj > Linking... >Creating library Release\gtkmm-2.4.lib and object Release\gtkmm-2.4.exp > widget.obj : error LNK2019: unresolved external symbol "class > Glib::RefPtr __cdecl Glib::wrap(struct _GtkTooltip > *,bool)" ([EMAIL PROTECTED]@@[EMAIL PROTECTED]@Gtk@@@[EMAIL > PROTECTED]@@[EMAIL PROTECTED]) referenced in function "int __cdecl `anonymous > namespace'::Widget_signal_query_tooltip_callback(struct _GtkWidget > *,int,int,int,struct _GtkTooltip *,void *)" ([EMAIL > PROTECTED]@@YAHPAU_GtkWidget@@HHHPAU_GtkTooltip@@[EMAIL PROTECTED]) > wrap_init.obj : error LNK2019: unresolved external symbol "public: static > unsigned long __cdecl Gtk::VolumeButton::get_type(void)" ([EMAIL > PROTECTED]@Gtk@@SAKXZ) referenced in function "void __cdecl > Gtk::wrap_init(void)" ([EMAIL PROTECTED]@@YAXXZ) > wrap_init.obj : error LNK2019: unresolved external symbol "public: static > unsigned long __cdecl Gtk::Tooltip::get_type(void)" ([EMAIL > PROTECTED]@Gtk@@SAKXZ) referenced in function "void __cdecl > Gtk::wrap_init(void)" ([EMAIL PROTECTED]@@YAXXZ) > wrap_init.obj : error LNK2019: unresolved external symbol "public: static > unsigned long __cdecl Gtk::ScaleButton::get_type(void)" ([EMAIL > PROTECTED]@Gtk@@SAKXZ) referenced in function "void __cdecl > Gtk::wrap_init(void)" ([EMAIL PROTECTED]@@YAXXZ) > wrap_init.obj : error LNK2019: unresolved external symbol "public: static > unsigned long __cdecl Gtk::RecentAction::get_type(void)" ([EMAIL > PROTECTED]@Gtk@@SAKXZ) referenced in function "void __cdecl > Gtk::wrap_init(void)" ([EMAIL PROTECTED]@@YAXXZ) > wrap_init.obj : error LNK2019: unresolved external symbol "public: static > unsigned long __cdecl Gtk::Builder::get_type(void)" ([EMAIL > PROTECTED]@Gtk@@SAKXZ) referenced in function "void __cdecl > Gtk::wrap_init(void)" ([EMAIL PROTECTED]@@YAXXZ) > wrap_init.obj : error LNK2019: unresolved external symbol "public: static > class Glib::ObjectBase * __cdecl Gtk::VolumeButton_Class::wrap_new(struct > _GObject *)" ([EMAIL PROTECTED]@Gtk@@[EMAIL PROTECTED]@@PAU_GObject@@@Z) > referenced in function "void __cdecl Gtk::wrap_init(void)" ([EMAIL > PROTECTED]@@YAXXZ) > wrap_init.obj : error LNK2019: unresolved external symbol "public: static > class Glib::ObjectBase * __cdecl Gtk::Tooltip_Class::wrap_new(struct _GObject > *)" ([EMAIL PROTECTED]@Gtk@@[EMAIL PROTECTED]@@PAU_GObject@@@Z) referenced in > function "void __cdecl Gtk::wrap_init(void)" ([EMAIL PROTECTED]@@YAXXZ) > wrap_init.obj : error LNK2019: unresolved external symbol "public: static > class Glib::ObjectBase * __cdecl Gtk::ScaleButton_Class::wrap_new(struct > _GObject *)" ([EMAIL PROTECTED]@Gtk@@[EMAIL PROTECTED]@@PAU_GObject@@@Z) > referenced in function "void __cdecl Gtk::wrap_init(void)" ([EMAIL > PROTECTED]@@YAXXZ) > wrap_init.obj : error LNK2019: unresolved external symbol "public: static > class Glib::ObjectBase * __cdecl Gtk::RecentAction_Class::wrap_new(struct > _GObject *)" ([EMAIL PROTECTED]@Gtk@@[EMAIL PROTECTED]@@PAU_GObject@@@Z) > referenced in function "void __cdecl Gtk::wrap_init(void)" ([EMAIL > PROTECTED]@@YAXXZ) > wrap_init.obj : error LNK2019: unresolved external symbol "public: static > class Glib::ObjectBase * __cdecl Gtk::Builder_Class::wrap_new(struct _GObject > *)" ([EMAIL PROTECTED]@Gtk@@[EMAIL PROTECTED]@@PAU_GObject@@@Z) referenced in > function "void __cdecl Gtk::wrap_init(void)" ([EMAIL PROTECTED]@@YAXXZ) > wrap_init.obj : error LNK2019: unresolved external symbol "private: static > void __cdecl Gtk::BuilderError::throw_func(struct _GError *)" ([EMAIL > PROTECTED]@Gtk@@CAXPAU_GError@@@Z) referenced in function "void __cdecl > Gtk::wrap_init(void)" ([EMAIL PROTECTED]@@YAXXZ) > Release\gtkmm-2.4.dll : fatal error LNK1120: 12 unresolved externals > Build log was saved at > "file://g:\cots\gtk\gtkmm-2.12.7\MSVC_Net2003\gtkmm\Release\BuildLog.htm" > gtkmm-2.4 - 13 error(s), 0 warning(s) > == Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped == > > It does not help to use Service Pack 1, the same error messages appear. > > I have used the following components: > > from gladewin32 (http://sourceforge.net/projects/gladewin32) > gtk-dev-2.12.9-win32-2.
Gtkmm Windows installers available
Dear gtkmm users, Official All-in-One Windows installers (runtime and development versions) for gtkmm are available again: http://ftp.gnome.org/pub/GNOME/binaries/win32/gtkmm They contain all files required to build applications using gtkmm with MinGW or MSVC++, including GTK+ binaries. More information is available at http://live.gnome.org/gtkmm/MSWindows. Feel free to ask if you have any problems with them. Suggestions are welcome as well. Thanks go to Murray Cumming and Cédric Gustin for their help that allowed me to create the installers. Armin ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: unresolved external symbol _gdk_win32_drawable_get_handle
On Thu, 2008-09-25 at 16:04 -0300, Paulo Flabiano Smorigo wrote:
> Hi everybody,
>
> I'm getting the "unresolved external symbol
> _gdk_win32_drawable_get_handle" error when compile my application on
> windows... :'(
>
> The code:
> Glib::RefPtr _winVideo = m_drwVideo.get_window();
> *p_windowID = (int)GDK_WINDOW_HWND(_winVideo->gobj());
I guess you are compiling with MinGW, right? What version of GTK+ do you
compile against, and what command do you use to compile?
I can compile this code:
#include
#include
int main()
{
Gtk::VBox wdg;
Glib::RefPtr window = wdg.get_window();
int foo = (int)GDK_WINDOW_HWND(window->gobj());
}
without problems against gtkmm 2.14.1 and GTK+ 2.14.3, using
g++ bla.cpp -o bla `pkg-config --cflags --libs gtkmm-2.4`
from msys.
(Note that that code doesn't make any sense, but it uses the same
functions as your code, and it compiles flawlessly).
By the way, it is not portable to store a HWND (which is a pointer,
actually) into an integer. This will probably fail on 64 bit Windows.
But this has nothing to do with your linker problem.
> Thanks...
> Paulo Flabiano Smorigo
Armin
___
gtkmm-list mailing list
gtkmm-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Gtkmm Windows installers available
lude\gtkmm-2.4\gtkmm\filechooser.h|641|error: template > argument 1 is invalid| > D:\XWin\include\gtkmm-2.4\gtkmm\filechooser.h|641|error: ISO C++ forbids > declaration of `get_file' with no type| > D:\XWin\include\gtkmm-2.4\gtkmm\filechooser.h|643|error: `Gio' has not > been declared| > D:\XWin\include\gtkmm-2.4\gtkmm\filechooser.h|643|error: ISO C++ forbids > declaration of `type name' with no type| > D:\XWin\include\gtkmm-2.4\gtkmm\filechooser.h|643|error: template > argument 1 is invalid| > D:\XWin\include\gtkmm-2.4\gtkmm\filechooser.h|643|error: ISO C++ forbids > declaration of `get_file' with no type| > D:\XWin\include\gtkmm-2.4\gtkmm\filechooser.h|744|error: `Gio' has not > been declared| > D:\XWin\include\gtkmm-2.4\gtkmm\filechooser.h|744|error: `File' was not > declared in this scope| > D:\XWin\include\gtkmm-2.4\gtkmm\filechooser.h|744|error: template > argument 1 is invalid| > ||More errors follow but not being shown.| > ||Edit the max errors limit in compiler options...| > ||=== Build finished: 50 errors, 0 warnings ===| Ugh. Seems like the giomm header files are missing in the installer. I created another one, including them: ftp://ftp.gnome.org/pub/GNOME/binaries/win32/gtkmm/2.14/gtkmm-win32-devel-2.14.1-2.exe Thanks, Armin > Armin Burgmeier wrote: > > Dear gtkmm users, > > > > Official All-in-One Windows installers (runtime and development > > versions) for gtkmm are available again: > > http://ftp.gnome.org/pub/GNOME/binaries/win32/gtkmm > > > > They contain all files required to build applications using gtkmm with > > MinGW or MSVC++, including GTK+ binaries. More information is available > > at http://live.gnome.org/gtkmm/MSWindows. > > > > Feel free to ask if you have any problems with them. Suggestions are > > welcome as well. > > > > Thanks go to Murray Cumming and Cédric Gustin for their help that > > allowed me to create the installers. > > > > Armin > > > ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: spawn_async_with_pipes on windows using mingw (code atached)
On Fri, 2008-09-26 at 17:59 -0300, Paulo Flabiano Smorigo wrote:
> Hi everybody,
>
> I'm still trying to compile spawn_async_with_pipes on windows. Now I
> created a little source that can help to solve the problem.
>
> I use the following command to compile (using gtkmm for windows
> libraries):
> i586-mingw32msvc-g++ Player.cpp `pkg-config --cflags --libs gtkmm-2.4`
> -o app.exe
>
> The code:
> #include
> #include
> #include
>
> class Player : public Gtk::Window
> {
> public:
> Player();
> virtual ~Player();
> };
>
> Player::Player()
> {
> int _pid = 0;
> int _stdin = 0;
> int _stdout = 0;
> int _stderr = 0;
>
> char *vec[5];
> vec[0] = "\"c:/mplayer/mplayer.exe\"";
> vec[1] = "\"-quiet\"";
> vec[2] = "\"-slave\"";
> vec[3] = "\"-idle\"";
> vec[4] = "\"c:/mplayer/truthhappens.ogg\"";
>
> Glib::spawn_async_with_pipes("\"c:/\"", (char**) vec,
> Glib::SpawnFlags(0), sigc::slot(), &_pid, &_stdin, &_stdout,
> &_stderr);
>
> std::cout << "PID:" << _pid << std::endl;
> std::cout << "STDIN: " << _stdin << std::endl;
> std::cout << "STDOUT: " << _stdout << std::endl;
> std::cout << "STDERR: " << _stderr << std::endl;
> show_all_children();
> }
>
> Player::~Player()
> {
> }
>
> int main(int argc, char *argv[])
> {
> Gtk::Main kit(argc, argv);
> Player player;
> Gtk::Main::run(player);
>
> return 0;
> }
>
>
> And the error:
> Player.cpp: In constructor `Player::Player()':
> Player.cpp:26: error: no matching function for call to
> `spawn_async_with_pipes(const char[6], char**, Glib::SpawnFlags,
> sigc::slot sigc::nil, sigc::nil, sigc::nil>, int*, int*, int*, int*)'
> /opt/gtk28win/include/glibmm-2.4/glibmm/spawn.h:147: note: candidates
> are: void Glib::spawn_async_with_pipes(const std::string&, const
> Glib::ArrayHandle Glib::Container_Helpers::TypeTraits >&, const
> Glib::ArrayHandle Glib::Container_Helpers::TypeTraits >&, Glib::SpawnFlags,
> const sigc::slot sigc::nil, sigc::nil, sigc::nil>&, void**, int*, int*, int*)
> /opt/gtk28win/include/glibmm-2.4/glibmm/spawn.h:156: note:
> void Glib::spawn_async_with_pipes(const std::string&, const
> Glib::ArrayHandle Glib::Container_Helpers::TypeTraits >&, Glib::SpawnFlags,
> const sigc::slot sigc::nil, sigc::nil, sigc::nil>&, void**, int*, int*, int*)
>
>
> Thanks in advance for the help...
PIDs are not simply integers on Windows, but pointers in fact (a HANDLE
for the created process). Glib provides the type Glib::Pid which should
be used for PIDs. This is an integer on linux, and a pointer on Windows.
So, try changing the type of _pid from int to Glib::Pid.
Furthermore, I don't think you can pass a simple C array as a
Glib::ArrayHandle to the spawn function (it would not know how many
entries there are in the array). Try using an STL container, such as
std::vector, instead:
Replace char *vec[5] by std::vector vec(5)
> Paulo Flabiano Smorigo
Armin
> ___
> gtkmm-list mailing list
> gtkmm-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gtkmm-list
___
gtkmm-list mailing list
gtkmm-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Troubles with signal_child_watch
On Sat, 2008-09-27 at 23:42 +0200, Fernando Tarín wrote:
> Hi I'm using the next code to launch a new process but the
> finished_process function is never executed, can someone help me with
> this issue?
You don't run a mainloop. All timeout handlers, idle handlers and child
watches are called from the glib mainloop. If you expect the child watch
to be called within the five seconds your code currently sleeps, maybe
try:
bool on_timeout(const Glib::RefPtr& loop)
{ loop->quit(); return false; }
[...]
Glib::RefPtr loop(Glib::MainLoop::create());
Glib::signal_timeout().connect(sigc::bind(sigc::ptr_fun(&on_timeout),
loop), 5000);
loop->run();
> #include
> #include
>
> #include
>
> void finished_process(int pid, int ret)
> {
> std::cout << "Process finished: " << pid << "|" << ret <<
> std::endl;
> }
>
> int main()
> {
> int stdout_fd, pid;
> Glib::ustring line;
> std::vector command;
>
> command.push_back("ls");
>
> try{
> Glib::spawn_async_with_pipes(".", command,
> Glib::SPAWN_SEARCH_PATH, sigc::slot(),
> &pid, NULL, &stdout_fd, NULL);
> }
> catch(Glib::SpawnError &e){
> std::cout << "Error: " << e.what() << std::endl;
> return 0;
> }
>
>
> Glib::signal_child_watch().connect(sigc::ptr_fun(finished_process),
>pid);
>
> Glib::RefPtr io =
> Glib::IOChannel::create_from_fd(stdout_fd);
>
> sleep(5);
>
> while (io->read_line(line) != Glib::IO_STATUS_EOF)
> std::cout << line;
>
> io->close();
> close(stdout_fd);
> std::cout << "Exit" << std::endl;
> }
Armin
___
gtkmm-list mailing list
gtkmm-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: gtkmm with VS2005 vd2 option
On Wed, 2008-10-01 at 15:56 +0200, Stefani Leonardo wrote:
> I am trying to compile an gtkmm 2.12 program with /vd2 option
>
> This C++ sample, compiled with /vd2 option on Visual Studio C++ 2005,
>
> // cl /vd2 /Zi /MDd r.cpp
> #include
> int main()
> {
> std::stringstream *s = new std::stringstream;
> delete s;
> }
>
> crashes. (Note no GTKmm is linked).
I'm not sure what the problem is, but using /MTd (Multi Threaded Debug)
instead of /MDd (Multi-Threaded Debug DLL) works for me with your
example.
> What C++ libraries can I use ?
> /vd2 is mandatory on gtkmm programs?
>
> Thanks
Armin
> ___
> gtkmm-list mailing list
> gtkmm-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gtkmm-list
___
gtkmm-list mailing list
gtkmm-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Gtkmm Windows installers available
On Thu, 2008-10-02 at 18:49 -0400, Philip Kovacs wrote: > On the "Building gtkmm on Windows" web page I note the statement: > > "We suggest that you use MSYS to build gtkmm on Windows." > > This statement can only be be interpreted as: This is meant as: "If you want to build gtkmm with MinGW, then we recommend using MSYS to do so", since it is in the "Using MinGW" section. I made it more clear on the Wiki page. > "We suggest that you build your project, gtkmm and another other C++ libraries > you intend to build from source with MSYS." > > Building any C++ project component with MINGW/MSYS means a total commitment > to that environment/build system for all C++ project components. C++ projects > and the libraries that they use must be built with the same compiler, due to > name mangling, exception handling, stack issues, etc. > > "The MSVC++ DLLs have been built with Visual C++ 2005." > > is fine, but better would be: > > "The MSVC++ DLLs have been built with Visual C++ 2005 and are linked to the > MS C/C++ runtime DLLs: MSVCR80.DLL / MSVCP80.DLL." It's a Wiki. Feel free to improve things yourself. > In my case, my Windows system has a later runtime environment: MSVCR90.DLL / > MSVCP90.DLL (MS Visual Studio 2008), so I have to recompile anyway. I think > cautioning people to verify which MS C/C++ runtime they have: 70/80/90, etc. > before using the binary installer would be a good thing. I don't have too much experience with different runtimes, but I succeeded in building a small example application with Visual Studio 2008 against the binaries of the installer, which have been built with Visual Studio 2005. Doesn't this work in general? I think the MSVCR80 runtime files are still shipped with Visual Studio 2008. > Anyway, I have built each of: gtkmm/glibmm/sigc++/cairomm sucessfully with > MS VC++ 2008. I just wish there were a way to automate the installation of > the development files to a target path from that gtkmm source tree. If that's indeed a problem, then we probably need to ship separate files for both Visual Studio 2005 (linked against *80.DLL) and 2008 (linked against *90.DLL). > Phil > > ___ > gtkmm-list mailing list > gtkmm-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtkmm-list ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: gtkmm with VS2005 vd2 option
On Fri, 2008-10-03 at 18:21 +0200, Stotz Urs (ENT) wrote: > On Wed, Oct 01, 2008 at 03:56:35PM +0200, Stefani Leonardo wrote: > > > > I am trying to compile an gtkmm 2.12 program with /vd2 option > > [...] > > /vd2 is mandatory on gtkmm programs? > > MSDN say: /vd supports incorrect behavior in an early version of Visual > C++, and is no longer needed. > > > - Microsoft Visual Studio 2008/.NET Framework 3.5 > http://msdn.microsoft.com/en-us/library/7sf3txa8.aspx > /vd supports incorrect behavior in an early version of Visual C++, and > is no longer needed. This very page says for /vd2: "Allows you to use dynamic_cast Operator on an object being constructed. For example, a dynamic_cast from a virtual base class to a derived class." which is exactly what gtkmm does, IIRC (although I'm not sure where, and it seems not to be mentioned in the bug). This is why /vd2 is required for applications using gtkmm. > - Microsoft Visual Studio 2005/.NET Framework 2.0 > http://msdn.microsoft.com/en-us/library/7sf3txa8(VS.80).aspx > /vd supports incorrect behavior in an early version of Visual C++, and > is no longer needed. > > > - Microsoft Visual Studio 2003/.NET Framework 1.1 > I have found in this msdn documentation only a description of /vd0 and > /vd1. > http://msdn.microsoft.com/en-us/library/7sf3txa8(VS.71).aspx /vd2 was introduced with Visual Studio 2005. > See this comment: > http://bugzilla.gnome.org/show_bug.cgi?id=158040#c15 > > Comment #15 from Murray Cumming (glibmm developer, points: 23) > 2006-05-24 07:30 UTC [reply] > So, this seems to be fixed. > > > I think you don't need /vd2 for Visual Studio 2005 and higher any more. I don't think so. But feel free to try out. > Regards, > Urs Armin > ___ > gtkmm-list mailing list > gtkmm-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtkmm-list ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Gtkmm Windows installers available
On Fri, 2008-10-03 at 18:14 +0200, Murray Cumming wrote: > On Fri, 2008-10-03 at 13:55 +0200, Armin Burgmeier wrote: > > On Thu, 2008-10-02 at 18:49 -0400, Philip Kovacs wrote: > > > On the "Building gtkmm on Windows" web page I note the statement: > > > > > > "We suggest that you use MSYS to build gtkmm on Windows." > > > > > > This statement can only be be interpreted as: > > > > This is meant as: "If you want to build gtkmm with MinGW, then we > > recommend using MSYS to do so", since it is in the "Using MinGW" > > section. I made it more clear on the Wiki page. > > > > > "We suggest that you build your project, gtkmm and another other C++ > > > libraries > > > you intend to build from source with MSYS." > > > > > > Building any C++ project component with MINGW/MSYS means a total > > > commitment > > > to that environment/build system for all C++ project components. C++ > > > projects > > > and the libraries that they use must be built with the same compiler, due > > > to > > > name mangling, exception handling, stack issues, etc. > > > > > > "The MSVC++ DLLs have been built with Visual C++ 2005." > > > > > > is fine, but better would be: > > > > > > "The MSVC++ DLLs have been built with Visual C++ 2005 and are linked to > > > the > > > MS C/C++ runtime DLLs: MSVCR80.DLL / MSVCP80.DLL." > > > > It's a Wiki. Feel free to improve things yourself. > > > > > In my case, my Windows system has a later runtime environment: > > > MSVCR90.DLL / > > > MSVCP90.DLL (MS Visual Studio 2008), so I have to recompile anyway. I > > > think > > > cautioning people to verify which MS C/C++ runtime they have: 70/80/90, > > > etc. > > > before using the binary installer would be a good thing. > > > > I don't have too much experience with different runtimes, but I > > succeeded in building a small example application with Visual Studio > > 2008 against the binaries of the installer, which have been built with > > Visual Studio 2005. Doesn't this work in general? > > > > I think the MSVCR80 runtime files are still shipped with Visual Studio > > 2008. > > > > > Anyway, I have built each of: gtkmm/glibmm/sigc++/cairomm sucessfully with > > > MS VC++ 2008. I just wish there were a way to automate the installation > > > of > > > the development files to a target path from that gtkmm source tree. > > > > If that's indeed a problem, then we probably need to ship separate files > > for both Visual Studio 2005 (linked against *80.DLL) and 2008 (linked > > against *90.DLL). > > That does sound necessary. People would otherwise sometimes be forced to > link to both, which is probably unpleasant. Can you take care of that, > please, Armin? Yes. We will have to think of a naming convention for those binaries. gtkmm-2.4-vc9.dll? (in contrast to gtkmm-2.4.dll for VS 2005, which we might then rename to gtkmm-2.4-vc8.dll, possibly breaking compatibility) But I'm still not 100% convinced. Do other C++ projects that provide Windows binaries also ship different DLLs for each Visual Studio Version? > And please make sure that those improvements are in the wiki, if Philip > doesn't do that. Armin ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: GTKmm Windows - Glibmm KeyFile Problem
On Fri, 2008-10-03 at 17:09 -0500, John Hobbs wrote: > Hello all, > > I just started working with Gtkmm on Windows a few days ago, and I > can't get Glib::Keyfile to work properly. > > If the KeyFile doesn't exist, I want to start a config screen and make > one. Problem is, I can't catch anything from load_from_file, it just > seems to blow up. > > I found a related item, but it doesn't look like it ever resolved: > http://www.nabble.com/Glib::KeyFile-bug--td18043898.html > > The Doc's say "If the file could not be loaded then a FileError or > KeyFileError exception is thrown." > > But there doesn't seem to be anything to catch. Anyone have something > I'm missing? > > Below is my build/run output and the source of my test file. > MSYS/MinGW. > > --- > > [EMAIL PROTECTED] ~/w32-light/src > $ g++ -Wall -o example example.cpp `pkg-config gtkmm-2.4 --libs > --cflags` > > [EMAIL PROTECTED] ~/w32-light/src > $ ./example.exe > > This application has requested the Runtime to terminate it in an > unusual way. > Please contact the application's support team for more information. > > [EMAIL PROTECTED] ~/w32-light/src > $ This is the output for me: [EMAIL PROTECTED] ~/test $ ./test.exe Caught FileError which is what I'd expect. What compiler version are you compiling your code with? Maybe there are ABI incompatibilities between different MinGW compilers. And, just to be sure, what gtkmm version are you using? I'm using "gcc version 3.4.5 (mingw-vista special r3)" which I also used for building the MinGW binaries in the 2.14 installer. Armin ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Gtkmm Windows installers available
On Fri, 2008-10-03 at 15:13 -0400, Jam wrote: > Damon Register wrote: > > Jamiil wrote: > >> Before installed the the bellow suggested gtkmm installer I did a > >> compilation of a small application I am working on, however, after > >> installing your 'installer', I am getting a lot of compilation errors. > >> > >> Here is a list of the errors I am getting, what am I doing wrong? > >> TIA > >> == > >> D:\XWin\include\gtkmm-2.4\gtkmm.h|30|giomm.h: No such file or directory| > >> D:\XWin\include\gtkmm-2.4\gtkmm\cellrendererpixbuf.h|31|giomm/icon.h: > >> No such file or directory| > > I could be wrong but I bet your PKG_CONFIG_PATH got mangled somewhere. > > Start there and see that it really points to where the installer put > > everything. > > > > Damon Register > > > > > I am sorry for the delay, yes I checked the PKG_CONFIG_PATH it points to > 'D:\XWing\lib\pkgconfig'. > > I have now downloaded the latest of the Win32 GTKmm and the problem remains. > > What am I doing wrong? According to the error you are seeing, I assume it fails for you as soon as you compile a file that includes , right? However, this works for me. Are you sure you have installed the correct version? Armin ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Gtkmm Windows installers available
On Sat, 2008-10-04 at 06:15 +0200, Murray Cumming wrote: > On Fri, 2008-10-03 at 22:50 +0200, Armin Burgmeier wrote: > > Yes. We will have to think of a naming convention for those binaries. > > gtkmm-2.4-vc9.dll? (in contrast to gtkmm-2.4.dll for VS 2005, which we > > might then rename to gtkmm-2.4-vc8.dll, possibly breaking compatibility) > > Did Cedric's old installer have a VS2005 build, or just a VS2003 one? It contained only a VS2005 one (and one for MinGW). > > But I'm still not 100% convinced. Do other C++ projects that provide > > Windows binaries also ship different DLLs for each Visual Studio > > Version? > > Yes, I'd like to do what's normal, though I can't think of anything to > look at. But in the end we must do what people need. > > It looks like Qt only provide a MinGW build (not even any binaries) > though that is not clear: > http://trolltech.com/downloads/opensource/appdev I'm going to add VS 2008 projects to SVN and corresponding binaries to the installers in the next few days. Armin ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Gtkmm Windows installers available
On Fri, 2008-10-03 at 18:06 -0400, Philip Kovacs wrote: > * Murray Cumming <[EMAIL PROTECTED]> [2008-10-03 18:14:15 +0200]: > > > > > "The MSVC++ DLLs have been built with Visual C++ 2005 and are linked to > > > > the > > > > MS C/C++ runtime DLLs: MSVCR80.DLL / MSVCP80.DLL." > > > > > > It's a Wiki. Feel free to improve things yourself. > > > > > > > In my case, my Windows system has a later runtime environment: > > > > MSVCR90.DLL / > > > > MSVCP90.DLL (MS Visual Studio 2008), so I have to recompile anyway. I > > > > think > > > > cautioning people to verify which MS C/C++ runtime they have: 70/80/90, > > > > etc. > > > > before using the binary installer would be a good thing. > > > > > > I don't have too much experience with different runtimes, but I > > > succeeded in building a small example application with Visual Studio > > > 2008 against the binaries of the installer, which have been built with > > > Visual Studio 2005. Doesn't this work in general? > > > > > > I think the MSVCR80 runtime files are still shipped with Visual Studio > > > 2008. > > Mixing runtimes can work, but there are hazards that may cause strange errors > (and thus difficult bug reports). If I have a project linked to runtime XX > that > uses a gtkmm-linked to runtime YY, I have to be very careful not to extract > the > underlying runtime object from the gtkmm object and thereby move the runtime > object across the XX/YY boundary. > > For example, if I ask gtkmm/glibmm to create an object that has an underlying > file descriptor, that fd (integer) only has meaning in the runtime it was > created, > e.g. YY. If I extract the fd from the object, I am essentially moving it > into > the project environment's runtime, XX. That can cause disasterous results. > > That said, it can still "work" if the programmer is careful and doesn't > mishandle > objects created by the gtkmm/glibmm library. We probably shouldn't rely on this, and I don't actually want to track bug reports that result from incompatible runtimes, either. So I think we'll just add separate MSVC 2008 binaries to the installer, to be safe. > Phil Armin ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: GTKmm Windows - Glibmm KeyFile Problem
On Sat, 2008-10-04 at 18:41 -0500, John Hobbs wrote: > It's at work, so I can't be 100% sure, but it's the one that I got > with Dev-C++, which it says is "Mingw/GCC 3.4.2" on the site. As for > Gtkmm I pulled the one from: > http://ftp.gnome.org/pub/GNOME/binaries/win32/gtkmm/2.14/gtkmm-win32-devel-2.14.1-2.exe > > I'll try using the newer gcc, the one listed on the MinGW site is > "gcc-3.4.5-20060117-3" is that where you got yours? Yes, I think so. If this turns out to be the problem, then I will add a warning to the Wiki page. > How hard is it to build them yourself if you have MSYS? Sorry, I don't understand what you do want to build yourself. If you mean gtkmm, then there are instructions on http://live.gnome.org/gtkmm/MSWindows/BuildingGtkmm. But it would be nice if you'd try out the other compiler first. > - John Thanks, Armin ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Using GTKmm with Visual Studio Express 2008
On Sun, 2008-10-05 at 07:58 -0700, Lex Man wrote: > I've now managed to add the GTKmm files so everything is included in compile > but now I get 1 error and 205 warnings! I don't think anybody will be able to help you without you providing the error message you are seeing. It's true that gtkmm produces several warnings espcially with VS 2008. I believe most of them are harmless and we can maybe just disable them using the property sheets if they get too annoying, but I'll have to double-check. > I am using a vista 64 bit system and followed this tutoral. > > http://www.gtkmm.org/docs/gtkmm-2.4/docs/tutorial/html/sec-visual-studio-new-project.html Armin ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Gtkmm Windows installers available
On Sun, 2008-10-05 at 16:46 -0400, Philip Kovacs wrote: > I am not a big fan of "installers" as they write to the registry. I prefer > zip archives that have no such side-effects. The gtkmm installer sets the GTKMM_BASEPATH environment variable that is required for the MSVC property sheets (they set the include paths to $(GTKMM_BASEPATH)\include\gtkmm-2.4 etc.). Simply using relative path names doesn't seem to work. Also, if you don't know where the GTK+ bundle has been extracted to, you probably can't set the correct paths to the C header and library files in the property sheets. Armin ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Gtkmm Windows installers available
On Tue, 2008-10-07 at 11:21 +0200, Murray Cumming wrote: > On Tue, 2008-10-07 at 11:16 +0200, Armin Burgmeier wrote: > > On Mon, 2008-10-06 at 18:25 +0200, Murray Cumming wrote: > > > On Mon, 2008-10-06 at 12:05 +0200, Armin Burgmeier wrote: > > > > On Sun, 2008-10-05 at 16:46 -0400, Philip Kovacs wrote: > > > > > I am not a big fan of "installers" as they write to the registry. I > > > > > prefer > > > > > zip archives that have no such side-effects. > > > > > > > > The gtkmm installer sets the GTKMM_BASEPATH environment variable that is > > > > required for the MSVC property sheets (they set the include paths to > > > > $(GTKMM_BASEPATH)\include\gtkmm-2.4 etc.). Simply using relative path > > > > names doesn't seem to work. > > > > > > Maybe it's worth mentioning (on the wiki page) that no registry settings > > > (or other environment variables) are set by the installer, or anything > > > else other than just putting files in directories. > > > > That's actually not true. The installer sets indeed HKLM\Software\gtkmm > > in the registry so that it finds previous versions when upgrading. > > OK. Please document that on the wiki. Done. > As long as people know what (and how little) it does, that shouldn't > disturb anybody. It seems that we even can get rid of that registry setting, and use the GTKMM_BASEPATH environment variable for the detection of previous versions (and for the uninstaller). I don't know whether that's a good idea generally, but I tested this locally, and it seems to work. Armin ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Gtkmm Windows installers available
On Mon, 2008-10-06 at 18:25 +0200, Murray Cumming wrote: > On Mon, 2008-10-06 at 12:05 +0200, Armin Burgmeier wrote: > > On Sun, 2008-10-05 at 16:46 -0400, Philip Kovacs wrote: > > > I am not a big fan of "installers" as they write to the registry. I > > > prefer > > > zip archives that have no such side-effects. > > > > The gtkmm installer sets the GTKMM_BASEPATH environment variable that is > > required for the MSVC property sheets (they set the include paths to > > $(GTKMM_BASEPATH)\include\gtkmm-2.4 etc.). Simply using relative path > > names doesn't seem to work. > > Maybe it's worth mentioning (on the wiki page) that no registry settings > (or other environment variables) are set by the installer, or anything > else other than just putting files in directories. That's actually not true. The installer sets indeed HKLM\Software\gtkmm in the registry so that it finds previous versions when upgrading. I only mentiond the GTKMM_BASEPATH variable to show that simple .zip files can't offer the same functionality as the installer (because the MSVC property sheets would not work). > > Also, if you don't know where the GTK+ bundle has been extracted to, you > > probably can't set the correct paths to the C header and library files > > in the property sheets. > > Yes, I like having the gtkmm dependencies in the same installer. It just > makes it easier. > > Rebuilding gtkmm (if we really can't provide binaries for all common > compilers) should already be easy (and Armin has documented that), but I > guess we'd welcome any suggestions/patches to improve that. Armin ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Gtkmm Windows installers available
On Sat, 2008-10-04 at 06:15 +0200, Murray Cumming wrote: > On Fri, 2008-10-03 at 22:50 +0200, Armin Burgmeier wrote: > > Yes. We will have to think of a naming convention for those binaries. > > gtkmm-2.4-vc9.dll? (in contrast to gtkmm-2.4.dll for VS 2005, which we > > might then rename to gtkmm-2.4-vc8.dll, possibly breaking compatibility) If we use the boost conventions, as suggested by Cedric on your blog, then it would probably look like "gtkmm-vc90-(d-)2_4.dll". Should we do the same for the MSVC2005 DLLs? And while we are at it, we could do the same for the property sheets (to, say, gtkmm-vc80-(d-)2_4.vsprops). We probably just need to keep the old ones, so existing projects can still find them. Armin ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Gtkmm Windows Runtime Installer - Silent Option
On Fri, 2008-10-10 at 11:43 -1000, John Hobbs wrote: > Hello, > > I am looking to deploy the Windows runtime installer in silent mode, > but it doesn't set the PATH when you do that. > > I am running: > > gtkmm-win32-runtime-2.14.1-2.exe /S /D=C:\Program Files\gtkmm > > Is there a flag I can use to make it set the env. variables? > Here is a ref. for adding a flag maybe: > http://nsis.sourceforge.net/Docs/Chapter4.html#4.12 > > Also, when you run it silent it seems to install as "current user > only", an option would be nice. There are already the two flags /SET_ENVVARS and /ALLUSERS which will probably do what you are looking for. I'm going to update the wiki and mention them. > Lastly, if you install silent, when you uninstall it won't clean up > the start menu at all. Yeah, I can reproduce this. I'll have a look. Thanks, Armin > ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Gtkmm Windows installers available
On Sat, 2008-10-04 at 11:40 +0200, Armin Burgmeier wrote: > On Sat, 2008-10-04 at 06:15 +0200, Murray Cumming wrote: > > On Fri, 2008-10-03 at 22:50 +0200, Armin Burgmeier wrote: > > > Yes. We will have to think of a naming convention for those binaries. > > > gtkmm-2.4-vc9.dll? (in contrast to gtkmm-2.4.dll for VS 2005, which we > > > might then rename to gtkmm-2.4-vc8.dll, possibly breaking compatibility) > > > > Did Cedric's old installer have a VS2005 build, or just a VS2003 one? > > It contained only a VS2005 one (and one for MinGW). > > > > But I'm still not 100% convinced. Do other C++ projects that provide > > > Windows binaries also ship different DLLs for each Visual Studio > > > Version? > > > > Yes, I'd like to do what's normal, though I can't think of anything to > > look at. But in the end we must do what people need. > > > > It looks like Qt only provide a MinGW build (not even any binaries) > > though that is not clear: > > http://trolltech.com/downloads/opensource/appdev > > I'm going to add VS 2008 projects to SVN and corresponding binaries to > the installers in the next few days. I recently uploaded revision 3 of the 2.14.1 installers [1]. They contain DLLs for both MSVC 2005 and MSVC 2008. They also fix the problem with the uninstaller not properly removing start menu items of user-local installations. There might also be new problems because of the DLL renames, although I hope there aren't. Armin [1] ftp://ftp.gnome.org/pub/GNOME/binaries/win32/gtkmm/2.14/ ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: windows uninstaller not pruning libxml2
On Mon, 2008-10-13 at 14:30 -0400, Philip Kovacs wrote: > Just a few libxml2 paths remained after using Windows uninstall. You > might want to check that. > gtkmm > gtkmm/include > gtkmm/include/libxml2 > gtkmm/include/libxml2/libxml > > (This is the "older" installer from about 2 weeks ago, i.e. before the > dll runtime versioning). I remember having fixed such a problem. The current version should contain the fix. But I'll double-check. Maybe revision 2 also has it already, but I'm not sure. > BTW, I am still actively using gtkmm, just not the packaged > runtimes. :-] > > Phil Thanks, Armin > ___ > gtkmm-list mailing list > gtkmm-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtkmm-list ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Gtkmm Windows Runtime Installer - Silent Option
On Mon, 2008-10-13 at 04:39 -1000, John Hobbs wrote: > Clearly I must not understand what's going on, perhaps you can clear > this up for me. > > Say I have 10 different favorite Gtkmm apps that I really want to > install on my Windows machine, because they are great pieces of > software. So I go download all 10 of them and install them, and each > one follows your recommendation of putting the libs next to the app. > So then I have 10 copies of the libs, and when I start up the apps I > get 10 copies of them in memory? (The question mark is because I don't > know if that is true with how dll's work, do they check memory even > when the loaded lib is from a different location on disk?) > So why provide a run-time installer at all then? The DLLs in the runtime installer are stripped (the MinGW ones, actually). This means they are smaller because they don't contain debug symbols. I thought of providing both debug and non-debug versions of the MinGW DLL's with the installer (as for MSVC++), but this would require different import libraries as well, and many applications using MinGW are built using autotools. As the library to use is more or less hardcoded that way (via the pkg-config file), this is probably not as useful as for the MinGW ones. Maybe it's worth thinking about adding a separate redist/ directory to the development installer that contains stripped versions of the DLLs in bin/. Then we could tell people to use these DLLs for redistributing. > I mean, unless you > intend for developers to say "The gtkmm runtime is a pre-req" and have > them go download it, or provide that utility in their installer, then > why provide it at all? Shouldn't a developer version that they can > take the libs from and distribute themselves be enough in that case? We actually tried this with Gobby[1] on Windows. We didn't ship GTK+ (and gtkmm) with it for a long time but pointed people to runtime installers, so that DLLs can be shared. But there were so many people that had problems to get it running so that we decided to redistribute GTK+. However, if we keep the runtime installers, then developers still have the option to (optionally) ship their applications without gtkmm. It is still possible to offer a version without the GTK+ and gtkmm runtime for more technical users that do like such things to be shared (FWIW, I'm one of them). From a maintainence point of view, the additional work for the separate runtime installer is nearly nonexistant. > I'm trusting that you have good reasons, you are clearly a dedicated > developer and knowledgeable person, but I just can't understand it > yet. > > - John Hobbs Armin [1] http://gobby.0x539.de ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: memory management with glibmm & giomm
On Tue, 2008-10-14 at 20:04 +0200, nico wrote:
> Hello,
>
> One week ago, I sent an email about a leak of memory of a program that
> list files of a directory (using giomm).
> My program was inspired by an official sample code (that we can get
> here:
> http://svn.gnome.org/viewvc/gtkmm-documentation/trunk/examples/book/giomm/directory_list/)
>
> In fact, there is a bug in this sample program:
>
> > *Glib*::RefPtr file_info = enumerator->next_file();
> > *while*(file_info)
> > {
> > *std*::cout << *"file: "* << file_info->get_name() << std::endl;
> > file_info = enumerator->next_file();
> > }
> This piece of code create FileInfo objects and never unref them.
> The right code would have beeb:
> > Glib::RefPtr file_info = enumerator->next_file();
> > while(file_info)
> > {
> > std::cout << "file: " << file_info->get_name() << std::endl;
> > file_info = enumerator->next_file();
> > file_info->unreference();
> > }
> Or, an other variant :
> > while(Glib::RefPtr file_info = enumerator->next_file()) {
> > std::cout << "file: " << file_info->get_name() << std::endl;
> > file_info->unreference();
> > }
You should never need to call unreference() yourself. If this fixes the
memory leak problem, then the problem is that
FileEnumerator::next_file() method does add an additional reference to
the return value, although it shouldn't.
> I'll try to report the bug,
Thanks.
> Regards,
> Nicolas
Armin
___
gtkmm-list mailing list
gtkmm-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: windows uninstaller not pruning libxml2
On Mon, 2008-10-13 at 20:49 +0200, Armin Burgmeier wrote: > On Mon, 2008-10-13 at 14:30 -0400, Philip Kovacs wrote: > > Just a few libxml2 paths remained after using Windows uninstall. You > > might want to check that. > > > gtkmm > > gtkmm/include > > gtkmm/include/libxml2 > > gtkmm/include/libxml2/libxml > > > > (This is the "older" installer from about 2 weeks ago, i.e. before the > > dll runtime versioning). > > I remember having fixed such a problem. The current version should > contain the fix. But I'll double-check. Yeah, It's fixed. > Maybe revision 2 also has it already, but I'm not sure. > > > BTW, I am still actively using gtkmm, just not the packaged > > runtimes. :-] > > > > Phil > > Thanks, > Armin ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: memory management with glibmm & giomm
On Tue, 2008-10-14 at 22:37 +0200, nico wrote: > > You should never need to call unreference() yourself. If this fixes the > > memory leak problem, > > > Yes, it solve my problem. > Now the memory usage is stable and < 700Kb. > Without this unref the memory usage is growing up (very quickly, for > example, I need about 50 Mb to scan 3000 files). > > then the problem is that > > FileEnumerator::next_file() method does add an additional reference to > > the return value, although it shouldn't. > the underline C g_file_enumerator_next_file() function return a pointer > to a new created GObject (we need to call g_object_unref() to free this > object). > Do you think that, there is a bug in the C++ binding? Yes. I filed a bug about it: http://bugzilla.gnome.org/show_bug.cgi?id=556387. I propose not to call unreference on your own, but instead wait for a glibmm release with the bug fixed. Or, if you really need this to work correctly and you can't wait for a release, you could maybe do something like: Glib::RefPtr info = enumerator->next_file(); if(G_OBJECT(info->gobj())->ref_count > 1) info->unreference(); This way, the unreference will only be called as long as the bug is not fixed in glibmm. > If you want to test, here is source code of programs : > > http://yojik.shtooka.net/gio.cc (giomm version) > http://yojik.shtooka.net/gio.c (gio version) > > Regards, > Nicolas Armin > ___ > gtkmm-list mailing list > gtkmm-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtkmm-list ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: comments on the gtkmm -vcXX- naming convention
On Wed, 2008-10-15 at 13:33 -0400, Philip Kovacs wrote: > I installed the latest gtkmm Windows development package and I have > some comments. > > From the point of view of application developers who require gtkmm as > a dependency, > this new -vcXX- naming convention for the import libraries is a > burden. > > I have to rework my build systems to handle this new library naming > convention; offer > end-users a switch to select VC80/90 and then link to the correct > libraries after "assembling" > a library name based on the switch. I don't know what your end-users are (actual users, or application developers?), but can't you just use the vc80 binaries if you are building with MSVC++ 2005 and the vc90 ones if you are building with MSVC++ 2008? > A better approach would have been to use the standard names we are > accustomed to: > cairomm-1_0.lib, sigc-2_0.lib, gtkmm-2_4.lib, etc. and creating > separate installers targeting > the required runtime. But that way it would still easily be possible to confuse the vc80 and the vc90 DLLs if people don't 100% know what they are doing, which is exactly what we tried to prevent with that naming convention. > The root of the installation tree would be the ONLY place where the > runtime was indicated, e.g.: > > C:\Program Files\Gtkmm-2.14.1-VC80 > > or > > C:\Program Files\Gtkmm-2.14.1-VC90 > > That way, you can easily point into the needed tree to link instead of > having to rework > build systems. > > Also, I haven't built gtkmm from source since this changeover. What > naming convention > do you use for the import libraries when building with MSVC? The same. For example, gtkmm-vc80-2_4.lib. > Do you discover the runtime > version automatically and name appropriately? There is no need to discover anything at runtime. The MSVC 2005 project files use the vc80 ones and the MSVC 2008 use the vc90 ones. > Really would have preferred to see my approach above It would have been nice to know this before doing the work of changing everything. Maybe I didn't make the plans clear enough. I'll try to do better next time. I don't know if this works, but would it be helpful in your case when we could add the old .dlls and .libs back, but as a Windows shortcut to the new vc80 ones? Armin ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: comments on the gtkmm -vcXX- naming convention
On Wed, 2008-10-15 at 15:04 -0400, Philip Kovacs wrote: > * Armin Burgmeier <[EMAIL PROTECTED]> [2008-10-15 20:25:22 +0200]: > > > On Wed, 2008-10-15 at 13:33 -0400, Philip Kovacs wrote: > > > I installed the latest gtkmm Windows development package and I > have > > > some comments. > > > > > > From the point of view of application developers who require gtkmm > as > > > a dependency, this new -vcXX- naming convention for the import > libraries > > > is a burden. > > > > > > I have to rework my build systems to handle this new library > naming > > > convention; offer end-users a switch to select VC80/90 and then > link > > > to the correct libraries after "assembling" a library name based > on the > > > switch. > > > > I don't know what your end-users are (actual users, or application > > developers?), but can't you just use the vc80 binaries if you are > > building with MSVC++ 2005 and the vc90 ones if you are building with > > MSVC++ 2008? > > I am the developer, so my end-users are the ones who will install > the > gtkmm runtime in order to use my applications. I still don't get what the problem is with this. You decide what you build your application with, and things will just work for the users because the runtime package contains all the necessary files to run the application, regardless whether you build against the MSVCRT80 or the MSVCRT90 runtime. > The argument that "confusion would result" if people copied the gtkmm > files into Windows/System32 is specious. People simply should not > be doing that. You should install gtkmm to a non-system directory > and > then use the path environment var to add the gtkmm bin/ to your path. But if there are two applications, one built with MSVC 2005 and one with MSVC 2008, then they should use different DLLs, right? If these DLLs have the same name, then this cannot work (at least not if the DLLs are meant to be shared). > My issue with the naming convention is that developers, such as > myself, > now have to make some very unusual changes to their build systems > to link gtkmm/glibmm/cairomm/sigc correctly. Sorry, I don't get it. What changes do you have to make, and why? Is the problem that you rather want to change the library search path instead of the library names to toggle between the vc80 and the vc90 builds? > Furthermore, there is no real need to tag the import libraries with > the > runtime name since the link libraries can easily be observed with > programs > like depends.exe. Anyone who is "confused" as to what gtkmm-2_4.dll > links > to can use depends, or programs like it, to observe what is going on. But we still couldn't have both shared vc80 and vc90 DLLs if they would have the same name. The import libraries have been tagged with the same convention because linking against a vc80 import library makes the program depending on the vc80 DLL, and linking against a vc90 import library makes the program depending on the vc90 DLL. > The visual cue in the filenames is very unusual and throws a problem > back > to all build systems that have the *mm's as deps. We used the same conventions as the boost C++ libraries, here: http://www.boost.org/doc/libs/1_35_0/more/getting_started/windows.html#library-naming So this seems not to be too unusual. Would you have the same problems with boost? > Even if you were to maintain only one installer, it would be better to > install > several trees that are rooted by the runtime version, rather than > create one > tree and use these names. > > I hope you will consider it. First, I would be interested in a few more opinions on this. > Phil > > BTW I know you worked hard on the new installer and my criticism is > meant > to be taken in a constructive light. Armin ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Console screen from spawn_process
On Thu, 2008-10-16 at 10:15 -0200, Paulo Flabiano Smorigo wrote: > Hi everyone, > > I'm developing an application to run on Windows and uses spawn_process > to run a command. > I use the "-mwindows" paramenter to avoid the console screen but when > I use the spawn the screen appears. > The title of this console is the name of the executable that I > spawned. I guess the spawned applications needs to be built with the -mwindows flag for this. It is also possible to change that flag after the application has been built. The Windows CreateProcess() API has a flag to suppress the console window for the child, but Glib does not use it for spawning applications. There has been a bug report about this which has been closed as WONTFIX: http://bugzilla.gnome.org/show_bug.cgi?id=509201 So your options are either to change the -mwindows flag of the child process (if you have control over that), or to use the Windows CreateProcess() API directly. Armin ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Using gtkmm with Visual C++ and _SECURE_SCL=0
On Fri, 2008-10-17 at 16:05 +0200, Thomas Frank wrote: > Hallo. > > I'm trying to introduce gtkmm (also) on windows as GUI to my non-GUI > libraries. As many other users of Visual C++ I need to #define > _SECURE_SCL=0 for the Release-versions of my libraries and any > application that uses them, to ensure a satisfying performance of the > STL-containers. > > It turns out that "_SECURE_SCL=0" is incompatible with gtkmm from the > windows installer-package. All the release-versions of the libraries > here are compiled with the default (and slow) "_SECURE_SCL=1". This > would be no problem at all, if no public interfaces would instantiate or > exchange any STL-containers. But a sigc::signal for example, uses > std::list to store slots connected to signals and returns a > list::iterator with the connect()-function. This produces linker errors > when calling signal::connect() and compiling and linking an application > with "#define _SECURE_SCL=0" against gtkmm. > > Has anybody ever ran into the same kind of problem(s) and found a > workaround other than recompiling gtkmm and all its dependant > C++-libraries? > > I would like to enjoy the comfort and reliability of the installers both > for development and deployment. Using "_SECURE_SCL=1" with my own > source-code is definitely not an option, due to the absolutely > disappointing performance of the STL-containers in this mode. > > I searched for _SECURE_SCL in the archives but didn't get any results. > Has this ever been a topic? I didn't even know this option existed. Of course, we could enable this for the gtkmm runtime binaries, but then people need to set the same flag in their applications, which is just one step more that could go wrong. This is why I would rather avoid it. We could also supply release binaries for both _SECURE_SCL=0 and _SECURE_SCL=1 (so we would have 6 different VC++ DLLs for each C++ module). Again, I'm not quite happy with this considering the duplication it involves. How many applications do (need to) use the _SECURE_SCL=0 option? Is it kind of standard that it is used for release builds? If not, then I'm sorry, but I don't think it's reasonable to support all the different MSVC++ compiler settings that produce incompatible binaries. Just because there are too much of them. However, considering the rules posted on [1], I don't see an easy workaround for your problem without rebuilding the involved C++ libraries. Armin [1] http://blogs.msdn.com/vcblog/archive/2007/08/10/the-future-of-the-c-language.aspx#4617984 ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Console screen from spawn_process
On Thu, 2008-10-16 at 15:01 -0200, Paulo Flabiano Smorigo wrote: > Hi Armin, > > Thanks for the fast reply! > > I compile the child process with the "-mwindows" parameter but the > problem is that I need to communicate with the child using stdin and > stdout by the method spawn_process_with_pipes but with "-mwindows" > there is no stdin and stdout... There still is, you just don't see it. You can use stdin and stdout for communication even when there is no console window. > So, there is no solution? I will have to understand the CreateProcess > API ? I did the same thing in Glom. Maybe it's helpful: http://svn.gnome.org/viewvc/glom/trunk/glom/libglom/spawn_with_feedback.cc?view=markup > Even if I have a system() call in the application this blank console > appears... :( > > If the bug is WONTFIX means there will be no fix? Most likely not. > Thanks... > Paulo Flabiano Smorigo Armin ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: gtkmm on Windows: Last steps
On Sun, 2008-10-19 at 15:40 +0200, Murray Cumming wrote: > It looks like we are almost done with the gtkmm on Windows effort. I > have just a couple of questions: > > 1. > http://live.gnome.org/gtkmm/MSWindows > says > "make sure the "Add the gtkmm runtime directory to the PATH variable" > option is checked. This is required for Windows to find the gtkmm DLL > files." > But: > > 1.1 > If you should make sure that it is checked, why is it an option? The > page should tell us how to make the decision. Isn't the following clear enough? "If you know what you do, then you can also uncheck that option. This can be useful if you have multiple versions of gtkmm installed (for example, both runtime and development DLLs) and want to choose which one to use by setting the PATH variable manually." Yes, it's actually an option for advanced users. That's why it's checked by default and the wiki page says only to change it if one knows what she does. It also makes sure users notice that we change the PATH variable. This can help them when testing redistribution packages (it doesn't make sense to test whether an application runs out of the box if all the required DLLs are in the PATH anyway). People could also want to only set the PATH in msys so it does not affect the global system, but only the msys environment. So personally, I see enough use cases to justify to keep this option. If others feel different about it, please tell us. > 1.2 > I thought that applications would find the DLLs because they are in the > same directory. Why is something in the PATH environment variable also > needed? I don't understand why MS Visual Studio would need it either if > we are using these "property pages". MSVC++ does not need it to build stuff, but to run or debug from within the IDE. I'm not sure whether there is an option in MSVC++ to extend the DLL search path that the property pages could set, but I'll check. If people do redistribute gtkmm with their applications, then it is not necessary to set the PATH variable. However, the main purpose of the runtime installer is to allow running applications that do not redistribute gtkmm. It might be debatable whether we would like to support that or not. An option would be only to provide a development installer and tell people to strip the MinGW binaries before redistributing. But that's also a bit dangerous since stripping some libraries such as libxml2.dll breaks them. Maybe this is because they have been built with MSVC, but I'm not sure. So it's not as easy as "strip *.dll". We would need to make clear which libraries to strip and which not. > 2. > The wiki page should make it clear that the runtime-only installer > installs stripped (no debug symbols) for mingw, but that the non-debug > DLLs are the same for other compilers, because it is harder for build > systems to automatically choose between stripped and debug versions on > that platform. I clarified this on the Wiki. > We should make it clear that it's probably the stripped > DLLs that you want to redistribute with your application. That's already mentioned in the Redistributing section. "If your application is built with MinGW, you should use the files from the runtime package, since they don't contain debug symbols." > 3. > Have we yet found a use for the silent install? If not, why do we > mention it? People have asked for it on the mailing list, so I added it to the Wiki page. I do think it's good in general that this is documented somewhere since there are few other options to find out the available flags. I'm not sure whether people are actually using silent install or not, but maybe others can comment on that. > 4. > Would someone like to update this section in the gtkmm book (in the > gtkmm-documentation module in svn), and just refer to the live.gnome.org > page where appropriate, instead of repeating: > http://www.gtkmm.org/docs/gtkmm-2.4/docs/tutorial/html/sec-windows-installation.html > Otherwise we'll have to remove it. I'll have a look. Armin ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: gtkmm on Windows: Last steps
On Sun, 2008-10-19 at 16:36 +0200, Armin Burgmeier wrote: > > 4. > > Would someone like to update this section in the gtkmm book (in the > > gtkmm-documentation module in svn), and just refer to the live.gnome.org > > page where appropriate, instead of repeating: > > http://www.gtkmm.org/docs/gtkmm-2.4/docs/tutorial/html/sec-windows-installation.html > > Otherwise we'll have to remove it. > > I'll have a look. I removed the Dev-C++ instructions since they were outdated, and the MinGW compiler shipped with Dev-C++ is 3.4.2, which we found to be incompatible to 3.4.5 with which the binaries are built. Since there were no news in Dev-C++ since 2005 it seems unlikely that this will change in future. Instead, I added links to the live.gnome.org pages. What about http://www.gtkmm.org/docs/gtkmm-2.4/docs/tutorial/html/chapter-msvc.html? I updated two or three paragraphs, but it still seems good and valid otherwise, although some of the content is already covered on the wiki page. Armin ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Using gtkmm with Visual C++ and _SECURE_SCL=0
On Mon, 2008-10-20 at 11:11 +0200, Thomas Frank wrote: > Hallo Armin. > > Thanks a lot for your response. > > 1. In Visual-C++ the _SECURE_SCL-flag enables some special security > checks within the STL-Container-templates. This means among others > that the base-classes for all iterators get an additional member, a > pointer to the referenced container. This pointer in turn is used to > make additional runtime-checks, if an iterator is actually pointing > into the container it is used with. To my opinion this is quite useful > in debug-mode, but for release-versions, these checks can easily slow > down the performance of programs by 10-20% and more, depending on the > algorithms used. Since _SECURE_SCL=0 removes the additional > pointer-member from the iterators, the binary-compatiblility with > libraries in 'secure-mode' is broken. Anyway. MS has decided to make > _SECURE_SCL=1 the default, for both release- and debug-mode. Which > leads me to... > > 2. I totally agree with pre-built libraries compiled with the > default-settings of a compiler. I did not really expect an additional > customized build for my purposes. That's why I asked for a known > workaround. It could be that sigc++ is the only source of problems, > since it exchanges iterators in its interface (signal::connect()). If > so, I would mail to their list, but I do not really know if there is > other items somewhere in the libraries that are also affected and I > cannot double-check the complete code... > > 3. I found the instructions on > http://live.gnome.org/gtkmm/MSWindows/BuildingGtkmm . But I would > rather like to rebuild exactly the libs and dlls, that come with the > installer-packages. Where can I find out, which packages of libsigc++, > glibmm, cairomm, pangomm and gtkmm were exactly used for the > installers? The DLLs have a version resource that shows the Version in the Windows explorer when viewing the DLLs, or by choosing Properties on a DLL. The only exception to this is libsigc++ which has been built from SVN since there was no release with updated MSVC project files when the latest installer was built. > The idea is, if I rebuild exactly the same versions, I could just > exchange the release-libs and -dlls of the standard gtkmm-installation > and are finished. > Maybe there is even a complete VisualC++-Workspace (sln) for all C > ++-libraries at once, that could be released along with the > installers? There is no such solution yet, but I think this is a good idea. The only problem that I see is that this solution file needs to know the path to the libsigc++, glibmm, cairomm etc. source code, even if we ship it with gtkmm. > Any aid in building a 'patch' for the installers would be welcome. The installer sources are in gtkmm SVN in the win32_installer directory. Adding a file that the installer is supposed to install is easy (if this is what you are looking for), just look how it's done for the existing files in gtkmm-installer.nsi.in, and remember to also add it to the uninstaller. > regards > Thomas Armin ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: gtkmm on Windows: Last steps
On Mon, 2008-10-20 at 10:24 +0200, Murray Cumming wrote: > On Sun, 2008-10-19 at 16:36 +0200, Armin Burgmeier wrote: > > On Sun, 2008-10-19 at 15:40 +0200, Murray Cumming wrote: > > > It looks like we are almost done with the gtkmm on Windows effort. I > > > have just a couple of questions: > > > > > > 1. > > > http://live.gnome.org/gtkmm/MSWindows > > > says > > > "make sure the "Add the gtkmm runtime directory to the PATH variable" > > > option is checked. This is required for Windows to find the gtkmm DLL > > > files." > > > But: > > > > > > 1.1 > > > If you should make sure that it is checked, why is it an option? The > > > page should tell us how to make the decision. > > > > Isn't the following clear enough? > > > > "If you know what you do, then you can also uncheck that option. This > > can be useful if you have multiple versions of gtkmm installed (for > > example, both runtime and development DLLs) and want to choose which one > > to use by setting the PATH variable manually." > > Not really, no. See below. > > > Yes, it's actually an option for advanced users. That's why it's checked > > by default and the wiki page says only to change it if one knows what > > she does. > > > > It also makes sure users notice that we change the PATH variable. This > > can help them when testing redistribution packages (it doesn't make > > sense to test whether an application runs out of the box if all the > > required DLLs are in the PATH anyway). > > > > People could also want to only set the PATH in msys so it does not > > affect the global system, but only the msys environment. > > > > So personally, I see enough use cases to justify to keep this option. If > > others feel different about it, please tell us. > > > > > 1.2 > > > I thought that applications would find the DLLs because they are in the > > > same directory. Why is something in the PATH environment variable also > > > needed? I don't understand why MS Visual Studio would need it either if > > > we are using these "property pages". > > > > MSVC++ does not need it to build stuff, but to run or debug from within > > the IDE. I'm not sure whether there is an option in MSVC++ to extend the > > DLL search path that the property pages could set, but I'll check. > > That sounds rather strange. Please do check. It would be nice to remove > the PATH change if possible. I don't have access to a windows machine until the end of the week. But I'll check that then. However, I don't think the runtime installer will be very useful when not setting the PATH variable (at least not to end users). So maybe it's best if we only provide the development installer in future. > If not, we need to mention that reason (for debugging) on the wiki > page. > > > If people do redistribute gtkmm with their applications, then it is > not > > necessary to set the PATH variable. However, the main purpose of the > > runtime installer is to allow running applications that do not > > redistribute gtkmm. > > > > It might be debatable whether we would like to support that or not. > An > > option would be only to provide a development installer and tell > people > > to strip the MinGW binaries before redistributing. But that's also a > bit > > dangerous since stripping some libraries such as libxml2.dll breaks > > them. Maybe this is because they have been built with MSVC, but I'm > not > > sure. So it's not as easy as "strip *.dll". We would need to make > clear > > which libraries to strip and which not. > > > 3. > > > Have we yet found a use for the silent install? If not, why do we > > > mention it? > > > > People have asked for it on the mailing list, so I added it to the Wiki > > page. I do think it's good in general that this is documented somewhere > > since there are few other options to find out the available flags. I'm > > not sure whether people are actually using silent install or not, but > > maybe others can comment on that. > > At the least we need to make it clear that we don't recommend using this > from application installers. Done. Armin ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: tutorial for netbeans and code-blocks
On Mon, 2008-10-20 at 11:29 +0200, Martin (OpenGeoMap) wrote: > Murray Cumming escribió: > > On Sun, 2008-10-19 at 21:50 +0200, Martin (OPENGeoMap) wrote: > > > >> Hi: > >> > >> I hace added a little tutorial for GTKMM, netbeans and code-blocks with > >> many pics ;-) ;-) . > >> http://wiki.netbeans.org/GTKMMApplicationInNetBeans > >> > > > > Thanks, that very clear. > > > > But people should not need to install the GTK+ installer. The gtkmm > > installer contains all the dependencies. > > > Ok. thanks murray. But the gtkmm installer what enviroment variables > configure in Windows?? > c:\gtk\bin\ > PKG_CONFIG_PATH I don't understand what the question is here. The gtkmm installer includes pkg-config.exe so that it finds all the GTK and gtkmm libraries without having to set PKG_CONFIG_PATH explicitely. Armin ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Console screen from spawn_process
On Mon, 2008-10-20 at 17:18 -0200, Paulo Flabiano Smorigo wrote: > Hi Armin, > > Thanks for the reply and the code. I saw it and notice that you don't > use the stdin of the spawn process. In my program I will need this. > > You sad that even if I compile with -mwindow I will have stdin and > stdout. So I compile and doing some tests I discover that the stdout > is working but if I try to send commands to stdin with the command > "write(&stdin, "my command", strlen(size_of_my_command))" there is no > result. So does this work when the console window is enabled? I'm not sure what your "stdin" is, but the write call normally takes an integer, not a pointer to something. I can also imagine that your command needs to be terminated with a newline character, "\n". Maybe the data is cached until one is encountered. But that's only a guess. > I trying to figure out what I'm doing wrong... Maybe you could help > me... > > Thanks again... > Paulo Flabiano Smorigo Armin ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: tutorial for netbeans and code-blocks
On Mon, 2008-10-20 at 17:40 +0200, Martin (OPENGeoMap) wrote: > Armin Burgmeier escribió: > > On Mon, 2008-10-20 at 11:29 +0200, Martin (OpenGeoMap) wrote: > > > >> Murray Cumming escribió: > >> > >>> On Sun, 2008-10-19 at 21:50 +0200, Martin (OPENGeoMap) wrote: > >>> > >>> > >>>> Hi: > >>>> > >>>> I hace added a little tutorial for GTKMM, netbeans and code-blocks with > >>>> many pics ;-) ;-) . > >>>> http://wiki.netbeans.org/GTKMMApplicationInNetBeans > >>>> > >>>> > >>> Thanks, that very clear. > >>> > >>> But people should not need to install the GTK+ installer. The gtkmm > >>> installer contains all the dependencies. > >>> > >>> > >> Ok. thanks murray. But the gtkmm installer what enviroment variables > >> configure in Windows?? > >> c:\gtk\bin\ > >> PKG_CONFIG_PATH > >> > > > > I don't understand what the question is here. The gtkmm installer > > includes pkg-config.exe so that it finds all the GTK and gtkmm libraries > > without having to set PKG_CONFIG_PATH explicitely. > > > humm. Open the console in windows. can you call the pkg-config > directly? Yes, as long as the installer added the bin/ subdirectory to the PATH environment variable (which it does by default, although this might change in future). > . this utility need the path of the pkg-config files. I can not > exec that utility without register that path of the files. I don´t know > but perhaps it´s the GTK version i was using. > http://gladewin32.sourceforge.net/ > > When i exec the pkg-config tell me that i need configure the > PKG_CONFIG_PATH You shouldn't need to do this if you are using the gtkmm development Windows installer. If you need to, then it's a bug. But it works for me. pkg-config on Windows has some magic built in, so that it automatically looks in the ../lib/pkgconfig (relative to the path to pkg-config.exe) directory when searching for .pc files. And this is where the gtkmm installer installs them. Armin ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: gtkmm on Windows: Last steps
On Mon, 2008-10-20 at 12:02 +0200, Murray Cumming wrote: > On Sun, 2008-10-19 at 19:49 +0200, Armin Burgmeier wrote: > > On Sun, 2008-10-19 at 16:36 +0200, Armin Burgmeier wrote: > > > > 4. > > > > Would someone like to update this section in the gtkmm book (in the > > > > gtkmm-documentation module in svn), and just refer to the live.gnome.org > > > > page where appropriate, instead of repeating: > > > > http://www.gtkmm.org/docs/gtkmm-2.4/docs/tutorial/html/sec-windows-installation.html > > > > Otherwise we'll have to remove it. > > > > > > I'll have a look. > > > > I removed the Dev-C++ instructions since they were outdated, and the > > MinGW compiler shipped with Dev-C++ is 3.4.2, which we found to be > > incompatible to 3.4.5 with which the binaries are built. Since there > > were no news in Dev-C++ since 2005 it seems unlikely that this will > > change in future. Instead, I added links to the live.gnome.org pages. > > > > What about > > http://www.gtkmm.org/docs/gtkmm-2.4/docs/tutorial/html/chapter-msvc.html? I > > updated two or three paragraphs, but it still seems good and valid > > otherwise, although some of the content is already covered on the wiki > > page. > > Looking at what's left, I guess it should just be moved to a wiki page, > please. And that should mention MS Visual Studio 2008 as well as 2005. Done. I moved the instructions to http://live.gnome.org/gtkmm/MSWindows/UsingMSVC. > And the link here should point to your generic gtkmm Windows page on the > wiki: > http://gtkmm.org/docs/gtkmm-2.4/docs/tutorial/html/sec-packages-windows.html Fixed as well. Armin ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Let's try again compiling windows...
On Sat, 2008-10-25 at 11:13 -0400, Jam wrote: > I just downloaded gtkmm-win32-devel-2.14.1-3 and try to recompile an > application I had developed under gtkmm-win32-devel-2.10.11-1, but I get > a strange error: > > > -- Build: default in Console application --- > > Linking executable: TheProgram.exe > D:\XWin\bin\..\lib\gcc\mingw32\3.4.5\..\..\..\..\mingw32\bin\ld.exe: > cannot find -lfontconfig > collect2: ld returned 1 exit status > Process terminated with status 1 (0 minutes, 0 seconds) > 1 errors, 0 warnings > --- > > Specs > Windows XP > codeblocks-8.02-setup > MinGW-5.1.3 > MSYS-1.0.11-2004.04.30-1 > > What am I doing wrong? Why do you link against fontconfig? I don't think any of gtkmm or its dependencies needs it on Windows. Armin ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: gtkmm on Windows: Last steps
> > > > 1.2 > > > > I thought that applications would find the DLLs because they are in the > > > > same directory. Why is something in the PATH environment variable also > > > > needed? I don't understand why MS Visual Studio would need it either if > > > > we are using these "property pages". > > > > > > MSVC++ does not need it to build stuff, but to run or debug from within > > > the IDE. I'm not sure whether there is an option in MSVC++ to extend the > > > DLL search path that the property pages could set, but I'll check. > > > > That sounds rather strange. Please do check. It would be nice to remove > > the PATH change if possible. I checked. I was wrong. When running out of the IDE, the PATH variable doesn't need to be set to the gtkmm DLL directory. It's only required when running it outside the IDE. But I really do wonder how MSVC++ finds the correct DLL search path. So if we want to avoid the PATH change, should we just drop the runtime installer? Or, should we only set the PATH variable in the runtime installer, but not in the development one, without further asking the user? Armin ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: gtkmm on Windows: Last steps
On Sun, 2008-10-26 at 15:04 +0100, Murray Cumming wrote: > On Sun, 2008-10-26 at 12:37 +0100, Armin Burgmeier wrote: > > > > > > 1.2 > > > > > > I thought that applications would find the DLLs because they are in > > > > > > the > > > > > > same directory. Why is something in the PATH environment variable > > > > > > also > > > > > > needed? I don't understand why MS Visual Studio would need it > > > > > > either if > > > > > > we are using these "property pages". > > > > > > > > > > MSVC++ does not need it to build stuff, but to run or debug from > > > > > within > > > > > the IDE. I'm not sure whether there is an option in MSVC++ to extend > > > > > the > > > > > DLL search path that the property pages could set, but I'll check. > > > > > > > > That sounds rather strange. Please do check. It would be nice to remove > > > > the PATH change if possible. > > > > I checked. I was wrong. When running out of the IDE, the PATH variable > > doesn't need to be set to the gtkmm DLL directory. It's only required > > when running it outside the IDE. > > I thought we were all sure that the DLLs were found by them being in the > same directory as the executable? I am now confused. The executable is only in the same directory as the gtkmm DLLs when the application is distributed with an installer or a zip file. This works without problems. However, by default, when building an application, the executable is created into debug/ and release/ subdirectories in the project's directory, where the gtkmm DLLs normally aren't. Running it from that location does not work when running it from outside the IDE. > > But I really do wonder how MSVC++ finds > > the correct DLL search path. > > > > So if we want to avoid the PATH change, should we just drop the runtime > > installer? Or, should we only set the PATH variable in the runtime > > installer, but not in the development one, without further asking the > > user? > > First let's understand what's happening. Armin ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: gtkmm on Windows: Last steps
On Sun, 2008-10-26 at 16:15 +0100, Murray Cumming wrote: > On Sun, 2008-10-26 at 15:25 +0100, Armin Burgmeier wrote: > [snip] > > > > I checked. I was wrong. When running out of the IDE, the PATH variable > > > > doesn't need to be set to the gtkmm DLL directory. It's only required > > > > when running it outside the IDE. > > > > > > I thought we were all sure that the DLLs were found by them being in the > > > same directory as the executable? I am now confused. > > > > The executable is only in the same directory as the gtkmm DLLs when the > > application is distributed with an installer or a zip file. This works > > without problems. > > > > However, by default, when building an application, the executable is > > created into debug/ and release/ subdirectories in the project's > > directory, where the gtkmm DLLs normally aren't. Running it from that > > location does not work when running it from outside the IDE. > > I think that's OK. I think we should just document that. > > So, I think we can remove the PATH stuff from the installer. > > ]snip]h > > > > So if we want to avoid the PATH change, should we just drop the runtime > > > > installer? > > I thought we needed the runtime installer to provide the stripped mingw > DLLs. We could still add these into a redist/ folder in the development installer, and tell people to use these for redistribution. That way, they only need to download one package, not an additional zip or runtime installer for redistribution. > > Or, should we only set the PATH variable in the runtime > > > > installer, but not in the development one, without further asking the > > > > user? > > I don't think we should set it in either one. Relying on PATH settings > is just an invitation to confusing problems. I'd rather just have a .zip > file containing those stripped MinGW DLLs and not have an actual runtime > installer. Armin ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Cannot build static libraries under mingw
On Sun, 2008-11-09 at 21:16 +0400, Alexander Shaduri wrote: > Hello, > > I'm having trouble building static glibmm with mingw > cross-compiler (linux build, windows target). > No problems with shared DLLs so far. > > The configure line is > ./configure --disable-shared --enable-static --target=i386-mingw32msvc \ > --host=i386-mingw32msvc --build=i686-linux --prefix=/opt/cross-tools > > Make stops with: > > . > Making all in giomm_simple > make[3]: Entering directory > `/0S/a11/0build/CROSS/mm-2.14-gcc43/glibmm-2.18.1/tests/giomm_simple' > /bin/sh ../../libtool --tag=CXX --mode=link i386-mingw32msvc-g++ > -mms-bitfields -O2 -march=i686 -mtune=generic -mms-bitfields -mms-bitfields > -Wall -Wno-long-long -o test.exe main.o ../../glib/glibmm/libglibmm-2.4.la > ../../gio/giomm/libgiomm-2.4.la -L/opt/cross-tools/i386-mingw32msvc/lib > -L/target/lib -lsigc-2.0 -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -lintl > i386-mingw32msvc-g++ -mms-bitfields -O2 -march=i686 -mtune=generic > -mms-bitfields -mms-bitfields -Wall -Wno-long-long -o test.exe main.o > ../../glib/glibmm/.libs/libglibmm-2.4.a > -L/opt/cross-tools/i386-mingw32msvc/lib -L/target/lib > ../../gio/giomm/.libs/libgiomm-2.4.a -lgio-2.0 > /0S/0tmp/0build/CROSS/mm-2.14-gcc43/glibmm-2.18.1/glib/glibmm/.libs/libglibmm-2.4.a > /opt/cross-tools/i386-mingw32msvc/lib/libsigc-2.0.a -lgobject-2.0 > -lgmodule-2.0 -lglib-2.0 -lintl > ../../gio/giomm/.libs/libgiomm-2.4.a(file.o):file.cc:(.text+0x1fbd): > undefined reference to `__imp___ZN4Glib10ObjectBaseD2Ev' > ../../gio/giomm/.libs/libgiomm-2.4.a(file.o):file.cc:(.text+0x2009): > undefined reference to `__imp___ZN4Glib10ObjectBaseD2Ev' > ../../gio/giomm/.libs/libgiomm-2.4.a(file.o):file.cc:(.text+0x20bd): > undefined reference to `__imp___ZN4Glib10ObjectBaseD2Ev' > ../../gio/giomm/.libs/libgiomm-2.4.a(file.o):file.cc:(.text+0x2114): > undefined reference to `__imp___ZN4Glib10ObjectBaseD2Ev' > ../../gio/giomm/.libs/libgiomm-2.4.a(file.o):file.cc:(.text+0x21a1): > undefined reference to `__imp___ZN4Glib10ObjectBaseC2Ev' > ../../gio/giomm/.libs/libgiomm-2.4.a(file.o):file.cc:(.text+0x2206): > undefined reference to `__imp___ZN4Glib10ObjectBaseD2Ev' > ../../gio/giomm/.libs/libgiomm-2.4.a(file.o):file.cc:(.text+0x22d1): > undefined reference to `__imp___ZN4Glib10ObjectBaseC2Ev' > ../../gio/giomm/.libs/libgiomm-2.4.a(file.o):file.cc:(.text+0x233f): > undefined reference to `__imp___ZN4Glib10ObjectBaseD2Ev' > ../../gio/giomm/.libs/libgiomm-2.4.a(file.o):file.cc:(.text+0x2421): > undefined reference to `__imp___ZN4Glib10ObjectBaseC2Ev' > ../../gio/giomm/.libs/libgiomm-2.4.a(file.o):file.cc:(.text+0x2486): > undefined reference to `__imp___ZN4Glib10ObjectBaseD2Ev' > ../../gio/giomm/.libs/libgiomm-2.4.a(file.o):file.cc:(.text$_ZN4Glib19wrap_auto_interfaceIN3Gio4FileEEEPT_P8_GObjectb[Gio::File* > Glib::wrap_auto_interface(_GObject*, bool)]+0x50): undefined > reference to `__imp___ZN4Glib10ObjectBase20_get_current_wrapperEP8_GObject' > ../../gio/giomm/.libs/libgiomm-2.4.a(inputstream.o):inputstream.cc:(.text+0x4ab): > undefined reference to `__imp___ZN4Glib6ObjectD2Ev' > ../../gio/giomm/.libs/libgiomm-2.4.a(inputstream.o):inputstream.cc:(.text+0x530): > undefined reference to `__imp___ZN4Glib6ObjectD2Ev' > > -- > About 70 KB of similar output follows. > -- > > ../../gio/giomm/.libs/libgiomm-2.4.a(loadableicon.o):loadableicon.cc:(.text+0x5f1): > undefined reference to `__imp___ZN4Glib10ObjectBaseC2Ev' > ../../gio/giomm/.libs/libgiomm-2.4.a(loadableicon.o):loadableicon.cc:(.text+0x656): > undefined reference to `__imp___ZN4Glib10ObjectBaseD2Ev' > ../../gio/giomm/.libs/libgiomm-2.4.a(loadableicon.o):loadableicon.cc:(.text$_ZN4Glib19wrap_auto_interfaceIN3Gio12LoadableIconEEEPT_P8_GObjectb[Gio::LoadableIcon* > Glib::wrap_auto_interface(_GObject*, bool)]+0x50): > undefined reference to > `__imp___ZN4Glib10ObjectBase20_get_current_wrapperEP8_GObject' > collect2: ld returned 1 exit status > make[3]: *** [test.exe] Error 1 > make[3]: Leaving directory > `/0S/a11/0build/CROSS/mm-2.14-gcc43/glibmm-2.18.1/tests/giomm_simple' > > > I tried building both static and shared libraries together, > but there seems to be some kind of binary incompatibility > between them, because while the build succeeded, I got > similar errors when linking my program against these static libraries. > Seems to be related to marking functions with dllimport. I don't think building gtkmm or glibmm as a static library is supported, and I don't know anybody who had success with this. Is there a specific reason why you can't simply use shared libraries? > Thanks, > Alexander Armin ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Cannot build static libraries under mingw
On Mon, 2008-11-10 at 21:05 +0400, Alexander Shaduri wrote: > On Mon, 10 Nov 2008 17:52:22 +0100 > Armin Burgmeier <[EMAIL PROTECTED]> wrote: > > > On Sun, 2008-11-09 at 21:16 +0400, Alexander Shaduri wrote: > > > Hello, > > > > > > I'm having trouble building static glibmm with mingw > > > cross-compiler (linux build, windows target). > > > No problems with shared DLLs so far. > > > > > > The configure line is > > > ./configure --disable-shared --enable-static --target=i386-mingw32msvc \ > > > --host=i386-mingw32msvc --build=i686-linux --prefix=/opt/cross-tools > > > I don't think building gtkmm or glibmm as a static library is supported, > > and I don't know anybody who had success with this. Is there a specific > > reason why you can't simply use shared libraries? > > Well, I was hoping that the size of my statically linked exe would > be less than total size of all gtkmm dlls + my exe. Makes distribution > easier under windows. And I can't use the shared gtkmm installer, > because I'm using mingw's gcc 4.3, which is binary-incompatible > with gcc 3.4 (which the dlls in gtkmm installer seem to be built with). > Shared gtk installer doesn't have this problem (no C incompatibility > there). > > Are you sure it's not supported as in "won't work, no matter how > you try"? It's not supported as in "There's no official guarantee that it will work. It might or might not." > Because, if I understand it correctly, it's a purely windows-specific > problem, solvable by adjusting the build system and macros to > not define some of the windows dll magic. Unfortunately, I lack the > skills needed to produce a patch (gtkmm's autotools stuff seems to be > beyond my grasp). I won't have a look at this myself as I don't think it would be a big gain to allow static linking. But surely a patch would be considered. > Thanks, > Alexander Armin ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: What am I doing wrong?
On Tue, 2008-11-11 at 08:30 -0500, Jam wrote: > This is not the first time I am posting this question, and I am > beginning to wonder if what I am facing is a bug or if it is indeed a > mistake at my end. Let me explain to you what I do when trying to > compile; so that you might be able to spot what I am doing wrong. > I am using > gtkmm-win32-devel-2.14.1-3.exe > > under Windows XP and using Code::Blocks 8.2 as my IDE, GCC compiler, > MSYS-1.0.11-2004.04.30-1 and MinGW-5.1.3 > > Using the Prompt, I type: > $> pkg-config gtkmm-2.4 --cflags > cflag_parameters.txt > $> pkg-config gtkmm-2.4 --libs > libs_parameters.txt > > I then open the cflags_parameters.txt and libs_parameters.txt files and start > Code::Blocks IDE. > I then copy the content in the cflags_parameters.txt to Code::Blocks, as > follows: >Project->Building Options->Compiler Settings->'Other Options' tab > > And the content of the libs_paramenters.txt as follows >Project->Building Options->Linker Settings->'Other Linker Options' box > > The values, or parameters, in the two above text files are: > > CFLAGS > ~~ > -mms-bitfields -ID:/XWin/include/gtkmm-2.4 -ID:/XWin/lib/gtkmm-2.4/include > -ID:/XWin/include/glibmm-2.4 -ID:/XWin/lib/glibmm-2.4/include > -ID:/XWin/include/giomm-2.4 -ID:/XWin/lib/giomm-2.4/include > -ID:/XWin/include/gdkmm-2.4 -ID:/XWin/lib/gdkmm-2.4/include > -ID:/XWin/include/pangomm-1.4 -ID:/XWin/include/atkmm-1.6 > -ID:/XWin/include/gtk-2.0 -ID:/XWin/include/sigc++-2.0 > -ID:/XWin/lib/sigc++-2.0/include -ID:/XWin/include/glib-2.0 > -ID:/XWin/lib/glib-2.0/include -ID:/XWin/lib/gtk-2.0/include > -ID:/XWin/include/cairomm-1.0 -ID:/XWin/include/pango-1.0 > -ID:/XWin/include/cairo -ID:/XWin/include/libpng12 -ID:/XWin/include/atk-1.0 > > > LIBS > > -LD:/XWin/lib -lgtkmm-2.4 -lgiomm-2.4 -lgdkmm-2.4 -latkmm-1.6 -lgtk-win32-2.0 > -lpangomm-1.4 -lcairomm-1.0 -lglibmm-2.4 -lsigc-2.0 -lgdk-win32-2.0 -latk-1.0 > -lgio-2.0 -lgdk_pixbuf-2.0 -lpangowin32-1.0 -lgdi32 -lpangocairo-1.0 > -lpango-1.0 -lcairo -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -lintl > > I am not sure if what I am doing is right, but I would really appreciate some > help. Do you still get this error? D:\XWin\bin\..\lib\gcc\mingw32\3.4.5\..\..\..\..\mingw32\bin\ld.exe: cannot find -lfontconfig If so, I don't see how fontconfig comes into play. It's not listed in the libraries linked against. I don't know Code::Blocks, but maybe its hidden behind some option in the IDE, of which you wouldn't expect adding fontconfig to the libraries? > Thanks folks Armin ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Win32 HWND
On Fri, 2008-11-14 at 00:08 +0100, Nikola Moraca wrote:
> I want to initialize Direct3D on a gtkmm window. Is there a way to
> obtain a win32 HWND for a Gtk::Window?
#include
HWND hwnd_from_window(Gtk::Window& window)
{
return reinterpret_cast(
GDK_WINDOW_HWND(window.get_window()->gobj()));
}
Note that this requires that there exists a GdkWindow for the
Gtk::Window. This is only the case after realization of the widget. You
can connect to signal_realize() of the window to initialize the Direct3D
stuff directly after the widget was realized.
> Thanks
Armin
___
gtkmm-list mailing list
gtkmm-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: [win32] Glib::IOChannel error?
On Fri, 2008-11-14 at 18:11 +0100, Köntös Eszter wrote:
> Hi all,
>
> I'm writing a crossplatform program that executes another application
> and reads from it's output. I'm using Glib::spawn_async_with_pipes to
> solve the process handling and i handle the pipes with Glib::IOChannel.
> The problem is that, if the application writes a string to it's output
> that contains central-european characters (like: á, é, ü, ő, etc.) than
> Glib::IOChannel::read_line throws the following exception:
Glib::IOChannel does implicit charset conversion, though I'm not exactly
sure from what to what. But if you know the program you are spawning
uses some specific character set (such as ISO-8859-2 (Central European))
for output, and expect to receive it as such in your application, then
you can try to disable that automatic charset conversion via
some_io_channel->set_encoding("");
> glibmm-CRITICAL ** :
> unhandled exception (type: Glib::Error) in signal handler:
> domain: g_convert_error
> code: 1
> what: invalid byte sequence in conversion input /the message is
> localized so i tried to translate it to english, hope it's fits to the
> original message/
>
> I have to use central-european charset, but i don't have any idea, how
> to solve this problem. Furthermore i can't catch any exceptions
> /Glib::IOChannelError or Glib::ConvertError, nor Glib::Error/, except (...).
If you are using the official gtkmm installer, then this might be
because of ABI incomptabilities between your Compiler (gcc 4.2.1) and
the one the official binaries were built with (gcc 3.4.5). You'll also
have trouble catching other exceptions thrown by glibmm or gtkmm then.
> This exception thrown only on windows; on linux everything works
> perfectly. I'm using MinGW compiler (gcc-4.2.1-sjlj-2,
> mingw32-make-3.81, mingwrt-3.15, w32api-3.12, binutils-2.18.50),
> gtk-2.14.4-1, gtkmm-2.14.1-3 and windows-1250 charset.
>
> The code:
> void ProcessHandler::spawn(const Glib::ArrayHandle& argv)
> {
> try {
> Glib::spawn_async_with_pipes(Glib::get_current_dir(),
> argv,
> Glib::SpawnFlags(0)|Glib::SPAWN_SEARCH_PATH,
> sigc::slot(),
> &child_,&stdin_,&stdout_,&stderr_);
> } catch (Glib::SpawnError& ex) {...}
> } catch (Glib::Error& ex) {...}
> ...
> #ifdef WIN32
> ioch_in_=Glib::IOChannel::create_from_win32_fd(stdin_);
> ioch_out_=Glib::IOChannel::create_from_win32_fd(stdout_);
> ioch_err_=Glib::IOChannel::create_from_win32_fd(stderr_);
> #else
> ioch_in_=Glib::IOChannel::create_from_fd(stdin_);
> ioch_out_=Glib::IOChannel::create_from_fd(stdout_);
> ioch_err_=Glib::IOChannel::create_from_fd(stderr_);
> #endif
> }
>
> Glib::IOStatus ProcessHandler::read_line_from_out(Glib::ustring& str)
> {
> try {
> return ioch_out_->read_line(str);
> } catch (Glib::IOChannelError& ex) {...}
> } catch (Glib::ConvertError& ex) {...}
> } catch (Glib::Error& ex) {...}
> } catch (...) {...}
Armin
___
gtkmm-list mailing list
gtkmm-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: (glibmm) Deeper level of inheritance in own type of objects - how-to or plans to implement?
On Wed, 2008-11-26 at 03:00 +0200, Cristi P wrote: > I struggled some time ago with doing object inheritance at more than > one level, like: > Glib::Object -> MyObjectA (w/ some properties for example) -> > MyObjectB (w/ additional properties and/or overriden [virtual] > functions) > While the gtkmm says about using "inheritance" I couldn't solve the > problem the way I expect from a C++ library. So, unless I'm mistaken > somewhere, it *almost* is impossible. > At that time I did some hard stuff to overcome that problem (with > implications on how you write your objects) but now I'm getting in > even bigger problems, when > instead of starting from Glib::Object I start from some other C++ > wrapper, like, for example, > Clutter::Group -> MyObjectA -> MyObjectB > > This is really annoying since I want to use C++ w/ the various > wrappers in more then a simplistic GUI wrapper and with one level of > inheritance :-( > > So far the problems that I think I saw: > a) it seems that the glibmm::object* source files (or at least some > ObjectBase constructors) are assuming derived objects are mostly C++ > wrappers or one level deeper > b) (from memory) saw some strange things about declaring the wrapper's > type as being the C actual type instead of the just created type ? >I think there was also a comment like "allow g_peek_class..." to > work !? > c) wrappers around methods want to "peek" at the original C object to > call some functions for example, and are assuming current object has > its parent type the C object, which, in case it runs on > object MyObjectB, it is a wrong assumption. I don't really understand what your problem is. Could you be more specific on what the actual problem is when you have a Glib::Object -> A -> B inheritance tree? And maybe provide a compilable test case? Maybe you need to create an own GType for each of your derived classes. This can be accomplished by calling the Glib::ObjectBase constructor with the type name as a string. But this is only a guess. > Can't the wrapping code gkmmproc is building, try, since it really > knows (or could) the C type, work directly on that type (w/ > g_peek_class...) instead of relying on the > actual object instance type being derived directly from the C type? > d) I also saw some comments about skiping some virtual function calls. > I wonder: > 1) what's the optimization they're talking about? (haven't > checked sources enough) When a C++ wrapper is created, such as Gtk::Window, and a C virtual function is called on the underlying GObject, such as the default signal handler for the "show" signal, then we can skip calling the virtual on_show() member function of the C++ object, because it cannot be overriden anyway. However, if the same (C) virtual function is called on an instance of a derived class, such as ExampleWindow inheriting from Gtk::Window, then ExampleWindow could have overriden the on_show() (C++) virtual function, so we need to call it. > 2) (would have to check) - can they also be a source of problems > for the thing I want to have fixed? I don't think so. > Anyway, I might be mistaken, and if there is a method to accomplish > what I said in the beginning that I want, I'd be glad to hear it! > > Thanks. Armin ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: gtkmm documentation for gtkmm-win32-devel-2.14.1-3
On Wed, 2008-12-03 at 20:40 -0500, Jam wrote: > Hello folks, > I am using 'gtkmm-win32-devel-2.14.1-3' and after installing it I cannot > find the documentation, there is the first page only, index.html, but > the rest of the pages are not there. I not always have access to the > Internet, thus I need to have this information in my laptop. > > Thanks I'll check the installer. It should also create documentation shortcuts in it's start menu folder. Can you access the documentation from there? Armin ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: gtkmm documentation for gtkmm-win32-devel-2.14.1-3
On Thu, 2008-12-04 at 13:04 -0500, Jam wrote: > Armin Burgmeier wrote: > > On Wed, 2008-12-03 at 20:40 -0500, Jam wrote: > > > > > Hello folks, > > > I am using 'gtkmm-win32-devel-2.14.1-3' and after installing it I cannot > > > find the documentation, there is the first page only, index.html, but > > > the rest of the pages are not there. I not always have access to the > > > Internet, thus I need to have this information in my laptop. > > > > > > Thanks > > > > > > > I'll check the installer. > > > > It should also create documentation shortcuts in it's start menu folder. > > Can you access the documentation from there? > > > > Armin > > > > > > > Thanks for your prompt response. > Yes, I have access to: > file:///D:/XWin/share/doc/gtkmm-2.4/docs/reference/html/index.html > and from there I can go to the 'Main Page', 'Widgets' and 'Namespace' > but not to the book, which, as a beginner, I depend so much on. Ah, so it's only the book what's missing. I updated the installer to gtkmm 2.14.3, also shipping the book. ftp://ftp.gnome.org/pub/GNOME/binaries/win32/gtkmm/2.14/ Armin ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Change font,size of column title
On Thu, 2008-12-11 at 12:03 -0700, Sirisha Muppavarapu wrote: > Hi there... > > I am looking for the method/piece of code which changes the > font/size,etc of the column title of the columns added to the treeview. > > treeView.modify_font(Pango::FontDescription(font)); > > doesn't seem to be helping. It changes the row's font but not the column > title's font. gtkmm archive emails are of no help. I see many similar > questions but no reply is posted! Any pointers in this direction is > highly appreciated. You could try using Gtk::TreeViewColumn::set_widget. Set a Gtk::Label with your desired font settings as the column's widget. > Thanks Armin ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Change font,size of column title
On Thu, 2008-12-11 at 13:43 -0700, Sirisha Muppavarapu wrote: > I am using Gtk::TreeModelColumn as given in the gtk tutorials below: > > http://www.gtkmm.org/docs/gtkmm-2.4/docs/tutorial/html/chapter-treeview.html#sec-treeview-model > > Anything to work around with the Gtk::TreeModelColumn to set the column > title font? I was speaking of Gtk::TreeViewColumn, not Gtk::TreeModelColumn. If you associate a model column to a TreeView via TreeView::append_column, then append_column returns an integer ID that can be used with TreeView::get_column to obtain the Gtk::TreeViewColumn. Alternatively, you can create the Gtk::TreeViewColumn directly, and pass this to TreeView::append_column. > Thanks > Sirisha Armin ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: About Gtk::Bin?
On Sun, 2008-12-14 at 13:30 +0100, Simon Fuhrmann wrote: > Hi Robert, > > yes, I changed the code a bit, but with no affect. There seems to be a > bug with Gtk::Bin or a reason I don't know. Here is a simplest-possible > testcase that confirms that it does not work (at least for me and Zhu): GtkBin does not handle size requisition or allocation. You'll need to do this yourself by overriding the on_size_request and on_size_allocate virtual functions. Alternatively, you can derive from a container which handles this already, such as GtkFrame, maybe setting the shadow type to SHADOW_NONE to remove the visible border around it. ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Dynamically adding widgets to HBox created with glade
On Wed, 2008-12-10 at 13:00 -0800, kondrara wrote:
> Hi,
>
> I created a dialog with glade. In this dialog, I have a HBox with two
> widgets, one is the label and the other widget will be determined at the
> runtime.
>
> So, in my code I got the reference to the HBox using get_widget after
> loading the glade file and then I am adding my widget to the HBox using the
> reference from the XML. The code compiles properly, but I can never see the
> widget.
>
> xmlRef = Gnome::Glade::create("myglade.glade");
> Gtk::HBox *pMyHBox;
> xmlRef->get_widget("myHBox", pMyHBox);
>
> Lets us assume I need to add one more label the the "myHBox"
>
> Gtk::Label lab("new");
> pMyHBox->add(lab); or
> pMyHBox->pack_start(lab); or
> pMyHBox->pack_end(lab); etc..
>
> I tried all possible ways to show it.. Unfortunately, I couldn't see it on
> my dialog.
>
> Please help me where I was wrong...
Did you call show() on your dynamically added widget?
> Thanks in Advance..
>
> -k
Armin
___
gtkmm-list mailing list
gtkmm-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: How can I get a TextLineEdit object, and capture a key event?
On Sun, 2008-12-14 at 04:53 +0800, Kermit Mei wrote: > Hello, I'm a newbie for gtkmm, in my program, I need a TextEdit which > can just handle only one line text? > > And I must capture the keyboard's event in it. > > For example, when I press the key "5", it should show the text "%" but > not "5". Gtk::Entry is such a one-line-text-editing widget. signal_insert_text() (belonging to the Gtk::Editable base class) is emitted every time text was inserted into the widget, so I think you can use it to replace special characters by others. > Thanks. > Kermit Mei Armin ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Problem with Gtk::manage in Visual Studio 2008
On Sat, 2008-12-20 at 16:55 +0100, klaus triendl wrote: > Pedro Sousa schrieb: > > Yes, I'm using the correct version of the Property Sheet, file > > gtkmm-vc90-2_4 and gtkmm-vc90-d-2_4 for the Visual Studio 2008. > > This error happens because one module (exe/dll) allocated memory which > is then freed in another module. > So in your case I suppose that the Gtk::VBox is created in your exe but > freed in the gtkmm module or its dependent modules. > > > 1) gtkmm uses the dynamic runtime > > Did you follow the instruction on http://live.gnome.org/gtkmm/MSWindows > to use the "Multi-threaded Debug" runtime, which is the static runtime? > As far as I can tell this is incorrect because gtkmm was linked against > the dynamic runtime library. > To solve your problem use the dynamic runtime - "Multi-threaded Debug" > for the Debug configuration or "Multi-threaded Release" for the Release > configuration. You might be right here. I'll change the Wiki page accordingly if Pedro confirms that this is the problem he's experiencing. > 2) c++ doesn't have yet a model for modules with different address spaces > > The instructions for MSVC say that it is necessary to use the same > runtime as gtkmm does and this might be necessary for various reasons - > which should be clearly documented I think because it isn't strictly > necessary to use the same runtime in your program like the dlls you link to. I'd actually like to keep this section quite simple, without too much complication. If people use the same runtime everywhere, then things will work fine. As soon as someone violates that rule, they must know what they are doing. > One thing to ensure is as I indicated above that memory allocated in one > module should be deallocated in that very same module - it always > depends on your needs but I believe that this is an important good practice. I don't think we can guarantee this for gtkmm. For example, the whole point of Gtk::manage is that the caller creates the object, but delegates ownership to gtkmm. > Glibmm/Gtkmm classes should have their own memory management functions > (operator new/operator delete - sigc has it btw). How would this look like? Would this mean that all gtkmm (and derived) objects are allocated with our own operator new, and deallocated with our own operator delete? Patches would be welcome, I think. > Also Glib::ustring and other classes handling resources are subject to > the same-module requirement. > If you use the same dynamic runtime like all modules for your program as > gtkmm obviously assumes then there is no problem because all modules use > e.g. the msvcp90.dll and msvcr90.dll. But if you have modules that link > against their own static runtime and modules that use other dynamic > runtimes (like msvcp80.dll and msvcr80.dll) those module-bound > allocation/deallocation operations are important. Armin ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Please wrap GtkObject::destroy signal
On Mon, 2008-12-29 at 00:52 +0100, Mathias Hasselmann wrote: > Please wrap the GtkObject::destroy signal: The signal is useful to > figure out that objects like windows in WINDOW_POPUP mode are destroyed. > > Those windows are ignored by the window manager and therefore don't > receive the GtkWindow::delete-event. Of course I could connect to other > auxiliary signals like "unrealize" or "unmap", but also can get this > signal without actually destroying the window, so connecting to those > signals would be hacks only working on occasion. I really want to know > when the widget is destroyed. > This signal is also convenient for terminating main loops as it has the > same signature as gtk_main_quit()/Gtk::Main::quit(). Actually I wonder > why that many tutorials suggest connecting to the delete-event signal > for terminating the main loop: The delete-event and gtk_main_quit() have > an incompatible signature and I've never read that the return value of > void functions always is zero. Is there a reason you can't use the "hide" signal? I think most gtkmm programs use this for terminating from the main loop, including the Gtk::Main::run(Gtk::Window&) overload. It also has the same signature as Gtk::Main::quit(). Normally one really doesn't need the GtkObject::destroy signal in C++. I would be surprised to see a use case where there is no cleaner way without using it. Another approach might be to subclass Gtk::Window, and do things in that subclass's destructor. > Ciao, > Mathias Armin ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Problems enumerating printers
On Tue, 2008-12-30 at 00:09 +0100, Tor Krill wrote:
> Hi,
>
> I have a bit of a newbie problem. Im trying to enumerate printers on a
> system. Doing so i get a lot off errors. Cut down version of code:
>
> --8<--
> #include
> #include
> #include
>
> using namespace std;
>
> static bool enumerate(const Glib::RefPtr& printer){
>
> cout << "Printer:" return false;
> }
>
>
> int main(int argc, char *argv[]) {
> Gtk::Main kit(argc, argv);
>
> Gtk::enumerate_printers(sigc::ptr_fun(enumerate),true);
>
> return 0;
> }
> --8<--
>
> Output when executing:
>
> --8<--
> t...@sid:~/tests/cpp_enumerate$ ./enumtest
> Printer:Print to File
>
> (enumtest:30909): GLib-GObject-CRITICAL **: g_object_unref: assertion
> `G_IS_OBJECT (object)' failed
> Printer:QL-500
> Printer:tors
>
> (enumtest:30909): GLib-GObject-CRITICAL **: g_object_unref: assertion
> `G_IS_OBJECT (object)' failed
>
> (enumtest:30909): GLib-GObject-CRITICAL **: g_object_unref: assertion
> `G_IS_OBJECT (object)' failed
> --8<--
This was a bug in gtkmm. I have fixed it in SVN (gtkmm-2-12, gtkmm-2-14
and trunk). Until that fix hits a tarball release you can use the C API
directly:
#include
gboolean enumerate(GtkPrinter* printer_, gpointer data)
{
Glib::RefPtr printer(printer_, true);
std::cout << printer->property_name() << std::endl;
}
gtk_enumerate_printers(enumerate, NULL, NULL, TRUE);
You'll also need to specify gtk+-unix-print-2.0 in pkg-config for this to work.
Armin
___
gtkmm-list mailing list
gtkmm-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Problem with Gtk::manage in Visual Studio 2008
On Sat, 2008-12-20 at 18:42 +0100, Armin Burgmeier wrote: > On Sat, 2008-12-20 at 16:55 +0100, klaus triendl wrote: > > Pedro Sousa schrieb: > > > Yes, I'm using the correct version of the Property Sheet, file > > > gtkmm-vc90-2_4 and gtkmm-vc90-d-2_4 for the Visual Studio 2008. > > > > This error happens because one module (exe/dll) allocated memory which > > is then freed in another module. > > So in your case I suppose that the Gtk::VBox is created in your exe but > > freed in the gtkmm module or its dependent modules. > > > > > > 1) gtkmm uses the dynamic runtime > > > > Did you follow the instruction on http://live.gnome.org/gtkmm/MSWindows > > to use the "Multi-threaded Debug" runtime, which is the static runtime? > > As far as I can tell this is incorrect because gtkmm was linked against > > the dynamic runtime library. > > To solve your problem use the dynamic runtime - "Multi-threaded Debug" > > for the Debug configuration or "Multi-threaded Release" for the Release > > configuration. > > You might be right here. I'll change the Wiki page accordingly if Pedro > confirms that this is the problem he's experiencing. Pedro, any luck? Armin ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Using Gdk::Pixbuf from multiple threads.
On Fri, 2009-01-02 at 17:09 +0100, Germán Diago wrote: > Hello. I'm trying to scale (make thumbnails) of pictures in a thread > pool. But I get random > crashes. The program (in the slot that goes to the thread pool) uses > Gdk::Pixbuf to scale > images. > I push a task to the thread pool but I don't know why, it crashes. Is > Gdk::Pixbuf thread-safe? I don't think so. You'll need to do locking on your own if you access the same pixbuf concurrently. You should probably use Glib::Mutex instead of the GDK lock, though. > I'm forgetting anything? I use Glib::thread_init at the beginning of > the program. Do I need to > use gdk_threads_init()? Thanks in advance. Armin ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: A typo in win32 installer english.nsh
On Sun, 2009-01-18 at 00:56 +1100, Dancefire wrote: > Hi, > > There is a typo in \gtkmm\win32_installer\translations\english.nsh. > The patch is attached. There are some strings that are no longer used but still in the translation files, such as the one with the typo you found. I removed those strings from the translation files. Thanks. Armin ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Simplified Chinese translation for gtkmm win32 installer
On Sun, 2009-01-18 at 00:48 +1100, Dancefire wrote: > Hi, > > I finished a Simplified Chinese translation for gtkmm win32 installer. > LANG=zh-cn. here is the patch. Thanks. I have committed this. I don't see the Chinese translation when I run the installer on an English Windows system. I suppose this is because of the installer recognizing that it would require a different codepage for it, and that it works properly on a Chinese system. Armin ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: using MinGW for Gtkmm on windows
On Mon, 2009-01-19 at 19:33 -0800, lovekie wrote: > I use the official installer to install the gtkmm, and I only want use MinGW > on windows to compile the program.(I don't want install the visual studio or > viusal studio express, they are too big.) I can successful compile and link > the simple test program, but when I try to run it. It said can't found > msvcr80.dll. How can I solve it? Does the Gtkmm need the visual stuido? I don't think msvcr80.dll is required by gtkmm when used with MinGW. If it is, then it's probably a bug. You can use a tool such as Dependency Walker [1] to find out which library pulls in msvcr80.dll. Armin [1] http://dependencywalker.com/ ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Glib::signal_idle().connect AND FileChooser
On Thu, 2009-02-19 at 13:23 +0100, Xavier Larrodé wrote: > Hi all, > I'm working on a Ogre3D viewer with gtkmm on linux and windows. > > > I'm using the last version of gtkmm for windows the 2.14.3-2 and it > seems that my idle function to update the viewer render breaks the > FileChooserDialog Render. > Actually the FileChooserDialog open, but nothing is displayed about > the current directory, so i can't select any files. > > > I made a simple video to illustrate the problem : > http://www.dailymotion.com/xabila/video/14150703 > > > > At the (half) of the video, i comment the Glib::signal_idle().connect > and after the dialog is allright, but my OgreScene is not updated ;) > > > Here is my code to update the viewer : > Glib::signal_idle().connect(sigc::mem_fun(this, > &MEApplication::idleA)); > > > > It was working fine with the 2.10-8.1 of gtkmm... > > > > > Maybe i'm doing something wrong? > Any ideas? Does the problem also happen on Linux? Does it happen when using the plain C API? Just a guess, but maybe lowering the priority of the idle function fixes the problem? (note: the higher the priority number the lower the priority) > Thanks a lot and sorry for my english... > > > > > xavier Armin ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Which control structure is faster?
On Thu, 2009-02-19 at 17:11 +0100, Dimitri Holz wrote:
> Which control structure is faster inside a loop (for, while or do-while)?
switch is probably faster because the compiler can use a lookup table.
But the compiler maybe optimizes the if version to do the same as the
switch version anyway. That's only theoretical, though. If you want to
know for sure, you should profile your code.
> 1)--
>
> switch(x)
> {
>case 1:
>{
>.;
>break;
> }
> case 2:
> {
>;
>break;
> }
> }
>
> 2)-
>
>
> if(x = = 1)
> {
> ;
> break;
> }
> if(x = = 2)
> {
> ;
> break;
> }
Armin
___
gtkmm-list mailing list
gtkmm-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: GIOmm on windows
On Thu, 2009-02-19 at 19:03 +, Pedro Sousa wrote: > Hi to everyone, > > I need to read some files in a application developed for windows OS. Can > I use GIOmm for accessing files on windows on windows? I think few functionality such as file monitoring is not (yet?) available on Windows, but generally yes, giomm works on Windows. We are using it in Glom and Gobby. > My best regards > Pedro Armin ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Windows installers for gtkmm development and runtime environments
On Sat, 2009-02-28 at 14:26 -0600, Philip Allison wrote:
> Hullo all,
> I've been looking at getting a little gtkmm app I wrote up and running
> on Windows using MinGW, and have run into a few rough edges. Firstly,
> although the glib-gettextize binary is included, the tool doesn't work,
> because the ${prefix}/share/glib-2.0 directory and its contents aren't
> included in the development environment - fortunately I dual boot and
> was able to copy them from a Linux installation with a nearby version of
> glib.
I will include the files into the next installer version. Thanks.
> Secondly, if you're going to include glib-gettextize, it might be
> nice to to include related utilities such as intltool. :)
glib-gettextize is shipped because it is part of glib. However, intltool
isn't. It's not contained in the GTK+ all-in-one-bundle either.
> My main problem though is that now I have the development environment
> installed, and my application built, I want to start thinking about
> building an installer - but I cannot install the runtime environment
> (which contains the versions of the DLLs recommended for redistribution)
> without uninstalling the development environment! This is quite
> inconvenient for someone with a limited number of Windows machines at
> their disposal. Any recommendations?
You could copy the DLL files from the runtime installer somewhere, and
then install the development one again. Or, simply run strip on the DLLs
from the development installer, which removes the debugging symbols.
For the next installer version, we plan to only ship one kind of
installer (a development installer which contains the files to
redistribute in a separate directory), so this should be fixed there
too. See also this discussion:
http://mail.gnome.org/archives/gtkmm-list/2008-October/msg00146.html
>
> Regards
> --
> Phil
Armin
___
gtkmm-list mailing list
gtkmm-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Windows installers for gtkmm development and runtime environments
On Mon, 2009-03-02 at 10:08 +0100, Murray Cumming wrote:
> On Sun, 2009-03-01 at 12:13 +0100, Armin Burgmeier wrote:
> > On Sat, 2009-02-28 at 14:26 -0600, Philip Allison wrote:
> > > Hullo all,
> > > I've been looking at getting a little gtkmm app I wrote up and running
> > > on Windows using MinGW, and have run into a few rough edges. Firstly,
> > > although the glib-gettextize binary is included, the tool doesn't work,
> > > because the ${prefix}/share/glib-2.0 directory and its contents aren't
> > > included in the development environment - fortunately I dual boot and
> > > was able to copy them from a Linux installation with a nearby version of
> > > glib.
> >
> > I will include the files into the next installer version. Thanks.
>
> Please check if the GTK+ installer has the same problem.
If you mean the GTK+ bundle zip, then no, it hasn't.
Armin
___
gtkmm-list mailing list
gtkmm-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Windows installers for gtkmm development and runtime environments
On Mon, 2009-03-02 at 11:16 +0100, Murray Cumming wrote: > On Mon, 2009-03-02 at 11:00 +0100, Armin Burgmeier wrote: > > > > I will include the files into the next installer version. Thanks. > > > > > > Please check if the GTK+ installer has the same problem. > > > > If you mean the GTK+ bundle zip, then no, it hasn't. > > Could you file a bug for that then? It seems like a bug to me. It seems like a bug that the GTK+ bundle does _not_ have the problem? To clarify: The GTK+ bundle contains the files in share/glib-2.0/ which exist on my Linux computer in /usr/share/glib-2.0, but our gtkmm installer doesn't. I'm going to fix the gtkmm installer soon, but I don't think there is a problem with the GTK+ bundle. Armin ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Windows Installer containing current glibmm?
On Thu, 2009-03-05 at 15:08 +0100, Mark Roberts wrote: > Dear List! > > gtkmm is the best toolkit I have ever worked with. My customer is also > satisfied. > > There exists a Windows installer gtkmm-win32-devel-2.14.3-2.exe supplied > by Armin Burgmeier, to whom I hereby address thanks. Appreciated. > Will there be a version of that installer that contains glibmm-2.18? This > would be useful, since glibmm-2.18 has some new features I am interested > in. The installer you mentioned contains glibmm 2.18 (2.18.1, to be exact). What features you need are missing from what the installer contains? > Thank you, > Mark Roberts Armin ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
