Closed GoogleCodeExporter closed 9 years ago
And you know since I'm jotting down my notes, maybe I'll take a look at how
much would be involved in re-implementing in jquery.
Original comment by deansofer
on 31 May 2011 at 10:36
People wishing to contribute just normally send a patch. If there *is* a
will+skill to do so, this code repository is completely sufficient :)
I may eventually migrate to Mercurial hosting here on Google code (which allows
forking as well), but only if there are enough requests to do so.
Original comment by ondrej.zara
on 31 May 2011 at 8:37
As for the jQuery reimplementation - are there any true advantages of doing so?
Using jQuery just means that every script kiddie without deeper JS knowledge
will feel more competent when looking at the code. I am not sure I want that :)
Original comment by ondrej.zara
on 31 May 2011 at 8:40
Hah, I was just wondering if it would 1: condense the code at all and 2:
empower more user contribution.
Script kiddies asside, any helpful patches are good patches. Especially since
your oz repo has a big message on it saying "You probably won't know how to use
this thing", which I think goes beyond a concern with script kiddies.
Anyway, when I was thinking about it one of the things I was wondering is maybe
(if we really wanted to optimize) we should be looking at canvas and skip
jquery altogether. However I think it may become more tedious just having to
build an interactive gui for canvas rather than working with simple html
elements.
Original comment by deansofer
on 31 May 2011 at 11:39
Yeah, oz.js is not well documented. OTOH, it is only kB uncompressed - and most
of that are ECMA Array prototypes for older browsers.
Incidentaly, I was also thinking about switching the rendering backend
completely to canvas, now when IE9 also supports this API. This would
automatically solve the "print / save as image" issue, for instance...
However, rendering into a canvas of this size does not seem to be feasible,
from the performance point of view. Maintaining a canvas of 2000x2000 pixels
and re-rendering it each time a table is moved, hm, I guess that would kill a
browser. Or maybe I am mistaken? Some measurements must be made here...
Original comment by ondrej.zara
on 1 Jun 2011 at 6:03
I sorta dropped the thoughts about jquery for now. However, I don't think you
should bother supporting printing/saving because people can use simple
screenshot plugins. Frankly, you'd be just as well off searching for a js
snippet someone made completely self-contained for taking screenshots or
printing. For that very reason, it's less within the scope of critical issues
(IMHO).
Original comment by deansofer
on 1 Jun 2011 at 6:07
You still should port to Github (or switch to mercurial I guess? never used it
before). Either that or finally get around to merging in some of the patches
floating around :)
Original comment by deansofer
on 1 Jun 2011 at 6:07
Which patches? I am not fully aware of any pending patches out there...
Original comment by ondrej.zara
on 1 Jun 2011 at 7:46
http://code.google.com/p/wwwsqldesigner/issues/detail?id=60#c9
http://code.google.com/p/wwwsqldesigner/issues/detail?id=45#c3
These were the only 2 I found, although looking through all the issues, a few
of em seem like duplicates you could probably close or offer a 'defacto'
solution (such as printing). I wouldn't keep suggesting phantom though, I would
just compile a list of screenshot tools/plugins
Original comment by deansofer
on 1 Jun 2011 at 9:21
Successfully migrated to Mercurial. People can fork this now :)
Original comment by ondrej.zara
on 20 Jun 2011 at 6:09
Original issue reported on code.google.com by
deansofer
on 31 May 2011 at 10:31