The return of the king!

[fullmetalcoder]

Yaeh! That would work as well and that would certainly be simpler than cecking for the OS. Stupid me!

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

[fullmetalcoder]

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

[jwintz]

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]

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]

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]

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]

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!

[ChristianEhrlicher]

I can't compile default plugin because of edyuk_plugin_main.cpp

$HEADER$
 
#include "main.h"
 
 
$PLUGIN_NAME$::$PLUGIN_NAME$()
 : QObject(0)
{
	;
}
...

$HEADER$

#include "main.h"


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

To copy to clipboard, switch view to plain text mode 

msvc doesn't like this.

[fullmetalcoder]

I can't compile default plugin because of edyuk_plugin_main.cpp

What are you talking about? This file is a template !!!
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?

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

[fullmetalcoder]

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]

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.