Anyone installed Qyotodevelop?

IBBoard · September 6, 2009, 4:01pm

Has anyone managed to get Qyotodevelop working properly? Apparently Synapse uses it for their Qyoto (Qt#) development in Monodevelop, but I’m having less luck so far.

I run a Gnome desktop, I’ve got mono-qt installed from the “KDE42” repo, Qyotodevelop from Gryffus’s branch and Monodevelop from the main Mono repo (not the Mono:Monodevelop repo). The “Create new Qyoto project” only appears sometimes (normally after disabling the addin, restarting Monodevelop and re-enabling it) and new projects aren’t being fully set up (I’ve got a qt-gui folder, but only .ui files in there, not the accompanying .cs file, so the project won’t build/run).

Anyone else tried Qyotodevelop and got it running? I prefer Gnome as a desktop, but some of the GTK# bindings are still the same as the C bindings and it is ugly as hell.

Thanks

IBBoard · October 17, 2009, 3:27pm

I’ll try again, since I’m still having problems.

Qyotodevelop has now moved to the Mono:MonoDevelop repo and I’ve moved to the Mono:MonoDevelop build of MD, but so far I’ve still not been able to get it to work properly. I’m getting the same behaviour as before, pretty much (won’t work when first enabled; may work when disabled, MD is restarted and plugin is re-enabled; builds the .ui file to the .cs when the Qyoto project option is available but not otherwise).

If anyone has any ideas of how to debug it (because I’m guessing that it fails to hook itself up properly) or if anyone knows who I should contact (since half of Qyoto is either anonymous Wiki pages or old and abandonned sites) then it would be greatly appreciated.

gryffus · October 20, 2009, 2:03am

Hello IBBoard.

Sorry for my late reply.

Could you please post here output of “zypper lr -u” please?

I will try to explain situation here:

Right now you have to do few “workarounds” which i’m trying to solve:

First of all you need to have qyotodevelop-devel package installed because it contains .pc file for monodevelop to recognize the plugin. This will be solved in next OBS rebuild (qyotodevelop and qyotodevelop-devel will be merged)

Second thing you have to do is disable/enable qyotodevelop plugin in MD addon manager every time you launch MD (you dont need to restart MD, just disable and enable the addon). This is known bug in qyotodevelop and must be fixed upstream - i already had some conversation with FireRabit - author of qyotodevelop about this.

After that you should be able to create new qyoto project.

Note that there is a bug in upstream kdebindings which prevents mono from identify mono-qt assemblies.
I have created a bugreport for this: https://bugs.kde.org/show_bug.cgi?id=211160

I hope i have helped you.

Regards
Gryffus

IBBoard · October 20, 2009, 8:38pm

Thanks for the reply I actually ended up emailing Andrew Jorgensen (the Mono:MonoDevelop maintainer) about it as I’d assumed he was maintaining it now it had moved out of your repos

Zypper output:

#  | Alias                        | Name                                   | Enabled | Refresh | URI                                                                                  
---+------------------------------+----------------------------------------+---------+---------+--------------------------------------------------------------------------------------
1  | Banshee:Unstable             | Banshee:Unstable                       | Yes     | Yes     | http://download.opensuse.org/repositories/Banshee:/Unstable/openSUSE_11.1+Banshee/   
2  | Chromium                     | Chromium                               | Yes     | Yes     | http://download.opensuse.org/repositories/home:/dbuck/openSUSE_11.1/                 
3  | Compiz                       | Compiz                                 | Yes     | Yes     | http://download.opensuse.org/repositories/home:/pedro_seon:/compiz/openSUSE_11.1     
4  | Mono                         | Mono                                   | Yes     | Yes     | http://download.opensuse.org/repositories/Mono/openSUSE_11.1/                        
5  | Mono_Develop                 | Mono Develop                           | Yes     | Yes     | http://download.opensuse.org/repositories/Mono:/MonoDevelop/openSUSE_11.1            
6  | devel:tools:scm:svn          | devel:tools:scm:svn                    | Yes     | Yes     | http://download.opensuse.org/repositories/devel:/tools:/scm:/svn/openSUSE_11.1/      
7  | home:gryffus:branches:Mono_1 | IBBoard Desktop                        | No      | Yes     | http://download.opensuse.org/repositories/home%3a//IBBoard%3a//desktop/openSUSE_11.1/
8  | openSUSE 11.1-0              | openSUSE 11.1-0                        | Yes     | No      | cd:///?devices=/dev/sr0                                                              
9  | openSUSE:11.1:NonFree        | openSUSE:11.1:NonFree                  | Yes     | Yes     | http://download.opensuse.org/repositories/openSUSE:/11.1:/NonFree/standard/          
10 | openSUSE:Factory:Contrib     | openSUSE:Factory:Contrib               | Yes     | Yes     | http://download.opensuse.org/repositories/openSUSE:/Factory:/Contrib/openSUSE_11.1/  
11 | repo                         | Packman Repository                     | Yes     | Yes     | http://ftp.skynet.be/pub/packman/suse/11.1/                                          
12 | repo-debug                   | openSUSE-11.1-Debug                    | No      | Yes     | http://download.opensuse.org/debug/distribution/11.1/repo/oss/                       
13 | repo-non-oss                 | openSUSE-11.1-Non-Oss                  | Yes     | Yes     | http://download.opensuse.org/distribution/11.1/repo/non-oss/                         
14 | repo-oss                     | openSUSE-11.1-Oss                      | Yes     | Yes     | http://download.opensuse.org/distribution/11.1/repo/oss/                             
15 | repo-source                  | openSUSE-11.1-Source                   | No      | Yes     | http://download.opensuse.org/source/distribution/11.1/repo/oss/                      
16 | repo-update                  | openSUSE-11.1-Update                   | Yes     | Yes     | http://download.opensuse.org/update/11.1/                                            
17 | repo_1                       | ATI Repository                         | Yes     | Yes     | http://www2.ati.com/suse/11.1                                                        
18 | repo_2                       | openSUSE BuildService - Mono:Community | Yes     | Yes     | http://download.opensuse.org/repositories/Mono:/Community/openSUSE_11.1/

I tried tinkering with the Qyotodevelop source code myself but didn’t get very far as there were a few bugs to fix and some bits that weren’t well documented in the MonoDevelop extension area. I did manage to get it showing up under a sensible category, though

I’ll try the work-arounds and hopefully it’ll fix it. Seems like a bit of an oddity that you need to disable and re-enable it each time! Hopefully Qt# will be nicer to work with than GTK# (which just shows far too many obvious non-OOisms in its interfaces).

[Edit] Nope, no luck there :\ No obvious errors from MonoDevelop, and I can create Qyoto projects, but it isn’t rebuilding the .cs from the .ui in my old project and in the new project there isn’t even the second .cs file in the sub-directory so it just gives me “The name ‘SetupUI’ does not exist in the current context”.

IBBoard · October 20, 2009, 9:05pm

Stupid timeout.

[what would have been edit 2] On top of that I get the following problems:

Adding a Qyoto project then closing MonoDevelop crashes with:

System.InvalidOperationException: Hashtable.Enumerator: snapshot out of sync.
  at System.Collections.Hashtable+Enumerator.FailFast () [0x00021] in /usr/src/packages/BUILD/mono-2.4.2.3/mcs/class/corlib/System.Collections/Hashtable.cs:933 
  at System.Collections.Hashtable+Enumerator.MoveNext () [0x00000] in /usr/src/packages/BUILD/mono-2.4.2.3/mcs/class/corlib/System.Collections/Hashtable.cs:946 
  at MonoDevelop.Projects.SolutionItem.Dispose () [0x0003b] in /usr/src/packages/BUILD/monodevelop-2.1.1/src/core/MonoDevelop.Projects/MonoDevelop.Projects/SolutionItem.cs:203 
  at MonoDevelop.Projects.SolutionEntityItem.Dispose () [0x0000f] in /usr/src/packages/BUILD/monodevelop-2.1.1/src/core/MonoDevelop.Projects/MonoDevelop.Projects/SolutionEntityItem.cs:85 
  at MonoDevelop.Projects.Project.Dispose () [0x00050] in /usr/src/packages/BUILD/monodevelop-2.1.1/src/core/MonoDevelop.Projects/MonoDevelop.Projects/Project.cs:209 
  at MonoDevelop.Projects.DotNetProject.Dispose () [0x00000] in /usr/src/packages/BUILD/monodevelop-2.1.1/src/core/MonoDevelop.Projects/MonoDevelop.Projects/DotNetProject.cs:361 
  at MonoDevelop.Projects.SolutionFolder.Dispose () [0x0001e] in /usr/src/packages/BUILD/monodevelop-2.1.1/src/core/MonoDevelop.Projects/MonoDevelop.Projects/SolutionFolder.cs:222 
  at MonoDevelop.Projects.Solution.Dispose () [0x00006] in /usr/src/packages/BUILD/monodevelop-2.1.1/src/core/MonoDevelop.Projects/MonoDevelop.Projects/Solution.cs:397 
  at MonoDevelop.Ide.Gui.RootWorkspace.Close (Boolean saveWorkspacePreferencies) [0x000f6] in /usr/src/packages/BUILD/monodevelop-2.1.1/src/core/MonoDevelop.Ide/MonoDevelop.Ide.Gui/RootWorkspace.cs:466

The qt-gui folder doesn’t appear when creating a new project until I first build it. Once it does appear it is just a normal folder rather than the special folder (which I did get at one point when first using QyotoDevelop). That means you’ve got to “show all” and edit the “hidden” .ui file.
The files in the qt-gui folder don’t actually seem to rebuild. I just did a quick test (start MD, disable plugin, enable plugin, edit .ui file and add a button, rebuild project manually just to make sure, run project, no change to default window)

Should I open these up as issues at FireRabbit’s GitHub repo?

IBBoard · December 11, 2009, 8:57pm

I’ve just updated to the latest RC of MonoDevelop from OBS, which means I lost Qyotodevelop because the build was version specific. I also just tried to go to FireRabbit’s GitHub for Qyotodevelop and it seems to be missing now. Anyone know where it moved to and whether anything improved? Is it CodeButler’s version now?

IBBoard · December 21, 2009, 8:24pm

I’ve just sent a Tweet to FireRabbit (Eric) and got this response. Looks like I’m stuck with that horrible GTK# API for native Linux apps in C#, even if it is far more functional than object-oriented :\

IBBoard · January 17, 2010, 9:03pm

After a while coding the WinForms interface for my C# app, I worked on the GTK# app again and boy is it hideous. I spend as much time, if not more, tracking down how to do simple things like “what is the selected item?” and writing a util class for it than I do actually working on the app proper.

I read a comment somewhere that the GTK# API was purposefully made similar to the GTK API for C so that it was familiar for old GTK developers. I’m sorry, but how many C developers are going to move to C# compared to the number of Java/C#/other modern OO language developers who might move to Mono and GTK#?

Anyway, rant over. The continued bad experience made me try contacting the KDE guys about FireRabbit’s comments. There’s a short conversation going at the moment, and initial responses look good. I’ve got to work out the best way to work with it and see how much better the API is, but apart from a potentially outdated “.ui to C# converter” and a bit of refactoring in progress then it is apparently still supported and fairly stable.

JoachimJ · May 19, 2010, 10:51pm

Hi.

Any luck yet?

I’m about to fail on my 12th-15th attempt on getting up to speed with Gtk#, so I’m really grasping for straws now.

IBBoard · May 21, 2010, 9:45pm

It depends what you mean by “luck”. I’ve given up on QyotoDevelop as it just doesn’t work and isn’t supported, but it isn’t really necessary.

I wrote a short article on using Qyoto/Qt# with MonoDevelop, including a script that rebuilds the C# code from the Qt .ui files. That works quite well and you just need QtDevelop.

The only problem I had then was that Qyoto was quite unstable at times. The guys managing the non-C++ Qt bindings were more than willing to help, but weren’t using Qyoto themselves and so didn’t find the problems themselves. I think they are in the process of restructuring it, though. It’s definitely a nicer API than GTK# for an object-oriented programming language, it’s just a shame it isn’t better supported.

JoachimJ · May 21, 2010, 10:00pm

I’ll check your article.

Thanks.

Star_Gazer · May 25, 2010, 4:08am

I installed it - funny thing though - I used the create Qyoto Solution feature from the list of templates in MonoDevelop (2.2), then the next day or so, it is no longer in list of templates for MonoDevelop!

But I have a lot of homework to do where Qt, MonoDevelop, and the C# Language is concerned, so the disappearance of the Qytoto Template was just another addition to a mount of frustrations, as in these adventures.

Did save IBBoard’s construction of a C# file to use for Qyoto as I learn this stuff via the processing of time.

I have the Qt Designer software (v. 3 & 4) installed.

Regards,
Clifton

Star_Gazer · May 27, 2010, 8:46pm

It would appear that when installing MonoDevelop’s Beta for version 2.4, the software management gives various options which include removing QyotoDevelop.

I wonder if QyotoDevelop will be updated?

Regards,
Clifton

IBBoard · July 5, 2010, 9:28pm

I think it’s a lost cause by now, but overall I’ve found that Qt Designer and the little script that I use were sufficient.

seasoned_geek · July 25, 2011, 4:07pm

You know, your post didn’t show the actual compilation command line. The current problem with OpenSuSE is that Qyoto seems to be horribly broken. No DLL files, only a .SO.

IBBoard · July 25, 2011, 8:44pm

I don’t remember what I was doing with Qyoto any more - I think I had a build script, but I can’t remember what it was as I sidelined the Qt# interface for my app ages ago. GTK# might have a hideous C-like API, but at least it worked and didn’t crash! I think I must have had a script to convert .ui files into their C# versions, but that’ll have just been a script to pass all .ui files to one of the commands from the Qyoto package.

You never know, maybe the creation of Xamarian will give Qyoto an indirect boost!