OK -- I think I've resolved the broken images issue. I had
all sorts of problems with images until I finally changed QxSettings.js
and rebuilt qooxdoo.js.
It seems that all the demos worked well because they were relying
on the default "../../themes/icons" path.
I was using QxImageManager.setIconPath(), which worked in most
situations, but this approach seemed to break the images in the
empty rows.
Now that I have rebuilt qooxdoo.js, that particular problem went away.
But I have a new problem. I am trying to dynamically load the
QxListView. When I do so, the images show up as 1x1. If I preload
the listview with dummy data before I try to dynamically load the
data, all rows that were preloaded with images have the desired 16x16
sizing. Rows that were not preloaded get 1x1 image sizing.
I have tried all possible update functions for QxListView:
update
updateContent
updateLayout
updateSort
No luck. Is there a call I'm missing? Or should I just tear down the
listview and build a new one each time?
> OK -- I think I've resolved the broken images issue. I had
> all sorts of problems with images until I finally changed QxSettings.js
> and rebuilt qooxdoo.js.
>
> It seems that all the demos worked well because they were relying
> on the default "../../themes/icons" path.
>
> I was using QxImageManager.setIconPath(), which worked in most
> situations, but this approach seemed to break the images in the
> empty rows.
If you do this in window.application.pre it should work, too.
>
> Now that I have rebuilt qooxdoo.js, that particular problem went away.
>
> But I have a new problem. I am trying to dynamically load the
> QxListView. When I do so, the images show up as 1x1. If I preload
> the listview with dummy data before I try to dynamically load the
> data, all rows that were preloaded with images have the desired 16x16
> sizing. Rows that were not preloaded get 1x1 image sizing.
>
> I have tried all possible update functions for QxListView:
> update
> updateContent
> updateLayout
> updateSort
>
> No luck. Is there a call I'm missing? Or should I just tear down the
> listview and build a new one each time?
Good question. In my test-cases this seems to work always. Can you send
us an (small) example which shows this problem?
Sebastian
>
> Jason Priebe
> CBC New Media
>
>
> -------------------------------------------------------
> 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=k&kid0944&bid$1720&dat1642 > _______________________________________________
> Qooxdoo-devel mailing list
> Qooxdoo-devel@... > https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
> If I preload
> > the listview with dummy data before I try to dynamically load the
> > data, all rows that were preloaded with images have the desired
> > 16x16
> > sizing. Rows that were not preloaded get 1x1 image sizing.
That sounds similar to the problem we were seeing, but that was when we were using "image" columns. It seemed to be some sort of timing issue - sometimes it would work, sometimes it wouldn't.
> That sounds similar to the problem we were seeing, but that
> was when we were using "image" columns. It seemed to be some
> sort of timing issue - sometimes it would work, sometimes it wouldn't.
>
> The image HTML was:
>
> <img width="1" height="1" style="border: 0pt none ;
> vertical-align: top;"
> src="images/han/?img=True&type=110&status=New"/>
>
> So perhaps there is a common problem. I stopped investigating
> the problem because we moved to iconhtml and there were
> better things to do...
I guess I can pick my poison:
- iconHtml: broken images on the empty rows (I just verified
that this still happens with the latest CVS code, even
when I set my paths in QxSettings.js before compiling)
- image: 1x1 images for any rows that were empty when the
QxListView was created
Just out of curiosity, how did you get that HTML dump for the image?
Some parts of this message have been removed.
Learn more about Nabble's security policy.
Sebastian Werner wrote:
> Good question. In my test-cases this seems to work always.
> Can you send us an (small) example which shows this problem?
Attached is a simple test. I have two QxListViews, one using
a column of type "iconHtml", and the other is using "image".
Each is created with no data rows.
Each has a "Populate" button that will load three rows of data
into them. I have attached "before and after" screenshots of
the list views.
In the iconHtml listview, I get broken images in the empty rows.
In the image listview, I get no broken images, but I get 1x1 images
(the tiny dots in the screenshot) in the populated rows.
I don't have any path initialization code in my example JavaScript,
but I don't think I need it, since I recompiled qooxdoo with custom
path settings in QxSettings.js.
I hope I'm not doing something wrong and wasting your time. Maybe
this time, it will be a legitimate issue! :-)
By far the easiest to use is Firebug as it highlights the applicable item as you wave the cursor around. Unfortunately the highlight then appears in the HTML so highlight the parent - then the item within is clean.
After seeing Hugh's post regarding Firefox, I decided to have a look
at my example in IE (I use Firefox most of the time). The results are
pretty different, as you can see in the attached screenshots.
No broken images in the iconHtml, but then I also get 1x1 images in
the iconHtml column after populating (it's almost impossible to
see the "dots", but when I highlight a row, I can see the 1-pixel
placeholder for the image).
This doesn't surprise me, since I've seen the different code path
for IE in the QxIconHtml source.
> By far the easiest to use is Firebug as it highlights the
> applicable item as you wave the cursor around. Unfortunately
> the highlight then appears in the HTML so highlight the
> parent - then the item within is clean.
Very nice. I never noticed the "Inspect Element" in Firebug before.
I also use the Firefox Web Developer Toolbar and turn on "display
element
information" (under the "Information" dropdown). You can then hover
over
individual elements and you get a semi-transparent floating panel with
details on the individual elements.
In the attached screenshot, you can see that the src attribute is empty
for the highlighted broken image (you can barely see the red outline
around the highlighted image in my screenshot).
> Attached is a simple test. I have two QxListViews, one using
> a column of type "iconHtml", and the other is using "image".
If you change the script src to "../../script/qooxdoo.js" and drop it into the demo/examples folder in the 0.5.1 release you can open it directly and see the problem.
These are the symptoms we are getting in our application.
> > Good question. In my test-cases this seems to work always.
> > Can you send us an (small) example which shows this problem?
>
> Attached is a simple test. I have two QxListViews, one using
> a column of type "iconHtml", and the other is using "image".
Sebastian, any progress on tracking down the sources of these problems? It's making icons in list views unusable.
Hugh Gibson schrieb:
>>> Good question. In my test-cases this seems to work always.
>>> Can you send us an (small) example which shows this problem?
>> Attached is a simple test. I have two QxListViews, one using
>> a column of type "iconHtml", and the other is using "image".
>
> Sebastian, any progress on tracking down the sources of these problems? It's making icons in list views unusable.
No, this is currently not on my list. Someone other has an interest to
fix it?
> > Sebastian, any progress on tracking down the sources of these
> > problems? It's making icons in list views unusable.
>
> No, this is currently not on my list. Someone other has an interest
> to fix it?
Well, it's a fundamental problem in qooxdoo so it should go on a list somewhere (now, where is that bug-tracking package? ;-) ).
Could you at least take a look at the example code and give a first-guess gut feel on what the problems might be? That would only take you five minutes. Then one of us lesser mortals can take a look.
Jason, I work a short week so won't be able to take a look at this until Monday, so if you want to delve into the qooxdoo code over the weekend, be my guest!
I've done a pretty deep dive into the source, and I can tell there's
a lot I have to learn about the internals of QX before I can really
track this one down.
In the case of iconHtml columns, I'm pretty sure that the problem
stems from the fact that the QxIconHtml used in the blank rows
has no icon source, and the QxImageManager expands the URL of "" to "".
This causes broken images.
I submitted a patch earlier to QxImageManager that would expand ""
to a blank.gif. Sebastian wasn't sure that was the right thing to
do, and I completely understand that.
I just had another thought, and that was to change QxIconHtml to
only add the image HTML if the icon URI is not "". This seems
to fix QxIconHtml under Mozilla, but it still results in a little
"invisible" 1x1 icon under MSIE. I did a little digging into this,
but I'm getting nowhere. When the QxIconHtml is constructed, it
has no icon, and no height or width. I'm not sure how the image
and height/width are supposed to be reset when you add data rows
to the QxListView.
But I've attached my patch that fixes the iconHtml columns under
Mozilla, in case it's of any use.
> -----Original Message-----
> From: qooxdoo-devel-admin@... > [mailto:qooxdoo-devel-admin@...] On Behalf
> Of Hugh Gibson
> Sent: Thursday, March 02, 2006 10:23 AM
> To: qooxdoo-devel@... > Subject: Re: [qooxdoo-devel] image issues in QxListView
>
> > > Sebastian, any progress on tracking down the sources of these
> > > problems? It's making icons in list views unusable.
> >
> > No, this is currently not on my list. Someone other has an
> interest to
> > fix it?
>
> Well, it's a fundamental problem in qooxdoo so it should go
> on a list somewhere (now, where is that bug-tracking package? ;-) ).
>
> Could you at least take a look at the example code and give a
> first-guess gut feel on what the problems might be? That
> would only take you five minutes. Then one of us lesser
> mortals can take a look.
>
> Jason, I work a short week so won't be able to take a look at
> this until Monday, so if you want to delve into the qooxdoo
> code over the weekend, be my guest!
>
> Hugh
>
>
> -------------------------------------------------------
> 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
> Qooxdoo-devel@... > https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel >
Sebastian, Andreas, Hugh and Kent have been set up as administrators who can
add other users and have full read/write access.
The anonymous user (someone who connects to the site but doesn't log in)
currently has access to submit new "tickets" (bug reports are called "tickets"
in this system) and browse the tickets and wiki. I have not enabled the
anonymous user to be able to write to the wiki. I don't tend to monitor
wikis, and until someone is doing so, I'd rather not encourage spammers.
Administrators, contact me off-list and I'll give you your initial password
which you can then change as desired.
This ticket system can be integrated with CVS at some point in the future, if
desired, so that check-ins and tickets can be related to each other. I'm not
quite prepared to be a CVS server right now (my upstream DSL speed isn't high
enough) but maybe in the future.
Enjoy!
Derrell
ps. You're probably wondering who the heck this Derrell guy is. :-) I've been
lurking here for many months, with tentative (likely, at this point) plans to
use qooxdoo for a large project in the not-too-distant future.
I like when people take initiatives! I definitively join this as I can
not see anyone else has taken the initiative before. Join the team.
Together we will make Qooxdoo stronger and better than the commercial
packages. So far it has come far.
It will unload the mailing list and give more space.
At the same time I would like to ask Sebastian if there is an intention
or plan to create more mailing lists to separate the traffic?
For example:
1. Beginner support
2. Advanced user support
3. Current changes of the code
4. Visionary changes of the framework
> "Hugh Gibson" <hgibson@...> writes:
>
> > (now, where is that bug-tracking package? ;-) ).
>
> After hearing this question enough times, I got a bug up my butt, and
> implemented it -- along with an included wiki. :-)
>
> The following URLs are now up and running:
>
> http://qooxdoo.org > http://www.qooxdoo.org > Forwards to Sebastian's qooxdoo web site
>
> http://bugs.qooxdoo.org > http://wiki.qooxdoo.org > Bug-tracking and wiki (located on my server)
>
> Sebastian, Andreas, Hugh and Kent have been set up as administrators who can
> add other users and have full read/write access.
>
> The anonymous user (someone who connects to the site but doesn't log in)
> currently has access to submit new "tickets" (bug reports are called "tickets"
> in this system) and browse the tickets and wiki. I have not enabled the
> anonymous user to be able to write to the wiki. I don't tend to monitor
> wikis, and until someone is doing so, I'd rather not encourage spammers.
>
> Administrators, contact me off-list and I'll give you your initial password
> which you can then change as desired.
>
> This ticket system can be integrated with CVS at some point in the future, if
> desired, so that check-ins and tickets can be related to each other. I'm not
> quite prepared to be a CVS server right now (my upstream DSL speed isn't high
> enough) but maybe in the future.
>
> Enjoy!
>
> Derrell
>
> ps. You're probably wondering who the heck this Derrell guy is. :-) I've been
> lurking here for many months, with tentative (likely, at this point) plans to
> use qooxdoo for a large project in the not-too-distant future.
>
>
> -------------------------------------------------------
> 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
> Qooxdoo-devel@... > https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
> At the same time I would like to ask Sebastian if there is an intention
> or plan to create more mailing lists to separate the traffic?
> For example:
>
> 1. Beginner support
> 2. Advanced user support
> 3. Current changes of the code
> 4. Visionary changes of the framework
>
> What do you say?
I don't think this project is nearly big enough to require that. The volume
on the mailing list is small, and at least for the time being, I see:
- Beginner support questions important to developers, to know what beginners
are having difficulty with;
- Advanced user support appropriate for even the beginning users;
- In a package that's evolving at the speed that qooxdoo is, everyone one
should know about current changes to the code;
- Although visionaries often specify the vision, proposals of the vision can
elicit comments from all users that shape the vision;
I'd prefer that there continue to be only one mailing list until such time as
the volume of messages on the list is too much to deal with.
> I'd prefer that there continue to be only one mailing list
> until such time as the volume of messages on the list is too
> much to deal with.
For what it's worth, I agree with Derrell. I look forward to a day
when the project hits critical mass where we need to segment the
mailing lists. But for now, it's light traffic, and you never
know when a very valuable piece of information will come through.
Priebe, Jason schrieb:
>
>> I'd prefer that there continue to be only one mailing list
>> until such time as the volume of messages on the list is too
>> much to deal with.
>
> For what it's worth, I agree with Derrell. I look forward to a day
> when the project hits critical mass where we need to segment the
> mailing lists. But for now, it's light traffic, and you never
> know when a very valuable piece of information will come through.
I agree completely with this.
Sebastian
>
> Jason Priebe
> CBC New Media
>
>
> -------------------------------------------------------
> 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=k&kid0944&bid$1720&dat1642 > _______________________________________________
> Qooxdoo-devel mailing list
> Qooxdoo-devel@... > https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>> http://bugs.qooxdoo.org >> http://wiki.qooxdoo.org >> Bug-tracking and wiki (located on my server)
>
> I'm unwilling to invest any time on these until I know if Sebastian is happy
> with this solution.
I haven't heard anything from Sebastian.
> Also, how easy will it be to change the look to the qooxdoo standard?
This is a very compact, secure bug tracking and wiki program written entirely
in C (http://cvstrac.org). Although there is some configurability that an
administrator can do, the general appearance can not be modified without some
C code changes.
Although this may not be the "ultimate" best solution, it's usable now. My
intention was to provide something to get bug tracking in qooxdoo started.
The fact that it provides wiki capability was an added bonus. I'd suggest
that it can be used, even though it doesn't look exactly like one might like,
until someone has the time to implement something better, and then the data
can be migrated to the new system. (It's certainly better to have some bug
tracking capability than nothing, I would think.) I am already sending a
backup copy of the bug-tracking and wiki database to Sebastian each night, so
he or someone he designates can do that migration at any time.
Some parts of this message have been removed.
Learn more about Nabble's 
QxListView_ss1.png (17K) 