Developer forums (C::B DEVELOPMENT STRICTLY!) > Development

CodeBlock of GUI

(1/3) > >>

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.

Navigation

[0] Message Index

[#] Next page