1 Attachment(s)
Re: The return of the king!
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... :)
Re: The return of the king!
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 ...
Re: The return of the king!
Quote:
Originally Posted by jwintz
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...
Quote:
Originally Posted by jwintz
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 :
Code:
LD_LIBRARY_PATh=$path:$LD_LIBRARY_PATH
by
Code:
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?
Re: The return of the king!
Quote:
Originally Posted by fullmetalcoder
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.
Code:
LD_LIBRARY_PATh=$path:$LD_LIBRARY_PATH \
DYLD_LIBRARY_PATh=$path:$DYLD_LIBRARY_PATH \
./binary
Re: The return of the king!
Yaeh! That would work as well and that would certainly be simpler than cecking for the OS. Stupid me!:rolleyes:
Re: The return of the king!
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.
Re: The return of the king!
Quote:
Originally Posted by jwintz
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
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...
Re: The return of the king!
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 ...
Re: The return of the king!
Quote:
Originally Posted by jwintz
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...
Re: The return of the king!
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 ...
Re: The return of the king!
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...
Re: The return of the king!
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!
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!:(
Re: The return of the king!
I can't compile default plugin because of edyuk_plugin_main.cpp
Code:
$HEADER$
#include "main.h"
$PLUGIN_NAME$::$PLUGIN_NAME$()
{
;
}
...
msvc doesn't like this.
Re: The return of the king!
Quote:
Originally Posted by ChristianEhrlicher
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:
Re: The return of the king!
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...
Re: The return of the king!
Quote:
Originally Posted by ChristianEhrlicher
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()...
Re: The return of the king!
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.
Re: The return of the king!
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.
Re: The return of the king!
Quote:
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?
Quote:
I am experiencing crashes on this application since day one
More precision about crashe(s) that you encoutered with this version?
Quote:
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.
Quote:
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