Re: [Mono-dev] Qt anyone?
Hey, I pinged the maintainers of the kdebindings package for opensuse and asked if they were building qyoto. Turns out it's disabled by default by them. They are now taking a look at creating qyoto packages for opensuse. I assume this will cover 11.0 and higher. So if you're interested in this, let them know: http://www.kdedevelopers.org/node/3896 Alan. On Thu, Feb 12, 2009 at 4:32 PM, Arno Rehn mono-de...@arnorehn.de wrote: On Wednesday 11 February 2009 23:12:52 you wrote: Hi Arno, I think Qyoto is a really great initiative and a really strong point to make Mono shine. But I wonder if you have plans (and resources) to: - Relaunch a website with information/tutorials/downloads. It doesn't matter how good Qyoto is if no one can easily find it. We will definitely put up stuff on techbase.kde.org, but I don't know if we'll relaunch a full blown website. Maybe something on sourceforge, we'll see. - Publish builds on the different OSs. IMHO what makes Qyoto rock is being able to create native GUIs for Solaris/Linux/Windows/Mac with a single codebase and minor tweaks. If we only have Linux, then sticking to WinForms or GTK# is still better, if only Mac I guess monoobjc is the right solution, and so on. Yes, we'll do that once we have time to build it on windows and os x. I think monoobjc is the perfect example: they've a solid website, full of samples, which gives a very good feeling when you enter it. You immediately think hey, this is a solid solution. Regards, pablo Arno Rehn escribió: On Linux it's pretty straight forward. Download a recent kde-bindings tarball and extract it somewhere. Build it as every other KDE module with cmake. Create a build directory, do cd build-dir; ccmake src-dir. Disable the stuff you don't want/don't need, like Soprano or Nepomuk bindings. Then just make; make install as usual. We haven't tried building on Solaris yet. On OS X someone got it working, but there seem to be issues with header files not being correctly found. You might have to play a bit to get it working there. On Friday 06 February 2009 20:36:29 pablosantosl...@terra.es wrote: are there tutorials to build on Mac/Linux/Solaris? Daniel Morgan escribió: Qyoto / Kimono Project http://ekarchive.elikirk.com/david/qyoto/ Here is a different project with a similar goal of creating CLR bindings for qt - qt4dotnet http://code.google.com/p/qt4dotnet/ If you google, you might be able to find ancient C# bindings to qt called qt# - but it has been abandoned. On a different subject, I wonder if someone would dare replace the glib and other dependencies in mono with qt. Then create clr bindings to qt. With these bindings, you could re-write mono using the clr bindings to qt. Now, that would be interesting. Please note, I am not saying anything is wrong with glib and its dependencies, I just think it would be neat to re-write mono using qt instead of glib. This way, you could write mono in C++ and have its internals OOP. Changing subject again, I think its good that there are many GUIs you can choose to use on top of mono: qyoto/kimono, asp.net, gtk#, swf, etc... --- On Fri, 2/6/09, pablosantosl...@terra.es pablosantosl...@terra.es wrote: From: pablosantosl...@terra.es pablosantosl...@terra.es Subject: Re: [Mono-dev] Qt anyone? To: SE1 ikr...@gmail.com Cc: mono-devel-list@lists.ximian.com Date: Friday, February 6, 2009, 6:51 AM Ok, great. The problem is exactly what you mentioned: with no website and no info... there's no way developers can get interested on it. SE1 escribió: pablosantosl...@terra.es wrote: Hi there, After reading: http://tech.slashdot.org/article.pl?sid=09/02/05/2138228, and after the announce of the LGPL Qt release, I think it's quite clear there's a lot to gain from a *solid* Qt binding for Mono. I mean, the Qyoto doesn't look like an alive project anymore (not at least a couple of weeks ago) and if I remember correctly it is restricted to Linux (true cross-platform is needed). And... apps! I'd be eager to port plastic GUI to Qt/C#, and maybe we could start from the Qyoto stuff, but not sure about the status. pablo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list Someone brought the same questions up recently. If you read the thread at http://www.nabble.com/Qyoto-project-dead---ts21427284.html you'll see that although the Qyoto website is down, the project is still very much alive. It also works cross-platform, just lacks the building support at the moment. Ilmar
Re: [Mono-dev] Qt anyone?
On Wednesday 11 February 2009 23:12:52 you wrote: Hi Arno, I think Qyoto is a really great initiative and a really strong point to make Mono shine. But I wonder if you have plans (and resources) to: - Relaunch a website with information/tutorials/downloads. It doesn't matter how good Qyoto is if no one can easily find it. We will definitely put up stuff on techbase.kde.org, but I don't know if we'll relaunch a full blown website. Maybe something on sourceforge, we'll see. - Publish builds on the different OSs. IMHO what makes Qyoto rock is being able to create native GUIs for Solaris/Linux/Windows/Mac with a single codebase and minor tweaks. If we only have Linux, then sticking to WinForms or GTK# is still better, if only Mac I guess monoobjc is the right solution, and so on. Yes, we'll do that once we have time to build it on windows and os x. I think monoobjc is the perfect example: they've a solid website, full of samples, which gives a very good feeling when you enter it. You immediately think hey, this is a solid solution. Regards, pablo Arno Rehn escribió: On Linux it's pretty straight forward. Download a recent kde-bindings tarball and extract it somewhere. Build it as every other KDE module with cmake. Create a build directory, do cd build-dir; ccmake src-dir. Disable the stuff you don't want/don't need, like Soprano or Nepomuk bindings. Then just make; make install as usual. We haven't tried building on Solaris yet. On OS X someone got it working, but there seem to be issues with header files not being correctly found. You might have to play a bit to get it working there. On Friday 06 February 2009 20:36:29 pablosantosl...@terra.es wrote: are there tutorials to build on Mac/Linux/Solaris? Daniel Morgan escribió: Qyoto / Kimono Project http://ekarchive.elikirk.com/david/qyoto/ Here is a different project with a similar goal of creating CLR bindings for qt - qt4dotnet http://code.google.com/p/qt4dotnet/ If you google, you might be able to find ancient C# bindings to qt called qt# - but it has been abandoned. On a different subject, I wonder if someone would dare replace the glib and other dependencies in mono with qt. Then create clr bindings to qt. With these bindings, you could re-write mono using the clr bindings to qt. Now, that would be interesting. Please note, I am not saying anything is wrong with glib and its dependencies, I just think it would be neat to re-write mono using qt instead of glib. This way, you could write mono in C++ and have its internals OOP. Changing subject again, I think its good that there are many GUIs you can choose to use on top of mono: qyoto/kimono, asp.net, gtk#, swf, etc... --- On Fri, 2/6/09, pablosantosl...@terra.es pablosantosl...@terra.es wrote: From: pablosantosl...@terra.es pablosantosl...@terra.es Subject: Re: [Mono-dev] Qt anyone? To: SE1 ikr...@gmail.com Cc: mono-devel-list@lists.ximian.com Date: Friday, February 6, 2009, 6:51 AM Ok, great. The problem is exactly what you mentioned: with no website and no info... there's no way developers can get interested on it. SE1 escribió: pablosantosl...@terra.es wrote: Hi there, After reading: http://tech.slashdot.org/article.pl?sid=09/02/05/2138228, and after the announce of the LGPL Qt release, I think it's quite clear there's a lot to gain from a *solid* Qt binding for Mono. I mean, the Qyoto doesn't look like an alive project anymore (not at least a couple of weeks ago) and if I remember correctly it is restricted to Linux (true cross-platform is needed). And... apps! I'd be eager to port plastic GUI to Qt/C#, and maybe we could start from the Qyoto stuff, but not sure about the status. pablo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list Someone brought the same questions up recently. If you read the thread at http://www.nabble.com/Qyoto-project-dead---ts21427284.html you'll see that although the Qyoto website is down, the project is still very much alive. It also works cross-platform, just lacks the building support at the moment. Ilmar ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- Arno Rehn a...@arnorehn.de ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Qt anyone?
Hi Arno, I think Qyoto is a really great initiative and a really strong point to make Mono shine. But I wonder if you have plans (and resources) to: - Relaunch a website with information/tutorials/downloads. It doesn't matter how good Qyoto is if no one can easily find it. - Publish builds on the different OSs. IMHO what makes Qyoto rock is being able to create native GUIs for Solaris/Linux/Windows/Mac with a single codebase and minor tweaks. If we only have Linux, then sticking to WinForms or GTK# is still better, if only Mac I guess monoobjc is the right solution, and so on. I think monoobjc is the perfect example: they've a solid website, full of samples, which gives a very good feeling when you enter it. You immediately think hey, this is a solid solution. Regards, pablo Arno Rehn escribió: On Linux it's pretty straight forward. Download a recent kde-bindings tarball and extract it somewhere. Build it as every other KDE module with cmake. Create a build directory, do cd build-dir; ccmake src-dir. Disable the stuff you don't want/don't need, like Soprano or Nepomuk bindings. Then just make; make install as usual. We haven't tried building on Solaris yet. On OS X someone got it working, but there seem to be issues with header files not being correctly found. You might have to play a bit to get it working there. On Friday 06 February 2009 20:36:29 pablosantosl...@terra.es wrote: are there tutorials to build on Mac/Linux/Solaris? Daniel Morgan escribió: Qyoto / Kimono Project http://ekarchive.elikirk.com/david/qyoto/ Here is a different project with a similar goal of creating CLR bindings for qt - qt4dotnet http://code.google.com/p/qt4dotnet/ If you google, you might be able to find ancient C# bindings to qt called qt# - but it has been abandoned. On a different subject, I wonder if someone would dare replace the glib and other dependencies in mono with qt. Then create clr bindings to qt. With these bindings, you could re-write mono using the clr bindings to qt. Now, that would be interesting. Please note, I am not saying anything is wrong with glib and its dependencies, I just think it would be neat to re-write mono using qt instead of glib. This way, you could write mono in C++ and have its internals OOP. Changing subject again, I think its good that there are many GUIs you can choose to use on top of mono: qyoto/kimono, asp.net, gtk#, swf, etc... --- On Fri, 2/6/09, pablosantosl...@terra.es pablosantosl...@terra.es wrote: From: pablosantosl...@terra.es pablosantosl...@terra.es Subject: Re: [Mono-dev] Qt anyone? To: SE1 ikr...@gmail.com Cc: mono-devel-list@lists.ximian.com Date: Friday, February 6, 2009, 6:51 AM Ok, great. The problem is exactly what you mentioned: with no website and no info... there's no way developers can get interested on it. SE1 escribió: pablosantosl...@terra.es wrote: Hi there, After reading: http://tech.slashdot.org/article.pl?sid=09/02/05/2138228, and after the announce of the LGPL Qt release, I think it's quite clear there's a lot to gain from a *solid* Qt binding for Mono. I mean, the Qyoto doesn't look like an alive project anymore (not at least a couple of weeks ago) and if I remember correctly it is restricted to Linux (true cross-platform is needed). And... apps! I'd be eager to port plastic GUI to Qt/C#, and maybe we could start from the Qyoto stuff, but not sure about the status. pablo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list Someone brought the same questions up recently. If you read the thread at http://www.nabble.com/Qyoto-project-dead---ts21427284.html you'll see that although the Qyoto website is down, the project is still very much alive. It also works cross-platform, just lacks the building support at the moment. Ilmar ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Qt anyone?
On Linux it's pretty straight forward. Download a recent kde-bindings tarball and extract it somewhere. Build it as every other KDE module with cmake. Create a build directory, do cd build-dir; ccmake src-dir. Disable the stuff you don't want/don't need, like Soprano or Nepomuk bindings. Then just make; make install as usual. We haven't tried building on Solaris yet. On OS X someone got it working, but there seem to be issues with header files not being correctly found. You might have to play a bit to get it working there. On Friday 06 February 2009 20:36:29 pablosantosl...@terra.es wrote: are there tutorials to build on Mac/Linux/Solaris? Daniel Morgan escribió: Qyoto / Kimono Project http://ekarchive.elikirk.com/david/qyoto/ Here is a different project with a similar goal of creating CLR bindings for qt - qt4dotnet http://code.google.com/p/qt4dotnet/ If you google, you might be able to find ancient C# bindings to qt called qt# - but it has been abandoned. On a different subject, I wonder if someone would dare replace the glib and other dependencies in mono with qt. Then create clr bindings to qt. With these bindings, you could re-write mono using the clr bindings to qt. Now, that would be interesting. Please note, I am not saying anything is wrong with glib and its dependencies, I just think it would be neat to re-write mono using qt instead of glib. This way, you could write mono in C++ and have its internals OOP. Changing subject again, I think its good that there are many GUIs you can choose to use on top of mono: qyoto/kimono, asp.net, gtk#, swf, etc... --- On Fri, 2/6/09, pablosantosl...@terra.es pablosantosl...@terra.es wrote: From: pablosantosl...@terra.es pablosantosl...@terra.es Subject: Re: [Mono-dev] Qt anyone? To: SE1 ikr...@gmail.com Cc: mono-devel-list@lists.ximian.com Date: Friday, February 6, 2009, 6:51 AM Ok, great. The problem is exactly what you mentioned: with no website and no info... there's no way developers can get interested on it. SE1 escribió: pablosantosl...@terra.es wrote: Hi there, After reading: http://tech.slashdot.org/article.pl?sid=09/02/05/2138228, and after the announce of the LGPL Qt release, I think it's quite clear there's a lot to gain from a *solid* Qt binding for Mono. I mean, the Qyoto doesn't look like an alive project anymore (not at least a couple of weeks ago) and if I remember correctly it is restricted to Linux (true cross-platform is needed). And... apps! I'd be eager to port plastic GUI to Qt/C#, and maybe we could start from the Qyoto stuff, but not sure about the status. pablo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list Someone brought the same questions up recently. If you read the thread at http://www.nabble.com/Qyoto-project-dead---ts21427284.html you'll see that although the Qyoto website is down, the project is still very much alive. It also works cross-platform, just lacks the building support at the moment. Ilmar ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- Arno Rehn a...@arnorehn.de ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Qt anyone?
pablosantosl...@terra.es wrote: Hi there, After reading: http://tech.slashdot.org/article.pl?sid=09/02/05/2138228, and after the announce of the LGPL Qt release, I think it's quite clear there's a lot to gain from a *solid* Qt binding for Mono. I mean, the Qyoto doesn't look like an alive project anymore (not at least a couple of weeks ago) and if I remember correctly it is restricted to Linux (true cross-platform is needed). And... apps! I'd be eager to port plastic GUI to Qt/C#, and maybe we could start from the Qyoto stuff, but not sure about the status. pablo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list Someone brought the same questions up recently. If you read the thread at http://www.nabble.com/Qyoto-project-dead---ts21427284.html you'll see that although the Qyoto website is down, the project is still very much alive. It also works cross-platform, just lacks the building support at the moment. Ilmar -- View this message in context: http://www.nabble.com/Qt-anyone--tp21863769p21864160.html Sent from the Mono - Dev mailing list archive at Nabble.com. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Qt anyone?
Ok, great. The problem is exactly what you mentioned: with no website and no info... there's no way developers can get interested on it. SE1 escribió: pablosantosl...@terra.es wrote: Hi there, After reading: http://tech.slashdot.org/article.pl?sid=09/02/05/2138228, and after the announce of the LGPL Qt release, I think it's quite clear there's a lot to gain from a *solid* Qt binding for Mono. I mean, the Qyoto doesn't look like an alive project anymore (not at least a couple of weeks ago) and if I remember correctly it is restricted to Linux (true cross-platform is needed). And... apps! I'd be eager to port plastic GUI to Qt/C#, and maybe we could start from the Qyoto stuff, but not sure about the status. pablo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list Someone brought the same questions up recently. If you read the thread at http://www.nabble.com/Qyoto-project-dead---ts21427284.html you'll see that although the Qyoto website is down, the project is still very much alive. It also works cross-platform, just lacks the building support at the moment. Ilmar ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Qt anyone?
Qyoto / Kimono Project http://ekarchive.elikirk.com/david/qyoto/ Here is a different project with a similar goal of creating CLR bindings for qt - qt4dotnet http://code.google.com/p/qt4dotnet/ If you google, you might be able to find ancient C# bindings to qt called qt# - but it has been abandoned. On a different subject, I wonder if someone would dare replace the glib and other dependencies in mono with qt. Then create clr bindings to qt. With these bindings, you could re-write mono using the clr bindings to qt. Now, that would be interesting. Please note, I am not saying anything is wrong with glib and its dependencies, I just think it would be neat to re-write mono using qt instead of glib. This way, you could write mono in C++ and have its internals OOP. Changing subject again, I think its good that there are many GUIs you can choose to use on top of mono: qyoto/kimono, asp.net, gtk#, swf, etc... --- On Fri, 2/6/09, pablosantosl...@terra.es pablosantosl...@terra.es wrote: From: pablosantosl...@terra.es pablosantosl...@terra.es Subject: Re: [Mono-dev] Qt anyone? To: SE1 ikr...@gmail.com Cc: mono-devel-list@lists.ximian.com Date: Friday, February 6, 2009, 6:51 AM Ok, great. The problem is exactly what you mentioned: with no website and no info... there's no way developers can get interested on it. SE1 escribió: pablosantosl...@terra.es wrote: Hi there, After reading: http://tech.slashdot.org/article.pl?sid=09/02/05/2138228, and after the announce of the LGPL Qt release, I think it's quite clear there's a lot to gain from a *solid* Qt binding for Mono. I mean, the Qyoto doesn't look like an alive project anymore (not at least a couple of weeks ago) and if I remember correctly it is restricted to Linux (true cross-platform is needed). And... apps! I'd be eager to port plastic GUI to Qt/C#, and maybe we could start from the Qyoto stuff, but not sure about the status. pablo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list Someone brought the same questions up recently. If you read the thread at http://www.nabble.com/Qyoto-project-dead---ts21427284.html you'll see that although the Qyoto website is down, the project is still very much alive. It also works cross-platform, just lacks the building support at the moment. Ilmar ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Qt anyone?
Daniel Morgan wrote: On a different subject, I wonder if someone would dare replace the glib and other dependencies in mono with qt. Then create clr bindings to qt. With these bindings, you could re-write mono using the clr bindings to qt. Now, that would be interesting. Can you elaborate on why glib should be replaced? For systems that don't support glib or where glib is undesirable, mono's eglib could be used instead, which is really tiny, BTW. A large part of mono applications is already relying on glib (as part of gtk/gtk#/gnome), so adding just another heavy dependency is not an option IMO. Not to speak about having to deal with 2 message queues, C++, license issues (Novell won't be able to re-release the runtime under a non GPL based license anymore). Robert ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Qt anyone?
are there tutorials to build on Mac/Linux/Solaris? Daniel Morgan escribió: Qyoto / Kimono Project http://ekarchive.elikirk.com/david/qyoto/ Here is a different project with a similar goal of creating CLR bindings for qt - qt4dotnet http://code.google.com/p/qt4dotnet/ If you google, you might be able to find ancient C# bindings to qt called qt# - but it has been abandoned. On a different subject, I wonder if someone would dare replace the glib and other dependencies in mono with qt. Then create clr bindings to qt. With these bindings, you could re-write mono using the clr bindings to qt. Now, that would be interesting. Please note, I am not saying anything is wrong with glib and its dependencies, I just think it would be neat to re-write mono using qt instead of glib. This way, you could write mono in C++ and have its internals OOP. Changing subject again, I think its good that there are many GUIs you can choose to use on top of mono: qyoto/kimono, asp.net, gtk#, swf, etc... --- On Fri, 2/6/09, pablosantosl...@terra.es pablosantosl...@terra.es wrote: From: pablosantosl...@terra.es pablosantosl...@terra.es Subject: Re: [Mono-dev] Qt anyone? To: SE1 ikr...@gmail.com Cc: mono-devel-list@lists.ximian.com Date: Friday, February 6, 2009, 6:51 AM Ok, great. The problem is exactly what you mentioned: with no website and no info... there's no way developers can get interested on it. SE1 escribió: pablosantosl...@terra.es wrote: Hi there, After reading: http://tech.slashdot.org/article.pl?sid=09/02/05/2138228, and after the announce of the LGPL Qt release, I think it's quite clear there's a lot to gain from a *solid* Qt binding for Mono. I mean, the Qyoto doesn't look like an alive project anymore (not at least a couple of weeks ago) and if I remember correctly it is restricted to Linux (true cross-platform is needed). And... apps! I'd be eager to port plastic GUI to Qt/C#, and maybe we could start from the Qyoto stuff, but not sure about the status. pablo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list Someone brought the same questions up recently. If you read the thread at http://www.nabble.com/Qyoto-project-dead---ts21427284.html you'll see that although the Qyoto website is down, the project is still very much alive. It also works cross-platform, just lacks the building support at the moment. Ilmar ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Qt anyone?
- Original Message - From: Robert Jordan robe...@gmx.net To: mono-devel-list@lists.ximian.com Sent: Saturday, February 07, 2009 1:33 AM Subject: Re: [Mono-dev] Qt anyone? Daniel Morgan wrote: On a different subject, I wonder if someone would dare replace the glib and other dependencies in mono with qt. Then create clr bindings to qt. With these bindings, you could re-write mono using the clr bindings to qt. Now, that would be interesting. Can you elaborate on why glib should be replaced? I can think of why it should be replaced, but seriously not with Qt... For systems that don't support glib or where glib is undesirable, mono's eglib could be used instead, which is really tiny, BTW. oh, I had not known of this one... maybe then I could get mono to build... A large part of mono applications is already relying on glib (as part of gtk/gtk#/gnome), so adding just another heavy dependency is not an option IMO. Not to speak about having to deal with 2 message queues, C++, license issues (Novell won't be able to re-release the runtime under a non GPL based license anymore). IMO: groan... as I see it, eliminating dependencies is the best. (sorry if all this is uninteresting or already exists, I have not investigated all this...). IMO, I would much rather people abstracted over the whole GUI issue, providing a generic API which would plug into whatever underlying GUI was available and it was told to use (and could multiplex the GUIs, unify message queues, ...). this could then be compared with AWT or similar, where AWT can go through Win32/GDI, GTK, Cocoa, or custom, ... (I could compare it to Swing, but I had largely stopped using Java well before there was Swing, and so have not really investigated how it works...). the main difference though is that it would be preferable if the framework had a separate frontend and backend, so that it would be possible to swap out the internal machinery and direct the same frontend API to different GUI frameworks at runtime (much like how the Linux VFS can manage multiple filesystem types). the purpose of this could be, for example, an app does most of its GUI as a custom OpenGL-based GUI (for example, I typically do this in my apps), but then may choose to pop up a dialog (such as, for example, a load/save dialog) using the native GUI. or maybe, the app is just GL based and wants to use its own GUI, not being plagued with having to be expected to target its output to GTK or similar... (or, for that matter, the API can provide its own GL-based backend, since it is usually not so difficult to make one piece of GL-based code cooperate with another, so long as the app is left with control over the drawing state, and the framework is not too agressive with how it uses GL). an example of this usecase could be, for example, allowing the app to direct the GUI rendering to a render-to-texture context, and directing any input back in through the surface, allowing the GUI to exist self-contained within a surface in a 3D world (meaning, the framework does not directly access the mouse or keyboard, rather events are fed-in through the backend). the framework can then be context-based, allowing for any number of separate GUI-spaces to exist. a render-to-pixel-buffer backend could also be useful (no GL dependencies allowed here), potentially for cases where neither an existing GUI framework or GL are available or desirable. I guess this does leave a slight complexity as to where fonts are stored and managed, so potentially some generic fonts could be managed by the frontend, but the backend manages drawing them, as well as other backend specific fonts. frontend would manage keeping track of widgets and a unified message gueue, but the backends would be responsible for drawing the widgets and possibly also for events. ... in the simple case though, the API could provide utility code to allow much more easily setting up and managing the GUI, and directing the output to GTK or Win32/GDI or similar (although, I would request the API not be structured much like GTK, as personally I find the general approach of GTK trying to make the app be a slave to itself to be a little offensive...). in my custom frameworks, I often end up with an update yourself call, as well as a draw yourself call (maybe N/A or NO-OP for a GTK or GDI based backend, likely these calls would be directed at the backend context rather than the frontend context?...). the app could then be responsible for making sure that these functions are called regularly (potentially per-context). all of this would allow both the flexibility of a customizable GUI, without forcing devs to go back to drawing all their own widgets, ... when the existing frameworks don't exactly work with what they want to do... this would be sort of like on the XBox/360, where the GUI can be used at the same time as the running game, and often the games
Re: [Mono-dev] Qt anyone?
- Original Message - From: Andrés G. Aragoneses kno...@gmail.com To: cr88...@hotmail.com Sent: Saturday, February 07, 2009 12:19 PM Subject: Re: Qt anyone? BGB wrote: - Original Message - From: Robert Jordan robe...@gmx.net To: mono-devel-list@lists.ximian.com Sent: Saturday, February 07, 2009 1:33 AM Subject: Re: [Mono-dev] Qt anyone? snip oh well, probably most people would not be so compelled by such an idea, but it is worth a try I guess... Your idea already exists. I don't know about AWT architecture, but a current technology that does this is XUL, and I believe Nokia is expanding it to add Qt into the mix (currently renders on Cocoa, Gtk, and Windows...). so, XUL is accessible from Mono and without involving a dependency on Mozilla's code?... this would be a critical factor (again, I have not looked into this). it is much like, one could argue, Swing exists, but it doesn't do people much good since it exists on the JVM and would have to be ported over... (likewise, me not being that terribly fammiliar with Canvas, which I would have to look into...). or Morphic exists, but it is the same situation... but, alas, something like this would be a good deal of effort defining and specifying things, followed then probably by implementing interfaces and then later implementing default components, ... I guess a much lighter-weight and simpler option would just be to do a custom C#-based GUI framework based on OpenGL, and blow off the larger problems (such as integrating with existing widget frameworks, or trying to provide a common frontend API with other frameworks). but, alas, I mostly develop things in C land anyways, so all this would not do me much good, me better off using my existing custom C-based GUI stuff... (when I was a good deal younger, I used GTK some, but IMO GTK was far more inconvinience and pain than it was worth, and it was much less effort to forsake it and draw my own widgets...). so, in my case (how it is approached): the app requests input state (keyboard and mouse state); this is passed to the GUI in a big update yourself call (the input is then passed to the widgets, which handle whatever input is directed to them); .. typically, here it does any internal stuff, like other update calls (for example: camera, console, world, ...). then the 3D world is set up and drawn (main scene graph or whatever else), .. later on, the app sets up the GL state (glOrtho, ...); draws any generic (non-GUI) overlays, ... calls the GUI's draw yourself handler, which then recursively tells all the widgets to draw themselves, ... .. (but, alas, this approach is widget-based rather than layer-based, so is arguably less ideal...). but, at least, my GUI stuff is more uniform and functional than my app's Scene-Graph support (where it proves problematic to have both a game-like live state while at the same time allowing a uniform interface to 3D modeling tasks, resulting in the creation of different specialized tools for different parts of the modeling, animation, mapping, ... process, even though the backend code is mostly shared...). but, oh well, whatever I guess... Regards. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Qt anyone?
Hi there, After reading: http://tech.slashdot.org/article.pl?sid=09/02/05/2138228, and after the announce of the LGPL Qt release, I think it's quite clear there's a lot to gain from a *solid* Qt binding for Mono. I mean, the Qyoto doesn't look like an alive project anymore (not at least a couple of weeks ago) and if I remember correctly it is restricted to Linux (true cross-platform is needed). And... apps! I'd be eager to port plastic GUI to Qt/C#, and maybe we could start from the Qyoto stuff, but not sure about the status. pablo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Qt anyone?
Hi there, After reading: http://tech.slashdot.org/article.pl?sid=09/02/05/2138228, and after the announce of the LGPL Qt release, I think it's quite clear there's a lot to gain from a *solid* Qt binding for Mono. I mean, the Qyoto doesn't look like an alive project anymore (not at least a couple of weeks ago) and if I remember correctly it is restricted to Linux (true cross-platform is needed). And... apps! I'd be eager to port plastic GUI to Qt/C#, and maybe we could start from the Qyoto stuff, but not sure about the status. pablo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Qt anyone?
Hi, Some time ago I was started project http://code.google.com/p/nobjectiveast/ NObjectiveAST that can be used to automate process of wrappers generation by parsing preprocessed Qt headers. Using it you can save time and improve my project. See usage in NObjective: http://code.google.com/p/nobjective/source/browse/trunk/ProxyGenerator/HeaderAnalyzer.cs WBR, Eugeny Grishul psantosl wrote: Hi there, After reading: http://tech.slashdot.org/article.pl?sid=09/02/05/2138228, and after the announce of the LGPL Qt release, I think it's quite clear there's a lot to gain from a *solid* Qt binding for Mono. I mean, the Qyoto doesn't look like an alive project anymore (not at least a couple of weeks ago) and if I remember correctly it is restricted to Linux (true cross-platform is needed). And... apps! I'd be eager to port plastic GUI to Qt/C#, and maybe we could start from the Qyoto stuff, but not sure about the status. pablo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- View this message in context: http://www.nabble.com/Qt-anyone--tp21863769p21864455.html Sent from the Mono - Dev mailing list archive at Nabble.com. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
