Author Topic: Beta testers wanted : New buffer list toolbar (GFileman)  (Read 11743 times)

Graeme

  • Senior Community Member
  • Posts: 2793
  • Hero Points: 347
Beta testers wanted : New buffer list toolbar (GFileman)
« on: October 24, 2006, 12:37:47 PM »
Hi

After noticing the comments about file tabs and the problems with them, I decided it was time to post the code I use as a replacement for file tabs.  A single row of filetabs isn't enough for me.  I wrote this code for myself and it does what I want, but it may not be what anyone else wants.  Anyway here it is.  I'm looking for people to beta test it and to get it working on platforms other than Windows.  I also want to know if this code is useful to you and any comments or suggestions you have. 

This code is very likely to have a performance issue if you have lots of files open at the same time - (not sure how many) due to the one second timer that decides whether to refresh the toolbar by iterating through all open buffers.  The refresh itself involves lots of copying and sorting and this is probably noticable with hundreds of files open.  I will fix this problem fairly soon if there's enough interest.   I usually have approx 40 files or less open at the same time and 2 GHz/3 GHz machines so it hasn't been a problem for me.

This code provides a toolbar that displays a vertical list of open buffers.  I have it docked at the right hand side and since I generally have no more than about 40 files open at the same time, I can switch buffers quickly.  I currently refer to this toolbar as GFileman, which stands rather loosely for GUI file manager, but it's not currently a file manager, so this name might change one day.  Also included is a "goback" mechanism that allows you to retrace where you've been.

Currently the code works on Windows only and in Slick V11, but is likely ok in Slick V10.  Slick V9 or earlier will need some changes, notably to the GFM_filename_entry_mode command (due to new toolbars in Slick V10) and to set the vse_v9_mode variable to true.

At this stage, I've included a copyright notice in the code, but this is mainly because I'm not sure how to handle this issue (open to suggestions).  I want to encourage contributions but I want them to be organized and I don't necessarily have lots of time to diff/ merge and resolve conflicts, yet I want to keep control of the code.  For now, the code is copyright and you can't redistribute this code except as follows.

  • You can post snippets of code that fix problems.
  • You get the code working on a new platform, in which case you may post a complete set of files, in a zip file with your name, initials or pseudonym in the zip filename.  If possible, make changes to the code using #ifdef etc according to the platform
  • You get the code working in Version 9 or earlier of slickedit, in which case post a complete set of files.
  • You change colours or sizes of any bitmap files, in which case, post a complete set of bitmap files.
  • For now, you may not post code that adds or changes functionality, but you can send it to me via a private message (don't send email).

The attached zip file includes documentation on how to install and use.  I recommend using a new config folder to try out this code, but I have been using it for quite a while so there shouldn't be much problem, though I have made quite a few changes over the last few days.  If you're unfamiliar with Slick C or writing macros, please read the sections in the documentation carefully regarding installing, uninstalling and handling SlickEdit upgrades.

I would like to keep this thread for discussion on how contributions to this code could be handled and other similar issues.  I would like to get comments on whether this toolbar is useful and suggestions for new features (I have a list already) or improvements so I will start a new thread for that ("GFileman comments").  If you find a bug, please start a "GFileman bugs" thread!  If you port the code to a new platform, maybe start a "GFileman new platforms" thread.

Graeme

[Updated the zip file to Rev2]

« Last Edit: October 27, 2006, 10:57:45 AM by Graeme »

hs2

  • Senior Community Member
  • Posts: 2761
  • Hero Points: 292
Re: Beta testers wanted : New buffer list toolbar (GFileman)
« Reply #1 on: October 24, 2006, 01:09:12 PM »
It's an honor to be your beta tester Graeme.
Didn't try it yet - but it looks like you did a great job and it's worth a hero point in advance !
I'll give some feedback asap.

Regards,

HS2

Graeme

  • Senior Community Member
  • Posts: 2793
  • Hero Points: 347
Re: Beta testers wanted : New buffer list toolbar (GFileman)
« Reply #2 on: October 25, 2006, 05:25:14 AM »

Forgot to mention, there's a couple of known issues, as listed at the end of the doc file

1. The editbox on the GFileman toolbar sometimes gets the focus when it shouldn’t (e.g. when the form is first opened).

2. The “tooltip” window that shows a filename and its time date, sometimes has the background on top of the foreground (there are two forms) – this is a Z-order problem.

Also, if you're using the "recent access" sort order for files - this doesn't work 100% of the time due to the fact that it uses the _switchbuf mechanism to keep track of the order buffers are visited and SlickEdit doesn't always call _switchbuf e.g when you use "goto bookmark".  This is also mentioned in the doc file with the GFH_last_buffer command.

Graeme

Graeme

  • Senior Community Member
  • Posts: 2793
  • Hero Points: 347
Re: Beta testers wanted : New buffer list toolbar (GFileman)
« Reply #3 on: October 27, 2006, 11:06:22 AM »
I've updated the zip file attachment to Rev2.  Source files don't have versioning in them yet but probably will next time.

I was doing some belated testing and found that "recent access" order produced an error.  This was because I made a bunch of functions static at the last minute and didn't retest everything.  I don't mind polluting the global namespace in my own code with lots of non static functions, but distributing to other people is different.  The error doesn't appear until runtime - this doesn't happen with C++ ...  Normally I would test more thoroughly before posting code but I was in a rush (like I am now).

Also fixed the width of the scrollbar image thing that caused it to be too narrow.

Also updated the doc file to say that GFilemanForms.e must be loaded first  - this doesn't seem to be necessary the very first time.

The options you see for setting "y offsets" and visibility of the editbox and buttons aren't fully functional yet.  If you do turn the visibility of the buttons off, you won't be able to turn it back on  :) - but you can edit GFilemanConfig.ini and close/ re-open the toolbar to get them back.

Graeme
« Last Edit: October 27, 2006, 11:10:24 AM by Graeme »

snoby

  • Junior Community Member
  • Posts: 3
  • Hero Points: 0
Re: Beta testers wanted : New buffer list toolbar (GFileman)
« Reply #4 on: November 01, 2006, 08:24:09 PM »
This is a great plug in, exactly what I was looking for.  I just recently switched from Codewright to slickedit and I was dying because I couldn't just switch between my last two buffers, like I could on Codewright.  THANKS!

Dennis

  • Senior Community Member
  • Posts: 3955
  • Hero Points: 515
Re: Beta testers wanted : New buffer list toolbar (GFileman)
« Reply #5 on: November 03, 2006, 05:48:34 AM »
Nice work.  I can tell you have put a lot of work into this.  A few suggestions:

1) Use the FILESEP macro instead of hard coding the / character into the bitmap path.

2) I got a stack when I single clicked on a directory name

3) Take a look at the on_resize() code for another dockable tool window, such as _tbbookmarks_form.  I think your form could do a better job of fitting itself in when it is docked.

4) It wasn't intended to be a plugin mechanism, but if you are clever about it, you could use 11.0.2's hot fix mechanism to simplify installation.  An 11.0.2 hot fix is just a flat zip file with a manifest.xml that specifies what to do: copying files to the config directory, running commands, loading macros, running batch macros, etc.  The DTD is pretty self-explanatory.

Graeme

  • Senior Community Member
  • Posts: 2793
  • Hero Points: 347
Re: Beta testers wanted : New buffer list toolbar (GFileman)
« Reply #6 on: November 03, 2006, 10:34:21 AM »
Nice work.  I can tell you have put a lot of work into this.  A few suggestions:

1) Use the FILESEP macro instead of hard coding the / character into the bitmap path.

2) I got a stack when I single clicked on a directory name

3) Take a look at the on_resize() code for another dockable tool window, such as _tbbookmarks_form.  I think your form could do a better job of fitting itself in when it is docked.

4) It wasn't intended to be a plugin mechanism, but if you are clever about it, you could use 11.0.2's hot fix mechanism to simplify installation.  An 11.0.2 hot fix is just a flat zip file with a manifest.xml that specifies what to do: copying files to the config directory, running commands, loading macros, running batch macros, etc.  The DTD is pretty self-explanatory.


Thanks.  I'm glad I posted it as beta software.  I posted the code in a bit of hurry when buffer tabs were a hot topic and never really did any systematic testing.  Obviously I've never clicked on a directory name coz I knew it didn't do anything, so thanks for finding that.  On Windows, I'll try to make this open the directory in Windows explorer and do nothing on other platforms.

I'll definitely look into the hotfix mechanism as the current installation requirements are a bit tedious - especially having to kill the one second timer and close toolbars (hope hotfixes can deal with that).

I wrote the code a little bit at a time over the last year or two and did it a little casually, thinking it was just for me.  I could do a better job if I worked on it fulltime.  If I was starting again I would try harder to decouple the data being displayed from the widget that displays it - this might be easier to do in C++.  I would have preferred to do it in C++ but the ability of the slick interpreter to handle errors gracefully rather than crash is really valuable, in my opinion, as well as being portable.

I'm putting off looking into the performance issue until someone complains about it!

Thanks a lot for looking at it.

Graeme