Hi,
I've been following this discussion since the beginning now trying to
understand what's the point about using XUL for Qooxdoo. To me it seems
that Qooxdoo's widget and layout system is much more developed than XUL.
Also, you could only rebuild parts of the complete power of XUL as it's
only one player in a set of technologies. How would you handle Gecko's
proprietary (or soon to be standardized) CSS features without breaking
Qooxdoo's cross platform design? What about the templating system which
only makes sense with RDF datasources? You also would need to support
XBL to not cut out the X in XUL (EXtensible User Interface Language),
it's XBL that makes XUL easily extensible. With a "Qooxdoo-XUL" you
would also have to drop things like overlays, or at least parts of it,
since there wouldn't be a way to hook yourself up to the Browser's UI.
So, to summarize all this, I don't think using XUL as a interface
description language makes sense when you have to rip it out of it's
context (which makes it as unique as it is). However, I'd be interested
in spreading XUL more and would like to hear what you guys imagine.
Regards,
Claus
Oliver Vogel wrote:
I think the main value of using XUL is to borrow from a standard that
has
many UI-related challenges solved using standard patters as Ben
mentioned.
There are also a host of tools starting to spring up to edit XUL
definitions. Even visual drag and drop tools to design UI's.
only for my personal interrest - can you send me a link to a
UI-deisgner creating XUL?
Using the QxBuilder syntax will work, but it may get pretty verbose
when you
start to link many components together with events.
Do we have to have the XUL engine on the client side? It would be
ideal, but
it would further slow down loading of qooxdoo apps. Can we not
implement a
server component that will take the XUL definition and generate all
necessary javascript that qooxdoo will need and simply have qooxdoo
load it
into its context. I can write such a converter initially in PHP pretty
quickly.
i think, this may be a good idea
There would be a client javascript component to it as well that
will call event callbacks with a context more comprehensive than qooxdoo
currently provides with its event system.
what is the problem of the event system used in qooxdoo?
This comes back to the question of how qooxdoo code should be defined to
maximize speed of loading. Is the API the fastest way or would it be
faster
to load some king of internal structure?
i think, we can use my class (maybe a rewritten class but like mine)
and we should use the API (maybe i am wrong, but i think, this is
easier to debug.
Olli
Christoph
--
View this message in context:
http://www.nabble.com/qooxdoo-PHP-framework-project-t1389226.html#a3768945
Sent from the qooxdoo-devel forum at Nabble.com.
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting
language
that extends applications into web and mobile media. Attend the live
webcast
and join the prime developer group breaking into this new coding
territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting
language
that extends applications into web and mobile media. Attend the live
webcast
and join the prime developer group breaking into this new coding
territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
--
Claus Augusti
Pustefix Core / Pre-Production / Stuff
Telefon: +49 721 91374 - 172
1&1 Internet AG Brauerstrasse 48
http://www.1und1.de 76135 Karlsruhe
Q: Speaking of security, Internet Explorer has had well-publicized holes...
Gates: Understand those are cases where you are downloading third-party
software.
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
