| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
Abstacted a simple set of reusable functions for generating dropdown
lists, as I'm likely going to need that more often.
|
|
This *should* be more standards-compliant, and *should* work in all major
browsers. But I really have to test that.
|
|
Time to clean up the javascript code a bit, this is a start...
|
|
Mainly because someone offered to translate the interface into
Hungarian, and interface languages are directly linked with database
languages.
|
|
OK, these are actually two separate things: to make the relations
translatable they didn't necessarily have to be stored as enum, and I
could've also converted them to enum but not have it translatable.
Nevertheless, it was easier to just do both at the same time.
Also note how I used the string "$____vnrel_<rel>____$" as identifier in
the relation graphs while I could have used something a lot shorter
("$<rel>$" would have been fine, for example). This is done so that
graphviz can make some space for those relations - the long identifier
gives a slightly more realistic representation of the actual length of
the relation titles.
|
|
|
|
|
|
Had to increase the size of icons.png a bit...
|
|
The subform id is now passed to htmlForm() as first formpart item. This
way the id won't change even if the title does, which will be the case
with the interface translation.
|
|
Damn, my javascript code is pure crap...
|
|
That image hasn't been used for a while. Used to be a selection
indicator for category filters.
|
|
Now the last unused space in icons.png is used as well. Another icon and
we'll need to enlarge it a bit.
|
|
There were only two states, processed and unprocessed, so simply
using a boolean column with correct naming is more clarifying.
|
|
|
|
|
|
|
|
It was a rather stupid and buggy idea...
|
|
|
|
Makes use of cookies to store the users' preference. Might be a good
idea to store this in the DB for logged in users, together with the
tagspoil cookie.
|
|
This way, we can just use our internal database date format for
client-side communication as well. The calculation is now done in
a centralized place in script.js, rather than all over the place in
the Perl code.
This'll also make it possible to make the date selector more
interactive. But that doesn't have a very high priority at the moment,
the good old three-selection-boxes-thing works fine.
Current implementation has only been tested on FF3, though I doubt
other browsers will complain.
|
|
|
|
|
|
This is what you get when you write half-hearted code and end up
having to change something afterward, you just always forget
to update *something*.
|
|
|
|
Conflicts:
lib/VNDB/DB/Discussions.pm
util/updates/update_2.3.sql
|
|
|
|
The categories are still available for viewing and editing to aid
in the transition to the tagging system, but editing has been removed.
|
|
|
|
|
|
second search
|
|
|
|
|
|
(interface is somewhat on the half-hearted side, but oh well)
|
|
And a "Don't forget to submit" text, and various important bugfixes,
and... geez, time for a coke with some cookies!
|
|
|
|
|
|
The usual: it's still pretty much useless and unfinished, will polish
up things later.
|
|
This'll make it possible to run the actual vndb in debug mode without
displaying that "this is not VNDB" message. And non-VNDB sites can now
properly run without debug mode while still displaying that message.
|
|
|
|
...in less technical terms: producers/vns are automatically added
when selecting them from the dropdown search, rather than having to
press the return key a second time.
|
|
|
|
|
|
|
|
Fixes (or more accurately, masquerades) the following:
13:40:23 <EchoMateria_Work> it displays a list of candidates, I can
point them alright, but when I click on any, it doesn't do anything
other than closing that drop-down-menu 9/10 of the time
|
|
Only tested this using FF3 for now, so may not always work.
|
|
|
|
The skin generator itself is now pretty much finished. Unless people
want more control over what they can change, that is.
|
|
So, instead of using separate smaller CSS files to overwrite
directives in the main (/static/f/style.css) file, I decided
to generate one CSS file for each skin, which includes everything
needed to render the page. The template for this skin is now
/data/skingen/style.css.
I just don't feel like maintaining two separate files when
changing something to the CSS.
Also converted the old layout into a skin directory (angel),
since the default skin isn't in the CSS template anymore.
|
|
generator
|
