Re: gtk-main-iteration -- use and understanding
On Sun, Jan 31, 2016 at 8:10 AM, Stefan Salewski wrote: Do you know an not too complicated example where code in a callback is called which may block for about one second? In the long term I may switch to a asyncroneously design, but currently I have no idea how to do that best. Have you a hint for that approach? My first thought would have been to trigger that callback via a g_idle_add() [1] call. This will schedule the callback to run only when there are no more pressing events waiting. Thus, the main_loop can finish handling input events and updating the screen before starting your callback. The callback will still block while it's running, of course, but that sounds like it's okay for your purposes at the present. Note that, if the callback returns True, it will be called again at the next idle time. If your callback is looping, your may be able to use this to call each loop separately, letting the main loop handle events in between. I don't know what this would mean for performance, though. Robert [1] https://developer.gnome.org/glib/stable/glib-The-Main-Event-Loop.html#g-idle-add ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
Re: Interactive data plotting application
On Sun, Jan 10, 2016 at 7:05 AM, Jozef V.Molnár wrote: I need to develop a GTK3 widget for data plotting, drawing and analysis purposes. I need the following features (many are standard requirements): - have a grid sensitive to mouse (to invoke a configuring menu) - add/remove plots - plots sensitive to mouse (display the data coordinates) - more than cursors (to perform measurements) - cursors capable of find edges of data plots - scrolling If you're working in Python, you should consider matplotlib [1], which has a GTK3 backend [2]. If you're not working in Python, you may still wish to see if you can wedge matplotlib into your system. It's rather powerful. As another possibility, you may wish to consider using a WebView and one of the many javascript plotting libraries out there. I'm aware of D3 and Bokeh off-hand, though I'm sure there are others. Robert [1] http://matplotlib.org/ [2] http://matplotlib.org/examples/user_interfaces/embedding_in_gtk3_panzoom.html [3] http://d3js.org/ [4] http://bokeh.pydata.org/en/latest/ ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
Re: Misconduct of GTK+/glib Bugtracker Admins
This is probably ill-advised, but what they hey?
Having read through your transcript, what I see is three developers
trying to deal with an initially-vague bug about non-standard use
reported against the incorrect component. Not only do they get that
straightened out, but Emmanuele Bassi offers to review patches for a
project that isn't his.
For this offer of help, you assert he is a liar ("Actually, you're
being absolutely inaccurate."), an idiot ("Perhaps you should review
what a dependency is."), and part of a conspiracy ("Red Hat has done
everything in their power to break that separation and create a
monolithic stack").
Andre Klapper hides this unproductive comment, and Emmanuele commits
the heinous sin of not immediately realizing that this happened. (But
sure, call him a liar about that, too.) You storm off in a huff;
meanwhile, Psy[H[] continues an apparently-productive technical
discussion of how to actually solve the bug. This suggests that,
perhaps, the problem wasn't with Messrs. Bassi, Blasen, and Klapper.
On Thu, Jun 4, 2015 at 3:44 PM, IgnorantGuru
wrote:
Specially, their conduct administering the GTK+ bugtracker in the case
of bug https://bugzilla.gnome.org/show_bug.cgi?id=750182 is
unacceptable. They are closing bugs preemptively,
No, they closed a bug reported against the wrong component, and shortly
thereafter reopened it against the correct component.
and are using the
code of conduct to threaten people who discuss the history and the
background of a bug. They threaten a user with the code of conduct
for
using the word "overengineered" to justify their choice not to use
systemd.
No, they ask Psy[H[] to stop editorializing ("Please, refrain from
making comments like these in the future."), and Psy[H[] does without
complaint.
They claim personal attacks when no one was even referred to
personally,
Other than those I document above?
and they themselves state that people are "not really
cool" (Emmanuele Bassi).
a) No, Emmanuele says that your behavior is "not really cool". There's
a subtle but important difference.
b) You're insulted that someone thinks you're only sorta cool? Really?
They make false technical statements then
delete any corrections offered in comments.
OmegaPhil repeated the "technical" parts of your hidden posts, and that
has not been deleted.
While these developers' response may not have been absolutely perfect,
it's a damn sight better job than I would have done in their place.
Robert
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list
Using g_mem_profiler_table
Hi all,
I'm trying to use g_mem_profile to get a comparison of memory usage for
several approaches in a GTK application. But I get a realloc error if
I set things up by calling g_mem_set_vtable(glib_mem_profiler_table).
Any ideas why?
Here's a basic C program:
#include
#include
int main( int argc, char** argv )
{
g_mem_set_vtable( glib_mem_profiler_table );
gtk_init( &argc, &argv );
return 0;
}
I compile with:
$ gcc `pkg-config gtk+-3.0 --cflags` mem-basic.c -o mem-basic
`pkg-config gtk+-3.0 --libs`
But when I run it:
$ ./mem-basic
*** Error in `./mem-basic': realloc(): invalid pointer:
0x01af7e80 ***
Aborted (core dumped)
This is on Ubuntu 14.04 (GTK 3.10.8, glib 2.40.2). This is my first
time attempting to g_mem_profile, so don't assume I've done any of the
obvious things yet.
Thanks,
Robert
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list
Re:Re: Would it be possible that gtk implementation in C++
On Sat, Aug 9, 2014 at 10:41 AM, 黄羽众 wrote: Another C++--, I have to say. Many of us would consider that a complement. Excuse for my unpolite, I can't find any point that interest me, the highlights it describes is very common in many existing OOP language. Yep, it's a bog-standard OOP language. The killer feature is its tight integration with GObject. And the only point I remember is its ABI compatible with C, which also limit its language possibility. I'm pretty sure both Vala and C are Turing-complete. :) I think it's would rather better to spend time solving the problem like gtkmm can't provide a function like "builder.signal_connect(this)" to auto connect the signals defined in glade XML files rather than start another project to reinvent the wheel. It sounds like you're looking for Gtk.Builder.connect_signals() [1]. It exists, but not in the gtkmm bindings. This suggests to me that the problem is C++, not GTK. There is a bug report [2], though, so jump in and get it fixed. Robert [1] http://references.valadoc.org/#!api=gtk+-3.0/Gtk.Builder.connect_signals [2] https://bugzilla.gnome.org/show_bug.cgi?id=573482#c64 ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
Re: Would it be possible that gtk implementation in C++
On Fri, Aug 8, 2014 at 12:04 PM, 黄羽众 wrote: Compare to many people here, I am freshman in GTK/GTKmm. I make this proposal just because sometimes I miss the day when I am using QT/Android/HTML5. In that case, I'd suggest you take a look at Vala [1,2]. Vala is a new language, reminiscent of C# and Java, that's built around the GObject system that's at the heart of GTK. This means that there's no impedance mismatch between the language's object system and GTK objects. It handles memory management for you (though you can play with pointers if you really want). It compiles to C, so it'll run everywhere. I've been using Vala for only a little while, but I'm thoroughly impressed. Give it a look. Robert [1] https://wiki.gnome.org/Projects/Vala [2] https://wiki.gnome.org/Projects/Vala/ValaForJavaProgrammers ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
Re: Routing scroll events in a Gtk.Overlay
On Thu, Jun 5, 2014 at 2:34 PM, Paul Davis
wrote:
On Thu, Jun 5, 2014 at 2:11 PM, Robert Schroll
wrote:
So I guess my question becomes, how can a parent (the EventBox)
prevent a certain type of event (scrolling) from being delivered to
its children.
standard solution to such a question is "return true from its own
handler".
I'm obviously misunderstanding something, because that isn't working
for me. In the test program below, there's an EventBox containing a
SpinButton. The EventBox has a scroll-event handler that returns True.
But when you scroll over the SpinButton, this handler is (almost)
never called. Instead, the SpinButton consumes these events. If you
uncomment the set_above_child line, then the EventBox gets the scroll
events, but it also gets the click events, so you can no longer adjust
the SpinButton by clicking on its buttons.
Now, I could keep the SpinButton from spinning by having a scroll-event
handler for the SpinButton return True. For this example, it'd work
fine. But in the circumstance where I have many children,
grand-children, great-grand-children, etc. of the EventBox, that gets
tedious.
Can you straighten me out? Thanks,
Robert
=== eventtest.py ===
from gi.repository import Gtk, Gdk
win = Gtk.Window()
eb = Gtk.EventBox()
sb = Gtk.SpinButton(adjustment=Gtk.Adjustment(50, 0, 100, 1, 5, 0))
eb.add(sb)
#eb.set_above_child(True)
win.add(eb)
win.set_default_size(200, 200)
win.connect('destroy', Gtk.main_quit)
def eb_scroll(widget, event):
print "Event Box scroll event"
return True
eb.connect('scroll-event', eb_scroll)
win.show_all()
Gtk.main()
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list
Re: Routing scroll events in a Gtk.Overlay
On Thu, Jun 5, 2014 at 1:19 PM, richard boaz wrote: instead of using GTK to route the events correctly, is it not possible (possibly preferable) to route all events to your own handler which you yourself can further negotiate and forward to the necessary widget? I hadn't considered that solution. This whole thing is supposed to live beside other GTK widgets in a toplevel window. My immediate reaction is that wouldn't work, since it would also trap events going to those other widgets. But I'll think about it some more. On Thu, Jun 5, 2014 at 1:28 PM, Paul Davis wrote: AFAIK, events propagate only via parent/child relationships (i.e. container/contained). So an event delivered to a widget that just happened to overlap another one but had no child/parent relationship with the covered one would never forward events to the covered one under any circumstances. So I guess my question becomes, how can a parent (the EventBox) prevent a certain type of event (scrolling) from being delivered to its children. The default handling works the other way, starting from the children and bubbling up. Using set_above_child(True) makes the parent get the events instead of the children, but that works for all events, not just the one I want to trap. Thank you both, Robert ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
Re: Routing scroll events in a Gtk.Overlay
On Wed, Jun 4, 2014 at 11:19 PM, Paul Davis wrote: You should know that GTK's design more or less does not cater to overlapping GtkWidgets. It is not completely clear if you are actually doing this, but it certainly sounds as if you are. The API allows you to create overlapping widgets, but nothing else in the API (though I admit to knowing GTK3 not as well as I should) defines event handling when this happens. Z-axis (or "stacking) ordering needs to be defined for this to be done rationally. GTK does not provide this as far as I know (GTK2 definitely does not and I don't think GTK3 changed this). It seems to be behaving perfectly sensibly. Scroll events go to the widget directly under the pointer, whether that's the overlaid or the underlying widget, and the bubble up through the parents. What I'm asking (I think) is if there's a way to change that sensible behavior. (And I have found one, but it involves scroll-event handlers on every widget.) We don't need to consider overlays, if that's worrisome. Consider a composite widget, say an EventBox with a whole hierarchy of children. Is there some way to make one type of event go directly to the EventBox, while others go through to the children? I'd hoped I could do this with set_above_child() and set_events(), but I haven't been able to make that work. Thanks, Robert ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
Routing scroll events in a Gtk.Overlay
Hi all, I'm working on a Gtk project (3.10, Python 2 for the prototype, if that matters) using a Gtk.Overlay [1]. The main child of the overlay is a WebKit.WebView. The overlaid widget is a Gtk.EventBox that contains a number of children, grand-children, etc. Right now, scroll events outside of the EventBox go to the WebView, as desired, but scroll events inside the EventBox go to one of it's children. Instead, I would like all of these scroll events to go to the WebView as well, so scrolling doesn't break when the EventBox moves under the pointer. The only way I've gotten this to work is to recursively attach a scroll-event handler to all the descendants of the EventBox that stops the event and instead creates a scroll event on the WebView. This works, but it's inelegant. I'm hoping there's a way to do this more simply, whether through the EventBox or the Overlay itself. One idea that sort of worked was to set EventBox.set_above_child(True). This ensured that the EventBox got all the scroll events over any of its descendants, so it was easy to pass them on to the WebView. But it also captured all other events, which I want to go through to the children. Is there some way to tell the EventBox to only capture scroll events? Or is there another way to do this? Thanks, Robert [1] Well, actually the Overlay is a custom class inheriting from Gtk.Overlay and implementing Gtk.Scrollable by passing through the adjustments of the WebView. This is to allow the whole thing to sit in a Gtk.ScrolledWindow that moves both the WebView and the overlaid widget together. I hope that doesn't make a difference, but maybe it does. ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
