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
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
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
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?
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
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
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
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:
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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]
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
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
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
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
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,
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
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()
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
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
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
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
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
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
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
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
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
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
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
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,
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
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
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:
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
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
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.
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
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
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
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:
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
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
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
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
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
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
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
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
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
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()
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
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
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
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
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
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
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
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
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
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 :-
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
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
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 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,
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
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
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
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
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
1 - 100 of 396 matches
Mail list logo
