Mono 2.10.1 and MonoDevelop 2.6 with a working form designer in the extras-testing repositories for the N900
What if I'm not all zadolbal?
In general, with the help of black magic, scrap and some kind of mother, I still managed to get Mono to gather under the scratchbox, and bring MonoDevelop to a sane state, so now the GUI editor works fine.
To put this miracle on a piece of metal, you need to connect extras-testing (hasn't anyone done this?) And select it in the program manager. If a version from the previous post has been installed, then it is better to clean it up, because it can be crookedly updated.
')
On the device there is no concept of a right click. No, there’s nothing to do. In the very same WinMobile, this has been since time immemorial, and is disabled for those windows that do not need it (see SHRecognizeGesture). Well, not laid and not laid. Probably it was somehow justified. Well, okay, we hang a filter on all window events when we initialize the binding to Gtk and rule them as it should. In general, the right click now works while the Fn key is pressed (with the arrow).
Well, menus menus, and a gooey designer, although it works, does not allow components to be put on a form. Why? And everything is simple. Drag-n-Drop is disabled in GTK . When I was digging, trying to understand what was happening, I found the following at the beginning of the gtk_begin_drag function:
Ok right Any configs, settings and environment variables to you. Just clumsily knocked out. This, apparently, is a reserve for the future for adding “new” features by uncommenting the code. After recompiling without this line, Drag-n-Drop miraculously earned, can you imagine? Well, you don’t have to touch the system gtk, it’s hard to break it there, so now I’ll load the correct library via LD_PRELOAD.
The autobird for turnips with logic is not friendly at all. Example. In the source package there are packages only with the architecture all. They are collected under i386. If i386 besides all architecture is lit there, then where will it all start to compile? That's right, under the ARM.
On the remaining features, perhaps, I will not say anything, it's time to finish the five-minute hate. In principle, IDE itself started up practically without patches (most of the jambs associated with GTK are fixed by special code in the binders). This speaks in favor of Novell programmers (or who bought them there?), Especially considering that Maemo is still based on Debian 3.0 code. By the way, there is no fresh MonoDevelop so far even in the debian experimental reps.
As for the runtime itself, the main idea is to cut the source package into 2 parts, one of which will quietly collect managed binaries for i386, and the second does not touch them at all and only deals with the native.
Accordingly, after receiving the assembled runtime, forcing the compiler to work in the arm-scratch box was a matter of a couple of scripts and stolen previously from i386-th normal libraries. Binaries for i386 are loaded past qemu-arm, so if you drag ld-linux.so.2 with the necessary dependencies, then nothing prevents you from running the processor's native code. As a result, the compiler starts this way.
In general, something like that. Now we have a full IDE.
UPD: I seem to have blown up some unobvious dependencies. If it does not start, put another mono-complete. The fixed package is being compiled.
In general, with the help of black magic, scrap and some kind of mother, I still managed to get Mono to gather under the scratchbox, and bring MonoDevelop to a sane state, so now the GUI editor works fine.
To put this miracle on a piece of metal, you need to connect extras-testing (hasn't anyone done this?) And select it in the program manager. If a version from the previous post has been installed, then it is better to clean it up, because it can be crookedly updated.
')
Non-standard technical solutions
On the device there is no concept of a right click. No, there’s nothing to do. In the very same WinMobile, this has been since time immemorial, and is disabled for those windows that do not need it (see SHRecognizeGesture). Well, not laid and not laid. Probably it was somehow justified. Well, okay, we hang a filter on all window events when we initialize the binding to Gtk and rule them as it should. In general, the right click now works while the Fn key is pressed (with the arrow).
Well, menus menus, and a gooey designer, although it works, does not allow components to be put on a form. Why? And everything is simple. Drag-n-Drop is disabled in GTK . When I was digging, trying to understand what was happening, I found the following at the beginning of the gtk_begin_drag function:
#ifdef MAEMO_CHANGES /* Reject any DND requests unconditionally. */ return NULL; #endif Ok right Any configs, settings and environment variables to you. Just clumsily knocked out. This, apparently, is a reserve for the future for adding “new” features by uncommenting the code. After recompiling without this line, Drag-n-Drop miraculously earned, can you imagine? Well, you don’t have to touch the system gtk, it’s hard to break it there, so now I’ll load the correct library via LD_PRELOAD.
The autobird for turnips with logic is not friendly at all. Example. In the source package there are packages only with the architecture all. They are collected under i386. If i386 besides all architecture is lit there, then where will it all start to compile? That's right, under the ARM.
On the remaining features, perhaps, I will not say anything, it's time to finish the five-minute hate. In principle, IDE itself started up practically without patches (most of the jambs associated with GTK are fixed by special code in the binders). This speaks in favor of Novell programmers (or who bought them there?), Especially considering that Maemo is still based on Debian 3.0 code. By the way, there is no fresh MonoDevelop so far even in the debian experimental reps.
As for the runtime itself, the main idea is to cut the source package into 2 parts, one of which will quietly collect managed binaries for i386, and the second does not touch them at all and only deals with the native.
Accordingly, after receiving the assembled runtime, forcing the compiler to work in the arm-scratch box was a matter of a couple of scripts and stolen previously from i386-th normal libraries. Binaries for i386 are loaded past qemu-arm, so if you drag ld-linux.so.2 with the necessary dependencies, then nothing prevents you from running the processor's native code. As a result, the compiler starts this way.
In general, something like that. Now we have a full IDE.
UPD: I seem to have blown up some unobvious dependencies. If it does not start, put another mono-complete. The fixed package is being compiled.
Source: https://habr.com/ru/post/118435/
All Articles