You can subscribe to this list here.
2005 |
Jan
|
Feb
|
Mar
|
Apr
(41) |
May
(353) |
Jun
(133) |
Jul
(534) |
Aug
(401) |
Sep
(219) |
Oct
(86) |
Nov
(144) |
Dec
(61) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2006 |
Jan
(200) |
Feb
(130) |
Mar
(345) |
Apr
(153) |
May
(247) |
Jun
(338) |
Jul
(222) |
Aug
(70) |
Sep
(39) |
Oct
(27) |
Nov
(76) |
Dec
(30) |
2007 |
Jan
(81) |
Feb
(44) |
Mar
(9) |
Apr
|
May
(3) |
Jun
(2) |
Jul
(34) |
Aug
(2) |
Sep
(1) |
Oct
|
Nov
|
Dec
(6) |
2008 |
Jan
|
Feb
|
Mar
(5) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2009 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
(7) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Sean M. <se...@sm...> - 2006-06-21 16:05:43
|
Aggie, is this because of not fixing the new icons that you uploaded? s <quote who=3D"M Thomas"> > It's fine on v2.6 but on the version that Aggie sent me I get black > icons... > > M. > > On 21/06/06, M Thomas <m....@gm...> wrote: >> I'm wrong... :D deleting the gifx fixed it but that would as it is the >> file that tells the processgif what to do with the gif. >> >> Hmmmm >> >> M. >> >> On 21/06/06, Colin Tatham <col...@ou...> wrote: >> > M Thomas wrote: >> > > I've believe that the problem might lie somewhere in the process g= if >> > > servlet and how it processes the gif files. >> > > I noticed that there are 2 whites in all them, both are RGB 255 25= 5 >> > > 255, which I thought might be causing the servlet a problem. >> > >> > By 'them' do you mean all of the *gif* files? >> > >> > > So I edited the palette and changed the 2nd white to be RGB 254 25= 4 >> > > 254, checked the transparency was still in place and saved them. = I >> > > then stopped the web server, deleted all the gifx files and >> restarted >> > > the web server. >> > >> > Does that mean the gifx files are unnecessary, or generated >> dynamically? (I didn't think either was >> > true...) >> > >> > > This seems to have solve the problem. >> > >> > That's odd. I've got an old version of Bod from Dec 2005 on a laptop= , >> and it doesn't have the >> > problem. I subsequently downloaded a newer version on the same >> machine, and it has the problem -- so >> > what changed? >> > >> > Colin >> > >> > > On 21/06/06, Colin Tatham <col...@ou...> wrote: >> > > >> > >>Anyone else seeing the bug where the icons in the top frame change >> colour once you go down a level >> > >>from the root? >> > >>The icon size in the menu also seems to be fixed to small, >> regardless of the setting in the resource >> > >>properties at the root... >> > >> >> > >> >> > >>Colin >> > >> >> > >> >> > >>-- >> > >>____________________________________ >> > >>Colin Tatham >> > >>VLE Team >> > >>Oxford University Computing Services >> > >> >> > >>http://www.oucs.ox.ac.uk/ltg/vle/ >> > >>http://bodington.org >> > >> >> > >> >> > >>_______________________________________________ >> > >>Bodington-developers mailing list >> > >>Bod...@li... >> > >>https://lists.sourceforge.net/lists/listinfo/bodington-developers >> > >> >> > > >> > > >> > > >> > >> > >> > -- >> > ____________________________________ >> > Colin Tatham >> > VLE Team >> > Oxford University Computing Services >> > >> > http://www.oucs.ox.ac.uk/ltg/vle/ >> > http://bodington.org >> > >> > >> > _______________________________________________ >> > Bodington-developers mailing list >> > Bod...@li... >> > https://lists.sourceforge.net/lists/listinfo/bodington-developers >> > >> >> >> -- >> m.cha3l >> > > > -- > m.cha3l > > > _______________________________________________ > Bodington-developers mailing list > Bod...@li... > https://lists.sourceforge.net/lists/listinfo/bodington-developers > --=20 Sean Mehan Head of e-Frameworks Learning and Information Services UHI |
From: Sean M. <se...@sm...> - 2006-06-21 16:05:15
|
how about a screen grab? s <quote who=3D"Jon Maber"> > Antony Corfield wrote: >> with Safari... >> Loose location icons along with search and links except logout. >> > Could you elaborate? Are the icons missing all the time? >> Shrinking window causes text to collapse better but eventually spills >> over into login div. >> > Does the overspilling text overwrite the content of the lower box or > push it down? > > A not very pro CSS solution would be to go back to the use of a table. > I.e. one row, two cells. The height of the row could be fixed and the > width of the right hand cell fixed. This solution would not be too bad > for accessibility because it could be navigated linearly and would work > better with browsers that implement CSS to version 1 or dont handle it > at all. What do you think about tables? > > > Jon > > > > _______________________________________________ > Bodington-developers mailing list > Bod...@li... > https://lists.sourceforge.net/lists/listinfo/bodington-developers > --=20 Sean Mehan Head of e-Frameworks Learning and Information Services UHI |
From: Jon M. <jo...@te...> - 2006-06-21 15:56:33
|
In summary, o There is a good solution - using CSS 2.1, trouble is it requires browsers to properly support CSS 2.1 o Bad browsers mean we need to use bad HTML and/or bad CSS o My conclusion is that we have to deal with the whackier browsers for the time being and plan for most browsers properly supporting CSS in a year or two's time. Therefore I propose an interim solution, i.e. the use of a very simple table with a fixed height. One cell on the left would contain the navigation icons and the title and within that the icons would float left therefore allowing the title to wrap to two or more lines beside it. A second cell on the right would have a fixed width and contain... ...what? Just the quick search? The use of the table makes it possible to vertically centre all the contents which would be neat and should work on all browsers. The rest of the frame could be outside the table or in a second one row table and could also vertically centre the contents. Jon Owen Davies wrote: > having spent a fair bit of time on this, i have come to the conclusion that > the only justifiable solution is to have a vertical scroll bar on the top > frame, because any other solution prevents users who enlarge their text from > viewing some of the site content and/or functionality. that is, of course, > until the dreaded frames are ditched! > > owen > ----- Original Message ----- > From: "Colin Tatham" <col...@ou...> > To: "Bodington developers" <bod...@li...> > Sent: Wednesday, June 21, 2006 3:50 PM > Subject: Re: [Bodington-developers] Top frame styling improvement - commited > to HEAD > > > >> Jon Maber wrote: >> >>> A not very pro CSS solution would be to go back to the use of a table. >>> I.e. one row, two cells. The height of the row could be fixed and the >>> width of the right hand cell fixed. This solution would not be too bad >>> for accessibility because it could be navigated linearly and would work >>> better with browsers that implement CSS to version 1 or dont handle it >>> at all. What do you think about tables? >>> >> If it works I wouldn't mind. We need to find a better overall solution at >> some point, so this would >> only be in the interim. >> >> I think we should also decide what the priorities are, as we no-one seems >> to have found the perfect >> solution yet (we've also had Owen here looking at it for quite a while). >> Visual appearance? Text >> re-sizing in browser? Displaying full title rather than abbreviating it? >> Limiting max number of >> parent icons to display? >> >> Colin >> >> -- >> ____________________________________ >> Colin Tatham >> VLE Team >> Oxford University Computing Services >> >> http://www.oucs.ox.ac.uk/ltg/vle/ >> http://bodington.org >> >> >> _______________________________________________ >> Bodington-developers mailing list >> Bod...@li... >> https://lists.sourceforge.net/lists/listinfo/bodington-developers >> >> > > > > _______________________________________________ > Bodington-developers mailing list > Bod...@li... > https://lists.sourceforge.net/lists/listinfo/bodington-developers > > |
From: Jon M. <jo...@te...> - 2006-06-21 15:46:21
|
I've been taking a look at it. It seems to happen after one has set colour preferences and then set them back to default. I dont think the problem is anything to do with the servlet that processes the GIFs, I think its the code that generates the appropriate URL to the GIF. To be more specific, the URL has a query string which tells the GIF processing how to do its work. I think its that query string that may be going wrong. In my installation I can see different query strings in the top frame compared to the menu of resources frame which isn't right. Now, shall I carry on with my testing programme or divert my efforts to this bug? Hmm.... Jon M Thomas wrote: > :D > > On 21/06/06, Sean Mehan <se...@sm...> wrote: > >> who can fix this? >> >> thanks, jon! >> >> >> s >> >> >> <quote who="M Thomas"> >> >>> I've also notice that there are errors with image properties in the >>> latest version. See screen captures. >>> >>> M. >>> >>> On 21/06/06, M Thomas <m....@gm...> wrote: >>> >>>> It's fine on v2.6 but on the version that Aggie sent me I get black >>>> icons... >>>> >>>> M. >>>> >>>> On 21/06/06, M Thomas <m....@gm...> wrote: >>>> >>>>> I'm wrong... :D deleting the gifx fixed it but that would as it is the >>>>> file that tells the processgif what to do with the gif. >>>>> >>>>> Hmmmm >>>>> >>>>> M. >>>>> >>>>> On 21/06/06, Colin Tatham <col...@ou...> wrote: >>>>> >>>>>> M Thomas wrote: >>>>>> >>>>>>> I've believe that the problem might lie somewhere in the process >>>>>>> >>>> gif >>>> >>>>>>> servlet and how it processes the gif files. >>>>>>> I noticed that there are 2 whites in all them, both are RGB 255 >>>>>>> >>>> 255 >>>> >>>>>>> 255, which I thought might be causing the servlet a problem. >>>>>>> >>>>>> By 'them' do you mean all of the *gif* files? >>>>>> >>>>>> >>>>>>> So I edited the palette and changed the 2nd white to be RGB 254 >>>>>>> >>>> 254 >>>> >>>>>>> 254, checked the transparency was still in place and saved them. >>>>>>> >>>> I >>>> >>>>>>> then stopped the web server, deleted all the gifx files and >>>>>>> >>>> restarted >>>> >>>>>>> the web server. >>>>>>> >>>>>> Does that mean the gifx files are unnecessary, or generated >>>>>> >>>> dynamically? (I didn't think either was >>>> >>>>>> true...) >>>>>> >>>>>> >>>>>>> This seems to have solve the problem. >>>>>>> >>>>>> That's odd. I've got an old version of Bod from Dec 2005 on a >>>>>> >>>> laptop, and it doesn't have the >>>> >>>>>> problem. I subsequently downloaded a newer version on the same >>>>>> >>>> machine, and it has the problem -- so >>>> >>>>>> what changed? >>>>>> >>>>>> Colin >>>>>> >>>>>> >>>>>>> On 21/06/06, Colin Tatham <col...@ou...> wrote: >>>>>>> >>>>>>> >>>>>>>> Anyone else seeing the bug where the icons in the top frame change >>>>>>>> >>>> colour once you go down a level >>>> >>>>>>> >from the root? >>>>>>> >>>>>>>> The icon size in the menu also seems to be fixed to small, >>>>>>>> >>>> regardless of the setting in the resource >>>> >>>>>>>> properties at the root... >>>>>>>> >>>>>>>> >>>>>>>> Colin >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> ____________________________________ >>>>>>>> Colin Tatham >>>>>>>> VLE Team >>>>>>>> Oxford University Computing Services >>>>>>>> >>>>>>>> http://www.oucs.ox.ac.uk/ltg/vle/ >>>>>>>> http://bodington.org >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Bodington-developers mailing list >>>>>>>> Bod...@li... >>>>>>>> https://lists.sourceforge.net/lists/listinfo/bodington-developers >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> -- >>>>>> ____________________________________ >>>>>> Colin Tatham >>>>>> VLE Team >>>>>> Oxford University Computing Services >>>>>> >>>>>> http://www.oucs.ox.ac.uk/ltg/vle/ >>>>>> http://bodington.org >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Bodington-developers mailing list >>>>>> Bod...@li... >>>>>> https://lists.sourceforge.net/lists/listinfo/bodington-developers >>>>>> >>>>>> >>>>> -- >>>>> m.cha3l >>>>> >>>>> >>>> -- >>>> m.cha3l >>>> >>>> >>> -- >>> m.cha3l >>> _______________________________________________ >>> Bodington-developers mailing list >>> Bod...@li... >>> https://lists.sourceforge.net/lists/listinfo/bodington-developers >>> >>> >> -- >> Sean Mehan >> Head of e-Frameworks >> Learning and Information Services >> UHI >> >> >> _______________________________________________ >> Bodington-developers mailing list >> Bod...@li... >> https://lists.sourceforge.net/lists/listinfo/bodington-developers >> >> > > > |
From: Owen D. <owe...@ou...> - 2006-06-21 15:35:28
|
having spent a fair bit of time on this, i have come to the conclusion that the only justifiable solution is to have a vertical scroll bar on the top frame, because any other solution prevents users who enlarge their text from viewing some of the site content and/or functionality. that is, of course, until the dreaded frames are ditched! owen ----- Original Message ----- From: "Colin Tatham" <col...@ou...> To: "Bodington developers" <bod...@li...> Sent: Wednesday, June 21, 2006 3:50 PM Subject: Re: [Bodington-developers] Top frame styling improvement - commited to HEAD > Jon Maber wrote: >> A not very pro CSS solution would be to go back to the use of a table. >> I.e. one row, two cells. The height of the row could be fixed and the >> width of the right hand cell fixed. This solution would not be too bad >> for accessibility because it could be navigated linearly and would work >> better with browsers that implement CSS to version 1 or dont handle it >> at all. What do you think about tables? > > If it works I wouldn't mind. We need to find a better overall solution at > some point, so this would > only be in the interim. > > I think we should also decide what the priorities are, as we no-one seems > to have found the perfect > solution yet (we've also had Owen here looking at it for quite a while). > Visual appearance? Text > re-sizing in browser? Displaying full title rather than abbreviating it? > Limiting max number of > parent icons to display? > > Colin > > -- > ____________________________________ > Colin Tatham > VLE Team > Oxford University Computing Services > > http://www.oucs.ox.ac.uk/ltg/vle/ > http://bodington.org > > > _______________________________________________ > Bodington-developers mailing list > Bod...@li... > https://lists.sourceforge.net/lists/listinfo/bodington-developers > |
From: M T. <m....@gm...> - 2006-06-21 15:05:07
|
:D On 21/06/06, Sean Mehan <se...@sm...> wrote: > who can fix this? > > thanks, jon! > > > s > > > <quote who="M Thomas"> > > I've also notice that there are errors with image properties in the > > latest version. See screen captures. > > > > M. > > > > On 21/06/06, M Thomas <m....@gm...> wrote: > >> It's fine on v2.6 but on the version that Aggie sent me I get black > >> icons... > >> > >> M. > >> > >> On 21/06/06, M Thomas <m....@gm...> wrote: > >> > I'm wrong... :D deleting the gifx fixed it but that would as it is the > >> > file that tells the processgif what to do with the gif. > >> > > >> > Hmmmm > >> > > >> > M. > >> > > >> > On 21/06/06, Colin Tatham <col...@ou...> wrote: > >> > > M Thomas wrote: > >> > > > I've believe that the problem might lie somewhere in the process > >> gif > >> > > > servlet and how it processes the gif files. > >> > > > I noticed that there are 2 whites in all them, both are RGB 255 > >> 255 > >> > > > 255, which I thought might be causing the servlet a problem. > >> > > > >> > > By 'them' do you mean all of the *gif* files? > >> > > > >> > > > So I edited the palette and changed the 2nd white to be RGB 254 > >> 254 > >> > > > 254, checked the transparency was still in place and saved them. > >> I > >> > > > then stopped the web server, deleted all the gifx files and > >> restarted > >> > > > the web server. > >> > > > >> > > Does that mean the gifx files are unnecessary, or generated > >> dynamically? (I didn't think either was > >> > > true...) > >> > > > >> > > > This seems to have solve the problem. > >> > > > >> > > That's odd. I've got an old version of Bod from Dec 2005 on a > >> laptop, and it doesn't have the > >> > > problem. I subsequently downloaded a newer version on the same > >> machine, and it has the problem -- so > >> > > what changed? > >> > > > >> > > Colin > >> > > > >> > > > On 21/06/06, Colin Tatham <col...@ou...> wrote: > >> > > > > >> > > >>Anyone else seeing the bug where the icons in the top frame change > >> colour once you go down a level > >> > > >>from the root? > >> > > >>The icon size in the menu also seems to be fixed to small, > >> regardless of the setting in the resource > >> > > >>properties at the root... > >> > > >> > >> > > >> > >> > > >>Colin > >> > > >> > >> > > >> > >> > > >>-- > >> > > >>____________________________________ > >> > > >>Colin Tatham > >> > > >>VLE Team > >> > > >>Oxford University Computing Services > >> > > >> > >> > > >>http://www.oucs.ox.ac.uk/ltg/vle/ > >> > > >>http://bodington.org > >> > > >> > >> > > >> > >> > > >>_______________________________________________ > >> > > >>Bodington-developers mailing list > >> > > >>Bod...@li... > >> > > >>https://lists.sourceforge.net/lists/listinfo/bodington-developers > >> > > >> > >> > > > > >> > > > > >> > > > > >> > > > >> > > > >> > > -- > >> > > ____________________________________ > >> > > Colin Tatham > >> > > VLE Team > >> > > Oxford University Computing Services > >> > > > >> > > http://www.oucs.ox.ac.uk/ltg/vle/ > >> > > http://bodington.org > >> > > > >> > > > >> > > _______________________________________________ > >> > > Bodington-developers mailing list > >> > > Bod...@li... > >> > > https://lists.sourceforge.net/lists/listinfo/bodington-developers > >> > > > >> > > >> > > >> > -- > >> > m.cha3l > >> > > >> > >> > >> -- > >> m.cha3l > >> > > > > > > -- > > m.cha3l > > _______________________________________________ > > Bodington-developers mailing list > > Bod...@li... > > https://lists.sourceforge.net/lists/listinfo/bodington-developers > > > > > -- > Sean Mehan > Head of e-Frameworks > Learning and Information Services > UHI > > > _______________________________________________ > Bodington-developers mailing list > Bod...@li... > https://lists.sourceforge.net/lists/listinfo/bodington-developers > -- m.cha3l |
From: Sean M. <se...@sm...> - 2006-06-21 15:01:29
|
who can fix this? thanks, jon! s <quote who=3D"M Thomas"> > I've also notice that there are errors with image properties in the > latest version. See screen captures. > > M. > > On 21/06/06, M Thomas <m....@gm...> wrote: >> It's fine on v2.6 but on the version that Aggie sent me I get black >> icons... >> >> M. >> >> On 21/06/06, M Thomas <m....@gm...> wrote: >> > I'm wrong... :D deleting the gifx fixed it but that would as it is t= he >> > file that tells the processgif what to do with the gif. >> > >> > Hmmmm >> > >> > M. >> > >> > On 21/06/06, Colin Tatham <col...@ou...> wrote: >> > > M Thomas wrote: >> > > > I've believe that the problem might lie somewhere in the process >> gif >> > > > servlet and how it processes the gif files. >> > > > I noticed that there are 2 whites in all them, both are RGB 255 >> 255 >> > > > 255, which I thought might be causing the servlet a problem. >> > > >> > > By 'them' do you mean all of the *gif* files? >> > > >> > > > So I edited the palette and changed the 2nd white to be RGB 254 >> 254 >> > > > 254, checked the transparency was still in place and saved them= . >> I >> > > > then stopped the web server, deleted all the gifx files and >> restarted >> > > > the web server. >> > > >> > > Does that mean the gifx files are unnecessary, or generated >> dynamically? (I didn't think either was >> > > true...) >> > > >> > > > This seems to have solve the problem. >> > > >> > > That's odd. I've got an old version of Bod from Dec 2005 on a >> laptop, and it doesn't have the >> > > problem. I subsequently downloaded a newer version on the same >> machine, and it has the problem -- so >> > > what changed? >> > > >> > > Colin >> > > >> > > > On 21/06/06, Colin Tatham <col...@ou...> wrote: >> > > > >> > > >>Anyone else seeing the bug where the icons in the top frame chan= ge >> colour once you go down a level >> > > >>from the root? >> > > >>The icon size in the menu also seems to be fixed to small, >> regardless of the setting in the resource >> > > >>properties at the root... >> > > >> >> > > >> >> > > >>Colin >> > > >> >> > > >> >> > > >>-- >> > > >>____________________________________ >> > > >>Colin Tatham >> > > >>VLE Team >> > > >>Oxford University Computing Services >> > > >> >> > > >>http://www.oucs.ox.ac.uk/ltg/vle/ >> > > >>http://bodington.org >> > > >> >> > > >> >> > > >>_______________________________________________ >> > > >>Bodington-developers mailing list >> > > >>Bod...@li... >> > > >>https://lists.sourceforge.net/lists/listinfo/bodington-developer= s >> > > >> >> > > > >> > > > >> > > > >> > > >> > > >> > > -- >> > > ____________________________________ >> > > Colin Tatham >> > > VLE Team >> > > Oxford University Computing Services >> > > >> > > http://www.oucs.ox.ac.uk/ltg/vle/ >> > > http://bodington.org >> > > >> > > >> > > _______________________________________________ >> > > Bodington-developers mailing list >> > > Bod...@li... >> > > https://lists.sourceforge.net/lists/listinfo/bodington-developers >> > > >> > >> > >> > -- >> > m.cha3l >> > >> >> >> -- >> m.cha3l >> > > > -- > m.cha3l > _______________________________________________ > Bodington-developers mailing list > Bod...@li... > https://lists.sourceforge.net/lists/listinfo/bodington-developers > --=20 Sean Mehan Head of e-Frameworks Learning and Information Services UHI |
From: M T. <m....@gm...> - 2006-06-21 14:52:50
|
I've also notice that there are errors with image properties in the latest version. See screen captures. M. On 21/06/06, M Thomas <m....@gm...> wrote: > It's fine on v2.6 but on the version that Aggie sent me I get black icons... > > M. > > On 21/06/06, M Thomas <m....@gm...> wrote: > > I'm wrong... :D deleting the gifx fixed it but that would as it is the > > file that tells the processgif what to do with the gif. > > > > Hmmmm > > > > M. > > > > On 21/06/06, Colin Tatham <col...@ou...> wrote: > > > M Thomas wrote: > > > > I've believe that the problem might lie somewhere in the process gif > > > > servlet and how it processes the gif files. > > > > I noticed that there are 2 whites in all them, both are RGB 255 255 > > > > 255, which I thought might be causing the servlet a problem. > > > > > > By 'them' do you mean all of the *gif* files? > > > > > > > So I edited the palette and changed the 2nd white to be RGB 254 254 > > > > 254, checked the transparency was still in place and saved them. I > > > > then stopped the web server, deleted all the gifx files and restarted > > > > the web server. > > > > > > Does that mean the gifx files are unnecessary, or generated dynamically? (I didn't think either was > > > true...) > > > > > > > This seems to have solve the problem. > > > > > > That's odd. I've got an old version of Bod from Dec 2005 on a laptop, and it doesn't have the > > > problem. I subsequently downloaded a newer version on the same machine, and it has the problem -- so > > > what changed? > > > > > > Colin > > > > > > > On 21/06/06, Colin Tatham <col...@ou...> wrote: > > > > > > > >>Anyone else seeing the bug where the icons in the top frame change colour once you go down a level > > > >>from the root? > > > >>The icon size in the menu also seems to be fixed to small, regardless of the setting in the resource > > > >>properties at the root... > > > >> > > > >> > > > >>Colin > > > >> > > > >> > > > >>-- > > > >>____________________________________ > > > >>Colin Tatham > > > >>VLE Team > > > >>Oxford University Computing Services > > > >> > > > >>http://www.oucs.ox.ac.uk/ltg/vle/ > > > >>http://bodington.org > > > >> > > > >> > > > >>_______________________________________________ > > > >>Bodington-developers mailing list > > > >>Bod...@li... > > > >>https://lists.sourceforge.net/lists/listinfo/bodington-developers > > > >> > > > > > > > > > > > > > > > > > > > > > -- > > > ____________________________________ > > > Colin Tatham > > > VLE Team > > > Oxford University Computing Services > > > > > > http://www.oucs.ox.ac.uk/ltg/vle/ > > > http://bodington.org > > > > > > > > > _______________________________________________ > > > Bodington-developers mailing list > > > Bod...@li... > > > https://lists.sourceforge.net/lists/listinfo/bodington-developers > > > > > > > > > -- > > m.cha3l > > > > > -- > m.cha3l > -- m.cha3l |
From: Colin T. <col...@ou...> - 2006-06-21 14:50:58
|
Jon Maber wrote: > A not very pro CSS solution would be to go back to the use of a table. > I.e. one row, two cells. The height of the row could be fixed and the > width of the right hand cell fixed. This solution would not be too bad > for accessibility because it could be navigated linearly and would work > better with browsers that implement CSS to version 1 or dont handle it > at all. What do you think about tables? If it works I wouldn't mind. We need to find a better overall solution at some point, so this would only be in the interim. I think we should also decide what the priorities are, as we no-one seems to have found the perfect solution yet (we've also had Owen here looking at it for quite a while). Visual appearance? Text re-sizing in browser? Displaying full title rather than abbreviating it? Limiting max number of parent icons to display? Colin -- ____________________________________ Colin Tatham VLE Team Oxford University Computing Services http://www.oucs.ox.ac.uk/ltg/vle/ http://bodington.org |
From: Antony C. <an...@sm...> - 2006-06-21 14:42:16
|
We're trying to fix problems caused by using frames, not sure if there is an easy solution! On 21 Jun 2006, at 15:29, Antony Corfield wrote: > On 21 Jun 2006, at 15:21, Jon Maber wrote: > >> Antony Corfield wrote: >>> with Safari... >>> Loose location icons along with search and links except logout. >>> >> Could you elaborate? Are the icons missing all the time? > Yes can't seem to get them back! >>> Shrinking window causes text to collapse better but eventually spills >>> over into login div. >>> >> Does the overspilling text overwrite the content of the lower box or >> push it down? > pushes it down which is reasonable behavior for css with small browser > window >> >> A not very pro CSS solution would be to go back to the use of a table. >> I.e. one row, two cells. The height of the row could be fixed and the >> width of the right hand cell fixed. This solution would not be too bad >> for accessibility because it could be navigated linearly and would >> work >> better with browsers that implement CSS to version 1 or dont handle it >> at all. What do you think about tables? >> >> >> Jon >> >> >> >> _______________________________________________ >> Bodington-developers mailing list >> Bod...@li... >> https://lists.sourceforge.net/lists/listinfo/bodington-developers > > > > _______________________________________________ > Bodington-developers mailing list > Bod...@li... > https://lists.sourceforge.net/lists/listinfo/bodington-developers |
From: Antony C. <an...@sm...> - 2006-06-21 14:29:58
|
On 21 Jun 2006, at 15:21, Jon Maber wrote: > Antony Corfield wrote: >> with Safari... >> Loose location icons along with search and links except logout. >> > Could you elaborate? Are the icons missing all the time? Yes can't seem to get them back! >> Shrinking window causes text to collapse better but eventually spills >> over into login div. >> > Does the overspilling text overwrite the content of the lower box or > push it down? pushes it down which is reasonable behavior for css with small browser window > > A not very pro CSS solution would be to go back to the use of a table. > I.e. one row, two cells. The height of the row could be fixed and the > width of the right hand cell fixed. This solution would not be too bad > for accessibility because it could be navigated linearly and would work > better with browsers that implement CSS to version 1 or dont handle it > at all. What do you think about tables? > > > Jon > > > > _______________________________________________ > Bodington-developers mailing list > Bod...@li... > https://lists.sourceforge.net/lists/listinfo/bodington-developers |
From: M T. <m....@gm...> - 2006-06-21 14:24:02
|
It's fine on v2.6 but on the version that Aggie sent me I get black icons... M. On 21/06/06, M Thomas <m....@gm...> wrote: > I'm wrong... :D deleting the gifx fixed it but that would as it is the > file that tells the processgif what to do with the gif. > > Hmmmm > > M. > > On 21/06/06, Colin Tatham <col...@ou...> wrote: > > M Thomas wrote: > > > I've believe that the problem might lie somewhere in the process gif > > > servlet and how it processes the gif files. > > > I noticed that there are 2 whites in all them, both are RGB 255 255 > > > 255, which I thought might be causing the servlet a problem. > > > > By 'them' do you mean all of the *gif* files? > > > > > So I edited the palette and changed the 2nd white to be RGB 254 254 > > > 254, checked the transparency was still in place and saved them. I > > > then stopped the web server, deleted all the gifx files and restarted > > > the web server. > > > > Does that mean the gifx files are unnecessary, or generated dynamically? (I didn't think either was > > true...) > > > > > This seems to have solve the problem. > > > > That's odd. I've got an old version of Bod from Dec 2005 on a laptop, and it doesn't have the > > problem. I subsequently downloaded a newer version on the same machine, and it has the problem -- so > > what changed? > > > > Colin > > > > > On 21/06/06, Colin Tatham <col...@ou...> wrote: > > > > > >>Anyone else seeing the bug where the icons in the top frame change colour once you go down a level > > >>from the root? > > >>The icon size in the menu also seems to be fixed to small, regardless of the setting in the resource > > >>properties at the root... > > >> > > >> > > >>Colin > > >> > > >> > > >>-- > > >>____________________________________ > > >>Colin Tatham > > >>VLE Team > > >>Oxford University Computing Services > > >> > > >>http://www.oucs.ox.ac.uk/ltg/vle/ > > >>http://bodington.org > > >> > > >> > > >>_______________________________________________ > > >>Bodington-developers mailing list > > >>Bod...@li... > > >>https://lists.sourceforge.net/lists/listinfo/bodington-developers > > >> > > > > > > > > > > > > > > > -- > > ____________________________________ > > Colin Tatham > > VLE Team > > Oxford University Computing Services > > > > http://www.oucs.ox.ac.uk/ltg/vle/ > > http://bodington.org > > > > > > _______________________________________________ > > Bodington-developers mailing list > > Bod...@li... > > https://lists.sourceforge.net/lists/listinfo/bodington-developers > > > > > -- > m.cha3l > -- m.cha3l |
From: Jon M. <jo...@te...> - 2006-06-21 14:21:37
|
Antony Corfield wrote: > with Safari... > Loose location icons along with search and links except logout. > Could you elaborate? Are the icons missing all the time? > Shrinking window causes text to collapse better but eventually spills > over into login div. > Does the overspilling text overwrite the content of the lower box or push it down? A not very pro CSS solution would be to go back to the use of a table. I.e. one row, two cells. The height of the row could be fixed and the width of the right hand cell fixed. This solution would not be too bad for accessibility because it could be navigated linearly and would work better with browsers that implement CSS to version 1 or dont handle it at all. What do you think about tables? Jon |
From: M T. <m....@gm...> - 2006-06-21 14:20:16
|
I'm wrong... :D deleting the gifx fixed it but that would as it is the file that tells the processgif what to do with the gif. Hmmmm M. On 21/06/06, Colin Tatham <col...@ou...> wrote: > M Thomas wrote: > > I've believe that the problem might lie somewhere in the process gif > > servlet and how it processes the gif files. > > I noticed that there are 2 whites in all them, both are RGB 255 255 > > 255, which I thought might be causing the servlet a problem. > > By 'them' do you mean all of the *gif* files? > > > So I edited the palette and changed the 2nd white to be RGB 254 254 > > 254, checked the transparency was still in place and saved them. I > > then stopped the web server, deleted all the gifx files and restarted > > the web server. > > Does that mean the gifx files are unnecessary, or generated dynamically? (I didn't think either was > true...) > > > This seems to have solve the problem. > > That's odd. I've got an old version of Bod from Dec 2005 on a laptop, and it doesn't have the > problem. I subsequently downloaded a newer version on the same machine, and it has the problem -- so > what changed? > > Colin > > > On 21/06/06, Colin Tatham <col...@ou...> wrote: > > > >>Anyone else seeing the bug where the icons in the top frame change colour once you go down a level > >>from the root? > >>The icon size in the menu also seems to be fixed to small, regardless of the setting in the resource > >>properties at the root... > >> > >> > >>Colin > >> > >> > >>-- > >>____________________________________ > >>Colin Tatham > >>VLE Team > >>Oxford University Computing Services > >> > >>http://www.oucs.ox.ac.uk/ltg/vle/ > >>http://bodington.org > >> > >> > >>_______________________________________________ > >>Bodington-developers mailing list > >>Bod...@li... > >>https://lists.sourceforge.net/lists/listinfo/bodington-developers > >> > > > > > > > > > -- > ____________________________________ > Colin Tatham > VLE Team > Oxford University Computing Services > > http://www.oucs.ox.ac.uk/ltg/vle/ > http://bodington.org > > > _______________________________________________ > Bodington-developers mailing list > Bod...@li... > https://lists.sourceforge.net/lists/listinfo/bodington-developers > -- m.cha3l |
From: Colin T. <col...@ou...> - 2006-06-21 13:50:50
|
M Thomas wrote: > I've believe that the problem might lie somewhere in the process gif > servlet and how it processes the gif files. > I noticed that there are 2 whites in all them, both are RGB 255 255 > 255, which I thought might be causing the servlet a problem. By 'them' do you mean all of the *gif* files? > So I edited the palette and changed the 2nd white to be RGB 254 254 > 254, checked the transparency was still in place and saved them. I > then stopped the web server, deleted all the gifx files and restarted > the web server. Does that mean the gifx files are unnecessary, or generated dynamically? (I didn't think either was true...) > This seems to have solve the problem. That's odd. I've got an old version of Bod from Dec 2005 on a laptop, and it doesn't have the problem. I subsequently downloaded a newer version on the same machine, and it has the problem -- so what changed? Colin > On 21/06/06, Colin Tatham <col...@ou...> wrote: > >>Anyone else seeing the bug where the icons in the top frame change colour once you go down a level >>from the root? >>The icon size in the menu also seems to be fixed to small, regardless of the setting in the resource >>properties at the root... >> >> >>Colin >> >> >>-- >>____________________________________ >>Colin Tatham >>VLE Team >>Oxford University Computing Services >> >>http://www.oucs.ox.ac.uk/ltg/vle/ >>http://bodington.org >> >> >>_______________________________________________ >>Bodington-developers mailing list >>Bod...@li... >>https://lists.sourceforge.net/lists/listinfo/bodington-developers >> > > > -- ____________________________________ Colin Tatham VLE Team Oxford University Computing Services http://www.oucs.ox.ac.uk/ltg/vle/ http://bodington.org |
From: Antony C. <an...@sm...> - 2006-06-21 13:46:35
|
with Safari... Loose location icons along with search and links except logout. Shrinking window causes text to collapse better but eventually spills over into login div. On 21 Jun 2006, at 11:33, Colin Tatham wrote: > Jon Maber wrote: >> Colin Tatham wrote: >> >>> Yes, but not very thoroughly. (I was wanting to check that the >>> default view I was seeing was >>> intentional, it looked odd to me, and I have had problems in the >>> past where either Firefox or Tomcat >>> was preventing me seeing the effects of changes to template/css >>> files...) >>> >> >> Caching of CSS files in browsers is really really bad news. In >> Firefox, >> if you reload a page the CSS files referenced within frames are NOT >> reloaded. To test my edits I had to type the URL of the top frame into >> the location box - reloading that properly reloaded the CSS files. > > Yes, or to make sure, I type in the URLs of the CSS files, and refresh > each one. > > I have found something similar with templates occasionally. I haven't > narrowed it down, but when it > happens I have to go through a process of undeploying, cleaning the > whole webapp and re-deploying. > If that doesn't work, stopping Tomcat, checking that there's no > process still hanging around (kill > it) and start Tomcat again! > > Colin > > -- > ____________________________________ > Colin Tatham > VLE Team > Oxford University Computing Services > > http://www.oucs.ox.ac.uk/ltg/vle/ > http://bodington.org > > > _______________________________________________ > Bodington-developers mailing list > Bod...@li... > https://lists.sourceforge.net/lists/listinfo/bodington-developers |
From: M T. <m....@gm...> - 2006-06-21 13:40:16
|
Hi Colin, I've believe that the problem might lie somewhere in the process gif servlet and how it processes the gif files. I noticed that there are 2 whites in all them, both are RGB 255 255 255, which I thought might be causing the servlet a problem. So I edited the palette and changed the 2nd white to be RGB 254 254 254, checked the transparency was still in place and saved them. I then stopped the web server, deleted all the gifx files and restarted the web server. This seems to have solve the problem. M. On 21/06/06, Colin Tatham <col...@ou...> wrote: > > Anyone else seeing the bug where the icons in the top frame change colour once you go down a level > from the root? > The icon size in the menu also seems to be fixed to small, regardless of the setting in the resource > properties at the root... > > > Colin > > > -- > ____________________________________ > Colin Tatham > VLE Team > Oxford University Computing Services > > http://www.oucs.ox.ac.uk/ltg/vle/ > http://bodington.org > > > _______________________________________________ > Bodington-developers mailing list > Bod...@li... > https://lists.sourceforge.net/lists/listinfo/bodington-developers > -- m.cha3l |
From: Naomi M. <na...@sm...> - 2006-06-21 13:22:20
|
> how the system hangs together and generates the html pages It all starts with the monstrous org/bodington/servlet/facilities/=20 Facility class, get used to it you'll be seeing a lot of it. If you =20 look in the bodington/tomcatadd/webapps/bodington/templates/=20 style_default/default directory, you'll find lots of html files which =20= are known as templates, these use methods in the Facility class to =20 generate html pages dynamically. For instance in an html file you'll see code like the following: <call> <target method=3D"methodName"> <variable name=3D"facility"/> </target> <parameters> <variable name=3D"request"/> <variable name=3D"writer"/> </parameters> </call> This tells the template to go to Facility and to the method =20 (methodName) above. This method will (usually) output lots of =20 hideous html - viola! The generated html files are preceded with =20 bs_template_ at runtime. i.e. menu.html would become =20 bs_template_menu.html. The thing I did at first was track through the code starting from a =20 template class and then to Facility. Things are slightly complicated =20= by the fact that these are 2 flavours of template too, 'old' and =20 'new', the code above is the easiest thing to look for IMO. Are you deploying on Windows? Naomi (newby too). On 21 Jun 2006, at 10:35, Ian Boseley wrote: > Hi, > > > > I am completely new to Bodington. However I am having diffculty =20 > trying to understand how the system hangs together and generates =20 > the html pages. I have been looking into the code and it doesn=92t =20 > seem very intuitive. Is there any documentation available, =20 > including a database schema, for developers? > > > > I have scoured the bodington Wiki and the bodington.org site but =20 > there seems to be little information generally available for the =20 > developer. > > > > I have imported the source into my deveolpment environment, =20 > eclipse, but am unable to deploy locally to my tomcat server. I =20 > have been building a .war file using the build.xml everytime I want =20= > to see what affect a change I have made to the look and feel of the =20= > site which is really slowing the process down. > > > > Can somebody tell me the file/package structure I need in eclipse =20 > to deploy directly to my local Tomcat installation? > > > > Hope someone can help. > > > > Ian > > _______________________________________________ > Bodington-developers mailing list > Bod...@li... > https://lists.sourceforge.net/lists/listinfo/bodington-developers |
From: Matthew B. <mat...@ou...> - 2006-06-21 13:17:52
|
Ian Boseley wrote: Capitalised words refer to the Java class (Facility is org.bodington.servlet.facilities.Facility). > I am completely new to Bodington. However I am having diffculty trying > to understand how the system hangs together and generates the html > pages. I have been looking into the code and it doesn’t seem very > intuitive. Is there any documentation available, including a database > schema, for developers? Quick Description: For URLs starting /site/ Request comes in and gets passed to BuildingServlet. BuildingServlet wraps request and response in Bodington specific wrappers. The request wrapper looks at the URL tries to load the Resource associated with that part of the tree. This can then be mapped onto a Facility which provides webby stuff. The the request tries to work out how to handle the URL (commented in Request), basically bs_template URLs map to templates (/tomcatadd/webapps/bodington/templates), bs_generated map to internally generated files, bs_virtual map to content purely outputted by Java. For bs_template requests the corresponding template is loaded (bs_template_main.html would load main.html) which is in the folder associated with the Facility (default folder is the fallback). Once the correct template has been located it is compiled into Java control is then passed to the compiled template. This will then probably make calls back to the Facility to output stuff dynamically. The database schema is built by the Installer which pulls it from lots of individual SQL files. > I have scoured the bodington Wiki and the bodington.org site but there > seems to be little information generally available for the developer. There isn't all that much :-( > I have imported the source into my deveolpment environment, eclipse, but > am unable to deploy locally to my tomcat server. I have been building a > .war file using the build.xml everytime I want to see what affect a > change I have made to the look and feel of the site which is really > slowing the process down. Do you have the src download or a checkout from CVS? When doing development I normal just use the build.xml. I copy sample.build.properties to build.properties and setup with the configuration for my tomcat install. Then I run the quickstart-database-create task quickstart-database-config task and then run the deploy-local task. This should then deploy Bodington to your local copy of tomcat. Then the reload task should allow the context to be reloaded. > Can somebody tell me the file/package structure I need in eclipse to > deploy directly to my local Tomcat installation? Are you using MyEclipse? There isn't a full webapp folder than can be deployed straight into the container. The build.xml creates a useable webapp folder under /build/webapps/bodington by copying in the basic webapp folder from /tomcatadd/webapp/bodington/, the web.xml from /etc, the external libs form /lib and the complied classes from /src -- -- Matthew Buckett, VLE Developer -- Learning Technologies Group, Oxford University Computing Services -- Tel: +44 (0)1865 283660 http://www.oucs.ox.ac.uk/ltg/ |
From: Colin T. <col...@ou...> - 2006-06-21 12:10:30
|
Anyone else seeing the bug where the icons in the top frame change colour once you go down a level from the root? The icon size in the menu also seems to be fixed to small, regardless of the setting in the resource properties at the root... Colin -- ____________________________________ Colin Tatham VLE Team Oxford University Computing Services http://www.oucs.ox.ac.uk/ltg/vle/ http://bodington.org |
From: Colin T. <col...@ou...> - 2006-06-21 10:33:43
|
Jon Maber wrote: > Colin Tatham wrote: > >>Yes, but not very thoroughly. (I was wanting to check that the default view I was seeing was >>intentional, it looked odd to me, and I have had problems in the past where either Firefox or Tomcat >>was preventing me seeing the effects of changes to template/css files...) >> > > Caching of CSS files in browsers is really really bad news. In Firefox, > if you reload a page the CSS files referenced within frames are NOT > reloaded. To test my edits I had to type the URL of the top frame into > the location box - reloading that properly reloaded the CSS files. Yes, or to make sure, I type in the URLs of the CSS files, and refresh each one. I have found something similar with templates occasionally. I haven't narrowed it down, but when it happens I have to go through a process of undeploying, cleaning the whole webapp and re-deploying. If that doesn't work, stopping Tomcat, checking that there's no process still hanging around (kill it) and start Tomcat again! Colin -- ____________________________________ Colin Tatham VLE Team Oxford University Computing Services http://www.oucs.ox.ac.uk/ltg/vle/ http://bodington.org |
From: Jon M. <jo...@te...> - 2006-06-21 10:17:01
|
Colin Tatham wrote: > Yes, but not very thoroughly. (I was wanting to check that the default view I was seeing was > intentional, it looked odd to me, and I have had problems in the past where either Firefox or Tomcat > was preventing me seeing the effects of changes to template/css files...) > Caching of CSS files in browsers is really really bad news. In Firefox, if you reload a page the CSS files referenced within frames are NOT reloaded. To test my edits I had to type the URL of the top frame into the location box - reloading that properly reloaded the CSS files. I'm not sure about I.E. but it seems worse than Firefox most of the time. The mechanism for handling dynamic CSS files in Bodington goes to great lengths to make sure that all browsers implement changes immediately while maintaining the performance advantages. The virtual CSS file that is directly referenced by the HTML is nearly empty - it just includes the actual CSS files. This tiny CSS file is delivered with headers that prevent any kind of caching so that any changes made to it are instantly applied but the size is so small that the lack of caching doesn't slow things down. The proper virtual CSS files are sent with headers that encourage caching. If the CSS needs to change the URL also changes and the include instructions in the master CSS change. Since the URLs have not been seen before the browser is forced to load them and apply them. Jon |
From: Colin T. <col...@ou...> - 2006-06-21 09:53:34
|
Jon Maber wrote: > Did you test it by increasing the font size and accessing a resource > with a very long title? Yes, but not very thoroughly. (I was wanting to check that the default view I was seeing was intentional, it looked odd to me, and I have had problems in the past where either Firefox or Tomcat was preventing me seeing the effects of changes to template/css files...) The title re-arranging itself worked quite well in Firefox, but IE6 wasn't great. Colin > Colin Tatham wrote: > >>- text size of links has changed (bigger) >> > > Unintentional - please adjust back down if you wish. > >>- size of 'Search' text and button is smaller >> > > This is a bit tricky because additional browser specific rules apply > beyond the CSS handling. I tried to fix the font size since the size of > the control itself is fixed but I found that Firefox ignores absolute > font sizes and scales them. That means that if the font size is > increased the button label becomes illegible. By making it smaller in > the first place it remains legible for longer as the font sizes are > notched up. > >>- search box positioning has moved up to top of frame >> > > To allow more space for growing text below it. > >>- all text and toggle icons have moved up to top of logged in div >> > > Ditto - when the font is increased it grows downwards. (But not the > icons - please adjust to taste) > >>- (IE6 only) title of current resource moved up to top of frame >> > > Ditto - allows space for several lines of text if the font enlarges or > if the title is very long. I fixed the aesthetics for CSS2.1 compliant > browsers by setting the display mode to a table cell and the vertical > alignment to middle. Sadly IE doesn't implement these rules so the only > solution would have been to actually tag the title up as a table. > >>Colin >> >> > > I've commented the CSS file to explain the properties. > > > > _______________________________________________ > Bodington-developers mailing list > Bod...@li... > https://lists.sourceforge.net/lists/listinfo/bodington-developers > > -- ____________________________________ Colin Tatham VLE Team Oxford University Computing Services http://www.oucs.ox.ac.uk/ltg/vle/ http://bodington.org |
From: Ian B. <Ia...@al...> - 2006-06-21 09:35:27
|
Hi, =20 I am completely new to Bodington. However I am having diffculty trying to understand how the system hangs together and generates the html pages. I have been looking into the code and it doesn't seem very intuitive. Is there any documentation available, including a database schema, for developers?=20 =20 I have scoured the bodington Wiki and the bodington.org site but there seems to be little information generally available for the developer.=20 =20 I have imported the source into my deveolpment environment, eclipse, but am unable to deploy locally to my tomcat server. I have been building a .war file using the build.xml everytime I want to see what affect a change I have made to the look and feel of the site which is really slowing the process down. =20 Can somebody tell me the file/package structure I need in eclipse to deploy directly to my local Tomcat installation? =20 Hope someone can help. =20 Ian =20 |
From: Jon M. <jo...@te...> - 2006-06-21 09:29:23
|
Did you test it by increasing the font size and accessing a resource with a very long title? Colin Tatham wrote: > - text size of links has changed (bigger) > Unintentional - please adjust back down if you wish. > - size of 'Search' text and button is smaller > This is a bit tricky because additional browser specific rules apply beyond the CSS handling. I tried to fix the font size since the size of the control itself is fixed but I found that Firefox ignores absolute font sizes and scales them. That means that if the font size is increased the button label becomes illegible. By making it smaller in the first place it remains legible for longer as the font sizes are notched up. > - search box positioning has moved up to top of frame > To allow more space for growing text below it. > - all text and toggle icons have moved up to top of logged in div > Ditto - when the font is increased it grows downwards. (But not the icons - please adjust to taste) > - (IE6 only) title of current resource moved up to top of frame > Ditto - allows space for several lines of text if the font enlarges or if the title is very long. I fixed the aesthetics for CSS2.1 compliant browsers by setting the display mode to a table cell and the vertical alignment to middle. Sadly IE doesn't implement these rules so the only solution would have been to actually tag the title up as a table. > Colin > > I've commented the CSS file to explain the properties. |