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,
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:
*
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, but
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:
http://cgit.freedesktop.org
On 05/21/2012 04:18 PM, Paul Davis wrote:
On Mon, May 21, 2012 at 9:39 AM, Michael Meeks
michael.me...@suse.com 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
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 corruption.
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
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
On 2010-05-01 16:22, Ray Strode wrote:
Hi,
On Fri, Apr 30, 2010 at 11:51 AM, Stef Walter stef-l...@memberwebs.com
wrote:
Could you give more details please? Thanks.
For reasons that are almost, but not entirely, clear to me you have to:
1. Block signals you're interested in on all
On 2010-04-30 03:56, Andy Wingo wrote:
On Fri 30 Apr 2010 10:23, Xavier Bestel xavier.bes...@free.fr 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
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. The
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 gthread-2.0
b0unc3 wrote:
2009/4/10 Nelson Benítez León nbenit...@gmail.com
Another way,
substring (GString *str, int index, int len)
{
return g_string_new_len (str-str, index, MIN (str-len - index, len));
}
snip
First of all thanks to everyone who replayed.
The implementation using g_srtndup
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,
Matthias Clasen wrote:
On Thu, Mar 26, 2009 at 5:38 PM, Stef Walter stef-
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 to do some quite interesting
stuff
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 these apis
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
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
failing
21 matches
Mail list logo
