Page 2 of 3 FirstFirst 123 LastLast
Results 21 to 40 of 57

Thread: The return of the king!

  1. #21
    Join Date
    Jan 2006
    Posts
    368
    Thanks
    14
    Thanked 18 Times in 17 Posts
    Qt products
    Qt4
    Platforms
    Unix/X11 Windows

    Default Re: The return of the king!

    Here are some of my tips, feel free to ignore them :

    1. The problems you have need to be addressed by just using the correct includes, and refactoring the whole code.
    2. Doxygen has an option to generate the includes for each file. You will see that almost-everything-includes-almost-everything on your project.
    3. You can also generate UML diagrams to understand the project "from above". This will help you the refactoring.
    4. The components of the application should be stand alone. This will will help the debugging, as each component cannot be debugged on it's own, on small test cases (other small applcations)
    5. The directory structure is very hard to comprehend.
    6. I still an unsure how to rebuild the whole application as release, or debug, as there are a lot of sub-projects. Should I change them all to "release"? (how about including a $SOURCE_ROOT/config.pri on each sub project?)
    7. You have classes with mixed targets: that handle configuration and also GUI. Again, this is bad practice, as you cannot unit-test those classes, not take them outside of the projects.
    Last edited by elcuco; 8th July 2006 at 12:02.

  2. #22
    Join Date
    Jan 2006
    Location
    travelling
    Posts
    1,116
    Thanks
    8
    Thanked 127 Times in 121 Posts
    Qt products
    Qt4
    Platforms
    Unix/X11 Windows

    Default Re: The return of the king!

    Quote Originally Posted by elcuco
    Here are some of my tips, feel free to ignore them :
    1. The problems you have need to be addressed by just using the correct includes, and refactoring the whole code.
    2. Doxygen has an option to generate the includes for each file. You will see that almost-everything-includes-almost-everything on your project.
    3. You can also generate UML diagrams to understand the project "from above". This will help you the refactoring.
    4. The components of the application should be stand alone. This will will help the debugging, as each component cannot be debugged on it's own, on small test cases (other small applcations)
    5. The directory structure is very hard to comprehend.
    6. I still an unsure how to rebuild the whole application as release, or debug, as there are a lot of sub-projects. Should I change them all to "release"? (how about including a $SOURCE_ROOT/config.pri on each sub project?)
    7. You have classes with mixed targets: that handle configuration and also GUI. Again, this is bad practice, as you cannot unit-test those classes, not take them outside of the projects.
    1. I don' see which problem you are talking about? I don't know any bug in Edyuk that could be solved by "the correct includes". In case you didn't noticed Edyuk has started as a refactored an improved version of DevQt... What would you want to refactor???
    2. Not true, but anyway... is it a problem that all components of an app are deeply linked?
    3. I know that but unfortunately : I'm not skilled in UML, I don't see any need to refactor (again) the code - maybe you could point out one -, I don't have any tools to genrate these UML diagrams...
    4. What do you call components exactly? And what means "standalone" for you? An app such as Edyuk can't have only standalone components as far as my understanding of these words goes...
    5. Is it? where do the difficulties start? It seemed quite logical to me but if you have a better proposition my hears are openned.
    6. Ah! Great question indeed... I may have been wrong in settings build_all in all projects... Edyuk projects files are configured to build in debug_and_release mode by default - maybe this explains the long compilation time a little better, huh? - all you need is to edit the files manually (removing build_all from the CONFIG variable). BTW you can do it under Edyuk with the project options dialog (and don't forget to save the project after modifying...)
    7. I know I could separate a bit more configuration dialogs and their "applications" but it wouldn't change that much things : even if all the configuration things are not done in the class their would still be a function or two to handle it (doing everything outside of them would be an useless overkill IMHO ...)
    I welcome your tips but could you be more *precise*, please?
    Current Qt projects : QCodeEdit, RotiDeCode

  3. #23
    Join Date
    Jan 2006
    Posts
    368
    Thanks
    14
    Thanked 18 Times in 17 Posts
    Qt products
    Qt4
    Platforms
    Unix/X11 Windows

    Default Re: The return of the king!

    "I still an unsure how to rebuild the whole application as release, or debug, as there are a lot of sub-projects. Should I change them all to "release"? (how about including a $SOURCE_ROOT/config.pri on each sub project?)"

    Lets start with this one:
    make a "config.pri" on the root of your project, and make all the subprojects include that ("include ../../config.pri"). Then you have a single point where you need to define configuration on your programs.

  4. #24
    Join Date
    Jan 2006
    Location
    travelling
    Posts
    1,116
    Thanks
    8
    Thanked 127 Times in 121 Posts
    Qt products
    Qt4
    Platforms
    Unix/X11 Windows

    Default Re: The return of the king!

    Quote Originally Posted by elcuco
    "I still an unsure how to rebuild the whole application as release, or debug, as there are a lot of sub-projects. Should I change them all to "release"? (how about including a $SOURCE_ROOT/config.pri on each sub project?)"

    Lets start with this one:
    make a "config.pri" on the root of your project, and make all the subprojects include that ("include ../../config.pri"). Then you have a single point where you need to define configuration on your programs.
    Not a bad idea! Won't do everything but enough for your config dilemma...
    Anyway you won't necessary nead to change all the configuration... Makefiles are generated with both debug and release which means that three makefile are generated :
    • a wrapper that handles targets such as : "debug", "release", "debug-clean", ...
    • a makefile for debug
    • a makefile for release
    All you need is to call make with the appropriate target... But The config.pri is still a good idea!


    Important note for developpers : unstable 0.5.0 packages have been released on Sourceforge.net. Don't waste your time creating plugins for Edyuk 0.4.2 : the plugin system has been completely rewritten... (the translation system as well but that matters a little less )
    Last edited by fullmetalcoder; 8th July 2006 at 14:55.
    Current Qt projects : QCodeEdit, RotiDeCode

  5. #25
    Join Date
    Jan 2006
    Posts
    19
    Thanked 1 Time in 1 Post
    Qt products
    Qt3 Qt4 Qt/Embedded
    Platforms
    MacOS X Unix/X11

    Question Re: build error!

    Hello I tried to build edyuk under linux FC4 with QT 3.3.4 and 4.1 installed and I had the following error:
    [firas@druid edyuk-stable]$ ./build
    edyuk.pro:7: Unknown test function: warning
    edyuk.pro:8: Unknown test function: warning
    cd src/lib && qmake lib.pro -o Makefile
    lib.pro:7: Unknown test function: warning
    lib.pro:8: Unknown test function: warning
    cd src/lib && make -f Makefile
    make[1]: Entering directory `/home/firas/edyuk-stable/src/lib'
    /usr/lib/qt-3.3/bin/uic ui/aboutdialog.ui -o ../tmp/ui/aboutdialog.h
    uic: File generated with too recent version of Qt Designer (4.0 vs. 3.3.4)
    make[1]: *** [../tmp/ui/aboutdialog.h] Error 1
    make[1]: Leaving directory `/home/firas/edyuk-stable/src/lib'
    make: *** [sub-src-lib] Error 2
    [firas@druid edyuk-stable]$
    any suggestions.
    thnks,
    firas

  6. #26
    Join Date
    Jan 2006
    Location
    travelling
    Posts
    1,116
    Thanks
    8
    Thanked 127 Times in 121 Posts
    Qt products
    Qt4
    Platforms
    Unix/X11 Windows

    Default Re: build error!

    Your log clearly shows the error : you're trying to compile edyuk with Qt 3... As you said that you have Qt installed this must be a path error... Make sure the path to Qt 4 comes before the one to Qt 3 in your path variable.
    Current Qt projects : QCodeEdit, RotiDeCode

  7. #27
    Join Date
    Jan 2006
    Location
    Bremen, Germany
    Posts
    476
    Thanked 70 Times in 66 Posts
    Qt products
    Qt3 Qt4
    Platforms
    Unix/X11 Windows

    Default Re: The return of the king!

    I recompiled with 4.2.0-tp1 and now also get an error on opening a file via File->Reopen->An already opened txt/src file. When I try to open a pro-file it works fine.
    It looks like some QAction aren't available anymore in QMenu::mouseReleaseEvent()... I can send you a bt if you want, but I doubt it helps you much.

    /edit: Just saw that 0.5.0 is out - currently compiling to see if problem still exists

    /edit2: After some compile problems I could start edyuk but it crashes on start ("QLayout::addChildWidget: DevCompilerOutput "" in wrong parent; moved to correct parent") in core.cpp:57

    And here the changes I had to made:

    Qt Code:
    1. devtranslator.cpp:235
    2. // QEvent e(QEvent::Type(DevApp::RunTimeTranslation));
    3. QEvent e((QEvent::Type)DevApp::RunTimeTranslation);
    4.  
    5. cppmatcher.cpp:408
    6. // if (!bd->couldCollapse || !bd->collapsedLines.size() > 0)
    7. if (!bd->couldCollapse || !(bd->collapsedLines.size() > 0))
    8.  
    9. pluginsystem.h:
    10. move Q_DECL_DLLEXPORT before QObject* / void
    11. extern "C" Q_DECL_EXPORT QObject* EDYUK_PLUGIN_INSTANCE_SYMBOL(QObject *o) \
    To copy to clipboard, switch view to plain text mode 
    Last edited by ChristianEhrlicher; 11th July 2006 at 08:09.

  8. #28
    Join Date
    Jan 2006
    Location
    travelling
    Posts
    1,116
    Thanks
    8
    Thanked 127 Times in 121 Posts
    Qt products
    Qt4
    Platforms
    Unix/X11 Windows

    Default Re: The return of the king!

    Quote Originally Posted by ChristianEhrlicher
    I recompiled with 4.2.0-tp1 and now also get an error on opening a file via File->Reopen->An already opened txt/src file. When I try to open a pro-file it works fine.
    It looks like some QAction aren't available anymore in QMenu::mouseReleaseEvent()... I can send you a bt if you want, but I doubt it helps you much.
    The reopen menu crashes under Win since I made it "run-time updatable". Maybe Qt 4.2.0 has brought this failure under all platforms but I fixed it in 0.5 anyway...

    Quote Originally Posted by ChristianEhrlicher
    /edit: Just saw that 0.5.0 is out - currently compiling to see if problem still exists
    Quote Originally Posted by ChristianEhrlicher
    /edit2: After some compile problems I could start edyuk but it crashes on start ("QLayout::addChildWidget: DevCompilerOutput "" in wrong parent; moved to correct parent") in core.cpp:57
    This warning message isn't relevant... Can you give a more complete log?

    Quote Originally Posted by ChristianEhrlicher
    And here the changes I had to made:

    Qt Code:
    1. devtranslator.cpp:235
    2. // QEvent e(QEvent::Type(DevApp::RunTimeTranslation));
    3. QEvent e((QEvent::Type)DevApp::RunTimeTranslation);
    4.  
    5. cppmatcher.cpp:408
    6. // if (!bd->couldCollapse || !bd->collapsedLines.size() > 0)
    7. if (!bd->couldCollapse || !(bd->collapsedLines.size() > 0))
    8.  
    9. pluginsystem.h:
    10. move Q_DECL_DLLEXPORT before QObject* / void
    11. extern "C" Q_DECL_EXPORT QObject* EDYUK_PLUGIN_INSTANCE_SYMBOL(QObject *o) \
    To copy to clipboard, switch view to plain text mode 
    Looks like MSVC sucks... I'll change that!
    Current Qt projects : QCodeEdit, RotiDeCode

  9. #29
    Join Date
    Jan 2006
    Location
    Bremen, Germany
    Posts
    476
    Thanked 70 Times in 66 Posts
    Qt products
    Qt3 Qt4
    Platforms
    Unix/X11 Windows

    Default Re: The return of the king!

    I've changed
    Qt Code:
    1. pCompilerOutput = new DevCompilerOutput(compiler);
    2. compiler->addTab(pCompilerOutput, tr("Errors"));
    To copy to clipboard, switch view to plain text mode 
    to
    Qt Code:
    1. pCompilerOutput = new DevCompilerOutput;
    2. compiler->addTab(pCompilerOutput, tr("Errors"));
    To copy to clipboard, switch view to plain text mode 

    and now it starts, But then I get a stack overflow in
    devtranslator.cpp (DevTranslator::setLanguage(QString)) because bOk never gets true...

  10. #30
    Join Date
    Jan 2006
    Location
    travelling
    Posts
    1,116
    Thanks
    8
    Thanked 127 Times in 121 Posts
    Qt products
    Qt4
    Platforms
    Unix/X11 Windows

    Default Re: The return of the king!

    Quote Originally Posted by ChristianEhrlicher
    I've changed
    Qt Code:
    1. pCompilerOutput = new DevCompilerOutput(compiler);
    2. compiler->addTab(pCompilerOutput, tr("Errors"));
    To copy to clipboard, switch view to plain text mode 
    to
    Qt Code:
    1. pCompilerOutput = new DevCompilerOutput;
    2. compiler->addTab(pCompilerOutput, tr("Errors"));
    To copy to clipboard, switch view to plain text mode 
    and now it starts
    Can't believe it! A misparenting shouldn't cause a crash... I've fixed it anyway.

    Quote Originally Posted by ChristianEhrlicher
    But then I get a stack overflow in
    devtranslator.cpp (DevTranslator::setLanguage(QString)) because bOk never gets true...
    Good that you point this out! Indeed the translation stuff wasn't well initialized but since I created french translation I didn't notice it. Fixed as well.

    I've updated the SVN trunk to 0.5.1, which includes all fixes for the bugs you reported and a working compilation engine, a widget to edit qrc files, and much more...

    I'll put pre-release packages on Sf.net ASAP. It's really good : Edyuk is now able to edit, build and run itself and I tried the compîlation engine with a few other projects (monkey studio aka qt4ds and QIde : it never failed...)

    Current Qt projects : QCodeEdit, RotiDeCode

  11. #31
    Join Date
    Jan 2006
    Location
    travelling
    Posts
    1,116
    Thanks
    8
    Thanked 127 Times in 121 Posts
    Qt products
    Qt4
    Platforms
    Unix/X11 Windows

    Default Re: The return of the king!

    Quote Originally Posted by fullmetalcoder
    I've updated the SVN trunk to 0.5.1,

    Apologies... My internet connection had troubles yesterday and this morning it was TortoiseSVN that bothered me. Anyway I finally managed to put the last source on the trunk.

    Quote Originally Posted by fullmetalcoder
    I'll put pre-release packages on Sf.net ASAP.
    Done as well. I'm waiting for some feedback...

    Quote Originally Posted by elcuco
    Lets start with this one:
    make a "config.pri" on the root of your project, and make all the subprojects include that ("include ../../config.pri"). Then you have a single point where you need to define configuration on your programs.
    Done! If you took some time to check you'll see that the config.pri is quite powerful as far as the user is concerned and well-documented.

    @elcuco : I'd like to know a few things :
    • how did you managed to have the tab stop set to 0
    • what do you think of the changes I've made to qmdilib so as to integrate run-time translation and "document" support in it ???
    Current Qt projects : QCodeEdit, RotiDeCode

  12. #32
    Join Date
    Jan 2006
    Posts
    368
    Thanks
    14
    Thanked 18 Times in 17 Posts
    Qt products
    Qt4
    Platforms
    Unix/X11 Windows

    Default Re: The return of the king!

    @elcuco : I'd like to know a few things :

    * how did you managed to have the tab stop set to 0
    * what do you think of the changes I've made to qmdilib so as to integrate run-time translation and "document" support in it ???
    I am not sure what do you mean by "tab stop", do you mean this?
    http://doc.trolltech.com/4.1/qtexted...StopWidth-prop

    About the modifications to qmdilib, I already told you in private, please send me patches, so I can understand what are you modifying. If your patches take care of several things, please split it into several logical patches. Since you relicensed the library to GPL, I cannot use your code, as I the license of qmdilib is LGPL. Sorry.
    Last edited by elcuco; 15th July 2006 at 18:48.

  13. #33
    Join Date
    Jan 2006
    Location
    Warsaw, Poland
    Posts
    33,363
    Thanks
    3
    Thanked 5,012 Times in 4,791 Posts
    Qt products
    Qt3 Qt4 Qt5 Qt/Embedded
    Platforms
    Unix/X11 Windows Android Maemo/MeeGo
    Wiki edits
    10

    Default Re: The return of the king!

    About long compilation times... Have you tried using precompiled headers? If you have many nested includes, this should help reduce the compilation time a lot (and I do mean a lot). And if the change is really significant, you might want to try to refactor or redesign the what-includes-what system to avoid all-includes-all situation as this greatly increases compilation time when not using precompiled headers. For example try to avoid as much inclusion as possible in the header files (haven't seen your files, so I don't know if you include in header files, just a wild guess) in favour of forward declarations or private class components which are only resolved in implementation modules (like TT does in Qt).

  14. #34
    Join Date
    Jan 2006
    Location
    travelling
    Posts
    1,116
    Thanks
    8
    Thanked 127 Times in 121 Posts
    Qt products
    Qt4
    Platforms
    Unix/X11 Windows

    Default Re: The return of the king!

    Quote Originally Posted by wysota
    About long compilation times... Have you tried using precompiled headers? If you have many nested includes, this should help reduce the compilation time a lot (and I do mean a lot). And if the change is really significant, you might want to try to refactor or redesign the what-includes-what system to avoid all-includes-all situation as this greatly increases compilation time when not using precompiled headers. For example try to avoid as much inclusion as possible in the header files (haven't seen your files, so I don't know if you include in header files, just a wild guess) in favour of forward declarations or private class components which are only resolved in implementation modules (like TT does in Qt).
    I don't know how to use precompiled headers, poor me...
    And I am already putting includes in sources as much as possible (understand when there is no inheritance forbidding it...). What about the private class components? I can't bear them : it's harder to use, produces bigger and slower code...
    I think refactoring a bit could help and if someone can explain me how precompiled headers works I wouldn't refuse...

    Quote Originally Posted by elcuco
    I am not sure what do you mean by "tab stop", do you mean this?
    http://doc.trolltech.com/4.1/qtexted...StopWidth-prop
    I meant tab size... The thing that make Edyuk crash on your PC because of a division by 0...

    Quote Originally Posted by elcuco
    About the modifications to qmdilib, I already told you in private, please send me patches, so I can understand what are you modifying. If your patches take care of several things, please split it into several logical patches. Since you relicensed the library to GPL, I cannot use your code, as I the license of qmdilib is LGPL. Sorry.
    No problem... I'll make you a small package and try to document it as much as possible... And if you're worried about licensing I will make this package LGPL'ed just for you! (and the beauty of your eyes... ).
    As you always talked about "patches" may you explain me how you want those "patches" to be? Would a documented source (stripped of any Edyuk-specific code) be enough or do you want something like diffs???
    Current Qt projects : QCodeEdit, RotiDeCode

  15. #35
    Join Date
    Jan 2006
    Posts
    368
    Thanks
    14
    Thanked 18 Times in 17 Posts
    Qt products
    Qt4
    Platforms
    Unix/X11 Windows

    Default Re: The return of the king!

    Diff's is good enough.

    The tab size was set to 0, because I was using an older configuration. In the original config, you did not have that parameter, and it defaulted to "0". (I think... never investigated very deep).

  16. #36
    Join Date
    Jan 2006
    Location
    Warsaw, Poland
    Posts
    33,363
    Thanks
    3
    Thanked 5,012 Times in 4,791 Posts
    Qt products
    Qt3 Qt4 Qt5 Qt/Embedded
    Platforms
    Unix/X11 Windows Android Maemo/MeeGo
    Wiki edits
    10

    Default Re: The return of the king!

    Quote Originally Posted by fullmetalcoder
    I don't know how to use precompiled headers, poor me...
    Check QMake docs.

    What about the private class components? I can't bear them : it's harder to use, produces bigger and slower code...
    I would argue with that. It's not that hard to use and causes the code to be cleaner, not to mention that it reduces the number of files that need to be included to use a particular class, because all symbols that are used only in the implementation file are not included in the header file. The code is not that bigger (one additional structure and one word for a pointer to the private component in the class definition) and not slower at all.


    I think refactoring a bit could help and if someone can explain me how precompiled headers works I wouldn't refuse...
    QMake docs explain that.

  17. #37
    Join Date
    Jan 2006
    Location
    travelling
    Posts
    1,116
    Thanks
    8
    Thanked 127 Times in 121 Posts
    Qt products
    Qt4
    Platforms
    Unix/X11 Windows

    Default Re: The return of the king!

    Quote Originally Posted by wysota
    Check QMake docs.
    I did it straight after my previous message and applied it : result is a compilation time divided by a little more than 2!!! On a five years old computer, each mode (debug or release) takes about 3 minutes and 40 seconds... Straight comparison : QIde takes 3 minutes and 30 seconds on the same computer!

    Quote Originally Posted by wysota
    I would argue with that.
    It's your right... And maybe you're right about performance and size issues but I won't use private components anyway... They made me loose hours when looking for something in Qt sources ...

    Quote Originally Posted by elcuco
    Diff's is good enough.
    Too bad!!! I don't have any diff tools... I've send you a package by email. Hope you'll like it!

    Quote Originally Posted by elcuco
    The tab size was set to 0, because I was using an older configuration. In the original config, you did not have that parameter, and it defaulted to "0". (I think... never investigated very deep).
    I think it lies in the old config. I've corrected that anyway. Any other bug you'd be the only to encounter?
    Current Qt projects : QCodeEdit, RotiDeCode

  18. #38
    Join Date
    Jan 2006
    Location
    Warsaw, Poland
    Posts
    33,363
    Thanks
    3
    Thanked 5,012 Times in 4,791 Posts
    Qt products
    Qt3 Qt4 Qt5 Qt/Embedded
    Platforms
    Unix/X11 Windows Android Maemo/MeeGo
    Wiki edits
    10

    Default Re: The return of the king!

    Quote Originally Posted by fullmetalcoder
    I did it straight after my previous message and applied it : result is a compilation time divided by a little more than 2!!! On a five years old computer, each mode (debug or release) takes about 3 minutes and 40 seconds... Straight comparison : QIde takes 3 minutes and 30 seconds on the same computer!
    Is that good or bad?


    It's your right... And maybe you're right about performance and size issues but I won't use private components anyway... They made me loose hours when looking for something in Qt sources ...
    But now when you know how to use them, it's not a problem anymore, right?


    Too bad!!! I don't have any diff tools...
    Now you do: http://gnuwin32.sourceforge.net/packages/diffutils.htm

  19. #39
    Join Date
    Jan 2006
    Posts
    368
    Thanks
    14
    Thanked 18 Times in 17 Posts
    Qt products
    Qt4
    Platforms
    Unix/X11 Windows

    Default Re: The return of the king!

    Hi,

    You sent me the full source of your code. What am I suppsed to do with it? Just dump it into my code and forget about my changes?

    You said in several occastions that you have OpenSUSE (or was it another Linux distro...?), anyway, on the shell execute this command (again, if you install the application recommended here, you can do similar things on Win32 as well).

    Qt Code:
    1. diff . ~/src/svn/qtedit4/tools/qmdilib/src/ -ru | less
    To copy to clipboard, switch view to plain text mode 

    This generates a diff/patch from your source into my source. This shows me what did you modify in my code, and what changes should I integrate into my code. From viewing this (too long) diff I conclude:

    1. We use different indentations. This is why the diff is so big, but the code is not that different (sometimes)
    2. We use different doxygen coding standards. Again, this makes the diff bigger, even tough you have the same documentation as I do. But, on some other locations, but documentation is more detailed (you forked off before I released v 0.0.1, in which I made eveny class fully documented).
    3. We use different convensions for "get" memebr functions. All the functions which query the state of the start with "get", all functions which modify the properties of the object start with "get". You used the Qt convention which I do not agree with, in which you have functions with the variable name. Using my method you can have a private variable "foo" and functions "fetFoo()" and "setFoo()". Using Qt convetions, you can have a "_mFoo" and "setFoo()", "foo()".

      IMHO my way is clearer. The way this feature is implemented in C# is the best, but let not get into this.


    What I still managed to understand from this huge diff:
    1. You added new functionalities to qmdiClient, some which I am putting into advanced classes which I call "plugins". You can see this in my 3ed demo in V 0.0.1.
    2. You added a "modified" flag to the qmdiActionGroup to fight the flicker. I still did not fully understand how it works on your code, but I am not sure I need this on my code, as this issue is almost gone on my SVN. It might help with the inserting of widgets. I need to test.
    3. The way the translation is done, if I understand it correctly, is wrong on your code. The mdi clients should know nothing about the translation system. Well, if you do want to modify the language in runtime, this might be a good reason. Anyway, you forked the systems available on Qt, the implementation is just wrong.


    I am attaching here patch I generated here. Please, in the far future try to send patches to people, instead of code. In the near future, I just cannot integrate your changes as you sent them. What you can do, is take V 0.0.1 of qmdiLib, modify it a little, and generate a very small patch to me. Then revert that patch, modify something else, and generate a patch again. Read this documentation from Debian about this subject:
    http://www.us.debian.org/doc/manuals...ltiple-patches
    Attached Files Attached Files

  20. #40
    Join Date
    Jan 2006
    Location
    travelling
    Posts
    1,116
    Thanks
    8
    Thanked 127 Times in 121 Posts
    Qt products
    Qt4
    Platforms
    Unix/X11 Windows

    Default Re: The return of the king!

    1. You added new functionalities to qmdiClient, some which I am putting into advanced classes which I call "plugins". You can see this in my 3ed demo in V 0.0.1.
    2. You added a "modified" flag to the qmdiActionGroup to fight the flicker. I still did not fully understand how it works on your code, but I am not sure I need this on my code, as this issue is almost gone on my SVN. It might help with the inserting of widgets. I need to test.
    3. The way the translation is done, if I understand it correctly, is wrong on your code. The mdi clients should know nothing about the translation system. Well, if you do want to modify the language in runtime, this might be a good reason. Anyway, you forked the systems available on Qt, the implementation is just wrong.
    1. I'll have a look...
    2. qmdiActionGroupList checks each qmdiActionGroup for modification before updating toolbars... What's so difficult?
    3. I do want to modify language on run-time and this is the best way I found to make sure that the translation event is propagated correctly to every client, that it does not occur everytime the translator list changes (through QApplication::installTranslator() or QApplication::removeTranslator()) because the run-time translation is also perfromed on plugins... If you've a better implementation to offer, and that achieves my goals, I'm open...
    Current Qt projects : QCodeEdit, RotiDeCode

Similar Threads

  1. [SOLVED] DirectShow Video Player Inside Qt
    By ToddAtWSU in forum Qt Programming
    Replies: 16
    Last Post: 3rd November 2011, 07:47
  2. Carriage Return in QString
    By incapacitant in forum Newbie
    Replies: 7
    Last Post: 2nd December 2010, 09:18
  3. When is the best time to delete a QCanvasItem
    By irudkin in forum Qt Programming
    Replies: 12
    Last Post: 8th March 2007, 21:28
  4. Replies: 4
    Last Post: 24th March 2006, 22:50
  5. Adding numbers to circles in QPaint
    By therealjag in forum Qt Programming
    Replies: 1
    Last Post: 12th February 2006, 10:21

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Digia, Qt and their respective logos are trademarks of Digia Plc in Finland and/or other countries worldwide.