CodeBlock of GUI

[puneet_m]

Which source file contains the code for codeblock GUI? I was checking through main.cpp, but seems like it does not have the implementation of complete GUI.

[TDragon]

There is no single source file that contains every GUI-related call C::B makes; that would be completely impractical. Code::Blocks makes good use of object-oriented C++, so a GUI object is generally part of or equivalent to a C++ object representing the underlying C::B functionality. Pay attention to classes that subclass wxWidgets classes or that have wxWidgets objects for members.

[wwolf]

Well, I will have to disagree here.   Good OO design would use the MVC pattern, so the code representing the model would not contain any reference to the GUI part.  If you do not believe me, try to ask Jim Coplien's opinion, he has a pretty strong and well founded idea why MVC should be used in C++ wherever possible.  In your case it would mean that if someone wants Code::Blocks for Qt, they could just change the View part, perhaps refactor the Controller part a bit to be more generic, and tada...

[TDragon]

wwolf:
I can't speak for the C::B developers, but to my mind what you're proposing trades too much efficiency for its flexibility. Decoupling and abstraction do come at a price, and a level of decoupling that would let one switch C::B's GUI system between wxWidgets and Qt would very expensive.

[wwolf]

Well, I do not think that I know enough to have an opinion about possible performance loss.  But what I know (being part of the C++ standardization effort) is that most of performance worries are actually unfounded.  C++ provides ways of abstraction that cost nothing runtime.  And I am not suggesting a system that can change between Qt and wxWidgets runtime.   All I wanted to point out is that we have a (strong) difference of opinion in what constitutes a good OO design.  In my humble opinion Model classes incorporating View elements does not.  It violates the most basic rule of good design: one entity - one responsibility.  And in addition I also thing that when our computing power doubles per (approx) 18 months, it is more important to make good designs than to worry about possible costs of abstraction.

Not to mention (well, I will just mention it) GUI stuff is not the thing that needs optimization.  If it is done well, it is fast enough.  Good and responsive GUIs are written in Python.  Of course, if scrolling is done by invalidating and redrawing the whole - well, that is just bad design.  What I am trying to say is that what is important to optimize is stuff that runs in tight loops.  Now no matter how fast we can type, GUI rarely falls into this category.

So again: I am not suggesting that Code::Blocks is rewritten to the MVC model.   I just objected to the idea that embedding View capabilities into Model classes is a good (OO or other) design.  I also think that the project is not in a stage where it would be time for refactoring.  For that to happen we would not only need a motivation, but a project that is stable and reasonably complete (i.e.: no serious bugs or missing features) and many more active designers.

Since when I have tried to create a DLL subproject with the wizard I have got an error message, something along the lines of "I have no clue how to set the optimization parameters" I do not consider Code::Blocks to be complete enough for a refactoring.

Sine it causes no trouble that the MVC is not followed, there is no motivation - unless my nagging is considered that.   If it works, do not fix it.

I also believe that we do not have enough people who are intimately familiar with Code::Blocks sources as well as its weaknesses to be able to confidently start any refactoring work - without too much risks.  Like: introducing bugs, not making what needs to be done - due to misunderstanding etc.

But now I have two things to politely disagree about: mixing GUI into Model code and that the abstractions required by MVC would impose too much performance penalty.  And I base the latter on talking to those people who have made the C++ Performance Technical Report (available for free at http://www.open-std.org/jtc1/sc22/wg21/ ) and on the fact that MVC was introduced inside SmallTalk, which is a sort of interpreted language.  And it was fast enough in there.

I think that by factoring out the GUI related code from the Model part could actually result in a faster executable.  The reason being is that the Model code could be done using all features of modern C++ (wxWidgets is very conservative in using C++ features due to its age), it could be smaller, better organized, so the compilers would have a better chance to make those things incredibly fast.  But that is also just an opinion.   But I like to think that it is based on experience.  Once I was able to make a program 2 times faster by just removing design decisions (well, changing) that were put in there to make the code fast.   By not doing them, it has got twice as fast! :>  Kind of a surprise, but if you read Herb Sutter's thoughts (and presentations) about optimization: it is quite common.  We could call it the "C/C++ programmers waste too much performance with optimizations" anti-pattern. :>  Me being also just as guilty as everyone else.

[TDragon]

Nice essay.

The M-V-C design pattern, like any design pattern, is a tool to be used if helpful and discarded if not. Consider the cost of using it on Code::Blocks. I estimate that 70% of C::B classes incorporate both wxWidgets GUI elements and data structures. To apply M-V-C, each of these classes would need to be split apart into at least two separate classes: one for the data structure, one for the GUI. We now have 70% more classes, and (at a guess) 20-30% more LoC to be compiled. Then we add the runtime expenses to the tally -- 10% of these new classes might give the compiler a clue to better optimizations, but the other 90% will at best come at no additional cost, and at worst actually come at a higher cost, through increased stack usage (minor) and increased dynamic allocations (major). Is there more? You bet. C::B's developers now have to keep track of 2-3 times as many relevant classes for each concept.

In combining the data structure with the single GUI element that is responsible for it, C::B usually benefits.

[wwolf]

Do not take me wrong, but I think that what you have said is only guesswork.  Unless you measure, you don't know.

Also pls. take it into account that understanding 20 complex classes is more of a burden than understanding (even) 40 simple ones.  Not to mention that if the GUIs choice of OO-for-everything does not infect the Model code, you may actually end up using design techniques (such as templates) that reduce the number of classes.

My 20+ years of experience in the field tells me the above.  I know that not only design complications come from mixing more responsibilities into a class, but it (unfortunately very) effectively raises the bar for new designers to join in.  Suppose I could contribute in the Model part.  Today I am not able to do that, because the Model part is mixed with the GUI, where I have no confidence.  Also, comes in testability.  Mixing GUI into Model makes unit testing close to impossible.

I feel that I am not going to convince you, but just let's make one more point and then we can agree to disagree.   You have mentioned that 10% of the code may get faster while 90% slower.  Even if that is the case what matters is: which one?  90% of the execution of a program is spent in 10% of its code.  (90-10 rule, sometimes 20-80 rule.)  In a GUI environment that 10% of the code (that provides your speed) is in the Model part - not in the GUI.  Of course, I am not talking about 3D and rendering applications, which are 99% GUI.

[stefanos_]

wwolf, can you please explain to me what do you mean by saying Model?

I have searched for this through Google and I haven't found anything that explains its meaning. Only a project named C++ Model Developer (CMD) http://stinet.dtic.mil/oai/oai?&verb=getRecord&metadataPrefix=html&identifier=ADA433836 has something about Model if that's the case.

[wwolf]

That is one part of the MVC pattern.  View, Model, Controller.  In a quick an dirty description: Model is the data we want to show.  View is the part that does the showing, it is the GUI.  Of course, it does not only show, you may also edit (change the Model) using it.  The Controller is the element that makes the connection between (possibly many different) Views and their Models.  See the WikiPedia article about it: http://en.wikipedia.org/wiki/Model-view-controller

[JGM]

See the WikiPedia article about it: http://en.wikipedia.org/wiki/Model-view-controller

Interesting, I will try to implement that kind of design on a program that I'm working on.

[stahta01]

Other than setting the Compiler options where do you think the extra overhead and work needed to use Model-view-controller design would be desired?

What I read in last 5 minutes implies, that the Model-view-controller design is best when large amount of data elements is used.

Tim S

[MortenMacFly]

What I read in last 5 minutes implies, that the Model-view-controller design is best when large amount of data elements is used.

I don't really get it, too. At work I practice MVC a lot. But this work is related to a huge configuration database and parameters. There the MVC pattern really fits. I don't see MVC for a dev-IDE though... Maybe for minor parts but how is a compiler front end related to a model???

[wwolf]

I did not mean the compiler front end to be a model.   Anyways, an IDE is not a compiler front end, that is the parser (and some more) of the compiler... as far as I know.

However think of an IDE that parses the compiler output, and can show it in different ways.  One view is the normal text view.  Another one may be a collapsable view where template or name lookup related (incredibly long) messages are collapsed (like Scintilla does with code) and they can be opened when you click them.  Yet another view (to the same Model) is signs inside the open editors that show which line has a warning or an error.

[wwolf]

As some of the linked documents (from the WikiPedia page) clearly state: MVC is not necessarily the easiest design choice for all possible problems.  All I wanted to point out is that it is an option that we want to think about when we design.  And there can be absolutely valid reasons why not to do it.  However I believe that "it will be slow" is not one of them, unless we have tested it on a sensible prototype that it is indeed slow.

Anyways, I want to point out again that I am not advocating to change Code::Blocks to use MVC.   I just wanted to show a (possibly) viable option, so that we all know about it.