Image 01
profile-image

fullmetalcoder

fullmetal coder , France
Developers Apps
Text Editors
Edyuk

Developers Apps 27 comments

Score 50.0%
Jul 20 2009
So you confirm that my proposed fix did the trick? Neat! At last Edyuk now compiles on the three major platforms supported by Qt 4 :D

If you have some more feedback I'd suggest that you use the the mailing list, my e-mail address or the tracker (as indicated in the README) because I do not visit qt-apps.org often and I might miss your post...

cheers

fullmetalcoder - Mar 23 2008
Nice to hear that it works under Mac as I myself can't test it on this platform. As for the changes needed to get it compiled I think the best solution would be to prevent the creation of the bundle as qplugin_generator is a command line application... I thought I have done this in the last development version but it looks like it hadn't been done when I had released the rc1.

I'd like to know if the following line successfully prevent bundle creation and make Edyuk compile without your proposed fix. :
CONFIG -= app_bundle

(to add in src/exec/exec.pro)

regards

fullmetalcoder
- Mar 20 2008
This tricky bug has been solved on SVN. Update your working copy and it should vanish...

cheers

fullmetalcoder

p.s. : after some SVN updates a make clean may be needed since qmake fails to achieve proper dependency tracking for the plugins. Rarely, a settings cleanup can also help (settings are located in $HOME/.Edyuk-<Edyuk version>/ )

- Aug 22 2007
The deserialization of Qt tag files was wrong in the old code (or rather : this file was badly filled since completion backend failed to locate Qt headers due to a specific quirk under Windows and loading of a corrupted tag file caused a crash. All these issues should have been solved in both the trunk and the 0.9.2 version.

cheers

fullmetalcoder
- Aug 22 2007
I'm afraid I just can't fix anything with as little informations... Please get the SVN HEAD revision of http://edyuk.svn.sf.net/svnroot/edyuk/trunk/ compile it (if possible in debug mode) run it under gdb ( LD_LIBRARY_PATH=. gdb edyuk.bin ) and send me a backtrace if it still crashes...

cheers

fullmetalcoder
- Aug 22 2007
lol!
well, it stands for FullMetalCoder...
some folks on QtCentre.org forums started shrinking my pseudo a while ago and I took the habit... - Jul 31 2007
This has been fixed by now... Yet another windows-specific problem : Qt headers are not "proper", they point to the sources using include directives, so the parsing of Qt headers leaves a blank tree which when saved leaves a malformed tag file which when re-loaded causes a segfault.

The last two issues (saving & re-loading) have been fixed (available on SVN) but the source of all these problems persists (and prevents code completion of Qt types from working properly BTW). I'm thinking about it... - Jul 31 2007
It has been reported and fixed but I can't release a newer package right now since another, slightly more annoying bug has been found : several ui files made with Qt Designer 4.3 won't work with earlier versions of uic...

If you however have Qt 4.3 installed and want to test the beta just do a SVN checkout... The code there should compile fine AFAIK...

cheers

fmc - Jul 30 2007
This is a real problem then... Please tell me which version of Qt and Edyuk you are using. Besides, it would be nice if you could send me a log. Also I suggest you try calling qmake a second time just between "make" and "make install". If none of these work please try the latest version available on SVN and feed me back.

fmc

P.S. : If you feel like sending more feedback and test results please consider using the mailing list at edyuk-devel@lists.sourceforge.net - May 02 2007
Are you sure that the files have been copied to /usr/edyuk ? Especially these should be present for Edyuk to run :

edyuk (shell script)
edyuk.bin (binary app)
libedyuk.so (+ symlinks, core library)

In case they have not been copied, tell me and I'll check the install target.

You can anyway run edyuk locally in the meantime by typing from the build directory :
$ ./edyuk - Apr 30 2007
Thanks for your interest and feedback! Don't worry, your bad rating should not kill me :) - Apr 12 2007
First of all I shall correct you : Edyuk 0.9.0-beta is explicitly marked as "unstable".

If you are using a Qt version prior to Qt 4.2 consider upgrading. Otherwise it would be good if you were a little more precise about the compilation problems you faced.

cheers

fmc - Apr 02 2007
Edyuk

Developers Apps 27 comments

Score 50.0%
Aug 28 2008
Thanks for your feedback. The project options dialog is known to have some problems and is thus being redesigned...

I'm afraid my knowledge of web development doesn't allow me to improve the site much (I'm using Joomla CMS) so I really don't know how I could improve the contact facilities for registered users...
However, my e-mail address, and the mailing list should be mentioned in the README so you should have been able to reach me anyway.

As for beta testing it's really simple. Just grab the content of the SVN trunk (you'll need subversion installed for this ) :
svn co http://edyuk.svn.sf.net/svnroot/edyuk/trunk/ edyuk

If you're interested in helping the development you're welcome! Send diffs/patches to the mailing list (edyuk-devel _AT_ lists _DOT_ sf _DOT_ net) and they'll be merged as soon as possible, unless they introduces new bugs/regressions... Then, if your contribution becomes too much for us to merge by hand you'll be granted SVN write access.

regards
- Nov 11 2007
The real problem behind binaries is that it needs someone with a static build of Qt 4... And that's not necessarily a good idea anyway because system libs used by Qt may vary from distro to distro, even in some minor way, and thus potentially cause API breaks...

I myself don't have a static build and my current distro refuses to let me build Qt by hand anyway (i.e. it provides Qt shared bins but every time I try to compile Qt from sources I end up with dozens of errors...)

If someday we find a guy willing to maintain linux bins (and that's true for mac & win bins as well) we'll welcome him and made these available through Sf.net dl servers (and also here ;))

regards

fullmetalcoder - Aug 31 2007
It definitely looks like qmake is called instead of qmake-qt4. I must admit I did not test this configuration option since I do not need it. As I can't fi it before a while (I'm not at home...) you have to options left : changing your env vars or fixing the code in charge of makefile generation (in src/default/makefilegenerator.cpp). A dirty fix (discarding conf options) would be enough for now if you don't feel like spending time on fixing the code properly... ;) - Jul 04 2007
Great! As you may have noticed we'd find another workaround (i.e disabling automated QObject check) but this is way better! Thanks for reporting :)

P.S : "Though in French"... Luckily I do speak French :) - Jun 07 2007
Yep... I meant pri files included within a project via "include()" function. And QDevelop won't help in handling that if your version of lupdate can't do it out-of-box.

However it seems that, since Qt-4.2.3, lupdate has gained the ability to handle include(), although lrelease still fails when it encounters this function...

As a consequence, your translations generated with lupdate from Qt 4.3 are OK. Yet, there are several entries that MUST be discarded : QShortcut context is handled by Qt's regular ts files.

When you'll create ts files use this command (from the top directory) :
$ lrelease translations/edyuk_ru.ts
$ lrelease translations/default_ru.ts

instead of :
$ lrelease src/lib/lib.pro
- Jun 03 2007
That's pretty kind of you but the main problem is that ts files have not been updated. This is mainly because I lack time (poor reason I admit) and lupdate does NOT support include() and thus fails to generate proper ts files when fed with a project file... Thus I need to fetch a file list, feed it to lupdate and then manually fix some entries within the generated file (mostly related to calling tr for Qt's object such as QShortcut::tr("Shift")...)

If Qt has fixed this bug (do they consider it as a bug?) in Qt 4.3 you may be able to re-generate ts files yourself. Otherwise I'll submit a bug to Trolltech because this is really get boring... And if they don't react fast enough I'll have to fix the code myself... :( - Jun 02 2007
It basically depends on what you mean by support...

By default, Edyuk is able to edit any source code. Highlighting, indenting, folding and parenthesis matching are availables if proper (generic, XML-based) language definitions are (default one being doxygen, C++, python and C# if I remember well). These definitions are very easy to write (and will be even easier in next version, already available in SVN though not fully functional).

The default plugin provided with Edyuk brings compilation, debugging and code completion for C++ only. Besides, the only supported project file is qmake's .pro

However, Edyuk can be extended in any way you wish by writing a C++ plugin...
- Jun 01 2007
OK great to see that you manage to patch this. :) However I do not notice any change between first and second patch... I guess that the QT_NO_QOBJECT_CHECK macro will do anyway.

About the russian translation : I got your mail and was convinced I answered it but my answer must have not been sent properly (or maybe my memory is just failing...). I'll thus say it here : translations are welcome! Just be aware that due to some internal changes not all sentences will be translated properly... You can send these translations to the mailing list (edyuk-devel AT lists DOT sf DOT net) or directly to me (fullmetalcoder AT hotmail DOT fr) - Jun 01 2007
That's not the same at all... What you showed is a purely Qt 4.3 specific error. I've just no idea why the qt_check_for_Q_OBJECT_macro function causes a compilation error but it at least shows that the core lib and the executable get compiled correctly since the error occurs in the qmake project parsing code. Or am I missing something?

Please send me the whole compile log (or at least all the error messages outputted by gcc. It would also be really kind of you to try tracking this error because, as I don't have neither a Windows box nor a Qt 4.3 installation it's gonna be hard for me to fix this on my own...
- May 31 2007
You must be running under windows... As I can't test Edyuk under this system, error sometimes show up...

To fix that you'll have to edit two files :

src/exec/main.cpp => remove the line
#include <QPool>

src/exec/exec.pro => remove the line
include(../../3rdparty/qpool/qpool.pri)

Doing this won't actually affect Edyuk behaviour because these lines were used to add a feature disabled for unstability reason...

Thank you for reporting this. I'll release a fixed archive ASAP. - May 28 2007
The default plugin only supports management of qmake projects and compilation/debugging of C++ application.

However, thanks to its plugin based architecture, it can be expanded in any way you like (provided that you're ready to spend some time writing a proper plugin in C++, of course ;) ). For instance someone contacted me to create a C# plugin . I haven't had news from hime since weeks but such a plugin might show up someday.

If writing a plugin is too hard for you, you can always write a syntax definitions for other languages so that highlighting/parenthesis matching/code folding and text indeting will work properly. - May 26 2007
Looks like you're using Qt 3... Edyuk is build with and designed for Qt 4. But it may also come from a dual-install of both versions... in this case be careful about the command that need to be used to call the proper version of qmake. On some distros it is qmake-qt4 on others it is qmake4... The simplest way to handle that is anyway to place the path to Qt4 binaries at the first place in your PATH variable by doing :

$ export PATH=/path/to/qt4:$PATH - Apr 06 2007
WebIssues Client

Developers Apps 10 comments

by mimec
Score 58.0%
Nov 12 2013
The problem is that I use a distro (Frugalware) which doesn't export Qt 4 paths/variables by default. This cause qmake itself to miserably fail unless I do a source /etc/profile.d/qt4.sh

Yet even doing this left CMake failing. I got an error on the first moc call which told me that invalid options/parameters had been passed.

Being unfamiliar with CMake I decided to write a qmake project. Your cmake architecture confused me at first but I finally managed to get it work by running "qmake -project" within src directory and then setting a few additional variables by hand in the generated .pro file (I can send it to you if you feel like adding support for qmake).

The config file is not a big issue... It's just something I mentionned because it might discourage some users, especially those who don't use a neat KDE text editor which allows on-the-fly editions of files over ftp... ;)

There are two things left to mention :
* I'd greatly appreciate some kind of notification mechanism (even a very simple one). For instance it would be great to know when connecting whether new issues have been added (which type and where...) since last connection. A great (and simple) way to highligt this would be colored icons and a status bar... Also colored icons indicating new comment/attachemnt/property change of an issues would be helpful
* I suggest you split your application in two : a lib handling the protocol and data representation + providing a set of widgets (no dialogs!), which could later be used to create plugins bringing WebIssues support in other apps such as IDEs, and a wrapper application which would link to it and organize widgets into a consistent UI. (I'm really interested in making a WebIssues plugin for Edyuk :) ) - May 31 2007
The soft sounds quite nice but...

1) Why the hell do you use CMake? Ok that's a stupid question... It's your choice but anyway please consider bundling a regular qmake project file (.pro) for everyone to be able to try your app (FYI I have cmake installed but it failed to build due to conflicts with my Qt installation and I had to write my own .pro files which wasn't a synch ...)
2) The web based setup is nice but what about providing a way to edit the config file through a simple webpage? Would have saved me some time...
3)CMake really sucks! Or at least it introduces a bad (i.e. not backward compatible with qmake) coding style : I was forced to write a shell script to comment out all occurrences of #include "some_file.moc"
4) Splitting your app into static libraries works with cmake but made me such a tough time porting the porjct files back to qmake...

OK that should be all for the cons by now... ;) I've set up the server and the client is now building smoothly so you'll get more feedback when I try it :)
- May 30 2007
PokerTH

Card 9 comments

by floty
Score 63.3%
Dec 23 2013
I've started playing poker with friends a while ago and this game is the first decent Texas Hold'em game I find on a computer!

I was just wondering if you planned to add some networking options which would make it so much funnier...

Keep up the good work anyway! :) - May 02 2007