Nor Jaidi Tuah wrote:
> > The compiled code is something like this (from memory):
> >
> >self = uazu_win_widget_construct(uazu_win_display_relayout_imp, self);
> >
> > i.e. the delegate is a dual-pointer (func, target), with 'self' as the
> > second part. But 'self' hasn't yet been initialis
> The compiled code is something like this (from memory):
>
>self = uazu_win_widget_construct(uazu_win_display_relayout_imp, self);
>
> i.e. the delegate is a dual-pointer (func, target), with 'self' as the
> second part. But 'self' hasn't yet been initialised, because the
> widget construc
Nor Jaidi Tuah wrote:
> > This seems okay so far, but here comes the killer:
> >
> > public class Display : Widget {
> > public Display() {
> > base(relayout_imp);
> > }
> > private void relayout_imp() { ... }
> > }
> >
> > This crashes when relayout() is called because
> This seems okay so far, but here comes the killer:
>
> public class Display : Widget {
> public Display() {
> base(relayout_imp);
> }
> private void relayout_imp() { ... }
> }
>
> This crashes when relayout() is called because the 'relayout_imp'
> argument to the cons
This is an inconvenience rather than a project-killer, but still ...
I know that the Java page suggests that instead of using anonymous
classes, to use delegates, but it just doesn't work out as hoped.
For example (much simplified):
public abstract class Widget : Object {
public abstract
The first approach seems basic and very good, but I'm just wondering about
asnc...
You've got me wrong there, I don't want to block glib main loop and wait until
it finishes rendering, I just wonder about this behavior:
Suppose that user move forward when he press "w" in speed of 2(m)/(s) .
Now
> Thank you. If I get you right, this will block events until I finish drawing,
> but that is the purpose.
> And is it possible to do it multi-threaded? In a way that input thread is
> different than drawing thread?
Well, the glib mainloop always needs to be on the thread where glib is
initializ
