Hello to everybody in this thread!
I followed the discussions about some rough or rude answers and
statements regarding qooxdoo.
And yes! There is some language and mentality barrier between "german
english" (which is also my language ;-)
and native english.
Don't take it to serious if answers appear short and somewhat
dismissive. It's just the german factor you have
to take into account ;-)
And I have to say here that Sebastian, Andreas and all other qooxdoo
developers do a realy great job! The main concept is well thought, the
code is very clear and appreciated to use qooxdoo in my project.
Sebastian helped me allot to understand the qooxdoo code and how to use
it in my project. Sometimes the answers were short but (as a german) I
never had the impression that this was meant unfreandly.
Please help qooxdoo being better and better!
Best regards to all!
Kent Olsson schrieb:
Dear Russel,
I do agree on what you say and I have got the same response a few times
the last few days, also from Sebastian. I am not happy with that either.
I interpreted it as a mis-attitude and I was very sorry about that.
So far I have looked at it mainly as a language-barrier problem/mistake.
Guys, I think Qooxdoo is a wonderful and fantastic approach, but to
become even more fantastic, I guess we have to help each other as much
as we can. Why are we here at all? I am here because I found a very good
tool and now I can see that I might help a little bit. To not only talk
I have provided quite a lot new classes I hope is useful for someone
more than me. I also intend to provide five more classes very soon.
Sebastian, we are trying to help you and help ourselves. When the
communication can work between us all, we will have a fantastic team
helping each other with all matters. But you need to let us come in if
it is going to beat the other solutions out there, because this is not
the only one, though it is the best at the moment. I can understand it
is your baby, but you have made it open, which is generous and very
frontier, and we are asking to help you. Please, do not push us away,
instead create a good team of all of us.
I guess that Russel and me would be more than willing to help out as
much as possible.
Sincerely guys...
Kent
On Fri, 2006-01-06 at 10:36 -0500, J. Russell Smyth wrote:
Wow, I have to say that this is a suprisingly unfriendly respnonse.
You asked me if we were using release or renderer, and this was my
answer. I say suprisingly unfriendly because I have been following
this list for quite some time and have not seen such a response
before.
I fully understand it is "not your problem" - that is one of the tradeoffs with
using Open Source, my problem is NEVER your problem.. sometimes our needs
will overlap, sometimes you may have a solution for my problem readily
available, but my problems will never be "your problem".
However, in a project that is expecting to benifit from input and
possibly code from its users,
(which you would from my co - anywhere from 2-5 major products would
use it, somewhere between 2k and 7k users on those apps, and 1-5
developers adding too and reviwing Qx code - depending on how usefull
the toolkit proved to be)
it is not usually a good idea to respond with "this is not our
problem" or "we are at version .14, dont expect us to [work]"
For a project like this to be successfull, it must be adopted by
users, and I can guarantee that managers seeing a response like this
from the lead dev for a project will quickly veto the use of the
project. It has happened to me before - unable to use a good tool
because the lead devs made responses like this in publicly visible
forums.
On 1/6/06, Sebastian Werner <[EMAIL PROTECTED]> wrote:
J. Russell Smyth schrieb:
Renderer. this would have to be our target if we were to use Qooxdoo,
for performance and advanced features, and we do not have the
opportunity to do a major rewrite just after adopting a new tool.
I am sorry. But this is not our problem. qooxdoo is currently at version
0.1.4. Don't expect that it is as stable and feature complete as other
native toolkits in versions beyond five and many years of development.
Sebastian
On 1/5/06, Sebastian Werner <[EMAIL PROTECTED]> wrote:
just one question. Are you trying out "renderer" or the current release?
Sebastian
J. Russell Smyth schrieb:
J. Russell Smyth schrieb:
I am curious about some "construction" decisions. Is there reasoning
behind making QxListView from "div" components rather than "table"? My
main curiosity is we are evaluating QooxDoo for some major internal
applications, and want to make sure we understand as much as possible
before making a decision.
The old qooxdoo use sub-node-structures many times. This is true for
tables, where you need to move the children to the desired target node,
which is not the real node of the parent itself.
I am not able to understand what you are saying here, other than old qooxdoo
used tables?
The new ones layout decisions use divs all over and try to create as
less as DOM nodes as necessary (as they are performance critical).
Yes, I understand that creating fewer dom nodes if possible is an advantage, but
do you not also discard all of the formatting capaiblities built natively into
table structure?
Dont get me wrong, in part I see the elegance of using div's and your own layout
mechanism where possible, but question the value in tabular data?
One reason I ask this is we have had to deal with large tables and
sorting here, and have had to do some interesting stuff to make them
fast - we have at least one app with a requirement for tables containing
5000 rows with sorting capability - with IE support a must. For QooxDoo,
if you load QxListView with 5k rows in the demo, it dies.. it has
actually crashed my IE, and when it dosnt, it just falls asleep.. even
with only a few k rows, sorting is unacceptably slow...
It really dies? What means "dies" for you?
Well, as I stated, it somtimes crashes IE. Other times it will just
spin CPU cycles at about 99% for very long periods of time (10-20
seconds for 5k rows)
Is the loading the problem or
the sorting of the data.
each additional 1k items takes progressively longer, so loading is
also a problem - somewhere around 15 seconds to load
But the real problem is sorting. And yes, it is MUCH worse in IE.
To handle sorts of large arrays at client is a
problem because the Internet Explorer has some huge performance impacts
there (much bigger than Firefox). If you have many items in your list it
is probably the best to do the real sorting at the server and just send
the new data via AJAX to the client.
doing this server side is not an option for at least one of the
applications. I myself dont
belive that 5k rows of data is human consumable, and displaying data
in this format to me
is incorrect, but that is the requirement.
Unfortunately, there is an existing in-house custom table component
that is able to sort 5k rows in IE on a moderatly powered pc (sub what
my test machine is) in sub second time, so
I wont be able to sell that it is too slow because of ie :)
If I can find ways to improve this, based on our in house solution, I
will gladly submit a patch.
Thank you for your information!
Russell
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
_______________________________________________
Qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
_______________________________________________
Qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
_______________________________________________
Qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
--
Mit freundlichen Grüßen
Dietrich Streifert
Visionet GmbH
|
