On Fri, 04 May 2007 10:27:34 -0400, Havoc Pennington wrote:
> It's a run-time env variable. I think we don't advertise it at all, it's
> more of a defense against people who have strong views on the topic and
> prefer "undefined behavior probably a crash" to "just exit" ...
And one thing to note h
Hi,
First of all, excuse me if this is the wrong instance to report a gtk
issue in windows. Just followed the link from GTK for Windows
http://www.gimp.org/~tml/gimp/win32/
I've executed the following code in Python:
http://www.dinko.cl/~dinko/test-py.html
And performed the following actions as
On 5/3/07, Cezary Krzyzanowski <[EMAIL PROTECTED]> wrote:
> So first I propose to make some note in the documentation (and maybe in
> the FAQ), that the supplied dialog needs to have RESPONSE_ACCEPT as the
> positive result.
>
> The second thing is to stop GTKFileChooserButton from changing the ti
I just had a chat with Alex on IRC. (I have attached the log if anyone
wants to read it.) Some of my ideas have changed after this
discussion, so I might contradict my previous mail now. Bear with me.
I've come to understand now that Alex' and my idea for what a stream
is and how it should work ar
On Fri, 2007-05-04 at 09:00 -0500, Jerry Haltom wrote:
> Why doesn't HAL use UUIDs?
Doesn't exactly make sense. Maybe you mean: "Why does my mount points
not use UUID?". Understand that HAL [1] is only a source of information
+ mechanism to allow g-v-m, KDE, gnome-mount, whatever to mount file
sy
On Fri, 2007-05-04 at 09:00 -0500, Jerry Haltom wrote:
>
> Why doesn't HAL use UUIDs? I'd say probably because up until now there
> was no abstraction to turn those UUIDs into usefully understandable
> paths for the user. If you plug in a USB disk and open Nautilus, you see
> the /media/usbdisk-1
Hi,
Carl Worth wrote:
> Anyway, I've learned a few new things, and found the discussion very
> useful. I hope you have as well.
Certainly.
> By the way, is that a compile-time or a run-tim environment variable?
> And what measures do you take to advertise it?
It's a run-time env variable. I thi
On Fri, 2007-05-04 at 15:27 +0200, Mathieu Lacage wrote:
> > > 5) You seem to use void * in as the data pointers. All applications I
> > > know use guchar * (some use gchar *) to handle data. From my stream
> > > handling experience this is to encourage people to think about what
> > > they pass t
On Fri, 2007-05-04 at 11:40 +0200, Alexander Larsson wrote:
> > 5) You seem to use void * in as the data pointers. All applications I
> > know use guchar * (some use gchar *) to handle data. From my stream
> > handling experience this is to encourage people to think about what
> > they pass to suc
On Tue, May 01, 2007 at 07:47:25PM -0500, Federico Mena Quintero wrote:
> > I don't think having widget-specific tap-n-hold animations is a good idea;
> > I would say that this is really a theme issue and it would be good if
> > every tap-n-hold operation "looks the same" the to user.
>
> You have
On Thu, 2007-05-03 at 11:11 +0200, Benjamin Otte wrote:
> Hi,
>
> I had an initial look at gvfs in particular the Inputstream and
> Outputstream implementations, and some comments came to my mind, in
> particular about the API. So I thought I'd post them as early as
> possible.
> These comments ar
On Fri, 4 May 2007, Gabriel Schulhof wrote:
> Hi!
>
> I don't know how much of an ABI break this would be, since all current
> code ignores the non-existent return value of g_object_get_property.
>
> OTOH, were we to have
>
> GValue *g_object_get_property (GObject *object, const gchar
> *property_
On 5/4/07, la deng <[EMAIL PROTECTED]> wrote:
> Then ,what's the power of gobject vs c++ with the compiler's
> Intelligence in OOP?
I think the usual answers are:
1) portability: you can get a standard C compiler anywhere; C++ (at
least back when gtk was started) is less portable
2) ease of lang
reference to the c++'s father's interview
http://www.artima.com/intv/abstreffi.html
fortran and c++ can achive good performance for they can abstract in
higher level and their compiler can think in higher level to avoid
the cache miss (like in the array vs vector )or to achive the "no
code"
T
On Thu, 2007-05-03 at 10:18 -0500, Jerry Haltom wrote:
> > The selection of whether to do local or remote i/o is done when
> > instantiating the GFile. We instantiate a GLocalFile or a GDaemonFile
> > depending on the uri and the default GVfs instance loaded. However, the
> > mapping from URI to wh
On Thu, 2007-05-03 at 15:18 -0400, David Zeuthen wrote:
> On Thu, 2007-05-03 at 10:14 +0200, Alexander Larsson wrote:
> > The way a normal application uses gvfs is by the gio apis. Essentially
> > you hand over a uri, and this uri is parsed by custom uri-type specific
> > code into a mount specific
Hi!
I don't know how much of an ABI break this would be, since all current
code ignores the non-existent return value of g_object_get_property.
OTOH, were we to have
GValue *g_object_get_property (GObject *object, const gchar
*property_name, GValue *value);
We could do nice things like
GValue
On Thu, 2007-05-03 at 15:45 -0400, David Zeuthen wrote:
> On Thu, 2007-05-03 at 16:59 +0200, Alexander Larsson wrote:
> > The selection of whether to do local or remote i/o is done when
> > instantiating the GFile. We instantiate a GLocalFile or a GDaemonFile
> > depending on the uri and the defaul
18 matches
Mail list logo