Native Window, again

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

Native Window, again

panyasan
Hello list,

I have asked this before but have been unsuccessful in attracting anyone's interest. New try: I want to use native browser windows in my application. If I create a new window with

var win = qx.bom.Window.open();

I get a native Window object which doesn't contain any reference to the qooxdoo object tree. How can I create qooxdoo widgets within this window? Or isn't that supported any more - it had been, I remember as much.

Thanks,

Christian
Reply | Threaded
Open this post in threaded view
|

Re: Native Window, again

Fabian Jakobs
Administrator
Hi Christian,

> I have asked this before but have been unsuccessful in attracting anyone's
> interest. New try: I want to use native browser windows in my application.
> If I create a new window with
>
> var win = qx.bom.Window.open();
>
> I get a native Window object which doesn't contain any reference to the
> qooxdoo object tree. How can I create qooxdoo widgets within this window? Or
> isn't that supported any more - it had been, I remember as much.
>  
qooxdoo is not yet multi-document ready. It is possible to render
widgets and listen for events but there are places in the framework,
which assume that only one root widget exists. Drag and drop, tooltips
or menus are such examples. It might be possible to make it happen but
it would require some deeper changes.

Best Fabian



--
Fabian Jakobs
JavaScript Framework Developer

1&1 Internet AG - Web Technologies
Ernst-Frey-Straße 9 · DE-76135 Karlsruhe
Telefon: +49 721 91374-6784
[hidden email]

Amtsgericht Montabaur / HRB 6484
Vorstände: Henning Ahlert, Ralph Dommermuth, Matthias Ehrlich, Thomas Gottschlich, Robert Hoffmann, Markus Huhn, Hans-Henning Kettler, Dr. Oliver Mauss, Jan Oetjen
Aufsichtsratsvorsitzender: Michael Scheeren


------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: Native Window, again

panyasan
Fabian Jakobs wrote
Hi Christian,
> I have asked this before but have been unsuccessful in attracting anyone's
> interest. New try: I want to use native browser windows in my application.
> If I create a new window with
>
> var win = qx.bom.Window.open();
>
> I get a native Window object which doesn't contain any reference to the
> qooxdoo object tree. How can I create qooxdoo widgets within this window? Or
> isn't that supported any more - it had been, I remember as much.
>  
qooxdoo is not yet multi-document ready. It is possible to render
widgets and listen for events but there are places in the framework,
which assume that only one root widget exists. Drag and drop, tooltips
or menus are such examples. It might be possible to make it happen but
it would require some deeper changes.

Best Fabian
Hello Fabian,

thanks for the info. As long as very basic functionality exists, I'd
be happy. I basically only need to be able to render forms and maybe
also a table - nothing fancy. But how would I go about doing it? Do I
need to import the qx global object into the new window's scope by
simply doing win.qx = qx and then instantiate widgets with var a= new
win.qx.ui.basic.Atom()? Or is there a special way of doing it?

Thanks,

Christian
Reply | Threaded
Open this post in threaded view
|

Re: Native Window, again

Fabian Jakobs
Administrator
Hi Christian,
> Hello Fabian,
>
> thanks for the info. As long as very basic functionality exists, I'd
> be happy. I basically only need to be able to render forms and maybe
> also a table - nothing fancy. But how would I go about doing it? Do I
> need to import the qx global object into the new window's scope by
> simply doing win.qx = qx and then instantiate widgets with var a= new
> win.qx.ui.basic.Atom()? Or is there a special way of doing it?
>  
I would try it from the outside of the iframe. Just load a blank html
file into the iframe. Then you can add a root widget to the iframe

var iframeRoot = new
qx.ui.root.Application(qx.bom.Iframe.getDocument(iframeElement));

than place your widgets into the the iframe root widget. Still I'm not
sure how well this will work. I'd be very interested in your results.

Best Fabian


--
Fabian Jakobs
JavaScript Framework Developer

1&1 Internet AG - Web Technologies
Ernst-Frey-Straße 9 · DE-76135 Karlsruhe
Telefon: +49 721 91374-6784
[hidden email]

Amtsgericht Montabaur / HRB 6484
Vorstände: Henning Ahlert, Ralph Dommermuth, Matthias Ehrlich, Thomas Gottschlich, Robert Hoffmann, Markus Huhn, Hans-Henning Kettler, Dr. Oliver Mauss, Jan Oetjen
Aufsichtsratsvorsitzender: Michael Scheeren


------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: Native Window, again

panyasan

Fabian Jakobs wrote
I would try it from the outside of the iframe. Just load a blank html
file into the iframe. Then you can add a root widget to the iframe

var iframeRoot = new
qx.ui.root.Application(qx.bom.Iframe.getDocument(iframeElement));

than place your widgets into the the iframe root widget. Still I'm not
sure how well this will work. I'd be very interested in your results.
I didn't try the Iframe, but experimented with the native window. This is how far I got:

Loag this in the playground (current trunk):

var win = new qx.bom.Window.open();
win.document.write("<html><body /></html>");
win.document.close();

var root = new qx.ui.root.Application(win.document);

// Create a button
var button1 = new qx.ui.form.Button("First Button", "icon/22/apps/internet-web-browser.png");

// Add button to document at fixed coordinates
root.add(button1,
{
  left : 100,
  top  : 50
});

// Add an event listener
button1.addListener("execute", function(e) {
  alert("Hello World!");
});

The button is correctly displayed, but the event handler is not called. I guess the event handling is the real issue - there was a mesage on the list a long time ago on this.

Best,

Christian


Reply | Threaded
Open this post in threaded view
|

Re: Native Window, again

panyasan
Looking through the code, my assumption is that it has to do with qx.event.Registration.getManager(). The event manager is chosen according to the global "window" object (line 78). This is really tricky, because the event target is instantiated in the parent window, and not in the child window. I wonder if an additional argument could be added to addListener(), i.e. "addListener("type",handler,this,window), so that the correct window context could be figured out by the getManager() method.

panyasan wrote
Fabian Jakobs wrote
I would try it from the outside of the iframe. Just load a blank html
file into the iframe. Then you can add a root widget to the iframe

var iframeRoot = new
qx.ui.root.Application(qx.bom.Iframe.getDocument(iframeElement));

than place your widgets into the the iframe root widget. Still I'm not
sure how well this will work. I'd be very interested in your results.
I didn't try the Iframe, but experimented with the native window. This is how far I got:

Loag this in the playground (current trunk):

var win = new qx.bom.Window.open();
win.document.write("<html><body /></html>");
win.document.close();

var root = new qx.ui.root.Application(win.document);

// Create a button
var button1 = new qx.ui.form.Button("First Button", "icon/22/apps/internet-web-browser.png");

// Add button to document at fixed coordinates
root.add(button1,
{
  left : 100,
  top  : 50
});

// Add an event listener
button1.addListener("execute", function(e) {
  alert("Hello World!");
});

The button is correctly displayed, but the event handler is not called. I guess the event handling is the real issue - there was a mesage on the list a long time ago on this.

Best,

Christian

Reply | Threaded
Open this post in threaded view
|

Re: Native Window, again

panyasan

panyasan wrote
Looking through the code, my assumption is that it has to do with qx.event.Registration.getManager(). The event manager is chosen according to the global "window" object (line 78). This is really tricky, because the event target is instantiated in the parent window, and not in the child window. I wonder if an additional argument could be added to addListener(), i.e. "addListener("type",handler,this,window), so that the correct window context could be figured out by the getManager() method
I tried to patch the code to retrieve the window of the event target object from getContainerElement().getDomElement(), but I guess that would have been too easy. ;-) The result was that clicking on the Button no longer worked (before it did, but the "execute" event was not fired). I guess random hacking without understanding the internals doesn't make much sense here. There is a bug for that in bugzilla already. I would be thrilled if the core team would find the issue interesting enough to invest some development time.  I am happy to work on this if I get some clues as to what would need to be changed.

Thanks,
Christian
Reply | Threaded
Open this post in threaded view
|

Re: Native Window, again

panyasan
Hi, is there any interest? Just let me know if this is no priority at all, then I'll stop asking - I won't be able to solve this on my own.

Thanks,
C.

panyasan wrote
panyasan wrote
Looking through the code, my assumption is that it has to do with qx.event.Registration.getManager(). The event manager is chosen according to the global "window" object (line 78). This is really tricky, because the event target is instantiated in the parent window, and not in the child window. I wonder if an additional argument could be added to addListener(), i.e. "addListener("type",handler,this,window), so that the correct window context could be figured out by the getManager() method
I tried to patch the code to retrieve the window of the event target object from getContainerElement().getDomElement(), but I guess that would have been too easy. ;-) The result was that clicking on the Button no longer worked (before it did, but the "execute" event was not fired). I guess random hacking without understanding the internals doesn't make much sense here. There is a bug for that in bugzilla already. I would be thrilled if the core team would find the issue interesting enough to invest some development time.  I am happy to work on this if I get some clues as to what would need to be changed.

Thanks,
Christian
Reply | Threaded
Open this post in threaded view
|

Re: Native Window, again

Fabian Jakobs
Administrator
Hi Christian,
> Hi, is there any interest? Just let me know if this is no priority at all,
> then I'll stop asking - I won't be able to solve this on my own.
>  
I am interested in this, sorry for the delay. The problem is the our
event system needs to know to which document an element/widget belongs.
Since events are sometimes attached before the elements/widgets are
added to the document, the event system cannot know how to handle them.
In these cases is uses the top level document, which leads to the
problems you have seen. To solve this I guess we would have to refactor
the event system. I would like to do this myself but currently this has
very low priority. I can offer you my help but this will probably be
tough :-)

Best Fabian

>> panyasan wrote:
>>    
>>> Looking through the code, my assumption is that it has to do with
>>> qx.event.Registration.getManager(). The event manager is chosen according
>>> to the global "window" object (line 78). This is really tricky, because
>>> the event target is instantiated in the parent window, and not in the
>>> child window. I wonder if an additional argument could be added to
>>> addListener(), i.e. "addListener("type",handler,this,window), so that the
>>> correct window context could be figured out by the getManager() method
>>>
>>>
>>>      
>> I tried to patch the code to retrieve the window of the event target
>> object from getContainerElement().getDomElement(), but I guess that would
>> have been too easy. ;-) The result was that clicking on the Button no
>> longer worked (before it did, but the "execute" event was not fired). I
>> guess random hacking without understanding the internals doesn't make much
>> sense here. There is a bug for that in bugzilla already. I would be
>> thrilled if the core team would find the issue interesting enough to
>> invest some development time.  I am happy to work on this if I get some
>> clues as to what would need to be changed.
>>
>> Thanks,
>> Christian
>>
>>    
>
>  


--
Fabian Jakobs
JavaScript Framework Developer

1&1 Internet AG - Web Technologies
Ernst-Frey-Straße 9 · DE-76135 Karlsruhe
Telefon: +49 721 91374-6784
[hidden email]

Amtsgericht Montabaur / HRB 6484
Vorstände: Henning Ahlert, Ralph Dommermuth, Matthias Ehrlich, Thomas Gottschlich, Robert Hoffmann, Markus Huhn, Hans-Henning Kettler, Dr. Oliver Mauss, Jan Oetjen
Aufsichtsratsvorsitzender: Michael Scheeren


------------------------------------------------------------------------------
Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9&#45;12, 2009. Register now&#33;
http://p.sf.net/sfu/devconf
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: Native Window, again

panyasan
Fabian Jakobs wrote
I am interested in this, sorry for the delay. The problem is the our
event system needs to know to which document an element/widget belongs.
Since events are sometimes attached before the elements/widgets are
added to the document, the event system cannot know how to handle them.
In these cases is uses the top level document, which leads to the
problems you have seen. To solve this I guess we would have to refactor
the event system. I would like to do this myself but currently this has
very low priority. I can offer you my help but this will probably be
tough :-)
Hi Fabian, thanks for the reply.

That's what I thought. It is really tricky. One way of doing it could be to add a method that remaps all attached events in the context of the new window. This method could then be called from different places in the framework which deal with adding event listeners or adding widgets. Do you think this could be a solution?

Christian
Reply | Threaded
Open this post in threaded view
|

Re: Native Window, again

panyasan

panyasan wrote
Fabian Jakobs wrote
I am interested in this, sorry for the delay. The problem is the our
event system needs to know to which document an element/widget belongs.
Since events are sometimes attached before the elements/widgets are
added to the document, the event system cannot know how to handle them.
In these cases is uses the top level document, which leads to the
problems you have seen. To solve this I guess we would have to refactor
the event system. I would like to do this myself but currently this has
very low priority. I can offer you my help but this will probably be
tough :-)
Hi Fabian, thanks for the reply.

That's what I thought. It is really tricky. One way of doing it could be to add a method that remaps all attached events in the context of the new window. This method could then be called from different places in the framework which deal with adding event listeners or adding widgets. Do you think this could be a solution?

Christian
I've done some experimenting but have to admit that I don't know enough about the event dispatch process in order to create patches that would allow remapping the events to the new window. Would it be possible to explain in a few sentences or maybe even a small graph how the current system of abstracting the "real" browser events works? I guess any solution that does not imply rewriting the event system from scratch must be based on unregistering the attached events from one window and reattaching them in the context of the new window.

Thanks,
C.
Reply | Threaded
Open this post in threaded view
|

Re: Native Window, again

panyasan
Hi Fabian,

panyasan wrote
I've done some experimenting but have to admit that I don't know enough about the event dispatch process in order to create patches that would allow remapping the events to the new window. Would it be possible to explain in a few sentences or maybe even a small graph how the current system of abstracting the "real" browser events works? I guess any solution that does not imply rewriting the event system from scratch must be based on unregistering the attached events from one window and reattaching them in the context of the new window.
I know this has low priority for the qx devs, but I'd humbly like to ask if you would see a chance of implementing native window support as I outlined. I know about

http://qooxdoo.org/documentation/0.8/event_layer_impl

but this document doesn't really help me solve the issue. Would there be a way withhin the current Framework to remap events to a different document? I am thinking of the follwoing pseudo-code

qx.event.Manager.getAllListeners().forEach( function( el, type, listener, useCapture ) {
  if ( x.y.getWindow(el) === nativeWindow ){
    // removing and re-adding should fix the listeners that have been attached to the
   // main window before the widget elements were added to the DOM of the new native
   // window
    eventManager.removeListener( el, type, listener, useCapture )
    eventManager.addListener( el, type, listener, useCapture );
},this);

Do you think somthing like this might work?

Cheers,

Christian
Reply | Threaded
Open this post in threaded view
|

Re: Native Window, again

Thomas Herchenroeder
Just a remark: Nothing much happens in core development without a bug. Did you create a bug for this issue, or is there an existing bug?!

T.

panyasan wrote:
Hi Fabian,


panyasan wrote:
  
I've done some experimenting but have to admit that I don't know enough
about the event dispatch process in order to create patches that would
allow remapping the events to the new window. Would it be possible to
explain in a few sentences or maybe even a small graph how the current
system of abstracting the "real" browser events works? I guess any
solution that does not imply rewriting the event system from scratch must
be based on unregistering the attached events from one window and
reattaching them in the context of the new window.

    

I know this has low priority for the qx devs, but I'd humbly like to ask if
you would see a chance of implementing native window support as I outlined.
I know about

http://qooxdoo.org/documentation/0.8/event_layer_impl

but this document doesn't really help me solve the issue. Would there be a
way withhin the current Framework to remap events to a different document? I
am thinking of the follwoing pseudo-code

qx.event.Manager.getAllListeners().forEach( function( el, type, listener,
useCapture ) {
  if ( x.y.getWindow(el) === nativeWindow ){
    // removing and re-adding should fix the listeners that have been
attached to the
   // main window before the widget elements were added to the DOM of the
new native
   // window
    eventManager.removeListener( el, type, listener, useCapture )
    eventManager.addListener( el, type, listener, useCapture );
},this);

Do you think somthing like this might work?

Cheers,

Christian 

  

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: Native Window, again

panyasan
Hi Thomas,

it's here:

http://bugzilla.qooxdoo.org/show_bug.cgi?id=1157

I am adding a link to this thread there.

Thanks,

Christian

thron7-2 wrote
Just a remark: Nothing much happens in core development without a bug.
Did you create a bug for this issue, or is there an existing bug?!

T.

panyasan wrote:
> Hi Fabian,
>
>
> panyasan wrote:
>  
>> I've done some experimenting but have to admit that I don't know enough
>> about the event dispatch process in order to create patches that would
>> allow remapping the events to the new window. Would it be possible to
>> explain in a few sentences or maybe even a small graph how the current
>> system of abstracting the "real" browser events works? I guess any
>> solution that does not imply rewriting the event system from scratch must
>> be based on unregistering the attached events from one window and
>> reattaching them in the context of the new window.
>>
>>    
>
> I know this has low priority for the qx devs, but I'd humbly like to ask if
> you would see a chance of implementing native window support as I outlined.
> I know about
>
> http://qooxdoo.org/documentation/0.8/event_layer_impl
>
> but this document doesn't really help me solve the issue. Would there be a
> way withhin the current Framework to remap events to a different document? I
> am thinking of the follwoing pseudo-code
>
> qx.event.Manager.getAllListeners().forEach( function( el, type, listener,
> useCapture ) {
>   if ( x.y.getWindow(el) === nativeWindow ){
>     // removing and re-adding should fix the listeners that have been
> attached to the
>    // main window before the widget elements were added to the DOM of the
> new native
>    // window
>     eventManager.removeListener( el, type, listener, useCapture )
>     eventManager.addListener( el, type, listener, useCapture );
> },this);
>
> Do you think somthing like this might work?
>
> Cheers,
>
> Christian
>
>  

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: Native Window, again

panyasan
I am keeping on experimenting... Next attempt for the trunk playground:

var win = new qx.bom.Window.open();
win.document.write("<html><body /></html>");
win.document.close();

var root = new qx.ui.root.Application(win.document);

// Create a button
var button1 = new qx.ui.form.Button("First Button", "icon/22/apps/internet-web-browser.png");

// Add button to document at fixed coordinates
root.add(button1,
{
  left : 100,
  top  : 50
});

// Add an event listener
button1.addListener("execute", function(e) {
  alert("Hello World!");
});

// the event manager for the button is still attached
// to the main window
this.info( qx.event.Registration.getManager(button1)
           == qx.event.Registration.getManager(root) );
// result: true


// get listeners and remove them
var listeners = qx.event.Registration.getManager(button1).serializeListeners(button1);
qx.event.Registration.getManager(button1).removeAllListeners(button1);

// import them to the manager of the new window
// doesn't work
qx.event.Registration.getManager(win).importListeners(button1,listeners);

I get an error "There is no event handler for the event 'undefined' on target 'qx.ui.form.Button'!"

Is there a way of switching the event manager for an individual widget?

Thanks,

Christian



panyasan wrote
Hi Thomas,

it's here:

http://bugzilla.qooxdoo.org/show_bug.cgi?id=1157

I am adding a link to this thread there.

Thanks,

Christian

thron7-2 wrote
Just a remark: Nothing much happens in core development without a bug.
Did you create a bug for this issue, or is there an existing bug?!

T.

panyasan wrote:
> Hi Fabian,
>
>
> panyasan wrote:
>  
>> I've done some experimenting but have to admit that I don't know enough
>> about the event dispatch process in order to create patches that would
>> allow remapping the events to the new window. Would it be possible to
>> explain in a few sentences or maybe even a small graph how the current
>> system of abstracting the "real" browser events works? I guess any
>> solution that does not imply rewriting the event system from scratch must
>> be based on unregistering the attached events from one window and
>> reattaching them in the context of the new window.
>>
>>    
>
> I know this has low priority for the qx devs, but I'd humbly like to ask if
> you would see a chance of implementing native window support as I outlined.
> I know about
>
> http://qooxdoo.org/documentation/0.8/event_layer_impl
>
> but this document doesn't really help me solve the issue. Would there be a
> way withhin the current Framework to remap events to a different document? I
> am thinking of the follwoing pseudo-code
>
> qx.event.Manager.getAllListeners().forEach( function( el, type, listener,
> useCapture ) {
>   if ( x.y.getWindow(el) === nativeWindow ){
>     // removing and re-adding should fix the listeners that have been
> attached to the
>    // main window before the widget elements were added to the DOM of the
> new native
>    // window
>     eventManager.removeListener( el, type, listener, useCapture )
>     eventManager.addListener( el, type, listener, useCapture );
> },this);
>
> Do you think somthing like this might work?
>
> Cheers,
>
> Christian
>
>  

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: Native Window, again

Fabian Jakobs
Administrator
Hi Christian,

the code looks like it should work. However I wasn't able to get it to
work, too. I've added some "qx.ui.core.queue.Manager.flush();" forcing
the ui to render and the dom elements to create but it didn't help.

BTW removing the event from the widget has no effect because they are
only attached to the qx.hml.Element. You will have to get the DOM
elements of the widget and move the events registered there.

e.g.
qx.ui.core.queue.Manager.flush(); // force element creation
var containerEl = button1.getContainerElement().getDomElement();

var listeners =
qx.event.Registration.getManager(containerEl).serializeListeners(containerEl);
qx.event.Registration.getManager(containerEl).removeAllListeners(containerEl);


You will have to do the same for the contentElement.

Best Fabian


> I am keeping on experimenting... Next attempt for the trunk playground:
>
> var win = new qx.bom.Window.open();
> win.document.write("<html><body /></html>");
> win.document.close();
>
> var root = new qx.ui.root.Application(win.document);
>
> // Create a button
> var button1 = new qx.ui.form.Button("First Button",
> "icon/22/apps/internet-web-browser.png");
>
> // Add button to document at fixed coordinates
> root.add(button1,
> {
>   left : 100,
>   top  : 50
> });
>
> // Add an event listener
> button1.addListener("execute", function(e) {
>   alert("Hello World!");
> });
>
> // the event manager for the button is still attached
> // to the main window
> this.info( qx.event.Registration.getManager(button1)
>            == qx.event.Registration.getManager(root) );
> // result: true
>
>
> // get listeners and remove them
> var listeners =
> qx.event.Registration.getManager(button1).serializeListeners(button1);
> qx.event.Registration.getManager(button1).removeAllListeners(button1);
>
> // import them to the manager of the new window
> // doesn't work
> qx.event.Registration.getManager(win).importListeners(button1,listeners);
>
> I get an error "There is no event handler for the event 'undefined' on
> target 'qx.ui.form.Button'!"
>
> Is there a way of switching the event manager for an individual widget?
>
> Thanks,
>
> Christian
>
>
>
>
> panyasan wrote:
>  
>> Hi Thomas,
>>
>> it's here:
>>
>> http://bugzilla.qooxdoo.org/show_bug.cgi?id=1157
>>
>> I am adding a link to this thread there.
>>
>> Thanks,
>>
>> Christian
>>
>>
>> thron7-2 wrote:
>>    
>>> Just a remark: Nothing much happens in core development without a bug.
>>> Did you create a bug for this issue, or is there an existing bug?!
>>>
>>> T.
>>>
>>> panyasan wrote:
>>>      
>>>> Hi Fabian,
>>>>
>>>>
>>>> panyasan wrote:
>>>>  
>>>>        
>>>>> I've done some experimenting but have to admit that I don't know enough
>>>>> about the event dispatch process in order to create patches that would
>>>>> allow remapping the events to the new window. Would it be possible to
>>>>> explain in a few sentences or maybe even a small graph how the current
>>>>> system of abstracting the "real" browser events works? I guess any
>>>>> solution that does not imply rewriting the event system from scratch
>>>>> must
>>>>> be based on unregistering the attached events from one window and
>>>>> reattaching them in the context of the new window.
>>>>>
>>>>>    
>>>>>          
>>>> I know this has low priority for the qx devs, but I'd humbly like to ask
>>>> if
>>>> you would see a chance of implementing native window support as I
>>>> outlined.
>>>> I know about
>>>>
>>>> http://qooxdoo.org/documentation/0.8/event_layer_impl
>>>>
>>>> but this document doesn't really help me solve the issue. Would there be
>>>> a
>>>> way withhin the current Framework to remap events to a different
>>>> document? I
>>>> am thinking of the follwoing pseudo-code
>>>>
>>>> qx.event.Manager.getAllListeners().forEach( function( el, type,
>>>> listener,
>>>> useCapture ) {
>>>>   if ( x.y.getWindow(el) === nativeWindow ){
>>>>     // removing and re-adding should fix the listeners that have been
>>>> attached to the
>>>>    // main window before the widget elements were added to the DOM of
>>>> the
>>>> new native
>>>>    // window
>>>>     eventManager.removeListener( el, type, listener, useCapture )
>>>>     eventManager.addListener( el, type, listener, useCapture );
>>>> },this);
>>>>
>>>> Do you think somthing like this might work?
>>>>
>>>> Cheers,
>>>>
>>>> Christian
>>>>
>>>>  
>>>>        
>>> ------------------------------------------------------------------------------
>>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
>>> 30-Day
>>> trial. Simplify your report design, integration and deployment - and
>>> focus on
>>> what you do best, core application coding. Discover what's new with
>>> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>>> _______________________________________________
>>> qooxdoo-devel mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>>>
>>>
>>>      
>>    
>
>  


--
Fabian Jakobs
JavaScript Framework Developer

1&1 Internet AG - Web Technologies
Ernst-Frey-Straße 9 · DE-76135 Karlsruhe
Telefon: +49 721 91374-6784
[hidden email]

Amtsgericht Montabaur / HRB 6484
Vorstände: Henning Ahlert, Ralph Dommermuth, Matthias Ehrlich, Thomas Gottschlich, Robert Hoffmann, Markus Huhn, Hans-Henning Kettler, Dr. Oliver Mauss, Jan Oetjen
Aufsichtsratsvorsitzender: Michael Scheeren


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: Native Window, again

panyasan

Fabian Jakobs wrote
Hi Christian,

the code looks like it should work. However I wasn't able to get it to
work, too. I've added some "qx.ui.core.queue.Manager.flush();" forcing
the ui to render and the dom elements to create but it didn't help.

BTW removing the event from the widget has no effect because they are
only attached to the qx.hml.Element. You will have to get the DOM
elements of the widget and move the events registered there.

e.g.
qx.ui.core.queue.Manager.flush(); // force element creation
var containerEl = button1.getContainerElement().getDomElement();

var listeners =
qx.event.Registration.getManager(containerEl).serializeListeners(containerEl);
qx.event.Registration.getManager(containerEl).removeAllListeners(containerEl);

You will have to do the same for the contentElement.
Something like this?

var win = new qx.bom.Window.open();
win.document.write("<html><body /></html>");
win.document.close();

var root = new qx.ui.root.Application(win.document);

// Create a button
var button1 = new qx.ui.form.Button("First Button", "icon/22/apps/internet-web-browser.png");

// Add button to document at fixed coordinates
root.add(button1,
{
  left : 100,
  top  : 50
});

// Add an event listener
button1.addListener("execute", function(e) {
  alert("Hello World!");
});

qx.ui.core.queue.Manager.flush();

[ button1.getContainerElement(), button1.getContentElement() ].forEach(function(el){
  var domEl = el.getDomElement();
  var listeners = qx.event.Registration.getManager(domEl).serializeListeners(domEl);
  qx.event.Registration.getManager(domEl).removeAllListeners(domEl);
  qx.event.Registration.getManager(win).importListeners(domEl,listeners);
},this);
qx.ui.core.queue.Manager.flush();

It's not working, though ;-(
Reply | Threaded
Open this post in threaded view
|

Re: Native Window, again

Fabian Jakobs
Administrator
Hi Christian,

I had yes something like this in mind. From my understanding it should
work but either we miss something or there is a bug in the event layer.

Best Fabian

> Something like this?
>
> var win = new qx.bom.Window.open();
> win.document.write("<html><body /></html>");
> win.document.close();
>
> var root = new qx.ui.root.Application(win.document);
>
> // Create a button
> var button1 = new qx.ui.form.Button("First Button",
> "icon/22/apps/internet-web-browser.png");
>
> // Add button to document at fixed coordinates
> root.add(button1,
> {
>   left : 100,
>   top  : 50
> });
>
> // Add an event listener
> button1.addListener("execute", function(e) {
>   alert("Hello World!");
> });
>
> qx.ui.core.queue.Manager.flush();
>
> [ button1.getContainerElement(), button1.getContentElement()
> ].forEach(function(el){
>   var domEl = el.getDomElement();
>   var listeners =
> qx.event.Registration.getManager(domEl).serializeListeners(domEl);
>   qx.event.Registration.getManager(domEl).removeAllListeners(domEl);
>   qx.event.Registration.getManager(win).importListeners(domEl,listeners);
> },this);
> qx.ui.core.queue.Manager.flush();
>
> It's not working, though ;-(
>  


--
Fabian Jakobs
JavaScript Framework Developer

1&1 Internet AG - Web Technologies
Ernst-Frey-Straße 9 · DE-76135 Karlsruhe
Telefon: +49 721 91374-6784
[hidden email]

Amtsgericht Montabaur / HRB 6484
Vorstände: Henning Ahlert, Ralph Dommermuth, Matthias Ehrlich, Thomas Gottschlich, Robert Hoffmann, Markus Huhn, Hans-Henning Kettler, Dr. Oliver Mauss, Jan Oetjen
Aufsichtsratsvorsitzender: Michael Scheeren


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel