Plugins: New source code editor based on Scintilla for W7 and x64?

@Leo: OK, thanks! I think I'll implement it first with a common EditCtrl and perhaps we can later exchange it.

Unfortunately I have the next question for you :blush: :
Scintilla needs a lot of external configuration stuff - at least, if it should deal with a lot of different languages. So, you have to define ALL the i.e. keywords ("if, else, this" for C++) for ALL languages and a lot of defines. My first approach was to compile some default languages in (so the plugin is generating a XML config, which the user can modify) but to provide the user with all possible languages from scratch I don't think this approach is a good idea. I would prefer to read in a XML file, which is generated by me, delivered with the plugin and provides all the necessary Scintilla input config and is not modifiable by the user. Additionally a common Opus config will exist, which is user modifiable of course.

I didn't find a plugin, which uses external (XML) input files. Where is an appropriate folder for this file (Viewers folder as well ?) ? Is this method recommended or do you prefer to generate this config by the Opus plugin (paying attention to be USB safe)?

@xbprm: Hehe, don't thank me before the baby is ready :neutral_face:. Nevertheless I hope there are some more people who are interested in such a plugin!

There's a GetConfigPath function in the Plugin Helper API which plugins should use to get the location for storing their config files. It's usually /dopusdata/ConfigFiles/Plugins, but using the API is best in case it varies.

The full details are in Plugin Support API SDK.pdf under, Configuration Functions section. There is also an API for reading and writing XML config files, but you probably won't want/need that if Scintilla has its own code for doing so.

Thanks, I was aware of GetConfigPath(), but I wasn't sure, if I'm allowed to place some config files there, which are not modified by Opus (as mentioned, they are just READ by my plugin and has to be copied by the user or later by some kind of installer, if any will exist in the near future ).

I will definitely have to use the API for reading XML files, as Scintilla is not able to read in some kind of configuration. It's up to the application, which uses Scintilla.

Very interesting plugin - has there been any progress lately ?!

Please keep going, we need something like this.. o)

Hi tbone!

Yes, I need this plugin as well and sorry for no progress yet. It is still on my TODO list and must be completed, but I'm still under heavy load. Reading more information about the Scintilla component showed, that the user interface and saved config structure must be more complex, than I thought: The user must be able to change colors, fonts and other settings for different languages and even for different textblocks of that language. Additionally the commands to change these settings are generated and not static. So I have to setup an infrastructure which can handle all these things.

If there is any progress, I'll write news in this thread!

Sorry again for no better news!

Best regards,
Sven

Go Svenni, Go!

Just a little bit of cheering for you.. o)

Anyone still interested in source viewer plugin?

Files go to
SciLexer.dll

/system

dosv.dll

C:\Program Files\GPSoftware\Directory Opus\Viewers

dosv.config.xml

/dopusdata/ConfigFiles/Plugins

You may also need:
Visual C++ Redistributable for Visual Studio 2012
http://www.microsoft.com/en-us/download/details.aspx?id=30679#
dosv.zip (1.24 MB)

Do you know, does it feature a find?

Did you recompile/enhance it or something? Never seen a config-dialog for this iirc.

Nice work! That looks great.

If it's ready for general use, please post it to the Viewer & VFS Plugins area.

Would it be possible to make it not require copying SciLexer.dll to system32? Is there a reason it can't be loaded from the same directory as the plugin DLL? (If it's loaded via LoadLibrary, you can give the full path to the DLL; it doesn't have to be in the system path.) That will make it possible for it to work with portable installs, and also avoid clashes with other things that want a different version of SciLexer.dll in System32. (And System32 should only contain parts of Windows itself really.)

Compiling for a static C++ runtime is also nicer for people using portable copies of Opus, since they cannot depend on the CRT being installed.

Supporting portable/USB copies also needs one more thing, which is a USB-safe manifest in the resources, which tells Opus the plugin is safe. (This should only be set if the plugin doesn't modify the registry or anything else outside of the Opus config folder to store its configuration etc.)

Please shout if you need any information or help!

Got it working.. somewhat. I agree with Leo, that looks really promising! o)

I have some issues:

  • the config dialog does not seem to work for me (anything I setup is lost).
  • it does not detect *.js files for some reason (no syntax-highlighting kicks in)
  • the config dialog does not seem to reflect the current filetype (it always shows "default" for language and style, though it did hightlight a powershell script e.g.).
  • the find (great that it's there!), is still a bit inconvenient - but hey for a v0.0.0.1 not bad at all! o)

Big thanks for doing this! o)

我简单试用了一下,中文乱码。

I had a try, Chinese garbled.

Nice work! I had a similar version as you can see in the first picture of this thread. To display a programming language with different styles was not very hard. The real effort of this plugin is to make a lot of things configurable for every language (as far as I remember). And of course you have to store and load that information. Even the indices (for the styles or languages) in SciLexer.dll are generated and will change from version to version (if new languages or styles are added). That was the point where I failed! Shame on me, I know! :imp: :imp:

I wish you all the best and that you'll finish your goal (so that I can delete it in my mind)! Good luck!!!

As Leo sugested SciLexer.dll should be now in

C:\Program Files\GPSoftware\Directory Opus\Viewers

CRT should not be necessary anymore.

USB export seems difficult.
Where should be x64 files located in x86 installation?
And how to copy config file?

<export>/dopusdata/dosv.config.xml</export>

Will this work?
There is also log file created in Logs directory. Should it be disabled?

Should work now.

Config file was auto generated from notepad++ version, so some things does not work yet.
You can try javascript now. No html scripts, though. And I will think how to fix background color later.

IMO implementing this will demand some hacking, unless Leo could help?

What exactly is inconvenient?

Posting example file and screenshot may help. But if it does not work in notepad, chances are low.

@Svenni77
I couldn't agree more.
dosv_0_0_0_2.zip (1.79 MB)

Man it's aweseom! o) CTRL+Mousewheel also works to zoom in/out, great! o)

The config dialog is also much better now. I noticed, the bold/italics/underline checkboxes are not yet set correctly after choosing a style.
Another minor issue is the column of linenumbers, it does not resize, when zooming in, but not a big deal for me.

Regarding the find, I guess people are used to press F3 to repeat the search with what has been searched before. Currently F3 to search forward and SHIFT+F3 to search backward does not have any function. You need to enter the find-textfield and retype what you have already been searching for to make the find go on/work again. You also cannot use RETURN within the textfield to make the find move forward, you need to grab the mouse and hit "next" or TAB switch to the buttons on the right hand side.
After selecting a keyword, I also expect CTRL+F3 to work like "find next" for the current selection and CTRL+SHIFT+F3" to work like "find prev". These F3 key combinations are very common and a must have for serious handling, I guess you also know them from VisualStudio e.g. It would be awesome if you could make them work like there/described.

This viewer plugin really adds alot to the overall DO experience! Please keep going! o)

Sorry for the delay in replying.

There's not much that needs to be done, as long as the code isn't writing to the registry or anything like that.

In the same places as they are now:

(Note: /home is an alias which resolves to the Opus program folder, usually C:\Program Files\GPSoftware\Directory Opus.)

  • On 64-bit HDD installs:
    x64 DLLs go in /home/Viewers
    x86 DLLs go in /home/x86/Viewers
  • On 32-bit HDD installs:
    x86 DLLs go in /home/Viewers
    x64 DLLs go in /home/x64/Viewers (This is new in Opus 11.12.5 and above.)[/li][/ul]

The HDD installs have copies of the other "bitness" so that they can export either or both to USB. (Priori to 11.12.5, only 64-bit installs had this capability. Now 32-bit ones do as well.)

Copying the plugin DLLs to USB sticks is done for you by Opus. Plugins do not need to worry about that. Opus will copy the appropriate DLLs to the appropriate place on the USB stick automatically.

The only extra thing you need to do is tell Opus that SciLexer.dll also needs to be copied, since Opus wouldn't know that extra DLL is part of your plugin otherwise. To do that, you just need to add it to the usbsafe.xml manifest details. The j2k plugin is an example that does this for two extra files. Here is its usbsafe.xml manifest:

As you can see, it just specifies a filename, so the additional files should be in the same folder as the plugin itself.

If you have extra DLLs or other files whose names are different on x86 and x64, the manifest can handle that as well. Here's how the Archives plugin deals with unrar.dll and unrar64.dll:

[quote]And how to copy config file?
/dopusdata/dosv.config.xml
[/quote]

Config files should be in the folder you get back from the GetConfigPath helper function. (Usually /dopusdata/ConfigFiles/Plugins.) As long as they are in there, they will be exported automatically.


Officially, the /dopusdata/Logs dir is private and it wasn't envisaged that plugins would write to there, so putting your own files in there may confuse some part of Opus (although it may be fine as well, I am not sure).

As far as USB installs go, it's the same on them as for an HDD install, as long as you are obtaining the config path via the helper API, or by asking Opus to resolve the /dopusdata alias. i.e. As long as you are not assuming the config folder is in the user's profile folder. (USB installs should not modify the user profile folder, since all the Opus config folders will be in another location in that scenario.)

I can try. I'm not sure what the question is, sorry. Do you need a way to map from a filename/extension to a file type?

By the way, if you don't have a licence with USB export enabled, I'm sure we can fix that for you to let you test things. Get in touch if you need it!

If you're in eval mode and don't have an Opus licence at all, we can sort that for you as well, if needed. We're happy to provide free licences to help with plugin development.

Thanks for help and suggestions @leo and @tbone.
USB export and shortcuts should work now. My main problem with manifest was that it was not clear for me that every config file from folder is exported (even if plugin does not support USB export).

To do what @tbone asked will require that information about extension of file currently displayed in preview panel should be accessible in configuration dialog. I understand why this will be problematic and suggest leaving this feature for now.
dosv_0_0_0_3.zip (1.79 MB)

Hi gdobin! o)

I hope you don't mind this little issue-section?

  • The font height seems to make problems and won't stay once set via the config dialog.
    I edited xml directly to fix this, but the default setting still seems to fight with the font height of a specific filetype, or it's me doing something wrong.

Feedback to your recent enhancements:

  • Background and coloring for js files is fine now.
  • Find next/prev and related F3 key-combination work very good, great! o)
  • Resizing of line number column works.
  • Enter in the find textbox works good.

A few more ideas in descending importance from my wishlist o):

  • Possibility to set a tab-width somewhere (I find a default tab-width of 8 blanks much to wide for browsing code).
  • Possibility to scroll the text by mousewheel, though focus is still within the find textbox at the bottom.
  • Possibility to reset the font-size to 100% (means standard font height). Maybe that also makes it easier to track down the font height issue, as I never know exactly wether it's the current zoom-factor being the problem or the font-size being set/read wrong.

Maybe a DO related topic:

  • I did not succeed to use your plugin as a catch-all for any other ascii filetype, is this possible at all with DO?
    I disabled the regular text-catch all plugin at the botton of the DO viewer prefs, but then I cannot look into text files anymore. I'd like to use the plugin for these files as well, numbered lines and highlighting of words is just to good to be missed! o)

This is another leap forward to perfection, thanks once more for what you did and share with us!

gdobin, thanks. Great work.
Not had much time with it but looks great so far. Will try to get more time over the next few days.

Hope you don't mind me asking. Are you able to share the source/repo?
Thanks again

Similar to Tbone, How would I make this this the default for all files? I have disabled the default text viewer. However some file do not display using this plugin.
for example:

  • .aspx: preview as a icon.
  • .xml: preview in IE.
  • .stylecop: preview as a icon.
  • .config: preview as a icon.