[Kde-bindings] Qyoto on Windows - interest and feedback

Crowell, Brian BCrowell at barbnet.com
Wed Dec 12 18:50:27 UTC 2012


I don’t consider it private. I noticed you had dropped the list, but I thought you had done that on purpose. (Anyone else on the list—this is what Mr. Dobrev and I have been talking about.)

I only took a short glance at uics, and I thought that actually the changes there would be minimal, just to replace one or two of the places where guessing is done (such as line 1088 in cswriteinitialization.cpp, where the enum’s name is guessed) with solid info. If that can be read straight out of, say, QMetaProperty, then yes, that wouldn’t take too much effort. I was thinking more along the lines of “if this information isn’t available to uics at run time, assemblygen can spit out what it knows.”

Right now, I’m working to understand the structure of assemblygen.

--Brian


From: Dimitar Dobrev [mailto:dpldobrev at yahoo.com]
Sent: Wednesday, December 12, 2012 12:36 PM
To: Crowell, Brian
Subject: Fw: [Kde-bindings] Qyoto on Windows - interest and feedback


    P.P: I think I made the mistake of replying to you only and as a result the last 3 or 4 mails did not reach the mailing list. As long as you don't consider this communication private, could you please add it in CC in your reply?

----- Forwarded Message -----
From: Dimitar Dobrev <dpldobrev at yahoo.com<mailto:dpldobrev at yahoo.com>>
To: "Crowell, Brian" <BCrowell at barbnet.com<mailto:BCrowell at barbnet.com>>
Sent: Wednesday, December 12, 2012 8:31 PM
Subject: Re: [Kde-bindings] Qyoto on Windows - interest and feedback


    I meant not rewriting in C# but rather that changing the basic approach uics uses would effectively require a rewrite, regardless of the language employed. Anyway, assemblygen works in a different way. It does read all type information but does not store it anywhere. It just generates the Qyoto libs and then the process exits, that's it. So if I understand correctly, you want to recognise the used Qyoto libs and read the type information from there. But if it's all about type recognition, you can do it in C++ too, by looking at the Qt types. Anyway, if you'd like to give it a shot, please go ahead. You can count on me for help. :)

    About your questions:
    - For now it's me only. Arno Rehn used to maintain them and is still available for questions (and quite helpful) but does not write code on Qyoto any more. However, he does develop and maintain SMOKE - the base of Qyoto (and other bindings) - so if he has time he would definitely work on (or accept patches for :)) any Qyoto issues that turn out to be SMOKE issues;
    - Unfortunately there are only two projects that I am aware of which use Qyoto - one of them abandoned<http://eric.extremeboredom.net/2009/03/31/364>, the other one, which is mine, incomplete - it is open source but because it is a port from GTK# to Qyoto, it requires more work to complete and I do not want to release it prematurely. So this is the sad reality and it's in the hope of attracting more users that I write documentation for Qyoto and upload binaries and make the API more native, which leads us to...
    - ... your third question - you have exactly guessed my intentions about Qyoto - " you would never know you weren’t using a native .NET/Mono library". I've done quite a lot of work in this regard - properties instead of get/set methods, two types of events (corresponding to Qt events and Qt signals), XML code comments, enum parameter types instead of int-s and uint-s. All of these were missing a year ago when I began working on Qyoto. But as you've correctly noticed, there is more work to be done. So not only you can change, to use your example, methods to properties, but I encourage you to do so. :) Only about your second example - perhaps it'd be better if QModelIndex.Sibling() becomes a property too (QModelIndex.Sibling). From what I've seen from the Qt API conventions, the lack of a verb in the function name suggests a simple getter so I believe a C# property would be the better solution in this case as well as in QModelIndex.Row(). And lastly, about the refactoring: yes, you can. I'm always for better code structure as long as the behaviour remains correct. If you'd like to give it a try, let me tell you the way I use to check what I've done: I make copies of the genereated qyoto-qt*.cs files, then run assemblygen and then diff the files to see what the changes are, if any. I'd only ask you to break your refactoring in steps and send me a separate patch for each - this way the repository always has the best code that is complete and there is less chance of merge conflicts.

    And lastly, as there are not that much users of Qyoto, now is the time to make the best possible API so feel free to implement your ideas. :)

    Regards,
    Dimitar

________________________________
From: "Crowell, Brian" <BCrowell at barbnet.com<mailto:BCrowell at barbnet.com>>
To: Dimitar Dobrev <dpldobrev at yahoo.com<mailto:dpldobrev at yahoo.com>>
Sent: Wednesday, December 12, 2012 7:33 PM
Subject: RE: [Kde-bindings] Qyoto on Windows - interest and feedback

I’ve got a better idea on uics. Instead of rewriting it in C#, have assemblygen, which has access to all of the type information, spit out tables of the properties and types and any renaming it’s done. Then uics doesn’t need to guess anything, just do a lookup.

I wouldn’t mind taking a stab at that, assuming I can teach CMake the dependency there. There are lots of other small things that might be nice to write into this.

Some questions:

•         Besides you, who maintains this?
•         How many projects depend on Qyoto at the moment?
•         •• • •••••• ••• ••• •••••••••• ••••• • ••• •••• ••• •••••• ••••• ••••• •••••••• • ••••••• • ••••••••••• •• ••••••••••• •• ••••••••• •••• ••••••••••••••• ••••• ••••••• ••••••••••• ••••• • •••••• •••••••• •••• •• •••••• ••••••••••••••••• • •••••••• ••• •••••••• ••••••••••••••••••••• •• •••••••••••••

I wouldn’t want to make waves if people are already heavily invested in Qyoto, but it would be awesome to be able to improve the quality to such a level that you would never know you weren’t using a native .NET/Mono library.

--Brian


From: Dimitar Dobrev [mailto:dpldobrev at yahoo.com]
Sent: Wednesday, December 12, 2012 4:32 AM
To: Crowell, Brian
Subject: Re: [Kde-bindings] Qyoto on Windows - interest and feedback


    Oh, sorry about that, I've already fixed it but I haven't pushed it yet because I've stacked other changes on top.

    You're right about uics, it would've been better if it could actually recognise the type but this is way too much work. I think the best approach would've been to convert the C++ produced by uic, to C# and I've been wondering why uics wasn't written like this in the first place. That is, uics was not initially my code, my work on it has mostly been hacking around issues such as the one you've found. Anyway, I'm going to work around this one as well, and I'll see about future versions. For now I'm not that willing to change the approach, be it type recognition or conversion from C++, because this would mean a rewrite, and in the middle to long term the ui format is being obsoleted in favour of QML.

    I do welcome contributors :), so if you have any questions on the Qyoto source code, feel free to ask. Just make sure to post your questions to the KDE bindings mailing list because other people could see and answer (for example the former maintainer Arno Rehn) if I'm not available.

    Dimitar

________________________________
From: "Crowell, Brian" <BCrowell at barbnet.com<mailto:BCrowell at barbnet.com>>
To: Dimitar Dobrev <dpldobrev at yahoo.com<mailto:dpldobrev at yahoo.com>>
Sent: Wednesday, December 12, 2012 3:09 AM
Subject: RE: [Kde-bindings] Qyoto on Windows - interest and feedback

Well, I got it to build, though in a bit of a roundabout way. I think my mistake was installing each of the projects in a different location. I may try it again. The only change I had to make, and I’m not sure why, but there’s a System.Data reference in assemblygen/src/plugins/qyoto/CMakeLists.txt that I had to change to System.Data.dll. Not sure why I had to make that change—I was building with .NET 4.0 CSC—but that got it to build.

Reading through, I can see why things might still be a bit scrambly. The original issue I mentioned looks like it’s caused by a mismatch between the DomProperty::Set code in assemblygen/tools/uics/cs/cswriteinitialization.cpp, which guesses the enum name “Feature” based on the name of the property (“features”), and the EnumGenerator, which uses the actual name of the enum. One could add another one-off case in cswriteinitialization.cpp, but the better solution would be if uics.exe could introspect the actual type of the property (I don’t suppose that’s possible at uics’s level?).

While it’s interesting and useful to know how Qyoto is put together, I’m not sure I’ll be able to write patches against this code. We’ll see how much time I can put toward it.

--Brian



From: Dimitar Dobrev [mailto:dpldobrev at yahoo.com]
Sent: Tuesday, December 11, 2012 12:41 PM
To: Crowell, Brian
Subject: Re: [Kde-bindings] Qyoto on Windows - interest and feedback


    You're completely correct, this is why I upload these binary packages for Windows.
    And about the open source apps - Qyoto, just as Qt, is LGPL-licensed so you are not obligated to open source your Qyoto apps.
________________________________
From: "Crowell, Brian" <BCrowell at barbnet.com<mailto:BCrowell at barbnet.com>>
To: Dimitar Dobrev <dpldobrev at yahoo.com<mailto:dpldobrev at yahoo.com>>
Sent: Tuesday, December 11, 2012 8:23 PM
Subject: RE: [Kde-bindings] Qyoto on Windows - interest and feedback

Awesome. Well, in that case, I’ll try the Nokia Qt SDK and just install the MinGW stuff.

Mind, I’ve used Qt, but only as PyQt, and mainly only on Linux. How anyone develops open source apps on Windows is beyond me—the amount of setup and voodoo necessary to do any kind of build is just insane. I suppose it’s merely well-tested voodoo on Linux.

--Brian

From: Dimitar Dobrev [mailto:dpldobrev at yahoo.com]
Sent: Tuesday, December 11, 2012 12:10 PM
To: Crowell, Brian
Subject: Re: [Kde-bindings] Qyoto on Windows - interest and feedback


    Well, Qyoto actually works with any 4.7.4+ version of Qt (only MinGW for Windows, though) but you need QtSDK for a healthy MinGW installation. I tried the latest MinGW recently but it didn't work, in short. So you can install only the MinGW component of the SDK and use any Qt version you want - the selection is performed in step 3 of the second set of steps depending on which qmake.exe you select.

________________________________
From: "Crowell, Brian" <BCrowell at barbnet.com<mailto:BCrowell at barbnet.com>>
To: Dimitar Dobrev <dpldobrev at yahoo.com<mailto:dpldobrev at yahoo.com>>; KDE bindings for other programming languages <kde-bindings at kde.org<mailto:kde-bindings at kde.org>>
Sent: Tuesday, December 11, 2012 7:46 PM
Subject: RE: [Kde-bindings] Qyoto on Windows - interest and feedback

I’m confused about which Qt to install.

There’s a commercial Qt SDK, but that appears to be for evaluation: http://qt.digia.com/Try-Qt-Now/

There’s the open-source libraries download, but that’s missing the mingw and Desktop directories you mentioned: http://qt-project.org/downloads

Finally, there’s the Qt SDK from Nokia (which was a pain to get, but seems to have the stuff I need)-- but it only goes up to Qt 4.8.1. This isn’t necessarily a problem, but does it stay up to date?

I’m installing the Nokia Qt SDK now, but do you have a recommendation?

--Brian


From: kde-bindings-bounces at kde.org<mailto:kde-bindings-bounces at kde.org> [mailto:kde-bindings-bounces at kde.org] On Behalf Of Dimitar Dobrev
Sent: Monday, December 10, 2012 3:39 PM
To: KDE bindings
Subject: Re: [Kde-bindings] Qyoto on Windows - interest and feedback


    Sorry, my e-mail client got bugged and sent the mail prematurely. Here are the instructions:

    1. Install QtSDK;
    2. Add C:\QtSDK\mingw\bin and C:\QtSDK\Desktop\Qt\<Qt_version>\mingw\bin to your PATH;
    3. Install CMake;
    4. Copy C:\QtSDK\mingw\bin\* to C:\QtSDK\mingw\libexec\gcc\mingw32\4.4.0\ (version may vary);
    5. Check out smokegen: git clone git://anongit.kde.org/smokegen;
    6. Check out smokeqt: git clone git://anongit.kde.org/smokeqt;
    7. Check out assemblygen: git clone git://anongit.kde.org/assemblygen ;

    for each in smokegen, smokeqt, assemblygen (in this order):
    1. Run cmake-gui - select the dir with the checked out source and the desired dir for binaries; use MinGW and specify C:\QtSDK\mingw\bin\gcc.exe as the C compiler and C:\QtSDK\mingw\bin\g++.exe as the C++ compiler;
    2. Fill in the CMAKE_BUILD_TYPE: "Release" or "Debug"; leaving it empty produced some strange half-debug version;
    3. Configure - when it complains about QT_QMAKE_EXECUTABLE, set it to the location of qmake.exe (C:\QtSDK\Desktop\Qt\<version>\mingw\bin\qmake.exe, for example) by browsing through the GUI;
    4. On the command line, cd to the dir through the command line and run "C:\QtSDK\mingw\bin\mingw32-make.exe install".

    Note about assemblygen: if it cannot find the SMOKE libs, go to the libs/ subdir of your installation dir (specified in CMAKE_INSTALL_PREFIX) and copy all smoke*.dll files to your CMAKE binary dir for assemblygen (or add the libs/ subdir to your PATH).

----- Forwarded Message -----
From: Dimitar Dobrev <dpldobrev at yahoo.com<mailto:dpldobrev at yahoo.com>>
To: KDE bindings for other programming languages <kde-bindings at kde.org<mailto:kde-bindings at kde.org>>
Sent: Monday, December 10, 2012 11:37 PM
Subject: Re: [Kde-bindings] Qyoto on Windows - interest and feedback


    Hello, Brian,

    Thank you for your interest. I'd like to tell you that such feedback is very useful. I'm working right now on fixing inacurracies in the documentation<http://api.kde.org/qyoto-4.0.5-api/index.html> but I'll try to fix these bugs by the end of the week, possibly sooner. However, if it is a show-stopper for you, please say so and the documentation could wait. :)

    Here's some build instructions for Windows:


________________________________
From: "Crowell, Brian" <BCrowell at barbnet.com<mailto:BCrowell at barbnet.com>>
To: "kde-bindings at kde.org<mailto:kde-bindings at kde.org>" <kde-bindings at kde.org<mailto:kde-bindings at kde.org>>
Sent: Monday, December 10, 2012 10:23 PM
Subject: [Kde-bindings] Qyoto on Windows - interest and feedback

Wanted to drop in and say that I've been a huge fan of Qt on Linux, and always hoped that someday I would be able to use it in my Windows-only corporate projects-- and now that Windows 8 has dropped, to help with that panicked look of "what do we do with our Windows Forms stuff now?"

So I'm surprised and very excited to see Windows binaries for the Qyoto project, and I want to offer encouragement, feedback, or whatever time I can spare to assist the project. (I wish I could offer programmatic help, but the last time I attempted to build any of the KDE bindings on Windows, I nearly threw my computer at the wall.)

I'm running the 4.0.5 Qyoto build (http://download.kde.org/stable/csharp-qt/4.0.5/win32/CSharpQt-Windows-4.0.5.7z) against Qt 4.8.4, and just beginning to test the framework against what I know Qt from the Python bindings.

The issues I've noticed so far have been with uics.exe:

* The included uics.exe has trouble with QDockWidgets. The dock widget's Features property are set using the wrong enum (QDockWidget.Feature instead of QDockWidget.DockWidgetFeature), and the code tries to call SetWidget() instead of setting the Widget property.

* uics.exe also produces code that sets a layout's Margin property, but a code warning says it should use SetContentsMargins() instead.

If this kind of feedback is useful, I'll be happy to provide it as I go. I'm eager to introduce our dev team to the joy that is Qt without forcing them to leave C#. If anyone has tips for building Qyoto on Windows, I might take another stab at that as well.

--Brian Crowell
  Developer, Barbnet Investments
_______________________________________________
Kde-bindings mailing list
Kde-bindings at kde.org<mailto:Kde-bindings at kde.org>
https://mail.kde.org/mailman/listinfo/kde-bindings






-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-bindings/attachments/20121212/49b8bdb8/attachment-0001.html>


More information about the Kde-bindings mailing list