On 4 October 2015 at 10:24, Manu <turkeyman@gmail.com> wrote:
> On 4 October 2015 at 10:09, Manu <turkeyman@gmail.com> wrote:
>> On 4 October 2015 at 02:43, Jeremy DeHaan via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>>> On Saturday, 3 October 2015 at 08:25:25 UTC, Manu wrote:
>>>>
>>>> On 3 October 2015 at 11:58, Jeremy DeHaan via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>>>>>
>>>>> I know a lot of people wish they had new bindings for Qt, so I was going
>>>>> to> give it a go soon. Is anyone currently working on such a thing? I'd
>>>>> rather
>>>>> help someone than compete with them.
>>>>
>>>>
>>>> I've spent about 2 weeks trying to get the latest Qt bound up... it's
>>>> a LOT of work, but I have done a fair bit of core stuff.
>>>> I can commit it somewhere if you wanna hack at it too...
>>>
>>>
>>> Yeah,that'd be great. I'm only interested in working on the latest Qt. You said two weeks and that's just been the core stuff. Are you doing the binding by hand?
>>
>> When I say 2 weeks, I don't mean like, full-time day-job type thing, just tinkering some nights.
>>
>> But yeah, by hand (ie, lots of regex-ing). It's hard to automate, but
>> an automated solution would surely be preferable, otherwise this will
>> be a maintenance nightmare.
>> The core stuff is the hardest bit, and requires the most manual
>> intervention. Sooooo many macros, and various platform abstractions.
>> The majority of feature headers may be automatable.
>>
>> The main thing I wanted to do with this binding was to eliminate moc. You shouldn't need to run moc; D can do that work right on the spot.
>
> Here: https://github.com/TurkeyMan/qt-d
>
> Note, this doesn't even come close to compiling... I basically just renamed all the .h files, got some of the Qt sample apps, translated those main.cpp files to D, and started trying to build. Then just working through compile errors, with each class of error being formed to the best regex I could muster and applying it across the board. Going for the simplest and most regex-able errors first (you'll find very little in the way of relevance regarding what is and isn't done), so that I could translate as much of the code as close to D as I can before having to deal with the harder ones.

Files like qatomic, qtypetraits, qtypeinfo, qglobal, qsystemdetection, qprocessordetection, qcompilerdetection, qobject, etc, etc... they are just brute-force work by hand. There's no way to automate this mess. It's a sea of #define.

This is primer program on QtE
----------------------------------------------------
import std.stdio;        // writeln
import core.runtime;     // Processing of input parameters
import std.net.curl: get;
import qte;              // work with Qt

class Exam: QMainWindow {
    this() {
		super();
	}
}
	
int main(string[] args) {
    // Test load library. '--debug' start in debug state.
    bool fDebug; foreach(arg; args) if (arg=="--debug") fDebug = true;
    int rez = LoadQt( dll.Core | dll.Gui | dll.QtE, fDebug); if (rez==1) return 1;  // Error load QtE
    QApplication app = new QApplication(&Runtime.cArgs.argc, Runtime.cArgs.argv, 1);
    // ----------------------------------

    Exam ex = new Exam();
    ex.show();

    // The main body of the program ..

    // ----------------------------------
    return app.exec();
}
---------------------------------------------------------

screenshot QtE on Windows and Linux
http://qte.ucoz.ru/QtE_win_2.png
http://qte.ucoz.ru/QtE_linux_2.png

Just for note, you can make desktop D applications in HTML/CSS3/scripting using https://github.com/midiway/sciter-dport

On Friday, 13 November 2015 at 20:03:38 UTC, Ramon wrote:
> Just for note, you can make desktop D applications in HTML/CSS3/scripting using https://github.com/midiway/sciter-dport


May be Github's Electron or D's webview bindings(which also abstracts too much, with too much weird naming conventions) IMO.

On Friday, 13 November 2015 at 21:30:34 UTC, karabuta wrote:
> On Friday, 13 November 2015 at 20:03:38 UTC, Ramon wrote:
>> Just for note, you can make desktop D applications in HTML/CSS3/scripting using https://github.com/midiway/sciter-dport
>
>
> May be Github's Electron or D's webview bindings(which also abstracts too much, with too much weird naming conventions) IMO.

No, there is a lot of difference between engines. Chromium is tailored for web-browsers, while Sciter goal is for making desktop apps, so it is more lighweight and flexible. Electron is a binary distribution so its pretty hard to mix any new native code.

You don't need to know nothing about Sciter API to start off, you can just download a project from http://misoftware.rs/Bootstrap and just write the HTML, the code will teach you by itself, you learn as you go, and it is flexible because you have access to all native source-code involved, unlike Electron.