I should warn you that current releases of BibleMemorizer use what is basically a big hack to allow them to compile on both Qt3 and Qt4. One of my immediate plans for a future release was to remove support for Qt3, since supporting both adds to the development effort and most distros have switched to Qt4 by now. (Windows and Mac builds were already made with Qt4.) This is why you see things like "BQListBoxItem" instead of "QListBoxItem," and also why I had, for example, "#include <qsettings.h>" instead of "#include <QSettings>." If you are willing to work on changes and would like to help with a proper port, it would be very much appreciated! One of the first orders of business will be converting the .ui files from Qt 3 to Qt 4 format. (There is a tool to do this automatically, but some things will have to be changed.) Changing the #includes to Qt4-style will break Qt3 building but won't remove the dependency on the Qt3 support library. http://qt.nokia.com/doc/4.5/porting4.html documents the actual process for porting to Qt4.
A couple things I did notice in your changes so far - one is that you have replaced some of my forward delcarations (e.g. "namespace X { class C }" replaced with "#include X/C.h") The former style I had was for a reason - it prevents unnecessary recompilations of a file which only uses pointers to a modified class or struct. Also, there was a place or two where you moved an initializer into the body of the constructor. My style has been to prefer initializers wherever possible. Is there a reason to change this?
Did you have other plans for new features or changes after this? If they're useful I'd be happy to include them in the official release (and would of course list you as an author.) I've added you to this project as a developer with Git repository access, so you can move your repository to the official SF hosting here if you'd like. I would probably prefer to have it here if you don't mind. (Previously I had only CVS enabled here, but I turned on Git for your sake.)
Feel free to ask any questions. I may be able to provide you with more coding help starting mid-May, but I'm in graduate school right now and have quite a bit of work before the semester ends. Welcome!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think that am a good idea. Who needs qt3, uses an older version of BibleMemorizer or makes a backport.
Using namespaces
My experience with GUI programming is, which often gives it a class for the GUI, and one class has for functionality. So, you can give the classes same name without conflicts:
GUI::Car
Type::Car
Factory::Car
and so on…
Prefer initializers
Yes, with c++ one can do many things. But it is also meaningful? Most programming languages make it differently. I find it to read with difficulty. It looks like Inheritance.
_My plans _
I wanted more functions for the categories. And an export for BibTeX (LaTeX).
GtiHub vs. FS.Net
I believe GitHub am better for Git. The best way its, you pull my changes in your Git. If there are decisions with me which you does not accept, you have more control. If you Git used I can pull back your changes. And I do not know whether I can achieve my goal. Then only one ruin stays.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I should mention with Qt3->Qt4 that one easy (but tedious, unless scripted) task is to eliminate dependence on qt_types.h by replacing the special typedefs and values with the proper Qt4 versions. You can of course use qt_types.h as your reference for what they are supposed to be. Eventually we also want to stop using classes starting with Q3 and replace them with proper Qt4 versions.
With regards to namespaces, I previously had a "bmemcore" and a "bmemui" namespace. I see you changed them to better match the directory structure, which is probably good. My style has been to add something like "UI" for the Qt-designer GUI and "Act" for the implementation GUI class. Thus naming conflicts were avoided, so the namespaces weren't strictly necessary. Most of the names date back to before I split up the namespaces and I opted to keep the style consistent after I did that.
The purpose of initializers is a slight efficiency improvement. Without initializers, a non-optimizing compiler would initialize everything to a default value, and then change it to something else in the constructor. Thus each value gets initialized twice rather than once. This is most noticeable for objects, which may have constructors and assignment operators that take significant time to run. With initializers, each value is only initialized a single time, to the correct value. Because GCC is probably smart enough to realize this and act as though we used an initializer (especially with optimizations turned on), it probably doesn't matter much. But I prefer to do things the "proper" way. Also, some constructors require arguments and thus MUST be placed in the initializer, so I figured it was more consistent to just put everything there.
Your plans do sound like useful contributions. With regards to Git, if GitHub provides better features than SourceForge, that's fine. You could also work in your own branch on SourceForge if you wanted. (I'm pretty new to Git, but my understanding is that's pretty easy to do. I've previously used SVN and CVS but am getting started with Git on some other stuff related to grad school research, so it'll be good for me to learn it better.)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
* i has the beckend switched to SQLite
* and made an import filter for old Files.
* Begine new GUI (with Qt 4 without ui-Files. I do not like the XML code.). This starts with the parameter
biblememorizer --altergui
Many comments in the code are German. I translate it later…
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello!
I had some problems to understand the Source Code. So I have begun with a Refactoring.
To find on
<a href="http://github.com/OlafRadicke/BibleMemorizer">
http://github.com/OlafRadicke/BibleMemorizer
</a>
I should warn you that current releases of BibleMemorizer use what is basically a big hack to allow them to compile on both Qt3 and Qt4. One of my immediate plans for a future release was to remove support for Qt3, since supporting both adds to the development effort and most distros have switched to Qt4 by now. (Windows and Mac builds were already made with Qt4.) This is why you see things like "BQListBoxItem" instead of "QListBoxItem," and also why I had, for example, "#include <qsettings.h>" instead of "#include <QSettings>." If you are willing to work on changes and would like to help with a proper port, it would be very much appreciated! One of the first orders of business will be converting the .ui files from Qt 3 to Qt 4 format. (There is a tool to do this automatically, but some things will have to be changed.) Changing the #includes to Qt4-style will break Qt3 building but won't remove the dependency on the Qt3 support library. http://qt.nokia.com/doc/4.5/porting4.html documents the actual process for porting to Qt4.
A couple things I did notice in your changes so far - one is that you have replaced some of my forward delcarations (e.g. "namespace X { class C }" replaced with "#include X/C.h") The former style I had was for a reason - it prevents unnecessary recompilations of a file which only uses pointers to a modified class or struct. Also, there was a place or two where you moved an initializer into the body of the constructor. My style has been to prefer initializers wherever possible. Is there a reason to change this?
Did you have other plans for new features or changes after this? If they're useful I'd be happy to include them in the official release (and would of course list you as an author.) I've added you to this project as a developer with Git repository access, so you can move your repository to the official SF hosting here if you'd like. I would probably prefer to have it here if you don't mind. (Previously I had only CVS enabled here, but I turned on Git for your sake.)
Feel free to ask any questions. I may be able to provide you with more coding help starting mid-May, but I'm in graduate school right now and have quite a bit of work before the semester ends. Welcome!
Qt3->Qt4
I think that am a good idea. Who needs qt3, uses an older version of BibleMemorizer or makes a backport.
Using namespaces
My experience with GUI programming is, which often gives it a class for the GUI, and one class has for functionality. So, you can give the classes same name without conflicts:
GUI::Car
Type::Car
Factory::Car
and so on…
Prefer initializers
Yes, with c++ one can do many things. But it is also meaningful? Most programming languages make it differently. I find it to read with difficulty. It looks like Inheritance.
_My plans _
I wanted more functions for the categories. And an export for BibTeX (LaTeX).
GtiHub vs. FS.Net
I believe GitHub am better for Git. The best way its, you pull my changes in your Git. If there are decisions with me which you does not accept, you have more control. If you Git used I can pull back your changes. And I do not know whether I can achieve my goal. Then only one ruin stays.
I should mention with Qt3->Qt4 that one easy (but tedious, unless scripted) task is to eliminate dependence on qt_types.h by replacing the special typedefs and values with the proper Qt4 versions. You can of course use qt_types.h as your reference for what they are supposed to be. Eventually we also want to stop using classes starting with Q3 and replace them with proper Qt4 versions.
With regards to namespaces, I previously had a "bmemcore" and a "bmemui" namespace. I see you changed them to better match the directory structure, which is probably good. My style has been to add something like "UI" for the Qt-designer GUI and "Act" for the implementation GUI class. Thus naming conflicts were avoided, so the namespaces weren't strictly necessary. Most of the names date back to before I split up the namespaces and I opted to keep the style consistent after I did that.
The purpose of initializers is a slight efficiency improvement. Without initializers, a non-optimizing compiler would initialize everything to a default value, and then change it to something else in the constructor. Thus each value gets initialized twice rather than once. This is most noticeable for objects, which may have constructors and assignment operators that take significant time to run. With initializers, each value is only initialized a single time, to the correct value. Because GCC is probably smart enough to realize this and act as though we used an initializer (especially with optimizations turned on), it probably doesn't matter much. But I prefer to do things the "proper" way. Also, some constructors require arguments and thus MUST be placed in the initializer, so I figured it was more consistent to just put everything there.
Your plans do sound like useful contributions. With regards to Git, if GitHub provides better features than SourceForge, that's fine. You could also work in your own branch on SourceForge if you wanted. (I'm pretty new to Git, but my understanding is that's pretty easy to do. I've previously used SVN and CVS but am getting started with Git on some other stuff related to grad school research, so it'll be good for me to learn it better.)
Okay, I stops my constructor changes.
i report the currente situation of my fork…
* i has the beckend switched to SQLite
* and made an import filter for old Files.
* Begine new GUI (with Qt 4 without ui-Files. I do not like the XML code.). This starts with the parameter
Many comments in the code are German. I translate it later…