Do NOT post raw bugs in here. This is a developer work list first, a design list second, a bug-tracker only for bugs that have been refined to the "we know how to solve" stage.
Wishlist and feature-type items should go on FutureFeatures
- Things to do
- lower priority buglist
- Issues
- Bizzarre browser bugs
- Things that are done
- unclassified bugs and other new things
1. Things to do
-
straw polls should not have d-rules, nor reporting. but they SHOULD close (from a meta-old comment)
-
general document filetype uploads
-
new folioitem class: lib/asdfasdfdasf
-
two-frame split *within* folio view
-
etc etc etc
-
url?
-
clickable link system
2. lower priority buglist
2.1. meeting area ui
-
DAILY DIGESTS are currently BROKEN. If you manually run do-daily-digest.php things seem to work? but being invoked from the cronjob seems to fail.
-
vote closing: results (i.e. the winning propositions) should be displayed SOMEWHERE -- probably the closing mesage?
-
folio index: sort by doctags is string-sort-based, which is bad because you get the 1 < 10 < 2 problem. This only crops up when you have more than 9 documents, of course.
-
vote creation: disable enter key=submit binding like how it is for post-main and doc creation. One person on the demo accidentally submitted too soon for a straw poll.
-
smarter popup sizes: should be based on the current size of the frameset window. Especially for expand${frame}'s. post-popup could be nice to be similar sized as curmsg, etc... I think javascript can get current sizes this by introspecting the window object.
-
Appr/Disappr closing announcement email should include Implementation details.
-
general comments
-
still need to do refs-in-folio-index for comments general to the marea. And also the "Comment on Item" functionality to create general comments in the case of polls, discoitems.
-
hide msglisttoolbar Expand, Collapse when on a non-threaded view like Date or Author. (also make them work on threaded views in the first place!)
-
improving tooltip help. Current implementation looks like the HTML title= tag... for example, http://www.javascriptkit.com/howto/toolmsg.shtml . Search for "html tooltips" to get more specialized js libs... for example http://www.platnum.cn
-
fix ordering for doc revisions in green dropdown (currently it's all documents, by date)
-
should somehow show which props one, on the closed poll view. Mark them out or something. This can be implemented by calling drule->evaluate() again.
-
add "cancel" button to compose window (re: "also - todd - Aug 04, 22:21" in "orig glossary" discussion, meta-old)
-
add menubar to Compose popup ("re: oh, it's POD's problem - brendan - Aug 05, 01:41" meta-old)
-
don't lose selected message upon reload (re: "losing selected message on reload - todd - Aug 04, 22:52" meta-old)
-
crop runaway lines in document (re: "runaway lines need to be cropped - todd - Aug 12, 14:27")
-
no?: runaway lines are only from single-word strings that are very long (in practice, only url's do this) This requires arbitrary splits within a word; after 20 characters, you arbitrarily insert a space, for instance. (slashdot comments do this). This would be bad: splits in bad places in a word. Splitting url's is worse, though it could be done intelligently so the url is still functional.
-
need to research: How do you do this while preserving copy-and-pasteability??? Is there a magical CSS attribute? It's easy for pine because it knows its fixed window width only.
-
Potential solution: split url's but not normal words
-
internal maximize buttons.
-
add the internal toolbars inside the maximized windows
-
maximized windows should actually be identical size to the current marea window, or at least not the weird skew as it is now
-
clicking links and controls inside the window currently (12/20) updates all frames of the home marea window *except* for the one that is maximized. This is because it is implemented by proxying the 'frameset' object to be 'opener' instead of 'parent'. It's a hack that kinda works, but really, all the ui code assumes that it's being run within the 7-frame environment.
-
to solve this, it seems, would require a big architecture revamp to have a general UI driver that could work for multiple views, where the 7-pane marea view is only one of them. the single-maximized-pane would be another view. A view for persons with disabilities might be another. You'd have to have an architecture where you could write plugin object/modules that implement general ui commands like like view_object and view_message, but the ui itself is driven through these abstracted ui state-change commands.
-
this general abstraction layer would be tricky to design to cover all possible ui's. and then you're doing this all in javascript, hardly a language that supports well-defined interfaces and such.
-
This sounds hard. therefore will only happen in distant future.
-
might be able to do yet another hack for internal maximize buttons though.
-
http:// links get clickable.. in both ws-doc and curmsg? upon view or store? store for msg, definitely, may be easier for doc upon view since that's the current model, mostly.
-
Scrolling to the hilite in the other window (autoscrolling). Currently implemented with document.location.hash; it's super easy, but isn't perfect -- it moves as one snap, and shows zero above context, we'd ideally want both abaove and below. I see two alternatives, neither very good at this time...
-
could make a system of higher-than-where-you-want hashes, snap to those. Perhaps, say, 40 characters before where you want to be.
-
dive into the hell of scrollX/scrollY. Lots of cross-browser incompatibilities? IE 6 alone has two different behaviors depending on your doctype delcarations... and 4/5 world is far worse.
-
Make all toolbars have little gif/png icons instead of plaintext as now... this is especially necessary for making the control frames for the disco viewer, folio viewer, and comment viewer, since you have better per-pixel control. i think visual icons are easier to use too. and it justifies the term "toolbar".
-
replace the calendar date selector with the slick one from http://dynarch.com/mishoo/calendar.epl (author of htmlarea) or also http://dynarch.com/mishoo/calendar/ Plus, it's more complete, has better documentation, and the author is clearly committed to the project, willing to improve it and maintain cross-browser compatibility.
-
default selected date in new poll/vote creation UI
-
perhaps should switch to dynarch.com jscalendar while we're at it? i think it's more customizable
2.2. non-marea ui bugs
-
make non-marea pages stop looking like shit
2.3. internals and performance changes
-
rename metadb 'users' -> 'allusers' so that both metadb and db could be the same mysqldb for a single-group install.
-
The testing for this will be ugly, may wait. grep reveals some 78 potential uses of "users" in this context that would have to be inspected. I'd guess you'd need to grep for all metadb or meta_connect occurrences than manually go thru the looking for queries involving the 'user' table. However, this is useful for getting POD running in shared hosting environments (if you ahve only one database)
-
do more testing of join_group() for new users, on preexisting polls.
-
D-Rule testing framework, started in testDecisions.php, needs a lot more work. It's far too hard to manually test them via the web interface, hopefully this will help.
-
cron.php
-
DONE: make a unified cron.php that can be run from code/ for ALL groups within the installation. Currently, a separate cron.php crontab entry is needed for every group. This is very easy to forget to add.
-
get cron.php working via wget/lynx for systems without standalone php interpreter, or to be run via cron access on a different system with mere http access to the server.
-
stick the doctag on the END of the downloaded filename when you download it. This means, implementing more symlinks in files/ &tc.
-
moving the announcement of a poll closing from 1 Announce Action per prop, to the poll as a whole. So no double-email on a tie.
-
Shortening the docspaces for DL and maybe parsing times...
-
SQ: <span class=empty_spot_unhilited onClick="selectspot(5);"> </span>
-
Better: <span class=e onClick="s(5)"> </span>
-
But the real solution could be javascript parsing thru innerHTML. That is, you download a version with spaces that are actually spaces, then run it thru a js fn that linkifies all the spaces. Much shorter download time, but it might be a lot for js and the js interpreter to handle.
-
make /files hierarchy without using symlinks? http://us4.php.net/manual/en/function.highlight-file.php shows possibility of CGI env vars, PATH_TRANSLATED most notably.
-
abolishing symlinks would be a step towards porting to windows/php/apache beyond linux/php/apache.
-
in-doc docref hiliting is SLOW: because 'getElementById' is O(n) which kills you for a long document with an id= tag for every single space. [O(n) is unconfirmed, picked it up from some dhtml performance webpage, it sure seems right... the browser has to navigate dumbly through the entire DOM tree, which is pretty dang big because *every* space has a DOM node associated with it.] Long documents take much longer to hilite an indiv docref; this seems to confirm that the lookup is O(n) for the number of spaces in the document.
-
potential hashing solutions: is it the case that a symtable/obj attr lookup in javascript is O(1)? It sure would be if symtables are implemented with hashtables, which is logical and is done in every other common interpreted programming language under the sun. If so, could use IE document.all for O(1) lookup for docrefs. Moz might be able to do it if you use the name= attribute??
-
and yes, such a strategy would violate the grand dream of the DOM and getElementById. Well, it's their fault it's implemented with a shitty function that's O(n) for no good reason.
3. Issues
4. Bizzarre browser bugs
-
1/28/04: on moz 1.4-ish, a marea name in the marea column of the frontpage that's especially long exhibits weird behavior: you mousedown on it then it compresses (rewraps) left-right. Weird to reproduce. If you try to click on the right side of the link, it compresses away before you mouseup and no click is registered.
5. Things that are done
-
"Folio index" --> "Index of items" terminology in marea
-
"Folio" can remain in the glossary, etc., and maybe we'll eventually put it in a label/title space for the left pane, but my current feeling is that it doesn't need to appear in the folio viewer itself.
-
DONE: 12/26. "items index" used instead, less cumbersome
-
FIXED 1/11/03: File uploads: currently don't work on Win IE 6; you click "Upload" and stuff happens, but then just the library page reappears with no file uploaded. Works fine on Moz.
-
more than this man... look for the "DONE:" tags as well as the fact oftentimes entries are straight out deleted.
6. unclassified bugs and other new things
-
in-doc docref hiliting is SLOW: because 'getElementById' is O(n) which kills you for a long document with an id= tag for every single space. [O(n) is unconfirmed, picked it up from some dhtml performance webpage, it sure seems right... the browser has to navigate dumbly through the entire DOM tree, which is pretty dang big because *every* space has a DOM node associated with it.] Long documents take much longer to hilite an indiv docref; this seems to confirm that the lookup is O(n) for the number of spaces in the document.
![[WWW]](/wiki/classic/img/moin-www.png){kind=small}
Promo Codes mobile- potential hashing solutions: is it the case that a symtable/obj attr lookup in javascript is O(1)? It sure would be if symtables are implemented with hashtables, which is logical and is done in every other common interpreted programming
-
language under the sun. If so, could use IE document.all for O(1) lookup for docrefs. Moz might be able to do it if you use the name= attribute??
PC pitstop Promo Code - dive into the hell of scrollX/scrollY. Lots of cross-browser incompatibilities? IE 6 alone has two different behaviors depending on your doctype delcarations... and 4/5 world is far worse.
Vistaprint Promo Code - to solve this, it seems, would require a big architecture revamp to have a general UI driver that could work for multiple views, where the 7-pane marea view is only one of them. the single-maximized-pane would be another view. A view for persons with disabilities might be another. You'd have to have an architecture where you could write plugin object/modules that implement general ui commands like like view_object and view_message, but the ui itself is driven through these abstracted ui state-change commands.
-
Scrolling to the hilite in the other window (autoscrolling). Currently implemented with document.location.hash; it's super easy, but isn't perfect -- it moves as one snap, and shows zero above context, we'd ideally want both abaove and below. I see two alternatives, neither very good at this time...
-
could make a system of higher-than-where-you-want hashes, snap to those. Perhaps, say, 40 characters before where you want to be.
-
dive into the hell of scrollX/scrollY. Lots of cross-browser incompatibilities? IE 6 alone has two different behaviors depending on your doctype delcarations... and 4/5 world is far worse.
