I am attempting to set QxListView columns at runtime, but have been
unsuccessful. Is there a way to set the columns outside of the constructor?
This has worked for setting the data elements (inside a QxListView
prototype extension) this._data = [...], however this._columns = {...} has
been
Michael Wilson schrieb:
Similar to iTunes (and a hundred other apps), is it possible to
multi-select a QxListView and then right-click to open a popup menu?
I want to mutli-select some rows then pop-up a tagging dialog to update
information on the selected rows. Is this possible with the curren
Similar to iTunes (and a hundred other apps), is it possible to
multi-select a QxListView and then right-click to open a popup menu?
I want to mutli-select some rows then pop-up a tagging dialog to update
information on the selected rows. Is this possible with the current
toolset?
Mike
--
Stanislav Ievlev schrieb:
Greetings!
Why do you use '#' as a default value for QxListViewContentCellIconHtml's html
property?
As a result QxListView with empty element list will be filled with '#' symbols.
Sorry for this. This seems also for me to be wrong. Fixed in CVS.
Sebastian
--
Wi
Greetings!
Why do you use '#' as a default value for QxListViewContentCellIconHtml's html
property?
As a result QxListView with empty element list will be filled with '#' symbols.
--
With best regards
Stanislav Ievlev.
---
This SF.net ema
Ricardo Borillo Domenech schrieb:
Hi,
It's possible to create a hidden column in a QxListView?
I would like to use this column to store an internal ID ...
your array can hold many other data, not just the ones used for the
columns. This way you can get something like "virtual hidden columns".
Ursprüngliche Nachricht-
> Von: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Im Auftrag
> von Ricardo Borillo Domenech
> Gesendet: Mittwoch, 11. Januar 2006 12:45
> An: qooxdoo-devel@lists.sourceforge.net
> Betreff: [qooxdoo-devel] QxListView question
>
> Hi,
>
>
Hi,
It's possible to create a hidden column in a QxListView?
I would like to use this column to store an internal ID ...
Thanks :)
--
Salut,
Ricardo Borillo Domenech
Analista/Programador - Servei d'Informàtica
Universitat Jaume I
http://xml-utils.com
smime
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 ans
Ok, now I seem to understand your position better.
Thanks.
Sebastian
J. Russell Smyth schrieb:
Sebastian,
Thank you for taking the time to reply, and clarify.
I do understand that Qooxdoo is not 100% feature complete, and if we
do adopt it we would be more than willing to assist in thi
Sebastian,
Thank you for taking the time to reply, and clarify.
I do understand that Qooxdoo is not 100% feature complete, and if we
do adopt it we would be more than willing to assist in this effort -
the point being we have consisdered writing a similar tool ourselves,
and feel if we can fi
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-
Sometimes a language barrier (i'm not talking code) can cause these kinds
of misunderstandings. English can sound a bit blunt if it's not someone's
first language, but if you strip down Sebastian's response it was fairly
straight-forward.
Izaak
On Fri, 06 Jan 2006 10:36:45 -0500, J. Russe
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
J. Russell Smyth schrieb:
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
befo
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 i
Kent Olsson schrieb:
THe question is how much a GUI like Qooxdoo is going to do. I guess it
would be better to let the server do this, and provide an interface for
AJAX here instead. At least for me it would be the choice.
That was what I meant with "move the sort handling to the server". :)
S
THe question is how much a GUI like Qooxdoo is going to do. I guess it
would be better to let the server do this, and provide an interface for
AJAX here instead. At least for me it would be the choice.
Kent
On Fri, 2006-01-06 at 11:46 +0100, Sebastian Werner wrote:
> Kent Olsson schrieb:
> > What
Well, I thought this list was open for discussion when it comes to these
issues.
;)
Kent
On Fri, 2006-01-06 at 11:48 +0100, Sebastian Werner wrote:
> sorry Kent, this was mainly an answer to J. Russell Smyth mail not to yours.
>
> Sebastian
>
>
> Sebastian Werner schrieb:
> > Kent Olsson schri
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 versio
sorry Kent, this was mainly an answer to J. Russell Smyth mail not to yours.
Sebastian
Sebastian Werner schrieb:
Kent Olsson schrieb:
What sort algorithm are we using here? Can it be optimized?
The "sort" use the native javascript sort. If it is slow for 10k entries
it is always slow. Gene
Kent Olsson schrieb:
What sort algorithm are we using here? Can it be optimized?
The "sort" use the native javascript sort. If it is slow for 10k entries
it is always slow. Generally IE performs bad on these actions - this is
already well known and nothing need to be discussed again.
You ca
What sort algorithm are we using here? Can it be optimized?
Kent
On Thu, 2006-01-05 at 18:52 -0500, J. Russell Smyth wrote:
> well, I would say a 50% performance hit is problematic as well.. and
> 11 sec to load 10k lines on a machine with the power you are
> discussing.. still pretty bad.
>
> B
well, I would say a 50% performance hit is problematic as well.. and 11
sec to load 10k lines on a machine with the power you are discussing..
still pretty bad.
But yes, the sort is the biggest problem.. I assume you can imagine our
users dont want their app to freeze every time they change a tabl
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.
On 1/5/06, Sebastian Werner <[EMAIL PROTECTED]> wrote:
> just one question. Are you trying out "rend
I was just to curious about this. I changed the List_View_10.htm user
demo of renderer so that it creates 1 lines.
Here are the benchmarks:
Reloading: IE6: ~11 sec.; FireFox 1.5: ~5 sec.
Sorting first column: IE6: ~ 54 sec.; FireFox 1.5: ~2 sec.
This is on a P4 3.6 GHz, 2 GByte RAM, retrie
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
> 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 understa
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
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 decis
Chris Ricks schrieb:
Sebastian Werner wrote:
Kent Olsson schrieb:
How can I edit an item in the QxListView? How can I add a new empty
editable item to the table? Is it implemented yet?
Nothing like this is implemented currently. IMHO it is the best to
handle this inside a new component which
Sebastian Werner wrote:
Kent Olsson schrieb:
How can I edit an item in the QxListView? How can I add a new empty
editable item to the table? Is it implemented yet?
Nothing like this is implemented currently. IMHO it is the best to
handle this inside a new component which extends the current Q
Kent Olsson schrieb:
How can I edit an item in the QxListView? How can I add a new empty
editable item to the table? Is it implemented yet?
Nothing like this is implemented currently. IMHO it is the best to
handle this inside a new component which extends the current QxListView.
editable jus
How can I edit an item in the QxListView? How can I add a new empty
editable item to the table? Is it implemented yet?
Kent
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new
34 matches
Mail list logo
