On Mon, Oct 13, 2008 at 13:47, Per Cederberg [EMAIL PROTECTED] wrote:
For version 1.5 I think we should consider having a nice little
download web page where you can customize your packed version of
MochiKit. I created a little dummy UI to show what I mean:
I have seen many problems with MochiKit.Selector while testing
MochiKit.Query module. As `Per Cederberg` is preparing for 1.4
release, I think MochiKit.Selector should not be included in 1.4, but
let we get something really useful with Sizzle which is going to be
integrated in MochiKit (hopefully
On Mon, Oct 13, 2008 at 14:43, Amit Mendapara [EMAIL PROTECTED] wrote:
I have seen many problems with MochiKit.Selector while testing
MochiKit.Query module.
You would be helping if you submitted these as bug-reports.
Arnar
--~--~-~--~~~---~--~~
You received
I'd appreciate bug reports for the MochiKit.Selector module in Trac or
here on the list. I've got 1-2 previously here in this thread that I
intend to have a look at soon.
Either way, I think we are beyond removing MochiKit.Selector entirely
for 1.4. I'll update the docs to point out that it is
On Mon, Oct 13, 2008 at 14:52, Per Cederberg [EMAIL PROTECTED] wrote:
Also, I'll add
specific notes for those selectors that won't be compatible with the
new Sizzle-powered version.
Assuming the bug in Sizzle that causes [attribute] to fail will be
fixed, the only ones that will not work are
On Oct 13, 5:52 pm, Per Cederberg [EMAIL PROTECTED] wrote:
I'd appreciate bug reports for the MochiKit.Selector module in Trac or
here on the list. I've got 1-2 previously here in this thread that I
intend to have a look at soon.
Once, I filed a bug report on the trac (related to
On Mon, Oct 13, 2008 at 3:13 PM, Amit Mendapara
[EMAIL PROTECTED] wrote:
Once, I filed a bug report on the trac (related to Sortables), but I
was unable to change/comment it later. That's why I never submitted
again.
Yes, this is very unfortunate. I used to have the same problem, so I
hear
On Mon, Oct 13, 2008 at 15:24, Per Cederberg [EMAIL PROTECTED] wrote:
On Mon, Oct 13, 2008 at 3:13 PM, Amit Mendapara
[EMAIL PROTECTED] wrote:
Once, I filed a bug report on the trac (related to Sortables), but I
was unable to change/comment it later. That's why I never submitted
again.
The version of trac is okay. See http://trac.edgewall.org/wiki/TracPermissions,
you can easily prevent those spams. You can see how TurboGears trac is
configured...
You can also think about moving MochiKit to Launchpad.net. It's really
a good platform to host OpenSource projects with distributed
Well, the login database is outside of trac since we're using basic
auth to login and they are the same credentials that give svn commit
access. Disabling anonymous commenting is something that I did because
I couldn't be bothered to implement a better spam filter or maintain
it.
I'm not really
On Mon, Oct 13, 2008 at 17:19, Bob Ippolito [EMAIL PROTECTED] wrote:
I'm not really sold on launchpad, I think bzr would be too much of a
barrier to entry for many people. I would certainly consider moving to
google code though, because that would be easy enough. All of our
other open source
I've been considering this for a while but didn't want to put forth
the effort at the time, but I think that with the release of 1.4 it
would be a good time to migrate from the Mochi Media hosted Trac and
SVN over to something else. My personal preference is Google Code
because we already use
I had intended to build exactly that years ago, but never got around
to it... mostly because it's hard to do client side and I didn't want
that feature to be dependent on some server-side script.
My thinking was that we'd keep packed versions of every module (so
that we could continue to use the
Seeing that this wasn't just an omission, I won't change it for the 1.4 version.
For version 1.5 I think we should consider having a nice little
download web page where you can customize your packed version of
MochiKit. I created a little dummy UI to show what I mean:
Google code seems fine by me. Especially if we get better access for
normal users.
The only issue I come to think of is that the mochikit.com web site
automatically updates from svn trunk. Don't know if it would be easy
to keep that link. Something which is pretty good to have from time to
time.
AFAIK Flash can't save to disk in that manner either.
You can build Flash content with free tools though (Adobe Flex 2 SDK,
MTASC, haXe, etc.).
-bob
On Mon, Oct 13, 2008 at 11:51 AM, Per Cederberg [EMAIL PROTECTED] wrote:
Scary stuff. JS in JS... :-)
I also gave the download issue some
Keeping the commit hooks for updating the site is possible, I'll
probably set up a svn mirror at or near the current svn repository and
our internal tools will be able to update that. Might have to hook up
some kind of mail hook thing to have it happen instantly though, I
don't think google code
On Mon, Oct 13, 2008 at 2:24 PM, Arnar Birgisson [EMAIL PROTECTED] wrote:
Minor usability pointer: When unselecting a module, instead of
unselecting everything that depends on it - highlight the relevant
part of uses XXX of those in some /error/ color.
I fooled around a bit with the visual
On Mon, Oct 13, 2008 at 22:09, Per Cederberg [EMAIL PROTECTED] wrote:
I fooled around a bit with the visual effects instead...
http://www.percederberg.net/mochikit/pack.html
Ah, nice, very nice.
As for the other thing (generating the pack) - I don't think there is
a good, clean way to do it
Hi again,
On Mon, Oct 13, 2008 at 22:23, Arnar Birgisson [EMAIL PROTECTED] wrote:
Although, there is one outrageous possibility: We could pregenerate
all possible combinations of modules. Now, before you call me crazy,
note that even if 14 modules could potentially mean 2^14~=16k
different
20 matches
Mail list logo
