Petr,
I think you are missing the point. What Thomas means (I think), is that he
(and probably others) will happily look at problems that can be REPRODUCED
in the standard Qooxdoo environment. Looking at problems related to your
custom build process is what is not really possible (with limited
ressources).
It's the same as asking "in my large application XY I have this and that
error, can you tell me what's wrong". Even if I'd provide the complete
source code, this would be asking a lot.
I also learnt by myself, that when I cannot reproduce a problem with a small
standard application and/or in the playground, the problem is very likely
within my own code.
Cheers,
Fritz
On Fri, 18 Sep 2009, Petr Kobalí?ek wrote:
Hi Thron and all others,
2009/9/18 thron7 <[email protected]>:
Although your issue seems solved, I want to make a few additional comments.
sorry. I don't want from you to solve my problem. But if this is bug
in qooxdoo (and for me it seems to be) I'd like to have some
assistance from developer that completely understand the API.
You're always fast to assume a bug in qooxdoo. But even if this is the
case, it is very hard to find out from our side. You only show up when
you have a problem, throwing arbitrary, poorly analysed, and mostly
incomplete pieces of information at us, and demand a solution. It's hard
to help you this way.
See my 'if'. I never said it's bug in qooxdoo. I catched some ones in
past so I only though it is.
As an example, in the generated output you sent, it said
"qxet": {"resourceUri": qxsettings["qx.path"] + "/resource", ...
This is nothing the generator generates. But it has immediate relevance
to the construction of URIs in the running app. But you didn't say a
word about it. I assume you have introduces it in some sort of
post-processing, but this is all guess-work. What is the value of this
'qxsettings["qx.path"]'? What else did you change? How am I supposed to
assess all these deviations with all their effects and side effects,
when I don't even know the scope of them all?
First I'd like to introduce the way I'm using qooxdoo - qxbuild.
I'm using qxbuild, because it gives me freedom to use qooxdoo as I
need - include modularity to our application. I know that there are
people thats using qooxdoo only with toolchain and they are happy -
the toolchain is nice and I like it, but I can't use it.
But on the other hand, qxbuild is generated using qooxdoo toolchain
with exception of postprocessing generated files. The postprocessing
part can be found in this file:
http://code.google.com/p/qxbuild/source/browse/trunk/qxbuild/fix.py:
replace('"/QOOXDOO_BUILD_PATH', 'qxsettings["qx.path"] + "')
QOOXDOO_BUILD_PATH is set in config.json in this section:
// Job to compile qooxdoo library with debugging informations
"qxbuild-debug" : {
"compile-dist": {
"uris": {
"script" : "/QOOXDOO_BUILD_PATH/script",
"resource" : "/QOOXDOO_BUILD_PATH/resource"
}
}
}
If you know the way to do this stuff using only config.json, please
tell me (I really hate this postprocessing).
(I need to set qooxdoo path dynamically, because our application is
servlet .war package and I don't know what exact path will be when
deployed).
It's some days ago you said me to include qxbuild in qooxdoo official
website, but I didn't do that, because it's set of hacks and I know
about that. Working with qxbuild means problems and I know about that
and if you don't want help me then simply don't reply to my questions,
it's simple and I haven't problem with it (this is really not personal
for me).
But let's go back to your point: "This is nothing the generator
generates", but what is difference between my output and generator
output in detail? This is only path adjustment.
I read
documentation about running source app in webserver, about theming,
about all. But I really don't know why when I create new theme
(completely outside my main package, just like another library) then
the paths that this theme are all wrong.
Maybe it's just because you have your own, non-standard build process,
no?! If you want us to help you, you have to be able to reproduce issues
in a standard qooxdoo environment, with a skeleton-based application,
using the standard build process. *You* have to do it, not us. And then,
if we figure things out together in such an environment, you might be
able to tranlate the insights back to your custom environment.
Yep, sorry about that.
HTH,
T.
So my questions are:
1. Can one theme reference others ? It's tested ?
2. If there are something wrong in paths, where I should go? (if
everything in my theme that starts with 'qxet' is wrong, where is
probably problem?)
3. Why Modern and Classic themes are included in build if I'm not
using it? (I must manually exclude them) (this is not related to this
problem, I'm just wondering)
Cheers
- Petr
2009/9/17 thron7 <[email protected]>:
Petr Kobalí?ek wrote:
Hi Thron,
I will make package that you can download and look for the problem. I
really don't know where I'm doing something wrong or if it's bug in
qooxdoo.
I'd rather have you read the documentation and answer the questions from
the previous mail, then dumping the entire package on me. After all,
it's up to you to get to grips with it and manage your package successfully.
T.
------------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
------------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
------------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
------------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
--
Oetiker+Partner AG tel: +41 62 775 9903 (direct)
Fritz Zaucker +41 62 775 9900 (switch board)
Aarweg 15 +41 79 675 0630 (mobile)
CH-4600 Olten fax: +41 62 775 9905
Schweiz web: www.oetiker.ch
------------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
