ideas to start implementing overview bar?

[ehab]

i also would like to see a search / bookmark overview bar like in chrome browser and also a firefox plugin, this was requested in "What features and/or improvements would you like to see in SlickEdit?"

http://community.slickedit.com/index.php/topic,4972.msg21177.html#msg21177

my idea to use use ida_like_highlight by Ding Zhaojie and this will update an overview bar.

so i want to know is it possible this way:

1- Create a custom form and drop an image, size it so it auto expands vertically with a fixed width then can be docked beside the vertical right scroll bar "no form visible - only when docked out" .

2- When an event happens e.g. mark_all_occurences called this will update the image with findings, this means drawing on the image couple of lines with respect to size of file, line number location. This will indicate the position of the finding and user can click on the actual buf scroll bar to move.

3- the drawing on image can be made externally for example calling a dll and call back will just load the image.

this is a really feature i would like to see. If SE team are not planning having this feature on i would like to try to implement it. So if any have already done this somewhere else any pointers would be great.

regards
ehab

[chrisant]

Yes, I'd like this too, and that sounds like it could be a good start.

Seems like using the line-modified flag colors could make sense.
I'd expect the tricky part to be efficiently detecting when to update the image.
Another potentially tricky part might be convincing the image scaler to use weighting instead of dropping pixels, or to favor dropping "blank" pixels (the implication being that I assume if the bar is 100px tall and the file has 200 lines then a 200px tall image would be scaled into 100px -- versus showing a scrollbar to scroll the overview).

Over the holidays I might have some spare time to help tinker on this -- send me a private message if you want to coordinate.

A fancy v2 feature might be to use syntax coloring to choose the color to show in the bar, but it makes sense to get a prototype working first. 

[ehab]

we can draw directly on the form, take a look at this code:

i got this from the help file, search for _draw_rect:

Code: [Select]

ctlcommand1.lbutton_up()
{
     selected_wid=orig_wid=p_window_id;
     p_window_id=selected_wid.p_parent;

     _save_draw_setup(draw_setup); // not needed now
 
     p_fill_style=PSFS_TRANSPARENT;
     p_draw_width=1;

     p_draw_style=PSDS_DASH;
     p_draw_mode=PSDM_XORPEN
    fgcolor=_rgb(0xEB,0x52,0x54);
    bgcolor=0;  /* Not used since p_fill_style=PSFS_TRANSPARENT */
    x1=10;y1=10;x2=400;y2=400;
    _draw_rect(x1,y1,x2,y2,fgcolor,bgcolor,'e');
    message('yes its called');
}

you can create a form, drop a button with event lbutton_up paste the above, load the form and run, click the button and you have a rectangle.

so i feel it is possible , use lines/colors , use the internal SE search results etc ... make it fast

i will be on holidays soon and back after xmas and if you didn't start already when i get back i'll get down to it.

thanks for the interest and best wishes for now. Lets do this

ehab

ps: look at the attachment

[Clark]

I read this too quickly to comment on the desired feature.

This type of drawing on a form with _draw_rect won't be supported in the next release. Sorry

[ehab]

thanks for the heads up. Best solution is to use a dll

[Graeme]

I don't quite get this.  What is the information that you're going to be showing on the overview bar?

[ehab]

some link info if you didn't use chrome or FF+plugin scroll bar

http://www.usabilitypost.com/2008/09/19/using-the-scrollbar-to-display-information/

it can be:
Bookmarks
error locations
match

hope you get the idea

[Graeme]

some link info if you didn't use chrome or FF+plugin scroll bar

http://www.usabilitypost.com/2008/09/19/using-the-scrollbar-to-display-information/

it can be:
Bookmarks
error locations
match

hope you get the idea

I get the idea but I don't see the point of it.  You can already step through error locations.  Why would you want to jump around rather than step sequentially through them - and why not use the message list?.  Same goes for bookmarks - why would you want to jump around.  The bookmarks toolbar lets you sort bookmarks by file.  And same for match  - is this search match?  The search results toolbar shows you a list of all matches.  Why not use that?

[ehab]

this is helpful for reviewing code. it gives general idea, eclipse, hippoedit, others do it. Why not slick. all in all its a good feature for me to have since i have been fixing legacy code and newer implementations.

this feature will complement ida like highlight macro.

[chrisant]

Sorry for the long response, but you asked why: 

Diff tools typically show an overview bar indicating where the files are different, and I think we all see the value of an overview bar in the context of diffs.  Editing a file is the process of introducing diffs -- is it really that different?

When I'm editing a 2,000 line file and making changes, I can only see 60 lines at a time.  It feels restrictive to my mind; I want "landmarks" and more context.  Especially in unfamiliar files -- when working in teams with 500 to 2,000 other developers in projects with anywhere from 10,000 to 600,000 files, it's not surprising that a lot of files are unfamiliar but still need comprehension and/or editing.

I want to see:
1.  Where lines have been inserted/changed (I don't mentally differentiate between inserts or changes, and many SE commands blur the distinction anyway by converting "changed" to "inserted" due to the macro writer conveniently deleting a line and then inserting a new properly formatted line; and vice versa).
2.  Where lines have been deleted (SE doesn't do this currently), e.g. with a small red mark in the margin in between the adjacent lines.  It feels disorienting to see insert/modify markers without being able to see deletion markers; I'm only seeing attributions for part of my "editing payload".
3.  Which edits have been saved already, and which edits haven't been saved yet.  VS does this very nicely by showing a green mark in the margin for saved edits, and a yellow mark in the margin for unsaved edits.

Why?  I'm a visual thinker.
- When I'm copy/pasting from one "Foo.c" to another "Foo.c" that look similar, the overview bar makes it more visually apparent whether I'm in the "copy from" file (unedited, blank overview bar) or the "paste to" file (colorful overview bar), even when the current 60 lines on the screen are unedited in either file.
- When editing an unfamiliar file, I sometimes add lines and scroll around gaining a better understanding of the file.  Sometimes while scrolling I lose track of where my edits were in the file, or which of the 8 overloaded functions with the same name the lines were in (overloaded functions diminish the value of using open_local_symbol).  An overview bar makes it visually apparent where there are edits, and less annoying/cumbersome to find my bearings again.
- There are a lot of little reasons why it's desirable.  There probably isn't any one "this is huge and appeals to everyone" reason.  I could give more examples, but instead I'm going to go back to vacationing... 

FWIW, a lot of my co-workers have installed an addon for VS that gives it an overview bar (with a miniaturized rendering of the file that even includes syntax coloring; not sure what I think of that part, haven't used it myself yet, but I've used overview bars in various other editors and file viewers).

Anyway, I was hoping this could be done purely in Slick-C, so it would be portable and so it could be docked as a toolbar.  But I guess it will require a DLL to do the rendering.  Hopefully there's a way to host a bitmap (or a window i.e. HWND) on a form, and dynamically update/replace the bitmap.  If so then a DLL could create a bitmap and give it to the Slick-C code to put on the form.  Hopefully it can be done purely in memory (versus writing the bitmap to disk and having Slick-C load it from disk).  It would be more efficient with less "refresh lag" if it were a native feature.

Ideally it should be a per-window adornment (not a single toolbar), but that requires a native feature.  (In the meantime I might try to hack it to be superimposed the overview on top of the scrollbar, but that seems ugly).

[Clark]

I'm already convinced this is a good feature. It's been on our list for a while but just hasn't made it to the top yet.

Version 17 will use Qt on all platforms. I think you will be able to access all of Qt's API if you use a DLL. It's still very hard to implement.

[Graeme]

I'm already convinced this is a good feature. It's been on our list for a while but just hasn't made it to the top yet.

Version 17 will use Qt on all platforms. I think you will be able to access all of Qt's API if you use a DLL. It's still very hard to implement.

Which part is hard to implement? 

Can Qt QImage class be used?
http://developer.qt.nokia.com/doc/qt-4.8/qimage.html

Does the switch to Qt have any benefits for other platforms?  Was that part of the motivation to do the improved Mac version?

Will there be many changes to the existing widget API.  For my own files toolbar I use slick's bitmap stretching ability to draw a light blue thin line "box" surround for my file list.  e.g. for a vertical line of varying length I have a bitmap 2 pixels wide and 4 high loaded into an image with the left column blue and the right column white and the p_stretch property true.  I then set the height to whatever I need and slick stretches the blue and white columns so I get a blue line one pixel in width.  Will this still work in version 17?

Graeme

[Graeme]

Sorry for the long response, but you asked why: 

Don't mind long answers.  Anyway, I'm on holiday too so I have plenty of time

Diff tools typically show an overview bar indicating where the files are different, and I think we all see the value of an overview bar in the context of diffs.  Editing a file is the process of introducing diffs -- is it really that different?

The original post mentioned search and bookmarks, rather than diffs.  Actually I wasn't aware that some diff tools have an overview bar but I see there's one here
http://www.grigsoft.com/wc3pics.htm

I've used google chrome for a long time but never noticed the "overview bar" when you do a search!!  I'm not sure I would ever use it though.

I want to see:
1.  Where lines have been inserted/changed (I don't mentally differentiate between inserts or changes, and many SE commands blur the distinction anyway by converting "changed" to "inserted" due to the macro writer conveniently deleting a line and then inserting a new properly formatted line; and vice versa).
2.  Where lines have been deleted (SE doesn't do this currently), e.g. with a small red mark in the margin in between the adjacent lines.  It feels disorienting to see insert/modify markers without being able to see deletion markers; I'm only seeing attributions for part of my "editing payload".
3.  Which edits have been saved already, and which edits haven't been saved yet.  VS does this very nicely by showing a green mark in the margin for saved edits, and a yellow mark in the margin for unsaved edits.

I assume VS is Visual Studio not Visual SlickEdit ( I guess that would be VSE).

My own xretrace macro interferes with Slick's color modified lines facility, by necessity.  It would be great to have some built in support for xretrace instead of doing this.  xretrace allows me to step through regions that I've modified but currently doesn't support the ability to start from the current buffer.  I often use the backup history diff mechanism to find what I've changed in the current file.  I sometimes want to be able to jump from the diff window to the corresponding place in the source file but I've never got round to trying to implement that myself.

- When editing an unfamiliar file, I sometimes add lines and scroll around gaining a better understanding of the file.  Sometimes while scrolling I lose track of where my edits were in the file, or which of the 8 overloaded functions with the same name the lines were in (overloaded functions diminish the value of using open_local_symbol).  An overview bar makes it visually apparent where there are edits, and less annoying/cumbersome to find my bearings again.

Maybe you could almost achieve what you want with a macro that hides certain lines in the current file based on their modified etc status.  You could temporarily select a small font to see more on the screen.  You could maybe have an additional read-only window (with its own buffer) that showed the actual lines (nothing hidden) of the region where the cursor currently is.

Anyway, I was hoping this could be done purely in Slick-C, so it would be portable and so it could be docked as a toolbar.  But I guess it will require a DLL to do the rendering.  Hopefully there's a way to host a bitmap (or a window i.e. HWND) on a form, and dynamically update/replace the bitmap.  If so then a DLL could create a bitmap and give it to the Slick-C code to put on the form.  Hopefully it can be done purely in memory (versus writing the bitmap to disk and having Slick-C load it from disk).  It would be more efficient with less "refresh lag" if it were a native feature.

DLL => platform specific, which I think is nice to avoid if possible, even though I'm currently a Windows only user.  The overview bar update could wait for a pause in keypresses but I don't think there's currently a way to detect that.

Ideally it should be a per-window adornment (not a single toolbar), but that requires a native feature.  (In the meantime I might try to hack it to be superimposed the overview on top of the scrollbar, but that seems ugly).

Google chrome's is on the scrollbar but the tracking bit hides the overview.  I almost never have more than one edit window visible at a time but that might change if V18 comes with the ability to drag edit windows outside the main window.

[chrisant]

The original post mentioned search and bookmarks, rather than diffs.

Yes, I'd like those kinds of things in an overview bar as well.

Actually I wasn't aware that some diff tools have an overview bar but I see there's one here
http://www.grigsoft.com/wc3pics.htm

Oops, I hadn't realized some don't.    Every GUI diff tool I've seen or used has an overview bar (Windiff, Beyond Compare, Araxis, KDiff3, WinMerge, Meld, to name a few off the top of my head).

- When editing an unfamiliar file, I sometimes add lines and scroll around gaining a better understanding of the file.  Sometimes while scrolling I lose track of where my edits were in the file, or which of the 8 overloaded functions with the same name the lines were in (overloaded functions diminish the value of using open_local_symbol).  An overview bar makes it visually apparent where there are edits, and less annoying/cumbersome to find my bearings again.

Maybe you could almost achieve what you want with a macro that hides certain lines in the current file based on their modified etc status.  You could temporarily select a small font to see more on the screen.  You could maybe have an additional read-only window (with its own buffer) that showed the actual lines (nothing hidden) of the region where the cursor currently is.

Thanks for the idea.  I think I wouldn't like to hide lines; I want to see things in context (even if the context is just a proportional sized rectangle) but hiding lines inherently hides context.  A while ago I wrote (and shared here) a macro for using F7/F8 to go to the prev/next section of inserted-or-modified lines.  I have lots of ways to find the edits, I want something related but different:  I want to have wider visibility into the file and context.  It's a little like being a rat in a maze:  the rat can always find its way through the maze to get to the cheese.  But wouldn't it be nice to be able to view the maze from above, and see the whole maze in context (not just the current corridor or junction) and see exactly where the cheese is?

Anyway, I was hoping this could be done purely in Slick-C, so it would be portable and so it could be docked as a toolbar.

DLL => platform specific, which I think is nice to avoid if possible

Yes.  Apparently it might be possible to do it purely in Slick-C (i.e. platform independent) in v16 and earlier, but the facility is being removed or perhaps replaced in v17.  I don't want to invest in writing a platform independent macro that definitely can't work on v17, so personally I would start with a Windows-only macro+DLL, and later see if it can be made portable after v17 comes around.

The overview bar update could wait for a pause in keypresses but I don't think there's currently a way to detect that.

Right, thanks for reminding me.  I'll add to the wish list topic a request for a couple new callbacks that would be tremendously useful:
- before_command, called immediately before a command is invoked.
- after_command, called immediately after a command is invoked.
In this context "command" would correspond to something bound to a key, but in recorded macros it would need to correspond more closely to the original key presses instead of the key press that invokes the recorded macro.

[hs2]

@chrisant: I really like your rat/cheese/maze analogy
And I also think the overview bar could be a really neat feature that would make a difference.
I think the known condensed source view might help a bit but only if one is very familiar with the code. Hence it's of very limited use for daily (team-)work.
For me the edit markers are most important. What about updating the Preview TB when browsing the edits (e.g. by dragging the view area).

Hmm .. and what about adding edit markers (ins,del,chg) to SE along with 'prev/next-edit' commands and maybe even a toolbar containing a list and updating the Preview TB when stepping/clicking thru it ?

Just my 2ct, HS2

All the best for 2012 to the SlickTeam and the SE community !