Re: Textview
Hi David,
On Fri, 25 May 2012 18:24:59 -0700 (PDT) you wrote:
Hi guys,
This might be a really dumb one...
It's certainly a very common failure to grasp a basic concept issue.
--- code tidbits ---
Loop:
memset (text, 0, 100);
sprintf (text, some very interesting data,
interesting_arguments);
textbuffer1 = gtk_text_view_get_buffer (GTK_TEXT_VIEW
(data-textview1));
gtk_text_buffer_get_end_iter (textbuffer1, end);
gtk_text_buffer_insert (textbuffer1, end, text, -1);
gtk_text_view_scroll_to_iter (GTK_TEXT_VIEW (data-textview1),
end, 0.0, FALSE, 0, 0);
End Loop
--- end of code ---
Any idea what I've done wrong?
You have not understood that EVERYTHING done by Gtk (and all such tool
kits) gets buffered for performance reasons. Your program is hogging
the CPU doing its work, part of which is to populate the text buffer,
and never letting Gtk have a chance to update the display. If you want
the display to respond, you MUST let the Gtk main loop get a slot. Try
re-writing your code into a form like:
g_idle_add ( my_worker_callback, NULL );
Gboolean my_worker_callback(gpointer data)
{
do_some_small_amount_of_stuff();
sprintf (text, some very interesting data, interesting_arguments);
textbuffer1 = gtk_text_view_get_buffer (GTK_TEXT_VIEW(data-textview1));
gtk_text_buffer_get_end_iter (textbuffer1, end);
gtk_text_buffer_insert (textbuffer1, end, text, -1);
gtk_text_view_scroll_to_iter (GTK_TEXT_VIEW (data-textview1),end, 0.0,
FALSE, 0, 0);
return more_to_do_yet;
}
(You'll need to check the syntax details, I've only thrown together a
basic shape)
In other words, don't use a loop construct - instead register the
contents of the loop as an idle task and let the Gtk main loop be your
loop.
HTH,
Rob
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list
Re: Question about GtkComboBox
On Thu, 19 Jan 2012 22:46:30 -0800 Igor wrote: Hi, ALL, I am using GtkComboBox and I need to show the dropdown list in my program. I found a function gtk_combo_box_popup() but the documentation says that it should be used for the accessibility purposes. Does this mean I can't use it? And if I can't what are the drawbacks? I don't know if this was the intent, but I've always interpreted that note as meaning you shouldn't normally ever need to programmatically show the drop-down because when the user wants to see it she will click on the arrow and GTK will take care of it. The author could think of one obvious exception, which was a user whose disability prevented use of the mouse, who might then need some accessibility tool to drive the UI in other ways. Assuming you have a good reason to deviate from the usual paradigm of comboboxes then I don't think that note was intended to ban your use of that function. It is, possibly, intended to encourage you to consider carefully whether you really want to break the paradigm. HTH Rob ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: GTK+ on Mac OS X status
On Sun, 20 Nov 2011 20:40:32 +0100 mitch wrote:
The tone of Lothar's mail borders outright FUD.
Lothar is one of those people who, for whatever reason, is incapable of
posting any comment not phrased as ${LIST_SUBJECT} is rubbish/run by
idiots/a waste of space. I expect it probably masks useful knowledge he
imparts, but frankly I got so fed up with it I rarely read what he
writes, so I wouldn't know.
Regards,
Rob
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: GTK+ library access issue?
Hi Earnie, On Tue, 25 Oct 2011 09:08:14 -0400 you wrote: However, IMNSHO, if LD can find the references in out-of-order .o object files it should be able to do the same with out-of-order library archives of object files but then I don't code LD. Well, no, for fairly obvious reasons. LD simply doesn't find the references in .o object files like it does with libraries. All .o files passed to LD are linked in full, because that's what the user is explicitly telling it to do (and traditionally a .o file only contained ONE chunk of linkable object, so it's fundamentally all-or-nothing). A library is different - it's a collection of .o chunks, and traditionally an ordered one at that. What LD does with a library is to examine each chunk in turn, look to see if it resolves any of the outstanding undefined symbols, and links it in if and only if it does. So there is never a retrospective go back and examine the libraries to see if we need any other bits operation. Items are always linked in the order they appear in the command. This also means that it actually matters quite a lot what order you construct your library in! HTH, Rob ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: gtk-list Digest, Vol 86, Issue 9
Hi Phong, On Mon, 6 Jun 2011 22:27:42 +0100 I wrote: When you call g_dir_open at the top level, you pass it a PATH to the directory, either relative to CWD or absolute. When it finds a file in there it prints only the name of the file, not its full path. So why would you expect the recursive call to work? The directories it finds in /home/me/test/files aren't present in /home/me/test so of course it won't find them. All of which was true, but there was one more thing I missed - you need to do this path combining whenever you want to refer to the actual file rather than the directory entry, and that includes the call to g_file_test. HTH Rob ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: gtk-list Digest, Vol 86, Issue 9
Hi Phong,
On Mon, 6 Jun 2011 15:52:12 -0400 you wrote:
Thank you Victor! I have written a recursive function to read all the
directories and files.
#include gtk/gtk.h
void read_all_files(const gchar* file) {
GDir *dir = g_dir_open(file, 0, NULL);
while ((file = g_dir_read_name(dir))) {
if (!g_file_test(file, G_FILE_TEST_IS_DIR)) {
g_print(%s was opened\n, file);
}
else {
read_all_files(file);
}
}
}
However, it seems that this function still only reads the 1st level of
subdirectory and print out all the files there and not reading any file at
2nd, 3rd, 4th, etc... levels.
Yes, and for a reason that should be fairly obvious if you look at the output.
When you call g_dir_open at the top level, you pass it a PATH to the directory,
either relative to CWD or absolute. When it finds a file in there it prints
only the name of the file, not its full path. So why would you expect the
recursive call to work? The directories it finds in /home/me/test/files aren't
present in /home/me/test so of course it won't find them.
If you call this with the result of a gtk file chooser, that will be an
absolute path. When you find a directory and recurse into it, you need to
combine the directory name file (that is, the local file not the argument
passed in - bad practice reusing the name like that) with the path where it
lives (which is the original file that you've overwritten - told you it was
bad practice!)
You've also failed to clean up after yourself like the manual tells you to.
The corrected version of your function would be:
void read_all_files ( const gchar* path )// Note the name change
{
const gchar * file; // Note that you need a local pointer var
GDir *dir = g_dir_open ( path, 0, NULL );
while ((file = g_dir_read_name(dir)))
{
if (!g_file_test(file, G_FILE_TEST_IS_DIR))
{
g_print(%s was opened\n, file);
}
else
{
// New code to create the full path to this subdirectory
gchar * newpath = g_build_filename ( path, file, NULL );
read_all_files(newpath);
g_free ( newpath );
}
}
// And the clean-up code you forgot
g_dir_close ( dir );
}
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Compiling a GTK application on windows
On Wed, 1 Jun 2011 17:27:47 +0200 Richard wrote: hi lothar, i guess i'm too sensitive when/where it comes to gtk+. how you can see past everything and know that i'm quite bad at what i do is pretty amazing, commendable, even. Indeed. Clearly he's an absolute genius and anyone who disagrees, whatever their history, must be uneducated. On Wed, Jun 1, 2011 at 5:16 PM, Lothar Scholz llot...@web.de wrote: Yes i'm an arrogant fuckhole - but at least i know how to program. Well, the first half of that seems demonstrably true. ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Compiling a GTK application on windows
Hi David, On Sun, 29 May 2011 19:54:17 +0200 you wrote: On Mon, May 30, 2011 at 12:22:11AM +0700, Lothar Scholz wrote: I can't understand why for example this mouse-leave error is not fixed. This is the most serious show stopper, next are the themes and third is the unix build system (at least someone is working on that) The unix build system is actually one of the best things: you can build MS Windows executables completely on the same system where you build Unix executables, i.e. on Unix – which is what most OSS projects seem to do nowadays. There really isn't any point trying to make people like Lothar see the light. Some folks are just so brainwashed into believing that an integrated development environment is the only option on Windows that they have become clinically incapable of grasping the simple fact that for anyone who knows what they're doing (and may be doing something more complex than the Visual Studio Hello world example) IDEs universally just get in the way, and make is your friend. Cheers, Rob ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Weird RadioButton behaviour
I have an application on which a group of RadioButtons select the control mode. The modes that are not in control show the current reading, while the in control has a SpinButton. To do this widget switching I have hooked up to the signal_toggled and signal_clicked of the RadioButtons and in the handler I check the get_state() value. This works fine when I click on the radio buttons with the mouse. The callback is invoked four times; twice on the old selection with the get_state returning false, then twice on the new with get_state() true. I don't know which order the clicked and toggled signals occur but it doesn't really matter. I am slightly surprised that I get two events on the old button - I haven't clicked it, after all. The problem is when I use the cursor keys to change button. Most times it works the same, but often (and it seems to usually be most times I move away from a particular button) the two signals sent by the leaving button happen with its get_state() still returning true. Presumably this is a race condition of some sort, but why is it so consistently problematic on keyboard actions and never on mouse? Is there a better way to do the whole thing? Thanks, Rob ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Weird RadioButton behaviour
Hi Tadej, On Tue, 3 May 2011 22:25:58 +0200 you wrote: Why do you connect to both GtkButton::clicked and GtkToggleButton::toggled signals? It would probably be better to only connect to toggled one. The SpinButtons time out, so clicking back on the already-active RadioButton should re-show it. It seemed from my original tests that the toggled signal was not emitted by this, but I wasn't expecting the clicked signal to be useful for the button being moved away from. For example: The Current RadioButton is selected and the user clicks on Power - This needs to hide the Current spinner and show the Power one The Power RadioButton is selected and the user clicks it again - The Power spinner needs to be shown again if it's timed out With only the toggled signal connected, I don't get the second of these, and I _do_ still have the buggy behaviour with cursor keys. This was where I started from before adding the timeouts. Rather surprisingly (at least it feels counter-intuitive to me), with only the clicked signal connected, it seems to work. I'm not totally happy with relying on a signal being sent when the event it's named for clearly hasn't happened, but if it's the best way to do it I'll cope :) Thanks for your help. Rob ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: 2 callbacks to same event
Hi Kevin, On Wed, 27 Apr 2011 13:48:25 -0400 you wrote: If you return False from both callbacks, doesn't it destroy the callback when it's done, so a second event won't be handled at all? No, I think you're confusing signals with timeouts. When you hook up to a signal, that signal is generated by an external event, and the callback returns a flag saying I've dealt with this. When you hook up to a timeout, the callback's return is a flag saying call me again at the next interval. I think. The documentation on signal callbacks mostly implies they don't return anything! Cheers, Rob ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Question about GTK+ and timers
Hi Igor, On Fri, 8 Apr 2011 18:08:30 -0700 you wrote: So, what is the best course of action? I just tested the program on the device and on x86. On x86 it produced correct results, whereas on the ARM device it didn't. So it looks like I will have to switch the endianess when running on the ARM? When talking to a remote device over a serial port, what you are receiving is fundamentally a byte stream, so the best way to handle it is to admit that in your code. Read it into an array of (unsigned) char, do any formatting / alignment checks that you can, and then extract the data into the variables you want it in. If there are raw binary values of more than one byte, extract them explicitly: MyWordVal = buf[2] + ( buf[3] * 256 ); /* data stream is little endian */ This is portable and clear to any future maintainer. The efficiency loss is negligible. Cheers, Rob ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: How many times can I call gtk_label_set_markup()?
Hi Igor, On Fri, 8 Apr 2011 13:33:29 -0700 you wrote: gtk_label_set_markup( GTK_LABEL( data1 ), m_data1-str ); g_free( m_data1-str ); Really? What is m_data1? Your earlier extract suggests you reuse it after this. By doing g_free() I'm giving anownership of the markup string to the control. Or I don't need this? No, by doing g_free you are releasing the memory allocated by m_data1-str. While this is probably OK because gtk_label_set_markup takes a copy, it is most definitely not giving ownership. The example in the Gtk docs does it because the markup string is dynamically created and immediately disposed of, because it's being escaped. In your case it's pointed to by a structure member, which strongly hints at it not being such a temporary object. In any case, it's very bad practice leaving a hanging pointer to memory you've just free'd, so common advice is to set m_data1-str to NULL immediately after the g_free call. If that looks like the wrong thing in your program, then the g_free call is wrong. Cheers, Rob ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Question about GTK+ and timers
Hi Igor, On Sat, 9 Apr 2011 00:14:45 -0700 you wrote: MyWordVal = buf[2] + ( buf[3] * 256 ); /* data stream is little endian */ This is portable and clear to any future maintainer. The efficiency loss is negligible. Is there any way to find out if the device is little- or big-endian? Well, if it's not your own device then one might hope it comes with a data sheet. Otherwise, you'll need to arrange to print out the raw hex data that arrives and reverse-engineer it. Also, I believe that the device spit out raw data in forms of characters. Raw data in what sense? I'd be surp... well, no, probably not surprised but definitely appalled if it's just dumping its internal data structure. For one thing, a serial link is not a reliable transport layer and needs to have some form of synchronisation protocol. And I failed to produce the same result as I got on x86. That may be surprising, but it may not. If you are relying on two different compiler back-ends for different processors generating the same exact layout of a struct then endian-ness isn't your only problem. But I want to know for sure. And the code for the big-endian will look like: MyWordVal = buf[3] + ( buf[2] * 256 ); right? Yes, that's right. But remember this is the _data_stream_ endian that you care about here, not the processor. Cheers, Rob ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Question about GTK+ and timers
On Fri, 8 Apr 2011, Igor Korot ikoro...@gmail.com wrote : My (hopefully last) question here in this thread is: g_io_add_watch() should take a callback (i.e. static function) or just a regular function? Are you writing in C or C++? I assume you're using the straight Gtk for C as the function g_io_add_watch belongs to that and we're on the gtk-list rather than the gtkmm one. Anyway, the function you need to pass is a callback, so it needs to be a straight C function not a C++ class member. It doesn't need to be static in the C sense. -- Rob Pearce http://www.bdt-home.demon.co.uk The contents of | All power corrupts, but we need electricity. this message are| purely my opinion. | Don't believe a | word. | ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: How many times can I call gtk_label_set_markup()?
On Fri, 8 Apr 2011, Igor Korot ikoro...@gmail.com wrote : And the first time I am using this function is in this code: data1 = gtk_label_new( NULL ); gtk_label_set_markup( GTK_LABEL( data1 ), m_data1-str ); g_free( m_data1-str ); Really? What is m_data1? Your earlier extract suggests you reuse it after this. gtk_table_attach( GTK_TABLE( table ), data1, 0, 1, 1, 2, GTK_EXPAND, GTK_EXPAND, 0, 0 ); gtk_widget_show( data1 ); -- Rob Pearce http://www.bdt-home.demon.co.uk The contents of | All power corrupts, but we need electricity. this message are| purely my opinion. | Don't believe a | word. | ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Question about GTK+ and timers
Hi Igor,
On Wed, 6 Apr 2011 22:38:43 -0700 you wrote:
Just one question: AFAIU this pair is polling the port for data and
when they become available I need to
drop them in the GUI.
It's going to be something like MT, right?
MT?
It's not a threaded approach, if that's what you mean.
Open the serial port and attach it to a g_io_channel:
fd = open ( /dev/ttyS0, O_RDWR|O_NONBLOCK );
hFile = g_io_channel_unix_new ( fd );
g_io_channel_set_encoding ( hFile, NULL, tErrPtr );
Now you can hook up a call-back:
RxEventSrc = g_io_add_watch ( hFile, G_IO_IN, HandleAsyncRx,
(gpointer)Instance );
Then in the call-back you read the incoming data and pass it to the GUI:
gboolean HandleAsyncRx ( GIOChannel *source, GIOCondition condition,
gpointer data)
{
GIOStatus stat;
gsize len;
GError * err = NULL;
unsigned char tmpbuf[32];
stat = g_io_channel_read_chars ( source,
(gchar*)tmpbuf, sizeof(tmpbuf), len, err
);
// etc
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Question about GTK+ and timers
Hi Igor, On Wed, 6 Apr 2011 12:12:56 -0700 you wrote: My task is to read the external device thru the serial port with the 1 sec interval. And then update the GUI with the new data. At least the documentation of this device says that it will write with 1 sec. I am testing on x86, then cross-compiling for ARM and run the program on ARM. Will I be better off with just continuous loop inside thread or the timer will do? If the device does an autonomous report every second, you're probably better off using a g_io_channel to capture the incoming message and update the GUI using g_io_add_watch. No need for a timeout. Cheers, Rob ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Timer start registration breaks the gtk_main()
Hi iko...@earthlink.net, On Sat, 26 Mar 2011 20:45:53 -0700 (GMT-07:00) you wrote: Yes. You are casting the _RESULT_ of a _CALL_ to ReadData into a GSourceFunc, but ReadData returns void. This produces utterly random results. Yes, I believe I made a mistake here. I was not in front of my developmental machine, so... I think the ReadData() is returning gboolean. Perhaps, but a gboolean is most definitely not the same as a GSourceFunc. So I shall reiterate: g_timer_add_seconds( 1, (GSourceFunc) frame-ReadData(), NULL ); ^^ You are casting the _RESULT_ of a _CALL_ to ReadData into a GSourceFunc, but ReadData returns bool. This produces guaranteed illegal results. The second argument of g_timeout_add_seconds is a function pointer, and requires that you pass it a simple C function reference _without_ the call syntax. Unless you're now going to say that you'd misremembered that too, and the actual code doesn't have the () after the frame-ReadData in the line I re-quoted. It would really help us to help you if you had posted your actual code rather than a misremembered vague approximation. Cheers, Rob ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Timer start registration breaks the gtk_main()
Hi iko...@earthlink.net, On Sat, 26 Mar 2011 01:54:31 -0700 (GMT-07:00) you wrote: Hi, ALL, Is it possible for the timer to cause gtk_main() to crash? It's possible for anything to become the point where your program crashes if you are sufficiently badly abusing it. Why do you pick on the timer as your suspect? How do I debug/fix it? There are many answers to this, all outside the scope of this mailing list. How do you normally approach debugging? Cheers, Rob ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Timer start registration breaks the gtk_main()
Hi iko...@earthlink.net,
On Sat, 26 Mar 2011 11:38:27 -0700 (GMT-07:00) you wrote:
Hi, Robert,
Here is what I do:
int main()
{
CFrame *frame = new CFrame();
result = frame-OpenPort();
if( !result )
return 1;
else
{
g_timer_add_seconds( 1, (GSourceFunc) frame-ReadData(), NULL );
^ ^^
gtk_widget_show( window );
frame-ReadData();
gtk_main();
}
}
in frame.h:
class CFrame
{
void ReadData();
}
Do you see any problems with that?
Yes. You are casting the _RESULT_ of a _CALL_ to ReadData into a GSourceFunc,
but ReadData returns void. This produces utterly random results.
The second argument of g_timeout_add_seconds is a function pointer, and
requires that you pass it a simple C function reference _without_ the call
syntax.
Cheers,
Rob
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Distributing extra space to children
On Sat, 18 Dec 2010 00:17:11 +0900 Tristan wrote: It does sound like an interesting feature, I wonder if there's any way to achieve this without adding features to GtkBox. It's certainly possible to kludge something like it with tables: - Allocate a sufficiently large table, say ten cells across. - Place the first child in cells 0..6 (i.e. attach with 0,7) - Place the second child in cells 7..9 (i.e. attach with 7,10) - Set the table to be homogenous Because the table cells are all equal sized, and the child widgets occupy 7 and 3 respectively, they get 70% and 30% of the space. Cheers, Rob ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Pointers and spawning processes with glib
On Fri, 10 Dec 2010 13:01:50 +1100 Lex wrote: It is pretty obvious it must be copied, even on windows where fork/exec doesn't exist. It's pretty obvious if: 1) you understand how processes work and differ from threads and... 2) you like to think about how things work under the hood For a lot of users, like Rupert, it's not at all obvious. I don't think adding a note in the documentation is too much effort, and would be of some benefit. Cheers, Rob ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: icon for gtk window.
Hi Lohitha, On Fri, 26 Nov 2010 18:01:36 +0530 you wrote: First thing is, I want to change the icon of this window... can any one help me to do this... I searched for apis but I didn't understood the solution Did you not spot the gtk_window_set_icon function? It's documented on the GtkWindow page. Cheers, Rob ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: What is a GdkScreen?
Hi Johannes, On Tue, 2 Nov 2010 20:25:12 +1000 you wrote: If I understand correctly, a GdkDisplay is basically an X server instance. A monitor is, well, a monitor. GdkScreen is supposed to be somewhere in the middle. OK, took me a while to find monitor, but... The GDK multihead documentation has this to say about the topic: GdkScreen objects are the GDK representation of a physical screen. Yet that sounds like the definition of a monitor. Almost. I think (and it's ages since I did any multi-screen stuff on X) that Xinerama confuses things by pretending to be one physical screen. The traditional X multi-screen approach was to declare each physical monitor as a separate screen identified by a suffix on the DISPLAY variable. If you took that approach, a GdkScreen would map to a physical screen, and the GdkDisplay would be the controlling X server. If you're using Xinerama, I think all monitors grouped by that make up one GdkScreen. So, if I understand right (which is by no means certain), a GdkScreen is the display area you can drag a window over, rather than having to plonk it onto another screen by other means. Then again, there's the whole issue of virtual screens and compositing window managers to make it potentially entirely different. Now with any luck somebody that knows what they're talking about will come along and correct me. Cheers, Rob ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Trying to cross compile glib-2.18.2 for ARM
Hi Enrico, On Fri, 13 Aug 2010 23:30:51 +0200 you wrote: That's silly! If the function is there and does not behave the specified way, the providing package (in this case libc) is simply broken and has to be fixed. It's that simple. No, that's not valid, and you're being a fascist. GTK endeavours to work on as wide a range of systems as possible, and therefore NEEDS to verify whether the things it uses are correctly available. If you don't do that, if you take the your system is broken, tough approach that you advocate, then you are antagonising potential users for the sake of some ludicrous expectation that there is only one true way. You might as well be Microsoft. *If* you really want some sanity test, why aren't they run in the 'make test' pass ? Because it's too late, and because most people don't do it. Checking everything in configure leads to rapid detection of problems, even if the diagnosis gets tough on cross-compile. Also, when cross-compiling, 'make test' has problems of its own! Now stop ranting and think a bit deeper. ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: GThreads and GThreadPool help for a dummy
On Sat, 24 Jul 2010 10:16:09 +0200 richard wrote: And, while I'm here, a couple of relevant guidelines to writing multi-threaded code: There's another that you've missed: - Use as few threads as possible. Basically, threads add overhead. You get benefit only up to the point where there are as many threads as you have independent CPU cores. Beyond that your performance drops off as compared to a well structured idle loop, and the readability isn't noticeably better either. If you want to sum the results of foo(x[i]) over an array of N elements, where N is large and foo() is simple, I wouldn't use threads. If this is a background task and you want GTK to remain responsive, I would launch exactly ONE thread to do the summing. If foo() is complex, I would split N into M ranges, where M is roughly the number of CPU cores you expect to have, and launch M threads. Only if N is approximately equal to M would I take the approach being discussed here. Rob ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: signal apparently missing on gtkcalendar
Hi John, On Sun, 11 Jul 2010 22:55:15 -0300 you wrote: I am reading the documentation of GtkCalendar, more precisely at the signals. There are the month-changed and day-selected signal, but why not a signal to represent the year changing? Presumably because it displays a whole month at a time, from which the user can pick a day. If the year changes then the month changes too, so I'm guessing the month-changed signal will be emitted. That would also be why the naming of those two signals is different; month-changed means the display has been updated, whereas day-selected means the user has picked one of the displayed options. Cheers, Rob ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: g_io_channel_read_to_end read just 998 chars, not more
Hi frederico, On Thu, 27 May 2010 11:02:47 -0300 you wrote: Why don't you test the error returns? GError *b = NULL; g_io_channel_read_to_end( channel, string, size, b); g_print(returned: %s\nsize: %d\nerror: %s, string, size, b-message); It causes segmentation fault. What I'm doing wrong here? You're not testing the error return. If the g_io_channel_read_to_end completes without error, then it doesn't change 'b', so the printf is doing a de-reference of a NULL pointer. You should change it to : GError *b = NULL; g_io_channel_read_to_end( channel, string, size, b); g_print(returned: %s\nsize: %d\n, string, size ); if ( b ) g_print(error: %s\n, b-message); ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: GTK progressbar call on XRenderComposite
Hi Huang,, On Thu, 20 May 2010 16:11:47 +0800 you wrote: Only the final progressbar is displayed. So it is hard for me to trace the render process of a progressbar. Can you guys have any idea? Well, normally this behaviour is a result of not letting the GTK main loop run between updates, but you probably already know that. ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: problem with compiling different C files with a global structure
On Tue, 11 May 2010 03:04:56 +0600 Debmalya Sinha sunnywiz...@gmail.com wrote: Am I missing some points here? You mean apart from: 1) This is a very VERY basic C programming issue, so this is the wrong place 2) The compiler gives you some clues when compilation fails, and you've not reported them 3) If you read those clues they might help you find the problem 4) Taking the time to think about things is usually quicker than waiting for an answer on a mailing list Now ask yourself how the compiler knows about data when compiling call.c ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Change button color in button-press-event
Hi g...@digosp.com, On Sat, 24 Apr 2010 09:49:37 -0400 you wrote: When a button is pressed, I want to change its color to blue, and when it is released to restore its original color. When you say pressed, you mean active? I think you need to look up the documentation on styles and themes. The code I use is shown below. I do get BUTTON PRESS and BUTTON RELEASE messages, but the button color does not change. snip gtk_widget_modify_bg(widget, GTK_STATE_PRELIGHT, color); gtk_widget_modify_bg(widget, GTK_STATE_NORMAL, color); So if you want to affect the appearance of the button while pressed, which is called ACTIVE, then why are you setting its colour in the NORMAL and PRELIGHT states? If I understand your intentions right, I don't think you need signal handlers or call-backs. Just set the widget's ACTIVE background colour and GTK will do the rest. Rob ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Change button color in button-press-event
Hi g...@digosp.com,
On Sat, 24 Apr 2010 14:02:26 -0400 you wrote:
This is for an embedded device with touch screen, no mouse.
If I send activate signal from my code to a button, it turns blue and
then back to its initial color, as expected.
When I press the button with my finger, I do get click event, but
button color never changes.
I noticed that most of the time PRESS is received only when I remove
my finger from the button.
That sounds like the touch screen may not be providing the right
signals. If it's trying to distinguish between cursor movement and
clicking, it may be using the removal of the finger to signal both
press and release. If that is so, the finger on button condition
probably results in PRELIGHT rather than ACTIVE, but note that you will
not see the signal you're hooking up to set the colour. You could try
adding
bg[PRELIGHT] = {0, 0, 1.0}
to your ButtonStyle, but the problem with that is the cursor probably
remains over the button after you've pressed it.
Rob
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: GTK setuid problem
Hi robin, On Tue, 20 Apr 2010 09:51:42 +0530 you wrote: My question is there any other work around for this problem? My need is the user should not be asked for root password each time (log off and log in) for the GTK application. The problem is that GTK is a huge library of complex stuff that is added to all the time, and as such is quite a likely place for security vulnerabilities to appear. The developers therefore (quite rightly) decided it shouldn't be run setuid. The intended way to work is to gather the bits that really need to be setuid into a small (and therefore probably quite secure) helper program that your big GUI can talk to (probably through pipes, maybe through sockets). What I don't understand is why you think making use of socket requires your application to be run as root. Rob ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: GTK setuid problem
On Tue, 20 Apr 2010 08:42:52 -0400 Paul Davis wrote: On Tue, Apr 20, 2010 at 3:22 AM, robin robi...@iwavesystems.com wrote: s = socket(AF_PACKET, SOCK_RAW, htons(ETH_P_ALL)); regular users can't do this on most (all?) linux systems. this is a highly priviledged operation, and its not a suprise that a regular user can't do this. Just to be clear, since Robin didn't say anything about why he's doing exactly that: Opening a socket _AT THIS LOW A LEVEL_ is a highly privileged operation. Unless the application is a net sniffer or similarly evil hacker tool, you won't need it. So to my mind, without knowing what Robin's application is, it seems likely that the correct fix is either: 1) Only allow root to use it. After all, it's a dangerous tool or 2) Fix the socket instantiation so that it doesn't need such privileges. Cheers, Rob ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Trying to cross compile glib-2.18.2 for ARM
Hi Chuck, On Mon, 19 Apr 2010 09:54:16 -0600 you wrote: checking for posix getpwuid_r... (cached) yes checking for posix getgrgid_r... configure: error: in `/opt/Freescale1/ltib/rpm/BUILD/glib-2.18.2': configure: error: cannot run test program while cross compiling See `config.log' for more details. error: Bad exit status from /opt/Freescale1/ltib/tmp/rpm-tmp.29960 (% build) snip What, exactly, are the 'test programs' that the glib make tries to run? There must have been a way to disable this in the older version of glib (glib-2.12.11) packaged with the Freescale ltib build, since that build does not have this issue. Was this an added feature of newer glib releases? It's not glib make, it's the configure script. In order to confirm whether glib can use a POSIX compliant getgrgid_r the configure script has to build and run a test program to check for compliance. For most things it's enough to compile the test, but for some compliance checks the program must actually be run on the target system. That's rather hard for configure to do when cross-compiling. It may be possible to explicitly tell configure whether the test would pass (or rather, to explicitly tell it whether to use the function) but it may not. The fact that older versions didn't suffer this problem could be down to older versions not needing that function, or it may be the availability was incorrectly assumed rather than tested. And that's about as much as I know on the topic! Rob ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Can't unmount flash drive after GtkFileChooserDialog in Windows
Hi Ian, On Tue, 23 Mar 2010 18:08:05 -0700 you wrote: So only stdin/out/err are open and the cwd is not on the flash drive. What the heck else could be preventing Windows from un-mounting it? Sadly it's probably some deep buried magic in Windows. The earlier post about working directories was on the right lines, I suspect, except it's not the application working directory that's the problem but some internal cache record. I've seen this happen with Windows Exploder - after browsing the flash drive it's sometimes not enough to browse away and you need to close that explorer window to allow the safe removal. You could try (though it's unlikely to help) explicitly setting the file chooser's current directory to C:\ before you delete it. ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Pango context in size request
Hi group, This is probably a dumb-ass question that I ought to know the answer to, but... I'm building a custom widget which includes some text that needs to be fitted round. To do it right I need to obtain the size of these by calling Pango functions with a context obtained for the widget. Is it guaranteed OK to do this in the .._size_request function? I kind of figure it must be because lots of widgets (labels, for example) must surely do so, but I can't find any definite confirmation in the docs. Cheers, Rob ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Remarks on gtk docs
Hi David, On Mon, 1 Mar 2010 10:04:27 +0100 you wrote: I've yet to see a Python programmer using Tkinter. Oooh! Ooooh! Sir! Sir! http://lintrain.sourceforge.net http://www.livewires.org.uk/python And I could name others. TkInter is not dead. However, that shouldn't detract from the important Gtk points that are being discussed. If there are any ;) :P ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: How to use GIOChannel to write binary data
Hi silverburgh, On Sat, 6 Feb 2010 21:00:29 -0800 you wrote: In the gio channel, http://library.gnome.org/devel/glib/stable/glib-IO-Channels.html#g-io-channel-write, there are these api to write characters g_io_channel_write_chars g_io_channel_write_unichar But why there is no api to write binary data? Because you don't need one. Binary data is merely a stream of 8-bit chars with no encoding. How can i use GIO channel to write non-character data? Look at the documentation for g_io_channel_write_chars and you will find an admittedly cryptic reference to g_io_channel_set_encoding. The documentation for that states: The encoding NULL is safe to use with binary data. I think this answers your question. Rob ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: How to use GIOChannel to read an Unix socket
Hi silverburgh, On Tue, 26 Jan 2010 23:59:11 -0800 you wrote: I have updated my gio_read_socket per your advice. No you haven't. Chris explicitly said you need to free the GIOChannel objectand that using g_io_channel_shutdown of itself is not sufficient. I quote: Actually, you have attempted to fix your problem in a different way, by closing the socket when the read data length is 0, assuming that you are doing blocking reads. However, you need to free the GIOChannel object. The easiest way to do that is to call g_io_channel_unref() on the GIOChannel object immediately after you have called g_io_add_watch() on it. g_io_channel_*_new() returns a GIOChannel object with a reference count of one. g_io_add_watch() adds a further reference count - if you decrement it by 1, the callback will be disconnected and the relevant GSource object removed when the callback returns FALSE, which it should do when it detects end-of-file, or if you call g_source_remove() on the return value of g_io_add_watch(). (Incidentally, you are also supposed to use g_io_channel_shutdown() rather than g_io_channel_close(), but that of itself is not sufficient to free the GIOCondition object and it is not necessary anyway in this usage.) I agree that the documentation on this isn't very good. So you need to change how you create the channel object (which you haven't posted so I have to assume you didn't change it) _AND_ you need to ensure that the callback returns FALSE when it detects end of file. Try doing what Chris said and see if that helps. Rob ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: g_assert vs. g_return_if_fail
Hi Jiří, On Wed, 20 Jan 2010 23:04:34 +0100 you wrote: No problem. I'm just wondering why there are two methods that do the same thing just slightly differently, They're not the same thing - one of them gives up on a particular function, the other aborts the application. while one of them shouldn't be used. I don't believe anyone said that. Somebody did say that g_assert should not be used where g_return_if_fail is used, because they do different things. So I guess my question is: What are the use cases for g_return_if_fail and what are the use cases for g_assert? (GLib newbie here) You should use g_assert in code under development to make explicit the assumptions of that code. So if your function does not handle the case of SomeVariable being negative, because you cannot envisage a case where it could ever be negative, then it is appropriate to add g_assert ( SomeVariable = 0 ) at that point. If your assumption turns out to be wrong then it will become obvious during development. You should use g_return_if_fail to cope with bad arguments to functions when you don't have control of the caller. This is the case in library functions, of course, which is why Gtk widget implementations use it a lot. For example, in the gtk_label_set_text implementation there's several g_return_if_fail tests of the first argument being a pointer to a GtkLabel, and the second being some text. If the programmer using the library gets this wrong it's not up to the library to crash his program for him; that would be damned annoying at the very least. But if the check wasn't there and the programmer got it wrong then the library probably would crash with a mystery segfault. So writers of libraries should use g_return_if_fail liberally, because it protects the user of the library and provides more helpful responses to mistakes. ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Theme / style problem - shadow on insensitive label
Hi all, I am building an application which includes, among other things, a bunch of radio buttons. One or more of these may, on occasion, be marked insensitive because the option is not available. OK so far. My customer wants a visual style with white text on a dark blue background. Disabled (i.e. insensitive) text should be mid-grey. Knowing how much people on here scream and yell about imposing such things, I am implementing that by providing a resource file that defines a theme. The problem I have is that when I mark a radio button (or any label) insensitive, the text acquires a shadow, and this shadow is WHITE! This makes it stand out even more than the active buttons, thus totally going against intent. I've tried googling, and all I got was a thread on this list seven years ago in which somebody asked how to remove this shadow and was told in no uncertain terms that he shouldn't be imposing style decisions in the code. Well, I'm trying to use a theme, so please can somebody answer the question for me? Cheers, Rob ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Not getting which mouse button is pressed on button-press-event
Hi Ed, On Wed, 13 Jan 2010 15:11:21 -0500 you wrote: Wasn't able to emulate middle button on my 2-button mouse (project for another day, perhaps). That's an X setting - EmulateMiddleButton or something of the like. If it's set then X intercepts near-simultaneous left and right buttons and substitutes a middle button. Can't verify 6,7, but perhaps it's time for me to buy a better mouse. I wonder, though, if this might be useful with a joystick (left, right). Buttons 6 and 7 are generated by some track balls and mice with excessive numbers of controls. You get some flexibility on what you map them to, and it's possible to use them for scrolling instead of 4 and 5. But as I understand it, none of this is relevant to GTK, which just passes through what the back-end produces. Rob ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: simple compass widget available
Hi Leon, On Sat, 9 Jan 2010 17:57:54 +1100 you wrote: Dear All, I wanted a compass widget (a compass rose with a single pointer/needle). I could not find one probably due to my incompetence! I have modified the dial_test and dial widget example to create one. If this is useful to others then where/how should I publish it? You can publish it on any web site you have control of, and tell us about it here. However, that's not the most effective. Better would be to find somebody with an existing library of GTK add-on widgets who would be happy to include yours, but that may prove hard. If you wanted to start one, I have an improved dial / meter widget to contribute ;) Rob ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: simple compass widget available
On Sat, 09 Jan 2010 12:11:54 -0500 Pierre-Luc wrote: You can also try to push it for inclusion in Gtk+ itself since most 3rd party Gtk+ widget libraries have been killed or merged. Is that true? The GTK widget list is still fairly basic, and none of the extended widget sets I've used are incorporated. Certainly, to my knowledge, gtk+-extra is still separate (and is not dead, in fact it's just acquired an extra maintainer) and gtkdatabox is under continuing development as a separate entity. There are widgets in the Gnome project (used by e.g. ghex) that are not in GTK itself despite sharing hosting and many developers. I'm not saying it's a bad idea - incorporating extra facilities into the core library would make it more appealing to users - but it doesn't appear to be common practice and I get the impression the GTK maintainers don't really want the hassle of taking on lots of other people's babies. Rob ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: glib install problem
Hi Juei-Hwa, On Thu, 15 Oct 2009 00:27:31 +0800 you wrote: Hi, I try to install glib-2.22.2, but I got some error messages. I follow the INSTALL file to install. I paste some messages below. Please help me to fix the problem. Thanks. % ./configure % make % sudo make install make[6]: Entering directory `/nfs/jhhu/software/glib-2.22.2/glib' sed -e s|\...@datadir\@|/usr/local/share| ./libglib-gdb.py.in libglib-gdb.py /bin/sh: libglib-gdb.py: Permission denied make[6]: *** [libglib-gdb.py] Error 1 make[6]: Leaving directory `/nfs/jhhu/software/glib-2.22.2/glib' That last line gives a path that looks like it's on an NFS mount. If so, the mount is almost certainly configured with root-squash, meaning that when you run something sudo you actually _LOSE_ all your rights to that directory. Try building and installing GTK from a local partition, not an NFS mount. Hope that helps. Cheers, Rob ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Deadlock problem when calling messagebox function with idle_add
On Tue, 18 Aug 2009 17:18:25 +0100 Andreas wrote: Okay I found a workaround: Please try not to top-post. Replies to posts, even your own, should quote the relevant bits only and THEN respond to them. I've shuffled things below: Andreas Sommer wrote: I have a function /putMessageBox/ which shows a message box dialog like this (it's Python but I think it's not specific to that language): ... dialog.run() dialog.hide() ... That function is fine if you want to execute the dialog as a modal dialog, i.e. the other windows block until it's been acknowledged. If you want the dialog non-modal (i.e. works in parallel with other windows) you should use a different approach. Calling the function normally from somewhere in the main thread works, but when I execute it with def helper(): putMessageBox(...) gobject.idle_add(helper) it deadlocks as soon as I press the OK button on the dialog. You appear to be showing the dialog whenever the GTK loop is idle. This seems a very unlikely requirement for a modal dialog. The dialog does not disappear, the buttons stays pressed and the complete application is stuck. Same with timeout_add, of course. That may not be a strictly accurate assessment. What happens, I suspect, is that the dialog is shown and handled, but when the user clicks OK and closes it, the main loop drops back to the idle state and immediately re-runs the dialog. Later you wrote: Okay I found a workaround: def helper(): *gtk.gdk.threads_enter()* putMessageBox(...) *gtk.gdk.threads_leave()* gobject.idle_add(helper) But why do I have to do that? Note that I call the above from the main thread, no multithreading involved. Please can somebody explain why this is necessary? There is some threading involved, of sorts. The dialog.run call creates a new GTK mainloop purely for that dialog. It's possible that the threads_enter is preventing the dialog's main loop from running the idle tasks that would otherwise re-run the dialog when you don't want it. I think we will need to see much more of the structure of your application to be able to help further. HTH Rob ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: csv (comma separated value) file
On Mon, 3 Aug 2009, Paolo Bacchilega paolo.bacchil...@libero.it wrote : it's not so easy, for example the following csv file: a;b;c has only two columns, you cannot handle this case with a simple g_strsplit call And for extra fun, I've recently had to handle a CSV format where the first line was: CSV version 2,.,*,, when generated in the UK and: CSV version 2;,;*;; when generated by our Italian customer. And yes, that does mean that the Italian version used ; as the separator and , for the decimal place, rather than , for the separator and . for the decimal. It also means that both versions use for quoting, and a line beginning with * is a comment. The tool reading this file is expected to deduce the correct format from that first line. -- Rob Pearce http://www.bdt-home.demon.co.uk The contents of this | Windows NT crashed. message are purely | I am the Blue Screen of Death. my opinion. Don't| No one hears your screams. believe a word. | ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Why there's still ONE element left after g_slist_free () ?
On Thu, 14 May 2009 20:27:18 + american.communist.pa...@gmail.com wrote: You should quote the object of the comment ENTIRELY before commenting, shouldn't you? Nobody misquoted you, nor did they strip any of your comment out. And nobody was objecting to your comment as a result of lack of context. The actual comment by PenT does state as much: to assign NULL to it after g_slist_free ()... Yes, that's true, PenT did state the right thing. AFTER g_slist_free. I don't see that I was mutually exclusive in my reply. Well how about this: On May 14, 2009 11:51am, Chris Moller mol...@mollerware.com wrote: american.communist.pa...@gmail.com wrote: Its old hat to C programmers that you set any object to NULL when you're done with it, which returns the memory used to the heap. Now note that the when you're done with it is merely a contextual clause and can therefore be eliminated from the sentence without significantly changing its meaning (simple English grammar 101). Therefore what you wrote was a statement that setting any object to NULL returns the memory to the heap. This is explicitly wrong. Your sentence should have read: It's old hat to C programmers that you set any pointer to NULL when you're done with it and have returned the memory used by the object it referenced to the heap. Though even that isn't strictly correct since the pointer may not reference a heap object, so you should have written: It's old hat to C programmers that you set any pointer to NULL when you're done with it; especially if you have deleted the object it referenced and returned the memory used to the heap. Sorry for the English lesson, but there are enough people reading this who don't _know_ what you must have meant that it really _does_ matter when you actually _say_ something quite different. HTH Rob ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Wrong Exif Id in io-jpeg.c?
On Mon, 16 Mar 2009, Paul Stuart paul_stu...@seektech.com wrote : But, in io-jpeg, they've defined: #define EXIF_IDENT_STRING Exif\000\000 which in hex would be 0x457869660030 by my count. I'm not quite sure how you reckon that. Escaped numbers in C strings are evaluated as octal, so seeing three digits is quite normal. The compiler will regard \000 as a single zero byte. -- Rob Pearce http://www.bdt-home.demon.co.uk The contents of this | Windows NT crashed. message are purely | I am the Blue Screen of Death. my opinion. Don't| No one hears your screams. believe a word. | ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Memory problem
On Thu, 5 Mar 2009, maeda ma...@claire.co.jp wrote :
I have a function which is eating up lots of memory. The function is
listed below
snip
int SetWidgetColour(GtkWidget *widget, int bordersize, int red,
int green, int blue)
{
GtkStyle *new_style;
snip
new_style = gtk_style_copy(gtk_widget_get_default_style());
snip
gtk_style_detach (widget-style);
gtk_widget_set_style(GTK_WIDGET(widget), new_style);
return TRUE;
}
The function creates a new style on the heap every time it's called.
That style is then allocated to the widget, so it must be persistent.
This will cause a lot of memory to be used... unless you can absolutely
guarantee that the gtk_style_detach call results in the old style
being free'd. The documentation only says it may result in it being
unrealised.
--
Rob Pearce http://www.bdt-home.demon.co.uk
The contents of this | Windows NT crashed.
message are purely | I am the Blue Screen of Death.
my opinion. Don't| No one hears your screams.
believe a word. |
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Alt+Button click and events
On Wed, 9 Jul 2008, Toralf Lund [EMAIL PROTECTED] wrote : I probably need to reconsider the way the application using modifiers, though (but I can blame the current setup on someone else), since it's probably quite common that the window manager wants to use Alt. It's also quite common for applications to want to use ALT-click - I have had to disable the (not particularly useful) ALT-click behaviour of KDE because it's far more useful to have it available to the Eagle PCB CAD tool, for example. So you're not alone in having this problem. -- Rob Pearce http://www.bdt-home.demon.co.uk The contents of this | Windows NT crashed. message are purely | I am the Blue Screen of Death. my opinion. Don't| No one hears your screams. believe a word. | ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Does gtk have issues with STL?
On Mon, 11 Feb 2008, Paul Davis [EMAIL PROTECTED] wrote : the use of threads in GUI toolkits that originated in the X Window world is generally quite difference than the use of it with GUI toolkits that originated in the win32 world. Actually I never noticed the difference, because my exposure to Win32 was through Borland's VCL library, which is non-thread-safe in similar ways to GTK. The all GUI calls in one thread rule applied there too. But being more accustomed to embedded code for systems with no OS and only a minimal scheduler, I don't tend to use threads anyway. -- Rob Pearce http://www.bdt-home.demon.co.uk The contents of this | Windows NT crashed. message are purely | I am the Blue Screen of Death. my opinion. Don't| No one hears your screams. believe a word. | ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: gimp-vs: gdk headers missing extern C
On Fri, 7 Dec 2007, [EMAIL PROTECTED] wrote :
They go away if I wrap the include directive in my program:
extern C{
#include gtk/gtk.h
}
But I think this wrap is supposed to be in the headers - the
other packages (ATK_, GTK_, PANGO_ etc.) work OK, using C linkage.
Yes, this wrapping is normally done in the headers, but because they are
fundamentally C headers and the wrapping is only valid in C++ it has
to be contained in a #ifdef. Though looking at the GTK headers, I think
this in turn is wrapped in magic (G_BEGIN_DECLS?)
Is it possible VC9 is not declaring the necessary symbol?
--
Rob Pearce http://www.bdt-home.demon.co.uk
The contents of this | Windows NT crashed.
message are purely | I am the Blue Screen of Death.
my opinion. Don't| No one hears your screams.
believe a word. |
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: GtkScrolledWindow in full screen
On Tue, 9 Oct 2007, Jonh Wendell [EMAIL PROTECTED] wrote : The widget size is exactly the screen size, say, 1280x800. When i put my window full screen, i still see the scrollbars, but they are not necessary, because the widget is the only widget visible on screen, and its size is the same as the screen size. Is that really true? I think not. If I have a GTK window containing only one widget of size 1280x800, the window is still 1284x804 because the window manager has added a border-frame around it. So when maximized on a 1280x800 screen the widget is only allocated 1276x796 and the scrollbars are required. -- Rob Pearce http://www.bdt-home.demon.co.uk The contents of this | Windows NT crashed. message are purely | I am the Blue Screen of Death. my opinion. Don't| No one hears your screams. believe a word. | ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: implementing a delayed busy cursor
Hi Paul, On Sun, 05 Aug 2007 14:02:22 -0400 you wrote: thanks -- i'll do some reading. at the moment, i'm not sure how this will work. if i set a gtk timeout for 1 second, but my program's think time is 10 seconds, then i won't get back to the event loop until after that, and i've therefore blown my intended timeout. If your program is doing something that will take it 10 seconds, you need to adjust your architecture to shift that operation out of the loop. Either: - Split the big think into lots of little chunks - Let the GTK main loop get a shot in between them or: - Move the complex thinky bit into another thread - Send a completion notification when it's done. For the first method you should use g_idle_add to put the iteration of chunks into free time. This leaves GTK running properly and doing your hard stuff when there's nothing else to update. For the second, the rule of thumb is that only the main thread should ever do a GTK call. Passing status from the worker thread can be done in several ways, but it's not a GTK issue. ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: How can i write multiple windows(MDI)
On Thu, 05 Jul 2007 09:30:12 -0600 Michael L Torrie [EMAIL PROTECTED] wrote: For some examples of the sort of product I'm thinking of, look at ATI Vision from Accurate Technologies, or INCA from ETAS, or LabView from National Instruments (though the last is less obvious). I maintain they could have done the interface without MDI child windows, perhaps using a tabbed document area, and we'd all be so much better off. And I maintain, having used an equivalent tool that took that approach, that their user-base would scream bloody blue murder if they ever did. We would NOT be better off. I'm not saying that MDI is the best for all situations. I'm not even saying it's good for Visual Studio (though in many ways I do find it better than tabs even there). What I am saying is that there ARE cases where something very like MDI is the best solution, and the dogmatic MDI is EVIL line taken by some people here is less than helpful. ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: How can i write multiple windows(MDI)
On Mon, 2 Jul 2007, Emmanuele Bassi [EMAIL PROTECTED] wrote : MDI is a broken concept that has been abandoned by every relevant platform because it doesn't work. Once again the anti-MDI FUD is spread. It may be true that MDI has some problems with specific (unusual) configurations, but those who dismiss it with such religious fervour are simply ignoring the real truth, that there are _some_ cases where MDI is exactly what you want... it's just that those cases are not the ones certain vendors used it for. Anyway, http://curlyankles.sourceforge.net was the link I didn't look up before. -- Rob Pearce http://www.bdt-home.demon.co.uk The contents of this | Windows NT crashed. message are purely | I am the Blue Screen of Death. my opinion. Don't| No one hears your screams. believe a word. | ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: How can i write multiple windows(MDI)
Hi Emmanuele, On Tue, 03 Jul 2007 10:24:00 +0100 you wrote: is exactly what you want... it's just that those cases are not the ones certain vendors used it for. and those cases are? Cases where the child windows are not separate documents, but separate parts of a single entity. Yes, you can do something like this with multiple separate top-level windows, but then you have to rely on the window manager to recreate the user's chosen layout, which isn't so certain, and in any case it places the wrong emphasis on the GUI. For some examples of the sort of product I'm thinking of, look at ATI Vision from Accurate Technologies, or INCA from ETAS, or LabView from National Instruments (though the last is less obvious). accusing one of FUD without caring to elaborate why is exactly a FUD technique in itself Which is presumably why it's exactly what you've just done? Anyway, I'll elaborate. You posted : MDI is a broken concept that has been abandoned by every relevant platform because it doesn't work. without any elaboration. This is a vastly sweeping statement that is (a) not true, (b) not justified and (c) not supported by any evidence. That's FUD. Simply pointing that out, however, is not FUD, however much you may wish to accuse me of it. ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: How can i write multiple windows(MDI)
On Thu, 28 Jun 2007, LinusLee [EMAIL PROTECTED] wrote : I want to implement an application which has multiple windows... The MDI look, where a main window has several child windows, is frowned upon by many here. There is no official GTK support for it because most of the development team consider it evil. You might want to check out curly ankles, but I can't be bothered to find the URL. It's in the archives, quite recently. -- Rob Pearce http://www.bdt-home.demon.co.uk The contents of this | Windows NT crashed. message are purely | I am the Blue Screen of Death. my opinion. Don't| No one hears your screams. believe a word. | ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Trouble Installing
Hi Scott, On Wed, 13 Jun 2007 19:20:36 -0400 you wrote: Here's more context: gcc -DHAVE_CONFIG_H -I. -I. -I.. -DG_LOG_DOMAIN=\Gdk\ -DGDK_COMPILATION -I.. -I../gdk -I../gdk-pixbuf -DGDK_PIXBUF_DISABLE_DEPRECATED -DG_DISABLE_CAST_CHECKS -D_REENTRANT -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include /pango-1.0 -I/usr/include/cairo -I/usr/include/freetype2 -I/usr/include/libpng12 -DG_DISABLE_DEPRECATED -g -O2 -Wall -MT gdkkeynames.lo -MD -MP -MF .deps/gdkkey names.Tpo -c gdkkeynames.c -DPIC -o .libs/gdkkeynames.o /bin/sh ../libtool --mode=link gcc -DG_DISABLE_DEPRECATED -g -O2 -Wall -o lib gdk-win32-2.0.la -Wl,win32/rc/gdk-win32-res.o -export-symbols ./gdk.def -versio n-info 1000:9:1000 -export-dynamic -rpath /usr/lib -no-undefined -export-symbols ^^ -regex ^[^_].* gdk.lo gdkcairo.lo gdkcolor.lo gdkcursor.lo gdkdisplay.lo gdk dnd.lo gdkdraw.lo gdkevents.lo gdkfont.lo gdkgc.lo gdkglobals.lo gdkkeys.lo gdkk eyuni.lo gdkimage.lo gdkdisplaymanager.lo gdkpango.lo gdkpixbuf-drawable.lo gdkp ixbuf-render.lo gdkpixmap.lo gdkpolyreg-generic.lo gdkrgb.lo gdkrectangle.lo gdk region-generic.lo gdkscreen.lo gdkselection.lo gdkvisual.lo gdkwindow.lo gdkenum types.lo gdkkeynames.lo win32/libgdk-win32.la -lgdi32 -user32 -limm32 -lshell32 -lole32 -Wl,-luuid -L/usr/X11R6/lib -lpangowin32-1.0 -lpangocairo-1.0 -lcairo -l Xrender -lSM -lICE -lX11 -lpangoft2-1.0 -lpango-1.0 -lm -lgobject-2.0 -lgmodule- 2.0 -lglib-2.0 -lintl -liconv -lfreetype -lfontconfig -lexpat -lpng12 -lz -lm .. /gdk-pixbuf/libgdk_pixbuf-2.0.la -lintl libtool: link: more than one -exported-symbols argument is not allowed Well, it's not wrong. The question is why the makefile has ended up giving that option twice. ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Trouble Installing
On Wed, 6 Jun 2007 18:48:02 -0400 Scott Peterson [EMAIL PROTECTED] wrote: I'm building gtk+-2.10.9 on Cygwin and I've hit a bit of a snag. Here's the error: There's some potentially important information missing here - we've only got the tail end of whatever (libtool) command is failing. -lglib-2.0 -lintl -liconv -lfreetype -lfontconfig -lexpat -lpng12 -lz -lm ../gdk-pixbuf/libgdk_pixbuf-2.0.la -lintl The presence of two requests to link with the intl library looks suspicious (though not necessarily the cause of the error). libtool: link: more than one -exported-symbols argument is not allowed We need to see the full argument list, which means the full command rather than the truncated tail end. Given that -lintl appears twice in the snippet you have posted, I wonder what else appears twice in the bit you cut. ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Installing gtk+2.10.12 issues.
Hi Sergei, On Thu, 31 May 2007 15:22:08 -0700 (PDT) you wrote: FOSS is also about freedom of speech. WTF? How is that supposed to be relevant? To shut me up develop a better/easier for end user way of building. No, the best way is for you to stop being such a spammer and restrict yourself to answering the point asked rather than plugging your product at every possible opportunity. You're behaving like one of those wannabee author celebrities who turn up on chat shows ostensibly to be interesting and spend all the time plugging their new book. The simple fact is, if every single post you contribute says why not use AppsFromScratch? Look what it can do! then I would consider anyone choosing to blacklist you as perfectly justified. Is that how a person wishing to contribute to the community wants to come across? If your product is good, we'll all start using it on the recommendation of others. If it's so bad that you need to push it with all the arrogance and persistence of Microsoft then I'm not even going to take a look. ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Data available for reading in a GIOChannel
On Tue, 29 May 2007, Jonathan Winterflood [EMAIL PROTECTED] wrote : A question arises, though: is it possible that the channel will recieve the last of the data between the time g_io_channel_read_chars returns G_IO_STATUS_AGAIN and the callbac k exits, and that the callback will not be called again? I don't think so, but given that somebody posted from experience that the callback is reentrant (which I didn't think was possible) perhaps I'm wrong. On the other hand, I've written code that assumes both non-reentrant and that any extra data arriving during the callback will result in it being called again, and I've never hit a problem. My understanding was that the Glib idle task checks the IO channel status and calls the callback if it's ready. Since Glib is non-threaded, this cannot happen during a previous execution of the callback. And since it uses the channel's state rather than any edge events, no data will be lost or ignored simply because the callback was running at the time it arrived. Indeed this must be true if Glib is non-threaded, because the data may arrive at any time and some huge Gtk re-draw may be in progress when it happens. But that's only my understanding as a user so I'd advise you all to ask one of the authors. -- Rob Pearce http://www.bdt-home.demon.co.uk The contents of this | Windows NT crashed. message are purely | I am the Blue Screen of Death. my opinion. Don't| No one hears your screams. believe a word. | ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Data available for reading in a GIOChannel
On Sun, 27 May 2007 16:57:03 +0200 Jonathan wrote: Hi, I need to read a large amount of data from a GIOChannel (200K, over the internet). So far, I use the gnet library to create the socket, and then I use the GIOChannel to integrate the read/writing into the program's loop (a GTK application) I use g_io_add_watch(_channel, G_IO_IN, (_imageDataReadyForReading), this); to register the callback for data reading. How can I determine the number of bytes available for reading, so as not to block on reading the data? On the applications where I've used g_io_add_watch it's on a serial port that I've opened non-blocking. Then my callback I just does: stat = g_io_channel_read_chars ( source, tmpbuf, sizeof(tmpbuf), len, err ); If there are less than tmpbuf characters waiting, it fills what it can and sets len to the actual number. Then I process len bytes. Normally my tmpbuf is bigger than the longest message I expect, but it seems to work even if it isn't. ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Hello and win32 g_io_channel help needed
On Fri, 4 May 2007 10:40:30 +1000
Burke.Daniel [EMAIL PROTECTED] wrote:
I can easily achieve this under Linux with a little
re-organisation to separate out the platform specific
portions.
Does anyone have a fairly straightforward approach to
do the same under windows? If I cannot add a watch to
the serial port I am afraid I may have to either fake
it with a poll?
Short answer - no.
Longer answer - the Windows serial port handling is ugly and painful,
and really seriously not designed for this. It assumes you'll be using
a separate thread for everything. But there is just about provision for
it. Polling is even worse, because Windows doesn't support anything
equivalent to the Unix select call.
Here are some extracts from the code I've used on Windows (using
Borland C++ Builder) with some sucess:
CommsLink::CommsLink ( const char * port, int baud ) {
DCB ioDCB;
hFile = CreateFile ( port, GENERIC_READ | GENERIC_WRITE, 0,
NULL, OPEN_EXISTING, FILE_FLAG_OVERLAPPED,
NULL );
sReadOverlap.hEvent = 0;
sReadOverlap.Offset = 0;
sReadOverlap.OffsetHigh = 0;
sWriteOverlap.hEvent = 0;
sWriteOverlap.Offset = 0;
sWriteOverlap.OffsetHigh = 0;
if ( GetCommState ( hFile, ioDCB ) )
{
// Set up appropriate attributes
ioDCB.BaudRate = baud;
ioDCB.ByteSize = 8;
ioDCB.Parity = NOPARITY;
ioDCB.StopBits = ONESTOPBIT;
ioDCB.fParity = false;
ioDCB.fBinary = true;
SetCommState ( hFile, ioDCB );
}
else
{
CloseHandle ( hFile );
hFile = INVALID_HANDLE_VALUE;
return;
}
}
VOID CALLBACK HandleAsyncRx ( DWORD error, DWORD NumBytes,
LPOVERLAPPED lpOverlapped ) {
CommsLink * cml = (CommsLink*)lpOverlapped-hEvent;
lpOverlapped-hEvent = 0;
cml-HandleRXEvent ( error, NumBytes );
}
bool CommsLink::SetRXHandler ( CommsCallback * cb )
{
RxCallBack = cb;
sReadOverlap.hEvent = (void*)this;
ReadFileEx ( hFile, AsyncReadBuffer, 8, sReadOverlap,
HandleAsyncRx );
return true;// Should check something
}
The problem is, Windows doesn't have the nice clean Gtk main loop to
poll for that event. So while the above has avoided needing a separate
thread, it doesn't work unless you have a timer tick regularly putting
your code into a suitable interruptible sleep state :
void __fastcall TAppWindow::Timer1Timer(TObject *Sender)
{
if ( SleepEx ( 0, 1 ) != 0 )
{
// There was an event, which means we received some data
etc..
I had this more-or-less working when my customer decided to use Linux.
The port to Gtk was much easier.
Cheers,
Rob
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: How do you develop you GTK code?
Hi Diogo,
On Fri, 13 Apr 2007 23:57:12 -0300 you wrote:
I am curious about it and really want to know: How do you develop your GTK
codes?
Mostly by hand.
Before coming to GTK I had done some GUI apps on Windows with Borland C++
Builder, which is quite nice for drawing fixed size dialogs with a small
selection of different widgets. I had also briefly tried customizing a GUI
written in Tcl/Tk (and later Python/Tkinter) with no RAD support.
My first few GTK apps were hand written using tables of widgets. It does make
it harder to visualize what you're creating as you go, but anyone that's done
HTML will be accustomed to how tables work. If you draw your GUI out on paper,
it's really not hard to code from that.
I tried Glade more recently, thinking it would be easier, like the Borland
tool. Well, it does work as a drawing tool, and I guess if you use libglade and
don't care how it ends up being implemented then it isn't too bad. But the code
generator (now deprecated) produces something truly horrid.
The other thing to bear in mind is this:
If you have a row or column of similar widgets, say buttons, then a tool like
Glade or BCB requires you to place every one individually. Writing the code by
hand lets you do:
for ( cc=0; cc10; cc++ )
{
MyButtons[cc] = gtk_button_new (..);
gtk_box_pack_start ( );
}
This is even more relevant if the number of buttons isn't known at design time!
___
gtk-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: (mild) performance issues
On Tue, 3 Apr 2007 13:03:46 -0700 (PDT) Bobby wrote: I'm not sure if we're proving that the original post had a point or that we have a lot of hardware, some of it good, some of it crap ;) It seems to me that you're proving that doing something mildly outrageous on the sort of machine you can find being thrown in the local dump (this Athlon 1.1 GHz machine I'm using was rescued from just such a fate) is nonetheless just about possible. Though the implication that 2.8 was much better than 2.10 is interesting! ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: (severe) performance issues
On Thu, 29 Mar 2007 13:58:51 -0700 (PDT) David J. Andruczyk [EMAIL PROTECTED] wrote: It does when you're monitoring a realtime datalogging system, and don't want to have gaps or slow response in the updates. (there are also graphical monitors as well, but the text is there for a precise reading) No, it doesn't. No, it absolutely doesn't. Who the £%$% do you think is watching this? Because you seem to have forgotten (along with your manners) the FIRST RULE OF GUI DESIGN : If it's not USEFUL to the USER it's WRONG. I use high speed data loggers. I would not want your feature. ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Dynamic changing values at a GtkTreeStore with pointers
On Sun, 25 Mar 2007 05:17:50 -0300 Diogo wrote: It is a little confusing to me because I assume that POINTERS are address and address are passed using key. No, wrong. Addresses are *passed* exactly like any other type is passed. Addresses can be *obtained* using the operator. Hence: char jim; char * fred; fred = jim; Means: jim is a variable of type char fred is a variable of type pointer to char Assign to fred the value obtained by applying the take address of operation on jim. Or make fred point to jim for short. Of course, C++ goes and f*£$s with your understanding by _also_ using to mean pass by reference, where reference *is not* the same as address. This is one of many places where C++ is a very bad OO language. Its use of polymorphism is horribly broken. ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Modal dialog working?
On Thu, 1 Feb 2007, [EMAIL PROTECTED] wrote : Does GTK_DIALOG_MODAL normally work OK? In my experience, the GTK definition of modal is slightly different to what you're used to on Windows. Both systems accept that a modal dialog freezes its parent application, but GTK doesn't force the dialog to the foreground. Perhaps one of the experts might correct me. -- Rob Pearce http://www.bdt-home.demon.co.uk The contents of this | Windows NT crashed. message are purely | I am the Blue Screen of Death. my opinion. Don't| No one hears your screams. believe a word. | ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Fwd: Segmentation fault on log
On Sun, 11 Feb 2007, José Antonio Sánchez [EMAIL PROTECTED] wrote : Having diferent threads making logging could trigger this? or is it only triggered with g_debug(Somethig recursive: %s,rec(z)) where rec(z) is something that has a debug inside? I'm not really a GTK expert, but my money would be on the former. In the latter case, at least with your example, I don't believe that would cause it. The reason being that it doesn't cause rec(z) to get called _during_ the outer g_debug but rather _before_ it. The compiler will evaluate all arguments of a function call before calling the function with the results. -- Rob Pearce http://www.bdt-home.demon.co.uk The contents of this | Windows NT crashed. message are purely | I am the Blue Screen of Death. my opinion. Don't| No one hears your screams. believe a word. | ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Getting greatest decimal accuracy out of G_PI
Hi Sergei, On Fri, 2 Feb 2007 16:14:09 -0800 (PST) you wrote: You can still use explicit cast, i.e. ((long double)G_PI) , can't you ? Even without the trail 'l' you have correctly suggested to add. You can, but would it work? AIUI the C standard only requires that to result in a long double type - it's perfectly valid (and may even be required) for the compiler to treat G_PI as a normal double first, thus losing the precision, then convert that result to a long double. The trailing 'l' instructs the compiler to treat it as a long double while compiling, thus retaining as much precision as it can. ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Continuing the saga Non-Blocking GUI developement
On Thu, 25 Jan 2007 11:06:22 -0500 Melvin wrote: unfortunately the laptop on which this program must run is something like 700Mhz Just as a random aside, the computer that does the _really_ time critical job of providing precisely timed fuel injection and (if applicable) ignition to all the cylinders on the engine of your vehicle is probably running at around 50MHz, with only 40KB of RAM. Of course, it's not running GTK :) ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Delay in Displaying Dialog
On Tue, 16 Jan 2007, Marshall Lake [EMAIL PROTECTED] wrote : Can there be more than one gtk_main() call in one program? And could that possibly help me? No, that's not allowed. There is a function that iterates the main loop once (gtk_main_iterate??) but the use of that is generally a sign of bad program design. However, it might get you out of a pickle if there's no obvious alternative. How does MODAL and gtk_dialog_run() work? Do they both integrate themselves with the GTK main loop behind the scenes? Yes, they do some arcane magic in conjunction with the main loop. -- Rob Pearce http://www.bdt-home.demon.co.uk The contents of this | Windows NT crashed. message are purely | I am the Blue Screen of Death. my opinion. Don't| No one hears your screams. believe a word. | ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Delay in Displaying Dialog
On Tue, 16 Jan 2007, Matt Fischer [EMAIL PROTECTED] wrote : I believe it's also possible to tell the mainloop about a file descriptor which should be watched, and have it call a function whenever new data appears. I have never used this tactic (hopefully someone else can clarify this) Yes - the GTK IO Channel structure allows this. I have used this approach to asynchronously monitor incoming data on a serial port, and it seems to work fairly well. It certainly gave me FAR fewer headaches than trying to do a similar thing on Windows! chan = g_io_channel_unix_new ( fd ); g_io_channel_set_encoding ( chan, NULL, tErrPtr ); EventSrc = g_io_add_watch ( chan, G_IO_IN, ParseRxData, user_data ); Where ParseRxData is the data handler function: gboolean ParseRxData ( GIOChannel *source, GIOCondition condition, gpointer data ) The only oddity I'm left with is that once I've run that GTK application, the serial port in question just blocks on open for all other applications, though I can re-run the GTK app without problem. -- Rob Pearce http://www.bdt-home.demon.co.uk The contents of this | Windows NT crashed. message are purely | I am the Blue Screen of Death. my opinion. Don't| No one hears your screams. believe a word. | ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Emulating MDI
On Fri, 12 Jan 2007, Micah Carrick [EMAIL PROTECTED] wrote : I typically just use resizable panes and tabbed notebooks. I think it's a nicer UI personally. Not that I really care what looks nicer to you personally... As I mentioned in my other reply, I'm not really looking to have several documents open (but only look at one of them) so a tabbed notebook is no use at all. And re-sizeable panes are all very well but rather limited to showing things side-by-side. What I want is to allow the user to define a group of stuff in one box, another group of stuff in a second box, and a different way of looking at other stuff in a third, then have the ability to say no, actually, I think I want that third box at the top, and the other two side by side below it. So resizing just doesn't cut the mustard. -- Rob Pearce http://www.bdt-home.demon.co.uk The contents of this | Windows NT crashed. message are purely | I am the Blue Screen of Death. my opinion. Don't| No one hears your screams. believe a word. | ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Emulating MDI
On Fri, 12 Jan 2007, Andrew Sobala [EMAIL PROTECTED] wrote : It's not supported natively in GTK+. Most people think that MDI is one of the worst user interface designs ever, and so its lack of support in GTK+ isn't an issue for most people. I've never really quite understood what people find so objectionable about it. It allows you to have two documents side-by-side without wasting space on two sets of menus/toolbars/etc. This is useful, for example when reviewing. In my case, though, I've not really got multiple documents but (potentially, at the user's option) several live displays of various aspects of a system, possibly in different forms, all of which are quite possibly of interest all at once. MDI seems a natural choice for that - indeed most of the commercial products of this type use it. Often it's not the top level - in one that I've used the MDI parent is but one page of a tab-book within a tab-book. That said, if you want to use an MDI-style layout, doing a google search for GTK MDI gives http://gtkadi.sourceforge.net as its first hit. Looks actively maintained, too (last SVN commit 2 hours ago). Interesting - thanks. Though the first screen-shot looks like a collection of re-sizeable panes, while the second is clearly a tab-book. The latter is totally unsuitable for my purposes. The former may be what I resort to, although of the similar tools I've used the one taking that approach was by far the ugliest and least usable. -- Rob Pearce http://www.bdt-home.demon.co.uk The contents of this | Windows NT crashed. message are purely | I am the Blue Screen of Death. my opinion. Don't| No one hears your screams. believe a word. | ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Emulating MDI
I have a Windows application I want to port to GTK. In the Windows version it uses the Multiple Document Interface scheme, where several document windows are placed on the main application canvas, and each of these windows is decorated like a top-level window. For this particular application, that layout makes a lot of sense. So, is there a convenient way I can re-create that look in a GTK app? There's no corresponding standard widgets - the only standard widget that has the user-resizing and minimize/maximize seems to be GtkWindow (and I suspect that's actually mostly provided by the window manager rather than GTK). -- Rob Pearce http://www.bdt-home.demon.co.uk The contents of this | Windows NT crashed. message are purely | I am the Blue Screen of Death. my opinion. Don't| No one hears your screams. believe a word. | ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Strange widget problem, GTK-2.10
Hi, I'm new to this list, so I hope this is vaguely the right place... I have an application that uses a custom widget derived (fairly closely) from the GtkDial example in the tutorial. It's close enough that I'm fairly confident the problem I have applies to the original too. This widget draws a dial, consisting of a background canvas, a needle, and a set of tick marks. When working right, the tick marks are in the fg[NORMAL] colour, the needle is (slightly oddly) bg[NORMAL] and the canvas is bg[ACTIVE]. I'd guess this combination was chosen to look nice on the defaults ;) Anyway, on GTK-2.8.x this application works fine, including when I set up my ~/.gtkrc-2.0 for lovely colours. On GTK-2.10.x it doesn't. The dial background is painted in needle colour. So I checked out the dial_test application, which uses the widget in the same way, and that works on GTK-2.10.x correctly. Hmm... thought I... that's weird. So I did some digging around, looking at the places where the two applications differ, starting around where the dial is used and moving out. Eventually I came down to the following: My proper application has a toolbar, containing several stock icons. If I set that toolbar to text only, the dial is coloured correctly. If I enable the icons, the dial's background is messed up. As far as I can tell, the background colour is set by the gtk_style_set_background call at the end of gtk_dial_realise What seems to be happening, on GTK-2.10.x only, is that the effects of this line are broken when a [stock] icon is displayed [in the tool bar]. This feels like a bug to me, and not just a bug in the GtkDial example but something wrong in GTK-2.10 itself. That said, I have worked out some modifications to GtkDial that get around it (by colouring the canvas in bg[NORMAL] and the needle in bg[ACTIVE] instead). But I do feel there's likely to be other places this behaviour may bite somebody. -- Rob Pearce http://www.bdt-home.demon.co.uk The contents of this | Windows NT crashed. message are purely | I am the Blue Screen of Death. my opinion. Don't| No one hears your screams. believe a word. | ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
