From: Stephen T. <st...@mo...> - 2006-11-15 20:47:23
|
Hi Andrew, > >Yep, it works and looks good, you should check it in. The only issue >I see is that the window scrolls back to top whenever the pop up menu >fires... maybe it has to do with its positioning in the DOM, I'm not >sure... it should be a child of outerDivMain, I think, not the entire >document. But I'd have to play with it to figure it out. > > > I hadn't noticed that. I'll have a look. >We were thinking about having the pop up menu behave a little >differently - it shoud pop up after hovering over a feature for a >fraction of a second or so, then disappear when dragging starts. The >reason for this is that single-clicking should be reserved for other >things, such as dragging or maybe drawing a little box or something to >select features, etc. (this will come later, it's not well-defined at >the moment). Also, double-clicking to center should be unhindered by >a menu popping up after the first click, but I think that can be taken >care of by cancelling the results of a single-click event if a >double-click comes in... somehow. > > I had it set on mouseover as you described and it felt not quite right for some reason but having a pop up on a hover is how we use the cgi GBrowse and it works great. We can try out a few options and see what's best and I think you are right about keeping the click events free. A rubber banding mechanism might be a good idea in the future to zoom in, for example. >I also see that double-clicking to center (on the main view cell, not >the ruler cell) is broken now, but I think I know why and I can fix it >when the code is in CVS. > > > Ok will check it in. >Next comes the figuring out how to populate the pop up menu with >relevant info... > > Yep. This is more tricky... I think we should try and use as many 'official' GBrowse calls as possible to ensure future compatibility. I wonder if Lincoln or Scott (if they are reading this) could offer any advice? Cheers, Steve >> >> >> >>>I found the problem. Everywhere, including "prototype_gbrowse.html", >>>your URLs should be "https", not "http"... on a whim I portscanned >>>{slave,gbrowse}.molbiol.ox.ac.uk and noticed port 80 is closed, but >>>443 is open... or at least for U.S.-originating packets. >>> >>>So this one: >>> >>>https://gbrowse.molbiol.ox.ac.uk/cgi-bin/gbrowse/coli_demo/?name=U00096%3A1..10000 >>> >>>works just fine. This one: >>> >>>https://slave.molbiol.ox.ac.uk/gbrowse/TiledImage/ecoli/prototype_gbrowse.html >>> >>>seems to load the XHTML, but nothing else. The problem seems to be >>>that the XHTML has "http" instead of "https" for the JavaScript >>>library URLs, so I can't load the JavaScript libraries. If the URLs >>>for libraries were changed to something like: >>> >>>https://slave.molbiol.ox.ac.uk/gbrowse/TiledImage/client/View.js >>> >>>then they would load. >>> >>>I guess there is some firewall config causing this problem... although >>>I'm puzzled why it works for someone from Australia but not the U.S. >>> >>> >>> >>We have worked out what the problem is and it is down to some configuration issues set up by the Oxford IT service which I won't go into since it's so bizarre (unless you're *really* interested :-)). >>http will work in a day or so but in the meantime have a look on our test server. This *should* work... >> >>http://jenna.molbiol.ox.ac.uk/gbrowse/TiledImage/ecoli/prototype_gbrowse.html >> >>I have also added a js pop-up based on one that was originally developed by Sylvain Gaillard and Gaëtan Droc. >> >>If it all works your end I will check it in. >> >>Cheers, >> >>Steve >> >> >>>On 11/14/06, Steve Taylor <st...@mo...> wrote: >>> >>> >>> >>>>Hi Andrew, >>>> >>>> >>>> >>>>>This sounds like excellent news, thanks! But, I'm getting timed-out >>>>>loading both pages you linked to... can you let us know when they're >>>>>back up? I would love to take a look. >>>>> >>>>> >>>>> >>>>Hmmm. I have tested both here and they work reasonably quickly although are more slow to load than the original AjaxGBrowse...I also got a got someone to test in Australia and he said it loaded ok >>>>though slightly more slowly. >>>> >>>>Can you try again please? Has anyone else on the list had time out problems? Again the URLs to try are: >>>> >>>>Ajax Gbrowse >>>>http://slave.molbiol.ox.ac.uk/gbrowse/TiledImage/ecoli/prototype_gbrowse.html >>>> >>>>Original Gbrowse >>>>http://gbrowse.molbiol.ox.ac.uk/cgi-bin/gbrowse/coli_demo/?name=U00096%3A1..10000 >>>> >>>> >>>> >>>> >>>>>You should commit the code to CVS... I've also made a few changes >>>>>across the server-side code (including generate-tiles) to test >>>>>on-demand tile rendering, which will be useful for large genomes, and >>>>>to fix some stupid bugs left in TiledImage, etc. from back in the day >>>>>(e.g. database connections not hanging up), which you probably noticed >>>>>and fixed by now also. Once your code is in, I'll merge in my >>>>>changes. >>>>> >>>>>Just to let everyone know about the "render on demand" stuff... the >>>>>idea is that we still fill a database with primitives, but only render >>>>>tiles as they are request by user (they are also saved, so no need to >>>>>re-render unless the underlying data changes, so we'll have some sort >>>>>of "dirty tile" flag or some such). >>>>> >>>>>This will enable people to put up large genomes without pre-rendering >>>>>all the tiles. Currently, the rendering step is the major limiting >>>>>factor (my benchmarks show around 90% of the actual generate-tiles.pl >>>>>time is spent on database lookup of primitives). For example, Dmel >>>>>arm 4 takes a full day to render on our 24-CPU cluster, but only an >>>>>hour of that time is spent filling the database. >>>>> >>>>>I'm trying a few things to optimize this right now, including the >>>>>on-demand rendering, and I'll keep the list updated once I get >>>>>somewhere (the things I'm trying can be found on >>>>>http://biowiki.org/view/GBrowse/WishList under the "rendering >>>>>optimizations" sublist). I think we could seriously reduce the >>>>>fill/access time, but until then, on-demand rendering will at least >>>>>make large genomes feasible. >>>>> >>>>> >>>>> >>>>Sounds good. Look forward to seeing that! >>>> >>>>Steve >>>> >>>> >>>> >>>>>On 11/13/06, Steve Taylor <st...@mo...> wrote: >>>>> >>>>> >>>>> >>>>> >>>>>>Hi, >>>>>> >>>>>>I thought I'd send this to open up the discussions on the new list!:-) >>>>>> >>>>>>I haven't checked in this code yet but I have modified generate-tiles.pm and BatchTilesImage.pm to allow marking up of the features in each of the tiles using client side image maps. We may want to >>>>>>change this later to do CSS maps but that would be only a small code modification. It basically generates an html file per tile with an inlined image and the appropriate map coordinates. The browser >>>>>>XMLHttpRequests the data over when it needs to using Ajax.Updater (from the js library Prototype). >>>>>> >>>>>>You can see what it looks like on: >>>>>> >>>>>>http://slave.molbiol.ox.ac.uk/gbrowse/TiledImage/ecoli/prototype_gbrowse.html >>>>>> >>>>>>Try dragging and clicking on features. >>>>>> >>>>>>Advantages of current implementation >>>>>>----------------------------------- >>>>>>- should work on all browsers and doesn't require any fancy javascript >>>>>>- will support polygons, ellipses etc >>>>>>- allows distribution on different servers for tiles >>>>>> >>>>>>Disadvantages of implementation >>>>>>------------------------------- >>>>>>- all html per tile currently generated server side (not sure if this is an advantage or disadvantage at this stage) but may be a pain to do updates >>>>>> >>>>>>Obviously where javascript:alert('Active image map') you should have the relevant details of the feature and a nicer pop up. The js alerts are pretty annoying at the moment when dragging! I intend to >>>>>>put js pop ups similar to the ones we have at http://gbrowse.molbiol.ox.ac.uk/cgi-bin/gbrowse/coli_demo/?name=U00096%3A1..10000. >>>>>> >>>>>>Let me know what you think. I will check it in if people think it is worthwhile at this stage. >>>>>> >>>>>>Regards, >>>>>> >>>>>>Steve >>>>>>------------------------------------------------------------------ >>>>>>Head of Computational Biology Research Group >>>>>>Medical Sciences Division >>>>>>Weatherall Institute of Molecular Medicine/Sir William Dunn School >>>>>>Oxford University >>>>>>Tel: +44 (0)1865 (2)22640 (WIMM - Monday to Wednesday) >>>>>>Tel: +44 (0)1865 (2)85732 (Dunn - Thursday to Friday) >>>>>>Web: http://www.compbio.ox.ac.uk >>>>>> >>>>>> >>>>>> >>------------------------------------------------------------------------- >>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 >> >> >> > >------------------------------------------------------------------------- >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 > > > |