On Tue, 17 Jun 2014 23:27:53 +0300 Galatsanos Panagiotis <galatsan...@gmail.com> said:
> You guys are right. It is prefered this way. Especially what raster said > about zooming. > > I've tried to implement a white box to indicate your position in scrollback > but I couldn't find a clean way to do it... > I'll give it a try the week next to this one. (if boris won't) i'd be doing it in edje with a dragable. edje defines the look of the hilight. > Panos > > > On Fri, Jun 13, 2014 at 2:10 AM, Carsten Haitzler <ras...@rasterman.com> > wrote: > > > On Thu, 12 Jun 2014 21:15:52 +0200 Boris Faure <bo...@fau.re> said: > > > > > On 14-06-12 18:14, Galatsanos Panagiotis wrote: > > > > Hello, > > > > > > > > Recently billiob worked around and almost rewrite the patch I was > > asking > > > > help for, last year, for miniview implementation for terminology. > > Minivew > > > > feature is a "map" of the history lines shown in a visual way at the > > right > > > > of your terminal, helping the user to go back in history in ease. User > > > > should be able to click on one point in this map and terminology will > > > > scroll back and show that point in terminal. > > > > > > > > What we have right now is a "history line to pixel" approach for > > drawing > > > > and placing at the right side, so for a terminal window with height > > say > > > > 500px we have only 500lines of history shown and the user have to > > scroll > > > > into the miniviews history to visually find something that goes back > > beyond > > > > line #500. It's like having 2 things for the same purpose. > > > > > > > > What I propose is to draw an image with height pixels equal to > > scrollback > > > > lines (taken from config maybe) and then "squeeze" this image into the > > side > > > > of the terminal window. For example if we have set scrollback to 2000 > > lines > > > > we should draw an image with height of 2000px (each pixel represents > > every > > > > line in history) and then stretch this image to fit the 500px height > > window > > > > of the terminal. > > > > > > I totally disagree with that. I have 10000 lines of history on a > > > terminal of about 600px height. That's about 16 lines of pixels per > > > history. This will just look like some random garbage. > > > The way I use the miniview is to scroll back in history but I still > > > need to make sense of that history. I need to find where was my last > > > prompt: a single line with some colors in a sea of white on black. > > > > > > There is still work to be done on that feature as the following > > > transcript with raster shows: > > > raster → billiob: have u noticed miniview ... has problems? > > > raster → try "tyls" > > > raster → also colors are wrong > > > raster → i'm fixing colors now > > > billiob → it's not a real compositor > > > raster → i know > > > raster → tyls tho crashes terminology > > > raster → thats bad > > > raster → (with miniview up) > > > billiob → hum, I may not have tested that > > > raster → first thing i tested > > > raster → BOOM > > > raster → it just gets colors wrongly > > > raster → it doesnt account for color settings at all > > > raster → io've fixed that locally now > > > billiob → oh, yes > > > raster → now i need to fix size to match aspect ratio > > > raster → fo font > > > raster → billiob: also the smart obj logic is .. weird > > > raster → like the smart show is moving/positing things > > > raster → as opposed to the parent edje > > > raster → miniview really should just be a smart obj with an image > > > raster → and thats it > > > raster → and with some apis to let the caller know its correct "size" > > > raster → and caller swallows and does the rest > > > billiob → hum, right > > > raster → then the theme can slide it in > > > raster → and add all the shadowing > > > raster → also determine sizing/scaling too > > > raster → there should be a hilight area to show the area in the > > > current terminal too > > > billiob → yes, but I didn't know how to do that and not screw up with > > > the colors > > > raster → billiob: should just be another edje object moved/resized to > > > overlay and/or underlay the area on the image object > > > raster → billiob: the base obj should really not be there imho > > > billiob → yes, I didn't know how to organize it correctly due to the > > > special sizing of the widget > > > raster → billiob: i'm fixing some of this. i can leave the rest to you > > > billiob → ok :) > > > raster → but it should be just like the command buffer > > > raster → or the about or options > > > raster → its swallowed and edj of the terminal itself decides where to > > > display > > > raster → align, stack and decorate > > > raster → how to animate show/hide > > > raster → billiob: ok. fixed crash, sizing badness and colors > > > raster → i shall leave the rest up to you > > > raster → :) > > > > > > People also want to use it as a scrollbar and not just an overlay on the > > > current terminal. > > > > oh yeah. i agree. that's why it likely has to also be configurable as to > > its > > zoom level/ the region of scrollback it covers. does it cover all of it? > > just > > the nearest N lines etc. - as a "widget" it shouldn't much care and just be > > told - choosing zoom level is likely the job of some extra big of code - > > some + > > and - buttons, shortcuts, mouse wheel etc. > > > > the idea of a visual scrollback inb miniature is great. how to make it both > > practical (drawing a 10k set of scrollback is impractical due to cost and > > memory size - so we'd have to either fake it by wholesale skipping large > > amounts of scrollback, and likely rendering at a lower resolution and > > pre-anti-aliasing pixels. eg if we have 10k lines we are not making a > > 80x10k > > image. hell no. what we do is make a 2.5k high image and when we draw a > > pixel > > we choose the nearest one (x/4, y/4) and we start with 0 and ADD the r, g, > > b > > and a, but r = r + (newr / 4); so effectively by also dividing the color > > by the > > scaledown and adding we will anti-alias AS we draw a low res version. we > > still > > have the cost though of scannign the whole buffer, which means we likely > > need > > to do this is passes/regions - eg render a low res approximation that just > > skips 3/4 of every line (just picks 2500 of the 10k), and then next pass > > merge > > in the other pair, so 1/4 and then 3/4 gets merged... then another pass > > merges > > 2/4 and 4/4. these passes likely want a worker thread... :) or... we > > render a > > region at a time eg max 1k lines in a region and we hand scrollback to a > > thread, it locks it, and begins rendering regions, handing back each > > region's > > pixel data when done. thread handles anti-aliasing and pre-downscaling. > > > > anyway... for lots of scrollback, these problems need a solution to make > > miniview practical and useful in the big picture. > > > > -- > > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > > The Rasterman (Carsten Haitzler) ras...@rasterman.com > > > > > > > > ------------------------------------------------------------------------------ > > HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions > > Find What Matters Most in Your Big Data with HPCC Systems > > Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. > > Leverages Graph Analysis for Fast Processing & Easy Data Exploration > > http://p.sf.net/sfu/hpccsystems > > _______________________________________________ > > enlightenment-devel mailing list > > enlightenment-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > ------------------------------------------------------------------------------ > HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions > Find What Matters Most in Your Big Data with HPCC Systems > Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. > Leverages Graph Analysis for Fast Processing & Easy Data Exploration > http://p.sf.net/sfu/hpccsystems > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing & Easy Data Exploration http://p.sf.net/sfu/hpccsystems _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
