gmod-ajax

[Gmod-ajax] ViewerComponent.js cursor

[Mitch S. <li...@ar...>]

I just randomly came across this as I was working my way through reading
the code, and I happened to have dealt with this recently.

If the patch doesn't make it onto the list as an attachment, I'll try
again and paste it into the body of the message.

It would be nice if the cursor was the open hand (-moz-grab) while over
a draggable area and the closed hand (-moz-grabbing) while actually
dragging.  We could make dragDiv*Style.cursor="-moz-grab" in
VewerComponent.js to start with, but I imagine we'd want the cursor to
be something other than -moz-grab when it's over an actual feature, and
I can't think of how to do that off the top of my head.  Can you attach
styles to imagemap regions?

I haven't tested this in context, as I haven't gotten the full
ajax-gbrowse setup going on my machine yet, but I believe it's correct,
or at least close.

Mitch

Re: [Gmod-ajax] ViewerComponent.js cursor

[Andrew U. <and...@gm...>]

Hi Mitch....

Sorry for taking so long to reply (this goes out to everyone,
actually), I've been away for a bit, among other things... but now I'm
trying to catch up.

I checked your cursor patch and it looks good; I'm going to check over
the two others, apply them and commit them shortly.

You should actually be registered as a developer on the SourceForge
GMOD project so you can commit the changes directly... I'm not an
admin, so I can't do it, but you should e-mail your SF login to Scott
Cain (ca...@cs...) who can add you to the project.

Thanks for your help!


Andrew


On 11/16/06, Mitch Skinner <li...@ar...> wrote:
> I just randomly came across this as I was working my way through reading
> the code, and I happened to have dealt with this recently.
>
> If the patch doesn't make it onto the list as an attachment, I'll try
> again and paste it into the body of the message.
>
> It would be nice if the cursor was the open hand (-moz-grab) while over
> a draggable area and the closed hand (-moz-grabbing) while actually
> dragging.  We could make dragDiv*Style.cursor="-moz-grab" in
> VewerComponent.js to start with, but I imagine we'd want the cursor to
> be something other than -moz-grab when it's over an actual feature, and
> I can't think of how to do that off the top of my head.  Can you attach
> styles to imagemap regions?
>
> I haven't tested this in context, as I haven't gotten the full
> ajax-gbrowse setup going on my machine yet, but I believe it's correct,
> or at least close.
>
> Mitch
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>
> _______________________________________________
> Gmod-ajax mailing list
> Gmo...@li...
> https://lists.sourceforge.net/lists/listinfo/gmod-ajax
>
>
>
>

Re: [Gmod-ajax] ViewerComponent.js cursor

[Mitch S. <li...@ar...>]

On Mon, 2006-11-27 at 13:17 -0800, Andrew Uzilov wrote:
> I checked your cursor patch and it looks good; I'm going to check over
> the two others, apply them and commit them shortly.

Don't feel too rushed; I'm not sure if the memory storage patches are
ready to go in.  My main goal with them was to make something simple
that could be compared with the database version.  If you like the idea
then there are still some decisions to make:

If we want to make memory/database a run-time option, then some more
reorganization is needed.  Maybe DatabasePrimStorage and
MemoryPrimStorage classes?  Anyway, the patch as it is certainly can't
switch at run-time.

If we want to give up on the database version and take it out, then a
different reorganization would be better IMO.  My first impulse would be
to merge BatchTiledImage with TiledImage, but I'm not sure how well the
users of TiledImage (other than BatchTiledImage) would work with that.

If we're not sure yet, then I think it's fine to leave the patch out of
the tree for a while.

My hope was that memory or database would be the clear winner and that
would save us from carrying the extra code.  As I see things, it depends
on whether or not the memory version uses too much ram on large/complex
tracks, and whether or not the memory version can be made fast enough to
make render-on-demand less interesting.

I'm not sure how much work you've done on render-on-demand.  Also, are
there reasons for it other than pre-rendering taking too long?

If no one beats me to it, I'll probably get the chance to make some
measurements before next week.  Hopefully that will answer the speed and
memory usage questions.  I'm also hopeful that it's possible to improve
on those things a bit from the current version.  I've been trying to
render without -r, and it seems to be taking much more memory than any
individual track/zoom render, which surprised me because I thought each
track/zoom combo was a different BatchTiledImage and I expected them to
get garbage collected after they got used.  Clearly I'm missing
something at this point, and it needs some more work.

Mitch