Re: Reshowing Icons in a Grid
On Fri, Mar 14, 2014 at 4:53 PM, Marshall Lake wrote: > > I have 10 different icons stored in 10 files. I want to display these 10 > icons in different locations in a gtk_grid_new(). > > It works fine once. > > If I gtk_widget_destroy(grid), create a new grid, and try to display these > 10 icons a second time (some in different grid locations and some not) I get > > gtk_grid_attach: assertion `gtk_widget_get_parent (child) == NULL' failed > > and several > > gtk_grid_attach: assertion `GTK_IS_WIDGET (child)' failed > > However, if I re-load the icons from their files after > gtk_widget_destroy(grid) it works fine the second time. Most widgets are "floating" on creation. Then when you add them to a container they get sinked. When you destroy the grid, it unrefs all its children before it is destroyed. If that is the only reference your icons, they are destroyed as well. You can g_object_sink_ref(your_icon) after you create them the first time, then you should be able to add them to new containers after they are destroyed. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Fwd: GUI signals from a thread (GTK+-3.10)
Oops, missed the list on my reply... -- Forwarded message -- From: Andrew Potter Date: Sat, Feb 15, 2014 at 9:41 AM Subject: Re: GUI signals from a thread (GTK+-3.10) To: Valentin But On Fri, Feb 14, 2014 at 9:25 PM, Valentin But wrote: > I've changed the code, now it's a perfect GTK+ threading example with > a progress bar! Will somebody add it to gtk3-demo and documentation? Its good to hear you're interested in contributing. But it is dangerous to send a message to a public mailing list claiming perfection! Somebody may feel like nitpicking. For instance.. ;) You've chosen to allocate your THREAD_PROGRESS_DATA on the stack, and have passed the address of the stack variable to g_idle_add(). Presumably you don't want to allocate and free a ton of progress_datas, which is understandable. But there are two problems with your approach which are fundamental to safely implementing threaded programs. Problem 1) Passing stack variables from a worker thread is dangerous. Consider this sequence of events: ### GTK+ Main Loop ### calls thread_progress()... ### Thread ### The loop ends, and g_source_remove() is called. But thread_progress is in the middle of executing, and g_source_remove() isn't going to do anything about that. thread_func() leaves scope, and the address of progress_data is now invalid! ### GTK+ Main Loop ### Tries to dereference progress_data. Who knows what it finds. If the thread is destroyed by this point, then you may even segfault. If you want to pass stack variables around via pointer, you must be absolutely sure the lifespan of the variable is longer than the functions that can access them. In this case, consider making THREAD_PROGRESS_DATA a member of your CallbackObject. This way its data lifetime exceeds that of the thread for sure. Problem 2) Reading and writing variables across threads is dangerous. Most variables on most architectures are not "atomically" updated. Indeed, you should never assume atomicity unless you are leveraging language or library features that explicitly give it. In this case, the gdouble x variable may only be half updated when it is read. Admitably this isn't a critical error in this case, but if someone were to take the same approach with updating a pointer they could get into real trouble. As such it shouldn't be presented as example code. The solution in this case would be to include and use a GMutex to guard access to all variables that multiple threads are touching. You have a similar problem with the way you have implemented aborting the thread. For this, a GCancellable provides a safe method. Your button can call g_cancellable_cancel() and inside the thread you can check g_cancellable_is_canceled(). The above are critical issues. As far as meaningless nitpicking, returning G_SOURCE_CONTINUE in thread_progress() describes its behavior more explicitly. You can also annotate messagebox() with the G_GNUC_PRINTF(2, 3) macro to enable compile-time format checking for calls to that function. These changes would make your program much closer to perfect I think. Cheers! ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GUI signals from a thread (GTK+-3.10)
On Fri, Feb 14, 2014 at 6:51 PM, Valentin But wrote:
> Greetings gtk-app-devel-list.
>
> I'm a newbie GTK+ developer and I have encountered with a problem.
Hello and welcome!
> Documentation say that "the threading support has been deprecated in
> GTK+ 3.6. Instead of calling GTK+ directly from multiple threads, it
> is recommended to use g_idle_add(), g_main_context_invoke() and
> similar functions to make these calls from the main thread instead".
>
> I have no idea how g_main_context_invoke() could be usefull for that
> and g_idle_add() is totally wrong: because if something heavy in the
> function happens, then the GUI hangs anyway.
This section of the documentation could be more explicit. The key
point about g_idle_add() is that it is safe to call from another
thread. Its purpose is not to perform blocking or "heavy" operations,
but instead to be a threadsafe method by which you can return
information to the main loop.
> Here's a minimal programm. Somehow GTK+ calls from thread are working.
> How sinfull is that?
It is fully sinful and few will pardon it! ;) It
"works"--sometimes--on your platform. The fact is that you are open to
segfaults or other spurious behavior.
While I don't have time to rewrite your program, here's the basic
outline of how it should work:
You should define small struct like struct progress_info {
GtkProgressBar* bar; gdouble fraction; }.
You should create a new function called something like
threadfunc_cb(gpointer userdata) that casts userdata to a struct
progress_info*, and then calls gtk_progress_bar_set_fraction() with
the information inside the struct. Be sure to return G_SOURCE_REMOVE,
and also g_free() the userdata.
Inside your threadfunc() should g_malloc a struct progress_info called
something like m_progress_info and set its parameters accordingly.
Then you should call g_idle_add(threadfunc_cb, m_progress_info).
With g_idle_add_full() you can specify a GDestroyNotify callback to
free your data automatically! Instead of calling g_free() in your
threadfunc_cb, you can use:
g_idle_add_full(G_PRIORITY_DEFAULT_IDLE, threadfunc_cb,
m_progress_info, g_free);
I looked around for example code on developer.gnome.org but came up
empty handed. Nonetheless, I'm pretty sure this mailing list has a ton
of old threads on the correct usage of g_idle_add(). :)
Have fun with your project!
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Could not find signal handler...
On Wed, Dec 11, 2013 at 11:06 AM, Ken Bass wrote: > I know that this subject has been asked and answered many times, and I have > been googling for several days to try to find an answer that works, but to > no avail. So, sorry in advance... >[...] > and the compile and like commands: > > gcc -I/usr/include/cairo -I/usr/include/glib-2.0 > -I/usr/lib64/glib-2.0/include -I/usr/include/pixman-1 > -I/usr/include/freetype2 -I/usr/include/libpng15 -I/usr/include/libdrm > -I/usr/include/gtk-3.0 -I/usr/include/gio-unix-2.0/ > -I/usr/include/pango-1.0 -I/usr/include/gdk-pixbuf-2.0 > -I/usr/include/harfbuzz -I/usr/include/atk-1.0 > -I/usr/include/at-spi2-atk/2.0 -O0 -g3 -Wall -c -fmessage-length=0 > -export-dynamic -o test.o ../test.c > > gcc -o test test.o -lcairo -lgdk-3 -lpangocairo-1.0 -lgdk_pixbuf-2.0 > -lcairo-gobject -lpango-1.0 -lgobject-2.0 -lglib-2.0 -lgmodule-2.0 -lgtk-3 > -latk-1.0 -lgio-2.0 -lcairo -lgdk-x11-2.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0 > -lpango-1.0 -lgobject-2.0 -lglib-2.0 -lgdk-3 -lcairo-gobject -lgmodule-2.0 > -lgtk-3 -latk-1.0 -lgio-2.0 Since you are linking gdk-x11, I assume you are building for Linux. The documentation at https://developer.gnome.org/gtk3/stable/GtkBuilder.html#gtk-builder-connect-signals suggests that you should be linking against gmodule-export-2.0, which is a different thing than gmodule-2.0. And I think the --export-dynamic needs to be an option in the second gcc command, as the -Wl,--export-dynamic in the documentation instructs the compiler to use the export-dynamic option at link time. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: freely re sizable GtkTreeView columns
On Sun, Dec 8, 2013 at 2:45 PM, Max Linke wrote:
> I'm writing my first GTK app with pygobject. I'm struggling with the
> resizing of treeview columns. The data in one column are quite long
> strings (filepaths) and I want to be able to dynamically resize the
> column to something smaller then the length of the strings.
>
> I'm creating the columns like this
>
> column = Gtk.TreeViewColumn('id', renderer, text=0)
> column.set_resizable(True)
>
> But then the min column size is the length of the longest string in the
> column. It would be nice if I could also resize the column to something
> smaller.
The cell renderer should be or be derived from a GtkCellRendererText.
The GtkCellRendererText has an ellipsize property that you can set. If
the text isn't allowed to be ellipsized, then the minimum size of the
column is going to be the length of the longest text row.
https://developer.gnome.org/gtk3/stable/GtkCellRendererText.html#GtkCellRendererText--ellipsize
Hope you are enjoying your first GTK app :)
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Still confused on new thread starting idle functions to update UI.
On Tue, Dec 3, 2013 at 11:02 AM, David Buchan wrote: > These darn threads and idle functions still baffle me. I'm sorry to be such a > pest. > I want to periodically update a textview as new information comes available. > Sometimes this information can come in quickly (roughly every tenth of a > second). Each update is a single line of text. > The thread allocates memory for the character string, and the idle function > does not free it. Instead, the thread free's the memory just before it stops. > It waits a bit to make sure the idle function has finished using the memory > containing the message. > This may seem awkward and unnecessary, but if I just use a single character > string, it is possible for the thread to replace the contents of the string > with the next message while an idle function is still working with the > previous message. Hi David, I have two solutions. The first would be to simply pass a strdup() of your message to g_idle_add() and then free() it in the callback. If you are concerned about memory fragmentation, another solution would be to box up a GString with a GMutex. In your thread you would lock the mutex and append to the string, and then unlock the mutex. In the callback, lock the mutex, process the string (by which I think you are just dumping into a GtkTextBuffer), clear the GString, and then unlock the mutex. Good luck :) ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Delay time to spawn new threads?
On Wed, Nov 27, 2013 at 11:20 AM, David Buchan wrote: > Yes, I've tried the printf thing. It takes about 1.5 sec. Very strange. It will be hard to help you much further without an example program. If thread creation does in fact take so long on your platform, you can perhaps create the thread ahead of time. What your thread should do is just pop from a GAsyncQueue. This will cause the thread to block; then when you push the button, you can use g_async_queue_push(), which will wake the sleeping thread. This design has some side effects: when you push the button twice, the work for the second button push will not begin until the first button push work is finished. This may or may not be an advantage. Actually, instead of setting all that up yourself, you might want to consider using a GThreadPool. This is probably all overkill and there is some other problem unless you are working on an some kind of embedded platform. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Delay time to spawn new threads?
On Wed, Nov 27, 2013 at 7:29 AM, David Buchan wrote: > I have written a program which spawns a new thread when the user clicks a > button. The new thread does something noticeable immediately after starting, > so I know when the thread has begun. What I mean is, if I run that piece of > code that is executed as a new thread, but as a stand-alone program, it does > it's thing immediately. > > However, when I have it run as a new thread when the user clicks a button, it > takes about 1.5 seconds before it does its thing. > > > I've done this with g_thread_create() and g_thread_new() with identical > results. Is it normal for there to be a 1.5 sec delay, or have I bumbled > something? While there is some cost to spinning up a new thread, it should be a much much less than 1.5 seconds. I suspect the problem may be elsewhere; what precisely is "something noticeable"? Are you creating or modifying GTK elements in your new thread? All GUI operations have to be done on the main thread (e.g. thread with the GMainLoop). Try putting a printf() at the start of your new thread; does that take 1.5 seconds to show up on stdout? ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: deactivate "enter" signal on GtkButton
On Thu, Nov 7, 2013 at 7:06 PM, Mahesh Chaudhari
wrote:
> On Thursday, 7 November 2013 10:46 AM, Andrew Potter
> wrote:
> On Thu, Nov 7, 2013 at 4:10 AM, Mahesh Chaudhari
> wrote:
>> Also (unsuccessfully) tried :
>> void enter_button1(GtkWidget *widget, gpointer data)
>> {
>>GtkStyle *style;
>>style = gtk_widget_get_style(button1);
>>style->bg[GTK_STATE_PRELIGHT] = style->bg[GTK_STATE_NORMAL];
>>gtk_widget_set_style(button1, style);
>> }
>
> This may not have worked because the theme style may be being applied
> after you call this function.
Actually the reason is may be that your theme is not setting the
background color, but is instead setting a _background image_.
What I found is that on my installation, a background image was being
set for the default button image, the image being a gradient from top
to bottom of a darker shade of gray. On hover, this gradient was not
drawn.
The example program below prevents my global theme from setting any
background image by default by overwriting it with a completely
transparent image of my own. This may or may not be what you want.
The question becomes, "How do I set a theme selector to use a
different, possibly defined elsewhere, selector?" e.g. set
GtkButton:hover to look the same as the standard GtkButton, whatever
it is.
I don't know.
#include
const gchar my_style[] = "GtkButton:hover,\
GtkButton:prelight, \
GtkButton \
{ \
background-image: -gtk-gradient(linear, center top, center bottom,
from(rgba(0,0,255,0)), to (rgba(0,0,255,0))); \
}";
void on_realize(GtkWidget *widget, gpointer user_data) {
GError *error = NULL;
GdkScreen *screen = gtk_widget_get_screen(widget);
GtkCssProvider *provider = gtk_css_provider_get_default();
gtk_css_provider_load_from_data(provider, my_style,
G_N_ELEMENTS(my_style), &error);
if (error) {
fprintf(stderr, "Error loading CSS Theme: %s\n", error->message);
g_error_free(error);
} else {
gtk_style_context_add_provider_for_screen(screen,
GTK_STYLE_PROVIDER(provider),
GTK_STYLE_PROVIDER_PRIORITY_APPLICATION);
}
}
int main(int argc, char *argv[]) {
gtk_init(&argc, &argv);
GtkWidget *window = gtk_window_new(GTK_WINDOW_TOPLEVEL);
GtkWidget *grid = gtk_grid_new();
GtkWidget *button = gtk_button_new_with_label("Button!");
gtk_container_add(GTK_CONTAINER(grid), gtk_label_new("Label 1"));
gtk_container_add(GTK_CONTAINER(grid), button);
gtk_container_add(GTK_CONTAINER(grid), gtk_label_new("Label 2"));
gtk_container_add(GTK_CONTAINER(window), grid);
g_signal_connect(window, "realize", G_CALLBACK(on_realize), NULL);
g_signal_connect(window, "hide", G_CALLBACK(gtk_main_quit), NULL);
gtk_widget_show_all(window);
gtk_main();
return 0;
}
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: deactivate "enter" signal on GtkButton
On Thu, Nov 7, 2013 at 4:10 AM, Mahesh Chaudhari
wrote:
> Also (unsuccessfully) tried :
> void enter_button1(GtkWidget *widget, gpointer data)
> {
> GtkStyle *style;
> style = gtk_widget_get_style(button1);
> style->bg[GTK_STATE_PRELIGHT] = style->bg[GTK_STATE_NORMAL];
> gtk_widget_set_style(button1, style);
> }
This may not have worked because the theme style may be being applied
after you call this function.
I would make a custom CSS theme and load it with priority
GTK_STYLE_PROVIDER_PRIORITY_APPLICATION.
See https://developer.gnome.org/gtk3/stable/GtkCssProvider.html and
https://developer.gnome.org/gtk3/stable/GtkStyleContext.html#gtk-style-context-add-provider-for-screen
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: calling gtk_widget_queue_draw from another thread
On Wed, Nov 6, 2013 at 9:58 AM, Horst Löffel wrote: > Because the program acts as a plugin i have to run gtk_main in it's own > thread. But drawing operations will come from another thread which i call > "main" thread. Many main loop implementations allow you to embed a different main loop within them. In your "main" thread, see if you can call gtk_main_context_iteration() regularly with may_block = FALSE instead of running the glib main loop full time in its own thread. This should eliminate the need for inter-thread communication. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Insert Various GTKWidgets into a dlg_window
On Fri, Jun 28, 2013 at 2:10 PM, Rui Pedro Caldeira wrote: > I'm sorry Andrew but I'm using GTK+ 2.24.19 and there is not GTKGrid on this > version, aren't you aware of an equivalent for version 2.24.19 of GTK+? The documentation for Gtk2 can be found here [1]. As you've noticed, there is no GtkGrid in Gtk2; instead you can use a [2] GtkTable or a [3] GtkHBox or [4] GtkVBox. You may also find the Gtk 2 tutorial useful [5]. [1] https://developer.gnome.org/gtk2/2.24/ [2] https://developer.gnome.org/gtk2/2.24/GtkTable.html [3] https://developer.gnome.org/gtk2/2.24/GtkHBox.html [4] https://developer.gnome.org/gtk2/2.24/GtkVBox.html [5] https://developer.gnome.org/gtk-tutorial/stable/book1.html ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Insert Various GTKWidgets into a dlg_window
On Fri, Jun 28, 2013 at 10:45 AM, Rui Pedro Caldeira wrote: > I have all sorts os GTKWidgets (buttons, labels, comboboxes,...) and a > dlg_window. > > And I would like to know how I can put all those widgets in the dlg_window > and set their size and position in the window. Assuming a dlg_window is an object that is or derives from GtkWindow, you are probably looking for something that derives from [1] GtkContainer, such as the recommended [2] GtkGrid. The recommended way to use Gtk+ is to use relative positioning and alignment, rather than absolute size and position; this allows your application to present a usable window across a variety of window sizes, languages, and fonts. However, if you _must_ use absolute sizes and positions, [3] GtkFixed is available. [1] https://developer.gnome.org/gtk3/stable/GtkContainer.html [2] https://developer.gnome.org/gtk3/stable/GtkGrid.html [3] https://developer.gnome.org/gtk3/stable/GtkFixed.html ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Invisible GtkImage
On Wed, Jun 26, 2013 at 2:51 PM, Kip Warner wrote:
> On Mon, 2013-06-24 at 13:56 -0700, Andrew Potter wrote:
> So two questions now I have for you, if you don't mind. The first is a
> problem with clipping, the same one I experienced a few days ago. Note
> the assistant button widgets at the bottom of the assistant.
>
> Implementation:
> <http://pastebin.com/ynsQFTzU>
Please show the code that deals with the TextView and ScrolledWindow.
The clipping is almost certainly due to setting the minimum size on
either the TextView, or the GtkBox the two are contained in. I have
example GtkAssistant code at the bottom of this email that does not
exhibit this issue until extraordinarily small window sizes.
> The second is just a request for clarification on the min() calculation
> in your do_draw() override. I'd just like to better understand what that
> calculation is attempting to do.
When scaling an image, both its height and width are changing. In
order to fit the allocated rectangle without clipping, one must figure
out which dimension is smallest (normalized to the aspect ratio). For
example, if a 200x100 image is allocated 200x50, the allocation is
height-limited and the image must be scaled to 100x50. OTOH if
allocated 100x100, the image is width-limited and must be scaled to
100x50.
> ... Hopefully now if anyone else in the future wants to do
> something similar with an image in Gtk+, they'll manage to find this
> thread. Actually, it might even be worth adding on the FAQ.
I'm getting motivated to work on a patch to GtkImage to add scaling support...
-
Below is an example program with ScalableImage in a GtkAssistant.
Example 1, start up:
http://i.imgur.com/ZdqwUZG.jpg
Example 2, Resized to less height. Notice the TextView/ScrolledWindow
had plenty of space to "give up" because it has no minimum height
http://i.imgur.com/wTN5rY9.jpg
Example 3, Clipping occurs at this very small size due to minimum size
on the ScalableImage as well as the ScrolledWindow/TextView
http://i.imgur.com/EAzFYOG.jpg
Example 4, ScalableImage is modified to return a 0 minimum size in
get_preferred_height_for_width(). This means that at very small
heights the image will not have enough space to fill the allocated
width, allowing the other widgets get some space in this corner case.
http://i.imgur.com/ZrOPt75.jpg
It is your choice whether or not to allow your header image to become
smaller when the window is pressured for height.
#!/usr/bin/python
# coding=UTF-8
from gi.repository import Gtk, Gdk, GdkPixbuf
class ScalableImage(Gtk.DrawingArea):
def __init__(self, filename):
super(ScalableImage, self).__init__()
self.pb = GdkPixbuf.Pixbuf.new_from_file(filename)
def do_get_preferred_width(self):
pw = self.pb.get_width()
return (0, pw)
def do_get_preferred_height(self):
ph = self.pb.get_height()
return (0, ph)
def do_get_preferred_height_for_width(self, width):
ph = width / self.get_aspect_ratio()
return (0, ph)
def do_get_request_mode(self):
return Gtk.SizeRequestMode.HEIGHT_FOR_WIDTH
def get_aspect_ratio(self):
return self.pb.get_width() / self.pb.get_height()
def do_draw(self, cr):
alloc = self.get_allocation()
pw, ph = self.pb.get_width(), self.pb.get_height()
aw, ah = float(alloc.width), float(alloc.height)
r = min(aw/pw, ah/ph)
cr.scale(r, r)
Gdk.cairo_set_source_pixbuf(cr, self.pb, 0.0, 0.0)
cr.paint()
return False
bin = Gtk.Box(False)
bin.set_orientation(Gtk.Orientation.VERTICAL)
img = ScalableImage("gnome-logo.png")
bin.add(img)
tv = Gtk.TextView()
buf = tv.get_buffer()
buf.set_text("Lorem ipsum dolor sit amet, consectetur adipiscing elit.\
Quas enim kakaw Graeci appellant, vitia malo quam malitias nominare.\
Quod autem satis est, eo quicquid accessit, nimium est; Solum\
praeterea formosum, solum liberum, solum civem, stultost; Erat enim\
Polemonis. Conferam tecum, quam cuique verso rem subicias; Duo Reges:\
constructio interrete. Aufert enim sensus actionemque tollit\
omnem.\n\nQuae cum magnifice primo dici viderentur, considerata minus\
probabantur. In quibus doctissimi illi veteres inesse quiddam caeleste\
et divinum putaverunt. Dolere malum est: in crucem qui agitur, beatus\
esse non potest. Tu vero, inquam, ducas licet, si sequetur; Eademne,\
quae restincta siti? Sint modo partes vitae beatae. Sextilio Rufo, cum\
is rem ad amicos ita deferret, se esse heredem Q. Negat enim summo\
bono afferre incrementum diem. Sin te auctoritas commovebat, nobisne\
omnibus et Platoni ipsi nescio quem illum anteponebas?\n\nIstam\
voluptatem, inquit, Epicurus ignorat? Inde sermone vario sex illa a\
Dipylo stadia confecimus. Quam ob rem tandem, inquit, non satisfacit?\
Duae sunt enim res quoque, ne tu verba solum putes.\n\nComprehensum
Re: Invisible GtkImage
2013/6/24 Andrew Potter : > # Note here that the minimum request is set to the natural height of > the input pixbuf > # This may not be the desired behavior in all circumstances > def do_get_preferred_height_for_width(self, width): > return (self.pb.get_height(), width / self.get_aspect_ratio()) Actually, it occurs to me that Kip is almost certainly going to want to change the size request methods to: def do_get_preferred_width(self): pw = self.pb.get_width() return (0, pw) def do_get_preferred_height(self): ph = self.pb.get_height() return (0, ph) def do_get_preferred_height_for_width(self, width): ph = width / self.get_aspect_ratio() return (ph, ph) Otherwise it won't scale down properly. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Invisible GtkImage
On Sun, Jun 23, 2013 at 10:04 PM, Kip Warner wrote:
> Hey Andrew. Thanks for the help. I've almost got it working after I took
> your advise, but the image is still taking up too much room in the
> vertical GtkBox above and below it. See all the extra space above and
> below it I'd like collapsed:
It turns out that GtkAspectFrame doesn't do what most of us in the
thread expect. All it does is ensures the child receives an allocation
of the correct aspect ratio; it does this by just giving the child a
subset of its own allocation:
From the Gtk+ source:
static void
gtk_aspect_frame_compute_child_allocation (GtkFrame *frame,
GtkAllocation *child_allocation)
{
...
if (ratio * full_allocation.height > full_allocation.width)
{
child_allocation->width = full_allocation.width;
child_allocation->height = full_allocation.width / ratio + 0.5;
}
else
{
child_allocation->width = ratio * full_allocation.height + 0.5;
child_allocation->height = full_allocation.height;
}
...
This means that the GtkAspectFrame does not attempt to do any sort of
height-for-width requests (in fact, it does not override any size
request method).This makes it unsuitable for the purpose of scaling
_up_ an image.
In an effort to definitively answer Kip's question, here is a complete
working program. You can see that I had to override
get_preferred_height_for_width and get_request_mode.
For any future readers, keep in mind this code assumes one wants to
scale a wide, short image up or down to fill the width of the
containing GtkBox.
Kip: In this implementation on my machine, printing out the width in
get_preferred_height_for_width() and the allocation in do_draw() never
showed any bizarre or out of bounds values.
The sample banner image is simply
https://www.gnome.org/wp-content/themes/gnome-grass/images/gnome-logo.png
Result: http://en.zimagez.com/zimage/2013-06-24-130547620x850scrot.php
Code:
#!/usr/bin/python
# coding=UTF-8
from gi.repository import Gtk, Gdk, GdkPixbuf
class ScalableImage(Gtk.DrawingArea):
def __init__(self, filename):
super(ScalableImage, self).__init__()
self.pb = GdkPixbuf.Pixbuf.new_from_file(filename)
def do_get_preferred_width(self):
pw = self.pb.get_width()
return (pw, pw)
def do_get_preferred_height(self):
ph = self.pb.get_height()
return (ph, ph)
# Note here that the minimum request is set to the natural height of
the input pixbuf
# This may not be the desired behavior in all circumstances
def do_get_preferred_height_for_width(self, width):
return (self.pb.get_height(), width / self.get_aspect_ratio())
def do_get_request_mode(self):
return Gtk.SizeRequestMode.HEIGHT_FOR_WIDTH
def get_aspect_ratio(self):
return self.pb.get_width() / self.pb.get_height()
def do_draw(self, cr):
alloc = self.get_allocation()
pw, ph = self.pb.get_width(), self.pb.get_height()
aw, ah = float(alloc.width), float(alloc.height)
r = min(aw/pw, ah/ph)
cr.scale(r, r)
Gdk.cairo_set_source_pixbuf(cr, self.pb, 0.0, 0.0)
cr.paint()
return False
win = Gtk.Window()
win.connect("delete-event", Gtk.main_quit)
bin = Gtk.Box(False)
bin.set_orientation(Gtk.Orientation.VERTICAL)
img = ScalableImage("gnome-logo.png")
bin.add(img)
tv = Gtk.TextView()
buf = tv.get_buffer()
buf.set_text("Lorem ipsum dolor sit amet, consectetur adipiscing elit.
Quas enim kakaw Graeci appellant, vitia malo quam malitias nominare.
Quod autem satis est, eo quicquid accessit, nimium est; Solum
praeterea formosum, solum liberum, solum civem, stultost; Erat enim
Polemonis. Conferam tecum, quam cuique verso rem subicias; Duo Reges:
constructio interrete. Aufert enim sensus actionemque tollit
omnem.\n\nQuae cum magnifice primo dici viderentur, considerata minus
probabantur. In quibus doctissimi illi veteres inesse quiddam caeleste
et divinum putaverunt. Dolere malum est: in crucem qui agitur, beatus
esse non potest. Tu vero, inquam, ducas licet, si sequetur; Eademne,
quae restincta siti? Sint modo partes vitae beatae. Sextilio Rufo, cum
is rem ad amicos ita deferret, se esse heredem Q. Negat enim summo
bono afferre incrementum diem. Sin te auctoritas commovebat, nobisne
omnibus et Platoni ipsi nescio quem illum anteponebas?\n\nIstam
voluptatem, inquit, Epicurus ignorat? Inde sermone vario sex illa a
Dipylo stadia confecimus. Quam ob rem tandem, inquit, non satisfacit?
Duae sunt enim res quoque, ne tu verba solum putes.\n\nComprehensum,
quod cognitum non habet? Nunc ita separantur, ut disiuncta sint, quo
nihil potest esse perversius. Quod ea non occurrentia fingunt, vincunt
Aristonem; Nos commodius agimus.\n\nCerte, nisi voluptatem tanti
aestimaretis. Roges enim Aristonem, bonane ei videantur haec: vacuitas
doloris, divitiae, valitudo; Quid ergo aliud intellegetur nisi uti ne
quae pars naturae neglegatur? Ab hoc autem quaedam non melius quam
veteres, quaedam omnino relicta. Verum tamen
Re: Invisible GtkImage
On Sun, Jun 23, 2013 at 11:17 AM, Kip Warner wrote: > On Sun, 2013-06-23 at 20:11 +0200, David Nečas wrote: >> Well, as it has already been suggested, this is a matter of packing. If >> you request that the widget does not expand >> >> page.pack_start(page._bannerAspectFrame, False, False, 0) >> >> then the containing box will not expand the widget when it is enlarged >> itself. You have to pass expand=True, fill=True. > > Hey David. Like I said to Colomban already, I already tried that. For a vertically orientated GtkBox, the 'expand' field in pack_start is going to be vertical expansion, so you are not going to want that. Instead set the GtkBox.set_hexpand(true) (and GtkBox.set_halign(GTK_ALIGN_FILL)), but definitely do pack children with Fill=True. Make sure both the GtkAspectFrame and the GtkDrawingArea are set to both set_halign(GTK_ALIGN_FILL) and set_valign(GTK_ALIGN_FILL). That means the aspect frame will receive the extra width, and its internal ratio keeping will make its implementation of get_requested_height_for_width() request enough height for your image to expand properly. Its all a problem of packing with expand & fill at this point. Just think about how you want the toolkit to work and make sure each component in the hierarchy is doing the right thing. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Invisible GtkImage
On Fri, Jun 14, 2013 at 5:20 PM, Kip Warner wrote: > I have three concerns. The first is that sometimes the incoming > allocation has some very strange width and height values in it, but are > usually valid the rest of the time. Sometimes I see values like > width of -408563232 and height of 32767. That's unusual. Quick testing of my own image resizing does not seem to have that occur. If you're sure that your requests are always absolutely sane, you might want to put together a small test case as it could indicate a pygtk bug, or maybe a gtk+ bug. > My second concern is that when the assistant window is resized to be > made larger horizontally, the image grows, as it should, but the bottom > of the assistant page with the usual assistant buttons (e.g. Cancel, > Continue) get clipped some how. Is your TextView set to have a minimum height? > My final concern is I'm worried about the introspection system's error > control on handling bad return signatures the way it did here. Since > the introspection data knows that the method should have provided two > out parameters, you'd think it would have caught this more gracefully > with an exception than a core dump? But I guess that's probably nothing > you or I can do about that right now. I suspect it has more to do with Python's dynamic typing. But you might raise the issue with the pygtk folks [1]. [1]: https://mail.gnome.org/mailman/listinfo/python-hackers-list ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GTK free function doesn't appear to have any affect.
On Fri, Jun 14, 2013 at 12:27 AM, dE wrote: > I was monitoring the memory usage before and after execution of > g_object_unref and gtk_list_store_clear, and it didnt change the memory > usage by a bit. > > Is this normal (am I doing it right?)? > > e.g. -- > gtk_list_store_clear (store); > g_object_unref( G_OBJECT (store) ); > g_object_unref ( G_OBJECT ( col_renderer [j] )); Do you have a treeview that is internally holding a reference to the list store? I don't know about the GtkBuilder structures. Also, g_new uses g_slice internally sometimes, and that will do things like try to cache pages I think. Be sure to set the G_SLICE environment variable to always-malloc when monitoring your memory usage. See [1] [1] https://developer.gnome.org/glib/2.36/glib-running.html ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Invisible GtkImage
On Thu, Jun 13, 2013 at 9:54 PM, Kip Warner wrote: > > What you can do to (try to) prevent that situation is to set the widget to > > do "height for width" allocation, and override > > get_preferred_height_for_width() to honor your aspect ratio. In some > > situations of course the toolkit won't be able to perfectly honor the > > allocation request, so be sure not to scale out of bounds no matter what. > > Right. What I will do is resize to exactly what is passed into my > do_size_allocate() override since that size should theoretically meet > the aspect ratio I am maintaining via my > do_get_preferred_height_for_width() override. > def do_get_preferred_height_for_width(self, width): > return (width / self._aspectRatio) > > def do_get_request_mode(self): > return Gtk.SizeRequestMode.HEIGHT_FOR_WIDTH > > ...but something very interesting happens immediately after the return > in do_get_preferred_height_for_width(). I get an assertion fail buried > deep somewhere in python-gi... I suspect something weird is happening because you have the wrong function signature. I can't find any reference to the basic widget methods on the python gtk documentation website, but the C signature is: voidgtk_widget_get_preferred_height_for_width (GtkWidget *widget, gint width, gint *minimum_height, gint *natural_height); So try: def do_get_preferred_height_for_width(self, width, minimum_height, natural_height): minimum_height = width / self._aspectRatio natural_height = width / self._aspectRatio If that doesn't work, try and find out how the python gintrospection stuff deals with out parameters. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Invisible GtkImage
On Thu, Jun 13, 2013 at 8:42 PM, Kip Warner wrote: > That makes sense, but should the allocation passed to the base class's > do_size_allocate() be the original allocation parameter that was passed > into the override, or the one that I modified to contain the new image > dimensions adjusted to maintain the aspect ratio? > > If I use the allocation passed into the override, the pixels in the > image appear to rescale appropriately, but the image as a whole does > not. It grows horizontally, but the height of the widget remains fixed. Yes, you should pass in the same allocation you received. A really proper way to do this would be to scale the image to less than the full allocation depending on the margins/padding/border etc., and then the base class could do the right job with honoring that stuff after you set the pixbuf. But by default that stuff is 0 and you don't have to worry about it in this case. What you can't do is allocate additional height to yourself in do_size_allocate(). So if you have a short wide image and are allocated more width than the height at your aspect ratio allows, you _shouldn't_ scale up or else your image will be clipped; the toolkit knows what it allocated to you and will not let you draw outside of that region. What you can do to (try to) prevent that situation is to set the widget to do "height for width" allocation, and override get_preferred_height_for_width() to honor your aspect ratio. In some situations of course the toolkit won't be able to perfectly honor the allocation request, so be sure not to scale out of bounds no matter what. I'm not sure on how to set the widget to do "height for width" allocation, it seems you may have to override get_request_mode()? What I did was override all the size request methods instead. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Invisible GtkImage
On Thu, Jun 13, 2013 at 6:09 PM, Kip Warner wrote: > The code mostly works in that I can see that the area the widget is > taking appears to be the correct size as I resize its parent. However, > the actual image pixels do not appear to be painted. > Hi Kip, After setting the rescaled image, you should probably "Chain Up" to the default size_allocate method. I'm not a python expert, but I believe Gtk.Image.do_size_allocate(self, allocation) at the end of your override should work. Looking at the implementation, the allocation needs to be stored in GtkWidget's private structure. Without chaining up, the allocation is never stored, and thus when on_draw() is called it is likely making a 0x0 sized Cairo context. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Image resizing
On Sat, Jun 8, 2013 at 10:27 PM, Kip Warner wrote: > The banner image should automatically resize as the window is resized. > It should use the full width available in the parent page (GtkBox), but > the image's height should be calculated as a function of the aspect > ratio to keep it from being distorted. > I don't want the scrollbars to ever appear and the full image to always > be visible. Any help appreciated. > One approach is ditching the ScrolledWindow and overriding the get_preferred_width_for_height/width() vfuncs to return the full image width, and then in size_allocate() set the image to a scaled pixbuf of the allocated width. This involves making a subclass which is a little bit of work if you've never done it before (especially in straight C). The only example I have on hand [1] is in Gtkmm and does quite a bit more than you need (Animated image support, toggling between thumbnail and full size). But overriding these functions should be enough: size_allocate() get_preferred_height() get_preferred_width_for_height() get_preferred_width() get_preferred_height_for_width() [1] https://github.com/talisein/Horizon/blob/master/src/horizon_image.cpp ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GtkCellRenderer for GtkButton or GtkSwitch
On Fri, May 3, 2013 at 12:53 PM, Michael Cronenworth wrote: > On 05/03/2013 02:29 PM, D.H. Bahr wrote: > > Ok, does anyone have some working code with similar effects? I've never > > coded my own widgets before, so I'm not sure how to do so. > Your question was asked[2] a few years ago, which turned up in my Google > search. > [2] > > https://mail.gnome.org/archives/gtk-app-devel-list/2008-September/msg00109.html > > This message is probably also relevant: [3] https://mail.gnome.org/archives/gtk-list/2009-October/msg00012.html ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Gdk PixbufAnimation supported formats
On Thu, Apr 18, 2013 at 12:40 AM, Kip Warner wrote: > Thanks Tadej. It looks like the only format that supports animation that > I can see on my system, and perhaps everywhere at best, is GIF. Do you > have any suggestions for another approach to a simple animation that > supports transparency and more than 8 bit colour? You can make a few png or jpg frames and hook up a g_timeout_add() callback to set the pixbuf on a GtkImage. I done similar when I needed to dynamically scale animated gifs. Be sure to stop your timeout on unmap()/unrealize(), especially if you have more than a handful of animated images instantiated anywhere. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Threads and gtk_widget_show (code should not be reached?)
You missed the list in your last reply. It is quoted below, and I've attached the file you sent me as well (table.txt). On Thu, Jan 31, 2013 at 4:54 PM, Ferdinand Ramirez < ramirez.ferdin...@yahoo.com> wrote: > Attached is a working program with GtkEntry in the table. If you comment > out line 21 and uncomment line 20 to use GtkTextView instead of GtkEntry, > you will encounter the error I mentioned. > > Similarly, if you replace the gtk_widget_show_all on line 65 by > gtk_widget_show, the error goes away but does not draw the table, only the > outermost frame. In fact, doing gtk_widget_show for successive levels of > children works until you reach the GtkTextView level. > > Am I invoking (in lines 73 to 75) the function to create the table in the > correct manner from the thread? What you see in lines 71 and 72 are > alternatives to invoking the function but those have identical results as > well. > > -Ferdinand > I've found that this isn't related to threading, and seems to be a bug in TextView; my guess is embedding TextViews inside TextViews is somehow a bad idea. This error only effects Gtk+-2.0 (at least 2.24.13), and does not effect Gtk+3.0 (3.6.4) I have attached a more concise version of the program that produces the bug. I found that if you delay the show_all on the embedded TextViews to another g_idle_add, you don't get the error. I believe the code is valid, so if nobody else has a comment you might want to file a bug. I don't know if Gtk+2 gets bugfixes anymore though.. The error is: Gtk-WARNING **: gtktextview.c:4610: somehow some text lines were modified or scrolling occurred since the last validation of lines on the screen - may be a text widget bug. Gtk:ERROR:gtktextview.c:4611:gtk_text_view_paint: code should not be reached And the backtrace is: #0 0x0030f9a35ba5 in raise () from /lib64/libc.so.6 #1 0x0030f9a37358 in abort () from /lib64/libc.so.6 #2 0x77775b37 in g_assertion_message () from /lib64/libglib-2.0.so.0 #3 0x00345001efd5 in gtk_text_view_expose_event () from /lib64/libgtk-x11-2.0.so.0 #4 0x00344ff4da3c in _gtk_marshal_BOOLEAN__BOXED () from /lib64/libgtk-x11-2.0.so.0 #5 0x77a3d910 in g_closure_invoke () from /lib64/libgobject-2.0.so.0 #6 0x77a4ea80 in signal_emit_unlocked_R () from /lib64/libgobject-2.0.so.0 #7 0x77a568c7 in g_signal_emit_valist () from /lib64/libgobject-2.0.so.0 #8 0x77a56de2 in g_signal_emit () from /lib64/libgobject-2.0.so.0 #9 0x0034500814be in gtk_widget_event_internal () from /lib64/libgtk-x11-2.0.so.0 #10 0x00344ff4be80 in gtk_main_do_event () from /lib64/libgtk-x11-2.0.so.0 #11 0x00344fa4556c in _gdk_window_process_updates_recurse () from /lib64/libgdk-x11-2.0.so.0 #12 0x00344fa45513 in _gdk_window_process_updates_recurse () from /lib64/libgdk-x11-2.0.so.0 #13 0x00344fa45513 in _gdk_window_process_updates_recurse () from /lib64/libgdk-x11-2.0.so.0 #14 0x00344fa45513 in _gdk_window_process_updates_recurse () from /lib64/libgdk-x11-2.0.so.0 #15 0x00344fa400e7 in gdk_window_process_updates_internal () from /lib64/libgdk-x11-2.0.so.0 #16 0x00344fa4263e in gdk_window_process_updates () from /lib64/libgdk-x11-2.0.so.0 #17 0x003450017eb2 in gtk_text_view_value_changed () from /lib64/libgtk-x11-2.0.so.0 #18 0x003450018346 in get_hadjustment () from /lib64/libgtk-x11-2.0.so.0 #19 0x00345001b140 in gtk_text_view_size_allocate () from /lib64/libgtk-x11-2.0.so.0 #20 0x77a40a9e in g_cclosure_marshal_VOID__BOXEDv () from /lib64/libgobject-2.0.so.0 #21 0x77a3db0b in _g_closure_invoke_va () from /lib64/libgobject-2.0.so.0 #22 0x77a563a8 in g_signal_emit_valist () from /lib64/libgobject-2.0.so.0 #23 0x77a56de2 in g_signal_emit () from /lib64/libgobject-2.0.so.0 #24 0x003450086268 in gtk_widget_size_allocate () from /lib64/libgtk-x11-2.0.so.0 #25 0x00344ff090ae in gtk_frame_size_allocate () from /lib64/libgtk-x11-2.0.so.0 #26 0x77a40a9e in g_cclosure_marshal_VOID__BOXEDv () from /lib64/libgobject-2.0.so.0 #27 0x77a3db0b in _g_closure_invoke_va () from /lib64/libgobject-2.0.so.0 #28 0x77a563a8 in g_signal_emit_valist () from /lib64/libgobject-2.0.so.0 #29 0x77a56de2 in g_signal_emit () from /lib64/libgobject-2.0.so.0 #30 0x003450086268 in gtk_widget_size_allocate () from /lib64/libgtk-x11-2.0.so.0 #31 0x00344ffe595b in gtk_table_size_allocate () from /lib64/libgtk-x11-2.0.so.0 #32 0x77a40a9e in g_cclosure_marshal_VOID__BOXEDv () from /lib64/libgobject-2.0.so.0 #33 0x77a3db0b in _g_closure_invoke_va () from /lib64/libgobject-2.0.so.0 #34 0x77a563a8 in g_signal_emit_valist () from /lib64/libgobject-2.0.so.0 #35 0x77a56de2 in g_signal_emit () from /lib64/libgobject-2.0.so.0 #36 0x003450086268 in gtk_widget_size_allocate () from /lib64/libgtk-x11-2.0.so.0 #37 0x00344ff090ae in gtk_frame_size_allocate () from /lib64/libgtk-x11-2.0.so.0 #38 0x0
Re: Threads and gtk_widget_show (code should not be reached?)
On Wed, Jan 30, 2013 at 8:11 PM, Ferdinand Ramirez < ramirez.ferdin...@yahoo.com> wrote: > I have nothing in there that modifies the buffer. I just create the view > and add it. In fact, the error comes from the line gtk_widget_show_all. If > I replace this line with code to traverse the hierarchy and do a > gtk_widget_show on each object, the error manifests itself only when I get > to the GtkTextView at the leaf nodes. > Unless anyone else has some bright ideas, it would be helpful if you could post a concise test case. Thanks, Andrew ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Threads and gtk_widget_show (code should not be reached?)
On Wed, Jan 30, 2013 at 2:17 PM, Ferdinand Ramirez < ramirez.ferdin...@yahoo.com> wrote: > However, as I pointed out, it works if I replace the GtkTextView with a > GtkEntry within each cell of the table. > > 2013/1/30 Ferdinand Ramirez > > > This works fine if it is all done from the main program. However, when > I > > > create the hierarchy described above in another thread and call > > > gtk_widget_show_all on the GtkFrame that is added, I get an error in > paint > > > saying code should not be reached. Before this error, there is a > warning > > > that the iterator in text view has changed. I am not sure if the > warning > > > and error are related. > If you are getting an iterator warning, you may be trying to use an invalidated GtkTextIter. Be sure to read http://developer.gnome.org/gtk3/stable/TextWidget.html Particularly,"Iterators are not valid indefinitely; whenever the buffer is modified in a way that affects the number of characters in the buffer, all outstanding iterators become invalid. (Note that deleting 5 characters and then reinserting 5 still invalidates iterators, though you end up with the same number of characters you pass through a state with a different number). Because of this, iterators can't be used to preserve positions across buffer modifications." Using an invalid iter is essentially the same as writing data randomly to memory. The GtkEntry probably works because it doesn't have a GtkTextBuffer/Iter. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GTK app development for windows.
> > On 01/30/2013 01:08 PM, John Stebbins wrote: > > I realized I didn't answer your question completely. My "installer" is > just a zip file containing the directory tree of > > everything needed. I have a simple script that copies everything needed > into the directory, then I zip it up. Example > > script attached. > Oh, this is really helpful for me! Thank you. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GTK app development for windows.
On Wed, Jan 30, 2013 at 10:52 AM, John Stebbins wrote: > Not sure where you are getting your information. I just built HandBrake > using the mingw tools on Fedora 18 with gtk+ 3 > support. Works spiffy. > Presumably he is getting his information from http://www.gtk.org/download/win32.php It is relatively easy to cross-compile a Gtk3 Windows .exe with mingw. But how do you give users the program? They need the Gtk3 & dependency .DLLs to run it. There is no Gtk3 installer. Do you have your own installer and distribute the .DLLs that are in the Fedora packages? I'm curious to know if that works. Also if you could share some details on your installer I would appreciate it. Thanks ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: open an existing file in buffer and write on it
On Fri, Jan 25, 2013 at 11:14 AM, Andrew Potter wrote: > [...] blah blah blah. > On second reading this comes off as a little flippant, my apologies. You made a good point, and I should have prefaced my example with links to "proper" serialization tools. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: open an existing file in buffer and write on it
On Fri, Jan 25, 2013 at 11:00 AM, Liam R E Quin wrote: > Please let's not encourage the use of binary file formats where there's > no measured performance requirement. An XML file would be better if > structure is needed, as then it can be interchanged with other tools and > platforms, and the fields are self-describing. Even JSON is better than > a binary file, although JSON is not so good for the document-oriented > text you often find in bibliographies, which I think was the original > purpose here? Not sure. > Those are good next steps, but are probably a little too much for someone who doesn't know how to read or write to a file. Writing the equivalent example using libxml2 would be way too much work. Besides, the GVariant on-disk format is documented, doesn't take any more dependencies, blah blah blah. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: open an existing file in buffer and write on it
On Fri, Jan 25, 2013 at 9:00 AM, Rudra Banerjee wrote:
> But this writes the data in unformatted form.
> Can you kindly explain a bit more?
>
>
A good tool glib has for serializing data is GVariant:
http://developer.gnome.org/glib/stable/glib-GVariant.html
All the example below is untested, so if it blows up try and figure out
what I was thinking ;)
Say you have some data in a list:
struct my_data {
gchar *name;
gint32 id;
};
GList *datas = NULL;
struct my_data *data = g_new0(struct my_data, 1);
data->id = 1;
datas = g_list_append(datas, data);
struct my_data *data = g_new0(struct my_data, 1);
data->id = 2;
datas = g_list_append(datas, data);
Your goal with serialization is to save everything in the list to a file,
so you can read it back later. So in terms of what you want to create in
the GVariant, you want an array of tuples that contain a string and a
gint32.
gsize num_elements = g_list_length(datas);
GVariant **v_array = g_new(GVariant*, num_elements);
for (GList *iter = g_list_first(datas), gsize i = 0; iter != NULL; iter =
g_list_next(iter), ++i;) {
struct my_data *this_data = (struct my_data*) iter->data;
v_array[i] = g_variant_new("si", this_data->name, this_data->id);
}
GVariant *v = g_variant_new_array(g_variant_get_type(v_array[0]), v_array,
num_elements);
g_variant_ref_sink(v);
Okay, now we have a variant that contains all the data that was in your
list. You can get a nice buffer of "binary data" to write to file:
gsize size = g_variant_get_size(v);
gconstpointer buf = g_variant_get_data(v);
GError *error = NULL;
gboolean res = g_file_set_contents("filename.dat", buf, size, &error);
if (!res) {
/* handle an error */
}
That's it! Your data is on disk. Be sure to free everything we allocated
above:
g_variant_unref(v);
g_free(v_array);
The next time your program starts, you're probably going to want to read
that data off the disk.
GList *datas = NULL;
gpointer buf;
gsize size;
GError *error = NULL;
gboolean res = g_file_get_contents("filename.dat", &buf, &size, &error);
if (res) {
GVariant *v = g_variant_new_from_data("a(si)", buf, size, FALSE, g_free,
buf);
g_variant_ref_sink(v);
for (gsize i = 0; i < g_variant_n_children(v); ++i) {
struct my_data *this_data = g_new0(struct my_data, 1);
g_variant_get_child(v, i, "si", &this_data->name, &this_data->id);
datas = g_list_append(datas, this_data);
}
g_variant_unref(v);
}
Now we're back where we started. I hope this is enough to help you get
started. You might also take a look at GFile and GFileOutputStream and
such. In general, read through all the glib documentation so you know
what's available to you.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: change treeview's cell height
On Thu, Jan 24, 2013 at 4:00 PM, Rudra Banerjee wrote: > gtk_tree_view_set_rules_hint (GTK_TREE_VIEW(tree), TRUE); > the rules_hint are not working, i.e. I am not getteing alternative color > for each row. I'm not an expert, but it probably means your default theme does not pay attention to that hint. This could be harder to diagnose since every Gtk3 release has had an evolved theme, and your distro may be changing it as well. What I would do is learn how to use the GtkCssProvider and make the rows the color you want. http://developer.gnome.org/gtk3/stable/GtkCssProvider.html Someone more knowledgeable than I might speak up though. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: change treeview's cell height
On Thu, Jan 24, 2013 at 3:33 PM, Rudra Banerjee wrote: > cell = gtk_cell_renderer_text_new (); > col_auth=gtk_tree_view_column_new_with_attributes ( >"Author", cell, >"text", COL_BIB_NAME, >NULL); > gtk_tree_view_column_set_sort_column_id( col_auth, ID_NAME); > gtk_tree_view_append_column (GTK_TREE_VIEW (tree), col_auth); > gtk_tree_view_column_set_max_width (col_auth,350); > > I googled the wrap_mode, but I haven't have any example. Please give me > a short example(even one liner) try: g_object_set(G_OBJECT(cell), "wrap-mode", PANGO_WRAP_WORD, "wrap-width", 10, NULL); If the cell has more than 10 characters, it might wrap. Good luck! ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: change treeview's cell height
On Thu, Jan 24, 2013 at 1:53 PM, Rudra Banerjee wrote: > In my treeview, I have cells of fixed width, and I want texts longer > than that should be wrapped with height increased. > Get a pointer to the GtkCellRendererText for the column in question; depending on how you construct your TreeView there are different methods. When you have that you can experiment with changing different properties, such as wrap-mode and wrap-width. See http://developer.gnome.org/gtk3/stable/GtkCellRendererText.html ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Would this leak be inside gtk?
On Wed, Jan 23, 2013 at 1:38 PM, Edscott Wilson < edscott.wilson.gar...@gmail.com> wrote: > Maybe it's just a bug in Valgrind... I'm finding that a threaded > environment may confuse Valgrind. I'll do some more checking. > In Valgrind threads become serialized, there is no true concurrency. I found a lot more success hunting memory leaks using Google's tcmalloc library. To use the heapcheck feature, you'll need to run your program on a x86 platform (a VM x86 on x86_64 works). tcmalloc on x86_64 does not provide the requisite stack traces. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Calculating the size of TextView
I did a little investigating today. This bug is fixed in the latest. I git
bisected and found out that the commit that makes it work
is 15be68054074bc, which was in 3.5.1. So I gtk 3.6 should work for you.
On Fri, Nov 23, 2012 at 10:53 AM, Andrew Potter wrote:
> I've run into this before myself [1]. Seems to happen only when you add
> the Textview to an already show()n parent, as you are doing by adding it
> with a button click.
>
> I gave up and used a label. They work fine.
>
> [1]
> https://mail.gnome.org/archives/gtk-devel-list/2012-September/msg00034.html
>
>
> On Sun, Nov 18, 2012 at 12:28 PM, Johan Mattsson <
> johan.mattsso...@gmail.com> wrote:
>
>> Hi
>> I am working on a GTK application that creates a form with many text
>> areas in it. It seems to work fine until I add my widgets to a
>> scrolled pane. Like this:
>>
>> test.vala:
>>
>> using Gtk;
>>
>> class MainWindow : Gtk.Window {
>>
>> Box vbox = new Box (Orientation.VERTICAL, 5);
>>
>> public MainWindow () {
>> set_default_size (700, 600);
>>
>> Button b = new Button ();
>> b.clicked.connect (add_text_field);
>> vbox.pack_start (b, false, false, 0);
>>
>> ScrolledWindow scrolled = new ScrolledWindow (null, null);
>> scrolled.set_policy (PolicyType.AUTOMATIC,
>> PolicyType.AUTOMATIC);
>> scrolled.add_with_viewport (vbox);
>>
>> add (scrolled);
>> show_all ();
>> }
>>
>> void add_text_field () {
>> TextView text_view1 = new TextView ();
>> TextBuffer text_buffer = new TextBuffer (null);
>> text_buffer.set_text ("""A long text ... A long text ...
>> A long text
>> ... A long text ... A long text ... A long text ... A long text ... A
>> long text ... A long text ... A long text ... A long text ... A long
>> text ... A long text ... A long text ... A long text ... A long text
>> ... A long text ... A long text ... A long text ... A long text ... A
>> long text ... A long text ... A long text ... A long text ... A long
>> text ... A long text ... A long text ... A long text ... A long text
>> ... A long text ... A long text ... A long text ... A long text ... A
>> long text ... A long text ... A long text ... A long text ... A long
>> text ... A long text """);
>>
>> text_view1.set_wrap_mode (WrapMode.WORD);
>> text_view1.set_buffer (text_buffer);
>>
>> vbox.pack_start (new Label ("New text view"), false,
>> false, 0);
>> vbox.pack_start (text_view1, false, false, 0);
>> show_all ();
>> }
>> }
>>
>> public static void main(string[] args) {
>> MainWindow m;
>> Gtk.init (ref args);
>> m = new MainWindow ();
>> Gtk.main ();
>> }
>>
>> Compile with valac test.vala --pkg gtk+-3.0
>>
>> The height of the TextView is twice the number of lines in the box
>> when TextView is added to the box. GTK will resize TextView when it
>> gets focus.
>> Is there a way to force GTK to recalculate the size of TextView before
>> it receives focus?
>> /Johan
>> ___
>> gtk-app-devel-list mailing list
>> gtk-app-devel-list@gnome.org
>> https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
>>
>
>
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Calculating the size of TextView
I've run into this before myself [1]. Seems to happen only when you add the
Textview to an already show()n parent, as you are doing by adding it with a
button click.
I gave up and used a label. They work fine.
[1]
https://mail.gnome.org/archives/gtk-devel-list/2012-September/msg00034.html
On Sun, Nov 18, 2012 at 12:28 PM, Johan Mattsson wrote:
> Hi
> I am working on a GTK application that creates a form with many text
> areas in it. It seems to work fine until I add my widgets to a
> scrolled pane. Like this:
>
> test.vala:
>
> using Gtk;
>
> class MainWindow : Gtk.Window {
>
> Box vbox = new Box (Orientation.VERTICAL, 5);
>
> public MainWindow () {
> set_default_size (700, 600);
>
> Button b = new Button ();
> b.clicked.connect (add_text_field);
> vbox.pack_start (b, false, false, 0);
>
> ScrolledWindow scrolled = new ScrolledWindow (null, null);
> scrolled.set_policy (PolicyType.AUTOMATIC,
> PolicyType.AUTOMATIC);
> scrolled.add_with_viewport (vbox);
>
> add (scrolled);
> show_all ();
> }
>
> void add_text_field () {
> TextView text_view1 = new TextView ();
> TextBuffer text_buffer = new TextBuffer (null);
> text_buffer.set_text ("""A long text ... A long text ... A
> long text
> ... A long text ... A long text ... A long text ... A long text ... A
> long text ... A long text ... A long text ... A long text ... A long
> text ... A long text ... A long text ... A long text ... A long text
> ... A long text ... A long text ... A long text ... A long text ... A
> long text ... A long text ... A long text ... A long text ... A long
> text ... A long text ... A long text ... A long text ... A long text
> ... A long text ... A long text ... A long text ... A long text ... A
> long text ... A long text ... A long text ... A long text ... A long
> text ... A long text """);
>
> text_view1.set_wrap_mode (WrapMode.WORD);
> text_view1.set_buffer (text_buffer);
>
> vbox.pack_start (new Label ("New text view"), false,
> false, 0);
> vbox.pack_start (text_view1, false, false, 0);
> show_all ();
> }
> }
>
> public static void main(string[] args) {
> MainWindow m;
> Gtk.init (ref args);
> m = new MainWindow ();
> Gtk.main ();
> }
>
> Compile with valac test.vala --pkg gtk+-3.0
>
> The height of the TextView is twice the number of lines in the box
> when TextView is added to the box. GTK will resize TextView when it
> gets focus.
> Is there a way to force GTK to recalculate the size of TextView before
> it receives focus?
> /Johan
> ___
> gtk-app-devel-list mailing list
> gtk-app-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
>
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Handle "Enter" pressing at GtkEntry
On Wed, Oct 3, 2012 at 7:42 AM, Yury Alyaev wrote: > What is the right way to catch "Enter" pressing at the end of the text input > to GtkEntry gtk_entry_set_activates_default() is probably what you want. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: need help with callback
On Tue, Apr 3, 2012 at 8:04 PM, Gary Kline wrote: > nobody?! I don't understand what you mean when you say >> i hope you can help me get the largest function to print If you are attempting to store application settings to disk, you might consider the GSettings API which is documented at http://developer.gnome.org/gio/stable/GSettings.html Good luck! ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
