You can subscribe to this list here.
2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
(11) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
(18) |
Feb
(17) |
Mar
(11) |
Apr
(12) |
May
(21) |
Jun
(76) |
Jul
(8) |
Aug
(156) |
Sep
(117) |
Oct
(67) |
Nov
(122) |
Dec
(134) |
2003 |
Jan
(170) |
Feb
(214) |
Mar
(121) |
Apr
(36) |
May
(25) |
Jun
(10) |
Jul
(13) |
Aug
(69) |
Sep
(3) |
Oct
(17) |
Nov
(2) |
Dec
(40) |
2004 |
Jan
(34) |
Feb
(50) |
Mar
(69) |
Apr
(10) |
May
(76) |
Jun
(126) |
Jul
(180) |
Aug
(32) |
Sep
(43) |
Oct
(31) |
Nov
(25) |
Dec
(21) |
2005 |
Jan
(23) |
Feb
(75) |
Mar
(32) |
Apr
(34) |
May
(23) |
Jun
(34) |
Jul
(25) |
Aug
(21) |
Sep
(31) |
Oct
(34) |
Nov
(6) |
Dec
(16) |
2006 |
Jan
(9) |
Feb
(19) |
Mar
(45) |
Apr
(64) |
May
(33) |
Jun
(29) |
Jul
(11) |
Aug
(24) |
Sep
(55) |
Oct
(24) |
Nov
(38) |
Dec
(40) |
2007 |
Jan
(47) |
Feb
(28) |
Mar
(89) |
Apr
(35) |
May
(58) |
Jun
(30) |
Jul
(103) |
Aug
(80) |
Sep
(57) |
Oct
(108) |
Nov
(45) |
Dec
(38) |
2008 |
Jan
(39) |
Feb
(45) |
Mar
(29) |
Apr
(46) |
May
(39) |
Jun
(20) |
Jul
(19) |
Aug
(38) |
Sep
(40) |
Oct
(49) |
Nov
(64) |
Dec
(31) |
2009 |
Jan
(20) |
Feb
(31) |
Mar
(28) |
Apr
(46) |
May
(45) |
Jun
(45) |
Jul
(32) |
Aug
(11) |
Sep
(34) |
Oct
(33) |
Nov
(40) |
Dec
(17) |
2010 |
Jan
(28) |
Feb
(55) |
Mar
(23) |
Apr
(78) |
May
(33) |
Jun
(11) |
Jul
(10) |
Aug
(12) |
Sep
(70) |
Oct
(89) |
Nov
(55) |
Dec
(33) |
2011 |
Jan
(33) |
Feb
(66) |
Mar
(33) |
Apr
(40) |
May
(20) |
Jun
(29) |
Jul
(199) |
Aug
(42) |
Sep
(76) |
Oct
(10) |
Nov
(29) |
Dec
(38) |
2012 |
Jan
(30) |
Feb
(52) |
Mar
(56) |
Apr
(25) |
May
(17) |
Jun
(93) |
Jul
(15) |
Aug
(19) |
Sep
(23) |
Oct
(78) |
Nov
(59) |
Dec
(2) |
2013 |
Jan
(62) |
Feb
(18) |
Mar
(12) |
Apr
(119) |
May
(47) |
Jun
(34) |
Jul
(34) |
Aug
(12) |
Sep
(69) |
Oct
(128) |
Nov
(14) |
Dec
(11) |
2014 |
Jan
(232) |
Feb
(62) |
Mar
(67) |
Apr
(165) |
May
(82) |
Jun
(54) |
Jul
(26) |
Aug
(70) |
Sep
(56) |
Oct
(59) |
Nov
(3) |
Dec
(16) |
2015 |
Jan
(9) |
Feb
(6) |
Mar
(2) |
Apr
(2) |
May
(3) |
Jun
(2) |
Jul
(1) |
Aug
(17) |
Sep
(6) |
Oct
(4) |
Nov
(2) |
Dec
(3) |
2016 |
Jan
(19) |
Feb
(5) |
Mar
(6) |
Apr
(3) |
May
(1) |
Jun
(10) |
Jul
(3) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Kenzaburo I. <ke...@30...> - 2002-09-23 20:10:02
|
I'll send the code snippet when I get home. I think I've gotten them to work alright. >> You mention a table reduced goal. Here's what I am open to: keep the >> tables >> for alignment and sometimes percentage widths but wrap the displayed text >> in >> span or div blocks. Would that be sufficient? > We'd have to clarify the details. I'd like to try one or two reference > pages (like main / view_all / view_bug), see if the results are > acceptable (in both aspects, design & cross browser compatibility and > php coding & maintainability) and then decide which way to go. Agreed. > Hrmpf, you're right on that one. I like to do things properly and tend > to forget, that doing things properly needs more knowledge (at least in > the beginning). > But I also made the experience, that good designs (talking about > software or layout) last longer, because in the long run they allow you > to do things you never dreamt of in the beginning. We don't have to > overdo it. That means: > - No table less HTML design, but table reduced. > - No full templating, but a clean separation of code and layout. > - No full OO design, but clever use of objects to encapsulate function > groups. Even the average code tinkerer can understand what > $user->mayReopen means. People lean at least basic oo nowadays at the > university. Fine with me. I feel pretty comfortable with this. >> Oh, I'm conducting a poll: http://mantisbt.sourceforge.net/vap.php3 - >> right >> now templates is winning. (might have to reload a few times) > Wow, strange things happen, if you don't switch on your computer for two > days. Indeed =) -Ken |
From: Kenzaburo I. <ke...@30...> - 2002-09-23 19:22:29
|
Looks promising. -Ken > Onken, Luebbe wrote: >> Hi together, >> >> I just stumbled on this link: >> http://tools.phpedit.net/phpCodeBeautifier/ >> >> Could help >> - L=FCbbe > > Cool. And they use Mantis!! :) > > Julian > > > -- > ju...@be... > Beta4 Productions (http://www.beta4.com) > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Mantisbt-dev mailing list > Man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev |
From: <lu...@ne...> - 2002-09-23 19:15:01
|
Kenzaburo Ito wrote: > Mmm discussion. :-) >>>* Tables are much more widely understood than DIVs+CSS. >> >>1) Yes, but that's because most people haven't tried/understood how to do >>it >>properly. Everybody copies from other people's table based design. This is >>a >>bit like arguing "all flies eat shit -> there must be something right about >>it" > > > It's funny how bad design propagates but I don't it's our place to change > this. Users have a certain expectation on the app. > ... > De facto standards place a certain amount of preconceptions into users. They > will expect to see tables when they look at the code. When they see DIVs and > no tables they will be confused, disturbed, frightened, frustrated, and > eventaully angry. OK, I can understand that. >>>* Tables give you more immediate information about the layout >>>of a document than DIVs+CSS. >> >>2) Yes, but that's not the original intention of using tables. They should >>not be used for layout. This technique stems from DTP People that haven't >>understood that *ML separates content from layout and that layout is >>dynamic, >>not fixed. They always want to have everything placed exactly 12.63 mm from >>the left border. > > > The goal I have in using tables is to place items in basic quadrants and > alignments. I don't have *any* idea of how to do this with DIVs right now. > I've tried and failed miserably. Could you mail me your ideas / code snippets (a saved page from within IE/Moz would do + the corresponding CSS)? I would give it a try. > I try very very hard to avoid exact placement of any items. I noticed that and I'm happy about it. That's why I still think the table reduced div+css approach can work with mantis. Maybe reality will prove me wrong, but I'd like to give it a try. >>>* DIVs+CSS is not perfectly supported across even the latest >>>generation of browsers. >> >>5) The things I tried worked on IE5.5, IE6 & Mozilla 1.0. Can you give me >>an example, where the layout is different? > > I tried centering > ... > And actually I didn't achieve success since when I add a border the two 50% > width items are NOT the same width because they had different padding sizes. > I consider this a nightmare for non-experts. Same as above. Please mail me your code. Maybe I find something that works and is not too complicated. > You mention a table reduced goal. Here's what I am open to: keep the tables > for alignment and sometimes percentage widths but wrap the displayed text in > span or div blocks. Would that be sufficient? We'd have to clarify the details. I'd like to try one or two reference pages (like main / view_all / view_bug), see if the results are acceptable (in both aspects, design & cross browser compatibility and php coding & maintainability) and then decide which way to go. > I think everyone needs to think of our target audience in terms of fiddling > with code. We can target people who are experts and either know or are > willingly to learn objects, templates, proper CSS and HTML design, and > anything else I've left out. This leaves us with a dramatically reduced > number of people. Hrmpf, you're right on that one. I like to do things properly and tend to forget, that doing things properly needs more knowledge (at least in the beginning). But I also made the experience, that good designs (talking about software or layout) last longer, because in the long run they allow you to do things you never dreamt of in the beginning. We don't have to overdo it. That means: - No table less HTML design, but table reduced. - No full templating, but a clean separation of code and layout. - No full OO design, but clever use of objects to encapsulate function groups. Even the average code tinkerer can understand what $user->mayReopen means. People lean at least basic oo nowadays at the university. > Now, I'm making assumptions that a) there are many non-experts who fiddle with > the code b) they are fairly successful with the curent code and c) they would > be less successful with the proposed expert-level changes. > > I'm very sure on a and c. I'm completely unsure about b. If b is close to > zero then there's no point in my objections. I agree on a), I got along with the code, so +1 on b), I gave up merging my changes in, because there was (up to now) no clean separation of code and layout, so I disagree with c). I think, that some level of separation & abstraction is not too much expert level coding, but even helps to increase b) > Oh, I'm conducting a poll: http://mantisbt.sourceforge.net/vap.php3 - right > now templates is winning. (might have to reload a few times) Wow, strange things happen, if you don't switch on your computer for two days. Elections in Germany are over now. I think I'll go voting again today (for templates off course :-) Greetings - Lübbe |
From: David A. D. <ha...@gn...> - 2002-09-23 10:32:32
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > I just stumbled on this link: http://tools.phpedit.net/phpCodeBeautifier/ And ironically, they're using Mantis to track bugs =) Someone should email the author and ask if he's ever tried to run his own tool against the code in Mantis. d. perldoc -qa.j | perl -lpe '($_)=m("(.*)")' -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.1.92 (GNU/Linux) iD4DBQE9ju20kRQERnB1rkoRAhP+AJ4s2u7lq2sPyVdqz82Ft6qw3EZCEQCXbOtS 6r419GKVSulY9cEAG3evOw== =Aikl -----END PGP SIGNATURE----- |
From: Dries S. <Dr...@hy...> - 2002-09-23 09:40:09
|
I have not to much experience with email myself, but have done a couple of newslist systems. One problem to keep in mind when sending out multiple mails at once are script (and apache) timeouts. It's usually not a problem when sending 30-40 mails or so (depending on settings, speed of server etc), but when the amount gets greater than that, script timeouts can occur. That problem is usually solved by separating the mail action into a separate 'program'. For example the PHP script could trigger a perl program (through system() method) that sends the mails. The php page may be refreshing every x seconds to check whether the perl program has finished successfully. This could be a problem for mantis as you're creating the need for another technology ... dries. > -----Original Message----- > From: Kenzaburo Ito [mailto:ke...@30...] > Sent: 21 September 2002 03:22 > To: man...@li... > Subject: [Mantisbt-dev] Emails and Scalability > > > All, > > At some point we're going to be dealing with redoing the > emailing. I've got > little expereince in this area so I'm hoping someone knows sometihng. > > First the setup. Right now we send out one email to a dummy > address (also > from a dummy address) and BCC all the interested parties. > > Why BCC? So developers can't be directly contacted by users. > > Why this needs to change: there are private and public > bugnotes, private and > public bugs, and different users have different localization settings. > > In an ideal world you send out one email to each user > involved in the message. > Each is localized to the user's settings and each reflects > the private/public > viewing rights. > > The potential (and probable) problem is scalability. Instead > of one email you > are now generally doubling the traffic (at least). How much > of an impact will > this be? Does anyone have experience with email/traffic > heavy projects? > > We need to consider the usual MTAs (Exchange, sendmail, postfix, etc.) > > Another consideration is the time it will take for the user > to regain control > of the browser while the emails are being sent. > > Also, we're looking at PEAR::Mail and phpMailer to completely > replace the > current homegrown solution. > > Thoughts and opinions? > > Thanks, > -Ken > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Mantisbt-dev mailing list > Man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev > |
From: Julian F. <ju...@be...> - 2002-09-23 09:05:10
|
Onken, Luebbe wrote: > Hi together, >=20 > I just stumbled on this link: > http://tools.phpedit.net/phpCodeBeautifier/ >=20 > Could help > - L=FCbbe Cool. And they use Mantis!! :) Julian --=20 ju...@be... Beta4 Productions (http://www.beta4.com) |
From: Onken, L. <lue...@re...> - 2002-09-23 08:20:34
|
Hi together, I just stumbled on this link: http://tools.phpedit.net/phpCodeBeautifier/ Could help - L=FCbbe |
From: Julian F. <ju...@be...> - 2002-09-21 23:04:54
|
jfi...@us... wrote: > Update of /cvsroot/mantisbt/mantisbt > In directory usw-pr-cvs1:/tmp/cvs-serv18690 > > Modified Files: > config_defaults_inc.php > Log Message: > * config_defaults_inc.php > (g_stop_on_errors): new config option to control whether to ignore page redirects when an error is handled > * error_api.php > (error_handler): > - just display the error string for E_USER_NOTICE > - don't display the original page on fatal errors unless there were previous non-fatal errors > (error_handled): new function that returns true if an error has been handled on this page > * helper_api.php > (debug): new function that generates a NOTICE for the debug string so it is displayed (as long as you have NOTICE display enabled with $g_display_notices) > * html_api > (print_meta_redirect): don't redirect if an error has been handled on this page and $g_display_notices is ON > * print_api > (print_header_redirect): don't redirect if an error has been handled on this page and $g_display_notices is ON I'm hoping this will provide a good compromise on errors now. If previous errors have been triggered, the page content will be shown so you can see them (but it's in a div afterwards - thanks to Victor for the idea). If they haven't, only the fatal error page will be shown. If you have NOTICE display turned on, you can now use debug() to print debug messages in a file while you're debugging. Any error (or a call to debug()) will cause page redirections not to happen if you have $g_stop_on_errors turned on. My debugging settings now look like this: $g_stop_on_errors = ON; $g_show_timer = ON; $g_show_detailed_errors = ON; $g_show_notices = ON; $g_show_queries_list = ON; $g_compress_html = OFF; # otherwise you get a blank page in view_all_bug_page when there's an error I suggest others use similar settings while developing. Let me know if there are still problems with the error stuff. Julian -- ju...@be... Beta4 Productions (http://www.beta4.com) |
From: Julian F. <ju...@be...> - 2002-09-21 18:41:39
|
This patch is applied in CVS (core.php:1.4) bre...@ka... wrote: >>Patch submission is pretty slow (I had the same problem when I started >>sending patches). I would say post them here. I promise I'll look at >>them if they aren't too huge :) > > > Six lines short enough? :) > > >>If you could include appropriate log messages with them detailing what >>changes you made that makes it a lot easier to review and a lot quicker >>to commit. > > > To sum it up (there's a summary inside the patch file as well): > This patch checks the environment variable 'MANTISBT_CONFIG' for a path > to a mantis configuration file. If MANTISBT_CONFIG isn't set, it grabs > the config from "config_inc.php" as normal. This is handy in that you > can install 1 copy of mantis code on a machine and use it to serve up > several different instances of mantis by creating seperate databases and > configurations for each virtualhost and adding a line such as: > 'SetEnv MANTISBT_CONFIG /foo/bar/mantis.php' in each virtualhost section. > > -Brett > > > ------------------------------------------------------------------------ > > # cd to your mantis directory and run 'patch -p0 < mantis_vhost_0.17.5.patch' > # This patch enables the config location to be set from an environment > # variable; making it possible for multiple vhosts to use the same mantis > # codebase. --Brett Carter (br...@ka...) > > diff -rc /tmp/mantis-0.17.5/core_API.php ./core_API.php > *** /tmp/mantis-0.17.5/core_API.php Sun Aug 18 12:53:27 2002 > --- ./core_API.php Wed Sep 18 11:12:26 2002 > *************** > *** 62,67 **** > --- 62,74 ---- > if ( file_exists( "config_inc.php" ) ) { > include( "config_inc.php" ); > } > + > + # Get config from apache vhost > + $t_local_config=getenv("MANTISBT_CONFIG"); > + if( $t_local_config && file_exists($t_local_config) ){ > + include($t_local_config); > + } > + > # Load file globals # @@@ ugly hack for ugly problem. Find better solution soon > require( "./default/config_inc2.php" ); > -- ju...@be... Beta4 Productions (http://www.beta4.com) |
From: Kenzaburo I. <ke...@30...> - 2002-09-21 02:21:46
|
All, At some point we're going to be dealing with redoing the emailing. I've got little expereince in this area so I'm hoping someone knows sometihng. First the setup. Right now we send out one email to a dummy address (also from a dummy address) and BCC all the interested parties. Why BCC? So developers can't be directly contacted by users. Why this needs to change: there are private and public bugnotes, private and public bugs, and different users have different localization settings. In an ideal world you send out one email to each user involved in the message. Each is localized to the user's settings and each reflects the private/public viewing rights. The potential (and probable) problem is scalability. Instead of one email you are now generally doubling the traffic (at least). How much of an impact will this be? Does anyone have experience with email/traffic heavy projects? We need to consider the usual MTAs (Exchange, sendmail, postfix, etc.) Another consideration is the time it will take for the user to regain control of the browser while the emails are being sent. Also, we're looking at PEAR::Mail and phpMailer to completely replace the current homegrown solution. Thoughts and opinions? Thanks, -Ken |
From: Kenzaburo I. <ke...@30...> - 2002-09-20 16:20:20
|
Mmm discussion. >> * Tables are much more widely understood than DIVs+CSS. > 1) Yes, but that's because most people haven't tried/understood how to do > it > properly. Everybody copies from other people's table based design. This is > a > bit like arguing "all flies eat shit -> there must be something right about > it" It's funny how bad design propagates but I don't it's our place to change this. Users have a certain expectation on the app. Witness the *continued* use of = and == for assigment and equality. Yet when something reasonable like := comes along it's the subject of idiotic flamewars. De facto standards place a certain amount of preconceptions into users. They will expect to see tables when they look at the code. When they see DIVs and no tables they will be confused, disturbed, frightened, frustrated, and eventaully angry. Given the certain fact that people are only using Mantis as a tool in their greater goal I know this will happen. >> * Tables give you more immediate information about the layout >> of a document than DIVs+CSS. > 2) Yes, but that's not the original intention of using tables. They should > not be used for layout. This technique stems from DTP People that haven't > understood that *ML separates content from layout and that layout is > dynamic, > not fixed. They always want to have everything placed exactly 12.63 mm from > the left border. The goal I have in using tables is to place items in basic quadrants and alignments. I don't have *any* idea of how to do this with DIVs right now. I've tried and failed miserably. I try very very hard to avoid exact placement of any items. I'm sure we all realize that things rarely used only as designed. IRC and email weren't designed to transfer multi-megabyte files. Yet this is a key feature. The cat is out of the bag and there's no way you, I, or anyone short of maybe MS can fix this. >> * Both require you to look at the HTML and the CSS if you >> want to do formating. > 3) That's no point for/against using DIVs+CSS if I understand you > correctly? Right, it just means that with the current solution or a new solution you still have to look at both files. Some people seem to think that CSS means you don't need to touch the HTML, maybe, but you still have to look. >> * I would argue that tables are easier to quickly bend to >> your needs, especially if you are not as familair with CSS. > 4) Hm, but that's because of 1) isn't it? Yes. >> * DIVs+CSS is not perfectly supported across even the latest >> generation of browsers. > 5) The things I tried worked on IE5.5, IE6 & Mozilla 1.0. Can you give me > an > example, where the layout is different? I tried centering a 50% div block in the middle of a page. Worked in IE6 *or* in Moz/Opera but not both. I did a google and found some pages that indicated this was a significant problem. I've since achieved success but this helps prove a point: it's not simple to do a simple action using just CSS. I consider myself pretty expereinced but I had problems with it. I spent about 3 hours twiddling with main page to use only DIVs. It looks fine now but I had to use 3 DIVs and spend 3 hours tweaking items until they worked. I think that's an indicator of how difficult this can become. And actually I didn't achieve success since when I add a border the two 50% width items are NOT the same width because they had different padding sizes. I consider this a nightmare for non-experts. >> * Too much work to convert ;P > If you leave out the "too" I'd agree. I did the main_page at home. If you > build up your css systematically, it's not too tough. It even saves some > space, because you don't need the <tr> anymore ;-) This seems to be the most valid point to me. But I don't think the tradeoffs justify it. I also think it's too much work. > The idea is not to drop all tables. Pages like view_bug or report_bug can > only be done with tables. The idea of using more DIVs+CSS is to be able to > layout/place the DIVs independently from each other and to get away from > the box in a box in a box approach. You mention a table reduced goal. Here's what I am open to: keep the tables for alignment and sometimes percentage widths but wrap the displayed text in span or div blocks. Would that be sufficient? I think everyone needs to think of our target audience in terms of fiddling with code. We can target people who are experts and either know or are willingly to learn objects, templates, proper CSS and HTML design, and anything else I've left out. This leaves us with a dramatically reduced number of people. Or we can target your average developer, someone working on their Java, C, C++, web page, or whatever. They are non-experts and are using Mantis because it suits their needs. They want to tweak something and so dig into the code and start to flail around. They find something that looks familiar and latch onto it and start tracing and understanding code form there. Now, I'm making assumptions that a) there are many non-experts who fiddle with the code b) they are fairly successful with the curent code and c) they would be less successful with the proposed expert-level changes. I'm very sure on a and c. I'm completely unsure about b. If b is close to zero then there's no point in my objections. Oh, I'm conducting a poll: http://mantisbt.sourceforge.net/vap.php3 - right now templates is winning. (might have to reload a few times) Thanks, -Ken |
From: Onken, L. <lue...@re...> - 2002-09-20 09:26:45
|
Hi Dries, > I agree with Ken. >=20 > I've been looking into table-less designs for a long time=20 > now, and I am a great supporter of content/design separation,=20 > but I don't think currently the effort of implementing it=20 > cross browser weighs up against the advantage. No, not table-less, that won't work with mantis. Table-reduced is what I intend. > The argument about tables being bad is incorrect as well I=20 > think. A table is a table (i.e. tabular data), and the mantis=20 > view bugs page for example is clearly tabular data!! Not every table is bad. Just using the box in a box approach is not = good. I'd like to leave the blocks of data, that belong together (call them = elements as in your statement below) in one table each, and place DIVs around them. > I usually use divs for individual elements like logos etc, or=20 > simple site. As soon as you start using layers for complex=20 > content layouts you get in trouble with older PC browsers No fancy stuff like that intended. Please take a look at http://barrierefrei.e-workers.de/browser.php. Unfortunately it's only in german, but it gives you a good idea of what = I mean. They use DIVs to separate the logical sections from each other and = CSS to layout them. No fancy stuff and it works well with most browsers. As = far as I can tell it's CSS1, W3C's validator shows some missing colour = warnings, but that's all. Since Mantis' layout is quite simple, I dont' see us running into = trouble if we go that way. =20 > They can live with fonts, colours etc not looking good, but=20 > there's no point if the product becomes unusable. I absolutely agree with you. I would like to make the transition smooth = and implement only changes that don't hurt the users. =20 > It's only when CSS2 is going to be widely supported that it's=20 > worth looking into for Mantis is my opinion! >=20 > dries. |
From: Dries S. <Dr...@hy...> - 2002-09-20 08:43:36
|
I agree with Ken. I've been looking into table-less designs for a long time now, and I am a great supporter of content/design separation, but I don't think currently the effort of implementing it cross browser weighs up against the advantage. The argument about tables being bad is incorrect as well I think. A table is a table (i.e. tabular data), and the mantis view bugs page for example is clearly tabular data!! I usually use divs for individual elements like logos etc, or simple site. As soon as you start using layers for complex content layouts you get in trouble with older PC browsers (even IE5 is not perfect), MAC browsers and unix/linux browsers. You can say that you don't care about the older browsers, but I can say for a fact that we would stop using mantis if CSS2 layouts would be used, as around half of our 30+ developers are using linux workstations and all kinds of weird browser flavours that definitely don't support CSS2. They can live with fonts, colours etc not looking good, but there's no point if the product becomes unusable. It's only when CSS2 is going to be widely supported that it's worth looking into for Mantis is my opinion! dries. > -----Original Message----- > From: Kenzaburo Ito [mailto:ke...@30...] > Sent: 20 September 2002 00:36 > To: man...@li... > Subject: [Mantisbt-dev] DIVs Tables and CSS > > > On the advice of a couple people I've been looking at DIVs > and CSS as a > replacement for Tables. It's pretty intersting and I've been > playing around > with it for a few days but I've come to the conclusion that > this is not a good > choice for our situation. > > Here are my key points: > > * Tables are much more widely understood than DIVs+CSS. > > * Tables give you more immediate information about the layout > of a document > than DIVs+CSS. > > * Both require you to look at the HTML and the CSS if you > want to do formating. > > * I would argue that tables are easier to quickly bend to your needs, > especially if you are not as familair with CSS. > > * DIVs+CSS is not perfectly supported across even the latest > generation of > browsers. > > * Too much work to convert ;P > > This may be an option for 2.0. There are definitely places > where we may use > DIVs but it will likely be in conjunction with tables. > > Thanks, > -Ken > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Mantisbt-dev mailing list > Man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev > |
From: Scott H. <ha...@ne...> - 2002-09-20 08:42:44
|
One issue, at least where I work, is Netscape 4 compatibility. Yes, it's old and it sucks, but a lot of our developers still use it and do not want to be forced to change. So if we go to CSS, it has to degrade gracefully. Scott |
From: Onken, L. <lue...@re...> - 2002-09-20 08:06:51
|
Ken wrote: > On the advice of a couple people I've been looking at DIVs=20 > and CSS as a replacement for Tables. It's pretty intersting=20 > and I've been playing around with it for a few days but I've=20 > come to the conclusion that this is not a good choice for our=20 > situation. I agree on most points, but there are some 'yes but' on my part =20 > Here are my key points: >=20 > * Tables are much more widely understood than DIVs+CSS. 1) Yes, but that's because most people haven't tried/understood how to = do it properly. Everybody copies from other people's table based design. This = is a bit like arguing "all flies eat shit -> there must be something right = about it" > * Tables give you more immediate information about the layout=20 > of a document than DIVs+CSS. 2) Yes, but that's not the original intention of using tables. They = should not be used for layout. This technique stems from DTP People that = haven't understood that *ML separates content from layout and that layout is = dynamic, not fixed. They always want to have everything placed exactly 12.63 mm = from the left border. =20 > * Both require you to look at the HTML and the CSS if you=20 > want to do formating. 3) That's no point for/against using DIVs+CSS if I understand you = correctly? =20 > * I would argue that tables are easier to quickly bend to=20 > your needs, especially if you are not as familair with CSS. 4) Hm, but that's because of 1) isn't it? =20 > * DIVs+CSS is not perfectly supported across even the latest=20 > generation of browsers. 5) The things I tried worked on IE5.5, IE6 & Mozilla 1.0. Can you give = me an example, where the layout is different?=20 > * Too much work to convert ;P If you leave out the "too" I'd agree. I did the main_page at home. If = you build up your css systematically, it's not too tough. It even saves some space, because you don't need the <tr> anymore ;-) > This may be an option for 2.0. There are definitely places=20 > where we may use DIVs but it will likely be in conjunction=20 > with tables. 0.99 please? The idea is not to drop all tables. Pages like view_bug or report_bug = can only be done with tables. The idea of using more DIVs+CSS is to be able = to layout/place the DIVs independently from each other and to get away from = the box in a box in a box approach. Greetings - L=FCbbe |
From: Kenzaburo I. <ke...@30...> - 2002-09-19 23:35:58
|
On the advice of a couple people I've been looking at DIVs and CSS as a replacement for Tables. It's pretty intersting and I've been playing around with it for a few days but I've come to the conclusion that this is not a good choice for our situation. Here are my key points: * Tables are much more widely understood than DIVs+CSS. * Tables give you more immediate information about the layout of a document than DIVs+CSS. * Both require you to look at the HTML and the CSS if you want to do formating. * I would argue that tables are easier to quickly bend to your needs, especially if you are not as familair with CSS. * DIVs+CSS is not perfectly supported across even the latest generation of browsers. * Too much work to convert ;P This may be an option for 2.0. There are definitely places where we may use DIVs but it will likely be in conjunction with tables. Thanks, -Ken |
From: Jeroen L. <jl...@ca...> - 2002-09-19 14:19:47
|
At 01:55 19-9-2002 -0700, you wrote: >I have no problems with this patch... in fact it might even help solve our >problems about being able to relocate all the core, config, lang, etc >files... the user could specify a location of a config file that could >overide the location variables for the other files and directories... > >I nearly just applied this but figure I might as well see if anyone can >come up with any problems I'm not thinking of... what do other developers >think? Ken?, Jeroen?, Victor? Sounds great. Jeroen |
From: David E. <de...@ss...> - 2002-09-19 10:58:19
|
>From: <br...@ka...> >I've also got a small perl program meant to be run from a cron job that scrapes a mantis database >and emails out a daily report of open bugs. If it's of interest to anybody, I'd be glad to post >a slightly more generalized version of it here. -Brett Yes, I'd love to have that piece of code. We'd like to do the same thing. Perhaps we need a folder in CVS for utils or tools or some such. David |
From: Julian F. <ju...@be...> - 2002-09-19 08:54:09
|
I have no problems with this patch... in fact it might even help solve our problems about being able to relocate all the core, config, lang, etc files... the user could specify a location of a config file that could overide the location variables for the other files and directories... I nearly just applied this but figure I might as well see if anyone can come up with any problems I'm not thinking of... what do other developers think? Ken?, Jeroen?, Victor? Julian bre...@ka... wrote: >>Patch submission is pretty slow (I had the same problem when I started >>sending patches). I would say post them here. I promise I'll look at >>them if they aren't too huge :) > > > Six lines short enough? :) > > >>If you could include appropriate log messages with them detailing what >>changes you made that makes it a lot easier to review and a lot quicker >>to commit. > > > To sum it up (there's a summary inside the patch file as well): > This patch checks the environment variable 'MANTISBT_CONFIG' for a path > to a mantis configuration file. If MANTISBT_CONFIG isn't set, it grabs > the config from "config_inc.php" as normal. This is handy in that you > can install 1 copy of mantis code on a machine and use it to serve up > several different instances of mantis by creating seperate databases and > configurations for each virtualhost and adding a line such as: > 'SetEnv MANTISBT_CONFIG /foo/bar/mantis.php' in each virtualhost section. > > -Brett > > > ------------------------------------------------------------------------ > > # cd to your mantis directory and run 'patch -p0 < mantis_vhost_0.17.5.patch' > # This patch enables the config location to be set from an environment > # variable; making it possible for multiple vhosts to use the same mantis > # codebase. --Brett Carter (br...@ka...) > > diff -rc /tmp/mantis-0.17.5/core_API.php ./core_API.php > *** /tmp/mantis-0.17.5/core_API.php Sun Aug 18 12:53:27 2002 > --- ./core_API.php Wed Sep 18 11:12:26 2002 > *************** > *** 62,67 **** > --- 62,74 ---- > if ( file_exists( "config_inc.php" ) ) { > include( "config_inc.php" ); > } > + > + # Get config from apache vhost > + $t_local_config=getenv("MANTISBT_CONFIG"); > + if( $t_local_config && file_exists($t_local_config) ){ > + include($t_local_config); > + } > + > # Load file globals # @@@ ugly hack for ugly problem. Find better solution soon > require( "./default/config_inc2.php" ); > -- ju...@be... Beta4 Productions (http://www.beta4.com) |
From: Julian F. <ju...@be...> - 2002-09-18 19:44:01
|
Martin Wickman wrote: > Julian Fitzell wrote: > >> Martin Wickman wrote: > > > > >>> return current_user_get_pref ($t_project_id); >>> >>> That is, let the function return the appropriate default value if >>> $t_project_id is null. >> >> >> I assume you mean: >> >> return current_user_get_pref ( 'default_project', $t_project_id ); >> But even then, that feels really wrong to me. Why would I write all >> my functions so they don't do anything unless I pass null in? > > > That was not the intention. My thought was to return a default value if > null is sent in. But providing the default value as an optional argument > is all good and well. 'default_project' is not a default value, it's the name of the field we are getting from the user. > > I think in > >> this case the code you are looking at *is* the function that returns >> the appropriate default value. >> >> My personal favourite solution is in Ruby which lets you do: >> >> foo = bar() >> foo ||= baz() >> >> return foo >> >> "foo ||= bar()" is the same as "foo = foo || bar()" >> >> This works in Ruby because nil behaves like false and || returns >> whichever of its operands first evaluate to a non-false value. > > > Thats pretty clever. I have ment to give Ruby for a spin, but time is > lacking. It is on my todo list anyway. > > Btw, is Ruby free software? http://www.ruby-lang.org/en/LICENSE.txt Julian -- ju...@be... Beta4 Productions (http://www.beta4.com) |
From: <br...@ka...> - 2002-09-18 18:10:53
|
> If you could include appropriate log messages with them detailing what > changes you made that makes it a lot easier to review and a lot quicker > to commit. I've also got a small perl program meant to be run from a cron job that scrapes a mantis database and emails out a daily report of open bugs. If it's of interest to anybody, I'd be glad to post a slightly more generalized version of it here. -Brett |
From: <bre...@ka...> - 2002-09-18 18:08:53
|
> Patch submission is pretty slow (I had the same problem when I started > sending patches). I would say post them here. I promise I'll look at > them if they aren't too huge :) Six lines short enough? :) > If you could include appropriate log messages with them detailing what > changes you made that makes it a lot easier to review and a lot quicker > to commit. To sum it up (there's a summary inside the patch file as well): This patch checks the environment variable 'MANTISBT_CONFIG' for a path to a mantis configuration file. If MANTISBT_CONFIG isn't set, it grabs the config from "config_inc.php" as normal. This is handy in that you can install 1 copy of mantis code on a machine and use it to serve up several different instances of mantis by creating seperate databases and configurations for each virtualhost and adding a line such as: 'SetEnv MANTISBT_CONFIG /foo/bar/mantis.php' in each virtualhost section. -Brett |
From: Julian F. <ju...@be...> - 2002-09-18 17:53:26
|
bre...@ka... wrote: > Is there a proper way to submit patches to the mantis project? I > submitted a patch over a month ago to the author (ke...@30...) > but I haven't recieved a reply. > > I've got a few other pieces of code I'd like to present as well; is this > the proper forum to discuss that? > -Brett Patch submission is pretty slow (I had the same problem when I started sending patches). I would say post them here. I promise I'll look at them if they aren't too huge :) If you could include appropriate log messages with them detailing what changes you made that makes it a lot easier to review and a lot quicker to commit. Thanks, Julian -- ju...@be... Beta4 Productions (http://www.beta4.com) |
From: <bre...@ka...> - 2002-09-18 17:46:46
|
Is there a proper way to submit patches to the mantis project? I submitted a patch over a month ago to the author (ke...@30...) but I haven't recieved a reply. I've got a few other pieces of code I'd like to present as well; is this the proper forum to discuss that? -Brett |
From: Martin W. <mar...@xm...> - 2002-09-18 11:33:22
|
Julian Fitzell wrote: > Martin Wickman wrote: > >> return current_user_get_pref ($t_project_id); >> >> That is, let the function return the appropriate default value if >> $t_project_id is null. > > I assume you mean: > > return current_user_get_pref ( 'default_project', $t_project_id ); > But even then, that feels really wrong to me. Why would I write all my > functions so they don't do anything unless I pass null in? That was not the intention. My thought was to return a default value if null is sent in. But providing the default value as an optional argument is all good and well. > I think in > this case the code you are looking at *is* the function that returns the > appropriate default value. > > My personal favourite solution is in Ruby which lets you do: > > foo = bar() > foo ||= baz() > > return foo > > "foo ||= bar()" is the same as "foo = foo || bar()" > > This works in Ruby because nil behaves like false and || returns > whichever of its operands first evaluate to a non-false value. Thats pretty clever. I have ment to give Ruby for a spin, but time is lacking. It is on my todo list anyway. Btw, is Ruby free software? -- Martin Wickman, X Media Solutions | mailto:mar...@xm... Box 3294, Holmbrogränd 1, S-600 03 Norrköping | http://www.xms.se Tel: +46 (0)11 24 48 49 | Fax: +46 (0)11 24 48 09 |