Re: [Mono-dev] Playing with Mono.Terminal, no success
Hi,
Any updates on this?
Thanks,
pablo
On 11/05/2010 9:21, pablosantosl...@terra.es wrote:
Hi Miguel,
Well, here's my code (I tried a different example than the one sent before)
using System;
using Mono.Terminal;
namespace clustermgr
{
class MainClass
{
public static void Main(string[] args)
{
Application.Init(false);
Dialog d = new Dialog (40, 8, Print);
Button b = new Button (All Pages);
b.Clicked += delegate {
d.Running = false;
};
d.AddButton (b);
b = new Button (Current Page);
b.Clicked += delegate {
d.Running = false;
};
d.AddButton (b);
Application.Iteration += delegate {
Application.Refresh();
};
Application.Run(d);
}
}
}
Problem is that the app ends immediately, I don't see anything on the
screen... Maybe I'm just misunderstanding the whole thing, I don't know...
pablo
On 10/05/2010 20:33, Miguel de Icaza wrote:
Hello,
I'm trying the simple sample at: http://www.mono-project.com/MonoCurses
Application.Init (false);
Dialog d = new Dialog (40, 8, Hello);
d.Add (new Label (0, 0, Hello World));
Application.Run (d);
on an OpenSuse box.
But it doesn't work for me, it just exits and breaks the terminal... :-(
Run your program like this to make sure it does not leave you in a
broken state:
mono sample.exe; stty sane
Please post a full sample and I'll take a look at it.
___
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-dev] Altering our build system.
Hello guys, Today's Mono build is designed very much with a bootstrapping focus in mind: it does a full compiler bootstrap, library bootstrap and then proceeds to compile the 2.0, 4.0 profiles and optionally the 2.1 profile. This is problematic for people that are not hacking on everything, for example folks that are not changing the runtime, mscorlib or the compiler do not really needs this. I would like to move to a setup where by default we assume we have a working mcs/runtime and we build the configured profiles (defaulting to 2.0 and 4.0). Additionally, we should have an option to trivially configure which profiles we want to build (2.0, 2.1, monotouch, 4.0). A final wish-list item would be to split up the *core* libraries from most of the extra libraries. The moonlight team is using a special process already to limit the number of assemblies built. Miguel. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Altering our build system.
On Thu, 2010-05-20 at 12:52 -0400, Miguel de Icaza wrote: I would like to move to a setup where by default we assume we have a working mcs/runtime and we build the configured profiles (defaulting to 2.0 and 4.0). ... A final wish-list item would be to split up the *core* libraries from most of the extra libraries. The moonlight team is using a special process already to limit the number of assemblies built. This would dovetail nicely with the idea of splitting up mcs into smaller modules as part of the git migration; see: http://www.mono-project.com/GitMigration I would also suggest using xbuild to build the non-core libraries. This will make it easier for people who aren't using Unix to build the libraries, as Visual Studio could then (hopefully) be used for building, thus avoiding the pain that is Cygwin for everything except the runtime and core libraries. - Jon ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Altering our build system.
I've been looking at a MSBuild based build for the class libs (based upon Jonathan Pobst's MonkeyBuilder). To actually make the projects usable in visual studio, they need to be one of a list of well known project types. While MSBuild can handle an arbitrary .proj file with arbitrary MSBuild tasks, to build inside VS you would need to use a .csproj. Currently, I have a build basically working using a .proj file with custom MSBuild tasks that mirror what MonkeyBuilder does (which mirrors the auto* based build). csproj files could be used, but it raises a few questions: 1. Can we build using either .Net compilers or mono compilers? 2. Is there the concept of make and make install (building class libs versus installing them in some location)? 3. Running unit tests There are more issues, but this is already a bit unrelated to Miguel's original post. The Windows build has recently gone downhill, so hopefully any changes we make might make life better (and hopefully no worse). Thanks, Jonathan On Thu, May 20, 2010 at 2:10 PM, Jonathan Pryor jonpr...@vt.edu wrote: On Thu, 2010-05-20 at 12:52 -0400, Miguel de Icaza wrote: I would like to move to a setup where by default we assume we have a working mcs/runtime and we build the configured profiles (defaulting to 2.0 and 4.0). ... A final wish-list item would be to split up the *core* libraries from most of the extra libraries. The moonlight team is using a special process already to limit the number of assemblies built. This would dovetail nicely with the idea of splitting up mcs into smaller modules as part of the git migration; see: http://www.mono-project.com/GitMigration I would also suggest using xbuild to build the non-core libraries. This will make it easier for people who aren't using Unix to build the libraries, as Visual Studio could then (hopefully) be used for building, thus avoiding the pain that is Cygwin for everything except the runtime and core libraries. - Jon ___ 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
