Really nice one. In fact I started the same some time back but never finished it. GREAT! That was a feature I missed hardly from notepad++. This should be merged with svn in the future... Do you have plans to do so? What is missing/what feedback do you need?Feedback I need/wish:
Well I am using it from no on - so far no problem on Windows. I'll tell if I see something different.
- is it stable? (I am not sure about that, possibly it makes infinite loops. But I can not reproduce it.)
I didn't miss this feature so far but if you say so - it might be nice. However, This sounds to me likt it should be an option.
- Should the MiniDoc sync to the main Doc so it automatically scrolls so that the grey rectangle is visible?
Again: I am happy with as it is so I don't see an urgent need for this, but if - an option. :-)
- On a click in the minidoc it makes the clicked line the first line in the main doc. Should it be become the line in the center?
Right clieck sounds obvious. Alternatively with mouse wheel if MiniDoc is under the mouse cursor (similar like we do it with editor tabs).
- When to set the focus to the MiniDoc, to be able to scroll in the MiniDoc (without changing position of the main Doc). Right click?
* Size of the font in the minidoc
- What should be configured? (Any volunteers?)
I've seen this, its not nice. You proposal would be a solution but required implementation and rewrite of the other plugins as well.
- The constants for the Indicators (highlight occurences and incremental search) in MiniStyledTextCtrl::MiniStyledTextCtrl() are bad to maintain.
(copy from Occurences highlighter and incremental search plugins). By the way is there a need for a central instance where a plugin can register for an Indicator?
I don't think so. If the font size is an option you can minimize it. But at some point for VERY long documents it does not make sense to minimise it even further. So an option to select the minimal font size and therefore zoom level is good, but no more. (These are my feelings.)
- Given by the decision to use a cbStyledTextCtrl to show the miniature, it is not possible to disply long documents without a scrollbar. Bad?
Bug: Showing the panel resets the background of my greyish syntax highlight theme in the editor.Can you explain how to reproduce?
... If I resize the mainview, the grey rectangle is not resized (until I click into the mainview).How do I get the plugin informed about the resize?
...For both suggestions; I don't know how to achieve them.
3. use even smaller font for larger files
4. it would be good if the space between the lines could be made smaller, so more text could be made visible.
... If I resize the mainview, the grey rectangle is not resized (until I click into the mainview).How do I get the plugin informed about the resize?
event.GetEditor()->Connect(wxEVT_SIZE,wxSizeEventHandler(MiniDoc::OnResize));
event.GetEditor()->Disconnect(wxEVT_SIZE,wxSizeEventHandler(MiniDoc::OnResize));
Another nice example that git is not always helpful... :-)That has nothing to do with git, but with two developers working on the same problem ath the same time.
Can you explain how to reproduce?See default colors of the c++ theme to dark gray and light gray. Then try to open the MiniDoc panel. If it still works correctly then I can share my theme...
...Applied your patch, thanks a lot. It is not working when the second splited view changes size (hide/show logs resizes only second view).
It goes a slightly different way, because I connect to the first cbStyledTextCtrl instead of the editor.
So resize-events in split-view are recognized also.
... for splitted editors ... is more broken (at least here): the actual highlighted lines (grey rectangle) get a white circle in the editors margin of the second control.Its because the marker MiniStyledTextCtrl::GetOurMarkerNumber() is not defined as wxSCI_MARK_EMPTY. And other unused marker numbers have other visible marker settings.
Index: cbeditor.cpp
===================================================================
--- cbeditor.cpp (revision 9855)
+++ cbeditor.cpp (working copy)
@@ -782,6 +782,7 @@
m_pControl->SetMarginMask(C_MARKER_MARGIN, 0);
m_pControl->SetMarginMask(C_CHANGEBAR_MARGIN, 0);
m_pControl->SetMarginMask(C_FOLDING_MARGIN, 0);
+ InitMarker(m_pControl);
SetEditorStyleBeforeFileOpen();
m_IsOK = Open();
@@ -797,6 +798,13 @@
}
ConnectEvents(m_pControl);
}
+void cbEditor::InitMarker(cbStyledTextCtrl* control)
+{
+ if(!control)
+ return;
+ for (int marker = 0 ; marker <= wxSCI_MARKER_MAX ; ++marker)
+ control->MarkerDefine(marker, wxSCI_MARK_EMPTY);
+}
void cbEditor::NotifyPlugins(wxEventType type, int intArg, const wxString& strArg, int xArg, int yArg)
{
@@ -1095,6 +1103,7 @@
// create the right control
m_pControl2 = CreateEditor();
+ InitMarker(m_pControl2);
// update controls' look'n'feel
// do it here (before) document is attached, speeds up syntaxhighlighting
I still can't see whats wrong.Can you explain how to reproduce?See default colors of the c++ theme to dark gray and light gray. Then try to open the MiniDoc panel. If it still works correctly then I can share my theme...
This http://cmpt.benbmp.org/codeblocks/screens/minidoc.theme.pngAhh... Thanks, now I see!
serious: The last line is white, probably because you're playing with the margins. See the screenshot: http://cmpt.benbmp.org/codeblocks/screens/minidoc.line.problem.png
There is another problem: When scrolling I can see the inactive lines from the minidoc drawn over the line numbers of my main editor. But I can't make a screenshot to demonstrate the artefact.First, I don't play with the margins. Again, apply the mentioned patch! The reason is that a cbStyledTextControl has some of the markers configured to visible symbols and colored lines.
The serious problem is worsened when a line or more is deleted in the document, then multiple lines become white.The white lines are gone with the mentioned patch. But the grey area will still be wrong in this cases. I have to update the MiniStc more regular after typing.
minor: After the plugin is loaded and then the panel is shown it is empty.What do you expect?
annoying: The gray area is really ugly, because of the dark greyish spaces between the lines, see the screenshot.That's true, I have to look into it.
...
Edit: Notepad++ seems to have no problem with the darker spaces between the lines. See this video https://www.youtube.com/watch?v=5Y6hE0SdgsQ
To see the active editor in the minidoc panel.minor: After the plugin is loaded and then the panel is shown it is empty.What do you expect?
... To see the active editor in the minidoc panel. ...You are right. I didn't think about loading a plugin after startup. Thanks.
annoying: The gray area is really ugly, because of the dark greyish spaces between the lines, see the screenshot.It's a bug in wxScintilla, see here:
Edit: Notepad++ seems to have no problem with the darker spaces between the lines. See this video https://www.youtube.com/watch?v=5Y6hE0SdgsQ
This is the bug report: http://trac.wxwidgets.org/ticket/13709 if you want to join the discussion:)...why do we care about wxSTC? We can do it ourselves... don't we (I guess I am missing something...).
And also because I'm left with the impression that the wx project is the current maintainer of the wxscintilla component.
* pumped (wx)Scintilla to 3.2.2The updates to scintilla are more or less independent from this.
* harmonised (wx)Scintilla with wxSTC from wxWidgets SVN (which happened to have updated scintilla, too lately)
This is the bug report: http://trac.wxwidgets.org/ticket/13709 if you want to join the discussion:)
I'll do a branch hopefully tomorrow...Well I did a branch right now (a little later than tomorrow :P). Please use the new project file "CodeBlocks.scintilla.cbp" for testing. I have done this for Windows only, atm. The branch is located at:
I just committed a linux project-file (only C::B core), some (linux) build-fixes and most important a fix for the white-text-on-white-background-issue (not yet tested on windows).OK Jens - so it was the Ascent method... Oh dear - 4 eyes only see more than two. I've merged all my remaining stuff that was pending in the mean time. This includes danselmi's changes wrt to the patch in MiniDoc (was it that one, or cbDiff?!), obfuscate's patch wrt to the black border and some others like a new event that allows (plugins) to modify the text being copied /pasted via clipboard...
Or just commit it, if there are no obvious issues and we fix it in trunk.I'm most likely not available much this week, so I decided to commit. It works fine on Windows. I am not sure if I did all the required stuff for the Linux build system, but at least "I did my very best"... ;-) The last update of Ubuntu in my VM broke it once again, so I cannot test it myself.
I would love to see that working...I hope, I'll find some time to work on a real scrollbar replacement later this year.
I hope, I'll find some time to work on a real scrollbar replacement later this year.BTW: I just discovered Jens' fork.
If you're talking about this: https://github.com/danselmi/MiniDoc/network then Jens' fork is way older and doesn't contain lots of commits. But probably it could be easily rebased.Ah - I didn't check the history. I was under the assumption that a fork must always be newer... :P ::)
...It is/was really bad. But I just commited some improvements. It still needs some resources but.. test it yourself.
OK, but still: any comments on the performance? Am I the only one experiencing such?
I've not used it since the first try, because it had problems when using two editors side by side.What problems?
Also I think it should not land in trunk before next release.Reasons? I am not in hurry. But I can't take anything out of statements like this!
What problems?Unfortunately I don't remember the details. :(
Reasons? I am not in hurry. But I can't take anything out of statements like this!I want to be careful. I'd rather prefer if there are several nightlies featuring it, so it can be tested a bit more.
Downloaded from github to check out the source code. It's quite bad if I'm being honest. The code doesn't have any helpful comments like you would expect from a decent source code and there are commented out parts of code without any explanation (=comment). In any case, the C::B project file doesn't even work, because it requires some kind of special compiler or something it's complaining when you open the project. If you want other people to contribute, you really need to write better comments and clean up the source code before you stuff it to github or release it. You don't have to be a professional programmer to figure this out, just think about it for a while. Just give your brains some time to think.
Your comment is useless; have you built Code::Blocks from source, before?
Your comment is useless; have you built Code::Blocks from source, before?
Yes, sadly I have and it didn't even work (that OSX adventure, remember?). You open source guys are so weird, you always try to turn it to users, everything is their problem, even when you fail to provide any kind of sane instructions how to compile something actually. Why it has to be this hard, there is nothing you gain by doing it this way. Well, maybe keep these projects to yourself so you get all the donations, maybe that's the reason, who knows.
Till you learn how to build a working Code::Blocks I strongly suggest you avoid
But, you have violated rules that other websites I am on use.
What does this even mean? I'm out this "forum" anyway, you can't even say anything without getting accused of something.Oh dear, the problem is not what you say but how. You just blame, right? I don't know why people stopped being polite these days. Maybe it would be different with some kind of good-behaviour.