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

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

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

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

some little error must be: 3dparty/qprojectmodel/qprojectparser.h: <quote> /**************************************************************************** ** ** Created using Edyuk IDE 0.8.0-rc1 ** ** File : qprojectparser.h ** Date : Sun Feb 11 13:44:47 2007 ** ** This file is provided AS IS with NO WARRANTY OF ANY KIND, INCLUDING THE ** WARRANTY OF DESIGN, MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. ** ****************************************************************************/ #ifndef _QPROJECT_PARSER_H_ #define _QPROJECT_PARSER_H_ #define QT_NO_QOBJECT_CHECK 1 #include "qproject.h" </quote>

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)

in first varian path to header was inserted just in code... #define QT_NO_QOBJECT_CHECK 1 will disable additional qobject check in kernel module monkeystudio builded properly with this definition too. about translation: i'll make new translation for 0.9.1 tonight and send to you.

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

qdevelop for example has the ability to automatically lupdate translations are specified in .pro it's simplest way i guess. or i missing somewhat? what you have to fix manually in regenerated .ts files?

or you mean .pri files included in project file? i can regenerate untranslated.ts with lupdate 4.3 and send it to your email before i lost my time to make new ru_RU translation. check it plz and/if it was regenerated properly I can continue at leisure

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

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.

again and again... ../../3rdparty/qprojectmodel/qprojectparser.h: In member function `void QProject Parser::qt_check_for_QOBJECT_macro(const T&) const [with T = QMakeParser]': ../../../Qt/4.3.0rc1/include/QtCore/../../src/corelib/kernel/qobject.h:411: in stantiated from `T qobject_cast(QObject*) [with T = QMakeParser*]' qmakemodel/qmakevariable.cpp:654: instantiated from here ../../3rdparty/qprojectmodel/qprojectparser.h:36: error: void value not ignored as it ought to be now i use QT-4.3.0 (stable), gcc-3.4.5, make-3.81, edyuk-0.9.1

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

I have solved the problem of compiling under windows! I think. Monkeystudio had a similar problem; it is described in detail here (though in french): http://forum.qtfr.org/viewtopic.php?pid=23815 To put it simply, with Monkey Studio, the complaint was about qsyntaxhighlighter because cppSyntaxHighlighter inherited from it, and was missing a Q_OBJECT after its definition (not sure if my vocabulary is right here). With Edyuk, a similar issue arises between QMakeParser and QProjectParser. Changing the code as follows in qmakeparser.h: Quote:

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

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.