Hi
Find attached the surces for the MiniDoc plugin. It provides a small view of the document.
See here how it looks like:
(http://s7.postimg.org/5epq0v7tj/Mini_Doc.jpg) (http://postimg.org/image/5epq0v7tj/)
As always, any feedback is welcome.
Todo's:
- position of grey rectangle is wrong with folded code in the editor.
- ?
regards danselmi
Hm, interesting...
I have a similar task in the todo, but I'm not sure when I'll have time to try it...
Have you considered attaching this miniview to every editor's tab?
Sources are here:
https://github.com/danselmi/MiniDoc (https://github.com/danselmi/MiniDoc)
post removed (shame)
SublimeText, Notepad++, VisualStudio all provide this feature...
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?
...I've "ported" this to wx30 and wx30 64 bit on Windows.. If you transfer the sources to contrib plugins in the SVN tree I can merge them...
Morten you can always fork his repo and then make pull request. :)
Quote from: MortenMacFly on August 08, 2014, 05:25:21 AM
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:
- is it stable? (I am not sure about that, possibly it makes infinite loops. But I can not reproduce it.)
- Should the MiniDoc sync to the main Doc so it automatically scrolls so that the grey rectangle is visible?
- 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?
- 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?
- What should be configured? (Any volunteers?)
- 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? - Given by the decision to use a cbStyledTextCtrl to show the miniature, it is not possible to disply long documents without a scrollbar. Bad?
If we have some feedback about stability we can integrate it into the repo.
regards danselmi
Quote from: danselmi on August 08, 2014, 11:16:17 AM
- is it stable? (I am not sure about that, possibly it makes infinite loops. But I can not reproduce it.)
Well I am using it from no on - so far no problem on Windows. I'll tell if I see something different.
Quote from: danselmi on August 08, 2014, 11:16:17 AM
- Should the MiniDoc sync to the main Doc so it automatically scrolls so that the grey rectangle is visible?
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.
Quote from: danselmi on August 08, 2014, 11:16:17 AM
- 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?
Again: I am happy with as it is so I don't see an urgent need for this, but if - an option. :-)
Quote from: danselmi on August 08, 2014, 11:16:17 AM
- 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?
Right clieck sounds obvious. Alternatively with mouse wheel if MiniDoc is under the mouse cursor (similar like we do it with editor tabs).
Quote from: danselmi on August 08, 2014, 11:16:17 AM
- What should be configured? (Any volunteers?)
* Size of the font in the minidoc
* any specific behaviour option
* Colours (I think you are already using colormanager, right?)
I can try if you like, but currently my time is really limited due to work an family (we have moved...). However, please move it to SVN before. I don't really want to use an external GIT and we keep the history in SVN. We have enough unsynchronised bits and pieces all around different GIT places already and I am afraid having so many forks will lead to trouble sooner or later. We could NOT add it to the full build system (workspace, automake...) for now and do it if its ready, if you like or use a branch (which would be a little overdone for an independent plugin though...).
Quote from: danselmi on August 08, 2014, 11:16:17 AM
- 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've seen this, its not nice. You proposal would be a solution but required implementation and rewrite of the other plugins as well.
Quote from: danselmi on August 08, 2014, 11:16:17 AM
- Given by the decision to use a cbStyledTextCtrl to show the miniature, it is not possible to disply long documents without a scrollbar. Bad?
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.)
Bug: Showing the panel resets the background of my greyish syntax highlight theme in the editor.
Suggestions:
1. remove the scroll, because it just wastes space
2. mark the currently visible part of the document/file by greying out the non-visible part -> currently you're doing the inverse and so highlighting staff in the editor is hard to see.
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.
Btw: Your code also reveals another weakness in the sdk: The menus shouldn't been accessed by name... This will break as soon as we change a menus name. I've seen similar in several other plugins. There should better be an sdk method providing plugins with access to the top level menus at least...
Two issues (on linux):
if I scroll in the main-window the grey rectangle in the MiniDoc-view is moved also, but if it leaves the visible area the miniDoc should auto-scroll, so the grey rectangle is always visible.
If I resize the mainview, the grey rectangle is not resized (until I click into the mainview).
I already addressed some issues.
What remains is:
Quote from: oBFusCATed on August 10, 2014, 01:12:40 PM
Bug: Showing the panel resets the background of my greyish syntax highlight theme in the editor.
Can you explain how to reproduce?
Quote from: jens on August 10, 2014, 06:33:15 PM
... 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?
Quote from: oBFusCATed on August 10, 2014, 01:12:40 PM
...
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.
For both suggestions; I don't know how to achieve them.
regards danselmi
Quote from: danselmi on August 12, 2014, 07:25:47 PM
Quote from: jens on August 10, 2014, 06:33:15 PM
... 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?
You can use:
event.GetEditor()->Connect(wxEVT_SIZE,wxSizeEventHandler(MiniDoc::OnResize));in the EditorActivated eventhandler and
event.GetEditor()->Disconnect(wxEVT_SIZE,wxSizeEventHandler(MiniDoc::OnResize));in the deactivate handler.
The problem is, that it does not works for splitted editors, but in this case there is more broken (at least here): the actual highlighted lines (grey rectangle) get a white circle in the editors margin of the second control.
I just send you a pull request (https://github.com/danselmi/MiniDoc/pull/1) with my solution for the resize-stuff.
My fork was created short before your resize-commit.
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.
Because of your last commit, the pull-request can not be merged directly (merge-conflicts).
Another nice example that git is not always helpful... :-)
Quote from: MortenMacFly on August 12, 2014, 11:09:19 PM
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.
With svn you can not even create a pull-request.
Quote from: danselmi on August 12, 2014, 07:25:47 PM
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...
Quote from: jens on August 12, 2014, 11:07:09 PM
...
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.
Applied your patch, thanks a lot. It is not working when the second splited view changes size (hide/show logs resizes only second view).
Quote from: jens on August 12, 2014, 08:09:02 PM
... 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.
A simple solution is to define all markers (0..wxSCI_MARKER_MAX] as wxSCI_MARKER_EMPTY after creation of cbStyledTextCtrl (in cbEditor). like this:
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 tried to define the marker from the MiniDoc plugin, but there I don't know when a splitted view gets created. Right?
regards
Quote from: oBFusCATed on August 13, 2014, 12:44:47 AM
Quote from: danselmi on August 12, 2014, 07:25:47 PM
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...
I still can't see whats wrong.
This http://cmpt.benbmp.org/codeblocks/screens/minidoc.theme.png
Quote from: oBFusCATed on August 13, 2014, 11:07:27 PM
This http://cmpt.benbmp.org/codeblocks/screens/minidoc.theme.png
Ahh... Thanks, now I see!
Is your theme ok when the invisible part is marked by greying out the non-visible parts? (latest sources, in config panel remove tick "inverse designator").
Can you try to patch cbEditor to init the markers ( patch from this
Quote from: danselmi on August 13, 2014, 10:31:02 AM
post)? Is it also a solution?
Can you try to reproduce the problem with this theme: http://cmpt.benbmp.org/codeblocks/screens/cb.editor.theme.conf ?
I've just tried the latest version and it seems that this error is fixed.
But there are two other errors, one minor and one more serious
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
minor: After the plugin is loaded and then the panel is shown it is empty.
annoying: The gray area is really ugly, because of the dark greyish spaces between the lines, see the screenshot.
Edit: Notepad++ seems to have no problem with the darker spaces between the lines. See this video https://www.youtube.com/watch?v=5Y6hE0SdgsQ
Edit2: The serious problem is worsened when a line or more is deleted in the document, then multiple lines become white.
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.
Quote from: oBFusCATed on August 14, 2014, 12:04:36 AM
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
Quote from: oBFusCATed on August 14, 2014, 12:22:36 AM
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.
Quote from: oBFusCATed on August 14, 2014, 12:04:36 AM
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.
Quote from: oBFusCATed on August 14, 2014, 12:04:36 AM
minor: After the plugin is loaded and then the panel is shown it is empty.
What do you expect?
Quote from: oBFusCATed on August 14, 2014, 12:04:36 AM
annoying: The gray area is really ugly, because of the dark greyish spaces between the lines, see the screenshot.
...
Edit: Notepad++ seems to have no problem with the darker spaces between the lines. See this video https://www.youtube.com/watch?v=5Y6hE0SdgsQ
That's true, I have to look into it.
Quote from: danselmi on August 14, 2014, 01:04:30 AM
Quote from: oBFusCATed on August 14, 2014, 12:04:36 AM
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.
The steps to reproduce the problem are:
1. Open some project or files
2. Enabled the minidoc
3. View -> MiniDoc
At step 3 the minidoc is still empty.
About the patch: I'll see if I can find time to try it.
Quote from: oBFusCATed on August 14, 2014, 08:47:30 AM
... To see the active editor in the minidoc panel. ...
You are right. I didn't think about loading a plugin after startup. Thanks.
I just commited the fix.
Quote from: oBFusCATed on August 14, 2014, 12:04:36 AM
annoying: The gray area is really ugly, because of the dark greyish spaces between the lines, see the screenshot.
Edit: Notepad++ seems to have no problem with the darker spaces between the lines. See this video https://www.youtube.com/watch?v=5Y6hE0SdgsQ
It's a bug in wxScintilla, see here:
https://groups.google.com/forum/#!topic/scintilla-interest/FAI2HjSYlLk (https://groups.google.com/forum/#!topic/scintilla-interest/FAI2HjSYlLk)
Ah, you've posted a link to a bug reported by me... ;D
MiniDoc.cpp fails to compile with wx30 (non-PCH) due to a missing include of logmanager.cpp.
This is the bug report: http://trac.wxwidgets.org/ticket/13709 if you want to join the discussion:)
Quote from: oBFusCATed on August 19, 2014, 09:58:58 AM
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...).
Because the wx devs can help with the fix, I'm not too familiar with the code.
Also the original bug report has nothing to do with codeblocks (I've tried to do a svn blame gui tool back then).
And also because I'm left with the impression that the wx project is the current maintainer of the wxscintilla component.
Quote from: oBFusCATed on August 19, 2014, 09:07:26 PM
And also because I'm left with the impression that the wx project is the current maintainer of the wxscintilla component.
In general yes, and we (better Morten) regularily synchronize our sources with the wxSTC-sources, but nevertheless we acn not use it directly, because we use many own patches in (wx)scintilla.
Well in fact we are synchronizing with scintilla directly and not with wxstc. Wxstc is far older than our wxscintilla component, additionally our component can do more than scintilla. We are the maintainer of wxscintilla meanwhile if you wish. Btw: I've already prepared the synch to scintilla 3.50 hence I see an issue with white fonts on white background I was unable to resolve so far. Scintilla has undergone some major changes I.e. switching the architecture to an mvc principle. This obviously is the reason but I could not pin point the exact code portion. I could do a branch of you like...
What I meant are commits like this:
Quote from: http://sourceforge.net/p/codeblocks/code/8278/
* pumped (wx)Scintilla to 3.2.2
* harmonised (wx)Scintilla with wxSTC from wxWidgets SVN (which happened to have updated scintilla, too lately)
The updates to scintilla are more or less independent from this.
You could make branch with the new scintilla, so more devs can have a look into the issue(s) with 3.50 .
What exactly is the issue with white fonts on white background ?
Oh right,I see.Well what I harmonised was mainly the layout of the source code wrt where the methods are located so you can compare better and (most important) the generator that actually creates the source code out of a template. It's a python script.
I'll do a branch hopefully tomorrow...
Quote from: oBFusCATed on August 19, 2014, 09:58:58 AM
This is the bug report: http://trac.wxwidgets.org/ticket/13709 if you want to join the discussion:)
Attached is how I think the solution should look like.
About the patch: it would be good if you can put a comment why do you need the second draw rectangle call.
Also: I'll be happy if you can negotiate this with the developers of wxWidgets...
Quote from: MortenMacFly on August 20, 2014, 05:31:34 AM
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:
https://svn.code.sf.net/p/codeblocks/code/branches/scintilla_3_5_0
Edit: Not to forget: Due to the changes of path's in the branch its best if you do a full
re-build and a
clean before. Its enough to compile/test this single project file, not the whole C::B workspace. But make sure you don't have any old plugins in the way referencing a different (old) scintilla component...
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).
Quote from: jens on August 30, 2014, 03:57:52 PM
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...
I've merged trunk into the branch, cleaned it up, fixed (?) the autotools build system so it would be ready to get merged into trunk again, if there are no complaints...
Are there any?
I will test it today or tomorrow.
Or just commit it, if there are no obvious issues and we fix it in trunk.
Quote from: jens on August 31, 2014, 12:25:11 AM
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.
Well with respect to the MiniDoc plugin:
Are there any news? In principle it works nicely, hence it takes away a lot CPU power thus scrolling of any editors becomes really clumsy. It goes away, if you disable the plugin, but NOT (?!) if you hide the minidoc Window.
I would love to see that working...
Ping... :-)
Quote from: MortenMacFly on February 17, 2015, 09:01:04 PM
I would love to see that working...
I hope, I'll find some time to work on a real scrollbar replacement later this year.
Quote from: oBFusCATed on February 21, 2015, 07:18:38 PM
I hope, I'll find some time to work on a real scrollbar replacement later this year.
BTW: I just discovered Jens' fork.
@Jens: What are the changes? Is that working more reliable?
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.
Quote from: oBFusCATed on February 21, 2015, 09:17:43 PM
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 ::)
OK, but still: any comments on the performance? Am I the only one experiencing such?
My intention when forking the repo was to make a pull request, which can be integrated automatically into the original repo without the need to handle patches manually.
It's not a "normal" fork.
I've not used it since the first try, because it had problems when using two editors side by side.
Also I think it should not land in trunk before next release.
Quote from: MortenMacFly on February 21, 2015, 09:49:16 PM
...
OK, but still: any comments on the performance? Am I the only one experiencing such?
It is/was really bad. But I just commited some improvements. It still needs some resources but.. test it yourself.
Quote from: oBFusCATed on February 21, 2015, 11:22:50 PM
I've not used it since the first try, because it had problems when using two editors side by side.
What problems?
Quote from: oBFusCATed on February 21, 2015, 11:22:50 PM
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!
Quote from: danselmi on February 24, 2015, 11:43:42 PM
What problems?
Unfortunately I don't remember the details. :(
I should see if I can give it a try at work, because there I'm using two editors side by side all the time.
Quote from: danselmi on February 24, 2015, 11:43:42 PM
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.
Hi!
I tested this plugin today and it performed really bad.. Is this only for me or also for other users? I remember that in the past this was not the case.... I suspect the wxScintilla update here?
No idea, I'm not using this plugin.
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.
Quote from: Krice on September 24, 2019, 09:23:07 AM
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?
Edit: Your comment can
almost be summed up by "the project is not newbie friendly".
It fails to mention
The OS used to build
The WX version used to build
The CB version used to build
And, it does not contain any error messages!
Edit2: It also fails to mention compiler version.
Tim S.
Is the fact that this plugin links to wxscintilla_cb a problem?
When using MiniDoc_wx31_64.cbp
Edit2: I am asking because non of the C::B contrib plugins do this linking.
Tim S.
Quote from: stahta01 on September 24, 2019, 08:11:11 PM
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.
Quote from: Krice on September 25, 2019, 08:08:11 AM
Quote from: stahta01 on September 24, 2019, 08:11:11 PM
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 the "Developer forums (C::B DEVELOPMENT STRICTLY!) ยป Plugins development" sub-form.
It assumes you have the ability to build a working C::B from source!
Tim S.
Quote from: stahta01 on September 25, 2019, 03:46:08 PM
Till you learn how to build a working Code::Blocks I strongly suggest you avoid
I can still comment about the quality of source code even if I didn't know anything about that particular language or library or whatever. What I find hilarious about Code::Blocks's code itself is that you people don't even cppcheck it before release. It's really no wonder why these open source projects are a mess, because that's what they are. Like I said, don't try to turn it to someone else's fault when your code is sub-standard, is badly commented and there are no clear instructions on how to use it.
I suggest reading and following this website rules!
http://forums.next.codeblocks.org/index.php/topic,9996.0.html (http://forums.next.codeblocks.org/index.php/topic,9996.0.html)
I think you have not yet violated the rules. But, you have violated rules that other websites I am on use.
You miss-quoted me.
Tim S.
Quote from: stahta01 on September 28, 2019, 06:57:34 PMBut, 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. I think I'm going to delete Code::Blocks and stop using it forever, thanks to you.
Quote from: Krice on September 29, 2019, 10:07:07 AM
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.
You can be sure that we do also know the flaws you mention and trying to work on that. But its also true, that OpenSource projects without being funded and thus havin full-time personal can hardly have a decent quality management. And I guess you know, that cppchecking the whole C::B source base will block the desktop PC's of our fellow developers for days. Would you want to block your PC?
Please be constructive, give some good advises and help. For example, you could start by providing configurations for the GitHub project to link C::B to recent code checkers there such that we get a continuous report first (CI).