Re: GitLab CI runners for non-Linux systems

[Ross Burton]

On 6 June 2018 at 15:38,  wrote:

> Le mercredi 06 juin 2018 à 15:33 +0100, Ross Burton a écrit :
>
> On 18 May 2018 at 10:52, Philip Withnall  wrote:
>
> tl;dr: Want to provide us with a GitLab CI runner for a non-Linux
> platform?
>
> There’s been a surge of interest recently, from various directions, in
> getting GLib better tested on non-Linux architectures. This is great,
> and we’ve got various people to thank for doing the thankless work of
> porting and testing. Particularly:
>  • macOS: Ryan Schmidt, Patrick Griffis, Michael Lauer, John Ralls
>  • Windows/MinGW/MSYS2: LRN, Christoph Reiter, Xavier Claessens, Chun-
> wei Fan
>  • Android: Xavier Claessens
>  • *BSD: Ting-Wei Lan
>
>
> Would you be interested in extending the Linux coverage to include
> cross-building to proper Linux?
>
> https://gitlab.gnome.org/rburton/glib/-/jobs/42792 is a bit hacky but
> demonstrates that using a Yocto-built toolchain with autotools, glib will
> cross-build successfully to aarch64.  Next step is to try with Meson, but
> auto* was easier as we exercise that in our own QA.
>
>
> We already have android aarch64 and mingw64 cross build on our linux
> docker images using meson. More cross build could be added of course.
>

How about mips64 proper Linux (not Android).  Actually, MIPS64/musl would
be an interesting combination given the patches we've previously had to
carry.

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

Re: GitLab CI runners for non-Linux systems

[Ross Burton]

On 18 May 2018 at 10:52, Philip Withnall  wrote:

> tl;dr: Want to provide us with a GitLab CI runner for a non-Linux
> platform?
>
> There’s been a surge of interest recently, from various directions, in
> getting GLib better tested on non-Linux architectures. This is great,
> and we’ve got various people to thank for doing the thankless work of
> porting and testing. Particularly:
>  • macOS: Ryan Schmidt, Patrick Griffis, Michael Lauer, John Ralls
>  • Windows/MinGW/MSYS2: LRN, Christoph Reiter, Xavier Claessens, Chun-
> wei Fan
>  • Android: Xavier Claessens
>  • *BSD: Ting-Wei Lan
>

Would you be interested in extending the Linux coverage to include
cross-building to proper Linux?

https://gitlab.gnome.org/rburton/glib/-/jobs/42792 is a bit hacky but
demonstrates that using a Yocto-built toolchain with autotools, glib will
cross-build successfully to aarch64.  Next step is to try with Meson, but
auto* was easier as we exercise that in our own QA.

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

Re: migrating gtk

[Ross Burton]

On 5 February 2018 at 14:15, Emmanuele Bassi  wrote:

> I gained the fact that you read your email and if you're still
> experiencing the issue, or if it was accidentally fixed in the ~4
> years between your original report and me going through the open bugs
> of gobject-introspection. That's why it was marked as NEEDINFO.
>

For what its worth we do this in the Yocto bugzilla too.  Bugs get pushed
to NEEDINFO if the assignee can't replicate/understand/etc, and the
reporter will get about two months of pings to provide more useful
information. If there's silence then the bug is closed.

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

Re: Does gobject-introspection support the cross-compile?

[Ross Burton]

On 13 August 2014 07:07, Rongqing Li rongqing...@windriver.com wrote:

 I am working under Yocto, and using the host g-ir-compiler to compiler
 target file, and the error is below:


Are you using meta-gir?  If not then you should.  If you are then it's
likely bitrotted, I recommend speaking to the author (Tomas Frydrych) about
any problems.

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

Re: A Gtk's build system ?

[Ross Burton]

On Tuesday, 5 August 2014, Simon McVittie simon.mcvit...@collabora.co.uk
wrote:

 Best-practice in at least Debian and Ubuntu is moving towards always
 discarding the upstream-supplied configure and Makefile.in, and
 re-running autoconf/automake to re-generate them during the build; this
 removes some of the perceived advantages of Autotools, but it means
 we're compiling from actual source code, not from something that looks
 vaguely like source code if you aren't really paying attention :-)


For what it's worth OpenEmbedded has also been doing this for years and not
as best practise but as default behaviour. We basically run autoreconf
-sif and have a surprisingly high success rate :)

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

Re: Can g_field_info_get_offset () provide same info as G_STRUCT_OFFSET?

[Ross Burton]

On 6 November 2013 14:45, Andrés G. Aragoneses kno...@gmail.com wrote:

 (unless glib upstream would accept a patch to wrap the G_STRUCT_OFFSET in
 a public function?).


That would be a function for every member of every struct, as
G_STRUCT_OFFSET is a macro (sounds unlikely to me).

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

Re: non-Linux OSes

[Ross Burton]

On Monday, 28 October 2013, Colin Walters wrote:

 The OpenEmbedded people are looking at it this cycle I believe.


Indeed we are.  Currently only glib is installing tests but integrating
them with our ptest framework for installing/running test suites is
trivial so more will follow.

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

Re: Spell checking in GIO

[Ross Burton]

On 9 October 2013 23:15, Paul Davis p...@linuxaudiosystems.com wrote:

 And if an extension point is added, it's better to add it in GIO, so
 command line tools can use it.


 I'm just curious. What command line tools use GIO (or even glib)?


A very rough list based on a grep of oe-core's metadata for glib-2.0 (so
yes, this is GLib and not GIO):  avahi, connman, network manager, bluez,
 neard, ofono, telepathy, desktop-file-utils, pkgconfig, vala, blktool, mc,
gconf, dconf, gstreamer.

Non-GTK+ applications that use GLib do exist.

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

Re: Spell checking in GIO

[Ross Burton]

On 9 October 2013 23:48, Jasper St. Pierre jstpie...@mecheye.net wrote:

 Of course, but do any of these need spell checking? I think it would be
 more helpful to solidify an API for spell checking to see if it's viable to
 do without UI concepts like cursor position or GTK+ concepts like
 GtkTextBuffer before deciding where to put it.


I wouldn't rush to state that there will be no command-line based
applications that want to spell-check.

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

Re: Stable, long term support releases for gtk+

[Ross Burton]

On 3 January 2013 15:02, Emmanuele Bassi eba...@gmail.com wrote:
 just as an addendum:

 it seems that GLib 2.32 is the version used by Ubuntu and Debian, so
 if we go for an LTS cycle for GLib as well as GTK+, the glib-2-32
 branch would be the one used as the baseline.

FWIW, the current Yocto Project release (1.3) has GLib 2.32.4 and GTK+
2.24.8.  In git for 1.4 we've currently got GLib 2.34.3 and GTK+
2.24.14, and I'm currently preparing the long-delayed inclusion of
GTK+ 3.6.2.

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

Re: Stable, long term support releases for gtk+

[Ross Burton]

On 3 January 2013 15:39, Emmanuele Bassi eba...@gmail.com wrote:
 how long is the long term support for Yocto? because if you include
 3.6 now, you'll need to have a LTS only for you, along with 3.4, which
 is definitely *not* my goal. unless you guys resync in the next cycle,
 which would suck. :-/

YP itself is on a six month release cycle with rolling support, no LTS
releases in the strict sense as yet.

The interesting bit in the LTS releases is more that if we ensure we
package them, then if someone does build a system using YP with six
years of support they can track the continued LTS releases.

I'll downgrade my gtk3 branch to 3.4.x now whilst it's still a personal branch.

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

Re: Mainloop debugging tool idea

[Ross Burton]

On 19 November 2012 15:33, Rob Bradford robert.bradf...@intel.com wrote:
 We've used this code before to do something like this
 (http://git.gnome.org/browse/libsocialweb/tree/src/poll.c) was
 definitely useful for finding blocking issues.

This is very minimal though, and only says when it blocks (which is
all we needed in libsocialweb) and nothing useful like the stack of
the blocked thread.

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

Re: notifications in gtk

[Ross Burton]

On Wednesday, 7 November 2012 at 01:23, Matthew Brush wrote:
 Actually, one of my favourite things about OSX is that it does not have
 these annoying notifications (except when apps force them using 3rd
 party libraries that users have to disable). If OSX has something really
 important to tell you, it pops up a proper dialog box (ex. when the
 battery is almost depleted or updates need to be installed).


Actually, Mountain Lion added the Notification Centre, which is essentially 
Growl plus a docked notification list.  http://www.apple.com/osx/whats-new/ has 
screenshots if you've never seen this in action.

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

Re: Multitouch review 2: press-and-hold

[Ross Burton]

On 1 February 2012 11:23, Bastien Nocera had...@hadess.net wrote:
 I still think that the press and hold animation has no place here. Apart
 from Windows, I've not seen any touch or stylus devices use this, and I
 seriously doubt its usefulness (versus it looking tacky, out of place,
 etc.).

All Maemo devices since the 770 do this, because that's where the
patch came from.

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

Re: DTDs and other fun

[Ross Burton]

On 26 January 2012 22:35, Matthias Clasen matthias.cla...@gmail.com wrote:
 Sure, I wouldn't object to replacing the DTDs by your schemas, and
 shipping the xml schemas that are suitable for xmllint.

As someone who uses nxml-mode in emacs, the automatic
validation/completion you get when hand-writing a XML file with a
RelaxNG schema is fantastic.

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

Re: RFC: new features

[Ross Burton]

On 12 January 2012 12:17, Paul Davis p...@linuxaudiosystems.com wrote:
 to me, this is highly unrealistic. undo/redo is incredibly application
 (and scale) specific. even inside one application, it can make sense
 to find two entirely different approaches to handling undo/redo (e.g.
 one based on save/restore of the full state of objects and other based
 on storing differences in state).

Tasks has a undo manager/undoable implementation and that's
implemented by function pointers that do the right thing, so you can
probably implement both methods with that.

(http://git.gnome.org/browse/tasks/tree/libkoto)

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

Re: RFC: glocal - automatically freeing memory when it goes out of scope

[Ross Burton]

On 21 November 2011 15:43, Dominic Lachowicz domlachow...@gmail.com wrote:
 If you want this sort of behavior, use a language like C++ that
 supports stack-allocated objects natively. GtkMM and GlibMM already do
 this wonderfully. Using a GNU-C ism which probably won't work with
 most other C compilers (MSVC, LLVM, ICC, ...) feels wrong to me.

We need a micro-C++ binding that looks exactly like traditional
GObject C but also hooks up the nice features like stack allocated
objects.  I don't like C++ but I'd consider a C++ compiler to compile
my C code if it could simplify memory management dramatically for
almost free. :)

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

Re: _wstat on Windows (actually stat stuff in general)

[Ross Burton]

On 29 September 2011 10:53, Kean Johnston kean.johns...@gmail.com wrote:
 I really don't need accurate GPS measuring to know that a Bugati Veyron is
 faster than a Fiat Uno, any more than I need to provide you with profiling
 data to prove that GIO is slower than g_stat().

I can also tell you that for driving from my house to the supermarket,
the Veyron won't be any faster because of other far larger sources of
delays, such as the speed limit (or HDD latency).

Of course GIO is slower when you look at the LoC count, the question
is for the typical case is performance acceptable.  If your
application is opening a million files then maybe it's not typical.

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

Re: _wstat on Windows (actually stat stuff in general)

[Ross Burton]

On 29 September 2011 11:13, Kean Johnston kean.johns...@gmail.com wrote:
 No way you can convince me
 otherwise I'm afraid, and that's not because I'm being stubborn, it's
 because I (and I think you) know I'm right. GIO is appropriate for some
 applications, of that I have no doubt, but trying to convince me that it's a
 viable alternative to stat() when all I want it the damned file size? Never
 gonna happen.

If you are happy limiting yourself to a single platform and don't need
some the magic that comes with GIO, feel free to use stat().  It's not
like GIO is going to break that for you.

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

Re: Replacing gdk_display_open(char*)

[Ross Burton]

On 16 November 2010 18:44, Petr Tomasek toma...@etf.cuni.cz wrote:
 So this would be really needed and I think Gtk should have some
 way to support an application simultaneusly using more than one
 screens.

 The current bottleneck on X is however the inability of XrandR to create
 new screens on the fly... :-(

What is stopping you using the GDK API to get the extents of the
monitors from the unified screen and say positioning the speakers
notes on one monitor and the presentation on the other?

To be honest, I thought Oo.o did this already - my laptop has Intel
GPU so uses the new world order of xrandr, and I'm sure I've done this
with oo.o.

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

Re: Color managed GtkImage

[Ross Burton]

On Tue, 2010-01-12 at 18:54 +, Richard Hughes wrote:
 Everything is converted to sRGB is one possible solution, but
 things need to be explicit.
 
 I think shoehorning everything into sRGB would be a very bad idea. 

I can see a very good argument for the colour managed GtkImage
converting to sRGB, considering it's not exactly shoehorning.  Very few
monitors can display the full sRGB gamut, yet alone more than sRGB.

Ross
-- 
Ross Burton mail: r...@burtonini.com
  jabber: r...@burtonini.com
   www: http://burtonini.com


signature.asc
Description: This is a digitally signed message part
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Undo stack for GTK+ (was: Re: undo in textview)

[Ross Burton]

On Mon, 2009-12-28 at 18:02 +0100, Holger Berndt wrote:
 Cross-posting to move the discussion to gtk-devel-list. Anybody interested
 in the topic, please follow up there.
 
 On Do, 24.09.2009 19:23, A. Walton wrote:
 
 It's definitely something many developers would love to see in Gtk+,
 but only a few have stepped up to the bat with patches and actually
 discussed the problem,
 
 Why don't we take the opportunity to discuss the problem now, then? I
 can start by offering my view on how an undo stack should look like,
 and provide a reference implementation as a basis of discussion.
 
 The implementation is a git branch called undo based on gtk+
 2.19.2, and can be found at git://github.com/hb/gtk.git
 I attached a cumulative (squashed) version to this mail for convenience,
 to be applied onto 2.19.2.

I'll have a look at your code later when I'm not feeling really rough,
but have you seen the undo classes in Marlin and Tasks?

http://git.gnome.org/browse/tasks/tree/libkoto, koto-undo-manager.c,
koto-undoable.c, koto-undo-action.c.

Ross
-- 
Ross Burton mail: r...@burtonini.com
  jabber: r...@burtonini.com
   www: http://burtonini.com


signature.asc
Description: This is a digitally signed message part
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Speeding up thumbnail generation (like multi threaded). Thoughts please.

[Ross Burton]

On Thu, 2009-10-01 at 16:00 +0200, Petr Tomasek wrote:
 On Wed, Sep 30, 2009 at 05:51:56PM +0100, Ross Burton wrote:
  On Wed, 2009-09-30 at 12:32 -0400, David Zeuthen wrote:
   (Btw, this infrastructure is not specific to the gphoto2:// GVfs
   backend; any GVfs backend can use it - say, a Flickr backend).
  
  Bad example, downloading the original file (no seeking in HTTP) just to
 
 HTTP_RANGE?

Thanks to latency I imagine it would actually be faster to download the
entire image than attempt to seek around a file over HTTP.

Ross
-- 
Ross Burton mail: r...@burtonini.com
  jabber: r...@burtonini.com
   www: http://burtonini.com


signature.asc
Description: This is a digitally signed message part
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Speeding up thumbnail generation (like multi threaded). Thoughts please.

[Ross Burton]

On Wed, 2009-09-30 at 16:57 +0200, Philip Van Hoof wrote:
 I don't think it has an upstream repository anymore, just source
 packages of distributions. 

I do find that using software which lacks a maintainer and canonical
repository is far preferable than software with a repository but no
maintainer or -- dare I say it -- maintained software.

Ross
-- 
Ross Burton mail: r...@burtonini.com
  jabber: r...@burtonini.com
   www: http://burtonini.com


signature.asc
Description: This is a digitally signed message part
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Speeding up thumbnail generation (like multi threaded). Thoughts please.

[Ross Burton]

On Wed, 2009-09-30 at 12:32 -0400, David Zeuthen wrote:
 (Btw, this infrastructure is not specific to the gphoto2:// GVfs
 backend; any GVfs backend can use it - say, a Flickr backend).

Bad example, downloading the original file (no seeking in HTTP) just to
extract the thumbnail would be pretty silly considering that Flickr
allows direct access to thumbnails (and other sizes) through its API. :)

Ross
-- 
Ross Burton mail: r...@burtonini.com
  jabber: r...@burtonini.com
   www: http://burtonini.com


signature.asc
Description: This is a digitally signed message part
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Speeding up thumbnail generation (like multi threaded). Thoughts please.

[Ross Burton]

On Wed, 2009-09-30 at 18:01 +0100, Bastien Nocera wrote:
 On Wed, 2009-09-30 at 17:51 +0100, Ross Burton wrote:
  On Wed, 2009-09-30 at 12:32 -0400, David Zeuthen wrote:
   (Btw, this infrastructure is not specific to the gphoto2:// GVfs
   backend; any GVfs backend can use it - say, a Flickr backend).
  
  Bad example, downloading the original file (no seeking in HTTP) just to
  extract the thumbnail would be pretty silly considering that Flickr
  allows direct access to thumbnails (and other sizes) through its API. :)
 
 Got that wrong. David was talking about out-of-band thumbnails (gphoto2
 can export that data as an attribute of the file, without downloading
 the whole file). So you are in agreement...

Ah, right, gotcha.

Ross
-- 
Ross Burton mail: r...@burtonini.com
  jabber: r...@burtonini.com
   www: http://burtonini.com


signature.asc
Description: This is a digitally signed message part
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Speeding up thumbnail generation (like multi threaded). Thoughts please.

[Ross Burton]

On Wed, 2009-09-30 at 13:06 -0400, David Zeuthen wrote:
 No, it's actually a great example.
 
 The way it works is that a GVfs backend can set the preview::icon file
 attribute (which is a GIcon) [1] to whatever it wants. In GVfs we have a
 class, GVfsIcon, that implements GLoadableIcon and GIcon. When clients
 read preview::icon, then the loading of the returned icon is directed
 back to the backend via the open_icon_for_read() VFunc on the
 GVfsBackend class. The backend can then use any API it wants to
 get/create the thumbnail. It is completely unrelated to the file in
 question.

I take it back, that is neat. :)

Ross
-- 
Ross Burton mail: r...@burtonini.com
  jabber: r...@burtonini.com
   www: http://burtonini.com


signature.asc
Description: This is a digitally signed message part
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Performance issue when trashing files (backtraced to fsync)

[Ross Burton]

On Tue, 2009-08-11 at 17:27 +0200, Mark wrote:
 What i find strange is moving files or folders form location x to
 location y is rapid but moving them to the trash is slow.. why is
 that?

As Alex said:

So, the issue here is that for each file we trash we write a small
keyfile with some information about the file.

Ross
-- 
Ross Burton mail: r...@burtonini.com
  jabber: r...@burtonini.com
   www: http://burtonini.com


signature.asc
Description: This is a digitally signed message part
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Cairo based engine api for GTK+ 3.0

[Ross Burton]

On Thu, 2009-06-18 at 11:45 +0100, Chris Wilson wrote:
 Just to clarify: do you want a cairo equivalent for the stipple effect
 or how to replace pango_cairo_layout_path()?

Can we just remove all stippling from GTK+ and instead use faded
colours?  Stipples are so 1990s...

Ross
-- 
Ross Burton mail: r...@burtonini.com
  jabber: r...@burtonini.com
   www: http://burtonini.com


signature.asc
Description: This is a digitally signed message part
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Review of gnio, round 1

[Ross Burton]

On Mon, 2009-05-11 at 15:08 -0300, Vovo ^^ wrote:
 Also will it always resolve names using only DNS?

Not sure if this was rhetorical or not but no, GResolver uses NSS so
could end up using LDAP, mDNS and so on.

Ross
-- 
Ross Burton mail: r...@burtonini.com
  jabber: r...@burtonini.com
   www: http://burtonini.com


signature.asc
Description: This is a digitally signed message part
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GLib plans for the next cycle

[Ross Burton]

On Wed, 2009-02-11 at 01:07 -0500, Matthias Clasen wrote:
 - Where do we put this ? Inside libgobject (since it is more or less
 DBus bindings for GObject) or inside libgio (since it uses the GIO
 async
 pattern and some utility classes from GIO) or separate ?
 
My proposal: Add it as a separate library, next to (or actually on
 top of) GObject and GIO. Maybe call it GBus.

Would it be possible for the dbus GLib main loop integration and the
GObject bridging to be separate libraries?  Having DBus integrated in
glib-only applications would be useful, and also it lets you re-use the
main loop binding if you don't want to use GBus.

Ross
-- 
Ross Burton mail: r...@burtonini.com
  jabber: r...@burtonini.com
   www: http://burtonini.com


signature.asc
Description: This is a digitally signed message part
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GLib Reference Documentation

[Ross Burton]

On Wed, 2009-01-07 at 18:08 +0100, Valerio Messina wrote:
 GLib Reference Documentation should mention that:
 1 - 'error' must be initialized to NULL before call
 'g_spawn_command_line_sync'
 3 - 'error' must be freed with: if (errorPtr) g_error_free (errorPtr);
 or lot of coredump and memory leak occur.

These are all covered by the documentation on GError, which has several
pages on how to use GErrors correctly.

Ross
-- 
Ross Burton mail: r...@burtonini.com
  jabber: r...@burtonini.com
   www: http://burtonini.com


signature.asc
Description: This is a digitally signed message part
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: EggDBus

[Ross Burton]

On Sun, 2008-12-21 at 21:48 -0500, David Zeuthen wrote:
 For the past 5 weeks or so, I've been working on a new (as compared to
 dbus-glib) D-Bus binding for GObject. The work on this has finally
 reached a stage where the code sufficiently complete and documented so
 I thought I'd send some mail describing it. The code is here

Sweet!

I ended up using libtelepathy-glib generated GInterfaces in my latest
project for the server side bindings (after a patch if you don't use
properties they don't link to libtelepathy-glib).  The GInterface model
is very nice to work with, so I'm glad EggDBus uses the same model.  If
I have the time I'll attempt a port to EggDBus and see how it works for
me.

Ross
-- 
Ross Burton mail: r...@burtonini.com
  jabber: r...@burtonini.com
   www: http://burtonini.com


signature.asc
Description: This is a digitally signed message part
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: gtk+ speed

[Ross Burton]

On Mon, 2008-12-22 at 13:12 +0200, Eugene Gorodinsky wrote:
 I haven't programmed much with gtk+, so forgive a noob if this is a
 silly question. My first impression when I looked at the architecture
 (using GObject etc.) was that this must take quite a bit of processing
 cycles and memory. So my question is: is there any room for
 improvement by rethinking the architecture (using Vala for some of the
 things maybe?) with gtk+ 3.0 in the works this question bothers me a
 bit :)

Vala is a high level language which is translated to GObject and C, so
you are proposing to rewrite GObject using GObject.

Ross
-- 
Ross Burton mail: r...@burtonini.com
  jabber: r...@burtonini.com
   www: http://burtonini.com


signature.asc
Description: This is a digitally signed message part
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: gtk+ speed

[Ross Burton]

On Mon, 2008-12-22 at 15:22 +0100, Robin Sonefors wrote:
 I think I got this impression of GObject because it forces you to really
 see the overhead, when most other languages/libraries works harder to
 hide more. For instance, the code generated for a virtual function in 
 C++ is as far as I understand (as I said, noob here) in principle the
 same as the code you have to manually write in GObject to do the same
 thing, it's just much more invisible.

Exactly.  C++ can do slightly more optimisation because the OO, casting
and so on are in the compiler instead of built at runtime, but the
underlying mechanics are the same.

Ross
-- 
Ross Burton mail: r...@burtonini.com
  jabber: r...@burtonini.com
   www: http://burtonini.com


signature.asc
Description: This is a digitally signed message part
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: [Patch] Re: Howto retrieve selected font size from GtkFontButton

[Ross Burton]

On Wed, 2008-12-03 at 14:34 +0100, Nelson Benítez León wrote:
  I think nowadays, thanks to library.gnome.org, most people use online
 documentation, it's way more practical because you don't have to
 install any package, it's always up-to-date, it has a good google
 search and you can open the information in several tabs with your
 browser.

I'd be greatly surprised if that is the case.  I can press F11 and get
context sensitive help for the function call I'm writing in a fraction
of a second with Devhelp without any context switching.  Compared to
switching to a web browser and making the search it is vastly faster.
Also the online docs may be more up to date, but what if your libraries
are not?

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
   www: http://burtonini.com


signature.asc
Description: This is a digitally signed message part
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Theme patriation

[Ross Burton]

On Sun, 2008-10-26 at 18:38 -0400, Thomas Thurman wrote:
 This would mean that the themes could interact better with the contents 
 of the window.  For example, it would become easy to add a button like 
 the oval button on an OS X window which hides the toolbar.

You can do this by extending the ICCCM WM_PROTOCOLS message.  Maemo and
Sato use the support in Matchbox for a custom action
(_NET_WM_CONTEXT_CUSTOM) to pop up the main menu bar, and I believe KDE
uses _NET_WM_CONTEXT_HELP to implement context-sensitive help (help icon
in the titlebar activates click-for-help mode).  Matchbox also supports
_NET_WM_CONTEXT_ACCEPT so that (insane) devices can create WinCE-style
dialogs.

Adding _NET_WM_CONTEXT_TOOLBAR sounds like it should be fairly simple to
do, especially with a GTK+ utility function to mark a toolbar as the
main toolbar.

It would also make it much easier to allow per-app themes, as is often
 requested for the GIMP.

I'm failing to see a reasonable use-case for the GIMP to have a
different theme.  What is the reasoning here?

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
   www: http://burtonini.com


signature.asc
Description: This is a digitally signed message part
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Qt vs. Gtk+ holy war Was: Steps to get to GTK+ 3.0

[Ross Burton]

On Thu, 2008-06-05 at 16:16 +0200, Christian Dywan wrote:
 What about Genie even?
 
 [indent=4]
 uses
 Glib
 
 class Foo : Object
 
 init
 var bar = 0

That doesn't define a property.

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Integrating optional file chooser implementations into GTK+

[Ross Burton]

Hi,

In Poky Linux[1] we're maintaining what could be termed a fork of
gtkfilechooserdefault.c targetted at devices with small screens.
Basically we're removed large amounts of functionality, and added some
extra options (such as the ability to restrict the file that the file
chooser will display to a particular subtree) which are often useful.

Now, we'd love to stop having to resync this huge patch on every GTK+
release because it's frankly quite huge.  Also, other people building
mobile devices might find this file chooser far more suitable for their
purposes than the default one.

Would there be any interest in us cleaning the patch up as a standalone
file chooser implementation, adding it to the GTK+ sources, and then
letting GtkFileChooser use a configurable (at configure time)
implementation (defaulting to the current widget)?

Cheers,
Ross

[1] http://pokylinux.org
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GtkBuilder bug?

[Ross Burton]

On Wed, 2008-02-27 at 22:32 +0100, Mikkel Kamstrup Erlandsen wrote:
 Hmmm. This sounds like a very narrow minded decision to me. I have
 been planning to write write a framework where one can send GtkBuilder
 XML snippets to a DBus service and have that service embed this as out
 of process plugins.
 
 The described GtkBuilder behavior forces me to write a separate
 validator before I pass it to the GtkBuilder. Bugger.

I don't believe that any data passed to a library should result in a
fatal warning, surely a GError return would be a far better option here.

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: g_intern_static_string() for type names as small optimization

[Ross Burton]

On Wed, 2008-01-16 at 16:53 +0200, Andrew W. Nosenko wrote:
 Matthias (or anyone else), could you explain, what this small
 optimization optimizes (what use-cases, on what way, etc), why and
 how big win/profit gives?

As the documentation says:

g_intern_static_string() does not copy the string, therefore string
must not be freed or modified.

When you are talking about several strings for every object, not having
to copy every one saves both time and memory.

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: [gfvs] cdda backend

[Ross Burton]

On Sun, 2007-12-16 at 18:22 -0500, David Zeuthen wrote:
  - Puts RIFF tags in the .wav files containing metadata; though no
metadata framework is currently hooked up (I tried experimentally
hooking up s-j's libjuicer and it works very well; unfortunately
that library is pulling in gtk, gnome-vfs, gconf... Ross?)

A total rewrite of Sound Juicer is on my to do list, but as my current
laptop doesn't have a CD drive progress has been slow. ;)  One of the
goals has been to ensure that the low-level libraries don't require GTK+
at all.  That said, metadata is tricky.

- CD-Text.  I've yet to see a commercial CD with CD-Text support
- FreeDB: useless.  The commercial servers are good (cf iTunes), but
freedb is a waste of space.  [this is where I get flamed]
- Musicbrainz.  Yes, libmusicbrainz is dead.  However, long live
libmusicbrainz!  There is a new API to the musicbrainz server which
resulted in a far saner library and I have a prototype patch to hook it
into libjuicer.

I have a plan, it just needs doing.  Volunteers to help gut and
reconstruct Sound Juicer welcome. :)

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Gtk on Embedded Device Query

[Ross Burton]

On Fri, 2007-11-30 at 17:41 +0530, Saroj Kumar wrote:
 Now I am planning to run gtk+ on X-server. I started hunting for
 X-server and found TinyX.
 Now how to cross-compile X-server? Is there any document on it. 
 
 I downloaded X-server from Xfree86 ftp site. Plz. guide me on
 cross-compiling.

The releases on x.org are probably preferable, as they are easier to
build.  I really recommend that you investigate a build system such as
Poky or OpenEmbedded instead of building it all by hand, which is a
*world of pain*.

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Gtk on Embedded Device Query

[Ross Burton]

On Thu, 2007-11-29 at 18:40 +0200, Kalle Vahlman wrote:
  The Main problem here is while drawing gtk widgets on screen my CPU usage
  goes upto 92%. Any button press in window also make CPU usage more.

Try your hardware using GTK+ on top of X11, many people have profiled
GTK+ with DirectFB and discovered that X11 is many times faster for them
due to better use of the hardware in X11 verses DirectFB.

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Patch review: sizing toggle cell renderers based on font size

[Ross Burton]

Hi,

http://bugzilla.gnome.org/show_bug.cgi?id=459997 contains a patch we're
shipping in Poky (pokylinux.org) to size the toggle cell renderer check
boxes to roughly the height of the font instead of hard-coding it at
12px.  A 12px check box is a little tricky to use on a screen with 200+
dpi. :)

I'd appreciate a review of this, we've got far too many patches at the
moment.

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF


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

Re: using dbus in the platform

[Ross Burton]

On Thu, 2007-10-18 at 20:20 +0100, Alp Toker wrote:
 The Hiker project (http://www.hikerproject.org/), a mobile application 
 framework based around GTK+, uses ALP IPC 
 (http://www.hikerproject.org/doc/html/group___a_l_p___i_p_c.html).

ALP IPC is an abstraction layer.  One of the implementations is DBus.

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Undo framework

[Ross Burton]

On Fri, 2007-09-21 at 17:51 +0100, Iain * wrote:
 I've had an undo framework in Marlin for years now, but recently
 people have been using it in other things (notably Ross in Tasks - ok,
 actually, he's the only one) and we discussed suggesting this for
 inclusion in GTK at some point in the future. QT4[1] and Cocoa[2] both
 have very similar frameworks. Attached are the header files.

This is, erm, an entirely different Ross Burton, and I think that this
should be added to GTK+.  I for one will use it in my application,
Tosks.

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GVfs status report

[Ross Burton]

On Fri, 2007-09-14 at 09:37 +0200, Alexander Larsson wrote:
  A more macro thought, since there's so much code here, it would be
  worth spending some time to try and identify the parts an app (vs. a
  file manager) would usually use, and then somehow highlight those
  parts in the docs and/or header file organization. i.e. make it easy
  if I just want to read and write a file
 
 Yeah, that makes sense. For you typical application that wants to load
 and save files I think the following is the core API:

If anyone wants to see a non-trivial real world application they can
have a look at my toy image viewer, Katachi.

$ bzr branch http://burtonini.com/bzr/katachi

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Rebuilding a table that has changed.

[Ross Burton]

I forgot to mention that this list is for the *development of* GTK+, not
for people *developing with* GTK+.  Please use gtk-app-devel-list in
future.

On Tue, 2007-07-24 at 07:33 -0700, serratemplar wrote:
 So gtk_container_remove I'll use to remove the table itself, then rebuild
 it? Or can I somehow use that to remove individual elements of the table? 
 I'm leaning towards the former, but I figured I'd ask.

gtk_container_remove() removes a child from a container.  A table is a
container. So you can remove your widgets (the children) from a table.

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Rebuilding a table that has changed.

[Ross Burton]

On Mon, 2007-07-23 at 11:10 -0700, serratemplar wrote:
 My application has multiple windows that will be used to sort objects
 (represented by images within event boxes); the intention is that objects
 can be dragged from one window and dropped into another, and that the tables
 within each will update to reflect this.  As far as I understand it, GTK
 tables are not designed to do this (as there is no remove function call in
 the table subset).
 
 I dug thru docs and forums and found no way to do this that seemed the
 correct way, and no other container class seems fit for the job.  I would
 really appreciate any advice you have to offer me.

GtkTable is a subclass of GtkContainer, you are looking for
gtk_container_remove().

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Themes and colours

[Ross Burton]

On Mon, 2007-07-02 at 11:57 +1000, Daniel Kasak wrote:
 I think this suggestion is a relatively small and natural extension of
 theming, and would allow for more visually appealing applications while
 working around the problems that people have with overriding default
 colours.

I think this is a good idea. GTK+ provides the infrastructure, we
basically need someone to come up with a sensible subset of colours that
can be agreed upon.  Then applications can request a named colour from
the theme, and if it doesn't exist use a hard-coded default colour.

Tasks is already doing this.  The default colours for low, medium, and
high priority tasks in the source code are optimised for Clearlooks, but
I use a dark theme so I have this in my .gtkrc-2.0:

style koto-task-view
{
color[priority-high] = dark red
color[priority-normal] = black
color[priority-low] = dim gray
color[priority-done] = dim gray
}
class KotoTaskView style koto-task-view

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Meetings at GUADEC

[Ross Burton]

Hi,

There are a number of meetings for various groups at GUADEC, these have
now been scheduled at http://www.guadec.org/schedule/meetings.  Apart
from the AGM, these meeting are all held in the Board Room.

Regards,
Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF


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

Re: GTK+ Team Meeting Minutes - June 5th

[Ross Burton]

On Tue, 2007-06-05 at 23:58 +0100, Emmanuele Bassi wrote:
 1) gtk+ meeting at GUADEC
 
Behdad asked for the day and time when the usual GTK+ team
meeting at GUADEC will be held. a slot has been booked on
monday (july 15th), but it should appear on the official
schedule.
 
ACTION: Kris will ask the GUADEC team to allocate sufficient
time for the GTK+ meeting at a convenient location.

The GTK+ team has the 10:30 until lunchtime slot on Monday.

http://www.guadec.org/schedule/meetings

That gives you two hours scheduled, plus the ability to overflow into
lunch if you wish.  Just finish before 14:00 otherwise you'll be pelted
with N800s by the GMAE meeting. :)

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Hinting GtkEntry

[Ross Burton]

On Thu, 2007-05-24 at 16:45 +0200, Tim Janik wrote:
  Several applications have GtkEntry classes which show a message in faded
  text when the entry is normally empty and disabled, wiping it when the
  entry is focused (as an example see the search bar in Evolution).
 
  I've made a simple subclass of GtkEntry which does this for Tasks, but
  is there any interest of adding this as a hint property to GtkEntry in
  GTK+ instead?
 
 if several apps duplicate this already, interest obviously exists.
 should be filed as a bug report with patch then.

http://bugzilla.gnome.org/show_bug.cgi?id=440963

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Hinting GtkEntry

[Ross Burton]

On Thu, 2007-05-24 at 13:13 -0400, Havoc Pennington wrote:
 Would it be better to just support an icon inside the entry? (how many 
 different use cases are there really for this, maybe all of them should 
 just be supported directly?)
 
 The reason for the side windows in GtkTextView is sort of different: 
 they scroll with the text view contents. The scrolling aspect would be 
 difficult to achieve without the side window feature.
 
 For putting an icon in an entry, there isn't really this complexity; 
 something like gtk_entry_set_icon() or just gtk_entry_set_left_widget() 
 would work fine, instead of having to deal with GdkWindow and custom 
 drawing.

SexyEntry supports activatable icons on the left and right of a widget,
although the implementation isn't great (doesn't support named icons and
so on).

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: is glib too bloated?

[Ross Burton]

On Mon, 2007-04-23 at 09:17 -0600, Michael L Torrie wrote:
 I think you mean below the gobject stack, don't you?  The data
 structure libraries are required by gobject after all, aren't they?
 
 In any case, I think a future split out of the glib data structure api
 would be excellent.  I pretty much use thinks like gslist, gstring, and
 ghash in *all* my C programs.  I also frequently use the glib logging
 facility.  
 
 On the other hand I don't often use gobjects, the event loop,
 call-backs, or any other part of glib in many of these little utility
 programs.  
 
 It would be nice, though, to only have a small dependency, rather than
 the entire glib.
 
 That said, glib isn't that big.

That is the current state: libglib only contains main loop, lists,
strings, hashes and so on.  On top of that there is libgmodule,
libgobject, and libgthread.  If you don't need objects and threads, you
don't need to use them.

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: g_get_user_config_dir leaks memory ?

[Ross Burton]

On Mon, 2007-03-26 at 20:40 +0100, Rúben Fonseca wrote:
  So my question is, is g_get_user_config_dir really leaking? Or it is
  just a Valgrind problem? Can I make it not to leak?

Looking up entries in the password database (thats the getpwnam_r call)
can potentially take a long time (say the database stored in a LDAP
server at the other end of slow VPN link), so GLib fetches it once and
caches it.  This is why you shouldn't free it.  So yes, technically it
is leaking, but it's a one-off cost (it won't grow over time) and is
good for you.  Just ignore it: someone really should sit down and make
an officially maintained suppressions file for Valgrind for the X11 and
GLib leaks.

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Dragging the text in a text entry issue

[Ross Burton]

On Thu, 2007-03-15 at 11:37 -0500, Cody Russell wrote:
 On Wed, 2007-03-14 at 16:32 +0200, Itai Bar-Haim wrote:
  Hi.
  I was looking through the API, but I couldn't find a way to disable
  dragging of the text. Is it possible at all?
 
 Look at the gtk_drag_???() functions.  For example, to disable an entry
 from receiving text drags you would do gtk_drag_dest_unset (widget).

There is the question of why you want to disable dragging of text.  If I
was using your application and wanted to drag text but couldn't, I
wouldn't be happy.

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Multimedia widgets in GTK+?

[Ross Burton]

On Thu, 2007-03-01 at 11:06 -0800, Brian J. Tarricone wrote:
 - BaconVolumeWidget, living in the libbacon module in SVN. It's
 currently used by a large number of applications, cut'n'pasted (Totem,
 Rhythmbox, LastExit, Banshee, Muine, Sound-Juicer, possibly others).
 
 I feel like this is a bit special-purpose and heavy for a GUI toolkit,
 no?  What kind of dependencies would it add to gtk?  Obviously the
 widget isn't very useful without an A/V framework backend, and I
 wouldn't want to see gtk depend on gstreamer, xine-lib, etc.

BaconVolume is just the widget, it doesn't actually control anything.
It is up to the application to connect to the changed signal and
implement the volume setting.

 The other
 difference is the ability to mark a fraction, ie. the amount of data
 already downloaded, and available for seeking. I can see Rhythmbox,
 Totem, Banshee, and any other apps dealing with streaming media using
 it.
 
 You mean sorta how YouTube does the seek bar with the little red
 indicator that moves to the right as more data gets downloaded?  Yeah,
 that could be pretty useful, maybe in things other than multimedia
 apps.  But again, could this be implemented via extra API in an
 existing widget?

Isn't this gtk_range_set_fill_level() (new in GTK+ 2.12)?

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Fwd: Memory leak in gobject

[Ross Burton]

On Fri, 2007-02-09 at 12:30 +0530, Uma Shankar Ladha wrote:

 The class structure which was created, when will that be destroyed?
 The Gtype's associated with these and how will that memory get
 destroyed.

They won't.  Unless you use GTypeModule to implement loadable types,
once a type is created it exists until the process exits.

Ross

-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Gtk engine development

[Ross Burton]

On Thu, 2007-02-08 at 09:32 +1100, Daniel Kasak wrote:
 I don't have a direct answer to your question, however I know that work
 is being done on Etk, which aims to be API-compatible with gtk+
 http://enlightenment.org/etk/

I just had a quick look at an Etk code example, and whilst it's
certainly similar to GTK+, it's not API-compatible (after the obvious
s/gtk/etk/.

http://code.google.com/p/etoolkit/wiki/HelloWorld

etk_window_new has no argument.
etk_window_resize would be gtk_window_set_default_size

and so on.

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: gtk-doc !?

[Ross Burton]

On Sat, 2007-01-27 at 22:51 +0100, Tomasz Jankowski wrote:
 I'm trying to write small library based on GObject and I want to
 document it's API with gtk-doc tool, but I have no idea how to use it.
 Moreover I can find any useful samples in net. Can someone explain me
 how to use it? 

The gtk-doc package comes with a detailed description of how to use it,
read setting-up.txt.

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: has anyone valgrind'd gtk?

[Ross Burton]

On Sun, 2006-12-03 at 22:11 +0800, [EMAIL PROTECTED] wrote:
 i have an application, and i'm noticing some leaks deep within gtk's 
 libraries.
 
 even if i take something simple, such as in the examples directory, the
 notebook example, modify it to destroy the notebook, table, and window before
 exitting, and run valgrind, there is quite a lot of memory that is not freed.
 
 has anyone looked at this before ?

GTK+ internally uses GSlice, which means you'll see lots of fake leaks.
Set G_SLICE=always-malloc when starting valgrind, and they'll probably
disappear.

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Pluggable widget types and implementations

[Ross Burton]

On Tue, 2006-11-28 at 14:53 +0100, Tim Janik wrote:
 Resulting in gtk_file_selection_new() to return objects of the custom type 
 gtkfileselector_derived_type, and gtk_printer_selection_new() to return
 objects of the custom type iface_implementation_type.

How would this interact with libglade/GtkBuilder, where dialogs are
created at runtime?  I'm guessing that GtkBuilder uses g_object_new() to
construct the objects.

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GTK-XCB is in progress

[Ross Burton]

On Tue, 2006-11-07 at 15:28 -0200, Johan Dahlin wrote:
  Anyway, I'd appreciate any advice/pointers you could provide, poking
  at the gdk-xcb backends.
  
  Leaves me wondering, what do you see as the benefit of the XCB backends
  for the Gtk+ stack?
 
 I'd say thread-safety.

And the ability to not link to libX11, which is relatively huge.

Ros
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GTK-XCB is in progress

[Ross Burton]

On Tue, 2006-11-07 at 13:21 -0500, Havoc Pennington wrote:
 It seems pretty clear that gtk-x11 has to continue to be installed - 
 gdkx.h is in the ABI.

Damn.  So it is.

 That means a path forward would have to make maintaining both XCB and 
 libX11 GDK targets a viable option, i.e. just cut-and-pasting the X11 
 backend and modifying it to be the XCB backend is not feasible. Instead, 
 for the next many years GTK+ would install a gtk-x11 and a gtk-xcb.
 
 The simplest path to have both seems to be to have an abstraction API 
 that could use libX11 or XCB on the backend. Doesn't XCB have a 
 libX11-like wrapper API? If so, why not make that the abstraction API?
 If not, why not write one that implements what gdk-x11 uses? So an XCB 
 backend shares virtually all code with the libX11 backend and the libX11 
 backend is pretty much unchanged.

There is work on porting libX11 to use XCB internally, which is probably
what you are thinking of.

In the public XCB API (gdkxcb.h vs. gdkx.h) native XCB API could be 
used, and gdk-xcb would not support gdkx.h or would support it only
with footnotes and caveats. This would allow apps to migrate to a 
libX11-API-free state by requiring the xcb backend and using gdkxcb.h 
instead of gdkx.h.

This sounds good to me.  Would deprecating gtkx.h be considered when XCB
is sufficiently deployed?

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GTK-XCB is in progress

[Ross Burton]

On Tue, 2006-11-07 at 13:45 -0500, Havoc Pennington wrote:
 Ross Burton wrote:
  This sounds good to me.  Would deprecating gtkx.h be considered when XCB
  is sufficiently deployed?
  
 
 It's almost an academic question, right... it's not like anything 
 deprecated in 2.0.0 has been removed yet.

True, but if it were deprecated then an embedded build could disable it
totally with some justification.

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: #315645; supporting tap-and-hold

[Ross Burton]

On Fri, 2006-09-22 at 12:37 +0200, Kristian Rietveld wrote:
 As Ross says in that bug, there are two ways of implementing this:
   - load a GTK+ module at run time;
   - add this functionality to GtkWidget.
 
 I would propose to add this functionality directly to GtkWidget.  The
 feature would only be turned on if the touchscreen mode has been
 turned on.

Sounds reasonable.  Great to see movement on this!

 Other points:
 
   - The original proposal in the bug report suggests to have the tap-n-hold
 operation generate a right click (button3 press).  I don't think we should
 hardcode this behaviour, since it will probably break a bunch of apps.
 IMHO it would be much better to have a tap-and-hold signal for this,
 also since most apps will want to handle tap-n-hold clicks
 differently anyway.
 
 Same story for having tap-n-hold automatically pop up menus.  Maybe
 we want to execute a different action.

I can't think of any applications on Maemo where tap-and-hold doesn't
open a popup-menu, are there any?  Although restricting tap-and-hold to
only open context menus might not be a good idea, it does lead to a
standard behaviour (like right click-context menu is currently).

   - It is probably a good idea to give feedback to the user when holding
 down the stylus at some place.  Maemo currently does this using an
 animation at the place where the stylus has been put down.  If we
 decide to provide an animation as feedback to the user we also need
 a way to query a certain position to see if it will respond to the
 tap-n-hold signal.  This way we avoid the scenario where an animation
 is shown and after that nothing happens.
 
 I am wondering whether we should provide a default animation in
 the icon theme and different icon themes can provide different
 animations.  Another option would be to add a function like:
 
   void gtk_widget_set_tap_and_hold_animation (GtkWidget *widget,
   GdkPixbufAnimation *ani);

If tap-and-hold is going to emit a generic signal rather than specify a
behaviour, the I think it should default to an animated icon in the icon
theme, and allow certain widgets to override the animation if required.

   - Of course we should make the hold time configurable.
 
   - In the bug report, Mitch pointed out that we can probably implement
 everything nicely by just adding a single signal to GtkWidget (we
 only have 3 placeholders left though, and only 2 after the new
 tooltips code hit CVS ...):
 
   typedef enum {
 GTK_WIDGET_TAP_AND_HOLD_QUERY,
 GTK_WIDGET_TAP_AND_HOLD_TRIGGER,
 GTK_WIDGET_TAP_AND_HOLD_CANCEL
   } GtkWidgetTapAndHoldAction;
 
   gboolean GtkWidget::tap-and-hold (GtkWidget *widget,
 GtkWidgetTapAndHoldAction  action,
 gint   x,
 gint   y);

What is the cancel action for?

I'm not convinced of the merits of sending a special signal opposed to
popup-menu.  Would GTK+ be edited so that tap-and-hold in a GtkEntry and
so on popped up the context menu, or would that be left to the
applications?

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Expandable text entry widget

[Ross Burton]

On Tue, 2006-09-05 at 23:15 +0200, karderio wrote:
 So, here's the suggestion : on a one line text entry, instead of cutting
 the text, with no easily detectable way for the user to tell how to
 scroll it, automatically make the text entry one line higher and show
 all the text.

Gossip does this, you might want to see what that does.  It might be so
trivial as to not even require a new widget.

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Gtk Application over GTK-DFB

[Ross Burton]

On Fri, 2006-08-11 at 14:24 +0530, Prasanna Kumar K wrote:
 in GTK-DirectFB the top level window(title-bar, border) is not
 visible only the GTK application(buttons, bars etc..) which
 are added to the top level window are visible.
 
 but the same application over GTK-X is showing both the top
 level window and the the widgets(buttons, bars, etc..)

DirectFB doesn't have a window manager, so applications have to draw
their own decorations.  See the DirectFB FAQ:

http://www.directfb.org/index.php?path=Documentation%2FUser+Manuals%
2FFAQpage=2

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Default timeouts

[Ross Burton]

On Fri, 2006-06-09 at 12:33 +0200, Michael Natterer wrote:
 Actually, it may make sense to simply use the user's configured
 key repeat and delay for these two setting values. What do you
 think?

That's probably a very good idea, on the grounds that people set the
keyboard delay/repeat to values they can handle (i.e. my Dad has slowed
them down as he isn't as fast as he used to be).What are the system
defaults for the keyboard delay/repeat?

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Deprecations

[Ross Burton]

Hi,

Would it make sense to mark all of the deprecated API in GLib and GTK+
with G_GNUC_DEPRECATED, so that people who are not using the
DISABLE_DEPRECATED macros still get warned that they are using
deprecated functions?  At the moment it's very black and white, and I
think deprecation functions need a grey...

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Deprecations

[Ross Burton]

On Wed, 2006-04-26 at 15:18 -0400, David Hampton wrote:
  Would it make sense to mark all of the deprecated API in GLib and GTK+
  with G_GNUC_DEPRECATED, so that people who are not using the
  DISABLE_DEPRECATED macros still get warned that they are using
  deprecated functions?  At the moment it's very black and white, and I
  think deprecation functions need a grey...
 
 That would break any project that compiles code using the -Werror flag.

So would upgrading the C compiler (think new gcc and the aliasing
warnings), or using a different set of headers that produces a warning
on an obscure architecture.  -Werror is a fine and mighty useful tool
for development, but a very bad idea for released code.

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Storing config data [was: Re: Printing settings, again]

[Ross Burton]

On Tue, 2006-04-04 at 22:02 -0500, Federico Mena Quintero wrote:
 That file is a blob parsed with GMarkup.

I'm not dissing your choice, but wouldn't GKeyFile be an easier API to
work with here?  Unless of course you need the flexibility of XML...

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: The printing work has been merged

[Ross Burton]

On Tue, 2006-03-28 at 21:05 +0200, Sebastian Rittau wrote:
 Two points to consider:
 
   * PostScript is the standard output format in the natural sciences
 and mathematics community. (Probably due to the prominence of
 LaTeX and dvips.) Also, since it's understood by many
 (semi-)professional printers it is often used for production of
 papers and preprints or as an intermediate format. On the other
 hand the only applications that would fit into this category are
 probably word processors, so general PostScript support is not
 necessarily needed.
   * PDF and PostScript have a slightly different application, in my
 opinion. PDF is used for web publishing, i.e. stuff that's to
 be read online, but can also be printed out. It has lots of
 features that don't make sense on paper (links or automatic
 table of contents, for example). PS on the other hand is the
 lingua franca for communication with printers (the hardware
 kind). If you've got something as PS on Linux you can print it,
 transform it, do all kinds of silly stuff that falls into the
 print preparation category. It's a format very well suited for
 a (printer independent) Print to file option.

An interesting counter-point is that we designed our own wedding
invites, and when we got them printed the printers (a very large chain
in England called Prontoprint or something) wanted source documents in
PDF.  They accepted PostScript if required but preferred PDF, as the
documents are less complicated, less prone to being targeting at
particular printers, and generally easier to print.

The same happened when I got some artwork printed on A2 card at another
large chain (Kallkwik this time): they claimed to accept Postscript but
when pushed (by mailing them CUPS postscript) admitted they import the
Postscript into Adobe Illustrator, so really want AI files.  Or PDF of
course.  I ended up sending PDF as neither Inkscape or CUPS would write
PostScript close enough to the PostScript that AI read.

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: The printing work has been merged

[Ross Burton]

On Mon, 2006-03-27 at 04:57 -0600, Yevgen Muntyan wrote:
 I believe it would be an easy option of PS backend (or whoever
 would print postscript), EPS is just PS without some header, right?

As I understand it EPS is a subset of PostScript.  Pure PostScript can
do anything, such as create new pages, be a web server, etc.
Encapsulated PostScript is designed for embedding in other documents, so
it more like SVG in that respect: lots of the functionality isn't
supported, EPS files have more explicit bounding boxes, etc.

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GNOME CVS: gtk+ matthiasc

[Ross Burton]

On Wed, 2006-01-25 at 11:01 -0500, Jonathan Blandford wrote:
 2. Push it out to XSettings
PROS: Solves this specific problem in the short run.  Has the
 potential to be cross-desktop.
CONS: Doesn't really scale in the long run.  Also, XSettings is
 intended for cross-desktop settings, not everything.

You could argue that URL handlers are valid cross-desktop settings, but
the implementation of that could be interesting.

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Memory consumption

[Ross Burton]

On Fri, 2005-11-25 at 18:23 +0300, Andrey Karavaev wrote:
 How about reducing of memory consumption(may be in next GTK+ versions..) ?
 Problem is following: even very simple GTK-application takes huge place
 in memory( resident memory) so if we have multiuser sysem .

There has been some significant progress in this area, and there is
still on-going work.  If you have any more concrete suggestions you are
welcome to bring them to the performance-list.

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Memory consumption

[Ross Burton]

On Fri, 2005-11-25 at 20:15 +0300, Andrejj Karavaev wrote:
 True: 810kb - in resident memory, and ~10Mb in swap - as i remember.
 Some times system needs to working with swap and it is
 very slow. The most of all it becames in multiuser system/server.

How is swap involved in this?  Surely you mean ~10M mapped, which is
something totally different, as the majority of that (about 9M) will be
shared with all other GTK+ applications.  pmap will tell you where the
memory of a process is going, any pages marked r-x from libraries are
shared between every process which is using them.

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: May gdk_pixmap_ref assert when GDK_IS_PIXMAP is true?

[Ross Burton]

On Mon, 2005-10-31 at 19:03 +, Clemens Eisserer wrote:
  run valgrind

 Thats a real great idea, valgrind - on ARM, yep.
 I just wonder what valgrind should do with the x86 code generated,
 maybe print it to stdout or save it in a file.
 Hmm, quite nice...

Run the code on a x86 machine, an incorrect memory access in still an
incorrect memory access (unless it's an alignment bug, in which case you
can fiddle a file in /proc to get a special signal).

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF


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

Re: cairo theme engines?

[Ross Burton]

On Wed, 2005-07-27 at 09:29 -0400, Luis Villa wrote:
 Hey... as I was putting together the demo livecd for the next release,
 it struck me that I can't really demo the cairo stuff in gtk much,
 besides the color picker :) Is there a publicly released cairo-using
 theme engine somewhere that I could build and ship as something to
 show off? (Presumably not the default.)

cairo-gtk-engines contains the engines Owen was showing off at GUADEC.

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

GTK+ tutorial to Docbook XML?

[Ross Burton]

Hi,

In Debian we ship a .devhelp file for the GTK+ tutorial, but it has got
out of date.  I believe it was originally hand-generated, but if the
tutorial was converted to Docbook XML then the gtk-doc stylesheets could
be used to make a .devhelp file automatically.

Are there any objections to me updating the GTK+ documentation (tutorial
and FAQ) to use Docbook XML (4.2) instead of Docbook 3.1 SGML?  This
would have the side effect of using libxslt/xsltproc to transform to
HTML instead of db2html.

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list