On 9/25/06, Attilio Fiandrotti <[EMAIL PROTECTED]> wrote:
> And the DFB backend was indeed found to be broken by the gtk-gnome
> Debian team when they tried to build a DFB flavour of GTK for use in the
> debian-installer.
> Is there a way to check if the DirctFB backend builds correctly before a
>
Thanks Tor,
How can I using get the stack trace sysinternals's Process Explorer
(I've downloaded it).
My program is actually a dynamically loaded plugin that runs in a very
large app (i.e. Alias|Wavefront Maya). Can I still see the stack trace?
I'm would really like to know where what's causi
Hi -
Newbie here.
My app uses the GTS library which in turn relies on (heavily on GLIB. My
code compiles fine, but if run my the executable from a network drive
(letter H), I get the message:
Unhandled Exception: System.Security.Policy.PolicyException:
Unverifiable assembly 'H:\path\to\program
OSX was missed also btw the change Behdad had me make effected it too.
On 9/25/06, Loïc Minier <[EMAIL PROTECTED]> wrote:
> On Mon, Sep 25, 2006, Attilio Fiandrotti wrote:
> > And the DFB backend was indeed found to be broken by the gtk-gnome
> > Debian team when they tried to build a DFB flavour
On Mon, Sep 25, 2006, Attilio Fiandrotti wrote:
> And the DFB backend was indeed found to be broken by the gtk-gnome
> Debian team when they tried to build a DFB flavour of GTK for use in the
> debian-installer.
I just cvs updated the gtk-2-10 branch, and it's still lacking these
fixes:
- rep
And the DFB backend was indeed found to be broken by the gtk-gnome
Debian team when they tried to build a DFB flavour of GTK for use in the
debian-installer.
Is there a way to check if the DirctFB backend builds correctly before a
major GTK relase, like (i guess) is done for X and win32 backends
On Mon, 25 Sep 2006, Alexander Larsson wrote:
> On Mon, 2006-09-25 at 13:00 +0200, Tim Janik wrote:
>> On Mon, 25 Sep 2006, Alexander Larsson wrote:
>>
>>> On Sun, 2006-09-24 at 14:33 +0200, Philip Van Hoof wrote:
On Wed, 2006-09-20 at 12:31 +0200, Alexander Larsson wrote:
Hey Alex,
On Mon, 2006-09-25 at 13:00 +0200, Tim Janik wrote:
> On Mon, 25 Sep 2006, Alexander Larsson wrote:
>
> > On Sun, 2006-09-24 at 14:33 +0200, Philip Van Hoof wrote:
> >> On Wed, 2006-09-20 at 12:31 +0200, Alexander Larsson wrote:
> >>
> >> Hey Alex,
> >>
> >> Great that you are planning to redesign
On Mon, 25 Sep 2006, Murray Cumming wrote:
>
>> On Mon, 2006-09-25 at 09:16 +0200, Alexander Larsson wrote:
>>> On Sun, 2006-09-24 at 14:33 +0200, Philip Van Hoof wrote:
On Wed, 2006-09-20 at 12:31 +0200, Alexander Larsson wrote:
Hey Alex,
Great that you are planning to re
On Mon, 25 Sep 2006, Emmanuele Bassi wrote:
> On Mon, 2006-09-25 at 09:16 +0200, Alexander Larsson wrote:
>> On Sun, 2006-09-24 at 14:33 +0200, Philip Van Hoof wrote:
>>> On Wed, 2006-09-20 at 12:31 +0200, Alexander Larsson wrote:
>>>
>>> Hey Alex,
>>>
>>> Great that you are planning to redesign t
> On Mon, 2006-09-25 at 09:16 +0200, Alexander Larsson wrote:
>> On Sun, 2006-09-24 at 14:33 +0200, Philip Van Hoof wrote:
>> > On Wed, 2006-09-20 at 12:31 +0200, Alexander Larsson wrote:
>> >
>> > Hey Alex,
>> >
>> > Great that you are planning to redesign the VFS.
>> >
>> > > Here is my current
On Mon, 2006-09-25 at 09:16 +0200, Alexander Larsson wrote:
> On Sun, 2006-09-24 at 14:33 +0200, Philip Van Hoof wrote:
> > On Wed, 2006-09-20 at 12:31 +0200, Alexander Larsson wrote:
> >
> > Hey Alex,
> >
> > Great that you are planning to redesign the VFS.
> >
> > > Here is my current GInputSt
On Mon, 2006-09-25 at 12:47 +0200, Tim Janik wrote:
> On Mon, 25 Sep 2006, Alexander Larsson wrote:
> > Also, In your example above the extra structure isn't needed. One would
> > just use different destroy notifiers for the two streams.
>
> hm, different? you mean you'd encode whether it's strea
On Mon, 2006-09-25 at 11:40 +0200, Tim Janik wrote:
> hm, in your initial proposal, you said that apps don't currently have control
> over whether they want to use/care about threading or not. so, are you
> planning for a way to use the GVFS API without threading under the hood?
> then, emulation
On Thu, 21 Sep 2006, Jalagandeswari G wrote:
> Hi All,
> When a new window is created in X window System CreateNotify event is passed.
> Is it right?
>
> what is the event type which is passed while creating a new window in GDK ?
>
> What is the equivalent event type in GTK/GDK for CreateNotify i
On Mon, 25 Sep 2006, Alexander Larsson wrote:
> On Sun, 2006-09-24 at 14:33 +0200, Philip Van Hoof wrote:
>> On Wed, 2006-09-20 at 12:31 +0200, Alexander Larsson wrote:
>>
>> Hey Alex,
>>
>> Great that you are planning to redesign the VFS.
>>
>>> Here is my current GInputStream:
>>>
>>> struct _GI
On Mon, 25 Sep 2006, Alexander Larsson wrote:
> On Mon, 2006-09-25 at 12:04 +0200, Tim Janik wrote:
>> On Wed, 20 Sep 2006, Alexander Larsson wrote:
>>
>>> On Wed, 2006-09-20 at 14:30 +0200, mathieu lacage wrote:
>
>> 2) What is the signature of GDestroyNotify ?
>
> Its already in
On Mon, 2006-09-25 at 12:04 +0200, Tim Janik wrote:
> On Wed, 20 Sep 2006, Alexander Larsson wrote:
>
> > On Wed, 2006-09-20 at 14:30 +0200, mathieu lacage wrote:
> >>>
> 2) What is the signature of GDestroyNotify ?
> >>>
> >>> Its already in gtypes.h:
> >>> typedef void(*GDestroy
On Mon, 2006-09-25 at 11:51 +0200, Tim Janik wrote:
> I think I see some confusion about the API abstraction layers here.
> > Consider the vfs as a switch for the filesystem layer.
>
> jup, that's exactly what i do. in terms of the unix FS layer, this'd
> basically allow every app to provide a FUS
On Wed, 20 Sep 2006, Alexander Larsson wrote:
> On Wed, 2006-09-20 at 14:30 +0200, mathieu lacage wrote:
>>>
2) What is the signature of GDestroyNotify ?
>>>
>>> Its already in gtypes.h:
>>> typedef void(*GDestroyNotify) (gpointer data);
>>
>> ah. I forgot about this.
On Mon, 25 Sep 2006, Alexander Larsson wrote:
> On Mon, 2006-09-25 at 11:17 +0200, Tim Janik wrote:
>
>> i haven't seen API proposals yet (allthough i haven't managed to read through
>> all of this thread yet either ;) so please bear with me if this is covered
>> by your ideas already...
>>
>> to
On Wed, 20 Sep 2006, Alexander Larsson wrote:
> Here is my current GInputStream:
>
> struct _GInputStreamClass
> {
> GObjectClass parent_class;
>
> /* Sync ops: */
>
> gssize (* read)(GInputStream *stream,
> void *buffer,
> g
On Mon, 2006-09-25 at 11:17 +0200, Tim Janik wrote:
> i haven't seen API proposals yet (allthough i haven't managed to read through
> all of this thread yet either ;) so please bear with me if this is covered
> by your ideas already...
>
> to allow applications to extend on the mechanisms and fac
On Wed, 20 Sep 2006, Alexander Larsson wrote:
> From just reading your post, without deeper insight into what you mean I
> would be hesitant to add something like that to glib. Its not clear that
> applications need it, and its not clear the the solution we create is
> good enough for the applicat
On Sun, 2006-09-24 at 14:33 +0200, Philip Van Hoof wrote:
> On Wed, 2006-09-20 at 12:31 +0200, Alexander Larsson wrote:
>
> Hey Alex,
>
> Great that you are planning to redesign the VFS.
>
> > Here is my current GInputStream:
> >
> > struct _GInputStreamClass
> > {
> > GObjectClass parent_cla
On Fri, 2006-09-22 at 14:29 +0200, ext Tim Janik wrote:
> well, instead of hacking *every* widget realize function, you could have
> written a simple loop that walks all GdkWindow children of widget->window
> recursively and applies extension events as long as gdk_window_get_user_data()
> == widget
26 matches
Mail list logo
