Re: recommendations for new laptop as existing one could crash.

[jcupitt]

I've been happy with my xps-13, fwiw.

https://arstechnica.co.uk/gadgets/2017/01/dell-xps-13-ubuntu-review-2017/

It's £1200 for the one with Ubuntu pre-installed. Fedora works well
too, apparently.

John
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Cross platform development

[jcupitt]

On 17 March 2017 at 22:02, Dirk Gottschalk via gtk-app-devel-list
<gtk-app-devel-list@gnome.org> wrote:
> I'm developing a multi platform application with GTK+ for Windows and
> Linux.

I make Windows binaries with jhbuild and mingw from linux. I have it
all wrapped up in a docker container, so all anyone needs to do to
make a binary is

sudo ./build.sh 8.3

and it'll build version 8.3 and make an installer, and the host
machine will be undisturbed.

You're very welcome to nick any parts which might be useful. It's
gtk2, but a gtk3 one would be a simple change. As long as you have
your project buildable via cmake or autotools, it should be simple to
adapt.

https://github.com/jcupitt/build-win64

John
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Migrate to gtk3.0

[jcupitt]

On 10 March 2017 at 15:48, Rúben Rodrigues  wrote:
> Yes, i'm using GtkPlot! SO, I think I'm unable to migrate this to gtk3
> because of graphs. SOmeone who knows something about this charts?
> http://madebyryan.blogspot.pt/2011/08/smooth-curves-for-gtk-chart-component.html

I switched from GtkPlot to goffice in my program, if that's any help.
goffice is the widgets from gnumeric nicely packaged up, including all
the charting code. It's better than gtkplot is most ways.

It has gtk2 (goffice 0.8 and earlier) and gtk3 versions, so you could
switch to goffice first, then move to gtk3 later.

John
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: How to confirm a memory leak

[jcupitt]

You need to set the malloc routines to use the real system malloc;

export G_DEBUG=gc-friendly
export G_SLICE=always-malloc

I have this suppressions file:

 https://github.com/jcupitt/libvips/blob/master/libvips.supp

That's for a gobject-based library, you might need to add a few things
to it. Run your program with:

 valgrind --suppressions=libvips.supp --leak-check=yes ./myprogram

And hopefully you'll see "0 bytes definitely lost".

John




On 28 July 2016 at 17:18, Norman Goldstein <norm...@telus.net> wrote:
> I'd like to understand how to confirm a potential memory leak in gtk3.
> Valgrind shows a definite leak, and "top" shows a steadily increasing
> resident set size (RES).  However, as I have come to understand, due to how
> gtk/glib uses slices for memory management, and how the main loop of gtk
> plays a part, things are not as straightforward as I have just outlined.  Is
> there a definitive guide, "How to confirm a memory leak in GTK"?  I have
> only seen various relevant pages on the net.
> ___
> 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: disabling mouse scroll on GtkComboBox and spin buttons

[jcupitt]

On 22 May 2016 at 10:57, Florian Pelz  wrote:
> On 05/22/2016 11:54 AM, jcup...@gmail.com wrote:
>> x = gtk_combo_box_new_text();
>> g_signal_connect(x, "scroll-event", G_CALLBACK(true_cb), NULL);
>> ...
>
> Ah yes, this is a much better way.

I'm not sure it'd work for spin buttons though :-(

Something like your event masks, Florian, would probably be necessary for that.

John
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: disabling mouse scroll on GtkComboBox and spin buttons

[jcupitt]

On 22 May 2016 at 07:36, Lokesh Chakka  wrote:
> Is there a way to disable mouse scroll on GtkComboBox and GtkSpinButton
> widgets ?

Yes, the mouse wheel to change the combo drives me CRAZY.

It means you can't use the mouse wheel to scroll a window that
contains widgets, since you might scroll a combo under the pointer
accidentally, and then you start changing the combo value instead of
scrolling. And once you've changed it, you can't change it back,
because you've no idea what it was set to before.

I block this in my code by connecting to scroll-event on the combo, for example:

x = gtk_combo_box_new_text();
g_signal_connect(x, "scroll-event", G_CALLBACK(true_cb), NULL);
...

where

static gboolean
true_cb(GtkWidget *wid, GdkEvent *event, void *data)
{
/* Stop any other scroll handlers running. We don't want the scroll
 * wheel to accidentally change widgets while we're moving.
 */
return TRUE;
}

John
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Documenting properties and signals with gtk-doc

[jcupitt]

I believe (I think) signals and properties are found at build time by
starting up your library and walking the classes you define.

You need to add a bit more machinery to your Makefile.am to help it
run g-ir-scanner for you. There's a page on the wiki about this:

https://wiki.gnome.org/action/show/Projects/GObjectIntrospection/AutotoolsIntegration?action=show

I couldn't see most of that stuff in your project, perhaps I missed it.

John



On 20 December 2014 at 12:39, Wouter Verhelst w...@uter.be wrote:
 Hi list,

 I've been pouring over the (fairly scarce) documentation and trying to
 fix things for several hours last night (until the wee hours of the
 morning, in fact), but so far haven't been able to figure this out:

 I wrote a library to deal with joysticks in a GObject/GTK-like way. It
 works (including a GTK-based tester tool, although the UI could use some
 improvement), and I now want to do the API documentation and also make
 sure that glib-introspection works.

 However, I do not seem to be able to get the documentation that I wrote
 for the few signals and properties to actually show up in the gtk-doc
 output. It just isn't there.

 I'm sure this must be something obvious to someone more experienced with
 gtk-doc than me, but I don't see it.

 Help?

 The code is at https://github.com/yoe/libjoy

 Thanks,

 --
 It is easy to love a country that is famous for chocolate and beer

   -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26
 ___
 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: Documenting properties and signals with gtk-doc

[jcupitt]

Oh dear, I'm sorry, I've been fiddling with gobject-introspection too
much recently. Of course you don't need introspection to generate
gtk-doc output.

I don't know why your signal documentation is not being generated.




On 20 December 2014 at 13:10,  jcup...@gmail.com wrote:
 I believe (I think) signals and properties are found at build time by
 starting up your library and walking the classes you define.

 You need to add a bit more machinery to your Makefile.am to help it
 run g-ir-scanner for you. There's a page on the wiki about this:

 https://wiki.gnome.org/action/show/Projects/GObjectIntrospection/AutotoolsIntegration?action=show

 I couldn't see most of that stuff in your project, perhaps I missed it.

 John



 On 20 December 2014 at 12:39, Wouter Verhelst w...@uter.be wrote:
 Hi list,

 I've been pouring over the (fairly scarce) documentation and trying to
 fix things for several hours last night (until the wee hours of the
 morning, in fact), but so far haven't been able to figure this out:

 I wrote a library to deal with joysticks in a GObject/GTK-like way. It
 works (including a GTK-based tester tool, although the UI could use some
 improvement), and I now want to do the API documentation and also make
 sure that glib-introspection works.

 However, I do not seem to be able to get the documentation that I wrote
 for the few signals and properties to actually show up in the gtk-doc
 output. It just isn't there.

 I'm sure this must be something obvious to someone more experienced with
 gtk-doc than me, but I don't see it.

 Help?

 The code is at https://github.com/yoe/libjoy

 Thanks,

 --
 It is easy to love a country that is famous for chocolate and beer

   -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26
 ___
 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: Plotting library for GTK+

[jcupitt]

On 8 December 2014 at 15:27, Johannes Deutsch j_deut...@web.de wrote:
 I use goffice for this kind of thing. It's the plot library from
 gnumeric, so any plot you can make in gnumeric, you can make with
 goffice.

 Do you know if it's safe to consider goffice for applications based
 on gtk3 that should run on win32 and linux?

My app is still trapped in gtk2 so I have to use goffice 0.8. It works
well on linux and windows.

Current goffice is gtk3 only. As far as I know it works on Windows too.

John
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Plotting library for GTK+

[jcupitt]

On 2 December 2014 at 16:17, Sergei Naumov vo...@rambler.ru wrote:
 I think this question was asked many times but googling gives a rather patchy
 answer to it. So, I am writing a piece of C code that acquires some data from
 hardware controllers and it also has to plot a few simple graphs and 
 histograms
 out of them. What is a canonical tool for such a purpose?

I use goffice for this kind of thing. It's the plot library from
gnumeric, so any plot you can make in gnumeric, you can make with
goffice. It's fast and beautiful enough, for me anyway.

https://github.com/GNOME/goffice

John
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

g_spawn*() on windows

[jcupitt]

Hi all,

I'm using g_spawn_command_line_sync() to run a series of command-line
programs (actually ImageMagick's convert, if that's important).

It works fine, but on Windows I get an incredibly annoying console
window flash up for a fraction of a second for each command. Does
anyone have any good ideas for hiding this?

From a bit of reading it seems that the glib helper program might need
to be changed: it uses _wspawnv() to start the command and this will
(I think) always show a console window for a console program. Is this
right?

John
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: g_spawn*() on windows

[jcupitt]

On 3 July 2014 15:26, Allin Cottrell cottr...@wfu.edu wrote:
 On Thu, 3 Jul 2014, Michael Cronenworth wrote:
 On 07/03/2014 08:33 AM, jcup...@gmail.com wrote:
 Yes, I'm doing that. It all works and I can capture stdout and stderr
 from the convert.exe I'm running, it's just that I get a very annoying
 command window flash on the screen each time.

 If anyone has any ideas about the command window, I'm all ears:-(

 I don't have ImageMagick binaries to check myself, but are they compiled
 as Windows apps or console apps? Console apps will always force a command
 prompt window to open. This is not a by-product of a g_spawn call.

 Within the win32 API there's a way to suppress the appearance of the console
 in such a situation (by passing the flag CREATE_NO_WINDOW to the function
 CreateProcess). I don't know offhand if the gspawn API exposes this option.

g_spawn_helper uses _wspawnv() to launch the .exe which unfortunately
does not have this option. I think g_spawn_helper might need reworking
to use CreateProcess or similar.

I could have a go at a patch, though I don't know much about win32 and
I'd probably make a hash of it :(

John
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Drawing bit mapped image in drawing area

[jcupitt]

On 27 March 2014 14:10, Ken Bass daytoo...@gmail.com wrote:
 I have a bit mapped image (really a video frame) that I want to display. I
 am guessing that putting it into a user drawing box would be the way to go.
 If there is a better way, please point me in that direction.

I have a tiny program which displays a live video image with an
overlay. It's in Python for gtk2, but gtk3 is (almost) the same,
except for the drawing model for the overlay. It runs at about 50fps
with not too much CPU load on my laptop.

https://github.com/jcupitt/rtiacquire/blob/master/rtiacquire/preview.py

The overlay is a crop box you can drag about and resize.

Use GtkImage to display the image data. When a new frame comes in,
decode to a RGB buffer, wrap it up as a GdkPixbuf, and set that pixbuf
as the data for the GtkImage.

https://developer.gnome.org/gdk-pixbuf/stable/gdk-pixbuf-Image-Data-in-Memory.html#gdk-pixbuf-new-from-data

https://developer.gnome.org/gtk3/stable/GtkImage.html#gtk-image-set-from-pixbuf

To draw the overlay, attach to expose-event with connect_after and
just draw. Your code will run after the GtkImage has painted the image
background, so draw anything you like and it'll float on top of the
image.

John
___
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.

[jcupitt]

Here's a tiny, complete program that does almost what you want. It's
gtk2, but should work fine with gtk3.

It just updates a status bar, but it'd be easy to make it do a textview instead.

John
___
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.

[jcupitt]

Oh dear, I think my attachment got munched (thanks Chris).

Try here:

http://pastebin.com/PsG2UDkY



On 4 December 2013 13:31,  jcup...@gmail.com wrote:
 Here's a tiny, complete program that does almost what you want. It's
 gtk2, but should work fine with gtk3.

 It just updates a status bar, but it'd be easy to make it do a textview 
 instead.

 John
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Valgrind is grinding my gears

[jcupitt]

I have a valgrind file here I use for my large gtk2 program:

http://www.vips.ecs.soton.ac.uk/development/nip2a.supp

I get clean runs with this file. Run with something like:

export G_DEBUG=gc-friendly
export G_SLICE=always-malloc
valgrind --suppressions=/home/john/nip2.supp \
  --leak-check=yes \
  nip2 ...  nip2-vg.log 21

I've not used it for a while, it might need a bit of updating.





On 5 November 2013 21:01, David Buchan pdbuc...@yahoo.com wrote:
 Aaaah. I see.

 Thanks guys.




 
  From: Bernhard Schuster schuster.bernh...@gmail.com
 To: David Buchan pdbuc...@yahoo.com
 Cc: David Nečas y...@physics.muni.cz; gtk-app-devel-list list 
 gtk-app-devel-list@gnome.org
 Sent: Tuesday, November 5, 2013 3:59 PM
 Subject: Re: Valgrind is grinding my gears



 No, as soon as you use GObject derived types (or call g_types_init/gtk_init) 
 the class structures for all your gobject derived classes will be created 
 _once_. This unevitable, but nothing to worry about (same for GThread and 
 friends), just be aware of their existance (and/or suppress them in the 
 valgrind output).

 This has nothing to do with G_SLICE=always-malloc, it actually just reduces 
 the false-positives of valgrind as g_malloc internally allocates big chunks 
 of memory and feeds them as chunks to g_malloc calls, which in turn valgrind 
 sometimes counts as possibly lost and clutters the output.

 Bernhard


 On Tue, Nov 5, 2013 at 9:54 PM, David Buchan pdbuc...@yahoo.com wrote:

 Hi Dave, GObject type registration machinery is, under normal circumstances, 
 only ever used tocreate structures that will exist during the entire program 
 lifetime. Does that mean that if I just use straight old malloc() instead of 
 g_slice(), most of the errors would go away? I gather that's essentially what 
 using G_SLICE=always-malloc would do. I can't try this out until late 
 tonight, unfortunately.  From: David Nečas 
 y...@physics.muni.cz
 To: David Buchan pdbuc...@yahoo.com
 Cc: gtk-app-devel-list list gtk-app-devel-list@gnome.org
 Sent: Tuesday, November 5, 2013 2:51 PM
 Subject: Re: Valgrind is grinding my gears On Tue, Nov 05, 2013 at 09:47:13AM 
 -0800, David Buchan wrote:
But when I invoke Valgrind at runtime, I get a lot of errors which I can't 
make any sense of. I have grabbed a small sample of them here: 
http://pdbuchan.com/valgrind.txt I don't like ignoring errors and warnings, 
but I don't know what to do with these. Has anybody else come across these 
types of Valgrind notifications?
 Yes, everyone.  You must understand that all the GObject type
 registration machinery is, under normal circumstances, only ever used to
 create structures that will exist during the entire program lifetime.
 So although things such as class reference leaks can exists, eveything
 inside g_type_class_ref() should be ignorable – and you can clearly see
 from the log that these allocations happen once, not a thousand times.
 The same for g_thread_init(), gtk_init(), etc.  Create a suppression
 file or google one... Regards, Yeti
 ___
 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
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: GUI freeze and long blocking operation

[jcupitt]

On 15 June 2013 01:33, Kip Warner k...@thevertigo.com wrote:
 as a last resort. Maybe you have some debugging tips? I'm finding it
 hard to debug in Python compared to all the many frontends to GDB for
 native code.

I never found the Python debuggers very useful. Event-driven programs
are not a great fit with traditional debuggers, in my opinion, because
execution is so non-linear. You are running tiny scraps of code all
over the place in an order set by an external driver that varies
between runs.

I use an interactive python interpreter to try stuff out, plus a lot
of logging. For example, I did a music player that pulses a set of
lightbulbs in time:

  https://github.com/jcupitt/huebert/blob/master/huebert/controller.py

Every method starts with:

  logging.debug('methodname: parameters')

And I debug by running with logging enabled and dumping the output to a file:

  ./huebert.py --debug  huebert.log

Then load the log into a text editor and compare the trace to what I
think ought to be happening.

John
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: GUI freeze and long blocking operation

[jcupitt]

On 14 June 2013 07:29, Kip Warner k...@thevertigo.com wrote:
 Hey Tristan. I see what you mean, but I think I should have provided
 more code to show that what I was actually doing I think was what your
 followup suggestion was. Namely do some short work, update the GUI, do
 some more short work, repeat.

 http://pastebin.com/DzrT7Fa7

From a quick look your code ought to work. I've written stuff very
like this which works fine.

I think you'll need to make a complete example I can try running, sorry.

John
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: GUI freeze and long blocking operation

[jcupitt]

Hi Kip,

On 13 June 2013 06:40, Kip Warner k...@thevertigo.com wrote:
 If I start the long job function from within my assistant's prepare
 signal callback, as opposed to en-queueing it there via idle_add(), then
 the GUI doesn't refresh throughout the duration of the long job. This
 happens even though I do pump the message queue during the long job via
 the usual...

 while Gtk.events_pending():
 Gtk.main_iteration()


There are two easy ways to do a long operation in Python.

First, with idle_add(). Your callback should run for no more than 50ms
or so before returning. If you need to do more work than that, just
wait to be called again. Do not process events, you can leave that up
to the main loop. This style is handy for non-blocking, background
tasks that don't need interaction from the user.

Secondly, with a regular loop that takes control for a long period.
You can keep the GUI alive by processing events, as you say above.
This style is better for modal actions that either block the GUI or
may require interaction.

It sounds like you have done both at the same time, which seems
confusing to me. I'd make a pure 2) one. If the GUI doesn't refresh,
you probably have a bug in your code somewhere.

John
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: GUI freeze and long blocking operation

[jcupitt]

On 12 June 2013 01:52, Kip Warner k...@thevertigo.com wrote:
 My GtkAssistant on one page in particular performs a long operation
 which would otherwise block the GUI from refreshing, if it were not for
 intermittent...

 while Gtk.events_pending():
 Gtk.main_iteration()

 To start the long work, the prepare signal is captured in my
 assistant and the long job (startDiscVerification()) method is
 enqueued via GObject.idle_add() in the onPrepare() method.

Do you need to use idle_add()?

I have a Progress class I use to draw a progress bar on the screen and
show a spinner and all that. It does the while pending / iterate thing
too. My code looks something like:

init:
  photo = gtk.Button('RTI Capture ...')
  photo.connect('clicked', self.rti_capture_cb, None)

rti_capture_cb:
  mark gui insensitive
  enable progress feedback

  while long_job():
do a bit of work
self.progress.update(percent)

  hide progress feedback
  mark gui active again

Code here, if it's any help:

https://github.com/jcupitt/rtiacquire

John
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: GtkBox vs GtkGrid

[jcupitt]

Hi Tom,

On 2 June 2013 13:12, Thomas A. Moulton t...@moulton.us wrote:
 Am I missing something?

 If I use GtkBox it seems that once I add a child I can't get access to it's
 address any more (GtkWidget *)

 So if I create a box with some things in it in glade I really can't do much
 with them.
 (Other than giving them specific names and using the builder object to look
 them up)

GtkBox is a subclass of GtkContainer, so you can use all those methods
to look up children or loop over them:

https://developer.gnome.org/gtk3/stable/GtkContainer.html

John
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Widget alignment

[jcupitt]

Hi Kip,

On 22 May 2013 01:17, Kip Warner k...@thevertigo.com wrote:
 How can I have this image widget added to the parent such that it is
 always vertically aligned with the top of the page, but keeping the
 other child box below it still vertically centred? I've tried wrestling
 with Glade, but I can't figure out how to do it.

GtkImage is a subclass of GtkMisc, and misc does alignment:

https://developer.gnome.org/gtk3/stable/GtkMisc.html#gtk-misc-set-alignment

Set the horizontal alignment to 0.5 to centre the image within its parent.

John
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Wake screen saver

[jcupitt]

Hi Paul,

On 18 March 2013 21:22, Paul Stelzig paul.stel...@reell.com wrote:
 Is there a way make the screen saver wake up without a key press or mouse 
 movement?  My program is written in C with GTK+ 3.0 I'm running on Linux Mint 
 13 with the mate desktop.  The program is monitoring a inputs from a DIO 
 card, and in normal operation the user isn't going to be using the keyboard 
 or mouse.

I guess you mean stop the screensaver kicking in and hiding your
window? Yes, you can send a dbus message to disable the gnome
screensaver temporarily:

https://live.gnome.org/GnomeScreensaver/FrequentlyAskedQuestions#I.27m_developing_an_application_that_has_a_fullscreen_mode.__Is_there_a_way_that_I_can_disable_the_screensaver.3F

John
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: window-popup = menu

[jcupitt]

Hi Mariano,

Just call gtk_menu_popup() and it'll position the menu away from the screen
edges for you.

https://developer.gnome.org/gtk3/stable/GtkMenu.html#gtk-menu-popup

John


On 13 March 2013 04:05, Mariano Gaudix marianocordobar...@gmail.com wrote:

 Hello  how i can  determine the size of a window-popup hidden ?  ¿  Or  how
 i can make  window-popup   behaves as a menu.

 I have a problem.
 if the botton to activate the window is in  the low position of the  screen
  , the window-popup  ,   is not shown above of the botton  ..

  see the  code and  video of the widget


 http://depositfiles.org/files/4e2ip0pfw
 ___
 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: window-popup = menu

[jcupitt]

Hi again,

You can connect to the map event. This happens after the window has been
realized and just before the window appears on the screen, so the size has
been calculated.

https://developer.gnome.org/gtk3/stable/GtkWidget.html#GtkWidget-map

In ::map, change window x/y to move it away from the screen edges. Or
that's what I'd try anyway!

John

On 13 March 2013 09:11, Mariano Gaudix marianocordobar...@gmail.com wrote:



 Hello .



 Is not  a  menu-popup .
 I  use  a window-popup   .
GTK_WINDOW_POPUP is used to implement widgets such as GtkMenu or
 tooltips  .

 https://developer.gnome.org/gtk3/stable/GtkWindow.html

 I  am  creating   a mockupwith  window-popup  thatcontains
  scrollbar   , and other  widgets

 this is my mockup


 http://www.youtube.com/watch?v=9ckRn_sx8CE






 2013/3/13 jcup...@gmail.com

 Hi Mariano,

 Just call gtk_menu_popup() and it'll position the menu away from the
 screen edges for you.

 https://developer.gnome.org/gtk3/stable/GtkMenu.html#gtk-menu-popup

 John


 On 13 March 2013 04:05, Mariano Gaudix marianocordobar...@gmail.comwrote:

 Hello  how i can  determine the size of a window-popup hidden ?  ¿  Or
  how
 i can make  window-popup   behaves as a menu.

 I have a problem.
 if the botton to activate the window is in  the low position of the
  screen
  , the window-popup  ,   is not shown above of the botton  ..

  see the  code and  video of the widget


 http://depositfiles.org/files/4e2ip0pfw
 ___
 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: GTK app development for windows.

[jcupitt]

On 24 December 2012 13:16, Muhammed Fatih BALIN
catlak.profesor@gmail.com wrote:
 How can I install necessary packages on ubuntu and compile gtk applications 
 for windows on _ubuntu_?

You can download the win32 gtk binaries here:

http://www.gtk.org/download/win32.php

Just compile and link your program with gcc-mingw-w64.

If you have many other dependencies, jhbuild is very convenient. I
have a repro here which builds a setup.exe installer for a large
application, including a lot of deps.

https://github.com/jcupitt/build-win32/tree/master/7.30

John
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Stock Id's and Icons on buttons

[jcupitt]

On 15 December 2012 23:47, Perdie Perduta rsperd...@gmail.com wrote:
 Can any one help me understand how to add my own stock id's or icons
 to these menu buttons, preferably in Glade rather than having to code
 it in the software.

I have some C here that adds new stock items:

https://github.com/jcupitt/nip2/blob/master/src/main.c

search for main_register_icons(). You're welcome to borrow any bits
that look useful.

John
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: GUI freezes waiting for callback function to return

[jcupitt]

On 13 December 2012 11:21, Mateusz Marzantowicz
mmarzantow...@osdf.com.pl wrote:
 I'm writing very simple application in Python using pygobject. I'm using

 What I've observed is that GUI (menu to be specific) freezes till my
 callback function finishes. It's completely unacceptable for GUI

This is because callbacks are run by the main GUI thread, so until
your callback returns, the GUI can't do anything. To give a nice
experience for the user your callbacks must be very short.

If you have to do some lengthy processing, you need to process GUI
events at regular intervals. In PyGtk this used to be:

def my_long_callback():
for i in long_time():
small_chunk_of_work()
while gtk.events_pending():
gtk.main_iteration()

I don't know what the pygobject equivalent is, something similar.

In C you can use threads for background tasks, but I think that's
difficult in Python.

John
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Best way to busy-wait in Python 3 / Gtk+ 3?

[jcupitt]

On 6 October 2012 15:48, Filip Lamparski matka.pooha...@gmail.com wrote:
 However, the thumbnail loading process takes a long time, so I want to put
 it into another process, with the GUI displaying a spinner or a progress
 bar until the loading finishes.

Sorry, I don't use Python much, but in C you'd start a thread to do
the load and then have that call g_idle_add() when it finished.
Meanwhile the main thread stays just handling inputs and repaints, but
you display some sort of busy indicator until the idle callback fires.
Something like:

on_load_button_click:
  busy = True
  update_view
  start worker thread

worker thread:
  load thumbnail
  g_idle_add (thumbnail_done, thumbnail)

thumbnail_done (thumbnail)
  busy = False
  set thumbnail
  update_view

John
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Best way to busy-wait in Python 3 / Gtk+ 3?

[jcupitt]

Sorry I missed the process bit.

To have the load in another process, use a pipe to send worker results
back to the main process, and add the pipe to your gtk main loop as an
event source.

You obviously can't use any gtk/glib stuff in your worker, you'd need
to just make a .jpg, then do all the widget stuff in the main process,

On 7 October 2012 12:34, Filip Lamparski matka.pooha...@gmail.com wrote:
 I specifically want to avoid using GLib's threading machinery in order to
 use multiprocessing, since later I want to add multithreading to the
 thumbnail loading process itself in order to utilise multiple cores more
 efficiently. That is because at first run, I have to download 128 images,
 and the server tends to take its sweet time.

 On 7 October 2012 10:23, jcup...@gmail.com wrote:

 Sorry, I don't use Python much, but in C you'd start a thread to do
 the load and then have that call g_idle_add() when it finished.
 Meanwhile the main thread stays just handling inputs and repaints, but
 you display some sort of busy indicator until the idle callback fires.

 John




 --
 _
 Filip Lamparski - FB - G+

___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Gtk_Tree_View, drawing speed

[jcupitt]

On 26 September 2012 07:09, Arne Pagel a...@pagelnet.de wrote:
 Do you see any other option?

Have you tried setting the fixed-height hint on the treeview?

By default treeview supports variable-height rows. This is great, of
course, but there is a performance penalty: whenever the model
changes, the view has to rescan the model and recalculate all the
heights. If all your rows are the same height, and they might be from
looking at your screenshot, you can set the fixed-height hint and get
treeview to just sample a single row.

http://developer.gnome.org/gtk3/stable/GtkTreeView.html#gtk-tree-view-set-fixed-height-mode

John
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: parsing bibtex with GKeyFile parser

[jcupitt]

On 6 September 2012 13:01, Rudra Banerjee bnrj.ru...@yahoo.com wrote:
 I am thinking of possibility of parsing a bibtex file with gkeyfile
 parser. bibtex has the structure like:
 @Book{a,
 Author=b and q and r, s ,
 Editor=c,
 Title=d,
 }

GKeyFile syntax is not much like that. You could probably use GScanner
to do the lexing and some sort of simple driver function for the
syntax, but I've not tried.

flex and bison would be the standard C way of making something like this.

Alternatively, google reveals a huge number of bibtex parsers for
every language you can think of, perhaps one of those could be reused.

John
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: auto refresh file in textview

[jcupitt]

Hi Rudra,

On 23 August 2012 13:45, Rudra Banerjee bnrj.ru...@yahoo.com wrote:
 whenever I am writing, it is saved, but to see the change, I have to
 reopen the file(obviously).

What do you need to know? Do you want your textview to update as the
file changes?

If your program is appending to the file as well as displaying in the
textview, it would be much simpler just to append to the textview
itself.

John
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: auto refresh file in textview

[jcupitt]

On 24 August 2012 14:41, Rudra Banerjee bnrj.ru...@yahoo.com wrote:
 I am sorry but I really don't know how to write on a buffer.

I append to a textview like this:

void
log_text( Log *log, const char *buf )
{
GtkTextView *text_view = GTK_TEXT_VIEW( log-view );
GtkTextBuffer *text_buffer = gtk_text_view_get_buffer( text_view );
GtkTextMark *mark = gtk_text_buffer_get_insert( text_buffer );
GtkTextIter iter;

gtk_text_buffer_get_end_iter( text_buffer, iter );
gtk_text_buffer_move_mark( text_buffer, mark, iter );
gtk_text_buffer_insert_at_cursor( text_buffer, buf, -1 );
gtk_text_view_scroll_to_mark( text_view, mark,
0.0, TRUE, 0.5, 1 );
}

J
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: yet another thread question

[jcupitt]

Hi again David,

On Friday, 6 July 2012, David Buchan wrote:

 When the user presses a button, an idle function is begun to watch a flag 
 which will tell it a message has been left in a string for it by a worker 
 thread. The worker thread is then started. It will produce results to be 
 displayed in a textview by the idle function. When the worker thread has 
 results, it puts them into the string and sets the message_available_flag. 
 The idle function sees the flag set, prints the results to the textview, and 
 then clears the message_available_flag.

There's a much simpler solution -- just malloc the string in the
worker and pass it to the main thread as an idle argument. Something
like:

worker()
{
  char *str;

  for(;;) {
str = g_strdup(hello world!\n);
g_idle_add(from_worker_cb, str);
sleep(1);
  }
}

gboolean
from_worker(char *str)
{
  update_textview(str);
  g_free(str);
  return FALSE;
}

Now there's effectively a flexible buffer between the worker and the
main thread, so one can briefly run ahead of the other if it has to.
As long as update_textview() typically takes less time than an
iteration of your worker's loop, you'll be fine.

If the worker is always very quick and textview is always very slow
you could fill memory. But this is very unlikely: updating your
program's model should be quick (or your program is badly designed)
and an iteration of a worker should be slow (otherwise, why bother
making a worker).

You could make the buffer bounded with a semaphore. Something like:

// start it at count 10
Semaphore *buffer_length = semaphore_new(10);

worker()
{
  char *str;

  for(;;) {
// decrement the semaphore
// if the semaphore is zero, block until it's 0
// then try again
semaphore_down(buffer_length);
str = g_strdup(hello world!\n);
g_idle_add(from_worker_cb, str);
  }
}

gboolean
from_worker(char *str)
{
  update_textview(str);
  g_free(str);
  // increment the semaphore
  // this will never block us, but can unblock anything
  // waiting on this semaphore
  semaphore_up(buffer_length);
  return FALSE;
}

Using locks and shared variables to synchronise threads can be very
hard, as you found. Races and deadlocks will bite you badly,
especially in more complicated situations.

I find semaphores a nice abstraction: they encapsulate the slightly
tricky process of read / lock / signal in a simple way. They are a bit
old-fashioned now though, which is why I guess glib does not have a
direct implementation.

John
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: yet another thread question

[jcupitt]

On 6 July 2012 14:49, David Buchan pdbuc...@yahoo.com wrote:
 If I understand the first solution correctly, we're creating a separate idle
 function for each message. If the worker thread gets a bit ahead of the GUI
 updates, then a few idle functions might pile up. ok. But one thing I don't
 understand is that these idle functions will be spawned by the worker thread
 (not from the main gtk context), and I thought only the main gtk iteration
 was allowed to muck around with the textview (or any other part of the GUI).

That's right, only the main thread can touch the textview.

Idle callbacks are always run by the main thread. The worker is simply
adding a function pointer and a data item to the list of jobs that the
main thread will perform next time it hits idle. glib has some locks
to make this thread-safe.

g_idle_add() looks something like this inside:

g_idle_add (function, data)
  LOCK (main_thread_idle_list)
  main_thread_idle_list.append (function, data)
  UNLOCK (main_thread_idle_list)

and the main thread runs something like this every time it's idle:

main_thread_idle()
  LOCK (main_thread_idle_list)
  while (main_thread_idle_list)
function, data = main_thread_idle_list.pop_head
function(data)
  UNLOCK (main_thread_idle_list)

so calling g_idle_add() from the worker queues a job for the main
thread. Calling g_idle_add() from a worker is like sending an
asynchronous message from the worker to the main thread.

John
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Another thread/idle/timeout question

[jcupitt]

On 5 July 2012 14:26, David Buchan pdbuc...@yahoo.com wrote:
 Is there a way to have a (non-main iteration) thread issue a signal when it 
 ends?

 I start up a timeout and an idle function when I spawn a new thread.
 I want the main iteration to stop the timeout and idle function as soon as 
 the new thread is finished and disappears.

You can use g_idle_add() to send a message from the worker to the main thread.

The worker might end like this:

worker_thread( .. )
{
  ..
  final_bit_of_work();
  g_idle_add( thread_done_cb, myself);
  return NULL;
}

and the main thread cleans up and stops like this:

gboolean
thread_done_cb(Worker *worker)
{
  // unlink the main thread from the worker
  g_source_remove(worker-timeout_sid);

  // wait for the worker to finish
  g_thread_join(worker-gthread);

  // all done!
  worker_free(worker);

  return FALSE;
}

Or perhaps you mean something more complicated and I've misunderstood
:( I use semaphores for hairier thread synchronisation problems.

http://en.wikipedia.org/wiki/Semaphore_%28programming%29

I have a set of simple semaphore functions over the g_thread primitives:

https://github.com/jcupitt/libvips/blob/master/libvips/iofuncs/semaphore.c

John
___
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 idle functions

[jcupitt]

Hi Igor,

On Tuesday, 3 July 2012, Igor Chetverovod wrote

 Hi David,
 probably you should use macros:
 gdk_threads_enter ()
 gdk_threads_leave ().


Those macros were used to lock the main gdk thread in earlier versions of
gtk if you wanted to call gtk_ functions from many threads. They are now
deprecated, I think, and you are only supposed to call gtk functions from
the main thread.

They are not necessary for g_idle_add().
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: GTK 2.24.10 memory leak on win32?

[jcupitt]

On 2 July 2012 15:44, Gabriele Greco gabriele.gr...@darts.it wrote:
 I'm posting the code here before creating a bugzilla entry for it since I'm
 not sure I can use g_idle_add to notify a new frame is available without
 freeing the source, that works in linux and in older WIN32 versions and it
 seems correct since g_idle_add() documentation says:

Your code looks a bit strange, but I agree it should work with no
leaks. Probably a bug.

John
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Porting Between Linux and Windows

[jcupitt]

On 16 June 2012 01:33, Eric Tavenner estaven...@gmail.com wrote:
 I am trying to teach myself C++.  My goal is to be able to write code for
 the same app in either Linux or Windows, and compile for both from the same
 code.  Is this possible?

Yes, I have a largish C/C++ program which I can build for Windows and
Linux from the same source code.

I think the difficulty is likely to be in your build system rather
than the source code. I've found building gtk programs on Windows
rather painful. I build WIndows programs on Linux with a
cross-compiler.

 I have Code::Blocks 10.05 on both OSes, (Fedora 17 and Windows 7) on a 64
 bit machine.

I've never used code blocks, perhaps it removes some of the pain from
building on win.

Try a hello world program and see if you can get it to build and run.
For example:

http://www.levien.com/gimp/hello.html

John
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Help with a multi-threaded application. Spot a crash.

[jcupitt]

Hi again Osmo,

On 31 May 2012 17:50, Osmo Antero osm...@gmail.com wrote:
 Jcupitt:
 Ok, g_idle_add() seems to need protection by gdk_threads_enter() and
 leave().
 Ref:
 http://developer.gnome.org/gdk/stable/gdk-Threads.html#gdk-threads-add-idle

That's out of date. g_idle_add() does not need any locking by you.

 can do without. Anyway, an interesting suggestion to use the main-loop to
 run a job-function or thread. This thread have to compete with other
 events like GUI-updates and key strokes.

Yes, you can't use the main thread for much computation, but it's fine
to just service events and do simple GUI changes. All drawing will be
serialised anyway, of course, so serialising slightly earlier will
hardly affect performance.

Additionally, having the guarantee that handlers cannot interfere with
each other makes your GUI code much simpler. You can manipulate your
model without worrying about locks. You only need to remember that
handlers can fire in (almost) any order.

John
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Help with a multi-threaded application. Spot a crash.

[jcupitt]

On 1 June 2012 20:41, Chris Vine ch...@cvine.freeserve.co.uk wrote:
 jcup...@gmail.com wrote:
 That's out of date. g_idle_add() does not need any locking by you.

 I think you may be confusing this with the fact that with glib = 2.32
 it is no longer necessary to call g_thread_init() to make glib thread
 safe, which is of course a completely different issue.

 There is a proposal to deprecate the use of the GDK global lock, but in
 a program which does use it, g_idle_add() does not exempt you from the
 need to invoke the global lock in idle callbacks, either by doing it in
 the idle callback yourself or by calling gdk_threads_add_idle().

I think we must be talking at cross-purposes. g_thread_init() is
becoming optional (it will always be called for you), but you've never
needed to lock either around calls to g_idle_add() and friends, or in
the handler when it is invoked, since it is run by the main loop.

For example, I posted some sample code ages ago (scroll down a bit):

http://old.nabble.com/g_main_loop-and-g_async_queue-td21288177.html

Or have I missed something horribly?

John
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Help with a multi-threaded application. Spot a crash.

[jcupitt]

On 31 May 2012 07:11, Osmo Antero osm...@gmail.com wrote:
 The actual code has also a LockedCounter (mutex controlled) object
 that feeds each thread with a unique sequence number. Only the thread
 with highest sequence number can tick and change the GUI, others will
 simply die away.

I expect you know, but this is not the recommended way to write
threaded GUIs with gtk. It will not be portable.

Best practice is to have a single main GUI thread doing all gtk_*()
calls. Worker threads can send data to the main GUI thread for display
with g_idle_add() and friends. You don't need any explicit locking if
you do it this way, which is nice.

John
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Getting the busy cursor to display.

[jcupitt]

On 10 April 2012 18:33, James Tappin jtap...@gmail.com wrote:
 Thanks for the suggestion. Unfortunately in this case it doesn't help. (I
 have also tried gdk_display_flush and gdk_window_flush, but still the same
 story).

Here's a tiny test program that works for me with gtk2. It just uses:

  gdk_window_set_cursor( win-window, busy_cursor );
  gdk_flush();

J

---
/* compile with
 *  gcc try80.c `pkg-config gtk+-2.0 --cflags --libs`
 */

#include gtk/gtk.h

GdkCursor *busy_cursor = NULL;

void
on_close_clicked (GtkButton * button, gpointer user_data)
{
  GtkWidget *win = GTK_WIDGET (user_data);

  gtk_widget_destroy (win);
}

void
on_open_clicked (GtkButton * button, gpointer user_data)
{
  GtkWidget *win = GTK_WIDGET (user_data);

  gdk_window_set_cursor (win-window, busy_cursor);
  gdk_flush ();
  sleep (1);
  gdk_window_set_cursor (win-window, NULL);
}

GtkWidget *
create_window1 (void)
{
  GtkWidget *win;
  GtkWidget *but;
  GtkWidget *align;
  GtkWidget *hbox;

  win = gtk_window_new (GTK_WINDOW_TOPLEVEL);
  gtk_window_set_default_size (GTK_WINDOW (win), 200, 200);

  align = gtk_alignment_new (0.5, 0.5, 0, 0);
  gtk_container_add (GTK_CONTAINER (win), align);
  gtk_widget_show (align);

  hbox = gtk_hbox_new (FALSE, 2);
  gtk_container_add (GTK_CONTAINER (align), hbox);
  gtk_widget_show (hbox);

  but = gtk_button_new_from_stock (GTK_STOCK_OPEN);
  gtk_box_pack_start (GTK_BOX (hbox), but, FALSE, FALSE, 2);
  g_signal_connect (but, clicked, G_CALLBACK (on_open_clicked), win);
  gtk_widget_show (but);

  but = gtk_button_new_from_stock (GTK_STOCK_CLOSE);
  gtk_box_pack_start (GTK_BOX (hbox), but, FALSE, FALSE, 2);
  g_signal_connect (but, clicked, G_CALLBACK (on_close_clicked), win);
  gtk_widget_show (but);

  return win;
}

int
main (int argc, char *argv[])
{
  GtkWidget *window1;

  gtk_init (argc, argv);

  busy_cursor = gdk_cursor_new (GDK_WATCH);

  window1 = create_window1 ();
  gtk_widget_show (window1);
  g_signal_connect (window1, destroy, G_CALLBACK (gtk_main_quit), NULL);
  gtk_main ();

  return 0;
}
-
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Getting the busy cursor to display.

[jcupitt]

On 10 April 2012 16:58, James Tappin jtap...@gmail.com wrote:
      call gdk_display_sync(gdk_display_get_default())
      call gdk_window_set_cursor(draw_window, busy_cursor)
      call gdk_display_sync(gdk_display_get_default())

My gtk2 program does this with:

gdk_window_set_cursor( window, cursor );
gdk_flush();

If that's any help :( I've not tried gtk3 yet.

J
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: problems understanding gtk3/gdk/cairo interaction

[jcupitt]

Hi Roger,

You should do all drawing in the expose handler and nowhere else.
Don't do any direct drawing in your data hander, instead update your
model and queue an expose event.

On 7 April 2012 02:16, Roger Davis r...@soest.hawaii.edu wrote:
 presumably this includes the GtkDrawingArea widget as well. If there is
 documentation on exactly how this double-buffering works with regard to
 GtkDrawingArea I would be greatly interested in seeing it to figure out if

Here's how it works in gtk2, I think this bit hasn't changed much for gtk3:

* an expose event comes in from X11
* it gets added to the set of pending expose events on your drawing
area -- gtk computes the minimal set of non-overlapping damage
rectangles
* when gtk feels the time is right to update your window, it allocates
a backing pixmap just large enough to hold all damage
* the backing pixmap is filled with the background colour for your widget
* the expose handler is triggered, passing in the backing pixmap as the drawable
* your expose handler draws to that --- you can fill the whole thing,
or you can loop over the (possibly smaller) list of damage rects that
make it up
* gtk clips against the damage outline and writes the new pixels to the display
* the temporary pixmap is deleted

As a former xlib programmer I was slightly horrified when I head about
all this, but it actually works pretty well on non-ancient machines.
My program disables the double buffering and does its own thing for my
main data display, since I don't want the clear to background
behaviour, but I use it everywhere else.

The discipline of only drawing in the expose handler is also helpful.
It forces you to decouple drawing from updating which will make your
performance degrade much more gracefully under load. Instead of
suddenly getting lag when you run out of cycles, you'll just see a
drop in the frame rate.

John
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Making a cursor (cross hair) track between image displays

[jcupitt]

Hi Jim,

On 2 April 2012 17:00, Tilton, James C. (GSFC-6063)
james.c.til...@nasa.gov wrote:
 When I place the cursor in one of the display images, I would like to have a 
 cross hair appear at the cursor location of the window in which the cursor is 
 placed at the location currently pointed to by the cursor. I would ALSO like 
 to have a similar cross hair appear in each of the other associated display 
 images.

Add an event handler to the eventbox and listen for GDK_MOTION_NOTIFY.
You need to use gtk_widget_add_events() and turn on motion events with
GDK_POINTER_MOTION_MASK, gtk will not deliver motion events to windows
by default to try to cut down on unnecessary signalling.

(gtk used to support motion event compression, where it would just
report the most recent position rather than all positions since the
last event delivery, but I think this has been deprecated ... perhaps
an expert knows)

Once you have a motion events, use motion.x and motion.y to get the
mouse position, map this to image space, then map out to the
coordinate space for your other image windows. On those other
displays, draw a floating crosshair at the right spot.

My program does something like this, you're welcome to look at the
source if it might help. Though it's a large, hairy thing and perhaps
not a clear example.

http://www.vips.ecs.soton.ac.uk/index.php?title=VIPS

John
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Making a cursor (cross hair) track between image displays

[jcupitt]

On 4 April 2012 15:37, Tilton, James C. (GSFC-6063)
james.c.til...@nasa.gov wrote:
 Your response is very helpful. The one key question that remains for me is:

 How do I draw a floating crosshair?

You need to do it by hand, unfortunately, though it's not so hard (I think).

The trick (in my opinion) is to have a compositing model for your
drawing areas. Imagine them as a stack of 2D elements which you draw
back-to-front in your expose handler. I wrote a mail on this a month
or so ago, though it was in relation to rubber-banding:



The implementation can be very simple, you don't need to really keep
separate layers around. You could just have a bool in your draw state
for display rubberband and that would be enough. Your expose might
looks like:

expose:
 draw background
 if rubber-band:
   draw rubberband

then in your mouse event handler you could have:

on left-down:
 set rubber-band
 queue draw for pixels touched by rubber band

on motion:
 if rubber-band:
   queue draw for pixels touched by rubber band
   update band position
   queue draw for pixels touched by rubber band

on left-up:
 unset rubber-band
 queue draw for pixels touched by rubber band

The various canvas widgets do basically exactly this for you.

J
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Re:GtkScrolledWindow/GtkViewport question

[jcupitt]

Hi Michael,

Unfortunately I don't think this is easy.

You need o do some kind of crazy hack, like realizing but not mapping
the dialog, measuring the size you get, guessing the amount of chrome
the theme is adding from that, then setting the default window size
and finally mapping. I'd love to be proved wrong though.

Yuk!

John
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Scrollable object problem in GTK 2.20 (Windows)

[jcupitt]

Hi John,

On 6 March 2012 09:38, John Emmas john...@tiscali.co.uk wrote:
 We're using GTK+ v2.20.0 which was current at that time.  The Windows version 
 has a peculiar problem

 The problem affects any scrollable / draggable object but the easiest 
 example to explain is probably a scroll bar.  Let's say I left click on a 
 scroll bar and start dragging it to scroll the attached GTK+ window.  But 
 while the scroll bar is scrolling, my mouse pointer goes outside the relevant 
 window and I release the left mouse button.  As you might expect, the scroll 
 bar stops scrolling.  The problem occurs when I return my mouse pointer back 
 inside the GTK+ window.  It seems like the scroll bar doesn't fully realise 
 that I've let go of it.  So as soon as my mouse pointer returns within the 
 GTK+ window, the scroll bar starts moving again - even though the mouse 
 button isn't pressed any more.

Yes, this (and many other annoying bugs) were fixed for 2.24. You
should see good improvements to copy/paste, drag/drop and filename
encoding support as well. It might even be a bit quicker.

I've just rebuilt my program against 2.24 if you want to test that or
anything else:

http://www.vips.ecs.soton.ac.uk/development/nip2-7.28.0-beta3a-setup.zip

John
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: gtk+ 2.24 installation problems

[jcupitt]

Hi Roger,

On Saturday, 3 March 2012, Roger Davis r...@soest.hawaii.edu wrote:
 I then downloaded those sources and first built glib 2.27.93 with a
 simple './configure --prefix=/usr; make; make install;'. That went fine,

Oh dear, I think you may have broken your system. You've overwritten files
which were being run by your package manager with your own copies. This
will break updates and may well cause other programs you haveinstalled to
start crashing mysteriously. I think you probably need to wipe your
computer and reinstall.

If you want a newer copy of a system library you need to install it and
everything it needs to a separate prefix. I usually build to a directory in
my home area and use environment variables to point the programs that need
the new stuff to this area rather than the system one.

John
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: porting Xlib/Motif apps to GTK+

[jcupitt]

Hi Roger,

I moved a medium-sized (100k lines) application from Motif/X11 to gtk+
a while ago.

As you say, gdk_ is a thin layer over the X11 drawing system, so
converting that is pretty easy. Gdk has quite a few helpers too, eg.
stuff for rendering a 24-bit image to whatever visual the server has,
so you can save some code there. It shouldn't be a huge effort to
port.

A quick port of your GUI code should be fairly easy too. You'll end up
with a not-very-gtk-ish program but, as long as it works, perhaps
that's OK. Prettying it up could be a long-term, low-priority effort.
Gtk has a nice GUI builder which could save you some effort, it'd be
worth experimenting with. You could also consider using Python,
JavaScript or equivalent for the top-level GUI and only using C for
the low-level stuff. Gtk3 seems to be heading very rapidly in this
direction.

I make Windows binaries for my program with a cross-compiler on Linux.
It works really well, I can get a nightly build, including a setup.exe
installer, uploaded automatically to my server. The Windows backend
does not implement all of gdk (the stippling modes are missing, for
example) which can be annoying.

I make an OS X binary on OS X with the Quartz backend. It also works
well, though you end up with a program that looks rather out of place
on the Mac desktop unless you do quite a bit of platform-specific
stuff. Again, it's easy to package automatically as a .dmg containing
a .app.

I used to try to make binaries for the various *nix platforms, but
it's a huge effort and not very reliable. IMO a tarball plus
build-it-yourself instructions is best. If your program is useful the
distributions will pick it up and package it for you. You could
support one distribution (eg. centos6) yourself I guess.

Once you have the thing basically working you could think about more
dramatic rewriting. As you say, switching to Cairo is going to be
necessary at some point.

Good luck!

John
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

progress bar use

[jcupitt]

On Monday, 16 January 2012, Nick Belshaw nick.s.bels...@googlemail.com
wrote:
 I would like to implement a progress-bar to make clear to users stuff is
 happening.
 Specifics involve loading and pre-processing of files. Some files might be
 very big requiring some 10's of seconds to do all stuff.
 At the moment the processing of the files blocks any updates I try to push
 to the progress bar.
 Do I have to go to threads or is there another way of handling this?

A simple solution is to run an iteration of the gtk main loop every few
milliseconds:

http://developer.gnome.org/glib/stable/glib-The-Main-Event-Loop.html#g-main-context-iteration

This may not be possible, of course, depending on the operation you are
performing.

Threads are actually very easy. Launch a thread to do the load and have it
send messages to the main GUI thread as it runs to update your application
about progress. Don't call any gtk stuff from the bg thread. You can do the
whole thing in less then 20 lines of C (probably).

John
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: maybe known, maybe not...

[jcupitt]

Hi Gary,

On 8 January 2012 02:49, Gary Kline kl...@thought.org wrote:
 o am trying to have a run button fork off a new gvim and increase
 a global counter after the first gvim is closed.  my main gtk goes
 dark and nothing responds in this case.  i don't know if every

If you do this:

  system(gvim stuff.txt);

system() will block until the vim exits, and while system() is
blocked, your gtk application will not be handling events (like
repaint).

A simple fix is to append a  so that the vim runs in the background:

  system(gvim stuff.txt );

Now the system() will return immediately and your gtk program can
carry on working while the gvim runs.

If you want something to stop the user launching 100s of gvims you
need to do a bit more work.

John
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: list troubles?

[jcupitt]

On 16 December 2011 08:17, Gary Kline kl...@thought.org wrote:
 i've asked what i thought were straightforeward quwstions recently.
 zip.  am i getting thru?

The last mail I see from you in my mail archive is 2 days ago, saying
thanks to Florian. Were there some more since then?

John
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: GtkTreeView very slow for large lists

[jcupitt]

2011/12/16 John Lindgren john.lindg...@aol.com:
 Lately I have been trying to improve the performance with large
 playlists (i.e. on the order of 100,000 entries).  The one remaining
 problem spot seems to be GtkTreeView.  I am attaching a simple test
 program that creates a GtkTreeView with 3 columns and 100,000 rows.
 With GTK+ 3.2.2, the program uses 29 seconds of CPU time before reaching
 idle, on a 2 GHz Core 2 Duo.  (GTK+ 2.24.8 is considerably better, at 10
 seconds, but still too slow for practical use.)  Is there any way that
 GtkTreeView can be made usable for such long lists?

I remember when the treeview system was being built one of the aims
was to make it (fairly) easy to write your own model.

The idea was that, if your application required it, you could swap the
generic default models for something which linked the view directly to
your program's internal state. For example, a database view could have
a custom model which pretended to have 100m rows and which fetched
chunks of 100 rows at a time from the database as required by the view
as it scrolled. The user would have the illusion of being able to
scroll freely though a huge dataset without having to build a massive
data structure in memory.

You obviously have to turn off auto row and column sizing, since it's
not going to be possible for the treeview to walk the model and
calculate sizes for you. I suppose sorting by column and filtering by
content could work if your index is good enough.

I've never tried implementing a custom model myself and I don't know
if this aim was realized in the final code, but that was one of the
ideas. Google suggests this link, I don't know whether it's any good
though.

http://en.wikibooks.org/wiki/GTK%2B_By_Example/Tree_View/Custom_Models

John
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: GtkTreeView very slow for large lists

[jcupitt]

On 16 December 2011 10:36,  jcup...@gmail.com wrote:
 2011/12/16 John Lindgren john.lindg...@aol.com:
 Lately I have been trying to improve the performance with large
 playlists (i.e. on the order of 100,000 entries).  The one remaining
 problem spot seems to be GtkTreeView.  I am attaching a simple test
 program that creates a GtkTreeView with 3 columns and 100,000 rows.
 With GTK+ 3.2.2, the program uses 29 seconds of CPU time before reaching
 idle, on a 2 GHz Core 2 Duo.  (GTK+ 2.24.8 is considerably better, at 10
 seconds, but still too slow for practical use.)  Is there any way that
 GtkTreeView can be made usable for such long lists?

 I remember when the treeview system was being built one of the aims
 was to make it (fairly) easy to write your own model.

I'm so sorry, I hadn't actually read your code, I now see you're
already doing exactly this.

I did notice that you forgot to put the treeview into fixed-height mode.

Normally, treeview lets rows vary in height (so you can change font
between rows, for example). To make this work, treeview has a idle
task which scans the entire model after it's been realized and
calculates a total height for the view, updating an initial guess.
This is the thing that's causing your terrible performance problems.

On my elderly desktop I see your test window almost immediately, but
it takes 50s for the CPU to drop to zero as it requests the height of
every row. If i add this line after creating the columns:

gtk_tree_view_set_fixed_height_mode (GTK_TREE_VIEW (list), TRUE);

The window appears instantly and there is no background CPU churn.

John
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: how to use hbox?

[jcupitt]

Hi Gary,

2011/12/11 Gary Kline kl...@thought.org:
        well, i've reached a stumbling block.  the app i am working
        on had things is a vertical stack.  so far, there about 6
        rectangles.  the first shows the default title and the
        count: Something like talk.0.txt

Here's a tiny demo program I think I made for someone a while ago. I
doesn't do what you want, but it does have an hbox with two buttons
in. Look down for create_window1().

John
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: GLIB for a webserver

[jcupitt]

Hi Marcelo,

On 10 December 2011 23:05, Marcelo Elias Del Valle mvall...@gmail.com wrote:
    Imagine the following scenario: the application running on my web
 server spends 20k of memory for each concurrent request. If I have
 enough concurrent requests in a way it will consume more memory than,
 let's say, 2Gb available memory, the expected result would be to
 refuse new connections, not restart the application and all current
 requests being handle.

I have 2p to offer on this question too. I use gobject as the basis
for an image processing library that gets used on servers. It's not
quite the same as your problem (and I'm sure it's much less
complicated!) but I think there are some similarities.

In my opinion, this is part of a general question of resource envelopes.

There are many resources my library has to manage apart from memory:
for example, it has to work with images comprised of many separate
files, sometimes up to 5,000 files to make a single image. Many *nix
systems have a limit of about 1,000 simultaneously open files, so my
library has to keep track of open files and if a request comes in for
a section of image not currently mapped, has to consider closing some
old files before attempting to open a new one.

It's not practical to track all memory allocations but my library does
track pixel buffers. If total pixel buffer usage gets near to a limit
set by the user it will start to free old buffers before creating new
ones. It also tries to limit the number of simultaneous threads that
can be active to a user-specified number. I've not really looked at
GPU usage yet but I imagine there will have to be some logic to
constrain that somehow as well.

Anyway, in my opinion, something like a web or image server needs to
be told a resource envelope it should try to run within and needs some
internal mechanism to manage requests which might push the system
outside that range. If you've got to the point where malloc() is
failing, your server is already as good as dead, unfortunately.

John
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: a couple questions...

[jcupitt]

Hi Gary,

On 8 December 2011 01:00, Gary Kline kl...@thought.org wrote:
        i'll need a play button and callback that invokes, say,
        espeak -f on that file.

Make a play button with gtk_button_new_from_stock(GTK_STOCK_PLAY):

http://developer.gnome.org/gtk3/stable/GtkButton.html#gtk-button-new-from-stock

To put the button to the right of the label, make an hbox and append to that.

http://developer.gnome.org/gtk3/stable/GtkHBox.html

Attach a callback in the same way as the inc and dec one you have
already and run system(espeak -f %s, myfile) from that.

John
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Focus behaviour on widget derived from a gtkentry

[jcupitt]

On 7 December 2011 09:16, Geert Janssens i...@kobaltwit.be wrote:
 I am now having problems to set the focus on this widget programmatically. In
 this particular use case, the widget is added to a GtkAssistant, and during
 the prepare of the page showing this widget, I call a gtk_widget_grab_focus on
 it. This does nothing.

I remember struggling to get focus working in my widgets too. In my
case the problem turned out to be forgetting to set the CAN_FOCUS flag
in _init(). Have you tried this?

  http://developer.gnome.org/gtk/2.24/GtkWidget.html#gtk-widget-set-can-focus

Needs to be called at some point for every widget object that can take
focus. Though perhaps the parent class should do this for you? Maybe
worth a try anyway.

John
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: obtain parent from menu callback

[jcupitt]

Hi Steve,

On 26 November 2011 08:27, Steve . iteratio...@gmail.com wrote:
 I've got a GtkItemFactoryEntry popup menu, the menu pops up from a button
 press event using gtk_menu_popup.

I found the best solution was to make my own menus and use quarks set
on them to link them to their context. I build the menus in my
class_init like this:

  pane = rowview_popup_menu = popup_build( _( Row menu ) );
  popup_add_but( pane, _( _Edit ), POPUP_FUNC( rowview_edit_cb ) );
  menu_add_sep( pane );
  popup_add_but( pane, GTK_STOCK_DELETE, POPUP_FUNC( rowview_remove_cb ) );

When you build a widget that needs one of these right-click menus you
link the widget to the menu with (rview is any client data, but in
this case is the underlying model):

 popup_attach( widget, rowview_popup_menu, rview );

and callbacks look like this:

 static void
 rowview_edit_cb( GtkWidget *menu, GtkWidget *button, Rowview *rview )
 {
do_stuff( rview );
 }

Source here, along with some other stuff. It's only 100 lines or so.

  https://github.com/jcupitt/nip2/blob/master/src/gtkutil.c

John
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: gtk and linux

[jcupitt]

Hi Craig,

On 3 November 2011 08:07, Craig craigbakal...@verizon.net wrote:
 Is there a list of linux flavors like Ubuntu, KDE, Red Hat... that
 include or don't include gtk? And, let's say that a type of linux

I think all will include gtk, either as part of the standard install
or available via the package manager. To install from the package
manager you just need to type gtk and click the install button
(details vary a bit).

Even this step is usually done for you: if you install a program which
needs gtk, gtk will be automatically installed for you.

 doesn't include gtk, how difficult is it for an average computer user to
 install gtk (on a scale of 1 to 10)?

Building and installing the whole of gtk from source requires a lot of
skill and work, but I think no regular user would ever need to do
this.

John
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: GLib with Flex and Bison

[jcupitt]

On 3 October 2011 01:37, Craig craigbakal...@verizon.net wrote:
 I am about to try to use GLib in a Bison file, mainly calling
 functions on the GList Object.  I have never tried this before.  Will it
 work?  Are there any threading issues?

Bison and flex don't use threads, so no, there's no issue there, it works fine.

John
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Valgrind questions

[jcupitt]

I posted this the last time this subject came up (twice last year, I
think), but I made this valgrind suppression file for my project:

 http://www.vips.ecs.soton.ac.uk/development/nip2.supp

Run with:

$ export G_DEBUG=gc-friendly

This makes Glib clear certain memory areas after using them, too.

$ export G_SLICE=always-malloc

This completely disables the magazine and slab allocator in Glib,
and makes it use plain malloc()/free() instead.

$ valgrind --suppressions=/home/john/nip2.supp \
  --leak-check=yes \
  myprog ...  myprog-vg.log 21

With this, I get no reported leaks in my huge (200,000 lines of C)
application on Ubuntu with current gtk+. There are some comments in
the file explaining what the various bits do. No doubt I've made some
errors :-( but perhaps it might be useful.

John
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Valgrind questions

[jcupitt]

Hi Tom,

On 20 September 2011 11:38, Thomas Harty t.har...@physics.ox.ac.uk wrote:
 Running like that, I still get quite a few leaks detected by valgrind. Some 
 of them are created by g_type_add_interface_static, which looks like another 
 type_init leak, which we can safely ignore. So, I've added the following to 
 the suppression file to kill these.

Ooop, thanks. I hadn't realised but I'd not updated the version on the
website for a while. I've put my current one up now and it includes a
thing for g_type_add_interface_static(), as you also found.

I've added a few more since the last update as well. There's an
annoying libz one which it now hides, and a couple of uint ones in
gettext.

With this version I get a clean run from hello.c with gtk+-2.0, except
for a single report from the theme engine, which I don't care about.

I've not tried 3.0 yet, I have some porting work to do before I get
stuck into that.

John
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Detecting Ctrl Esc in GTK app

[jcupitt]

That lets you detect ctrl-esc anywhere on the desktop. If you only
need to detect crtl-ecs within your window you can just set
ControlEscape as an accelerator, see:

http://developer.gnome.org/gtk3/stable/gtk3-Keyboard-Accelerators.html

On 30 August 2011 06:33, czk czon...@gmail.com wrote:
 try gdk_window_add_filter or gtk_key_snooper_install

 2011/8/30 Andrew Wood a@me.com

 Is there a way to regiser a handler function which will be called whenever
 the user presses Ctrl-Esc in a GTK app?

 Thanks

 __**_
 gtk-app-devel-list mailing list
 gtk-app-devel-list@gnome.org
 http://mail.gnome.org/mailman/**listinfo/gtk-app-devel-listhttp://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

___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Detecting Ctrl Esc in GTK app

[jcupitt]

Hi Andrew,

You can add an accelerator to a window and it'll be called when that
key combination is pressed. It doesn't need to be associated with a
widget.

However I think it's generally considered good form to have a menu
item somewhere with the accelerator as a shortcut. That way the user
can discover your handy keypress and get some idea what it does.

John

On 30 August 2011 14:03, Andrew Wood a@me.com wrote:
 Thanks for the tip.  Can accelerators only be used with menu items, only Ive
 just tried doing it by linking it to the clicked signal on a (hidden)
 GtkButton but it doesnt work?

 My idea was when the key combo was pressed the accelerator would emit a
 clicked signal on the button and the buttons handler would then be called.

 On 30/08/11 09:52, jcup...@gmail.com wrote:

 That lets you detect ctrl-esc anywhere on the desktop. If you only
 need to detect crtl-ecs within your window you can just set
 ControlEscape as an accelerator, see:

 http://developer.gnome.org/gtk3/stable/gtk3-Keyboard-Accelerators.html

 On 30 August 2011 06:33, czkczon...@gmail.com  wrote:

 try gdk_window_add_filter or gtk_key_snooper_install

 2011/8/30 Andrew Wooda@me.com

 Is there a way to regiser a handler function which will be called
 whenever
 the user presses Ctrl-Esc in a GTK app?

 Thanks

 __**_
 gtk-app-devel-list mailing list
 gtk-app-devel-list@gnome.org

 http://mail.gnome.org/mailman/**listinfo/gtk-app-devel-listhttp://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


 ___
 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

Re: Detecting Ctrl Esc in GTK app

[jcupitt]

On 30 August 2011 15:22, Andrew Wood a@me.com wrote:
 How would you link it directly to the window then rather than to a widget?

You can link a GClosure to a key press with this:

http://developer.gnome.org/gtk3/stable/gtk3-Keyboard-Accelerators.html#gtk-accel-group-connect

Parse ctrlesc to key/mod with

gtk_accelerator_parse( ctrlesc, key, mods );

(I've not actually done this, I always use a widget, but I think it should work)

John
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: gtk assistant any good?

[jcupitt]

On 19 August 2011 16:13, Michal Suchanek hramr...@centrum.cz wrote:
 https://bugzilla.gnome.org/show_bug.cgi?id=656816

Could you explain the combobox navigation bug a little more? It seems
to work for me.

If I open GIMP preferences (for example) and tab to one of the
comboxboxes there I can use up/down arrows to change the value (or the
scroll wheel, which I don't like, but that's another question) or
left/right to move to other widgets.

If I pop the combo open with space or enter I can change the value
again with up/down (though not with scroll, confusingly). Pressing
space or enter accepts my change, esc cancels it. Once the popup is
closed I can again use tab and arrows to navigate the dialog.

Are you expecting tab and left/right while the combo is open to close
the popup and navigate? I don't think many GUI toolkits have this
behaviour.

John
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Questions on creation of glyphs

[jcupitt]

Hi Ferdinand,

 I want to create a small set (say
 5-10 symbols) of custom glyphs and want these symbols to be
 part of the alphabet of a fictional language. I also want to
 assign unused unicode values to these symbols and want these
 symbols to appear on my application as well as the terminal
 when I press specific keys.

Here's how font rendering works in gtk on linux (I hope I have this right):

- gtk uses Cairo to draw on the screen
- Cairo uses Pango to do draw text
- Pango does layout and final rendering, but uses freetype2 to do the
rasterisation from the font file
- freetype2 uses fontconfig to find font files from names like sans 12

Other platforms are slightly different. On Windows and OS X, pango
uses the host drawing system to rasterise glyphs.

So to answer your question, you need to make a new font containing
your new glyphs. There are quite a few font editing systems, I've not
used any myself but I understand fontforge is popular:

http://fontforge.sourceforge.net/

Take an existing open font and add your new glyphs somewhere.

Next, install the font, details will vary with your system. On linux
you can bundle the font with your app and use the fontconfig env vars
to add it to the search system, l I think.

Finally, depending on where you added it to the font, you should be
able to type your characters with various key combinations. You can
also edit key maps I think, though I've never tried.

John
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: I Miss Using My Anjuta IDE

[jcupitt]

On 11 March 2011 12:23, Craig Bakalian craigbakal...@verizon.net wrote:
 I don't know if this is the right place to complain about this, but ever
 since I update to 11.04 I have not been able to use Anjuta IDE.

Hi Craig,

11.04 is still in development and is not finished. You should expect
many broken packages and non-functional programs. You can report
issues you find on launchpad and I'm sure they will be very grateful
for your help.

For maximum reliability (as far as Ubuntu offers that anyway, hehe),
you should stick to the LTS (Long-term support) releases. 10.04 is the
current one. It is missing a few very recent features though, and if
you really need those, you should use 10.10, the current stable
release.

John
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: custom gtkwidget destruction

[jcupitt]

On 24 February 2011 22:57, James Morris jwm.art@gmail.com wrote:
 I am wondering if in this case, as there is no extra data to destroy,
 is it really necessary for me to specify the destroy function?

 Put another way, by specifying the destroy function, am I duplicating
 by 'over-riding' the 'default destructor' and/or possibly omitting
 things which should be done?

You only need to define destroy() if you want to do something on
destroy. It can be handy for debugging though, I often have empty
virtual methods with #ifdef DEBUG printfs in.

You chain up to your parent classes destroy function, so nothing is
being omitted, don't worry.

 With regard to the docs, finalize and dispose are mentioned. Are these
 only required if I explicitly need deeper control over the destruction
 (of - in this case - the widgets my widget uses)?

They all have slightly different meanings. My understanding is:

  destroy

This means: every other object holding a ref to me should drop it.
It's used to tell OTHER objects that you are going, not to do any
destruction yourself.

For example, when you can call gtk_widget_destroy() on a menu item, it
does not directly destroy the item. Instead, the items emits a
destroy signal, the enclosing menu sees that and drops the ref it
holds to the item, the item's refcount hits zero, and the item is then
dispose()d.

So ... destroy is generally something you listen out for for any
objects you hold references to, not something you implement yourself.

  dispose

This is called when an object's refcount hits zero. This is where you
should drop any refs you hold to other objects. Note that dispose can
run several times, since objects can have refcounts that go back up
again from zero, so be careful not to double-free anything.

  finalize

This is called just before the object's memory is freed. It is called
exactly once and is a good place to free any strings or other small
structures the object holds.

John
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Viewport diagonal scrolling redraw

[jcupitt]

On 16 February 2011 04:48, Rendaw ren...@zarbosoft.com wrote:
 As a side note, does gdk_window_process_updates() preserve mouse motion
 events when the MOTION_HINT mask is set?  I also had motion event queuing
 problems (I would stop moving the mouse but the screen would continually
 redraw for a few seconds until it had caught up) before I moved the
 gtk_adjustment_set_value()'s out of the motion handling code and into a
 g_idle_add callback.

I don't know how to get silky diagonal scrolling easily, but I can
help here (I think). The solution I found was to calculate all mouse
movement relative to the root window, not the window being scrolled.

In the motion event, there are a couple of fields called x_root and
y_root. Record these on button down together with the scroll position
of the underlying window, then during motion, scroll the window to the
position found by subtracting the start x_root from the current x_root
plus the original x.

This makes these feedback effects (which can be bizarre and horrible)
impossible.

John
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Memory leaks

[jcupitt]

I posted this the last time this subject came up (twice last year, I
think), but I made this valgrind suppression file for my project:

 http://www.vips.ecs.soton.ac.uk/development/nip2.supp

With this, I get no reported leaks in my huge (200,000 lines of C)
application on Ubuntu with current gtk+. There are some comments in
the file explaining what the various bits do. No doubt I've made some
errors :-( but perhaps it might be useful.



On 9 February 2011 17:01, James Morris jwm.art@gmail.com wrote:
 On 9 February 2011 16:10, Michael Cronenworth m...@cchtml.com wrote:
 James Morris wrote:

 How does one gain this mysterious tool for Linux?

 It's called Google. There's a web page[1] that details how to setup valgrind
 to debug gtk/glib apps and even a preliminary suppression file.

 [1] http://live.gnome.org/Valgrind

 That's called patronising. I have been there already. What good is a
 work in progress when the progress stopped over two years ago?

 Not only do we have to write our own code, we have to put work into
 making other peoples code ignore the errors in other peoples code so
 we can see the errors in our own code. It's a bloody outrage!
 ___
 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

Re: Bring a widget to the foreground

[jcupitt]

On 7 January 2011 11:33, John Emmas john...@tiscali.co.uk wrote:
 Although I can now change the button's label font, the new font seems to be 
 quite transitory and certain operations seem to reset it.  For example if 
 (later) I change the label's text (e.g. if it currently says This message 
 and I change it to say That message) the font will immediately revert back 
 to whatever it was when the button got created.

I think the simplest solution is to use pango markup and set the text
and font together. It seems to me to be the cleanest way to do it.

John
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Bring a widget to the foreground

[jcupitt]

I agree, I was just trying to keep it simple.

On Tuesday, 4 January 2011, Jaroslav Šmíd jardas...@gmail.com wrote:
 Don't do that. Fixed size buffers are evil for string formatting. You better 
 use g_strdup_printf even though this would lead to reallocations. But much 
 better then end up with cropped text.

 On 01/02/2011 10:00 PM, jcup...@gmail.com wrote:

 On 2 January 2011 15:39, John Emmasjohn...@tiscali.co.uk  wrote:

 To be honest, all I'm trying to do is create a button whose label font can be 
 changed on demand.  I've managed to achieve it by using an empty button with 
 a label on top, except that the label doesn't always stay on top!


 Ah, OK, yes, there's a much simpler technique.

 Try something like this:

    txt = some text to display;
    font = sans 12;

    snprintf (button_text, 256,
       span font_desc=\%s\ size=\medium\%s/span,
       font, txt);
    gtk_label_set_markup (
      GTK_LABEL (gtk_bin_get_child (GTK_BIN (button))),
      button_text);

 Assuming 'button' is a regular gtk button containing a label.

 John
 ___
 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

Re: Bring a widget to the foreground

[jcupitt]

Hi John,

On 2 January 2011 13:17, John Emmas john...@tiscali.co.uk wrote:
 As an example, let's say I wanted a button whose label needed to be at the 
 top of the button, rather than in the centre.  I use either a separate label 
 or a graphical image to achieve this.

You can just set the alignment on the label to get them to display at
the top of the button.

 Each time the button gets pressed I need to make sure that it doesn't obscure 
 the other widget.  So having done whatever gets done in response to the 
 button press, I need to bring the other widget to the foreground again.  Does 
 GTK+ have a method available for achieving this?

GTK does not officially support overlapping widgets. However, you can
sort-of do it by putting groups of widgets into eventboxes and putting
those boxes into a layout. To move to the front, ref the box, remove
it from the layout, add again, and unref. It would probably work with
other containers too. I hope I've understood what you want.

John
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Bring a widget to the foreground

[jcupitt]

On 2 January 2011 15:39, John Emmas john...@tiscali.co.uk wrote:
 To be honest, all I'm trying to do is create a button whose label font can be 
 changed on demand.  I've managed to achieve it by using an empty button with 
 a label on top, except that the label doesn't always stay on top!

Ah, OK, yes, there's a much simpler technique.

Try something like this:

  txt = some text to display;
  font = sans 12;

  snprintf (button_text, 256,
 span font_desc=\%s\ size=\medium\%s/span,
 font, txt);
  gtk_label_set_markup (
GTK_LABEL (gtk_bin_get_child (GTK_BIN (button))),
button_text);

Assuming 'button' is a regular gtk button containing a label.

John
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Cancel construction of GObject

[jcupitt]

On 27 November 2010 11:14, Jaroslav Šmíd jardas...@gmail.com wrote:
 Is it possible to cancel construction in gobject-derived class?

I don't think so. Lots of code (including code inside gobject) assumes
that g_object_new() always returns a valid pointer.

I handle this by having a more complicated init system. I have
g_object_new() just doing basic mem alloc and setting up a start
state, then I let parameters be set, then I have a virtual function
called build(), which can fail, which constructs the full object.

So make a subclass of GObject for your application (MyObject?) with a
can-fail init system and make all your classes derive from that.

My code is here, if you're curious:

http://vips.svn.sourceforge.net/viewvc/vips/vips7/trunk/libvips/iofuncs/object.c?view=markup

http://vips.svn.sourceforge.net/viewvc/vips/vips7/trunk/libvips/include/vips/object.h?view=markup

John
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Memory management in gtk

[jcupitt]

On 19 October 2010 06:22, Vishak V. Kurup vishak.ku...@nestgroup.net wrote:
 I am having a small problem related to GTK. My application is having
 around 15 windows.  When I start my application and check the memory
 usage using top utility it shows around 19MB. When a new window is
 created it may increase upto 22 MB (varies each time). And after I
 destroy the new window my memory is not getting reduced. Could anyone
 please tell me why memory usage is not decreased even after I destroy
 widget.

top is not the best way to see memory use of a program, or to check for leaks.

When a program starts, the system hands over a large chunk of ram to
the memory library. This library then hands out the memory to the
program in small bits as the program asks for it. If the chunk is
exhausted, the library asks for more memory from the OS. When memory
is freed, the memory library does not return it to the host operating
system (with certain strange exceptions), instead it keeps it around
for reuse. As a result, you will (almost) never see the memuse fall,
as reported by top, for any program.

To check for leaks, you need to use a special tool. In my opinion, the
most useful under Linux is valgrind. Run it with something like:

export G_DEBUG=gc-friendly

This makes Glib clear certain memory areas after using them, too.

export G_SLICE=always-malloc

This completely disables the magazine and slab allocator in Glib,
and makes it use plain malloc()/free() instead.

valgrind --leak-check=yes \
  myprog ...  myprog-vg.log 21

You will get some false positives. I have a suppressions file here:

  http://www.vips.ecs.soton.ac.uk/development/nip2.supp

Which hides all the false positives from the gtk stack.

John
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: GTK+ vs GTK 2 vs GTKMM

[jcupitt]

On 14 September 2010 15:48, Dmitry Kruglov i...@midisa.org wrote:
 5. I want to work with the database and use the Grid in different
 windows: http://gtkextra.sourceforge.net/

I think you'll find that the standard gtk treeview widget is better
for this. For example, if you use Rhythmbox, the main display of songs
is done with this widget.

It sounds like gtkmm would fit your checklist. Try making a test
program and see if it seems OK.

If you don't need to do a lot of CPU-intensive processing, you could
also consider PyGtk. Development is very fast and easy, and
performance is generally fine. For example, the Ubuntu Software Centre
is implemented in PyGtk.

John
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: porting gdk - cairo

[jcupitt]

On 11 August 2010 02:14, Allin Cottrell cottr...@wfu.edu wrote:
 rid of GdkGC.  I'd imagine that the effect I'm after is something
 that many GTP apps have need of, and it's trivial to achieve with
 the GDK API.

I've found that XOR rubber banding is quite hard to do reliably in
gdk.  The problem I think is that you are using the screen pixels to
store part of the state, and that gets hard to coordinate between the
various things that can affect the display.

I had mouse movements triggering rect moves, mouse moves with a button
held down causing background scrolling of the canvas, and mouse moves
over other screen objects triggering highlight effects. With all these
things going on at once it became very difficult to get XOR rubber
bands to not leave annoying trails as they moved.

I switched to an update-model / invalidate-widget / redraw-on-idle
scheme as Dov suggests and I got prettier updates with less
complication. Since input and output are decoupled, it'll scale more
gracefully between slower and faster machines as well, which is nice.

Anyway, my 2p.

John
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: how to implement my own window decoration

[jcupitt]

2010/7/28 c-aries babyari...@gmail.com:
 Hi all. Can someone show me how to implement my own window decoration?
 Such as removing the title and resize buttons, adding background picture in
 the window decoration.

You can use gtk_window_set_decorated() to turn off the usual window decorations:

  
http://library.gnome.org/devel/gtk/stable/GtkWindow.html#gtk-window-set-decorated

You can then draw whatever you like at the top of the window. You'll
need to implement drag / iconize / close yourself though, and the
titlebar you draw probably won't match the user's theme.

John
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: GTK/GDK equivalent to UpdateWindow() ?

[jcupitt]

On 4 July 2010 16:50, John Emmas john...@tiscali.co.uk wrote:
 operation being processed.  Neither of those is quite what I need.  I'm 
 looking for is a function that will force a window to be repainted at once, 
 before any other pending events get processed.

There's gdk_window_process_updates():

http://library.gnome.org/devel/gdk/stable/gdk-Windows.html#gdk-window-process-updates

But I'm not certain is does much any more. Generally, you just paint
in the expose handler and nowhere else, and calls like this are
unnecessary.

What are you trying to achieve? Perhaps there's some other way to get
the effect you need.

John
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Brainy person needed for scrolling canvas problem!

[jcupitt]

Hi John,

On 2 July 2010 16:04, John Emmas john...@tiscali.co.uk wrote:
 Now for the problem  when in playback mode, I'd like the viewport to 
 have a vertical now line (similar to the play head on a tape recorder).

I doubt I count as brainy, but one simple technique would be to render
the screen in layers.

You would have an offscreen pixbuf with the current view, minus the
now line. On an expose event, you copy the relevant parts of the
offscreen buffer to the display, then draw the now line over that.
Because of gtk's double-buffering, this will be flicker-free.

To scroll 100 pixels to the right, you blit your offscreen buffer by
100 pixels, draw just the objects in the exposed area of pixels, then
queue an expose for the whole widget.

This means you have to handle all the scrolling yourself, but it's not
so hard. Just connect your 'scroll by x pixels' function to the adjust
signal on a scrollbar.

If you need more speed (though I think it'd be quick enough on most
machines) you'd probably need to use opengl.

John
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Translating co-ordinates from local to screen space

[jcupitt]

On 11 June 2010 11:50, Matthew Allen l...@sydneyband.com.au wrote:
 I'm trying to translate co-ordinates from local widget space into screen
 space and back again. Is that possible with GTK?

You can use _get_allocation() to get the size and position of a widget
within it's parent:

http://library.gnome.org/devel/gtk/stable/GtkWidget.html#gtk-widget-get-allocation

There's also a more general thing that will translate between any two
widgets which share a common ancestor:

http://library.gnome.org/devel/gtk/stable/GtkWidget.html#gtk-widget-translate-coordinates

If you're trying to turn mouse x/y into widget x/y, I think that
should be done for you, as far as I know.

John
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Top down layout

[jcupitt]

On 9 June 2010 06:16, Matthew Allen l...@sydneyband.com.au wrote:
    GtkWidget *vp = gtk_viewport_new(GTK_ADJUSTMENT(h), GTK_ADJUSTMENT(v));
    if (vp)
    {

On a tiny style point, by design gtk cannot get out of memory errors.
You can set a handler to run on out-of-mem, and allocations you
perform yourself with g_try_malloc() can test for oom, but no part of
gtk either tests, or can fail.

The reasoning (as I understand it) is that oom conditions are almost
impossible to recover from in GUI programs. If you can't allocate
enough memory for a new widget (somewhere around 100 bytes), your
chances of being able to save state or even display a warning are
almost nil.

You can set an oom handler and perhaps, depending on your app, there
are some caches you can drop safely without disturbing the GUI. Even
that is a little unlikely :-( The oom can be triggered by almost
anything and it's hard to be certain you don't have races.

John
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: gdk_draw_image() not working?

[jcupitt]

On 8 June 2010 23:22, Tomasz Sterna to...@xiaoka.com wrote:
 I am using the following code (stripped):

  8 
 drawing = gtk_drawing_area_new ();
 gc = gdk_gc_new (drawing-window);
 image = gdk_image_new (GDK_IMAGE_FASTEST,
                       gdk_visual_get_system(), w, h );
 paint_image (image-mem); // custom painting function
 gdk_draw_image (drawing-window, gc,
                image, 0, 0, 0, 0, -1, -1 );
  8 

 and I don't see my image on screen :-(

You need to call gdk_draw_image() in your expose handler. Something like:

drawing = gtk_drawing_area_new ();
g_signal_connect (drawing, expose, my_expose, my_state);

static gint
my_expose (GtkWidget *widget, GdkEventExpose *event, my_state)
{
  GdkRectangle *rect;
  int i, n;

  gc = ...

  gdk_region_get_rectangles( event-region, rect, n );
  for( i = 0; i  n; i++ ) {
image = ... build the area at: rect[i].x, rect[i].y,
rect[i].width, rect[i].height
gdk_draw_rgb_image (widget, gc, ... );
  }
  g_free( rect );

  return( FALSE );
}

Though that's a bit old-fashioned now, I think all the cool kids use Cairo.

John
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Top down layout

[jcupitt]

On 9 June 2010 12:40, Matthew Allen l...@sydneyband.com.au wrote:
 the problem I have now is that because I'm catching the configure-event
 on the GtkWindow (to adjust my internal position/size variables) the
 scrollview doesn't update to the client area of the window as I resize it.

That's an easy one (phew): all _event signals are bool-valued. Return
TRUE to indicate that you've handled the event, return FALSE to
propagate further.

http://library.gnome.org/devel/gtk/stable/GtkWidget.html#GtkWidget-configure-event

John
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Good view on windows

[jcupitt]

On 25 May 2010 16:20, Adam Chrapkowski adam.chrapkow...@gmail.com wrote:
 I have written a GTK+ based application and I need to redistribute it on
 Windows (I'm Ubuntu user).

I'd add another bit of advice to Tor's excellent mail: cross-compile
from linux with mingw. It really is much faster and simpler than
compiling on Windows. You can use Wine to test your program.

nsis runs on linux too, so you can build a handy .exe installer as
well if you want, all from the same build script.

John
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: multithreaded gtk app

[jcupitt]

Hi,

2010/1/20 Manu TM manutm...@gmail.com:
 I'm having troubles debugging a multithreaded gtk app I made.

 Basically, the app looks like this:

You need to post a complete small program that people can compile and run.

Though from your fragment it doesn't look like you are using threads,
just timeouts. ARe you sure you want a multi-threaded GTK application?

John
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: menu bitmaps on 64-bit build

[jcupitt]

Hi Garth,

2010/1/14 Garth's KidStuff garthskidst...@gmail.com:
 I build the same source on both 32-bit and 64-bit machines running various
 versions of ubuntu (64-bit is only 9.04 and 9.10) and on the 32-bit builds I
 see the menu item bitmaps, but on 64-bit, I don't.

Ubuntu 9.10 has removed menu icons in an attempt to reduce visual clutter.

You can turn them back on with System / Preferences / Appearance /
Interface / Show icons in menus.

John
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: How to remove MenuItem from Menu?

[jcupitt]

2009/10/22 Lars Wirzenius l...@liw.fi:
 * when you create and add the menu item, keep a reference to it

 * when you remove it, call the function to remove a child from the
 container; with the Python binding's it's just the .remove(menuitem)
 method, but in C I guess it's gtk_container_remove.

Actually, you can just search for the item and destroy it with
gtk_widget_destroy(). _destroy() will automatically unlink widgets
from their containers.

John
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: How to remove MenuItem from Menu?

[jcupitt]

2009/10/21 Peter Daum gator...@yahoo.de:
 There are several functions to dynamically change/reorder menus,
 but I couldn't find or figure out a way how to remove a certain
 item from a Menu. Is this possible? How?

 (I tried some strange things like calling item-destroy
 and was not surprised that it didn't work ...)

You can just use gtk_widget_destroy(item), I believe. Though I
generally just destroy and rebuild the whole menu for safety.

John
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Resizing

[jcupitt]

2009/10/7 John Coppens j...@jcoppens.com:
 - I have a (top-level) window, with a vbox, then a vpanel, a frame, an
 'alignment' and a table (listed in the order of nesting).

 When I change something in the table, which makes it wider, the table
 gets wider, wider than the frame, which doesn't resize, and neither does
 the rest upwards in the hierarchy.

 I understand that normally the size allocation starts from the window
 down. How do I resize from de table up?

You need to put stuff inside something which can get larger. I'd put a
scrolledwindow inside the vpane, then the frame and the table inside
that.  This will mean if the table gets bigger than the vpane, it'll
get scrollbars.

John
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: latest glib and gtk for Windows?

[jcupitt]

2009/4/21 Gabriele Greco gabriele.gr...@darts.it:
 About this issue, I've been able to build the whole win32 GTK
 environment only on WIN32 mingw since all the configure process relies
 too much on pkg-config to be usable from a cross-compiler (we usually
 build all of our apps on linux with the mingw crosscompiler
 distributed with all the debian derived distro).

I build win32 gtk and apps on a cross compiler (ubuntu mingw) and it
seems to work fine with no manual hackery required. What problems were
you having?

John
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Rendering lines

[jcupitt]

2009/4/13 Paolo pra...@gmail.com:
 I'm drawing lines into GtkDrawingArea through gdk_draw_line function. The
 results is good, but not enough. How can I increase the rendering?

Do you mean make it faster'? You could try:

- disable gtk's automatic double buffering
- try another X driver (there's often a choice for your hardware)
- use OpenGL instead
- draw to an offsceen window then blip the finished drawing on to the
screen in a single ROP
- speed up the thing you're using to generate the coordinates
- are you using Windows? the gdk backend on windows is not built for high speed

It depends on the platform and what you're trying to accomplish.

John
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

signals returning results

[jcupitt]

Hi all,

I'd like to make a signal that can return a bool result. I've defined it with:

progress_signals[SIG_UPDATE] = g_signal_new( update,
G_OBJECT_CLASS_TYPE( class ),
G_SIGNAL_RUN_FIRST,
G_STRUCT_OFFSET( ProgressClass, begin ),
progress_update_accumulate, NULL,
nip_BOOLEAN__INT_INT,
G_TYPE_BOOLEAN, 2,
G_TYPE_INT,
G_TYPE_INT );

but then at runtime I get the message:

(nip2:73155): GLib-GObject-WARNING **: gsignal.c:1287: signal
Progress::update has return type `gboolean' and is only
G_SIGNAL_RUN_FIRST

Checking the source, the warning comes from:

  if (return_type != G_TYPE_NONE 
  (signal_flags  (G_SIGNAL_RUN_FIRST | G_SIGNAL_RUN_LAST |
G_SIGNAL_RUN_CLEANUP)) == G_SIGNAL_RUN_FIRST)
{
  g_warning (G_STRLOC : signal \%s::%s\ has return type `%s'
and is only G_SIGNAL_RUN_FIRST,

Why can't I make a RUN_FIRST signal that returns a boolean? I can't
see anything in the docs about this.

John
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Continuous variable updation in a text box

[jcupitt]

2009/3/10 Adeel Malik adeelmali...@yahoo.com:
 I intend to monitor the variable's value (acquired via data acquisition 
 hardware) at a rate of around 1,000 times per second.
 I haven't used textboxes before in GTK+. Could anyone suggest how to update 
 the value of a variable in a textbox etc., at this rate.

You'll burn up all of your CPU and you probably still won't reach
1,000 updates a second. No one can read numbers that quickly, and your
display will only update at (maybe) 60 frames a second anyway.

I would suggest updating at 10 frames per second (quite fast enough
for any human) and showing the average of the last 100 measurements.
You could add a second and third label showing the minimum and maximum
values in the last 5 seconds if you're keen not to miss any peaks.

I would have a background thread to do the data capture and analysis,
then have this thread signal the GUI to update 10 times a second.

For example:

http://www.mail-archive.com/gtk-app-devel-list@gnome.org/msg09058.html

John
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list