Re: How to determine EOF after g_io_channel_read_to_end?
I get it. G_IO_STATUS_NORMAL just means EOF, or it will return G_IO_STATUS_AGAIN. Thanks :) 在 2007-05-09三的 15:06 +0800，Hu Zheng写道： I want to implement the http client by iochannel, just send the request, then save all the data to a buffer util the connection is closed. Because the data may be binary, so I think it is not good to use g_io_channel_read_line, I think g_io_channel_read_to_end should be most suitable, but I can't determine the EOF by this function, if I don't shutdown the iochannel by EOF information, the io watch function will always be called with G_IO_IN. How to determine EOF when using g_io_channel_read_to_end and doesn't use g_io_channel_read_line? Much thanks! ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
setting font height for GtkTextview using pango
Hi i am using pango fontdesc to set the font type, size for a GtktextView. Is there any way to change the font height using pango. i have attached a screen shot of output. you can see the white space between two lines (top and bottom of each row). how to avoid those spaces. Please give your suggestion. Thanks prabahar k ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Displaying iso 6937-2 character set letters in GtkWidget
hi I need a way to use iso 6937-2 set for display it in console or on a suitable GTK widget (suggest any) through a c program. I found that this set is available in /usr/lib/gconv/folder as iso_6937-2.so file. how do we use it in a c program. Please give suggestion about this. Thanks prabahar k ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Displaying iso 6937-2 character set letters in GtkWidget
On Wed, May 09, 2007 at 08:31:11PM +0530, prabahar k wrote: I need a way to use iso 6937-2 set for display it in console or on a suitable GTK widget (suggest any) through a c program. I found that this set is available in /usr/lib/gconv/folder as iso_6937-2.so file. how do we use it in a c program. Please give suggestion about this. To display any text in Gtk+ you need to: 1. represent it in UTF-8 2. have the corresponding Pango script engine 3. have suitable fonts With these three ingredients, any Gtk+ widget can display the text. Without them, none can. I don't know what languages/scripts ISO 6937-2 is used for, so I can't tell what the situation is with 2 and 3. However if GNU iconv supports it, chances are at least 1 can be done with g_convert(). Conversion to Unicode is nowadays also the first step to display it esentially anywhere. Yeti -- http://gwyddion.net/ ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
How to create more space leading to and trailing PangoLayout text output with background color?
Hi, In a widget subclass, I'm using a PangoLayout object to render a markup string. Because white spaces in the markup is discarded, I am looking for a way to control the space rendered leading to the text and the spaces trailing to it. The spaces have different background color than the surrounding. What is the best way to create spaces in the Pango rendering of markup? Thanks! -- Daniel Yek ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Newbie needs help: gtk_entry's stopped accepting key stroke entires
FIXED!! I hope the moderator leaves this on the forum: It was not
Google-able ... just in case someone else pulls a bone-head move like I did.
This code was working as a key event handler:
static int key_pressed3(GtkWidget* w, GdkEventKey* event, gpointer data) {
if (event-keyval == 65293)
actionOptions(w, data);
return true;
}
... later ... in the signal area:
gtk_signal_connect(GTK_OBJECT(dialog), key_press_event,
GTK_SIGNAL_FUNC(key_pressed3), dialog);
It turns out that this is either not needed, depreciated, or just plain
wrong. I'm sure that I borrowed this from someone 4 years ago. Some things
definitely changed with GTK over the last 4 years. Commenting out the
signal_connect line restored my keyboard keypress events for all of my
gtk_entry textboxes. It would still be cool if someone vastly more
knowledgable than me could add a note to this thread explaining why this
code worked 4 years ago, what it did 4 years ago, and why it doesn't work
now.
Later -
Luke
crazyluke wrote:
I developed a GTK+ app about 4 years ago that worked well. It was probably
built under GTK ~2.4 or 2.6. I just setup the latest version of Dev-Cpp
compiler with GTK 2.10. I recompiled the old source files. Everything
works fine except for one MAJOR thing: All of the gtk_entry textbox
widgets will not take characters entered via keyboard. Here is the
behavior:
-- You can click in gtk_entry boxes and get a flashing insertion carat in
any of them
-- You can use the mouse to highlight 'gtk_entry_set_text' text in the
boxes or part of the text that is set into a field
-- You can drag-and-drop text with the mouse field-to-field -- and any
changed values are pulled later (e.g., a box has a '1' in it; you
drag-and-drop a '0' out of another field to that field, a '10' comes back
when the field is checked with a 'gtk_entry_get_text'
-- gtk_entry_set_editable (discontinued) and gtk_editable_set_editable
have no affect (true or false)
-- Fields seem to respond normally to other settings (e.g., they can be
enabled/disabled, made invisible/visible, etc.)
-- Other widgets in the window work perfectly: checkboxes, radiobuttons,
regular buttons
Everything about these fields is normal, except that no characters appear
when pressing any keys on the keyboard.
The field setup is pretty straightforward:
GtkWidget *CreateTextEntry(const char *s) {
GtkWidget *w = gtk_entry_new();
gtk_entry_set_text(GTK_ENTRY(w), s);
//gtk_entry_set_editable(GTK_ENTRY(w), TRUE); //discontinued
gtk_editable_set_editable(GTK_EDITABLE(w), TRUE);
return w;
}
Am I missing some sort of new gtk_entry signal/keyboard hookup?
Is there something wrong with my old code for this window's events that
would let everything else work but not keyboard entries?
gtk_widget_show_all(dialog);
gtk_main();
gtk_widget_destroy(dialog);
while (gtk_events_pending()) gtk_main_iteration();
return gGTKAnswer;
Or, is this going to be some sort of library/dll/compiler settings issue?
I'm STUCK!
Luke
--
View this message in context:
http://www.nabble.com/Newbie-needs-help%3A-gtk_entry%27s-stopped-accepting-key-stroke-entires-tf3708587.html#a10380489
Sent from the Gtk+ - Dev - General mailing list archive at Nabble.com.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Newbie needs help: gtk_entry's stopped accepting key stroke entires
Hi,
On Tue, 2007-05-08 at 10:46 -0700, crazyluke wrote:
This code was working as a key event handler:
static int key_pressed3(GtkWidget* w, GdkEventKey* event, gpointer data) {
if (event-keyval == 65293)
actionOptions(w, data);
return true;
}
Your code returns TRUE from the event handler. This stops signal
emission and keeps other handlers from being invoked. Check the
documentation of GtkWidget::key-press-event (or any other event signal
handler).
BTW, this would have been more appropriate to ask on gtk-list or
gtk-app-devel-list as this list is about development of GTK+, not about
development using GTK+.
Sven
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Fixing the GtkTreeModel::row-deleted inconsistency
Hi, In the past all GtkTreeModels used to emit the row-deleted signal *after* a node had been fully deleted from the internal data structures. This means that it is not possible to get an iter to that node any longer. When fixing up the GtkTreeModelSort and GtkTreeModelFilter long ago, it appeared that emitting row-deleted after deleting the node is troublesome. These models implement their own reference counting (the ref_node and unref_node methods), and on deletion of a node some objects (GtkTreeView in particular) have to release their last references to the node. For this they need the iterator, which is not available anymore. We ended up changing the sort and filter models to emit the row-deleted signal *before* deleting the nodes. Later on people implementing their own GtkTreeModels with reference counting hit the same problem and at some point a note was added to the API documentation, saying that implementations of GtkTreemodel must emit row-deleted prior to removing the node. Currently this behavior is inconsistent in GTK+, as the GtkListStore and GtkTreeStore still emit row-deleted *after* deleting a node. For the sake of consistency I would like to modify both models to also emit row-deleted before deleting a node. This will also allow for other applications to release their references to objects in a model row before a row is really deleted. It does however change the behavior if you are iterating through the model, the row in the process of being deleted will still be visible, where it was invisible before. Any objections? I intend to make this change before the 2.12 release. regards, -kris. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Fixing the GtkTreeModel::row-deleted inconsistency
Hi, On Wed, 2007-05-09 at 14:06 +0200, Kristian Rietveld wrote: Currently this behavior is inconsistent in GTK+, as the GtkListStore and GtkTreeStore still emit row-deleted *after* deleting a node. For the sake of consistency I would like to modify both models to also emit row-deleted before deleting a node. This will also allow for other applications to release their references to objects in a model row before a row is really deleted. It does however change the behavior if you are iterating through the model, the row in the process of being deleted will still be visible, where it was invisible before. Wouldn't it make more sense to introduce a new signal row-delete and use that instead of changing the semantics of row-deleted? If that would have been done in the first place, then you wouldn't have said inconsistency now. But then I have to admit that I probably just don't know enough about the internals. Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
libglade and GObject support
Hi all, it seems to me that libglade doesn't support yet GtkSizeGroup and other non-GtkWidget objects. There's a patch attached to this bug report: http://bugzilla.gnome.org/show_bug.cgi?id=161903 but it has not been applied yet (after two years). What is blocking this patch? Without this functionality, one still needs to do some manual C work on the libglade generated widget tree, which kills much of the benefit of using libglade. Ciao, Alberto -- http://www.mardy.it -- Geek in un lingua international! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: libglade and GObject support
On Wed, 2007-05-09 at 15:26 +0300, Alberto Mardegan wrote: Hi all, it seems to me that libglade doesn't support yet GtkSizeGroup and other non-GtkWidget objects. There's a patch attached to this bug report: http://bugzilla.gnome.org/show_bug.cgi?id=161903 but it has not been applied yet (after two years). What is blocking this patch? Well, I think the basic idea why we didnt push for its inclusion since back then was the GtkBuilder initiative [1], we want libglade functionality wrapped into gtk+ proper and any special-cased widget building code wrapped into the actual widget-class code itself. I think it would be much better for everyone if we get GtkBuilder done now and not evolve on libglade, my concern here is mostly based on the diverse ways in which you can represent widgets in xml: libglade might do it one way, GtkBuilder might want to do it another - then with all kinds of glade files in circulation things will definitly be harder to manage. Cheers, -Tristan [1]: GtkBuilder patches/discussion available on these bugs: http://bugzilla.gnome.org/show_bug.cgi?id=172535 http://bugzilla.gnome.org/show_bug.cgi?id=383035 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Some comments about GVFS
Hello, On Tue, 2007-05-08 at 16:59 +0200, Alexander Larsson wrote: I'm still not sure why gstreamer needs to run its own mainloop in its thread though. If its async, then it should be able to use the default mainloop. Is it because there is no guarantee of the default mainloop running always? I am not certain how the mainloop got involved here. GStreamer uses threads so that it can use blocking read() and write() calls. Underneath, it's true they go through select() first on the fd + a control fd from a socketpair, because you need to be able to cancel a wait from another thread, so that you can seek, for example. Perhaps that is the concern? In any case, as long as one is able to cancel an in-progress sync operation from another thread, GStreamer is fine, AFAIK. Regards, Andy. -- http://wingolog.org/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
