| ../irclogs/#mantishelp.2009-12-17.log | ||
| --- scribe started --- | 00:00 | |
| paul__ | is the way we've ruined the html formatting of some pages | 00:00 |
|---|---|---|
| dhx_m | sort of like using our custom field implementation for every single field (including built in ones) | 00:00 |
| paul__ | the whole of view.php table is like on 1 line | 00:00 |
| dhx_m | not worth the effort IMO | 00:01 |
| dhx_m | if we're planning on using a templating engine | 00:01 |
| paul__ | well, I care more about the formatting then template engine | 00:01 |
| paul__ | as tbh, I've not yet understood the gain :P | 00:01 |
| dhx_m | all I'm saying is that it is duplicated effort | 00:01 |
| dhx_m | paul__: you could switch templates depending on whether the user is browsing from a mobile phone or a computer | 00:02 |
| nuclear_eclipse | well, if we created a MantisField class, with ->height and ->width integers for spans, then mantis could potentially handle laying them out into a grid/table according to each field's needs, and the field only needs to handle outputting the actual content of the field.... | 00:02 |
| paul__ | height being what? | 00:02 |
| paul__ | colspan/rowspan? | 00:02 |
| nuclear_eclipse | but it always sounds like it would be a *lot* of work to accomplish | 00:02 |
| paul__ | or pixels? | 00:02 |
| nuclear_eclipse | colspan/rowspan | 00:02 |
| dhx_m | also to throw another spanner in here | 00:03 |
| nuclear_eclipse | stick with a standard grid size of eg, 6 columns across | 00:03 |
| dhx_m | there is a lot of demand for the assigned to field (and reporter fields) to be modified to accept a list of users | 00:03 |
| nuclear_eclipse | and then let the 6 columns flow to fit the width of the browser | 00:03 |
| dhx_m | which makes me think that we need to support multi-line "list" fields like assigned users, relationships, etc | 00:04 |
| nuclear_eclipse | dhx_m: isn't that what the bug_handle_threshold is for? | 00:04 |
| dhx_m | nuclear_eclipse: the idea is that you can assign a bug to userA and userB at the same time | 00:04 |
| nuclear_eclipse | oh | 00:04 |
| nuclear_eclipse | that sounds horrible | 00:04 |
| dhx_m | nuclear_eclipse: or multiple users can acknowledge/report an issue | 00:04 |
| nuclear_eclipse | neither user A nor B will feel responsible for the issue then | 00:04 |
| paul__ | that sounds like something to do with what you put in the field | 00:04 |
| paul__ | i.e. if you had a 2 colspan field for 'reporter' | 00:05 |
| paul__ | we can make that listbox/dropdown/ajax popup/whatever | 00:05 |
| dhx_m | I don't really see a need for it either... but the general principle of having a field that contains a list of users is important | 00:05 |
| nuclear_eclipse | lies | 00:05 |
| dhx_m | for instance, a bug_monitor list | 00:05 |
| * nuclear_eclipse plugs his ears and screams random words | 00:05 | |
| paul__ | i'm just wondering if one defined an multidimensial array | 00:06 |
| paul__ | containing fieldname,colspan,rowspan | 00:06 |
| paul__ | whether youcould make something you could build+validate on save | 00:06 |
| dhx_m | nuclear_eclipse: I was thinking that for a bug, you may want to list the people who implemented the fix (programmers) and also the people that reviewed it (there may be more than one) | 00:06 |
| nuclear_eclipse | dhx_m: you just like to make things complicated, eh? | 00:07 |
| dhx_m | paul__: you're still assuming that the output will always be in a tabular format... which won't be true for mobile devices, our current bug_report page, etc | 00:08 |
| dhx_m | nuclear_eclipse: yep :D | 00:08 |
| paul__ | our current bug report page is a table atm | 00:08 |
| dhx_m | nuclear_eclipse: however if we have a proper custom field API, the hard work would be a once off effort that can then be reused for any sort of field you like | 00:08 |
| paul__ | and tbh | 00:08 |
| paul__ | tables do make it easier to work with ;p | 00:09 |
| dhx_m | well it's two columns | 00:09 |
| dhx_m | also it's deprecated :p | 00:09 |
| dhx_m | we should be using the label tag in HTML... and fieldset's to group similar fields (if needed) | 00:09 |
| paul__ | and technically | 00:10 |
| paul__ | even if it wasn't a table | 00:10 |
| paul__ | div tags | 00:10 |
| paul__ | you'd still end up with a table like structure | 00:10 |
| dhx_m | no need for div tags either | 00:10 |
| dhx_m | I prefer "grid like structure" :D | 00:11 |
| paul__ | at some point | 00:11 |
| paul__ | if we define a grid (table atm) | 00:11 |
| paul__ | as having rows/columns | 00:11 |
| paul__ | and putting fields in them | 00:11 |
| paul__ | whether those fields are made up of fieldsets/divs/tables | 00:12 |
| paul__ | to the user defining the grid the logic is the same | 00:12 |
| paul__ | 00:13 | 00:13 |
| paul__ | bedtime | 00:13 |
| dhx_m | yeah I guess | 00:13 |
| dhx_m | ok, cya later :) | 00:13 |
| paul__ | it's when you get funky and say | 00:13 |
| paul__ | with a template | 00:13 |
| paul__ | we could have the fields in a circle | 00:14 |
| dhx_m | let me know if you have further thoughts on it when you're next around | 00:14 |
| dhx_m | haha | 00:14 |
| paul__ | and whilst you could do that | 00:14 |
| paul__ | imo, most people wanna: | 00:14 |
| paul__ | a) be able to customise stuff | 00:14 |
| paul__ | b) be able to skin it to fit into their site | 00:14 |
| paul__ | that to me basically means: | 00:14 |
| paul__ | users wanna: | 00:14 |
| paul__ | a) have a management gui | 00:15 |
| paul__ | b) have some decent css | 00:15 |
| paul__ | i.e. everything has a class etc | 00:15 |
| paul__ | 'template' engines then come down to something we'd use | 00:15 |
| paul__ | (and the few that wanna make a template for a mobile phone | 00:15 |
| paul__ | (however does't an iphone(future?) render most websites without requiring special layouts now a days? | 00:16 |
| nuclear_eclipse | paul__: re iphone, yes, and so does my android phone | 00:16 |
| paul__ | which makes me think | 00:17 |
| paul__ | are the days of difference devices needing different layouts gone? | 00:17 |
| paul__ | (you can define .css to only apply to @print etc right?) | 00:17 |
| nuclear_eclipse | granted, it tends to require a decent amount of horizontal scrolling because mantis is loaded with info, which is why a phone-friendly style would likely want to reducce the number of columns | 00:17 |
| dhx_m | paul__: don't they require you to scroll horizontally as well? | 00:18 |
| paul__ | dunno | 00:19 |
| paul__ | anywy i need to go | 00:20 |
| nuclear_eclipse | gn you two | 00:20 |
| paul__ | tomorrow i'm out (work xmas) | 00:20 |
| dhx_m | cya :) | 00:20 |
| dhx_m | nuclear_eclipse: you're leaving too? | 00:20 |
| nuclear_eclipse | nope | 00:21 |
| paul__ | and then friday = half day, xmas hols so time :) | 00:21 |
| dhx_m | well I'm not either :) | 00:21 |
| nuclear_eclipse | but you said you had to go earlier, so I assumed :P | 00:21 |
| nuclear_eclipse | oh, nvm | 00:21 |
| nuclear_eclipse | that was paul__ | 00:21 |
| dhx_m | hah | 00:21 |
| dhx_m | paul__: have fun with all the parties :) | 00:21 |
| dhx_m | paul__: just remember not to commit anything straight afterwards heh | 00:22 |
| paul__ | it's ok | 00:22 |
| paul__ | i've got a list | 00:22 |
| paul__ | i'll warn you now though | 00:23 |
| paul__ | expect commits from saturdaay -> 4th Jan | 00:23 |
| paul__ | nn | 00:23 |
| dhx_m | backdated from 2008? :p | 00:23 |
| dhx_m | ca | 00:23 |
| dhx_m | cya | 00:23 |
| paul__ | not 2008 | 00:23 |
| paul__ | lets see | 00:24 |
| paul__ | i'd say october | 00:24 |
| dhx_m | ah ok :) | 00:25 |
| CIA-27 | Mantisbt: hickseydr * rdc27985620d7 /javascript/ (dev/projax/scriptaculous.js min/projax/scriptaculous.js): Fix #11207: Disable use of missing sound.js Projax script | 02:02 |
| CIA-27 | Mantisbt: hickseydr master-1.2.x * rcadd14c0dc31 /javascript/ (dev/projax/scriptaculous.js min/projax/scriptaculous.js): Fix #11207: Disable use of missing sound.js Projax script | 02:02 |
| sshirley | Hi everyone! I am using v1.1.0. How does one add or delete categories? For example, right now we have "Defect", "Enhancement", and "General" as categories and we want to get rid of "General". | 15:19 |
| nuclear_eclipse | sshirley: manage -> manage projects | 15:24 |
| nuclear_eclipse | also sshirley, 1.1.0 has many known security vulnerabilities and bugs -- you should really upgrade to 1.1.8 | 15:25 |
| sshirley | How easy is the upgrade? My manager has been reluctant to do that (though I've said we should probably do that). | 15:27 |
| nuclear_eclipse | if you don't have any modifications, it's as easy as dropping the new version of mantis on top of the old one -- just backup your database and old installation first just in case ;) | 15:30 |
| sshirley | There are a couple of mods. But yeah. | 15:32 |
| * paul__ sighs | 15:56 | |
| * paul__ lurks briefly | 18:34 | |
| paul__ | sqlite! | 18:34 |
| * nuclear_eclipse knocks paul__ upside the head | 18:35 | |
| paul__ | oh? | 18:36 |
| paul__ | it's ok | 18:36 |
| paul__ | that's saturday evening | 18:36 |
| paul__ | not now | 18:36 |
| paul__ | got other stuff to do first | 18:36 |
| paul__ | like pub in 5 minutes | 18:36 |
| paul__ | just need tofind dvd iso | 18:36 |
| paul__ | burn it | 18:36 |
| paul__ | and get to pub | 18:36 |
| CIA-27 | Mantisbt: jreese * r429448eebb63 / (core.php core/authentication_api.php verify.php): Fix regression of issue #10930 in commit 0085bcd7 | 21:21 |
| CIA-27 | Mantisbt: jreese master-1.2.x * r4dab8016128e / (core.php core/authentication_api.php verify.php): Fix regression of issue #10930 in commit 0085bcd7 | 21:21 |
Generated by irclog2html.py