On 09/27/2012 04:48 PM, Ivan Shmakov wrote:
> $ HOME=/net/home/jrh emacs
>
> Moreover, GNU Bash started under such a Emacs instance will also
> use /net/home/jrh/.bashrc (instead of /home/jrh/.bashrc), and so
> will GNU Wget, or Lynx, and a sheer variety of other tools.
>
>
On 08/10/2012 12:43 PM, Mario Sanchez Prada wrote:
> However, I understand some might see the fact of exposing the number of
> masked characters as a security issue, so that's why I'm asking for
> feedback here now.
If an application exposes the number of characters to be rendered on the
screen, t
On 08/06/2012 05:56 PM, Paul Davis wrote:
> i don't believe that there are any examples in glib/gdk/gtk where a
> signal handler attached to a signal of a glib/gdk/gtk object will be
> executed in anything other than the main event loop.
Does GIO count? Off the top of my head:
* GDBusInterfaceS
On 07/22/2012 10:28 PM, John Emmas wrote:
> Your comments are absolutely valid Simon (as are everyone else's) but
> I fear we've drifted into a siding here.
>
> The basic problem is that GTK+ has lost two very high calibre
> developers in a very short space of time.
I wasn't going to comment, b
On 07/16/2012 09:40 PM, Damon Register wrote:
> It's just for the introspection.m4 file; you should be able to copy it
> into the m4/ directory in the GTK+ source.
In general, should we be copying introspection.m4 into our projects?
Cheers,
Stef
___
gt
On 05/25/2012 11:14 PM, Mike wrote:
> Unfortunately, I just managed to get this error to trigger now even
> with the optimization changes, which is probably good -- I'd like to
> trust the compiler! In any case, is there a document anywhere that
> describes the different threads that glib sets up?
On 05/22/2012 04:46 PM, Michael Meeks wrote:
>
> On Tue, 2012-05-22 at 16:07 +0200, Stef Walter wrote:
>> If you have more details/links on how VCL gets around this, I'd be
>> interested. A bit of a morbid curiosity perhaps :P
>
> Sure; here is some of it:
>
On 05/22/2012 01:03 PM, Michael Meeks wrote:
>> Even if you get the locking "right" -- even if absolutely only one
>> thread is executing at once in your process -- like Paul said, you still
>> get behavior that at a minimum freezes your window, and in other cases
>> can act a lot like memory corru
On 05/21/2012 04:18 PM, Paul Davis wrote:
> On Mon, May 21, 2012 at 9:39 AM, Michael Meeks
wrote:
> >That claim sounds really strange; since - well - we do that in
> > LibreOffice ourselves :-)
> >
>
> Windows does not allow you to process events/messages for a given window
> in
On 2012-03-26 13:43, John Emmas wrote:
The above code gives me a handle which is functionally equivalent to a
Glib file handle (it can be used with read() and write() etc) BUT the
file can be renamed - even when open.
Reaching back into my memory of windows development past here ... but
won't
I've completed much of the work on GTlsDatabase. I left this work idle
for quite a while, sorry bout that.
But the good news is that I've used glib-networking with the gnutls
backend to connect to a https website with a key+certificate stored on a
smart card, so a lot of the pieces are in place an
On 2010-10-07 16:29, Tadej Borovšak wrote:
> You should definitely not modify values in returned array, since this
> central part of GtkTreePath. Currently, modifying parts of this array
> is the same as moving your path using gtk_tree_path_(next|prev)(), but
> if internal structure of GtkTreePath
Is the integer array returned from gtk_tree_path_get_indices() writable
by design? Or should it be treated as readonly?
Some stuff like GtkTreeModelSort and GtkTreeModelFilter write to this
index array, but those may be liberties taken by gtk+ internally.
Perhaps we would change the return values
On 2010-05-01 16:22, Ray Strode wrote:
> Hi,
>
> On Fri, Apr 30, 2010 at 11:51 AM, Stef Walter
> wrote:
>>> Could you give more details please? Thanks.
>>
>> For reasons that are almost, but not entirely, clear to me you have to:
>>
>> 1. Bloc
On 2010-04-30 13:38, Matthew Bucknall wrote:
> Find attached an excerpt from an application of mine. Not entirely
> self-contained, but you should get a general idea of what is going on.
>
> Using the attached code, my application calls app_signal_block_unused()
> early on during initialization. T
On 2010-04-30 10:51, Stef Walter wrote:
> On 2010-04-30 08:53, Richard Hughes wrote:
>> On 30 April 2010 14:36, Stef Walter wrote:
>>> Remember that this doesn't work correctly in threaded apps, as we found
>>> in gnome-keyring-daemon. You have to do the strange
On 2010-04-30 08:53, Richard Hughes wrote:
> On 30 April 2010 14:36, Stef Walter wrote:
>> Remember that this doesn't work correctly in threaded apps, as we found
>> in gnome-keyring-daemon. You have to do the strange
>> signal-handling-thread-thing.
>
> Co
On 2010-04-30 03:56, Andy Wingo wrote:
> On Fri 30 Apr 2010 10:23, Xavier Bestel writes:
>
>> On Fri, 2010-04-30 at 09:18 +0100, Richard Hughes wrote:
>>> I'm writing for comments. Making my daemons (upower, PackageKit, etc)
>>> quit nicely after receiving SIGTERM or SIGINT is _really_ hard to do
Emmanuele Bassi wrote:
> 1. bug 600141 (desrt)
> - dbus-1 brings in pthread
> - gio-2.0 doesn't
> - dlopen()-ing a shared object linking to pthread from a library
> that doesn't is a big no-no which kind of works in Linux but
> breaks things like gdb
> - big hammer: make gio-2.0 depend on gthre
b0unc3 wrote:
> 2009/4/10 Nelson Benítez León
>> Another way,
>>
>> substring (GString *str, int index, int len)
>> {
>> return g_string_new_len (str->str, index, MIN (str->len - index, len));
>> }
>>
>
> First of all thanks to everyone who replayed.
> The implementation using g_srtndup looks
Kristian Høgsberg wrote:
> So unless we find a show-stopper bug in the import
> within the next few days, what's on git.gnome.org now is final.
Not a show stopper, but it'd be cool to migrate the svn-ignore property
over into .gitignore files. Or is this to be handled some other way?
Cheers,
St
Matthias Clasen wrote:
> On Thu, Mar 26, 2009 at 5:38 PM, Stef Walter > That may be the case, and I thought about this myself. One thing in
>> favor of doing the conversion of 'real text' -> 'display text' in the
>> model is that it allows subclassed models
Christian Dywan wrote:
> this looks a little bit more complex than it should be, from my first
> impression anyway. Essentially I would think you need this kind of
> 'workflow' in the application code, once you have a buffer implemented:
>
> entry = gtk_entry_new ();
> buffer = gnome_keyring_entry
Tristan Van Berkom wrote:
>> * gtk_entry_buffer_get_visibility
>> * gtk_entry_buffer_set_visibility
>> * gtk_entry_buffer_get_invisible_char
>> * gtk_entry_buffer_set_invisible_char
>> * gtk_entry_buffer_unset_invisible_char
>> * gtk_entry_buffer_have_invisible_char
>
> I have a feeling
A while back [1] I tackled the possibility of having GtkEntry store it's
text in a application configurable memory buffer. This makes GtkEntry
very useful for use with gnome-keyring and seahorse passwords/secrets [2].
I've given it another shot, and come up with what I think is a much
better appro
Mark Mielke wrote:
> I think fsync() is absolutely necessary to be explicit in this
> situation, because the application needs to assert that all data is
> written *before* using rename to perform the atomic-change-in-place
> effect. I think that anybody who thinks fsync() is unnecessary is
> faili
26 matches
Mail list logo
