PDA

View Full Version : The return of the king!



fullmetalcoder
8th June 2006, 08:52
Hi all,

After DevQt's death I continued my work on the IDE I had started a few months ago. First I had to change its name because I thought it wouldn't be good to keep the name after the team splitted. But if I changed the name to Edyuk it's also because legally speaking 'DevQt' wasn't a good name...

Anyway Edyuk developpment is anything but finished and it needs as many testers as possible. Thus I'm announcing that rebirth of DevQt now that I openned a Sourceforge project and started commiting on the SVN trunk.

For some reasons I don't want to open Edyuk to a team based developpment right now but until that day come feel free to report bugs, send suggestions, and create plugins...

A mailing list as also been created and it has been connected to the svn repository to keep track of commits.

Suscribe to the mailing list (https://lists.sourceforge.net/lists/listinfo/edyuk-devel)
Sourceforge site (http://sourceforge.net/projects/edyuk)
Edyuk website (http://edyuk.sourceforge.net) (still needs a lot of work :o )

The address to access SVN repository is :
https://svn.sourceforge.net/svnroot/edyuk

fullmetalcoder
12th June 2006, 15:21
Looks like nobody is interested... :(

Anyway, as some people on the french forum pointed out, an archive will certainly be a little more convenient for many people willing to test Edyuk. So here it is... :)

jwintz
12th June 2006, 17:14
Before your second post I checked the code out and compiled it on MacOSX using Qt-4.1.3.

It works fine.

Just a suggestion : since libedyuk is not a plugin, we have to set DYLD_LIBRARY_PATH to launch edyuk. Maybe this could be enhanced ...

fullmetalcoder
13th June 2006, 14:14
Before your second post I checked the code out and compiled it on MacOSX using Qt-4.1.3.

It works fine.

Nice to hear such a comment! Did you tried openning a file or a project ? I'm asking this because people on the french forum told me it crashed... I guess they have a problem with the defaut plugin but I can't see what's wrong...



Just a suggestion : since libedyuk is not a plugin, we have to set DYLD_LIBRARY_PATH to launch edyuk. Maybe this could be enhanced ...

you mean that, in the edyk launch script, I should replace the line :

LD_LIBRARY_PATh=$path:$LD_LIBRARY_PATH
by

DYLD_LIBRARY_PATh=$path:$DYLD_LIBRARY_PATH
Then I'll do it but I'll need either 2 separate scripts (would be ugly) either a way to detect the OS from the script...
Any ideas on how to do that?

wysota
13th June 2006, 14:18
Then I'll do it but I'll need either 2 separate scripts (would be ugly) either a way to detect the OS from the script...
Any ideas on how to do that?

Set both.


LD_LIBRARY_PATh=$path:$LD_LIBRARY_PATH \
DYLD_LIBRARY_PATh=$path:$DYLD_LIBRARY_PATH \
./binary

fullmetalcoder
13th June 2006, 14:20
Yaeh! That would work as well and that would certainly be simpler than cecking for the OS. Stupid me!:rolleyes:

jwintz
13th June 2006, 14:45
I just remind that applications on mac are bundles and you have to launch it using the "open" command.

$> export DYLD_LIBRARY_PATH ....
$> open edyuk.bin.app

or ...

$> ./edyuk.bin.app/Content/MacOS/edyuk.bin

The last solution is easier to embed in the script but it is not the apple recommandation for opening an application.

Therefor I advise you to use the otool and install_name_tool command in order to embed frameworks into the application bundle. This could be done using a script ....

More informations can be found at http://doc.trolltech.com/4.1/deployment-mac.html.

fullmetalcoder
13th June 2006, 14:51
I just remind that applications on mac are bundles and you have to launch it using the "open" command.

$> export DYLD_LIBRARY_PATH ....
$> open edyuk.bin.app

or ...

$> ./edyuk.bin.app/Content/MacOS/edyuk.bin

The last solution is easier to embed in the script but it is not the apple recommandation for opening an application.

Therefor I advise you to use the otool and install_name_tool command in order to embed frameworks into the application bundle. This could be done using a script ....

More informations can be found at http://doc.trolltech.com/4.1/deployment-mac.html (http://doc.trolltech.com/4.1/deployment-mac.html.[/quote)


Bunch of information! Maybe too much... I guess I'll follow the simplest way since I can't test any other : disabling bundles unless someone offers to take care of that aspect...

jwintz
13th June 2006, 14:59
I don't think you should do that ... The simple option would be a script edyuk_macx with export and open. Then, for each file release, you should build bundle embedding all libraries using otool and install_name_tool.

Persons checking your trunk out know how to launch edyuk without any script whereas final users just wanna drag and drop edyuk into their application folders or wherever else. This is why each release should be correctly packed the way it is mentionned in the deployment documentation and proposed in the forge file release system. Preparing the bundle is just a question of 5 minutes ...

fullmetalcoder
13th June 2006, 15:11
Preparing the bundle is just a question of 5 minutes ...
It may be true for a mac user but a poor guy like me that has only Fedora Core 5 and Window$ ME installed on his PC will never manage to bundle anything and that's why I'm looking for someone else to care about that... Or I'll just drop the bundle stuff...

jwintz
13th June 2006, 15:19
No problem ! You just can't do that since you don't have a mac available but I or anyone having a mac can type these five lines for you when you whenever you decide a new release ...

I mean preparing the bundle consists in :
- svn update
- qmake
- make
- otool .... (several times)
- install_name_tool (several times)

And that's it ! As for development, don't change anything it's just fine since the two last steps are just for mac.

I'm gonna check this out soon when releasing the first version of my own software and I think at this time i'll try to make this automatic using qmake possibilities. I'll let you know ...

fullmetalcoder
13th June 2006, 15:22
Thank you! Would be good to be able to automatize it through Mac. I think you can do something with custom functions but I haven't looked at that yet so I can't help you... Reading qmake docs should bring you an answer...

fullmetalcoder
4th July 2006, 11:04
Hi all,

version 0.4.2 is out!!!
SVN trunk has been updated and packages are no availables through Sourceforge release system. Go check out (http://sourceforge.net/project/showfiles.php?group_id=168260)!

Hope you'll like it even if compiling is not implemented yet... :)

P.S : If a crash occures when you try to open a file please send me a bug report with complete system specs! This is a "well-know" bug that seems to happen only on Window$ XP with certain versions of Qt so I can't fix it... I've submitted a bug report to Trolltech but they didn't find any bug thelmselves... It's driving me mad!:(

ChristianEhrlicher
4th July 2006, 14:16
I can't compile default plugin because of edyuk_plugin_main.cpp



$HEADER$

#include "main.h"


$PLUGIN_NAME$::$PLUGIN_NAME$()
: QObject(0)
{
;
}
...


msvc doesn't like this.

fullmetalcoder
4th July 2006, 17:35
I can't compile default plugin because of edyuk_plugin_main.cpp

What are you talking about? This file is a template !!!:p
It's not part of default plugin source... It's just data whose variables designed by two $ will be filled later on when the user wants to create a new file/project...

Was it included in the project (I don't think so..), did you added it yourself or did something weirder occured?:confused:

ChristianEhrlicher
4th July 2006, 18:04
I thought that this is a template but as qmake build a vcproj from it and the main pro-file also seemed to use it - it build a vs-solution *with* them) I thought it is maybe needed. Also your program crashed because no default plugin was found and as the project was named 'default' I used it...

fullmetalcoder
4th July 2006, 18:18
I thought that this is a template but as qmake build a vcproj from it and the main pro-file also seemed to use it - it build a vs-solution *with* them) I thought it is maybe needed. Also your program crashed because no default plugin was found and as the project was named 'default' I used it...

You're confusing me... I've just checked the src/default/default.pro file and as expected, I didn't found any occurence of the template files...

What exactly did you do? There is no way for the templates to be processed by qmake except if you stupidly called "qmake -project" while there are already project files... If you generate *.vcproj , normally qmake should work well with subdirs so you'd only need to create two of them:

edyuk (core library, executable and default plugin) : edyuk.pro
[optionnal] examples (stub-plugin) : examples/examples.pro
If subdirs aren't properly handled (I've heard that qmake bundled with 4.2 preview has troubles with them...) there are only 3 projects to create, using qmake to convert *.pro to *.vcproj and not to create anything else :

core library : src/lib/lib.pro
executable : src/exec/exec.pro
default plugin : src/default/default.pro
[optionnal] example plugin : examples/stub-plugin/stub-plugin.pro
Edyuk won't crash if there are no default plugin but if no plugins are found it will abort using qFatal()...

elcuco
4th July 2006, 18:51
I am experiencing crashes on this application since day one. I decided to look it up, and here is what I found so far:

int DevText::column(const QTextCursor& c)
for some reason the tab size was set to "0" on my setup. the code divides by the size of the tab.

I deleted the configuration on my system, and I managed to reproduce the same problem.

I would like to say, that I am strongly (un)impressed by the long compilation times. For example, on My gcc 4.01, AMD 2500, 512MB it takes 12m1.207s to build against Qt 4.1.4.

ChristianEhrlicher
6th July 2006, 10:02
I now used nmake generator and all works fine. I only got some warnings (http://msdn2.microsoft.com/en-us/library/695x5bes.aspx) at
blockdata.h:48
highlghterinterface.h:25
devdock.h:28
devperspective.h:30

This seems to be a popular warning when compiling apps created with gcc (I found a lot of them during kdelibs4 compile).

It started without crashing but got a crash when I wanted to close a source file.

I should take a look on my vcproj generator why it failed. One thing I noticed is that vs don't like two projects with the same name as you have with edyuk.exe and edyuk.dll.

fullmetalcoder
8th July 2006, 09:21
It started without crashing but got a crash when I wanted to close a source file.
A crash when closing a source file but not when openning it? That's a new issue!!! Could you give more precision?


I am experiencing crashes on this application since day one
More precision about crashe(s) that you encoutered with this version?


int DevText::column(const QTextCursor& c)
for some reason the tab size was set to "0" on my setup. the code divides by the size of the tab.
Thanks for that report elcuco. I'll fix it.


I would like to say, that I am strongly (un)impressed by the long compilation times. For example, on My gcc 4.01, AMD 2500, 512MB it takes 12m1.207s to build against Qt 4.1.4.
And maybe you have some magic tricks to make g++ compile OOP, especially with Qt meta data, faster??? :p

elcuco
8th July 2006, 12:56
Here are some of my tips, feel free to ignore them ;) :


The problems you have need to be addressed by just using the correct includes, and refactoring the whole code.

Doxygen has an option to generate the includes for each file. You will see that almost-everything-includes-almost-everything on your project.
You can also generate UML diagrams to understand the project "from above". This will help you the refactoring.

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)

The directory structure is very hard to comprehend.

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?)

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.

fullmetalcoder
8th July 2006, 14:52
Here are some of my tips, feel free to ignore them ;) :

The problems you have need to be addressed by just using the correct includes, and refactoring the whole code.
Doxygen has an option to generate the includes for each file. You will see that almost-everything-includes-almost-everything on your project.
You can also generate UML diagrams to understand the project "from above". This will help you the refactoring.
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)
The directory structure is very hard to comprehend.
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?)
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.

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???
Not true, but anyway... is it a problem that all components of an app are deeply linked?
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...
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...
Is it? where do the difficulties start? It seemed quite logical to me but if you have a better proposition my hears are openned.
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...)
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?

elcuco
8th July 2006, 15:04
"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.

fullmetalcoder
8th July 2006, 15:12
"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 releaseAll 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 ;) )

firas
9th July 2006, 04:55
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

fullmetalcoder
9th July 2006, 20:54
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.

ChristianEhrlicher
11th July 2006, 08:35
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:



devtranslator.cpp:235
// QEvent e(QEvent::Type(DevApp::RunTimeTranslation));
QEvent e((QEvent::Type)DevApp::RunTimeTranslation);

cppmatcher.cpp:408
// if (!bd->couldCollapse || !bd->collapsedLines.size() > 0)
if (!bd->couldCollapse || !(bd->collapsedLines.size() > 0))

pluginsystem.h:
move Q_DECL_DLLEXPORT before QObject* / void
extern "C" Q_DECL_EXPORT QObject* EDYUK_PLUGIN_INSTANCE_SYMBOL(QObject *o) \

fullmetalcoder
13th July 2006, 16:00
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...



/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

This warning message isn't relevant... Can you give a more complete log?



And here the changes I had to made:



devtranslator.cpp:235
// QEvent e(QEvent::Type(DevApp::RunTimeTranslation));
QEvent e((QEvent::Type)DevApp::RunTimeTranslation);

cppmatcher.cpp:408
// if (!bd->couldCollapse || !bd->collapsedLines.size() > 0)
if (!bd->couldCollapse || !(bd->collapsedLines.size() > 0))

pluginsystem.h:
move Q_DECL_DLLEXPORT before QObject* / void
extern "C" Q_DECL_EXPORT QObject* EDYUK_PLUGIN_INSTANCE_SYMBOL(QObject *o) \


Looks like MSVC sucks... :p I'll change that!

ChristianEhrlicher
13th July 2006, 16:24
I've changed


pCompilerOutput = new DevCompilerOutput(compiler);
compiler->addTab(pCompilerOutput, tr("Errors"));

to


pCompilerOutput = new DevCompilerOutput;
compiler->addTab(pCompilerOutput, tr("Errors"));


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

fullmetalcoder
14th July 2006, 17:27
I've changed


pCompilerOutput = new DevCompilerOutput(compiler);
compiler->addTab(pCompilerOutput, tr("Errors"));
to


pCompilerOutput = new DevCompilerOutput;
compiler->addTab(pCompilerOutput, tr("Errors"));

and now it starts

Can't believe it! A misparenting shouldn't cause a crash... I've fixed it anyway.


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...)

:)

fullmetalcoder
15th July 2006, 16:17
I've updated the SVN trunk to 0.5.1,

:o
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. :)



I'll put pre-release packages on Sf.net ASAP.

Done as well. I'm waiting for some feedback... ;)



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 :confused:
what do you think of the changes I've made to qmdilib so as to integrate run-time translation and "document" support in it ???

elcuco
15th July 2006, 19:09
@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/qtextedit.html#tabStopWidth-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.

wysota
16th July 2006, 04:14
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).

fullmetalcoder
16th July 2006, 20:56
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...



I am not sure what do you mean by "tab stop", do you mean this?
http://doc.trolltech.com/4.1/qtexted...StopWidth-prop (http://doc.trolltech.com/4.1/qtextedit.html#tabStopWidth-prop)

I meant tab size... The thing that make Edyuk crash on your PC because of a division by 0...



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... :p).
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???

elcuco
16th July 2006, 21:47
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).

wysota
16th July 2006, 23:34
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.

fullmetalcoder
18th July 2006, 10:07
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!



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 ... :mad:



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!:)



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? ;)

wysota
18th July 2006, 10:59
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 ... :mad:
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

elcuco
18th July 2006, 19:04
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).



diff . ~/src/svn/qtedit4/tools/qmdilib/src/ -ru | less


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:


We use different indentations. This is why the diff is so big, but the code is not that different (sometimes)
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).
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:

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.
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.
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/developers-reference/ch-best-pkging-practices.en.html#s-multiple-patches

fullmetalcoder
19th July 2006, 19:12
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.
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.
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'll have a look...
qmdiActionGroupList checks each qmdiActionGroup for modification before updating toolbars... What's so difficult?
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...

krawek
10th August 2006, 00:58
Hi,

I send you a patch for DevApp

fullmetalcoder
23rd August 2006, 18:21
I should have done it 3 weeks ago but my poor network connection and then holidays prevented me from uploading last Edyuk version on Sf.net. Anyway it's done now. Edyuk 0.5.1 is available and among the most noticeable changes an install target (for Unix) and a binary installer (for M$ Window$) have been added. BTW if anyone is willing to craft a Mac bundle he is welcome.

Next version is already on rails :
- A complete rewrite of the editor is on work and will BTW be released separately as QCodeEdit
- Designer integration will be added and for this I need feedback : Shall I create a special "Designer perspective" or can I simply add dock widgets to the already existing C++ perspective of the default plugin???
- Debugging engine will be implemented and the default plugin will provide a wrapper for GDB


I send you a patch for DevApp
Sorry but I'm quite puzzled... What is the point of this patch???

sector
23rd August 2006, 23:16
Hi,

I tried to compile on win2000, mingw, Qt4.2.0-tp1, if I run it gives Segmentation fault. Recompiled in debug mode, here is backtrace, maybe it'll be useful for you. Problem seems to be with loading plugins.

See attachement.

krawek
23rd August 2006, 23:26
Sorry but I'm quite puzzled... What is the point of this patch???
It solves a common error, the patch change:

static DevApp* Init(int argc, char **argv); -> static DevApp* Init(int &argc, char **argv);

and

DevApp(int argc, char **argv); -> DevApp(int &argc, char **argv);


and fix a potencial crash in your application


cheers

fullmetalcoder
24th August 2006, 12:44
I tried to compile on win2000, mingw, Qt4.2.0-tp1, if I run it gives Segmentation fault. Recompiled in debug mode, here is backtrace, maybe it'll be useful for you. Problem seems to be with loading plugins.

Never seen something like this... What was the last message on the splash screen?


It solves a common error, the patch change
I saw what the patch changed but I didn't know it was a common error... I'll change that but I'd like to know where the potential crash occurs?

krawek
24th August 2006, 15:32
I saw what the patch changed but I didn't know it was a common error... I'll change that but I'd like to know where the potential crash occurs?

I get this with the last qt 4.2 snapshot:



krawek trunk # LD_LIBRARY_PATH=. gdb -ex run -ex bt --batch ./edyuk.bin
Using host libthread_db library "/lib/tls/libthread_db.so.1".
[Thread debugging using libthread_db enabled]
[New Thread 47644403135520 (LWP 15420)]
[New Thread 1082132832 (LWP 15423)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 47644403135520 (LWP 15420)]
0x00002b55129b03f8 in QString::fromLocal8Bit (
str=0x10 <Address 0x10 out of bounds>, size=-1) at qstring.cpp:3287
3287 if (size == 0 || (!*str && size < 0))
Current language: auto; currently c++
#0 0x00002b55129b03f8 in QString::fromLocal8Bit (
str=0x10 <Address 0x10 out of bounds>, size=-1) at qstring.cpp:3287
#1 0x00002b5512a1f3ad in QCoreApplication::arguments () at qstringlist.h:66
#2 0x00002b551134f975 in sm_performSaveYourself (smd=0x6416b0)
at qcoreapplication.h:74
#3 0x00002b55113502a6 in sm_saveYourselfCallback (smcConn=0x7fffffd96670,
clientData=0x10, saveType=-1, shutdown=7231952, interactStyle=67)
at qapplication_x11.cpp:4675
#4 0x00002b5511b1d317 in _SmcProcessMessage () from /usr/lib/libSM.so.6
#5 0x00002b5511c2b3af in IceProcessMessages () from /usr/lib/libICE.so.6
#6 0x00002b5511341341 in QSmSocketReceiver::qt_metacall (this=0x63ffa0,
_c=QMetaObject::InvokeMetaMethod, _id=-1, _a=0x7fffffd97250)
at qapplication_x11.moc:63
#7 0x00002b5512a2d0c9 in QMetaObject::activate (sender=0x642800,
from_signal_index=4, to_signal_index=4, argv=0x7fffffd97250)
at qobject.cpp:2911
#8 0x00002b5512a49bae in QSocketNotifier::activated (this=0x7fffffd96670,
_t1=11) at moc_qsocketnotifier.cpp:79
#9 0x00002b5512a342ab in QSocketNotifier::event (this=0x642800,
e=0x7fffffd97780) at qsocketnotifier.cpp:276
#10 0x00002b55112f99f8 in QApplicationPrivate::notify_helper (this=0x50cf20,
receiver=0x642800, e=0x7fffffd97780) at qapplication.cpp:3430
#11 0x00002b55112f9bee in QApplication::notify (this=0x50cf00,
receiver=0x642800, e=0x7fffffd97780) at qapplication.cpp:3371
#12 0x00002b5512a3db9b in socketNotifierSourceDispatch (source=0x50ee30)
at qcoreapplication.h:180
#13 0x00002b5512cf8486 in g_main_context_dispatch ()
from /usr/lib/libglib-2.0.so.0
#14 0x00002b5512cf9ea8 in g_main_context_acquire ()
from /usr/lib/libglib-2.0.so.0
#15 0x00002b5512cfa36f in g_main_context_iteration ()
from /usr/lib/libglib-2.0.so.0
#16 0x00002b5512a3d9d0 in QEventDispatcherGlib::processEvents (
this=0x50d5b0, flags={i = 20}) at qeventdispatcher_glib.cpp:351
#17 0x00002b551136de29 in QGuiEventDispatcherGlib::processEvents (
this=0x7fffffd96670, flags=) at qglobal.h:1610
#18 0x00002b5512a1d2de in QEventLoop::processEvents (this=0x7fffffd96670,
flags=) at qglobal.h:1610
#19 0x00002b5512a1d490 in QEventLoop::exec (this=0x7fffffd97980, flags=
{i = 0}) at qglobal.h:1627
#20 0x00002b5512a216ea in QCoreApplication::exec () at qglobal.h:1611
#21 0x00000000004008d8 in main ()

sector
24th August 2006, 16:36
Last scene before segfault says: "Initializing plugins..."

fullmetalcoder
26th August 2006, 10:13
I get this with the last qt 4.2 snapshot:



krawek trunk # LD_LIBRARY_PATH=. gdb -ex run -ex bt --batch ./edyuk.bin
Using host libthread_db library "/lib/tls/libthread_db.so.1".
[Thread debugging using libthread_db enabled]
[New Thread 47644403135520 (LWP 15420)]
[New Thread 1082132832 (LWP 15423)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 47644403135520 (LWP 15420)]
0x00002b55129b03f8 in QString::fromLocal8Bit (
str=0x10 <Address 0x10 out of bounds>, size=-1) at qstring.cpp:3287
3287 if (size == 0 || (!*str && size < 0))
Current language: auto; currently c++
#0 0x00002b55129b03f8 in QString::fromLocal8Bit (
str=0x10 <Address 0x10 out of bounds>, size=-1) at qstring.cpp:3287
#1 0x00002b5512a1f3ad in QCoreApplication::arguments () at qstringlist.h:66
#2 0x00002b551134f975 in sm_performSaveYourself (smd=0x6416b0)
at qcoreapplication.h:74
#3 0x00002b55113502a6 in sm_saveYourselfCallback (smcConn=0x7fffffd96670,
clientData=0x10, saveType=-1, shutdown=7231952, interactStyle=67)
at qapplication_x11.cpp:4675
#4 0x00002b5511b1d317 in _SmcProcessMessage () from /usr/lib/libSM.so.6
#5 0x00002b5511c2b3af in IceProcessMessages () from /usr/lib/libICE.so.6
#6 0x00002b5511341341 in QSmSocketReceiver::qt_metacall (this=0x63ffa0,
_c=QMetaObject::InvokeMetaMethod, _id=-1, _a=0x7fffffd97250)
at qapplication_x11.moc:63
#7 0x00002b5512a2d0c9 in QMetaObject::activate (sender=0x642800,
from_signal_index=4, to_signal_index=4, argv=0x7fffffd97250)
at qobject.cpp:2911
#8 0x00002b5512a49bae in QSocketNotifier::activated (this=0x7fffffd96670,
_t1=11) at moc_qsocketnotifier.cpp:79
#9 0x00002b5512a342ab in QSocketNotifier::event (this=0x642800,
e=0x7fffffd97780) at qsocketnotifier.cpp:276
#10 0x00002b55112f99f8 in QApplicationPrivate::notify_helper (this=0x50cf20,
receiver=0x642800, e=0x7fffffd97780) at qapplication.cpp:3430
#11 0x00002b55112f9bee in QApplication::notify (this=0x50cf00,
receiver=0x642800, e=0x7fffffd97780) at qapplication.cpp:3371
#12 0x00002b5512a3db9b in socketNotifierSourceDispatch (source=0x50ee30)
at qcoreapplication.h:180
#13 0x00002b5512cf8486 in g_main_context_dispatch ()
from /usr/lib/libglib-2.0.so.0
#14 0x00002b5512cf9ea8 in g_main_context_acquire ()
from /usr/lib/libglib-2.0.so.0
#15 0x00002b5512cfa36f in g_main_context_iteration ()
from /usr/lib/libglib-2.0.so.0
#16 0x00002b5512a3d9d0 in QEventDispatcherGlib::processEvents (
this=0x50d5b0, flags={i = 20}) at qeventdispatcher_glib.cpp:351
#17 0x00002b551136de29 in QGuiEventDispatcherGlib::processEvents (
this=0x7fffffd96670, flags=) at qglobal.h:1610
#18 0x00002b5512a1d2de in QEventLoop::processEvents (this=0x7fffffd96670,
flags=) at qglobal.h:1610
#19 0x00002b5512a1d490 in QEventLoop::exec (this=0x7fffffd97980, flags=
{i = 0}) at qglobal.h:1627
#20 0x00002b5512a216ea in QCoreApplication::exec () at qglobal.h:1611
#21 0x00000000004008d8 in main ()
And the reference stuff fixed it??? Thanks a lot then! I wouldn't have understood how to fix such a backtrace...

@sector :
Are you using precompiled binaries for windows ?
Did you try krawek patch ?

vratojr
29th August 2006, 17:25
Hi,i tryed to complile Eduyk on my computer (AMD Athlon 64 with Suse 10.1) and I got this error:

g++ -c -include ../tmp/obj/lib/unix/debug/edyuk_debug -m64 -pipe -g -D_REENTRANT -Wall -W -fPIC -D_DEV_BUILD_ -D_DEV_DEBUG_ -D_QMDI_BUILD_ -DQT_XML_LIB -DQT_GUI_LIB -DQT_CORE_LIB -DQT_SHARED -I/usr/local/Trolltech/Qt-4.1.4/mkspecs/linux-g++-64 -I. -I/usr/local/Trolltech/Qt-4.1.4/include/QtCore -I/usr/local/Trolltech/Qt-4.1.4/include/QtGui -I/usr/local/Trolltech/Qt-4.1.4/include/QtXml -I/usr/local/Trolltech/Qt-4.1.4/include -I. -Icompiler -Ieditor -Igui -Imdi -Iplugin -Isettings -Iui -Iworkspace -Iutil -I../tmp/moc -I../tmp/ui -o ../tmp/obj/lib/unix/debug/devworkspace.o workspace/devworkspace.cpp
workspace/devworkspace.cpp: In member function ‘void DevWorkspace::coreChanged(CorePlugin*)’:
workspace/devworkspace.cpp:697: error: cast from ‘CorePlugin*’ to ‘int’ loses precision
make[2]: *** [../tmp/obj/lib/unix/debug/devworkspace.o] Error 1
make[2]: Leaving directory `/home/vratojr/Download/edyuk-0.5.1/src/lib'
make[1]: *** [debug-all] Error 2
make[1]: Leaving directory `/home/vratojr/Download/edyuk-0.5.1/src/lib'
make: *** [sub-src-lib-make_default] Error 2


?

Oh I compiled it succesfully on window XP (not 64 version) run with VMWare but it doesn't start. Il loads a bit (i see the splashscreen) and the crashes.It says something like: 'The istruction "<hexnumbers>" referred to the memory locatio "<hex>". The memory couldn't be "read"'

fnmblot
29th August 2006, 21:43
Oh I compiled it succesfully on window XP (not 64 version) run with VMWare but it doesn't start. Il loads a bit (i see the splashscreen) and the crashes.It says something like: 'The istruction "<hexnumbers>" referred to the memory locatio "<hex>". The memory couldn't be "read"'
I have the exact same issue on Windows XP. :( It compiles with no problem.

fnmblot

fullmetalcoder
30th August 2006, 10:22
Hi,i tryed to complile Eduyk on my computer (AMD Athlon 64 with Suse 10.1) and I got this error:
?

You're compiling in debug mode : a qDebug() is used to output the address of the core plugin currently used and a "classic C cast" is used : (int)pointer.

This doesn't occur under win, whatever your CPU because debug build is disabled by default. I don't know why it causes an error and not a warning but you can get rid of it by changing the config.pri file:

replace :

win32:CONFIG += release
else:CONFIG += debug_and_release
by :

win32:CONFIG += release
else:CONFIG += release

If you happen to know how to fix the cast error please let me know...



Oh I compiled it succesfully on window XP (not 64 version) run with VMWare but it doesn't start. Il loads a bit (i see the splashscreen) and the crashes.It says something like: 'The istruction "<hexnumbers>" referred to the memory locatio "<hex>". The memory couldn't be "read"'
If you are using Qt 4.2 you should try krawek patch, otherwise I don't see what's wrong but try the patch anyway...

Sorry, I couldn't test under Qt 4.2 :o

ksqt
30th August 2006, 16:59
I downloaded the latest edyuk.exe and ran the installer. When I try to run the program, I only get a splash screen, and it disappears, and no more.....
Is there something I am supposed to do, or am I missing something?

Win XP

vratojr
31st August 2006, 13:33
If you are using Qt 4.2 you should try krawek patch, otherwise I don't see what's wrong but try the patch anyway...
Sorry, I couldn't test under Qt 4.2 :o

Hrmm no, it's Qt 4.1.3 under windows and 4.1.4 under Linux.

vratojr
31st August 2006, 16:35
You're compiling in debug mode : a qDebug() is used to output the address of the core plugin currently used and a "classic C cast" is used : (int)pointer.
If you happen to know how to fix the cast error please let me know...


It seems that you have to change the cast to long int. I have a 64bit computer, so a qint64 would be enough!;)
It works but I fear that u have to change all the other casts ....:(
Or maybe u can wait that I DO want to take a look at Edyuk (compiled in debug mode) and do all the changes myself!;)

ksqt
1st September 2006, 22:11
I downloaded the latest edyuk.exe and ran the installer. When I try to run the program, I only get a splash screen, and it disappears, and no more.....
Is there something I am supposed to do, or am I missing something?

Win XP

Anybody else with this issue?

fullmetalcoder
2nd September 2006, 09:58
Hrmm no, it's Qt 4.1.3 under windows and 4.1.4 under Linux.
And both crash? I do use the same versions of Qt and Fedora Core 5 and Windows ME are OK... Try the patch anyway and see if it solves it...



It seems that you have to change the cast to long int. I have a 64bit computer, so a qint64 would be enough!;)
It works but I fear that u have to change all the other casts ....:(
Or maybe u can wait that I DO want to take a look at Edyuk (compiled in debug mode) and do all the changes myself!;)

I guess I will remove the cast... Or maybe I can wait that you had a look at the latest version (0.6.0 beta, available on SVN) cause after that you WILL want to take a look at Edyuk ;) :

Perspective system
The best editing framework ever seen
Compilation (only gcc but you can extend it to any compiler through plugins)
Full Qt Designer Integration
Run-time translation
Dynamic shortcuts (language-aware)
and more...:D

ksqt
3rd September 2006, 02:38
Anybody else with this issue?

Also tried downloading the zip source, built just fine, but when running "edyuk.exe" I only get splash screen, and it disappears.....nothing else.....:eek: