Hi! Qt# is a binding of the Qt toolkit to the C# programming language. Have a look at http://qtcsharp.sourceforge.net/. The attached ebuild installs the required shared library and CIL DLL. It requires a recent GCC, Qt >=3.1 and Mono >=0.30. I suggest dev-dotnet/qtcsharp. It works fine for me (on x86). Best Wishes, Martin
Created attachment 29054 [details] qtcsharp-0.7.1.ebuild
There was an issue with the name of the ebuild! It has to be called "qtsharp" which seems to be the right name of the project. I am posting the new ebuild. I also corrected the SRC_URI line in order to contain all sourceforge mirrors (via "mirror://"). Didn't know that! Sorry, I am a beginner ;)
Created attachment 29232 [details] qtsharp-0.7.1 ebuild
DEPEND is wrong, you don't need mono to use Qt#. Unfortunatly there is no "virtual/cli" or something (most things work with pnet and mono, mono is just "hardcoded" in most packages). I don't really know what should be done about this, but perhaps it's too early (still! ;) to deal with that, who knows.
That's not really true. The newest versions of qt# don't work with pnet. But you are right, a virtual depend would be the better way, for the future. http://qtcsharp.sourceforge.net/faq.html#SECTION00031000000000000000
The FAQ is wrong here (or you could just call it "outdated"), pnet/qt# works for a long time now (and still does, I am using it right now as we speak). Also, the INSTALL file of qt# (which is more up to date) says: * Mono >= 0.30 or Portable.NET >= 0.6.2 Before 0.7.1, pnet was even required to build qt# (because of csant). Anyway, I just think it's the wrong trend to let everything depend on mono although in fact mono isn't required, not for building and not for running it ;)
what about the qtsharp bindings in kdebindings? are those different?
Those are the same. It is explained at the home page: http://qtcsharp.sourceforge.net/
now available in kde-base/qtsharp
Thanks! But why did you put it in kde-base? I think dev-dotnet would be far more appropriate..?
agreed, it really should be moved.
It's a part of the splitted up kdebindings package. From my POV it does make sense to keep these packages in kde-base. At least the PyQt/PyKDE stuff (not exposed yet) is not congruent to the versions in dev-python/.
imho, if there is no 'physical' reason to have it in kde-base it should be in the logical place. i can't comment on pykde or the whole why & how of the split-up, but it shouldn't result in two different versions anyway.
>i can't comment on pykde or the whole why & how of the split-up, but it shouldn't result in two different versions anyway. I don't know about the other stuff in kdebindings, but we can't do much about it that kde.org ships sip/pyqt/pykde versions, which differ from the ones from the original authors. The reasons why kde.org maintains them as part of kdebindings is, that the author of pykde does not have the time to keep up with newest kde versions (e.g. there is no pykde version compatible with kde-3.3.1 yet). If there are similar issues with other bindings - annoying as it is - it makes sense to keep the ones from kdebindings in kde-base and maybe to have concurring ones in other categories. If this is not the case and qtsharp and "kdebindings-qtsharp" are identical, then I'll agree with you and instead the split-up kdebindings, the standalone tarball should be used, by a dev-dotnet/qtsharp ebuild.
In such a situation i would choose to support the best-maintained bindings, not both of them, I think that is too risky & confusing to users. I think it's strange bindings get treated like that by the kde team & there is not a single repository for development.
foser: It's not that simple. The versions in kdebindings are older, patched ones, so pykde works with the new kde version. On the other hand this does not justify, that users of PyQt, want or should have to live with older versions. I did not really look into it, yet. Maybe it's possible only to extract pykde from kdebindings. But the bug is about Qt# anyways and I don't know how this bindings are handled.
I want to make sure - is the kdebindings/qtsharp package exactly the same as the independant 0.7.1 package? Can we forget about qtcsharp.sf.net releases from now on?
Just a little note: The ebuild has no keywords and ewarn says that it won't build because csant is not available in portage, that's not entirely true. csant is part of the DotGNU Portable.NET toolchain (dev-dotnet/pnet) and thus, qtsharp will build on your favorite GNU box :) But that "problem" solved automatically since the latest version from the qtcsharp module on sourceforge (released 9 months ago, hum...) doesn't require csant anymore. Though, I don't know if that applies to the qtsharp stuff extracted from kdebindings, too.
err, just to clarify: With "The ebuild has no keywords [...]" I did *not* mean that it should be keyworded, just read that wording in the ChangeLog, don't know why I mentioned it ;)
Yes, it has no keywords because it can't be build without csant, and I didn't know Gentoo had csant :-) I thought it needs it because the docs that come with it (in kdebindings) say so. Can someone comment on the kdebindings-qtcsharp.sf.net differences please? I don't want to spend my time on trying to make the wrong version build. I only have to do with the 'kde' in kdebindings - I don't actually use qtsharp :-) What app (preferrably in portage) uses/needs qtsharp, so that I can test against it?
Sorry, I have to say that kdebindings isn't up-to-date any more. Version 0.7.1 from qtcsharp.sf.net (QTSHARP-0_7_1_BRANCH in Sourceforge CVS) is the most current version! Moreover, work on the current version has been stopped in favor of a new approach (called Bugtussle), which is developed entirely in Sourceforge CVS. This means we really have to use the tarball from the Sourceforge site, sorry.
*** Bug 42180 has been marked as a duplicate of this bug. ***
I'd like to, um, disassociate myself from this ebuild since I don't use qtsharp and due to the current version not being developed anymore as per comment #22. So don't expect me to do anything more for it... This is assigned to dotnet@ anyway :-) When an uptodate ebuild is committed we can remove kde-base/qtsharp.
Version 0.7.1 was the last one. No updates since March 18, 2004. Their webpage is unmaintained, their IRC channel is empty. Is it time to drop this request?
Dropping.
I would. I think Qyoto is the replacement for this, and the development seems quite active.
I dropped it with latexer's permission. You are right about the Qyoto replacement. For what I see Qyoto is part of Kimono. I fail to locate their home page though. Any clues?
