Re: Handling Unix signals?
On Thursday 03 March 2005 13:29, Toralf Lund wrote: Igor Gorbounov wrote: [snip] I've got an advice here to use any way to send a message to MainLoop (see the mailing list for 21.02.2005). I've choosen the Glib::Dispatcher for this purpose, Ah. Yes. That seems to be more or less exactly what I was looking for, only I couldn't find the right spot in the documentation. Thanks. some gurus say that it may cause problems sometimes... What exactly would those problems be? I found some comments in earlier list posts, but they left me none the wiser... [snip] The problem is that you can only use async-signal-safe functions in a signal handler. Glib::Dispatcher is designed to be thread safe, not async-signal-safe, and you would need to examine the code for Glib::Dispatcher to see if calling emit() on a Dispatcher object also meets the async-signal-safe requirement (it quite possibly does). See paragraph 2.4.2 of the Single Unix Specification, System Interfaces, Signal Concepts, General Information, at http://www.unix.org/single_unix_specification/ for the list of async-signal-safe functions. You can easily do it yourself - create a pipe, plumb it into the main program loop with Glib::signal_io().connect() and then have the signal handler put a byte in the pipe (write() is async-signal-safe). Chris. ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Displaying simple HTML in gtkmm app
On Thursday 24 March 2005 22:24, John Taber wrote: [snip] Well, mentioned is the right word. - Glib::wrap() will give you a pointer to gtkmm object. It is an overloaded function, so it will give you an instance of the appropriate class. Sorry, but this doesn't really help me. Can someone help me out a bit more? Thks. John Pass a pointer to the GTK+ object to be wrapped as the argument to Glib::wrap(), and Glib::wrap() returns a pointer to the resulting wrapped gtkmm object. What more do you want to know? Chris ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Obtaining a TreeModel::Row from a TreePath
On Saturday 09 April 2005 16:11, Matthias Kaeppler wrote: Hello, I want to build list of data objects associated with a row in a tree view, based on the current selection. I know I can get the selected rows by calling TreeSelection::get_selected_rows(), but despite its name, this method returns a list of TreePathS, and not a list of TreeModel::Rows. So how can I obtain the rows from the path objects? To convert a path to an iterator, use Gtk::TreeModel::get_iter(const Gtk::Treemodel::Path), and then derefence the iterator (a row is just a dereferenced iterator). However, you probably want to convert all the paths to rows with a suitable functor using Gtk::TreeSelection::selected_for_each_path(). (As an example you can see: http://cvs.sourceforge.net/viewcvs.py/efax-gtk/efax-gtk/src/selected_rows_handle.h?rev=1.4 and http://cvs.sourceforge.net/viewcvs.py/efax-gtk/efax-gtk/src/selected_rows_handle.cpp?rev=1.3 Chris Chris ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: When and when not to use Glib::RefPtr?
On Tuesday 05 April 2005 22:57, Matthias Kaeppler wrote: Hello, is there a general rule of thumb which classes require access through a Glib::RefPtr? For example, based on the gtkmm tutorial, a TreeModel is constructed directly, while a TreeView is handled through a RefPtr. What's the point? You might want to look at http://developer.gnome.org/doc/API/2.0/gtk/GtkObject.html for an explanation of the way GTK+ deals with object lifetime management. If an object is derived from GtkObject then its container manages lifetime, and you (the user) are only responsible for the object if you add a reference count yourself (if you do that, at some stage you must unreference it again). On the other hand, the general rule for an object derived from GObject but not GtkObject is that the user (that is, the user calling the function which delivers the object) is responsible for managing its lifetime. However this is only a general rule. In practice, with an object derived from GObject but not GtkObject it can sometimes be quite difficult to work out whether GTK+ is actually presenting the user with a new object for which the user is responsible or whether the function is only an accessor to an object which something else is managing. If the function delivering the object has something like create or new in its name then you are getting something for you to manage with an initial reference count of 1. But if you are accessing it with something like, for example, gtk_tree_view_get_selection(), then you are delivered a pointer to an GObject which the tree view manages (it is a mere accessor). The general rule for gtkmm is that where gtk+/gdk/gdk-pixbuf/glib expects the user to manage the lifetime of an object derived from GObject but not GtkObject, then (as wrapped for gtkmm) it comes to you via a Glib::RefPtr object (an intrusive smart pointer) which does the referencing and unreferencing for you. However the analogy is not exact. gtkmm uses Glib::RefPtr for things derived from GObject even where GTK+ does not expect you to manage the lifetime of the unwrapped object. Taking the example of gtk_tree_view_get_selection(), in the gtkmm equivalent (Gtk::TreeView::get_selection()), the Gtk::TreeSelection object is delivered to you via a Glib::RefPtr and gtkmm adds an additional reference count (which GTK+ does not) before doing so for the purpose. (Whether that is a good thing is debatable, as the TreeSelection object has no meaning if the TreeView has been destroyed, so it is an ineffective ghost if the TreeView is destroyed before the object holding the Glib::RefPtr finally disposes of it, but it has the merit of consistency.) The various Gtk::Widget::get_*() accessor functions are a similar example. gtkmm adds an additional reference count and delivers the result to you via Glib::RefPtr, but GTK+ provides raw accessors only. It is easier to leak memory and resources with GTK+ than with gtkmm. Chris. ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: When and when not to use Glib::RefPtr?
On Monday 11 April 2005 01:53, Murray Cumming wrote: [snip] In general we avoid guessing such (undocumented) internal lifetime details, and just do the same thing with all GObjects. C coders do whatever works, with lots of errors along the way. Typically, in a case such as this, where the holding of a reference counting smart pointer is not enough to ensure the usable lifetime of the object, C++ would use a weak pointer. You are being unkind to C coders. Although glibmm does not provide weak pointers, C coders have glib, which does: it provides g_object_add_weak_pointer() (Adds a weak reference from weak_pointer to object to indicate that the pointer located at weak_pointer_location is only valid during the lifetime of object. When the object is finalized, weak_pointer will be set to NULL), together with g_object_remove_weak_pointer(), g_object_weak_ref() and g_object_weak_unref(), and GWeakNotify(), for the purpose. The glib weak pointer will tell the user precisely whether the object it references is valid or not. Chris. -- Summer is y-cumen in, lhude sing, cuccu! Groweth sed and bloweth med, springeth the wude nu. ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Getting a modal run
On Thursday 21 April 2005 22:23, Bob Caryl wrote: Hello Everyone, I've derived a class from Gtk::Window. I am running it from within another window thusly: Cashwin cw; cw.show(); Gtk::Main::run(cw); This works fine, except that it is not synchronous. I can get focus on the window that spawned this one and run it again. I don't want this to happen. The window is too complex to derive from Gtk::Dialog (I tried that). Assuming my assumptions about derivation from Gtk::Dialog were correct, any ideas? Look at the set_modal(), set_transient_for() and set_sensitive() methods to do what you want. (set_modal() is actually the one you are after if I understand your question, but you usually want to use it in combination with the others.) I would normally use Gtk::Main::run() to enter the blocking loop and Gtk::Main::quit() to leave it, but Gtk::Main::run(Gtk::Window) may work (although I normally reserve that for the main program object which, when closed, will terminate the program.) Chris. -- Summer is y-cumen in, lhude sing, cuccu! Groweth sed and bloweth med, springeth the wude nu. ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: wstring to ustring conversion
On Thursday 21 April 2005 23:13, Emre Turkay wrote: Greetings, I need to convert std::wstring into glib::ustring. It seems that conversion from/to std::string is included in the ustring and the way is pretty straight forward, however I couldn't figure out the *correct way* to make the conversion from wstring. I've been looking into the ustring source code, but it is really overwhelming for a guy who doesn't know anything about the internationalization and character code stuff ;) I think, for now I'll go and just write a one by one copy function and use it, however I would like to work on a better solution in the long term. Can you guys give me a pointer for information about it, well ustring compared to wstring would be the best. That depends on the encoding in your std::wstring, and the character size. (I do not use Windows but I think that that used to use 16 bit wide characters, which were neither utf16 nor ucs4 but comprised that part of the ucs4 character set reproducible as a single 16-bit character, but that may now have changed.) Glib has various conversion functions you could use, not all of which are in glibmm, including g_utf8_to_utf16(), g_utf8_to_ucs4(), and vice versa. See http://developer.gnome.org/doc/API/2.0/glib/glib-Unicode-Manipulation.html You can use these to make a conversion functor for std::transform and then iterate through the source and target strings, but you would need to handle conversion errors. If you wanted to be clever you could also implement std::codecvt stream code conversion facets using the Glib functions. You will not get anywhere with this without learning something about internationalisation and character codes. Chris. -- Summer is y-cumen in, lhude sing, cuccu! Groweth sed and bloweth med, springeth the wude nu. ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Displaying simple HTML in gtkmm app (got it!)
On Thursday 21 April 2005 19:06, [EMAIL PROTECTED] wrote: [snip] The other thing that I noticed about this way of implementing this is that you are limited to a single instance of a window that can render HTML. I was starting to create a C++ wrapper class, but found out that the lines: g_signal_connect( G_OBJECT( document ), request_url, G_CALLBACK( gtkhtml::url_requested ), NULL ); g_signal_connect( G_OBJECT( document ), link_clicked, G_CALLBACK( gtkhtml::link_clicked ), NULL ); are proving to be difficult to resolve. How would you connect gtk+ signals to a C++ class instance? That appears to be the question now, for me at least. I am not sure I have understood the question but if relates to making the callback aware of the class instance invoking the callback (say the one in whose constructor the call to g_signal_connect() was made) then pass the address of that instance (the this pointer) as the data argument, which is the last argument and is of type void*, thus: g_signal_connect( G_OBJECT( document ), request_url, G_CALLBACK(gtkhtml::url_requested ), this ); then gtkhtml::url_requested() would use static_cast() to cast its last argument back to a pointer of the relevant type. gtkhtml::url_requested() should have extern C linkage (and made a friend if it needs to have access to the class internals), but it looks as if it is a static class member function, which cannot have C linkage. Using a static member function will work with some compilers (eg g++) but not with others - it is implementation dependent. Chris. -- Summer is y-cumen in, lhude sing, cuccu! Groweth sed and bloweth med, springeth the wude nu. ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Added tooltip to display details of items in TreeView
On Friday 06 May 2005 15:41, Andrew E. Makeev wrote: Bob Caryl wrote: Tony Yum wrote: That connection syntax should probably be: signal().connect(sigc::bindbool(sigc::mem_fun(object, mem_fun), false)); where mem_fun expects the boolean value as a formal parmater. I don't think that was changed in Gtkmm-2.6 comparing to Gtkmm-2.4, but connect() function has 2 arguments: 1 - connection slot, 2 - flag after = true by default. So, if you would your callback to be called before other handlers you should to pass false as second argument. Instead, you may wish to use connect_notify() function that sending after = false. You don't use sigc::bind. Although they are not well documented for those new to gtkmm, these are glibmm signal proxies, which are interfaces to the GObject signal system on which GTK+ relies. The connect method for these takes two arguments, the second argument determining whether the user's callback is called after the GTK+ default handler (if any) - a true value, or before it - a false value. A glibmm signal proxy has two forms of connect: connect(), which by default passes true (after) to the second argument, and connect_notify(), which by default passes false (before) to the second argument. connect_notify() also always expects a void return type for the callback, even if the signal requires a boolean return type (say it is handling an GDK/X event, all of which have _event in the signal name). connect_notify() will supply the boolean return value itself, and return false (carry on processing the signal). Confusingly, GObject's g_signal_connect() calls the callback before the default handler (g_signal_connect_after() will call it after the default handler). Both these are macro front ends for g_signal_connect_object(). Returning true from a callback connected using g_object_connect() will therefore stop signal emission to the default handler. I do not know why gtkmm does it the other way around but I expect there is a reason. Of course with gtkmm you have access to the equivalent virtual protected member function (on...()) for more fine-grained control of how the default handler executes (the GObject signal system offers you before or after, and if before, either skip the default handler or don't skip it, whereas with the gtkmm virtual protected member function you can call the default handler at any point you want). A sigc signal object does not have the second argument - it knows nothing about default handlers, as it is justs a generalised callback mechanism. Likewise it has no connect_notify() method. Chris -- Summer is y-cumen in, lhude sing, cuccu! Groweth sed and bloweth med, springeth the wude nu. ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Gnome, Gtkmm and sockets
On Tuesday 17 May 2005 23:47, Fabio Rafael da Rosa wrote: [snip] Tks for reply :) . I'm just start gnome hacking, but I know how to use general C++ programming (things like sockets). Didn't know that gnome didn't had a standard lib for socket communication. Thanks for answering, I'll use the standard API for my program ... gnome-vfs provides an imlementation for sockets, amongst other things. It is a library for abstracting file systems, so I suspect it is not what you have in mind as it is aimed at protocol independence. However, you might want to have a look at it. It is wrapped (gnome-vfsmm) and you could probably find out more on the gnomemm mailing list. Chris. -- Summer is y-cumen in, lhude sing, cuccu! Groweth sed and bloweth med, springeth the wude nu. ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: What is gtkmm default font and size?
On Tuesday 07 June 2005 14:48, John Taber wrote:
When a gtkmm program (and any gtk program for that matter) runs under
Gnome, the fonts are nice, but when it is run under KDE, the fonts are
terrible - what font and size does gtkmm default to? I would assume this
is best addressed from the user settings (in KDE the Control Center allows
user to select font and size for various types).
If you are running it under KDE then the gnome settings daemon will not be
running. You have two options:
1. Amend/provide {gtkdir}/etc/gtk-2.0/gtkrc to specify fonts and anything
else you think important.
2. Start {gnomedir}/libexec/gnome-settings-daemon in the startkde script,
which will pick up all your Gnome settings, including fonts and styles.
Chris.
--
Summer is y-cumen in, lhude sing, cuccu!
Groweth sed and bloweth med, springeth the wude nu.
___
gtkmm-list mailing list
gtkmm-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Using (or not using) sigc::mem_fun with the G_CALLBACK macro
On Thursday 16 June 2005 12:50, Paul Davis wrote:
On Thu, 2005-06-16 at 06:08 -0500, Bob Caryl wrote:
Murray Cumming wrote:
And if you must provided a C function pointer, you'll need to provide a
pointer to a static method (or global function) and the state
information as user_data. See the various SignalProxy classes, for
instance, in TreeSelection.
In other words, the way I've done it (separate executable invoked via
fork, execv) is the only thread safe way to do this until GtkHTML has a
C++ wrapper.
what are you thinking? this has nothing to do with threads. it doesn't
even have a *lot* to do with language, except for the fact that you
can't use a non-static C++ member function as a C callback. if you
really want to use C++ objects with GTK widgets, then do this:
class Foo {
public:
static gint my_c_proxy_for_bar (arglist...);
gint my_handler_for_bar (otherarglist...);
};
gint
Foo::my_c_proxy_for_bar (..., gptr user_data, ...)
{
return reinterpret_castFoo*(user_data)-my_handler_for_bar
(relevant_args...);
}
gint
Foo::my_handler_for_bar (otherarglist...)
{
}
and then somewhere, connect
gtk_signal_connect (widget, signal, , SomePtrToFoo);
I have done this a lot with the GtkCanvas widget which has never been
wrapped for C++ (and never will be; we're migrating to GNOME::Canvas
ASAP)
You are not even guaranteed that static C++ member functions can be used as a
C callback.
You should really use a function with C linkage as the proxy (probably in
anonymous namespace so it is not exported). Static member functions are not
guaranteed to have the C linkage. On g++ they do, but I believe on the Intel
compiler as an example they do not, and your example will not compile. (In
your example the C++ handler is public, but if it were private the proxy
function would also need to be a friend.)
Chris
___
gtkmm-list mailing list
gtkmm-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: problem with exiting from a Glib::Thread
On Saturday 25 June 2005 12:58, Yair Hershkovitz wrote: i call throw Glib::Thread::Exit() to exit from a thread, what happens is: glibmm-ERROR **: unhandled exception (type unknown) in signal handler aborting... this happens to me on every program i wrote that uses glib's threads I have never thrown that exception to exit a thread and I have never looked at the source code to see what it does, but if glibmm relies on the underlying pthreads implementation not doing its own stack unwinding (which it would not with standard C pthreads) and therefore trying to do it itself with exceptions then it may well have run into a problem with the NPTL (new POSIX threads library) implentation of threads for Linux. Other Unix based systems such as HP-UX and Solaris also have their own pthreads extension for C++ which may also cause problems with Glib::Thread::Exit. I do not know whether Glib::Thread::Exit is compatible with Windows threads. NPTL provides its own stack unwinding when pthreads is used in a C++ environment. However, there is no standard way of doing this because C++ does not yet have a standard for threads. A number of options for implementing thread termination in a C++ environment are: a) Do nothing - just do nothing more than is required by POSIX pthreads, which is to terminate the process at the point the thread reaches a cancellation point (assuming deferred cancellation is used) without calling any destructors for local objects and to rely on the user implementing his own clean up handlers with pthread_cleanup_push() and pthread_cleanup_pop(). This is what Linuxthreads users have to do (which includes FreeBSD). b) To call the destructors on all objects with local scope (bare stack unwinding) but without implementing it via a catchable exception; c) To implement the stack unwinding as an exception. But then, how far should the stack unwind - only to the point at which the thread exits or (if the exception is not caught) should it terminate the entire process in which the thread is running? Common sense dictates the former approach (it is the only sane one for thread cancellation) but that would in fact contradict the C++ standard such as it exists at present. But if that non-standard approach is adopted to pseudo-exceptions used to terminate a thread, should it also apply to other exceptions thrown in a multi-threaded program? Should all uncaught exceptions only propagate to the point at which the thread in which it is thrown ends, or should it terminate all other threads executing in the process concerned? There are arguments for either approach for this. NPTL has its own slightly odd implemention for stack unwinding as an exception upon thread cancellation, called forced stack unwinding, which is a combination of both b) and c) above. The pseudo-exception involved in terminating a thread is anonymous but can be caught with catch(...) in order to do any additional clean-up the user wants to do (although catching it for clean-up is really relevent to calls to pthread_cancel() rather than pthread_exit(), as a call to pthread_exit() can be preceded by whatever clean-up the user wants in the ordinary course of thread execution). However, if that is done the catch handler MUST THEN CALL throw when it has finished its clean-up in order to carry on unwinding the stack or stack unwinding will proceed automatically to terminate the entire process in which the thread is executing (I am not sure what exception NPTL will throw to do this, possibly std::unexpected). The reason given for this is that thread cancellation should not (in the view of the implementers of NPTL) as a matter of principle be capable of being stopped by catching the pseudo-exception and then not rethrowing it, but that does not excuse (in my view) the NPTL approach of terminating the entire process if the user's code does in fact try to do this. Issues such as this are at present under consideration by the C++ standards committee for the next version of the C++ standard, which almost certainly will make some provision for threads, if only to deal with issues such as this. The behaviour of NPTL is unintuitive (and to my mind wrong), and may trip up any attempt at home grown stack unwinding which cancels threads by throwing an exception at the user level (such as Glib::Thread::Exit), and then trying to stop stack unwinding by catching all exceptions at the point at which the tread terminates to enable the handler to then call pthread_exit() (or gthread_exit()). With NPTL that will cause an exception to be generated in an exception handler with no obviously predictable result (and undefined behaviour). Furthermore, if the implementation such as in glibmm causes the NPTL pseudo-exception to be caught with catch(...) and then not rethrown then NPTL will automatically terminate the whole process (ie, your program). Therefore, quite probably
Re: problem with exiting from a Glib::Thread
On Sunday 26 June 2005 07:56, Yair Hershkovitz wrote: i'm using mandriva 2005, they suppose to have nptl (there is a /usr/include/nptl with headers) but i dont know how to link againts it. i also don't know to which threads library glib is linked. how can i check that? Glib uses whatever thread library is compiled into glibc if you either compiled glib yourself or you are using the version of glib which comes with your distribution. So the issue is really what thread library has been compiled into glibc. From what you say this is almost certainly NPTL, but you can check this by doing: /lib/libc.so.6 --version The resulting text will include a line: linuxthreads-0.10 by Xavier Leroy if it uses linuxthreads, or a line: NPTL 0.60 by Ulrich Drepper (or a later version of NPTL) if it uses NPTL. If it uses NPTL then try running your program with the following environmental variable exported: LD_ASSUME_KERNEL=2.4.19 In Redhat and Suse at least this forces NPTL to adopt Linuxthreads behaviour (that is, it prevents forced stack unwinding) and it probably does the same with your distribution, so if Glib::Thread::Exit works correctly with this variable set and exported then you have a NPTL issue. Chris ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: gtkmm and gcc 4.0
On Sunday 26 June 2005 11:45, John Taber wrote: My experiences trying out gcc 4.0 vs 3.3.5 with gtkmm 2.6.1 1) some dialog classes compile as 1/2 the size 2) most classes have the same nasty looking warning on shared libraries 3) linking has the warning that gtkmm wants to use libstdc++ so.5 instead of libstdc++ so.6 (running gcc 4.0.1 Debian unstable) 4) one of my key programs segfaults with 4.0 - runs fine with 3.3.5 (have not tracked down why yet) my initial conclusion: I've gone back to using 3.3.5 for now. Maybe switch to 4.0 on next program version with gtkmm 2.8. gcc 4.0 seems to have a big advantage on code size but since gtkmm relies on quite a few libraries, it might take a little while until all are pretty well compiled themselves under 4.0 and that all the latest versions are being used together (ie gtk just came out with 2.6.8, glib with 2.6.5 and I know I'm not using those yet). This also points out a real practical problem in maintaining a stable gtkmm version on a developer's machine when the underlying shared libraries keep updating and I have yet to see anywhere on the web site specific version numbers as to what is tested with what. It looks as if in fact you have NOT recompiled gtkmm as you say, or if you have, it is not in a directory assessible to the loader. gcc-3.3 uses version 5 of libstdc++, and gcc-3.4 and 4.0 use version 6. In particular you would have encountered the same issue if you were to have changed your gcc version to 3.4. If you do replace gcc-3.3 you will still need to keep its version 5 libstdc++ libraries somewhere in the /etc/ld.so.conf library directories because other programs may depend on them. Versions 5 and 6 are parallel installable so your criticisms look off the mark. Furthermore the information about versions was given to you and you did not need to search the web - it was in the warnings which you said you were given, which is why I am able to deduce what your problem is. Ignoring the same nasty looking warning on shared libraries will not get you very far in any programming environment. Chris ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: gtkmm and gcc 4.0
On Sunday 26 June 2005 12:15, Christian von Kietzell wrote: Am Sonntag, den 26.06.2005, 04:45 -0600 schrieb John Taber: My experiences trying out gcc 4.0 vs 3.3.5 with gtkmm 2.6.1 1) some dialog classes compile as 1/2 the size 2) most classes have the same nasty looking warning on shared libraries 3) linking has the warning that gtkmm wants to use libstdc++ so.5 instead of libstdc++ so.6 (running gcc 4.0.1 Debian unstable) 4) one of my key programs segfaults with 4.0 - runs fine with 3.3.5 (have not tracked down why yet) Some problems are to be expected. In order to use GCC 4.0 all C++ libraries will have to be compiled using GCC 4.0, as 4.0 and 3.3.x are using different ABI versions. Debian hasn't made the transition yet. Are you sure about this? They use different libstdc++ libraries but my understanding was the the C++ ABI was not broken between gcc-3.3/3.4/4.0. In any event, incorrect library versions is the first problem he encountered (it is the one reported by the linker) and recompiling gtkmm would have solved both, if both exist. Chris. ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: gtkmm and gcc 4.0
On Sunday 26 June 2005 13:30, Roger Leigh wrote: Changing libstdc++ does break the ABI. Debian is currently using GCC 3.3 with libstdc++5. We will, in a few weeks, switch to GCC 4.0 and libstdc++6. At this point all the C++ libraries will need to be rebuilt, and these problems will go away. It's not possible to use multiple versions of libstdc++ in one program, so linking a library built against libstdc++5 with a program built with GCC 4.x is going to be dodgy. I agree with that, but saying that compilers have different ABIs can mean different things to different people, particularly with those who remember the bad old days of gcc-3.95, gcc-3.0, gcc-3.1 and gcc-3.2, when the C++ ABIs for each were different, and most people were very unhappy about that (in the sense that the same libraries compiled with each compiler would have different ABIs). gcc-3.2, 3.3 and 3.4 did not break ABI in that sense (the same linking and name mangling conventions are used for each). However, as you say the ABI of libstdc++ did change with the change of the major library version number from 5 to 6, in the same way that the gtkmm ABI changed between 2.2 and 2.4, which makes gcc-3.3 and gcc-3.4 incompatible - made worse by the fact that version 6 of libstdc++ will not compile with gcc-3.3 (and version 5 will not compile with gcc-3.4) and that as you say you cannot link the same program against both version 5 and 6 (but they are parallel installable so that you can have different programs on the same system linked against different versions provided that any one program and all its dynamically linked dependencies are linked against only any one version). In practice, as you say this means that all C++ libraries are going to have to be recompiled when changing from gcc-3.3 to gcc-3.4 or 4.0. I had to do exactly that when I moved from gcc-3.3 to 3.4 - but for me this only meant recompiling gtkmm, Qt and KDE. gcc-3.4 and 4.0 both use version 6 of libstdc++ and as I understand it you can interchange gcc-3.4 and 4.0 without difficulties. I may well download gcc-4.0 to test that out. Chris. ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Glib::Dispatcher (multiple emit/write lockup)
On Tuesday 28 June 2005 04:15, Mario Sergio Fujikawa Ferreira wrote:
[snip]
I added a few fprintf(stderr, ) traces to glibmm dispatch.cc
code so that I could pin point exactly where the problem occured. It
seems to me that it is a problem with reentrancy since nothing
guarantees that the write(2) call on the sender is atomic.
Which is reinforced by the comment right below the write(2)
call on the DispatchNotifier::send_notification() method on
http://cvs.gnome.org/viewcvs/glibmm/glib/glibmm/dispatcher.cc?rev=1.12view
=markup
// All data must be written in a single call to write(), otherwise we
can't
// guarantee reentrancy since another thread might be scheduled between
two
// write() calls. The manpage is a bit unclear about this -- but I hope
// it's safe to assume immediate success for the tiny amount of data
we're
// writing.
Well, I am hitting a wall here. Glib::Dispatcher is not
reentrant and there is little I can do about it.
Adding per Dispatcher mutex protections around the write(2) system call
do-while loop
while (sender_mutex_.trylock() == false)
Glib::Thread::yield();
do
n_written = write(fd_sender_, data, sizeof(data));
while(n_written 0 errno == EINTR);
sender_mutex_.unlock();
does not protect against lockups. Nor does adding a mutex inside
Dispatcher::emit().
void Dispatcher::emit()
{
Glib::Mutex::Lock lock_(mutex);
notifier_-send_notification(this);
}
Checking the mailing lists, I found some interesting remarks
http://mail.gnome.org/archives/gtkmm-list/2002-September/msg0.html
which do point out the reentrancy problem.
There is a suggested solution at
http://mail.gnome.org/archives/gtkmm-list/2002-September/msg8.html
pointing out that a lock-free FIFO multiple-writers-single-reader could
be the solution. I do agree that this is non trivial.
The POSIX Single Unix Specification provides in relation to write() that:
Write requests to a pipe or FIFO shall be handled in the same way as a
regular file with the following exceptions:
...
Write requests of {PIPE_BUF} bytes or less shall not be interleaved with
data from other processes doing writes on the same pipe. Writes of greater
than {PIPE_BUF} bytes may have data interleaved, on arbitrary boundaries,
with writes by other processes, whether or not the O_NONBLOCK flag of the
file status flags is set.
...
PIPE_BUF is never less than 512 and is usually 2048 in size. Admittedly the
standard only requires writes by different processes to be atomic with a
write of a size not greater than that, but it would be odd if the same
behaviour were not exhibited by different threads within one process. If you
are using Windows, I thought that it was POSIX compliant?
Unfortunaly gnome.org is down at the moment so I cannot look up your mailing
list references, but why is it that mutexes around the write call don't solve
the issue (if in fact different threads within the same process do not
benefit from the POSIX atomicity guarantees)? That should avoid concurrent
writes to the Dispatcher pipe in every case.
Chris
___
gtkmm-list mailing list
gtkmm-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: gtkmm-list Digest, Vol 14, Issue 43
On Friday 01 July 2005 11:38, Mario Sergio Fujikawa Ferreira wrote:
[snip]
That does not protect against race conditions. If the
send_notification (emit()) thread is interrupted right in the middle of
the write(2) call, we will end up with another thread doing a write(2)
and another one overlapping is atomicity is not guaranteed. As per the
POSIX standard upholding, I am not seeing such atomicity guarantees
under Conectiva Linux 9 kernel 2.4.x series with Linuxthreads. It could
be just a problem with my development environment (which should not be
since I am able to reproduce this problem under Mandriva Linux) but we
should not rely on that but do take a safer approach right from the
start.
Pipes are, through their file descriptors, a resource shared between processes
as well as threads. You can be pretty sure that glibc is providing the
atomicity guarantees required by POSIX with respect to this, as it tries hard
to get these things right.
You can therefore take it that there is no race condition in relation to
different processes writing to the same pipe. As I said, you are technically
right in the sense that POSIX only guarantees the position where different
processes write to the same pipe, not where different threads within any one
process write to the same pipe. Even if glibc were not to offer atomicity
between threads (although it would have to work hard at not providing
atomicity between threads if it is providing it between processes), I am
pretty certain that this is not your problem (see further below). (It is
difficult to see how interleaved data could cause a lock-up - note that
write() itself is guaranteed to be thread safe.)
[snip]
Okay, here is my theory from what I gathered from gdb. This is
just a theory. Others more experienced with {glib,gtk}mm inner workings
should know better. Well, under some irregular circunstances it is
possible to lock up all threads (including the main thread and the
controller thread for that matter) if a send_notification thread is
preempted in the middle of it's execution while holding the lock. If
the main/controller thread tries to use the send_notification (emit()),
it will end up waiting on that mutex. Dead lock. Any way, even if this
is not the case, I am experienced deadlocks with that approach.
I think I can see where you are going wrong. You should not have the same
thread both (a) calling emit() on the Glib::Dispatcher object (sending the
notification) and (b) being the thread within which the Glib::MainContext
polling the pipe for reading executes (and therefore in which the slot
connected to the Dispatcher executes). You should normally only emit from a
worker thread - ie a thread which is not the main thread (Glib::MainContext)
within which Glib/GTK+ is executing. Otherwise you can get a deadlock.
This deadlock does not arise as you suggest because of a recursive call to any
mutex you use (if all you are doing is putting a mutex around the write call
to the pipe then the same thread which is doing that write cannot at the same
time also be trying to reacquire the mutex), but because the write is a
blocking write and when any one thread is writing to the pipe, it cannot also
be reading from it.
You say you are using the Dispatchers heavily. If you are stuffing so much
data into the pipe that it is full before it has a chance to be read by the
next iteration through the main program loop (Glib::MainContext), then if the
thread sending the notification is also the one which reads from it then it
will block on the write for ever because the pipe can never be emptied.
If you are emitting a signal in the same thread as the one in which you want
the slot connected to it to execute (the main program thread), just use a
plain sigc::signal0void object in those cases (reserve the Glib::Dispatcher
for a case where a different thread is sending the notification). You can
have a sigc::signal0void object and a Glib::Dispatcher object connected to
the same slot, and because the slot will (if you adopt this approach) be
executing in only the main program thread, you will need no mutexes for it.
Chris.
___
gtkmm-list mailing list
gtkmm-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Problem packing labels into Gtk::Table
On Saturday 16 July 2005 05:30, Nickolai Dobrynin wrote: [snip] The problem I get is that this code gives me Illegal instruction at runtime. Anybody knows why? (I am using gtkmm-2.4.11 on Gentoo). Yikes. Insufficient cooling on your CPU in summer temperatures? Chris ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Problem packing labels into Gtk::Table
On Sunday 17 July 2005 01:23, Nickolai Dobrynin wrote: Chris, :) Believe it or not, your response was actually helpful because, at least, I have learned that there is no problem in the code itself. So I went to check if all intermediate builds were fresh, and they were NOT. After rebuilding everything from scratch, the whole thing started working like a charm. It was intended to be helpful. I am glad to see you have solved the problem, but it is surprising that that could cause an illegal instruction. It is likely it was corrupted in some way rather than stale. Chris. ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Gtk widgets in gtkmm (Previously no subject)
On Thursday 21 July 2005 16:22, Andrew Krause wrote: (Sorry about the no subject topic... in any case...) I have a c++ class that contains Gtk+ widgets. They work perfectly fine except for one thing. When I try to connect a signal to them, they throw an error saying that the function that it is connected to should be formatted: void (*) () instead of: void (MyClass) (). How can I get around this? Is there a way without requiring all of my functions to receive the class data and not be a part of the class? g_signal_connect has its callback (slot) function passed as a C function pointer (cast with G_CALLBACK()). The cludge (which will work with most but not all compilers) is to make your callback a static member function of the class. The correct (standards complying) approach is to make the callback a function outside the class with C linkage (ie declare it extern C) and make it a friend of the class if it needs access to the class's private or protected members. You will need to pass the class instance to the callback if the callback needs to access non-static data of the class. If so pass the this pointer as the last (data) argument to g_signal_connect(), and then cast it back to the correct type in the callback. Chris ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Gtk widgets in gtkmm (Previously no subject)
On Monday 25 July 2005 07:32, Andrew E. Makeev wrote: Chris Vine wrote: [snip] g_signal_connect has its callback (slot) function passed as a C function pointer (cast with G_CALLBACK()). The cludge (which will work with most but not all compilers) is to make your callback a static member function of the class. The correct (standards complying) approach is to make the callback a function outside the class with C linkage (ie declare it extern C) and make it a friend of the class if it needs access to the class's private or protected members. You will need to pass the class instance to the callback if the callback needs to access non-static data of the class. If so pass the this pointer as the last (data) argument to g_signal_connect(), and then cast it back to the correct type in the callback. I only would add one note: you may wish to use static class method as callback for that signal, then you could save c++ style and avoid friend declarations. I mentioned this as the cludge option above. It is not standards conforming, as static class methods do not have C linkage and are therefore a separate type from functions (such as GSignal callbacks) which do: Paragraph 7.5.1 of the standard: All function types, function names, and variable names have a language linkage. The default language linkage of all function types, function names, and variable names is C++ language linkage. Two function types with different language linkages are distinct types even if they are otherwise identical. Static member functions work as C callbacks with g++ and many other compilers, but not with all. Given the increasing pedantry of g++ in the gcc-4.0 release, it would not surprise me if in due course g++ stops supporting it. Chris. ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Libpropc++
On Thursday 18 August 2005 11:38, Foster Gareth wrote: Since template code cannot be 'separated' from the rest of a program into a shared library, all the files that depend on a template library (such as, in fact, libsigc++) will have to be open-sourced in order to comply with the terms of the LGPL. This does indeed implicate that you'd have to open-source at least a part of your program in order to be able to use libsigc++. I've heard about this problem in the context of other open source libraries. Does anyone know if there is there any scope for this being addressed in the forthcomming C++ standard, is it even on the agenda for that revision or perhaps the next? Did you really mean addressing this in the C++ standard? You just need to address it by employing an appropriate licence. Header and source files in libstdc++ (as supplied with gcc) apply the GPL with a special exemption to cover executable programs compiled from source code using it, in the following terms: As a special exception, you may use this file as part of a free software library without restriction. Specifically, if other files instantiate templates or use macros or inline functions from this file, or you compile this file and link it with other files to produce an executable, this file does not by itself cause the resulting executable to be covered by the GNU General Public License. This exception does not however invalidate any other reasons why the executable file might be covered by the GNU General Public License. This is a modified GPL rather than a modified LGPL, I think because no-one was very sure what the LGPL means anyway, whereas it was thought that allowing linking (static or dynamic), macros, inline functions and template instantiation without causing the result to be governed by the GPL was understood by anyone writing C++ programs. On the other hand the first sentence of the special exception, in referring to using it as part of a free software library, does not make much sense either, since the remainder of the special exception is concerned with the use of the library to create an executable program. Section 5 of the LGPL says this: 5. A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a work that uses the Library. Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License. However, linking a work that uses the Library with the Library creates an executable that is a derivative of the Library (because it contains portions of the Library), rather than a work that uses the library. The executable is therefore covered by this License. Section 6 states terms for distribution of such executables. When a work that uses the Library uses material from a header file that is part of the Library, the object code for the work may be a derivative work of the Library even though the source code is not. Whether this is true is especially significant if the work can be linked without the Library, or if the work is itself a library. The threshold for this to be true is not precisely defined by law. If such an object file uses only numerical parameters, data structure layouts and accessors, and small macros and small inline functions (ten lines or less in length), then the use of the object file is unrestricted, regardless of whether it is legally a derivative work. (Executables containing this object code plus portions of the Library will still fall under Section 6.) Otherwise, if the work is a derivative of the Library, you may distribute the object code for the work under the terms of Section 6. Any executables containing that work also fall under Section 6, whether or not they are linked directly with the Library itself. The point arising here is that section 5 of the licence claims that any program which links with, or uses non-trivial macros or inline functions, is a derivative to be released under section 6, and section 6 requires the object code of the program to be freely copiable (ie non-proprietary) unless it only links dynamically with the LGPLed library by a suitable shared library mechanism . For templates, with most compilers this is probably impossible. With those which support the export keyword it may be possible to separate out object files in this way, although I doubt it. What a load of mumbo-jumbo. The LGPL is a masterpiece of unintelligibility. Under English law (I do not know about others) authors can release their code on whatever terms they want (unless they have assigned the copyright or have developed the code in the course of their employment). To deal with the template problem a library can presumably be released under a modified LGPL which adds templates of any length after small macros and small inline
Re: Text next to pixbuf in single column
On Saturday 27 August 2005 09:05, Igor Jovanovic wrote: Hello everyone. I found an example how to put icons in cells, but I want my text to appear in a same cell as pixbuf. I'm not sure how custom cellrenderers can be used for packing multiple data type in a single cell of a TreeView. That segfaults killing me :) If anyone have some example please help. You don't need a custom renderer just to display a pixbuf icon and text in the same tree view cell. You can pack two cell renderers (say one for a text model column and one for a pixbuf model column) in the same tree view column using gtk_tree_view_column_pack_start()/ gtk_tree_view_column_pack_end(), and then call gtk_tree_view_column_add_attribute() or gtk_tree_view_column_set_attributes() for each of the renderers to connect it to their respective model columns. (Tree model columns are just data points.) You can do something like this: GtkTreeModel *tree_store = GTK_TREE_MODEL(gtk_tree_store_new(2, GDK_TYPE_PIXBUF, G_TYPE_STRING)); GtkTreeViewColumn *column = gtk_tree_view_column_new(); gtk_tree_view_column_set_title(column, My column); GtkCellRenderer *renderer = gtk_cell_renderer_pixbuf_new(); gtk_tree_view_column_pack_start(column, renderer, FALSE); gtk_tree_view_column_set_attributes(column, renderer, pixbuf, 0, NULL); renderer = gtk_cell_renderer_text_new(); gtk_tree_view_column_pack_start(column, renderer, TRUE); gtk_tree_view_column_set_attributes(column_p, renderer, text, 1, NULL); GtkWidget *tree_view = gtk_tree_view_new_with_model(tree_store); gtk_tree_view_append_column(tree_view, column); Chris. ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Text next to pixbuf in single column
On Monday 29 August 2005 11:37, Chris Vine wrote: On Saturday 27 August 2005 09:05, Igor Jovanovic wrote: Hello everyone. I found an example how to put icons in cells, but I want my text to appear in a same cell as pixbuf. I'm not sure how custom cellrenderers can be used for packing multiple data type in a single cell of a TreeView. That segfaults killing me :) If anyone have some example please help. You don't need a custom renderer just to display a pixbuf icon and text in the same tree view cell. You can pack two cell renderers (say one for a text model column and one for a pixbuf model column) in the same tree view column using gtk_tree_view_column_pack_start()/ gtk_tree_view_column_pack_end(), and then call gtk_tree_view_column_add_attribute() or gtk_tree_view_column_set_attributes() for each of the renderers to connect it to their respective model columns. (Tree model columns are just data points.) You can do something like this: GtkTreeModel *tree_store = GTK_TREE_MODEL(gtk_tree_store_new(2, GDK_TYPE_PIXBUF, G_TYPE_STRING)); GtkTreeViewColumn *column = gtk_tree_view_column_new(); gtk_tree_view_column_set_title(column, My column); GtkCellRenderer *renderer = gtk_cell_renderer_pixbuf_new(); gtk_tree_view_column_pack_start(column, renderer, FALSE); gtk_tree_view_column_set_attributes(column, renderer, pixbuf, 0, NULL); renderer = gtk_cell_renderer_text_new(); gtk_tree_view_column_pack_start(column, renderer, TRUE); gtk_tree_view_column_set_attributes(column_p, renderer, text, 1, NULL); GtkWidget *tree_view = gtk_tree_view_new_with_model(tree_store); gtk_tree_view_append_column(tree_view, column); Sorry, I just realised this is on the gtkmm list. Do the same in gtkmm (there is one-to-one correspondence with the GTK+ equivalent). Chris ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Text next to pixbuf in single column
On Monday 29 August 2005 11:38, Chris Vine wrote: Sorry, I just realised this is on the gtkmm list. Do the same in gtkmm (there is one-to-one correspondence with the GTK+ equivalent). And as you asked for an example there is already documentation to show you how to do it: http://www.gtkmm.org/docs/gtkmm-2.4/docs/tutorial/html/ch08s02.html#id2499871 (Look also at the stockbrowser example code.) This is a slightly more convenient interface than the GTK+ one if you use a Gtk::TreeModelColumnRecord object to set the renderers up. Chris ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: ustring problem
On Thursday 01 September 2005 21:45, Erwin Rol wrote: OK after recompiling the srpm from http://download.fedora.redhat.com/pub/fedora/linux/extras/development/SRPMS /glibmm24-2.6.1-1.src.rpm on my system it works correctly. During the configure of i can see the following line ; checking whether the compiler allows a static member variable to be initialized inline to std::string::npos... no which seems to do the trick, the question is why are the binary rpms not working, are they just compiled with a older/different compiler ? - Erwin gcc-4.0 does allow static member variables to be initialised inline. So do gcc-3.2, 3.3 and 3.4, with x86 at any rate. Older pre-C++98 compilers may not. What does 'gcc --version' tell you? You may have more than one compiler installed and be calling the wrong one. Chris ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: ustring problem
On Thursday 01 September 2005 23:31, Erwin Rol wrote: On Thu, 2005-09-01 at 22:57 +0100, Chris Vine wrote: On Thursday 01 September 2005 21:45, Erwin Rol wrote: gcc-4.0 does allow static member variables to be initialised inline. So do gcc-3.2, 3.3 and 3.4, with x86 at any rate. Older pre-C++98 compilers may not. What does 'gcc --version' tell you? You may have more than one compiler installed and be calling the wrong one. gcc (GCC) 4.0.1 20050831 (Red Hat 4.0.1-12) and the system is; Linux xpc.home.erwinrol.com 2.6.12-1.1519_FC5 #1 SMP Sat Aug 27 13:54:40 EDT 2005 x86_64 x86_64 x86_64 GNU/Linux Its not the wrong compiler, i am sure about that. And the problem is not that the member variables are initialized inline, the problem is that std::string::npos is not constant, and so can not be used to initialize static inline initialization. gcc-4.0.1 defines npos, as follows: static const size_type pos = static_castsize_type(-1); See the members of: templatetypename _CharT, typename _Traits, typename _Alloc class basic_string; in the file bits/basic_string.h. Perhaps your redhat version does something different, but in the standard gcc distribution it is definitely a constant. Chris ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: The string display in diferent language system.
On Thursday 22 September 2005 08:29, Johnson Zhao wrote: Hello, Everybody I have written a application to display different languages, like English, Chinese or others. the application is running well. I use gtkmm, mingw and dev-cpp on windows. If I run the application in Chinese environment Windows XP, the Chinese chacarters displayed well, but in English environment is not. I wrote the code like this: Gtk::MessageDialog dialog(*this, Test the Chinese string.); Glib::ustring mystring = this is my string in Chinese, 测试中文字符串的显示; dialog.set_secondary_text(Glib::locale_to_utf8(mystring)); I know that gtk display the text in utf-8, so I think it will display the same thing in different environment. Why it displayed bad character. Is there any errors in my understand? and how can I do this? 1. If you are hard-coding the language string into your code, why are you calling Glib::locale_to_utf8(), as it cannot be locale dependent? 2. What are you trying to do with Gtk::MessageDialog::set_secondary_text()? Chris ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: exchanging data between different programs
On Friday 21 October 2005 09:52, Andreas Schropp wrote: hello, I wanted to write some GUI-application using gtkmm-2.0 that acts somewhat similar than a server application. So, there shall be the GUI permitting the manipulation of different things and a different part of code waiting on a string from another program (non-GUI) to arrive. I am quite a programming starter and I don't have any clue how to implement something like that. What to use? Signals, pipes, sockets?? Until now, my server always freezes the GUI ... Thanks a lot in advance!! Use a pipe, fifo or socket and connect the file descriptor for it into the main program loop with Glib::signal_io().connect(). See the documentation at http://www.gtkmm.org/docs/glibmm-2.4/docs/reference/html/classGlib_1_1SignalIO.html#a0 Chris ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Gtkmm: gratitude and suggestions
On Sunday 23 October 2005 19:09, Maxim Udushlivy wrote: Hmm... Those non-const counterparts are needed only for getter functions which return somehow tied objects which should be as const as widget itself (for example Label::get_layout). Right? Non-const functions/methods are required for non-const objects. Chris ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Glib::ustring tradeoffs?
On Friday 28 October 2005 13:00, Matthias Kaeppler wrote: Let's say I have a filename named übung1.txt (Note the umlaut--if your newsreader can display it hehe). Will this filename make trouble with std::string, or be lost/replaced when converting to Unicode? UTF-8 represents Unicode characters by a series of bytes, of between 1 and 6 bytes in length - true ASCII characters (of value less than 128) are also valid UTF-8 and represented by 1 byte, and all other characters are represented by more than one byte. You can put any char value you want (including null characters and UTF-8 byte sequences) into a std::string object. UTF-8 is just another series of bytes as far as a std::string object is concerned, as is any other byte-based encoding such as ISO8859-1. A Glib::ustring object stores its UTF-8 contents as a series of bytes in the same way that a std::string object does (in fact, it contains a std::string object for that purpose). The main difference between a std::string object and a Glib::ustring object is that the Glib::ustring object counts it size, iterates and indexes itself with operator[]() by reference to whole Unicode characters rather than bytes - operator[]() will return an entire Unicode (gunichar) character for the index rather than a byte, as will dereferencing a Glib::ustring iterator. It can also search by reference a Unicode (gunichar) character and a Unicode (gunichar) character can be inserted into it (for that purpose the character will be converted into the equivalent UTF-8 byte representation and then inserted in the underlying std::string object). In many applications this extra functionality is irrelevant and using a std::string object for storing and manipulating UTF-8 byte sequences will be fine and have less overhead. In addition, if you try to manipulate a Glib::ustring object after putting an invalid UTF-8 byte sequence into it the Glib::ustring object will be in an undefined state, so you need to know that what you are putting into it is valid. (You can check this before manipulating it with Glib::ustring::validate().) You can check whether a std::string object contains valid UTF-8 with g_utf8_validate(), and extract a Unicode character from the byte stream it contains with Glib::get_unichar_from_std_iterator(), so you can take your choice between using std::string or Glib::ustring depending on your needs. Chris ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Glib::ustring tradeoffs?
On Saturday 29 October 2005 09:49, Matthias Kaeppler wrote: I'd have another question though. First, what's the difference between these two conversions: std::string ascii = text; // what's the difference between this ... Glib::ustring unicode = ascii; // ... and this? Glib::ustring unicode = Glib::locale_to_utf8(ascii); In this case, there is no difference if the locale charset (and the charset in which you have written your source code) is ASCII compliant (eg one of the ISO8859 or Microsoft charsets), because ASCII characters are valid UTF-8, and the string text is valid ASCII and so valid UTF-8. If you are using Unix or Windows you can assume your charset is ASCII compliant. So Glib::locale_to_utf8() will do nothing in your example. Furthermore, do I have to wrap every line of text into a call to Glib::locale_to_utf8()? For example if I define a widget text somewhere, do I have to do it like this: #define WIDGET_LABEL Glib::locale_to_utf8(BUTTON) ... widget.set_text(WIDGET_LABEL); and what could happen if I don't make the conversion? You need Glib::locale_to_utf8() if you want to put characters which are in your locale charset (where that might not be UTF-8) into something requiring UTF-8, such as a GTK+/gtkmm widget. This is only likely to happen if you are reading from an external source such as a file which contains data in the locale charset. As in your example you are hardwiring the text into the source code, then the best thing is not to convert the text, but to write the hardwired string in UTF-8 in the first place. (As it happens, BUTTON is valid ASCII and therefore valid UTF-8.) Normally if you are hardwiring text into your source code, such as the text for a label or button, you would enable translations from different languages by using gettext() and intltools. You can ensure that gettext() provides the translated text in valid UTF-8 format by calling bind_textdomain_codeset([prog_name], UTF-8) after the call to bindtextdomain(). The text can then be put directly into a GTK+/gtkmm widget. (In that case, calling Glib::locale_to_utf8() on the text returned by gettext() would be positively wrong, because an incorrect conversion will be attempted if the locale charset is not UTF-8 and the call will do nothing if the locale charset is UTF-8.) Similarly, if you are writing a program which needs to store data to file, it is best to store it in UTF-8. You will then not need to do any code conversion when reading the file contents into a GTK+ widget, and the file will be entirely portable (it will work whatever locale the program user happens to have adopted on his/her system). Practically all GTK+/gtkmm widgets from which text is obtained (such as Gtk::Entry) provide it in UTF-8 encoding, but there are exceptions. Gtk::FileChooser passes a file or folder name in the locale's filename encoding so it can be passed straight to Unix/Windows open() (but the filename text can be converted to UTF-8 with Glib::filename_to_utf8(), and vice-versa with Glib::filename_from_utf8(), if wanted). Chris ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: running a program with a different language than the current locale
On Friday 04 November 2005 13:53, Jonathon Jongsma wrote: On 11/3/05, ZeeGeek [EMAIL PROTECTED] wrote: may be you can open a terminal and set the variable LANG to portugese and then launch your program in that terminal. I've tried that, but it doesn't seem to work for me. I've tried the following: LANG=pt_BR.UTF-8 appname and LC_ALL=pt_BR.UTF-8 appname as well as both of these combined. It doesn't seem to work unless i log out and log in with a portugese GNOME session. Maybe it's not possible to run a program in a different locale from the rest of the desktop? Setting LC_ALL should work if you are choosing the correct locale, but have you tried instead setting the LANGUAGE (not LANG) environmental variable - see the documentation for GNU gettext? LANGUAGE has the highest priority (LANG the least, after LC_ALL). Chris ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Equivalent to gtk_drag_get_source_widget()?
On Sunday 06 November 2005 17:17, Matthias Kaeppler wrote: Hi, in a drag and drop signal handler I see no way to figure out which widgets are the source and target of the drag and drop operation. Gdk::DragContext can only return pointers to the source and target /windows/ but that's of little help if one or both aren't windows. I noticed a function in the GTK+ reference manual called gtk_drag_get_source_widget() which returns a pointer to the source /widget/, which is what I would need, but I can't find an equivalent function in gtkmm. Is there any? And is there also some function to retrieve the target widget of a dnd operation? The drag_data_received signal in GTK+ will pass the target widget as its first paramater. The gtkmm equivalent does not, but there is a good reason for that, namely that the receiving object knows what it is. The Gtk::Widget::on_drag_data_received() method will be called on the object which received the drag. You should not really need to know either what object the data was dragged from either. First, it may not be in the same address space as the process receiving the drag (gtk_drag_get_source_widget() will return NULL in that case, and where it is in the same address space you can store it in a variable assessible to both widgets if you really need it). Secondly, if you want to notify the source object that the drag has been completed there are signals available for that, via gtk_drag_finish() (or the gtkmm equivalent). Chris ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Equivalent to gtk_drag_get_source_widget()?
On Wednesday 09 November 2005 06:40, Matthias Kaeppler wrote: Chris Vine wrote: The drag_data_received signal in GTK+ will pass the target widget as its first paramater. The gtkmm equivalent does not, but there is a good reason for that, namely that the receiving object knows what it is. The Gtk::Widget::on_drag_data_received() method will be called on the object which received the drag. True. You should not really need to know either what object the data was dragged from either. I do, because I need some form of this check: if (source == target) don't do anything; else issue some operation This is to prevent the user from issueing an operation on the same widget when it's only allowed from one widget to another. This is only a problem if the same widget is set to be a drag source and a drag destination. Is that the case? You can check it in other ways anyway, such as by reference to the data supplied by the drag_data_get() signal handler (GTK+) or the signal_drag_data_get() signal or on_drag_data_get() method (gtkmm). You might find chapter 18 of the GTK+ tutorial helpful at http://www.gtk.org/tutorial/c1920.html . (It is directly translatable to gtkmm). Chris ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Equivalent to gtk_drag_get_source_widget()?
On Thursday 10 November 2005 21:48, Chris Vine wrote: [snip] This is only a problem if the same widget is set to be a drag source and a drag destination. Is that the case? You can check it in other ways anyway, such as by reference to the data supplied by the drag_data_get() signal handler (GTK+) or the signal_drag_data_get() signal or on_drag_data_get() method (gtkmm). You might find chapter 18 of the GTK+ tutorial helpful at http://www.gtk.org/tutorial/c1920.html . (It is directly translatable to gtkmm). Actually on further thought I am not even sure that even if the same widget is set as a valid source and destination for the data in question, GDK/GTK+ allows you to drag data to yourself. You might want to check that this is possible before you start worrying about it. Chris ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Equivalent to gtk_drag_get_source_widget()?
On Thursday 10 November 2005 21:55, Paul Davis wrote: On Thu, 2005-11-10 at 21:52 +, Chris Vine wrote: Actually on further thought I am not even sure that even if the same widget is set as a valid source and destination for the data in question, GDK/GTK+ allows you to drag data to yourself. You might want to check that this is possible before you start worrying about it. it absolutely does. Yes, you must be right. in fact, for the TreeView, you can *only* drag to yourself given the default configuration of a treeview. i posted here recently about tricky ways to workaround this. That is not right. Or at least, only right if you are talking about the high-level Gtk::TreeView drag and drop API. If you go to the low level GDK + GTK+ + GtkWidget (gdkmm + Gtk::Widget) drag and drop functions you can drag and drop between any GTK+ widgets, including between different TreeViews (and indeed between GTK+ widgets and non-GTK+ widgets which use the Xdnd or Motif protocols). Lots of applications do that (including one I have written). Of course the receiving widget needs to be able to interpret what it is receiving, which may cause problems if that comprises other than plain text or a pixbuf. Rather than trying to drag a row, which would be very difficult, you can drag the data contained within the row, and recreate the row at the receiving end. Chris ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Equivalent to gtk_drag_get_source_widget()?
On Thursday 10 November 2005 22:31, Paul Davis wrote: the treeview defines itself as a drag source only for same widget DnD. if you do not take several complex steps to alter this, you cannot drag out of the treeview. that's mostly because the only target the treeview accepts/sends by default is a string representation of the path within an unnamed treemodel. its so unutterably braindead as to be unbearable :) fortunately, you can hack around it, although it took me the better part of a day to work out all the wrinkles. The application I wrote drags between different tree views and I didn't have to do anything except call functions connected to the usual drag_begin, drag_data_get, drag_motion, motion_notify_event and drag_data_received signals, with appropriate calls to gtk_drag_set_icon_pixmap(), gtk_drag_source_set(), gtk_drag_source_unset(), gtk_drag_dest_set(), gtk_tree_view_get_dest_row_at_pos(), gtk_tree_view_set_drag_dest_row(), gtk_selection_data_set(), gdk_drag_status() and gdk_drag_finish(). This is a GTK+ application but the same goes for gtkmm. All the data was transferred as plain text, which made it relatively easy to use the standard GTK+/GDK functions. I think I must have been operating at a different level of the API than you were. I have never successfully been able to use the mid-level API comprising gtk_tree_get_row_drag_data(), gtk_tree_set_row_drag_data(), gtk_tree_view_set_rows_drag_source() and gtk_tree_view_set_rows_drag_dest(). Perhaps that is what you managed to get working. The API is quite poorly documented at that level. Chris ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Question
On Thursday 10 November 2005 10:16, Surya Kiran Gullapalli wrote:
Did you run gnome-settings-daemon ?
And that is my point, i've to run one or the other of gnome
applications, (gnome-font-properties as i've mentioned in my previous
mail, ultimately starts gnome-settings-daemon). I cannot get the
clearlooks (or whatever theme) for my gtk application, with out running
gnome-settings-daemon.
What a curious point. You want your program to display itself using a GNOME
theme but you don't want to run any GNOME daemons to do it. It is a bit like
complaining that you cannot run a KDE program without the KDE libraries
installed.
Actually, GTK+ is a little more accommodating than KDE, because you can set
styles and fonts and the like by hand by amending or providing
{gtkdir}/etc/gtk-2.0/gtkrc to specify them.
But as someone else has pointed out, it is better to start
{gnomedir}/libexec/gnome-settings-daemon in the start-up script for whatever
environment you are running your GTK+ applications in (such as the startkde
script), which will pick up all your GNOME settings, including fonts and
styles. You do not explain why you have a problem with that.
Chris
___
gtkmm-list mailing list
gtkmm-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: GtkDrawingArea on_clicked ?
On Monday 28 November 2005 02:52, Rob Benton wrote: Jonathon Jongsma wrote: You might try looking at the function Gtk::Widget::set_events() or Gtk::Widget::add_events() to make the drawing area respond to the events you're interested in. jonathon On 11/26/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi, i've got drawinrgarea and i'm trying to make something when i click with mouse on it but my tries failed. Can some give me a clue how to do it ? Use a Gtk::EventBox. Check the book in the Gtkmm documentation, chapter 12. You don't need an EventBox if you have a DrawingArea as I am pretty sure it has its own Gdk::Window (that is one of its purposes). If so, it is already capable of receiving events - you just need to enable them with Gtk::Widget::set_events(). Chris ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: a nasty accident of API design
On Monday 28 November 2005 16:51, Murray Cumming wrote: consider: Glib::RefPtrGtk::TreeStore model = ListStore::create (); model-clear(); model.clear(); those last two lines both compile, but they have a completely different effect. the first clears the model, the second clears the refptr. it seems to me that it would be wise to make sure that envelope classes like RefPtr have no methods that are likely to also exist in the wrapped classes. Yes, this causes confusion quite often. I wanted to remove RefPtr::clear(), or at least deprecated it. I seem to have had some problem creating an operator=() to replace it: From http://cvs.gnome.org/viewcvs/glibmm/ChangeLog?view=markup Wanted to remove clear() too, but there is no =0 equivalent yet. It's a bit late now (we can't break API), but a patch would be welcome. At the moment Glib::RefPtr follows the example of many reference counting smart pointers by only taking a pointer to the managed type in its constructor - the intention being that any assignment should be from another RefPtr so the reference count can be incremented. Where a pointer assignment is allowed, then it must reseat the referenced object and start a new reference count for the reseated object of 1. If you want to allow assignment of a NULL pointer to a Glib::RefPtr you would need to implement such reseating, and also handle the special case of a NULL pointer to vacate the existing reference and put the RefPtr into a null state. That would change the API and does not seem to be an approach favoured by many smart pointers. std::auto_ptr and boost::shared_ptr have a reset() method but I am not sure if that is better than a clear() method. boost::shared_ptr does not allow assignment of a pointer by operator=(), but you can reseat the referenced object using an overloaded reset() method which takes a pointer. Requiring a call to Glib::RefPtr::reset(0) to reset the RefPtr would make it more difficult to do the wrong thing by mistake, and could be implemented as part of a new reseating method. Chris ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: tray-icon
On Wednesday 30 November 2005 09:35, Igor Gorbounov wrote: Is tray icon implemented in gtk+(gtkmm)? Acccording to Google search it was promised in 2003. Igor Gorbounov libegg has EggTrayIcon, which I (and many others) have used with good results and will presumably form the basis of the tray icon code to go in GTK+2.10. You will have to use the C API, but there isn't too much too that. Chris ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: ustring::validate() costs?
On Thursday 01 December 2005 20:41, Matthias Kaeppler wrote: Hey guys, I am reading filenames from the harddisk which may or may not be in UTF-8 encoding. So, since Gtk+ and Glib naturally expect UTF-8, I somehow have to make sure my code doesn't break when the user's filenames are encoded differently. I spent quite some time searching the web and reading source code and documentation how to do this properly, and what I could figure out so far is this: If G_BROKEN_FILENAMES is set to 1 in the environment, then g_filename_to_utf8 will try to convert from the current locale to UTF-8, otherwise, the string is copied 1:1. For some reason this variable isn't mentioned in the documentation of the Glib character set conversion functions, so maybe my information is outdated--It only mentions G_FILENAME_ENCODING to determine the character set when you're converting /from/ UTF-8 to the locale's encoding. Anyway, I really don't want to force the user to set some obscure environment variable just so the program will work for him (since there are still users who do not use UTF-8 yet this is just not acceptable). So I thought I could do this: For every file I read, I first check if it's valid UTF-8 using ustring::validate(). If it isn't, I get the locale's character encoding with Glib::get_charset() and pass it to Glib::setenv(G_FILENAME_ENCODING, result_of_get_charset). Otherwise I set the env-variable to again. Bottom line, in any case the call to Glib::filename_to_utf8() will succeed (that's the intention at least). This way I can be sure that even files with mixed encodings (UTF-8 and non-UTF-8) are converted correctly, plus I don't need to force the user to supply these values. However, I'm concerned about runtime costs. How exactly does validate() work? How expensive is it to call on say 1000 files? Are you worried about the codeset of a file's contents or of its filename? You begin by referring to filenames, but you appear to end by referring to the codeset in which a file has been written to. All filenames in any one system will use the same codeset - you cannot have files with mixed encodings, as you put it, in that sense. If you are worried about a file's contents, I cannot comment on the time taken to run Glib::ustring::validate(), but if you do not need the result stored in a Glib::ustring object it would probably be faster to call the glib function g_utf8_validate() directly (which does not require constructing a Glib::ustring object to use), and check the input file line by line. If all you want to do is to validate a filename then the call will take very little time and have no practicable expense, whether you use g_utf8_validate() of Glib::ustring::validate(). On some other points, it is much better for your program to store data to file, and retrieve it, entirely in UTF-8. It is only if you are obtaining data from files written to by other programs in the same system, which you know might be in the system's locale codeset and that might not comprise UTF-8, that you may have to consider codeset conversion. (For files written to by other remote systems the codeset may not be the either the local system's locale codeset nor UTF-8, so calling Glib::locale_to_utf8() would not necessarily do what you want it to do in any case). In any event, calling Glib::get_charset() to obtain the local system's locale codeset seems pointless. Glib::locale_to_utf8() will do this test for you and do nothing if the locale codeset happens to be UTF-8. If all you want to do is to force a conversion of a filename from the locale codeset to UTF-8 and you don't want to bother with the G_BROKEN_FILENAMES or G_FILENAME_ENCODING environmental variables, just use Glib::locale_to_utf8() (this will have the same effect as calling Glib::filename_to_utf8() with the G_BROKEN_FILENAMES environmental variable set). You lose the flexibility of being able to cater for the locale codeset and the filename codeset being different, but how many systems would do something as insane as that anyway? The G_BROKEN_FILENAMES environmental variable is accepted by all versions of glib-2. Only at some later point in the glib-2 release cycle was the G_FILENAME_ENCODING variable adopted (it doesn't work with glib-2.0, but I do not know at what point between glib-2.0 and glib-2.8 it arrived). The G_FILENAME_ENCODING environmental variable works both ways - it determines the operation of both Glib::filename_to_utf8() and Glib::filename_from_utf8 (), and as far as I am aware G_BROKEN_FILENAMES does the same. Chris ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: ustring::validate() costs?
On Thursday 01 December 2005 23:48, Chris Vine wrote: [snip] I said: All filenames in any one system will use the same codeset - you cannot have files with mixed encodings, as you put it, in that sense. To be entirely accurate, perhaps I should add that you can (to the system, any filename is just a series of bytes), but you will completely confuse any file browser and your console or xterm will be likely to be unable to display all or some of the filenames. Chris ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: call connected signal
On Friday 02 December 2005 11:02, Andreas Volz wrote: Hi, how could I force gtkmm to call a signal. I need this for redraw of a GUI part. I connected it this way: target_combo.signal_changed().connect (sigc::mem_fun (*this, Application::on_target_combo_changed)); If I call the on_target_combo_changed() function there're several warnings and the app crash. I think there's a libsig call for this. But I couldn't find it. On your first point, just provide your own custom signal object and connect it to the same slot. On the second, presumably there is a bug in your code. I do not think there is a special libsig call for crashing your application. Chris ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: ustring::validate() costs?
On Saturday 03 December 2005 09:18, Matthias Kaeppler wrote:
[snip]
Yes, with this background, that sounds reasonable. I think it's highly
irritating though that g_filename_to_utf8() isn't the suggested way to
convert filenames to UTF-8, but rather g_locale_to_utf8() (I think this
is essentially what you said right?). It would be very nice to have this
information in the API reference directly.
I only point I was making on this aspect of your post was that:
filename = file_info-get_name();
if (filename.validate())
{
Glib::setenv(G_FILENAME_ENCODING, UTF-8);
Glib::setenv(G_BROKEN_FILENAMES, 0);
}
else
{
std::string charset;
Glib::get_charset(charset);
std::cout Current locale: charset std::endl;
Glib::setenv(G_FILENAME_ENCODING, charset);
Glib::setenv(G_BROKEN_FILENAMES, 1);
}
// this call throws if the filename contains special chars
// and is not encoded in UTF-8, how can this happen??
filename = Glib::filename_to_utf8(filename);
Could be replaced by:
filename = file_info-get_name();
if (!filename.validate()) filename = Glib::locale_to_utf8(filename);
which would produce the same result in a more rational way.
I am not saying this is how you should do it. On a minor point of
implementation, you should catch any exceptions thrown by
Glib::locale_to_utf8() because if the filename passed to it is not in your
locale codeset you will get an exception - which would happen in this code if
the filename you have extracted is in neither the local system's locale nor
UTF-8 codesets. (Likewise you should do the same with Glib::filename_to_utf8
().)
The right way to do it is to set the G_FILENAME_ENCODING or G_BROKEN_FILENAMES
environmental variable in /etc/profile or an executable shell file
in /etc/profile.d, depending on your distribution (which is how system wide
environmental variable should be set), and then use Glib::filename_to_utf8().
This will enable your code to be usable (if G_FILENAME_ENCODING is
appropriately set by the user) with filenames in other than the UTF-8 or the
local system's locale codeset.
Chris
___
gtkmm-list mailing list
gtkmm-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: ustring::validate() costs?
On Saturday 03 December 2005 12:39, Matthias Kaeppler wrote: [snip] Okay, I see. I guess my system is really messed up then, since I obviously have exactly this problem: Some (or even most) of my files are neither encoded in UTF-8 nor in my locale's encoding (that's why g_filename_to_utf8() fails because I haven't set these variables properly). I doubt that you have filenames other than in your locale codeset or UTF-8. You appear to have some of each - you probably created files with Nautilus and because you did not have G_FILENAME_ENCODING or G_BROKEN_FILENAMES set it made the name in UTF-8, and all your others (including those you created via the console) are in your locale codeset. It would be nice to figure out in my program for /each/ file I read, in which character set it is encoded. Is this possible? I only found functions so far which can either read the locale's character set or check if some filename is valid UTF-8 (or not), but no function which individually probes for a certain file in which character set its filename is encoded. This would solve my problem, since I could then use Glib::convert() directly to convert from and to the correct encoding for each filename individually. Maybe this is how Nautilus does it (since it doesn't have any problems reading my files, I guess it has at least /some/ clever mechanism to detect for each file if a conversion is necessary and if so, from which character encoding it has to convert to UTF-8). Looks as if I have to peek at the Nautilus source again, but if you have any good ideas how to solve this without setting these environment variables I'm all ears :) I doubt that is your problem, or that Nautilus bothers to try and deduce your codeset for you if it is in neither your locale codeset nor UTF-8 nor specified in the G_FILENAME_ENCODING environmental variable. However, as you say you can look at the Nautilus source code. Chris ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: patch reviewers
On Friday 02 December 2005 16:46, Murray Cumming wrote:
On Tue, 2005-11-15 at 11:02 +0100, Murray Cumming wrote:
I have given cvs write access to several people. I'd like one (or more)
of them to be an official patch reviewer.
My inbox is not overflowing with replies. I meant you.
Do they know who {they are}/{you is}?
Chris
___
gtkmm-list mailing list
gtkmm-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: License question
On Monday 12 December 2005 08:49, Murray Cumming wrote: The point is that if glibmm (not his code) contains templates released under an unmodified LGPL, he would as he says be required to release any source code which instantiates any of the templates or links (other than dynamically) with code which contains such instantiations. This would apply to anything using libsigc++ (which means that although GTK+ can be used in closed source code, gtkmm cannot), [snip] This is highly debatable - otherwise nobody would be asking. The intention is clear. If someone worries enough about this then they should ask the FSF, who wrote the LGPL. In extreme circumstances, if it was really necessary, we could relicense libsigc++ under the MIT/BSD license, or license it as GPL+exception, as GNU's libstdc++ is licensed: http://gcc.gnu.org/onlinedocs/libstdc++/17_intro/license.html Again, the only opinion I'd pay much attention to on this is the FSFs because they have lawyers. The FSF, who say they are the primary sponsor of GNU, recognise there is a problem as libstdc++ is released under a modified GPL to deal specifically with the template problem, as you yourself note. The problem with the LGPL is explicitly set out in the web page to which you refer, so they at any rate do not regard it as highly debatable. No proprietary developer in his/her right mind would use a LGPL library requiring the instantiation of templates. Modifying the licence would therefore be a good idea, but would require the consent of the authors of the relevant code. Whilst the views of the FSF seem reasonably clear (there is a problem), their views as to the meaning of the licence they have authored would not be probative in English law (about which I do know) in any event, even if they were copyright holders of the code in question, which they are not. The licence would be interpreted by reference to the words it uses. The GPL licence does not state which system of law is to apply to it, so the legal system applying in the case of any particular proceedings affecting any particular code depends on the rules of private international law for the court in which the proceedings are brought, and it is not beyond the bounds of possibility that some of them might have regard to the views of the FSF. At the end of the day it comes down to which jurisdictions recognise another's judgements against their own citizens. That is a matter of international treaty. Chris ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: License question
On Monday 12 December 2005 18:11, R. Douglas Barbieri wrote: So will the FSF sue even though the authors of the library promise not to? The FSF cannot sue. They do not own the copyright to the code. Chris ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: License question
On Tuesday 13 December 2005 21:38, R. Douglas Barbieri wrote: [snip] For example, my business partner and I just started the libx3d project (http://libx3d.sourceforge.net/) and the license we intend to use is the LGPL. There might possibily be some templates available for the library, so we might want to reconsider using the license. But the point is, even released under the LGPL, we are only interested in a) allowing the code to be used in another application, open source or proprietary, and b) if changes are made, share them back out so we all can benefit. This is why for the SSWF library (http://sswf.sf.net), the license chosen was the BSD. The traditional BSD licence does not require your point b, so the SSWF library may have missed its target. (Otherwise OS X would not have been developed by Apple.) It looks as if the GNU libstdc++ licence or a LGPL modified along the lines I have mentioned might be the answer. You can modify the licence any time you like provide that all those who hold the copyright consent - which is the authors unless they have assigned copyright or have produced it in the course of their employment. (This is English law, I do not know about your own jurisdiction.) Chris ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: License question
The LGPL has a specific exemption in section 5 for macros and small inline functions (I think a maximum length of 10 lines is specified to count as a small inline function). It does not include templates (whether of more or less than 10 lines) as it was not designed with C++ in mind. I will look it up this evening and give you the precise text, and what I have done in the past as a modification of the licence (I have used a modified LGPL rather than a modified GPL, and if you wanted to I would have no problem with you adopting the same wording). Chris Message Received: Dec 13 2005, 10:25 AM From: Murray Cumming To: Chris Vine Cc: gtkmm-list@gnome.org, [EMAIL PROTECTED] Subject: *** SPAM *** Re: License question On Mon, 2005-12-12 at 22:20 +, Chris Vine wrote: On Monday 12 December 2005 08:49, Murray Cumming wrote: The point is that if glibmm (not his code) contains templates released under an unmodified LGPL, he would as he says be required to release any source code which instantiates any of the templates or links (other than dynamically) with code which contains such instantiations. This would apply to anything using libsigc++ (which means that although GTK+ can be used in closed source code, gtkmm cannot), [snip] This is highly debatable - otherwise nobody would be asking. The intention is clear. If someone worries enough about this then they should ask the FSF, who wrote the LGPL. In extreme circumstances, if it was really necessary, we could relicense libsigc++ under the MIT/BSD license, or license it as GPL+exception, as GNU's libstdc++ is licensed: http://gcc.gnu.org/onlinedocs/libstdc++/17_intro/license.html Again, the only opinion I'd pay much attention to on this is the FSFs because they have lawyers. The FSF, who say they are the primary sponsor of GNU, recognise there is a problem as libstdc++ is released under a modified GPL to deal specifically with the template problem, as you yourself note. The problem with the LGPL is explicitly set out in the web page to which you refer, so they at any rate do not regard it as highly debatable. Still, I'd prefer to hear directly from an FSF person about this because it does seem vague. I'd like to know a) Is LGPL meaningless for C++ libraries that provide templated types (most C++ libraries)? b) Is LGPL meaningless for C libraries that have macros in their headers? c) Is a certain amount of a) or b) OK? [snip] -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Is Disptacher-functionality Gtkmm only?
On Saturday 31 December 2005 15:51, Daniel Kraft wrote: Hi! My system seems to have some problems with idle signals and the Dispatcher class (as I priviously posted); therefore I used pure GTK+ for idle signals, and it worked. Now I wanted to try the same for Dispatcher, but I couldn't find the GTK+ equivalent! Is that a Gtkmm-added feature? If so, has anyone an idea how to do the same in GTK+ (although this is the wrong mailing list)? Glib::Dispatcher doesn't use idle signals. It uses a pipe to communicate between threads. It is specific to glibmm (it does not have an equivalent in glib), but you can easily make your own with a pipe and a GIOChannel object. If you have a problem with Glib::Dispatcher, it is almost certainly a coding error in your code and not a problem with either glibmm or your system. Chris ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Deleting a timer
On Monday 02 January 2006 14:36, [EMAIL PROTECTED] wrote:
Hi,
I used g_timeout_add to call a function every tot seconds (or minutes).
Now I'd want to delete and add dynamically the timer. In other words,
i've a button that initialize the timer, and another button that stop
the timer. So if i click the first button:
std::cout Inizialiting timer...\n;
guint timer_id;
timer_id =
g_timeout_add(3,(GSourceFunc)scansioneDB::acquisisciAux,true);
and
gboolean scansioneDB::acquisisciAux(bool start)
{
if (!start)
return 0;
else {
std::cout Eseguo operazione pianificata...\n;
return 1;
}
}
If, from the clicked event of the stop button, I call acquisisciAux
with false parameter this stop the timer??? Or i've to call
g_timeout_add(3,(GSourceFunc)scansioneDB::acquisisciAux,false)???
You are on the wrong list, but in any event, the timer is removed if either:
1. g_source_remove() is called on the timer id returned by g_timeout_add, or
2. the callback returns false.
Passing a boolean value to the third argument of g_timeout_add() should fail
to compile (the third argument is a void* and not an int), and it is also
pointless since the assigned value will be passed to every invocation of the
callback, not just the first one. (You could pass an unsigned integer value
with the GUINT_TO_POINTER() macro and then cast it back in the callback with
the GPOINTER_TO_UINT() macro, but it would remain pointless.)
Chris
___
gtkmm-list mailing list
gtkmm-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Deleting a timer
On Monday 02 January 2006 16:10, [EMAIL PROTECTED] wrote: What is the right list, so I can post there? This is the mailing list for the C++ bindings for GTK+ and glib - it would therefore be relevant if you were inquiring about the Glib::signal_timeout().connect() wrapper function for g_timeout_add(). The gtk-list or gtk-app-devel-list would normally be relevant to using the C API of glib. [snip] So, I've to understand better the timer... Anyway a last question: My actual goal is to call a function at an interval, but with different parameters every interval. Specifically, the parameters are the time of the last call to the function (or a specfied time) and the current time (or a specified time). Is it possible with g_timeout_add?? The third argument of g_timeout_add() binds to the callback (as does for example the fourth argument of g_signal_connect()). The timeout callback works the same way as other glib or GTK+ signal callbacks. It is just a program event for the program event loop. You do not say why you need to store timings, but if that is what you need to do, why don't you generate the timings in the callback itself and store the most recent one in a static variable of function scope? If you are programming in C++ you could alternatively make the callback a friend of a class and store the timings as class data (if the data is not a static class member, you will have to pass the 'this' pointer as the third argument of g_timeout_add() so that you can cast it back to the relevant type in the callback in order to reference the object instance concerned). Although many compilers (such as gcc) in practice allow you to pass a static class member function to a function pointer with C linkage (and GTK+ callbacks have C linkage) thus avoiding the need for a friend function, this is not guaranteed to work by the standard as static class member functions cannot have C linkage (they have C++ linkage) and they are therefore different types. Note that the timeout callback is called from the program event loop so the interval you specify in g_timeout_add() is the earliest (not the latest) that your callback will be called, and depends on what other things the program is doing at the time. The timer does not attempt to make up lost time between invocations of the callback. Chris ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: is it possible to 'kill' a thread?
On Monday 16 January 2006 16:00, B.Hakvoort wrote: Hi, I was wondering if it's possible to end a thread from OUTSIDE that thread. I have a thread which executes an un-interruptable function and i'd like to end that execution whenever a user presses the 'cancel' button. I did some searching and found Glib::Thread::Exit, but i'm not sure how it can be usefull in this situation. Any insights in how to accomplish this the 'right' way? You can't with GThread/Glib::Thread. However, if you know that pthreads is the underlying implementation, you can use pthread_cancel(). I think Windows has something similar. Note that pthread_cancel() is a C function. When used in a program written with C++, it is implementation defined whether the destructors of local (automatic) objects are invoked (with linuxthreads they are not, but with NPTL they are - and the same would apply to a call to g_thread_exit()). Accordingly it is best to make no assumptions, and to choose the cancelation point (with pthread_setcancelstate()) for a time when there are only built-in types in local scope, and to use pthread_cleanup_push()/pthread_cleanup_pop() for cleanup of other resources. An alternative is to signal the thread concerned so that it will call g_thread_exit() or throw Glib::Thread::Exit. However if you do this via the main program loop (say, with a Glib::Dispatcher object) then the signalling thread has no control over the time when the other thread will receive the signal. However it becomes very easy for the receiving thread to arrange a suitable time to commit suicide which cleans up properly when it receives the signal (so that g_thread_exit() will be fine). But that in turn means that the receiving thread cannot be in a blocking system function, and enabling the use of blocking system calls is quite a common reason for using separate threads in the first place. In that case you will have to call pthread_cancel() from the other thread. Happily, in POSIX all blocking system calls are cancelation points. There may be problems with using Glib::Thread::Exit with NPTL - see http://mail.gnome.org/archives/gtkmm-list/2005-June/msg00211.html and the follow-ups - although that may have just been the user. Chris ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: is it possible to 'kill' a thread?
On Tuesday 17 January 2006 08:32, Paul Davis wrote: Cancelling a thread is a no no. The general rule of thumb is to do what Ed here is saying. You write your worker thread so that it checks some sort of status flag. This solves a couple of problems, first and foremost, its implementation independant ( not to say that the actual calls are, unless you use something like Glib::Thread ; I imagine, I've only used pthreads cause like any normal *nix developer, I generally shun windows. /rant ) Anyway, that being said, if you do use something like pthreads, there is an alternative method. pthread_signal is a way to signal threads. It works quite a bit like normal process signaling, but on a per thread basis. You can setup your thread signal masks on a per thread basis, and then send messages via signals in this manner. There are some caveats. First, you're gonna need a new enough implementation of pthreads. Second, but really part of the first, this is going to limit portability even between *nix distros. I do alot of Tru64 / FC4 development. Its been awhile so I can't remember if Tru64 supports pthread_signal. pthread_kill() is the POSIX version, but if the signal handler just sets a flag, what's the point? If the threads are in the same process, since there is shared memory you can set a flag directly and be done with it (provided you use a mutex to ensure visibility). Perhaps your proposal was to have the facility to use signals to interrupt blocking system calls which POSIX requires should return with an EINTR error in the presence of a signal where the SA_RESTART flag is not set, but programming this so that appropriate action is taken on every occasion that an asynchronous signal might be received (except by ending up just setting flags) seems to me to be a nightmare. Setting flags in a signal handler also has the problem that it is difficult to ensure memory visibility/synchronisation on multi-processor systems - POSIX mutex functions are not async-signal-safe. You would probably have to use system specific memory barriers. If you use blocking calls in the thread to be cancelled, I think the only workable approach is to use pthread_cancel(). pthread_cancel() is fine if you either use deferred cancelation together with correct and liberal use of pthread_setcancelstate() to limit the only permissible cancelation points to particular blocking functions of interest and control the object state at those points, or you use NPTL or the equivalent threading systems available on commercial UNIXes which will guarantee (as a C++ extension of the POSIX standard) to unwind the stack on cancelation. I have to say I would prefer that to using pthread_kill(). Chris ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Adding event on a bool in ListStore
On Thursday 26 January 2006 19:49, [EMAIL PROTECTED] wrote: On 1/26/06, Bob Caryl [EMAIL PROTECTED] wrote: The prototype of your callback slot is undoubtedly incorrect. Check the callback slot prototyping information for signal_toggled for guidance. Bob It's all the day that i look that... I'm lost... The protoype of the signal_toggled wants an argument of type Glib::ustring*(specifying the treepath for the cellrenderer) and returns void. No it doesn't. It takes an argument const Glib::ustring. My callback is void window1::on_toggled(Glib *ustring)... (i tried also without arguments but nothing change... maybe i've to try with a treepath???) Glib *ustring would be an obvious error. If in fact you wrote Glib::ustring* that would still not match the prototype. Chris ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Removing a widget from its container without destroying it
On Monday 13 February 2006 10:19, Mickael Drean wrote: Well, in fact the problem is in an overloaded function : on_realize and that crash when i call gtk::widget::on_realize() ... I tried with a MyWidget m_Widget[2], and the problem is still there. When I use a Gtk::DrawingArea for example, there is no problem So, i think I have the good gtkmm! But i still don't understand what happen. Why are you calling Gtk::Widget::on_realize() (if that is what you meant by gtk::widget::on_realize())? Chris ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: compile simple example of gtkmozembedmm by myself
On Friday 17 February 2006 22:34, Tobias Eberle wrote: Hello, When you downloaded, extracted, decompressed, configured, made and installed the gtkmozembedmm tarball, how did you do it? I installed gtkmozembedmm into /usr/local. The examples are compiled fine by using the shipped makefiles. I want to compile it by myself because I want to see how it works and how I must compile my own app hopefully using it in the future. Does your PKG_CONFIG_PATH environmental variable include /usr/local/lib/pkgconfig ? It is doesn't, pkg-config will not find anything in /usr/local/lib/pkgconfig. Chris ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Using Glib::ustring with std::wstring
On Monday 20 February 2006 18:41, Loïc Joly wrote: Hello everybody, I'm starting to use LibXml++ for a new project, and in this context, I'd like to convert from std::wstring to Glib::ustring and the other way around. I can see some convertion functions with std::string, but not with std::wstring. Am I missing something ? std::wstring (and wchar_t) are types, not codesets. (As you refer to Glib::ustring, the narrow character codeset that you have in mind is presumably UTF-8). If sizeof wchar_t is 4 and you are interested in UCS-4/UTF-32, glib has g_utf8_to_ucs4() and g_utf8_to_ucs4_fast() which will do what you want. (Note however that you will need to free the return values of these after loading them into your std::wstring object.) If you are using windows you will probably want to use g_utf8_to_utf16(). For the reverse there is g_ucs4_to_utf8() (and g_unichar_to_utf8()) and g_utf16_to_utf8(). Chris ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: gettext
On Tuesday 21 February 2006 10:57, Volosatov Alexander wrote: Sorry, this is not by gtkmm, but maybe somebody help. I use gettext for i18n. 1. how i can change language of program while program is running? 2. Program language != local lang. and local lang == progr. lang only when i do: bind_textdomain_codeset(default, ru_RU); Why? You question 2 is not intelligible, but in answer to question 1 you would normally set the locale programmatically with setlocale(). gettext will use the locale so set. (Note that LANGUAGE has highest priority, then LC_ALL, and lastly LANG.) Chris ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: a re-display method for my DrawingArea
On Wednesday 01 March 2006 22:19, Paul Davis wrote: On Wed, 2006-03-01 at 22:04 +, eduardo fiss beloni wrote: Hello someone knows a method to re-display a Gtk::DrawingArea derived whenever I want. for example: In my Gtk::Window derived, I have a Gtk::Button and a Gtk::DrawingArea derived and whenever I press the Gtk::Button (the button_pressed() event will be called), the Gtk::DrawingArea derived must be updated. however I don't know this update method... call the queue_update() method of the drawing area from the button press handler. the drawing area will get an expose event; implement on_expose_event() for the DrawingArea derived object and make it draw stuff there. Gtk::Widget::queue_draw() I think, rather than queue_update() (I don't think it has a queue_update() method). Chris ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: SigC::Object ambigous base class
On Tuesday 04 April 2006 09:26, Josepo Urrutia wrote: Maybe this is not a gtkmm related question, if so sorry for the inconveniences. I must do a change to a quite old program ( uses gtkmm 2.2.12 ) that affects the inheritance tree. During the conversion I get this compiler error : In file included from /usr/include/sigc++-1.2/sigc++/object_slot.h:73: /usr/include/sigc++-1.2/sigc++/object_slot.h: In constructor `SigC::ObjectSlotNode::ObjectSlotNode(void (*)(void*), T*, void*, T2) [with T = Appl, T2 = bool (Appl::*)()]': /usr/include/sigc++-1.2/sigc++/slot.h:211: instantiated from `SigC::Slot0R::Slot0(SigC::SlotNode*) [with R = bool]' /usr/include/sigc++-1.2/sigc++/object_slot.h:73: instantiated from `SigC::Slot0R SigC::slot(O1, R (O2::*)()) [with R = bool, O1 = Appl, O2 = Appl]' appl.cc:6092: instantiated from here /usr/include/sigc++-1.2/sigc++/object_slot.h:45: `SigC::Object' is an ambiguous base class of `Appl' make: *** [sonda.o] Error 1 One of the changes has been moving the inheritance of SigC::Object from the class 'Appl' to a more generic class. Are you using multiple inheritance? If so, you may have two SigC::Object objects in the inheritance path, thus giving rise to an ambiguity. Chris ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: virtual inheritance and Glib::Interface
On Wednesday 05 April 2006 22:57, Jonathon Jongsma wrote: On 4/5/06, Murray Cumming [EMAIL PROTECTED] wrote: On Wed, 2006-04-05 at 13:37 -0500, Jonathon Jongsma wrote: Just so I understand, what do you think is not true? The fact that multiple Interface objects might be created? Yes. Not true, I think. Here's an attempted explanation: Gtk::TreeStore inherits non-virtually from TreeModel, TreeSortable, TreeDragSource, and TreeDragDest Because each of these inherits virtually from Interface, TreeStore has only one copy of Interface. That's kind out counterintuitive, but I Perhaps you misunderstood. I was saying that these classes do NOT inherit virtually from Interface. At least looking at CVS they do not appear to be. It would only be useful to, for instance, inherit TreeModel virtually from TreeStore and ListStore, if I was going to create classes like this: Yes, I was not trying to suggest that ListStore inherit from TreeModel virtually, I was suggesting that since ListStore inherits from 4 classes with a common ancestor (of which TreeModel is one), those 4 classes should use virtual inheritance to inherit from Interface, which they don't appear to do. But then if they have anything other than a default constructor you can make them practically unusable, because of the need to invoke the constructor from the most derived class. If it doesn't matter having multiple Interface objects (and I do not know if it does or it doesn't) you may be better off leaving things as they are. Chris ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Glib::ustring::lovercase()
On Thursday 06 April 2006 08:45, Volosatov Alexander wrote: Strange behavior of this function. It work properly only with Roman letters, but with Cyrillic alphabet do not work. Befor this I convert string to utf8. Where is problem? Probably you have not correctly converted the string to utf8. If by Roman you mean ASCII, all ASCII characters are valid utf8, so conversion cannot have failed. Chris ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: gtkmm.org down?
On Saturday 22 April 2006 23:49, Chris Vine wrote: On Tuesday 18 April 2006 17:07, Murray Cumming wrote: On Tue, 2006-04-18 at 10:55 -0500, Jonathon Jongsma wrote: Is the gtkmm website down? I don't get anything but a blank index page and 404s for everything else. It does seem to be down. It was working about an hour ago. Let's give it another hour or so. I'll ask again for GNOME to take over hosting. Sourceforge do seem to have been proving of late the aphorism that you get what you pay for. They still have not fully recovered from their CVS outage (and anonymous CVS read access is still out, and there are still intermittent statistics problems). And now developer access to sourceforge is down since yesterday. Sigh. ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: sigc undefined?
On Saturday 13 May 2006 9:28 pm, Joe Van Dyk wrote: I guess I'm doing something stupid, but dunno what it could be. Running this on Ubuntu Dapper. Why isn't sigc not declared? Did I not install something correctly? [EMAIL PROTECTED]:~/projects/gtkmm/hello_world$ g++ main.cpp `pkg-config gtkmm-2.0 sigc++-2.0 --cflags --libs ` -o hello main.cpp: In constructor 'Hello_World::Hello_World()': main.cpp:20: error: 'sigc' has not been declared main.cpp:20: error: 'mem_fun' was not declared in this scope gtkmm-2.0 uses libsigc++-1.2. Only gtkmm-2.4 or above uses libsigc++-2.0, so you either need to install a later version of gtkmm or install libsigc++-1.2. If you do the latter, you will have to use gtkmm-2.0/libsigc++-1.2 syntax, and not gtkmm-2.4/libsigc++-2.0 syntax. Chris ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: How to properly exit a thread?
On Sunday 14 May 2006 06:10, Xiangfei Jia wrote: I created a thread like this: Glib::Thread *const read = Glib::Thread::create(sigc::mem_fun(node, FrameNode::read_new_data), false); Sometimes, when I exit from my program I got this error message: GThread-ERROR **: file gthread-posix.c: line 247 (): error 'Device or resource busy' during 'pthread_cond_destroy ((pthread_cond_t *) cond)' aborting... Aborted I looked at the Glib reference, I found out I should use throw Glib::Thread::Exit http://www.gtkmm.org/docs/glibmm-2.4/docs/reference/html/classGlib_1_1Thre ad_1_1Exit.html(); to exit my thread. But I don't really know how to use this properly. Can anyone tell me how to use it please! Glib::Thread::Exit is an exception which can be thrown in a thread to cause the thread to terminate itself, as an alternative to calling g_thread_exit(). g_thread_exit() may or may not unwind the stack of the terminating thread when it is called - that depends on the underlying implementation (if the underlying threading system is the NPTL implementation of pthreads it will, if it is the linuxthreads implementation of pthreads or, I believe, Windows threads it will not). The idea behind Glib::Thread::Exit is to ensure stack unwinding, so that local objects having non-trivial destructors are correctly destroyed, by propagating the exception through the stack until being caught by the Glib::Thread implementation just before the thread terminates itself. You should not normally try to catch Glib::Thread::Exit yourself (you should only do so if you want to check whether you want to proceed with thread termination part-way through the stack unwinding). You do not need to bother with Glib::Thread::Exit (or g_thread_exit() or pthread_exit()) if your thread terminates naturally by the slot function called in Glib::Thread::create() (in your case FrameNode::read_new_data()) returning. It is a mechanism to procure premature termination. The error you report appears to indicate that a thread was waiting on a condition variable when the condition variable was destroyed (probably when the Glib::Cond object concerned went out of scope causing its destructor to call pthread_cond_destroy()). That indicates a logic error somewhere in your code, and according to the POSIX standard it also gives rise to undefined behaviour. Chris ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Fwd: memory
On Friday 19 May 2006 06:45, Ramashish Baranwal wrote: [snip] shared_ptr is used to provide access to the underlying object, so you need not modify the same instance of the shared_ptr in another thread. Normally different threads used different instances of shared_ptrs all providing access to the same object. As a side note if you look closely even assignment of shared_ptrs modify their internals (reference count). But that is an implementation detail. To make shared pointers employing reference counting thread safe in the pointer sense, the only thing which needs to be treated atomically thread-wise is the reference count. There are some smart pointers which claim to provide low-overhead locking for the referenced object (see eg http://axter.com/smartptr/ and its associated mutex_wrapper class). I find it difficult to believe it is true that this can be done generically in a way which is either efficient or avoids deadlocks, but from time to time you are surprised. Chris ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Fwd: memory
On Friday 19 May 2006 06:45, Ramashish Baranwal wrote: Thats right. boost::shared_ptr is not designed to provide mutual exclusion. Its thread safe in the sense of maintaining its own integrity, i.e. you can safely use shared_ptr(s) in multiple threads to access the same underlying object. Its upto the underlying object to provide mutual exclusion (preventing simulataneous modification). But you cannot safely modify a shared pointer (ie apply a non-const operation to the shared pointer) in one thread and read from or modify the same instance of shared pointer in another thread. shared_ptr is used to provide access to the underlying object, so you need not modify the same instance of the shared_ptr in another thread. Normally different threads used different instances of shared_ptrs all providing access to the same object. As a side note if you look closely even assignment of shared_ptrs modify their internals (reference count). But that is an implementation detail. you cannot safely modify the referenced object in one thread and read or modify it in another thread, unless the object does its own locking.) What this means is that you can have the same object referenced by a container of shared pointers in one thread and a container of shared pointers in another thread provided that you arrange separate locking of the referenced object. The circumstances in which you might want to do that are quite limited. Not really. This cirumstance is in fact very common for single threaded applications, for applications which use their resources in only one thread, or for applications which serialize the modification of their resources to one thread. I see shared_ptr as a way of providing automatic memory management and not mutual exclusion. The cost of having locking for the underlying object in a shared_ptr would be prohibitive for applications that doesn't require it. Your lengthy response deserves a slightly longer answer than may earlier one, now I have had my evening meal and watched the news on the TV! I agree with what you wrote in general, but on your so you need not modify the 'same instance of the shared_ptr' in another thread, the point is that in the particular multi-threaded use to which you refer it would be usual (and usually necessary) for a shared pointer intended for use in one thread (thread 1) to be used to initiase a shared pointer to the same referenced object in another thread (thread 2). That is not thread safe if the first mentioned shared pointer might have a non-const operation carried out on it in thread 1 at or around the same time as it is used to intialise a pointer in thread 2, unless additional synchronisation is carried out. On your last paragraph, you were in fact agreeing with me. In each of the cases you mention (single threaded applications, for applications which use their resources in only one thread, or for applications which serialize the modification of their resources to one thread) thread safety of the shared pointer is irrelevant. I also agree that it is not desirable for a shared pointer to attempt also to lock the referenced object, although I gave you a link to a pointer implementation which does in fact do that and claims to do so efficiently. This is probably becoming a bit off topic, having derived from my remark that thread safe has a number of different meanings, with which I think we both agree. Chris ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: locale_to_utf8 crashes on WinXP with Gtkmm 2.8.4 / Glibmm 2.8.6 and Gtk+ 2.8.18 / Glib 2.10.3
On Saturday 03 June 2006 12:19 am, Vinzenz 'evilissimo' Feenstra wrote: Hi, I'm trying to use a string with german umlauts in an application and Glib::locale_to_utf8 returns an invalid string. If I execute this: Glib::ustring test = Glib::locale_to_utf8(äöüß); and I retrieve an invalid object Glib::ustring the debugger shows me an Bad Pointer in this object. I'm wondering if this _can_ be a Glibmm problem or if it is more a Glib problem? Btw anyone knows another GTK+ package like this one from gladewin32.sf.net? It is very bad practice to call Glib::locale_to_utf8() on a string literal because it will only work if the codeset locale on the machine on which the code is compiled is the same as the codeset in which the string literal happens to have been written. These may not even be the same if the code is written and compiled on the same machine (it will depend on the editor with which the code is being written). If you want a string literal to be in UTF8 then write it in UTF8, or write it in some other known codeset and use codeset conversion which does not base itself on the locale. Chris. ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: locale_to_utf8 crashes on WinXP with Gtkmm 2.8.4 / Glibmm 2.8.6 and Gtk+ 2.8.18 / Glib 2.10.3
On Saturday 03 June 2006 23:09, Chris Vine wrote: It is very bad practice to call Glib::locale_to_utf8() on a string literal because it will only work if the codeset locale on the machine on which the code is compiled is the same as the codeset in which the string literal happens to have been written. These may not even be the same if the code is written and compiled on the same machine (it will depend on the editor with which the code is being written). Actually, on reflection it is more problematic than that. It will only work reliably if the codeset of the string literal as saved to file by the editor and compiled into the binary happens to be the same as the locale codeset under which the program is run by any particular user. Chris ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: communication between different parts of application via signals
On Sunday 25 June 2006 18:13, Joe Van Dyk wrote: On 6/25/06, Joe Van Dyk [EMAIL PROTECTED] wrote: Hi, Say a user clicks a checkbox in a menu that affects three other parts of the application. Would a signal be the best way to communicate that change to the rest of the application? How would that work? Would I create a custom signal or slot? How would the other parts of the application listen to that signal? Would I create the slot and then pass that slot to the other parts of the application (i.e. in a constructor)? Sorry for the basic questions, but signals and slots and functors are still confusing to me. I'm also a gigantic fan of unit testing -- are signals unit testable? Historically, I've hooked up a function to the clicked event of the check box. And that function calls member functions of the different objects in the application. So, signals aren't used for communication. But something about that seems smelly. I do not really understand what you are saying. sigc slots are just callbacks, executed at the point the signal is invoked. Nothing listens to them; they just execute when called, like any other function pointer or functor or callback. If the callback function calls other member functions it does so because you have coded the callback function to call the member functions. Chris ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: communication between different parts of application via signals
On Monday 26 June 2006 06:33, Joe Van Dyk wrote: On 6/25/06, Chris Vine [EMAIL PROTECTED] wrote: On Sunday 25 June 2006 18:13, Joe Van Dyk wrote: [snip] Historically, I've hooked up a function to the clicked event of the check box. And that function calls member functions of the different objects in the application. So, signals aren't used for communication. But something about that seems smelly. I do not really understand what you are saying. sigc slots are just callbacks, executed at the point the signal is invoked. Nothing listens to them; they just execute when called, like any other function pointer or functor or callback. If the callback function calls other member functions it does so because you have coded the callback function to call the member functions. Ardour makes heavy use of libsigc++ as a way to provide anonymous coupling between components, particulular between the backend and user interface. The code makes heavy use of the Model-View-Controller programming model, and attempts to draw from the best work on programming pattern languages. From http://ardour.org/development . That's what I'm asking about. I wonder if I'm not understanding anonymous coupling correctly. Hm. This doesn't seem to have anything to do with your original post, which didn't really make sense. Any form of callback mechanism, whether plain function pointers, function objects, libsigc++, .NET delegates or the numerous similar techniques help promote loose coupling of objects (if, as I assume, that is what is meant by anonymous coupling). Loose coupling of objects promotes modularity which promotes good code organisation which promotes maintainability and extensibility. If you view the libsigc++ signal/slot mechanism as a means of organising your code through type safe function pointers (callbacks) suitable for use with class methods and with automatic disconnection of the callbacks when relevant objects cease to exist then you will not be far out. It is not magic (it doesn't create code execution paths you have not written). Chris ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Which button is used on a drag?
On Tuesday 08 August 2006 22:59, Mark Tilford wrote: [snip] Also, what's the best way to limit a drag to being within a single application? I found the direct method of putting the PID in the TargetEntry; is there a better way? The GTK+ function gtk_drag_dest_set() takes as its third argument an array of GtkTargetEntry structs by pointer (one for each drag/mime type employed, such as text/plain and STRING). Each struct has a member called flag, which can be passed (amongst other things) the GTK_TARGET_SAME_APP flag, which if applied will cause the drag destination only to accept drops from the same application. I do not have easy access to gtkmm documentation at the moment but I assume something similar can be done with Gtk::Widget::drag_dest_set(). Chris ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Creating widgets at runtime
On Wednesday 13 September 2006 15:08, andypaxo wrote: From all the replies given I am now doing the following: - Creating a widget via new() - Adding it to a container - Using gtkmm's manage() to take care of it after that And now widgets can be created and got rid of at any time during execution. If what you are doing is creating objects on demand, that's generally the way to do it, but creating objects on freestore with the new expression can be quite time/CPU intensive and if the widget is likely to be frequently used, instead of deleting it and then recreating it later, it can be better just to hide it and then show it again (or call Gtk::Window::present() if it is an entire window) on demand. Another alternative for a frequently used widget which is only shown on demand is to create it statically and add and remove it from its container (and/or show and hide it) as required. Chris ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Problems reading from IOChannel
On Thursday 14 September 2006 11:27, Javier Aranega wrote: Hi !! The problem was a codification problem when reading the Glib::IOChannel codification from a file that was codificate with ISO-8859-15, extensible too for reading this from a pipe with Glib::IOChannel. The solution was very simple, with the set_codification(Glib::ustring) method of IOChannel: using namespace Glib; RefPtrIOChannel io; io = IOChannel::create_from_file(filename, r); io-set_encoding(ISO-8859-15); Now it works fine. Perhaps this helps anyone. Javi Aránega *Case 1: Trying to read a text file [snip] The file that I try to read is a text file with ascii characters. [snip] *Case 2: Using IOChannel with pipes to send/receive text between This code work well in the most of the cases, but sometimes I get this exception, I guess that could be some problem with the characters that I read, but I don't understand because sometimes works sometimes I get the exception if I work with normal characters (ascii). I have tried some validate methods, but it doesn't work. How I could know what really causes the problem? Someone have idea of how to fix that problem? Any suggestion? I was wondering whether to respond to this when you first posted, but as you said in both cases it occurred with ASCII characters, which comprise valid UTF-8 (and as it happens, also valid ISO-8859-15) I assumed it must be something else with your code. You must have been putting non-ASCII characters, with a value greater than 127, into the Glib::IOChannel object. You will get conversion exceptions if you try to put characters into a Glib::IOChannel object which don't match the current encoding (which by default is UTF-8). By the way if your use of Glib::IOChannel is codeset neutral, then you may be better off setting the encoding to (if you do this no codeset conversion will be attempted, so any stream of bytes, including binary, will be accepted). Hardcoded codeset conversion as you have done it can be quite dangerous (particularly if different users may be using different codesets). Depending on the usage you may want to get the user's locale programmatically and use that in the call to Glib::IOChannel::set_encoding(). Chris ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Threading Problem
On Saturday 23 September 2006 12:24, Pavel Rojtberg wrote: Since I could not find any gtkmm threading tutorial that covers glib threads with use of gtkmm, I relied on the pygtk documentation: http://www.async.com.br/faq/pygtk/index.py?req=showfile=faq20.001.htp I used Glib::thread_init() instead of gobject.threads_init(), but could not find any equivalent for gobject.idle_add(), so perhaps that is where my problems originate from. Anyway the problem is that sometimes the interface just stops being updated while still emmiting events, so I can use the close button. You cannot access GTK+ in more than one thread without using the global GDK lock (and you cannot do it all, with or without the GDK lock, under windows). This explains how GTK+ interacts with glib threads: http://developer.gnome.org/doc/API/2.0/gdk/gdk-Threads.html To post events using gtkmm, see Glib::Dispatcher. You can also use the raw C function g_idle_add() if you wish, but this is not wrapped in glibmm (presumably because glibmm provides Glib::Dispatcher, which glib does not). Either of these will execute the callback in the thread in which the main program loop (and by default GTK+) execute, so avoiding the need to use the GDK global lock. If you use g_idle_add(), make sure the handler returns FALSE so that it only fires once. Chris ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Threading Problem
On Tuesday 26 September 2006 23:29, Chris Vine wrote: On Saturday 23 September 2006 12:24, Pavel Rojtberg wrote: Since I could not find any gtkmm threading tutorial that covers glib threads with use of gtkmm, I relied on the pygtk documentation: http://www.async.com.br/faq/pygtk/index.py?req=showfile=faq20.001.htp [snip] You cannot access GTK+ in more than one thread without using the global GDK lock (and you cannot do it all, with or without the GDK lock, under windows). This explains how GTK+ interacts with glib threads: http://developer.gnome.org/doc/API/2.0/gdk/gdk-Threads.html To post events using gtkmm, see Glib::Dispatcher. You can also use the raw C function g_idle_add() if you wish, but this is not wrapped in glibmm (presumably because glibmm provides Glib::Dispatcher, which glib does not). Either of these will execute the callback in the thread in which the main program loop (and by default GTK+) execute, so avoiding the need to use the GDK global lock. If you use g_idle_add(), make sure the handler returns FALSE so that it only fires once. I allowed the fact that you were unable to find any documentation on an equivalent to PyGTK's gobject.idle_add() to unduly influence me. Although I never use it in glibmm, it does exist - see http://www.gtkmm.org/docs/glibmm-2.4/docs/reference/html/classGlib_1_1SignalIdle.html So you can use either Glib::Dispatcher or Glib::SignalIdle. Chris ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Threading Problem
On Wednesday 27 September 2006 13:28, Pavel Rojtberg wrote: Chris Vine wrote: On Saturday 23 September 2006 12:24, Pavel Rojtberg wrote: Since I could not find any gtkmm threading tutorial that covers glib threads with use of gtkmm, I relied on the pygtk documentation: http://www.async.com.br/faq/pygtk/index.py?req=showfile=faq20.001.htp I used Glib::thread_init() instead of gobject.threads_init(), but could not find any equivalent for gobject.idle_add(), so perhaps that is where my problems originate from. Anyway the problem is that sometimes the interface just stops being updated while still emmiting events, so I can use the close button. You cannot access GTK+ in more than one thread without using the global GDK lock (and you cannot do it all, with or without the GDK lock, under windows). This explains how GTK+ interacts with glib threads: http://developer.gnome.org/doc/API/2.0/gdk/gdk-Threads.html To post events using gtkmm, see Glib::Dispatcher. You can also use the raw C function g_idle_add() if you wish, but this is not wrapped in glibmm (presumably because glibmm provides Glib::Dispatcher, which glib does not). Either of these will execute the callback in the thread in which the main program loop (and by default GTK+) execute, so avoiding the need to use the GDK global lock. If you use g_idle_add(), make sure the handler returns FALSE so that it only fires once. Chris thanks for your reply. meanwhile I asked on the IRC and came out with the Glib::signal_idle().connect(), which is as far as I can see the equivalent of g_idle_add(). But while trying to use it I noticed that sigc++ does not work with Glib::RefPtr - I just could not bind Gtk::TextBuffer::insert without a wrapper function... Anyway which implementation would hou consider as the cleaner one signal_idle or dispatcher? Both Glib::Dispatcher and Glib::SignalIdle should work similarly. Glib::Dispatcher uses a pipe under the covers, as does Glib::SignalIdle when used with Unix-like systems, although with different priorities in the main program loop, which will probably not make any difference in practice. I do not know if Glib::Dispatcher works with windows if you are interested in portablility, although Glib::SignalIdle does. The important thing with Glib::SignalIdle is to remember to have the handler return false. Returning true can turn your main loop into a busy wait. In relation to binding arguments, there are apparently some difficulties in storing a smart pointer in a slot - see http://mail.gnome.org/archives/libsigc-list/2006-August/msg8.html , which probably includes storing Glib::RefPtr objects in them. Whether it applies when you bind the RefPtr to the slot as an argument with sigc::bind I do not know. If that is a problem you can push the argument onto a std::queue (say in class scope) and pop it off again in the handler, although that is less appealing aesthetically. In the threading context you also need to consider memory visibility of the argument passed from one thread to the other - it seems very unlikely that shunting bytes via a pipe to trigger the main loop (which is what happens under the covers) is not going to cause memory to sync up, but POSIX doesn't guarantee it - to get that guarantee you need to have a release in the sending thread and an acquire in the receiving one, typically by using a mutex. Using a std::queue would deal with this automatically as you would in any event protect access to the queue with a mutex in this use. In practice C programmers do the equivalent with g_idle_add() and GAsyncQueue (for the data). This is probably also what PyGTK uses to bind arguments. With g_idle_add() you can also pass the data as the data argument of that function, but then you would have to provide your own locking in multi-threaded use. You could of course use the C functions in your C++ code if you want. They are less opaque and it is easier to see how locking and visibility issues will work out than when wrapped for C++. Chris ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Sort Indicator
On Monday 09 October 2006 09:20, Surya Kiran Gullapalli wrote: Hi all, I've a gtkmm application written and linked to gtkmm-2.8. Now after gnome-2.16 released. I've linked my application to gtkmm-2.10. Every thing went fine, except that the sort indicators for gtk_tree_view were not shown any more. Any ideas? It's a bug. See http://bugzilla.gnome.org/show_bug.cgi?id=352738 . Chris ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Find out if a widget or window is actually visible?
On Wednesday 25 October 2006 10:21, Toralf Lund wrote: Does Gtkmm/Gdkmm offer a nice and simple way to find out if a widget or window is actually visible to the user, i.e. is mapped *and not obscured by another window*? I mean, .e.g Gdk::Window::is_viewable () and Gdk::Window::is_visible ()/Gtk::Widget::is_visible() will answer only first half of that question, I believe, i.e. they will tell me whether the window/widget is mapped, but not check if it is covered by something else. I am not entirely sure if I understand you but Gtk::Widget::is_visible() will tell you whether the widget is obscured. (Note however that a minimised window still counts as visible so in practice you will need to check for both.) The best thing is to connect to the Gtk::Widget::signal_visibility_notify_event() signal of the Gtk::Window object concerned. The GdkEventVisibility argument passed to the slot has an enumerated member variable called 'state' of type GdkVisibilityState which can tell you whether the widget is wholly or partially obscured (it has state values of GDK_VISIBILITY_UNOBSCURED GDK_VISIBILITY_PARTIAL and GDK_VISIBILITY_FULLY_OBSCURED). The callback will be called whenever the visibility state changes. Chris ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: *** SPAM *** Re: Find out if a widget or window is actually visible?
On Monday 30 October 2006 08:10, Toralf Lund wrote: Chris Vine wrote: On Wednesday 25 October 2006 10:21, Toralf Lund wrote: Does Gtkmm/Gdkmm offer a nice and simple way to find out if a widget or window is actually visible to the user, i.e. is mapped *and not obscured by another window*? I mean, .e.g Gdk::Window::is_viewable () and Gdk::Window::is_visible ()/Gtk::Widget::is_visible() will answer only first half of that question, I believe, i.e. they will tell me whether the window/widget is mapped, but not check if it is covered by something else. I am not entirely sure if I understand you but Gtk::Widget::is_visible() will tell you whether the widget is obscured. (Note however that a minimised window still counts as visible so in practice you will need to check for both.) I thought I proved by testing that is_visible() would merely check whether show() had been called - not if the widget or window was actually visible to the user, but maybe I got it wrong... The signal responds to things done on the desktop rather than by you. You (the programmer) can keep your own flags about what you have done programmatically. For that reason if hide() is called the signal is not emitted (but Gtk::Widget::is_visible() will correctly state that it is not visible). I do not really understand what you mean about show(). If you have called hide() and it remains hidden (that is, you have not called Gtk::Window::present() in the case of a window or Gtk::Widget::show() in the case of a widget) then Gtk::Window::is_visible() will return the correct result, at least when I use it. Chris ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Find out if a widget or window is actually visible?
On Wednesday 01 November 2006 09:18, Toralf Lund wrote: I suspect that you did not understand my original question. I want to know if the user can actually see the widget, not just if it is theoretically visible in the sense that it has been shown via show() and not subsequently hidden via hide(). In other words, I'm looking for a call that also returns false if for instance the widget is covered by a different window. I have already explained that Gtk::Widget::is_visible() does this, and that you can get greater information about whether a widget is fully or partially obscured by connecting to the Gtk::Widget::signal_visibility_notify_event() signal. If this does not work for you then you must be doing something wrong. Chris ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Gtk::Window
On Friday 15 December 2006 16:38, Jamiil Abduqadir wrote: Howdy! On a Gtk::Window, I want to place some frames, however, because of the nature of Gtkmm, the frames are displayed in the centre of the Gtk::Winodow widget. I would rather have the widgets in the Gtk::Window widget shifted to the left, is there a method that could do this. I have tried, n'am still trying, to find this method but to no avail. Use Gtk::Alignment. Chris ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: A signal for Gtk::MessageDialog
On Thursday 28 December 2006 03:03, Jamiil Abduqadir wrote: Hello, I am writing a class that derives from 'Gtk::MessageDialog'. What does the class do? you got it, it displays a dialog box with some information on it. Now, to the problem. Just like any 'Gtk::MessageDialog' it has a button in there that I need to connect to a signal, but since I don't know the name of the button, I cannot write something like Mybutton.signal_clicked().connect(sigc::ptr_fun(on_button_clicked)); Gtk::MessageDialog derives from Gtk::Dialog which has a Gtk::Dialog::get_action_area() method returning a pointer to its Gtk::HButtonBox member. Gtk::HButtonBox derives from Gtk::Box and you can obtain its childer (the buttons) with Gtk::Box::children(). However you should rarely need to do that. You can just connect to Gtk::Dialog::signal_response signal. The response_id parameter will indicate which button was pressed (if the dialog has more than one button). Chris ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Gtk::Main and GMainLoop
On Monday 01 January 2007 02:44, Matt Hoosier wrote: On 12/31/06, Andreas Volz [EMAIL PROTECTED] wrote: Hello, is it possible to get access to the GMainLoop from a Gtk::Main? Or have I to use a Glib::MainLoop instead if I need access to the GMainLoop? You may have trouble getting at the GMainLoop instance used to implement the UI thread of a Gtk+ program. Its instance is totally hidden inside static variables of gtkmain.c, and there's no accessor function to fetch it out of there. There's probably nothing GlibMM or GtkMM can do to give the GMainLoop instance (wrapped or otherwise). http://developer.gnome.org/doc/API/2.0/gtk/gtk-General.html says It's OK to use the GLib main loop directly instead of gtk_main(), though it involves slightly more typing. So with GTK+, instead of calling gtk_main() you can instead call g_main_loop_new(), and then call g_main_loop_run() on the returned GMainLoop object (and store that object for future use if required). Presumably (although I do not know as I haven't tried it) instead of calling Gtk::Main::run(), it would be possible to call Glib::MainLoop::create(), and then call Glib::MainLoop::run() on the returned MainLoop object, which you could store. You would still, however, be required to have created the singleton Gtk::Main object prior to doing so. Chris ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Widget mask out clicks
On Thursday 04 January 2007 08:28, johnmb wrote: Paul Davis wrote: On Wed, 2007-01-03 at 01:14 -0800, johnmb wrote: I am trying to make a widget insensitive to mouse clicks but active in all other respects using the following statement :- m_TreeView-set_events(~Gdk::BUTTON_PRESS_MASK); This doesn't work, what am I misunderstanding about event masks ? m_TreeView-unset_events (Gdk::BUTTON_PRESS_MASK); Thanks for the reply Paul, I tried your suggestion but get the following error message when compiling gui_menu.cc:76: error: 'class Gtk::TreeView' has no member named 'unset_events' Your original approach was right: set_events() will reset the event mask (as opposed to add_events() which will not), although a better approach may be to call m_TreeView-set_events(m_TreeView-get_events() ~Gdk::BUTTON_PRESS_MASK). However, did you call set_events() before the widget was realised? It won't work if you do not. Chris ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Widget mask out clicks
On Thursday 04 January 2007 16:55, johnmb wrote: Thanks Chris, I tried your statement as follows :- m_TreeView = new Gtk::TreeView(); m_TreeView-set_events (m_TreeView-get_events() ~Gdk::BUTTON_PRESS_MASK); As you can see, I can't perform set_events any earlier than this as m_TreeView is created by the immediately preceeding instruction; however, it still allows mouse clicks through. Is Gdk::BUTTON_PRESS_MASK the correct bit mask to use ? I couldn't offer an opinion - I do not know what you are trying to do (or stop happening). Try unsetting Gdk::BUTTON_RELEASE_MASK also. If you are interesting in pointer motion, there are motion events/masks also. There are also button motion masks, which receive pointer motion events when a button is pressed. Chris ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Widget mask out clicks
On Friday 05 January 2007 16:28, johnmb wrote: All I am trying to is to make the TreeView widget insensitive to mouse clicks. I am putting together a touch sensitive screen application and peoples fingers are going to be too thick to reliably control the tree directly so I am using separate buttons at the bottom of the screen to navigate the tree. I want to inhibit the mouse clicks on the tree itself to avoid accidental corruption of the cursor position by peoples fingers brushing against the screen as they move from one part of the screen to another. I tried unsetting Gdk::BUTTON_RELEASE_MASK also but to no avail. There is something about having to overload the events themselves in the docs but I wasn't sure about which methods these referred to. Have you done this yourself. You can connect to the gtkmm signal proxies for the GDK events concerned with the second argument (the after argument) of false so that they are called before the default signal handler, and return true in the callback, which will stop further propagation of the event concerned. You can also overload the equivalent protected virtual function equating to the signal and return true from that, which will also prevent event propagation if all works correctly, although I would prefer connecting directly to the signal proxy as mentioned above. (I have a folk memory that on one or two occasions the protected virtual functions didn't quite do what I wanted when returning true.) That is the only way to do it if you want dynamically to switch event handling on and off after the widget has been realised. However, none of that should be necessary if you set the event bit mask correctly and you do so before the widget concerned is realised. With raw (C) GDK/GTK+ you can also block the signal dynamically with the g_signal_handler_block()/g_signal_handler_unblock() functions, but to use that with gtkmm you would probably have to connect directly to the C (GObject) signal for the event because I don't think that the gtkmm signal proxies expose the underlying GObject signal handler id. However, are you sure you are actually blocking events for the correct widget? It sounds as if you are not, but I don't know to any degree of detail how GtkTreeView propagates events between renderers to columns to tree views and the like. Chris ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Adding custom GDK events
On Friday 12 January 2007 01:20, Daniel Elstner wrote: Am Freitag, den 12.01.2007, 00:23 + schrieb Chris Vine: With Glib::signal_idle() you have to reconnect the slot every time you want it to fire (and make sure you return false). With Glib::Dispatcher you just call emit on it (it is in effect a thread safe version of sigc::signal0void). Glib::signal_idle() is more convenient if you want to pass different data on each invocation, because you can do that by binding to the slot. You should only emit Glib::Dispatcher from a different thread from the main GUI thread. Glib::signal_idle() is thread safe and can be called from the main GUI thread or any other thread. Oh sh*t. If I had only known that Glib::signal_idle() was thread-safe, I might never have started working on Glib::Dispatcher :-) It does have the advantage though that it's memory allocation-free once set up. It has the advantage of being much more efficient, since emitting the signal only requires writing a few bytes to a pipe, rather than creating new slots. The main problem with Dispatcher is that if you try to emit from the main (GUI) thread, you risk a deadlock (if the pipe happens to be full the write will block and where the emitting thread is the main loop thread which also does the read, will never unblock). I have my own Dispatcher-like class which detects this condition and will invoke the connected slot directly rather than via the pipe when this occurs. It also detects if, between the dispatcher being emitted and the main loop executing the slot (an indeterminate period of time), the Dispatcher object has ceased to exist, but that is a much less significant issue. Chris ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Adding custom GDK events
On Friday 12 January 2007 15:40, Daniel Elstner wrote: Am Freitag, den 12.01.2007, 11:25 +0100 schrieb Murray Cumming: On Fri, 2007-01-12 at 03:03 +0100, Daniel Elstner wrote: Now wait... are you really sure Glib::signal_idle() is thread-safe? It's meant to be in glib, at least. Yes, most of GLib is thread-safe if used with some precautions. The problem is that we do not just pass a function pointer to it, but also an allocated data structure written to in one thread and read in another. The main problem is that sigc++ uses reference counting instead of copy semantics. BTW that's also the reason I didn't inherit from sigc::trackable in the Dispatcher code and thread examples. I see that you changed that. It might not be an issue at all but it'll need investigating how exactly the objects are used in these instances. Avoiding all the implicit behind-the-scenes stuff made sure that it isn't a problem, though. The glib main loop in glib-2.* is thread safe. g_idle_add() (and other main loop functions) are therefore thread safe in terms of the main loop itself. As I think you are saying, this does not in itself ensure memory visibility of the callback function pointer or data argument of the idle callback (or any other data passed between the threads concerned) and if visibility on multi-processor systems is required then some form of memory synchronisation (fences or barriers) will be required, typically by means of mutex locking of the data. In practice however I suspect this will be achieved since I am pretty sure (although this perhaps should be checked and I will do so next week) that when g_idle_add() is called the main loop locks and unlocks mutexes for the main loop and this will have the effect also of synchronising memory as regards the callback. Therefore, by the time the callback is executed memory will have synchronised on any POSIX system. Furthermore on Unix-like systems g_idle_add() uses a pipe and although not guaranteed by POSIX it seems inconceivable that in practice writing to a pipe in one thread and reading from it in another would not synchronise memory. If this were not the case g_idle_add() would be ineffective for one of its main intended purposes, which is message passing from other threads to the main loop thread. I do not know if glibmm gives rise to further sychronisation issues but I would be surprised if it did, in the sense that if there is a problem with sigc slots with Glib::signal_idle() then there is a problem with g_idle_add() so far as concerns its function pointer and data arguments. If this is not the case, it may be a good idea for Glib::SignalIdle to provides its own internal locking. Chris ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Adding custom GDK events
On Sunday 14 January 2007 00:38, Chris Vine wrote: [snip] As I think you are saying, this does not in itself ensure memory visibility of the callback function pointer or data argument of the idle callback (or any other data passed between the threads concerned) and if visibility on multi-processor systems is required then some form of memory synchronisation (fences or barriers) will be required, typically by means of mutex locking of the data. In practice however I suspect this will be achieved since I am pretty sure (although this perhaps should be checked and I will do so next week ... [snip] Having now looked at glib/gmain.c it seems to me that g_idle_add() is thread safe (in the wider sense that it can be used to pass messages to/execute callbacks in the main loop thread from other threads, as well as in the narrow sense that the main loop is thread safe). The same appears to apply to Glib::SignalIdle. Each GMainContext object has a mutex associated with it which is used to lock main context operations. g_idle_add_full() creates the new idle source object and then calls g_source_set_callback(), which assigns (amongst other things) the function pointer and data arguments to the data members of the relevant idle source object. At this point the memory representing the function pointer and data argument is unsynchronised. However it follows this with a call to g_source_attach() which attaches the idle source object to the relevant GMainContext object under the mutex lock for that main context (an acquire and a release). When the data members of the idle source object are read for dispatching, g_main_context_dispatch(), which calls g_main_dispatch(), does so under the same mutex lock, with an acquire and a release. Therefore, when the main loop thread reads these data members, there has been (a) a release operation by the signalling thread, and (b) an acquire operation on the same synchronisation object by the reading thread. Accordingly the memory of the reading thread will be synchronised with that of the signalling thread to a condition no earlier than the release instruction being executed, and no out of order execution of the write will be permitted beyond the point of the acquire or the point of synchronisation, assuming a platform with these minimum-level thread safety guarantees. (Actually Posix, in section 4.10, General Concepts, Memory Synchronization, gives stronger guarantees than that.) You know glibmm better than me, but it seems to me that the same would apply to that. Glib::signal_idle().connect() will create the idle source, and then call Glib::SignalIdle::connect() on it, which will invoke g_source_attach(). The only thing I notice is that Glib::SignalIdle::connect(), after the call to g_source_attach(), calls Glib::SourceConnectionNode::install(). I do not know what that does, but if it is important to dispatch of the slot in the main loop by the relevant GMainContext object you could always put LOCK_CONTEXT(context_)/UNLOCK_CONTEXT(context_) around it (or if it makes sense to put the call to Glib::SourceConnectionNode::install() before the call to g_source_attach(), put it before the call to g_source_attach()). As it happens, I recall the PyGTK FAQ recommending using gobject.idle_add() as the way to pass events to the main thread (although their FAQ page does not seem to be responding at the moment). Chris ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: glibmm thread safety [was: Re: Adding custom GDK events]
On Sunday 14 January 2007 23:37, Daniel Elstner wrote: Am Sonntag, den 14.01.2007, 00:36 + schrieb Chris Vine: [snip] It also detects if, between the dispatcher being emitted and the main loop executing the slot (an indeterminate period of time), the Dispatcher object has ceased to exist, but that is a much less significant issue. Hmm, this one is actually more interesting to me. I reckon this situation could only occur if if a receiving thread instantiated more than one Dispatcher object, right? Because otherwise the pipe() should have been closed already. The safe route seems to be to make sure that the Dispatcher objects live as least as long as the main loop runs. Alternatively, have the receiving thread wait for some token that signals the very last invocation of the Dispatcher slot. My implementation has a static pipe, and an object count is not kept for the purpose of closing the pipe when all objects have been destroyed. Once the two file descriptors for the pipe are committed, they are committed. Glib::Dispatcher also uses a static pipe I think, but even if it closes the pipe when the last Dispatcher is destroyed (does it?) then the problem could still arise. A particular program may (and usually will) have multiple Glib::Dispatcher objects sharing the static pipe and each object keeps its own slot. After signalling one of them from a worker thread it is always possible that before the slot maintained by the Dispatcher object is executed by the main loop the particular object concerned has gone out of scope. Unlikely no doubt, but clearly not impossible since there is more than one thread of execution. As well as a static pipe, my implemention also has a mutex-protected static std::set object which keeps a record comprising the address of each Dispatcher-like object in existence (the constructor inserts its address in the set and the destructor removes it). I am not sure how Glib::Dispatcher indicates which Dispatcher object's slot is to be invoked, but my implementation does it by having the emission of the notification send the address of the notifying object over the static pipe. Before the static pipe calls the relevant slot held by the notifying object via the address sent over the pipe it checks that a notifying object of that address still exists. This works provided that the notifying objects are only constructed and destroyed in the main loop thread. Unlike Glib::Dispatcher, my implementation does not have this restriction but it is documented that further synchronisation may be required IF they are constructed or destroyed in other threads and object lifetime cannot be guaranteed. I originally developed this independently of Glib::Dispatcher so it could be used in unwrapped GTK+ (although it does rely on libsigc++). Chris ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: glibmm thread safety [was: Re: Adding custom GDK events]
On Monday 15 January 2007 01:16, Daniel Elstner wrote:
Am Sonntag, den 14.01.2007, 23:49 + schrieb Chris Vine:
[snip]
You know glibmm better than me, but it seems to me that the same would
apply to that. Glib::signal_idle().connect() will create the idle
source, and then call Glib::SignalIdle::connect() on it, which will
invoke g_source_attach(). The only thing I notice is that
Glib::SignalIdle::connect(), after the call to g_source_attach(), calls
Glib::SourceConnectionNode::install(). I do not know what that does, but
if it is important to dispatch of the slot in the main loop by the
relevant GMainContext object you could always put
LOCK_CONTEXT(context_)/UNLOCK_CONTEXT(context_) around it (or if it makes
sense to put the call to Glib::SourceConnectionNode::install() before the
call to g_source_attach(), put it before the call to g_source_attach()).
inline
void SourceConnectionNode::install(GSource* source)
{
source_ = source;
}
It's trivial, and can be moved somewhere before the g_source_attach()
without harm. In fact, it should be moved, as it writes data that might
be read by another thread.
However, I can still see one possible show-stopper: sigc++. Well,
contrary to what I feared at first, explicitly copying a sigc::slot
performs a deep copy. In particular, this comment relieved me
(note that sigc::slot_rep is a subclass of sigc::trackable):
/* Don't copy the notification list.
The objects watching src don't need to be notified when the new
object dies. */
trackable::trackable(const trackable /*src*/)
: callback_list_(0)
{}
Now to the bad news. Glib::signal_idle().connect() returns a
sigc::connection object.
connection::connection(slot_base sl)
: slot_(sl)
{
//Let the connection forget about the signal handler when the handler
object dies:
slot_-add_destroy_notify_callback(this, notify);
}
connection::~connection()
{
if (slot_)
slot_-remove_destroy_notify_callback(this);
}
Doomed, I'd say. At least the call to remove_destroy_notify_callback()
after the GSource mutex has been unlocked is unavoidable with the
current API. Maybe we'll be able to play some tricks and put something
entirely different into the sigc::connection object. A special-purpose
slot which holds a connection ID or something, and goes through the
GMainLoop/GSource interface to destroy the callback slot.
Yes, I see. Perhaps it could be dealt with by adding a new method such as
SignalIdle::safe_connect() which does not return a sigc::connection object.
In this kind of case you would never usually want to use a sigc::connection
object - the callback would return false and the idle handler would
automatically be disposed of (by the main program thread, which is OK).
Better still for this usage, perhaps there could be a
SignalIdle::single_connect() method which returns nothing and which will
disconnect the callback whatever it's return value once it has been executed
(in other words, it expects a void return value from the callback).
Chris
___
gtkmm-list mailing list
gtkmm-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: glibmm thread safety
On Monday 15 January 2007 01:32, Daniel Elstner wrote: Am Montag, den 15.01.2007, 00:57 + schrieb Chris Vine: [snip] This works provided that the notifying objects are only constructed and destroyed in the main loop thread. Unlike Glib::Dispatcher, my implementation does not have this restriction but it is documented that further synchronisation may be required IF they are constructed or destroyed in other threads and object lifetime cannot be guaranteed. Well, you can have multiple main loops. I believe one of the glibmm threading examples actually does this. If I come across a need for that, I was going to templatise the notifier class with a tag type for each main context/main loop so that there would be a separate pipe for each main context. It could still be useful though to be able to create the notifier object in a different thread from the one in which the slot will execute. Chris ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: glibmm thread safety [was: Re: Adding custom GDK events]
On Monday 15 January 2007 17:27, Murray Cumming wrote: On Mon, 2007-01-15 at 18:03 +0100, Daniel Elstner wrote: [snip] I like that idea. It's useful beyond solving the threading problems as well, as you no longer need to use sigc::bind_return(), or change the code to return a boolean. I'd prefer to call it connect_oneshot() or connect_once(), though. Murray? Sounds generally fine, as long as there's clear documentation saying when you should use it, and when not to use the other one. To complete the thought, it doesn't seem worth providing something similar for Glib::SignalIO::connect(), Glib::SignalTimeout::connect() or Glib::SignalChildWatch::connect() because they do not have the specialist usage that Glib::SignalIdle does, other than to document that they must be called in the main loop thread (and perhaps suggesting that either users should use the glib API in the unlikely event of them wanting to connect up watches/timeouts in some other thread, or should hand on the connection of such other Glib::Source objects to Glib::SignalIdle::connect_once() - I am pretty certain it is safe to create and attach new GSource objects in main loop callbacks but this would also need to be checked before making the suggestion given the locking going on). Chris ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
