mono / xwt Goto Github PK

WPF implementation of ICanvasBackend

Hey!

I've been trying to get an idea of the layout engine lately, but since right now the only finished one seems to Gtk+ one, I wanted to ask something that I'm pretty sure you already understand.

SizeCheckStep (in WidgetBackend in the Gtk+ backend) seems to be describe a global layout mechanism - SizeRequest/SizeAllocate in Gtk.Widget don't seem to be fired that many times -for example, when added to a Gtk+ box, or a Window object-. If this is the case, why is this mechanism here, and not in the main namespaces -non backend-?

Or the number of calls is a result of the very specific layout you are driving?

Or are you using Gtk+ 3.0?

(Or I'm likely missing something? :) )

Thanks for the feedback,
Carlos.

The current "flat" style for WPF buttons looks too close to disabled:

GTK takes on a fairly different look on Windows:

I'm not positive what the right style is, but I don't think it's what is there now.

Attempting to e.g. fill a rectangle after DrawImage has no effect.
However, surrounding the DrawImage call with ctx.Save() and ctx.Restore() seems to solve the problem.

I believe this a GTK+ backend bug. Save()/Restore() should be called automatically within DrawImage.

WPF implementation of IListViewBackend

WPF ISaveFileDialog implementation

Add support for IButtonBackend.SetButtonType

Complete TreeView backend implementation

One example of this feature would be tabs with icons and close buttons.
I believe this should be trivial to add to GTK+ and WPF. Not so sure about Mac.

This issue only comes up when you build the project with MD.

Unhandled Exception: System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.TypeInitializationException: The type initializer for 'Xwt.WPFBackend.TreeViewBackend' threw an exception. ---> System.IO.IOException: Cannot locate resource 'xwt.wpfbackend/treeview.xaml'.

at MS.Internal.AppModel.ResourcePart.GetStreamCore(FileMode mode, FileAccess access)

at System.IO.Packaging.PackagePart.GetStream(FileMode mode, FileAccess access)

at System.IO.Packaging.PackagePart.GetStream()

at System.Windows.Application.GetResourceStream(Uri uriResource)

at Xwt.WPFBackend.TreeViewBackend..cctor() in c:\Users\tzi\Documents\Projects\xwt\Xwt.WPF\Xwt.WPFBackend\TreeViewBackend.cs:line 49

There is currently no front and back end implementation for a toolbar I'm pleased to help out with some guidance.

DrawingFigures, Curve2 exposes the following errors:
curvto moveto-stuff has error in comparing (|| not &&)
lineto has to have same moveto-stuff as curveto (maybe find a better way)
relcurveto, rellinto ditto

Arc is wrong (see RoundedRectangle in Rectangles)

solution is here:
lytico@de35e86
but I dont't dare to make a pull request cause I messed up whitespace in ContextBackendhandler.cs and the proj-files

GTK defines default sizes for widgets, WPF does not. Either:

1. XWT needs to define default sizes so WPF can match.
2. GTK sizes need to be reset to minimums and the user should specify.

Instead of making the user manually add a click event and invoke Menu.Popup, let's remove Popup and add

Menu IWidget.ContextMenu { get; set; }

In this way, the platform is responsible for when the right time to open a context menu.

In the Introduction section of the README, the start of the 3rd paragraph reads:

Xwt can be used a standalone framework

It should be:

Xwt can be used as a standalone framework

(Not submitting a pull request because it looks like it would mess up the word-wrapping and I don't know exactly what row it should wrap at.)

WPF implementation of ISelectFolderDialogBackend

Although XWT allows using ScrollViews with custom widgets, this is worthless because GetPreferredWidth/GetPreferredHeight methods are ignored.
Overriding GetPreferredWidthForHeight/GetPreferredHeightForWidth also has no effect.

Using ScrollViews with "native" widgets(such as Xwt.Button) seems to work just fine.

Add support for custom data types in WPF's ClipboardBackend.

WPF implementation of IComboBoxEntryBackend

WPF IOpenFileDialog implementation

System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> GLib.GException: Unrecognized image file format

at Gdk.PixbufLoader.Write(Byte[] buf, UInt64 count)

at Gdk.PixbufLoader.LoadFromStream(Stream input)

at Gdk.PixbufLoader.InitFromStream(Stream stream)

at Gdk.PixbufLoader..ctor(Stream stream)

at Xwt.GtkBackend.ImageHandler.LoadFromStream(Stream stream) in c:\Users\tzi\Documents\Projects\xwt\Xwt.Gtk\Xwt.GtkBackend\ImageHandler.cs:line 36

at Xwt.Backends.ImageBackendHandler.LoadFromResource(Assembly asm, String name) in c:\Users\tzi\Documents\Projects\xwt\Xwt\Xwt.Backends\ImageBackendHandler.cs:line 49

at Xwt.Drawing.Image.FromResource(Type type, String resource) in c:\Users\tzi\Documents\Projects\xwt\Xwt\Xwt.Drawing\Image.cs:line 60

at Samples.Images..ctor() in c:\Users\tzi\Documents\Projects\xwt\Samples\Samples\Images.cs:line 38

--- End of inner exception stack trace ---

at System.RuntimeTypeHandle.CreateInstance(RuntimeType type, Boolean publicOnly, Boolean noCheck, Boolean& canBeCached, RuntimeMethodHandleInternal& ctor, Boolean& bNeedSecurityCheck)

at System.RuntimeType.CreateInstanceSlow(Boolean publicOnly, Boolean skipCheckThis, Boolean fillCache)

WPF implementation of IContextBackendHandler

WPF implementation of IScrollViewBackend

I'd like to propose that TransformPoint (ref double x, ref double y ) and TransformPoints ( Point points[] ) are added to the Drawing Context methods, so that a Point (x,y ) or array points[] can be transformed by the Current Transformation Matrix (CTM).

These are probably the most useful methods, although Cairo and GDI also provide TransformDistance, which omits the translation element. As an alternative to the latter, the CTM { get; set; } could be made available, so that more complex transformations like skew could be achieved.

I'd like to propose that TransformPoint and TransformPoints methods are added to the Drawing Context, so that an array of Points can be transformed by the Current Transformation Matrix (CTM) of the Context. The suggested methods would be:-
void TransformPoint( ref double x, ref double y ); and void TransformPoints ( Point[] );

These are probably the most useful of the possible methods, though GDI and Cairo also provide TransformDistance, which omits the translation element, and could be included. Alternatively, the CTM { get; set; } could be made available, so that more general transforms like skew could be achieved.

Currently, I believe there is no way for a Canvas control to figure out which parts should be redrawn.

In my personal tests, this seems to be making things too slow since in some cases an user widget may be unnecessarily drawing too much. This seems to be particularly bad when scrolling is considered, and makes XWT drawing practically unusable in my case - at least on GTK+.

Even platforms that do not have this feature should have no problems, since it's trivial to add a "fallback" result(a rectangle including the entire widget), while platforms that do have this would have its speed greatly improved.

As a potential alternative, one could pass this data to Context and have it ignore the useless drawing calls. This should also speed up the rendering, and require fewer(if any) changes to the API.

The use of a Func to retrieve the data is a leaky abstraction of GTK. The use of this inside Clipboard needlessly creates closure allocations and delegate invocations that are simply unnecessary on other platforms. We should change this argument to simply be an object, and GTK should simply close over the value itself.

Benefits:

• Implementation details of GTK do not leak through to the contracts
• One less closure for all platforms (GTK included)
• One less delegate invocation on WPF and Mac

Downside:

• Minor update to GTK backend logic
• ???

WPF support for Drag & Drop from IWidget

I was wondering if Xwt will have a split pane container: 2 child widgets, divided by a horizontal or vertical bar that can be moved by the user.
The trick is: one could implement such a widget traditionally(like Gtk# does with boxes) or in the user-space(detect size changed events and resize widgets). In theory, having each backend handle things separately would make things look more native. However, in practice, I noticed that e.g. the Gtk# backend implements boxes(hbox, vbox) kind-of-manually(without actually using the native Gtk.Hbox and Gtk.Vbox), so I'm wondering if there really is an advantage or this is merely causing repetition.

One thing I thought of was to allow "native implementations" and "user widget fallbacks". The trick here is to allow backends to implement their own native widgets, but to create a User Widget that would be picked if no native backend is available: In practice, allowing a Xwt widget to be the backend of another Xwt widget.

Frankly, I doubt Xwt will have too many backends, and in that case this might be worthless over-abstracting, but if most containers are implemented like in the Gtk# backend, it seems there might be a use-case for this, so I thought I should at least mention this idea.

Need windows-style stock icons for those that don't have a native equivalent.

This might not be the appropriate tracker to report this bug, since the code I am referring to is in a fork that was not yet pulled in, but I chose to report this bug here because the WPF fork doesn't seem to have its own issue tracker.

While developing the button backend, I noticed that merely changing the button label completely destroys the layout.
If the window is resized or even moved, the layout is good once again.

Even though this bug is exposed by my button backend, I believe this might be a problem with the basic layout system itself.
Adding SWC.Canvas.SetLeft/SetTop and setting e.Width/e.Height to BoxBackend seems to solve the problem.

I attached a couple images showing the bug. In this example, I created a HBox with three buttons. The first one has a label "Click me!" and, when clicked, changes the label to "Thank you".

hello,
would you mind to have a Size-Point-Conversion?
Point.-Size is already here, so ...

public struct Size
{
....

public static explicit operator Point(Size size)
{
return new Point(size.Width, size.Height);
}

Xwt is amazing!
many thanks for it!
I just started to refactor my application to work with xwt, and started a System.Windows.Forms-Backend
(http://limada.git.sourceforge.net/git/gitweb.cgi?p=limada/limada;a=tree;f=src/Xwt.SWF)

so, how is the best way to contribute?
greetings
lytico

I am looking into this project since this is something I've wanted for long.
However (and I know this is acceptable since the project is recent), I can't help but notice that xwt is not well documented.
Perhaps this git repository should include a Wiki?

In particular, I am interested in:

1. What are the goals and anti-goals of the project
2. What is the exact expected behavior of TimeoutInvoke in EngineBackend
3. What is the absolute minimum required to have a working backend (e.g. the most important parts)

Unhandled Exception: System.InvalidOperationException: No backend found for object: Xwt.TreeStore
at Xwt.Backends.BackendHost.LoadBackend () [0x00000] in :0
at Xwt.Backends.BackendHost.get_Backend () [0x00000] in :0
at Xwt.TreeStore.get_Backend () [0x00000] in :0
at Xwt.TreeStore.AddNode (TreePosition position) [0x00000] in :0
at (wrapper remoting-invoke-with-check) Xwt.TreeStore:AddNode (Xwt.TreePosition)
at Samples.MainWindow.AddSample (TreePosition pos, System.String name, System.Type sampleType) [0x00000] in :0
at Samples.MainWindow..ctor () [0x00000] in :0
at (wrapper remoting-invoke-with-check) Samples.MainWindow:.ctor ()
at Samples.App.Run (System.String engineType) [0x00000] in :0
at MacTest.MainClass.Main (System.String[] args) [0x00000] in :0
[ERROR] FATAL UNHANDLED EXCEPTION: System.InvalidOperationException: No backend found for object: Xwt.TreeStore
at Xwt.Backends.BackendHost.LoadBackend () [0x00000] in :0
at Xwt.Backends.BackendHost.get_Backend () [0x00000] in :0
at Xwt.TreeStore.get_Backend () [0x00000] in :0
at Xwt.TreeStore.AddNode (TreePosition position) [0x00000] in :0
at (wrapper remoting-invoke-with-check) Xwt.TreeStore:AddNode (Xwt.TreePosition)
at Samples.MainWindow.AddSample (TreePosition pos, System.String name, System.Type sampleType) [0x00000] in :0
at Samples.MainWindow..ctor () [0x00000] in :0
at (wrapper remoting-invoke-with-check) Samples.MainWindow:.ctor ()
at Samples.App.Run (System.String engineType) [0x00000] in :0
at MacTest.MainClass.Main (System.String[] args) [0x00000] in :0

Sample code is (which works in WPF by the way):

public class LoginWindow : Dialog
{
    Label titleUserName = new Label("User Email:");
    Label titlePassword = new Label("Password:");

    TextEntry userName = new TextEntry();
    TextEntry password = new TextEntry();


    Table table = new Table();

    public LoginWindow()
    {
        table.Attach(titleUserName,0,0);
        table.Attach(userName, 1,0);

        table.Attach(titlePassword,0,1);
        table.Attach(password,1,1);

        Buttons.Add(new DialogButton(Command.Ok));
        Buttons.Add(new DialogButton(Command.Cancel));
        Content = table;
    }
}

public class App
{
    public static void Run(string engineType)
    {
        Application.Initialize(engineType);

        var w = new LoginWindow();
        w.Title = "Lambda";
        w.Width = 300;
        w.Height = 100;
        w.Show();

        Application.Run();

        w.Dispose();
    }
}

And the Gtk runner is:

class MainClass
{
    public static void Main(string[] args)
    {
        App.Run ("Xwt.GtkBackend.GtkEngine, Xwt.Gtk, Version=1.0.0.0");
    }
}

File dialogs are a very useful feature. They allow selecting files from the file system in a user-friendly way.
They generally come in a few categories:

1. Open or Save
2. File or Folder
3. Single or Multiple

Additionally, some dialogs might include filters(e.g. file format filters), and they often allow the application to set the "current folder".

WPF implementation of ITextLayoutBackendHandler

I'd like to have new DrawImage overloads in Xwt.Drawing.Context:

These overloads would be the "source rectangle" on the image, effectively drawing only a portion of the image on the widget.

Equivalent feature in other toolkits:

• WinForms: http://msdn.microsoft.com/en-us/library/ms142040.aspx
• AWT/Swing: http://docs.oracle.com/javase/1.4.2/docs/api/java/awt/Graphics.html#drawImage%28java.awt.Image,%20int,%20int,%20int,%20int,%20int,%20int,%20int,%20int,%20java.awt.image.ImageObserver%29

WPF implementation of IPanedBackend

WPF implementation of IDialogBackend

Xwt.Rectangle has a lot of "errors", that is different behaviour compared with System.Drawing.RectangleF.
I guess most people are using System.Drawing.RectangleF or System.Drawing.Rectangle so it would be nice to have the same behaviours.

As far as I can see now the "errors" are in methods that noone uses so far,
as: Right, Bottom, FromLRTB, Union, Intersect, Contains, Inflate

I refactored
https://github.com/mono/mono/blob/master/mcs/class/System.Drawing/Test/System.Drawing/TestRectangleF.cs
to work with Xwt.Rectangle.

Is it ok to change Xwt.Rectangle to pass all tests? That means, that I refactor it and make a pull request, together with the test.

the results:

Test 'Xwt.Test.TestRectangle.Contains' failed:
f
Expected: True
But was: False
Playground\View\TestRectangle.cs(66,0): at Xwt.Test.TestRectangle.Contains()

Test 'Xwt.Test.TestRectangle.EdgeIntersection' failed:
Empty
Expected: True
But was: False
Playground\View\TestRectangle.cs(230,0): at Xwt.Test.TestRectangle.EdgeIntersection()

Test 'Xwt.Test.TestRectangle.GetContents' failed:
Right
Expected: 34.0d
But was: 35.0d
Playground\View\TestRectangle.cs(89,0): at Xwt.Test.TestRectangle.GetContents()

Test 'Xwt.Test.TestRectangle.Inflate' failed:
INF#1
Expected: 2,5/56x50
But was: 10,10/40x40
Playground\View\TestRectangle.cs(137,0): at Xwt.Test.TestRectangle.Inflate()

Test 'Xwt.Test.TestRectangle.Intersect' failed:
INT#3
Expected: 40,40/10x10
But was: 10,10/40x40
Playground\View\TestRectangle.cs(151,0): at Xwt.Test.TestRectangle.Intersect()

Test 'Xwt.Test.TestRectangle.IsEmpty' failed:
negative w/h
Expected: True
But was: False
Playground\View\TestRectangle.cs(84,0): at Xwt.Test.TestRectangle.IsEmpty()

Test 'Xwt.Test.TestRectangle.Offset' failed:
OFS#1
Expected: 15,15/40x40
But was: 10,10/40x40
Playground\View\TestRectangle.cs(158,0): at Xwt.Test.TestRectangle.Offset()

Test 'Xwt.Test.TestRectangle.ToStringTest' failed:
0
Expected string length 30 but was 11. Strings differ at index 0.
Expected: "{X=10,Y=10,Width=40,Height=40}"
But was: "10,10/40x40"
-----------^
Playground\View\TestRectangle.cs(165,0): at Xwt.Test.TestRectangle.ToStringTest()

Test 'Xwt.Test.TestRectangle.Union' failed:
Expected: 5,5/46x46
But was: 5,5/45x45
Playground\View\TestRectangle.cs(180,0): at Xwt.Test.TestRectangle.Union()

10 passed, 9 failed, 0 skipped, took 5,62 seconds (NUnit 2.5.5).

MarkdownView Regex.Replace() causes endless loop.
I tested WPF.

For example, this text causes endless loop.

https://github.com/gitextensions/gitextensions/blob/master/README.markdown
The line: "The mailing list can be found at ..." causes endless loop

WPF implementation of IFrameBackend

WPF implementation of ICustomWidgetBackend

When running WPFTest, I ocasionally get this error:

InvalidOperationException:
"The calling thread must be STA, because many UI components require this."

    PresentationCore.dll!System.Windows.Input.InputManager.InputManager() + 0x254 bytes 
    PresentationCore.dll!System.Windows.Input.InputManager.GetCurrentInputManagerImpl() + 0x3c bytes    
    PresentationFramework.dll!System.Windows.Input.KeyboardNavigation.KeyboardNavigation() + 0x76 bytes 
    PresentationFramework.dll!System.Windows.FrameworkElement.FrameworkServices.FrameworkServices() + 0x1a bytes    
    PresentationFramework.dll!System.Windows.FrameworkElement.EnsureFrameworkServices() + 0x41 bytes    
    PresentationFramework.dll!System.Windows.FrameworkElement.FrameworkElement() + 0x128 bytes  
    PresentationFramework.dll!System.Windows.Controls.Panel.Panel() + 0x14 bytes    
    Xwt.WPF.dll!Xwt.WPFBackend.CustomPanel.CustomPanel() + 0x2c bytes   
    Xwt.WPF.dll!Xwt.WPFBackend.BoxBackend.BoxBackend() Line 43 + 0x15 bytes C#
    mscorlib.dll!System.Activator.CreateInstance(System.Type type, bool nonPublic) + 0x46 bytes 
    mscorlib.dll!System.Activator.CreateInstance(System.Type type) + 0x7 bytes  
    Xwt.dll!Xwt.Engine.WidgetRegistry.CreateBackend<Xwt.IBackend>(System.Type widgetType) Line 43 + 0x8 bytes   C#
    Xwt.dll!Xwt.XwtComponent.OnCreateBackend() Line 71 + 0xd bytes  C#
    Xwt.dll!Xwt.Widget.OnCreateBackend() Line 270 + 0x8 bytes   C#
    Xwt.dll!Xwt.XwtComponent.LoadBackend() Line 94 + 0x10 bytes C#
    Xwt.dll!Xwt.XwtComponent.Backend.get() Line 56 + 0x8 bytes  C#
    Xwt.dll!Xwt.Widget.Backend.get() Line 291 + 0x9 bytes   C#
    Xwt.dll!Xwt.Widget.Dispose(bool disposing) Line 241 + 0x8 bytes C#
    System.dll!System.ComponentModel.Component.Finalize() + 0x18 bytes  
    [Native to Managed Transition]  

I suspect this is caused by the garbage collector attempting to dispose a widget with no backend (on XwtComponent.LoadBackend, the backend == null code path is being used and "this" refers to Samples.DragDrop)

Assuming this is indeed a bug caused by GC collecting not-yet-implemented backends, this might become gradually less of an issue as more backends are implemented.

On Wpf (only), the Label sample expands to the full application window size, overwriting the sample selection tree. It is possible to (carefully) select the left-hand edge of the sample window and drag it back to expose the sample tree, but it seems that the minimum width for the tree window is not being respected (or some other Allocation problem).

Description:
Attempting to set the MainMenu of a Window to null results in a NullReferenceException.

System:
Linux Ubuntu x86-64 (11.10, I think)
MonoDevelop 2.6
Mono 2.10.5

Minimalistic example:

using Xwt;

class MainClass
{
    public static void Main (string[] args)
    {
        Application.Initialize("Xwt.GtkBackend.GtkEngine, Xwt.Gtk, Version=1.0.0.0");

        Window w = new Window();
        w.MainMenu = null;
        w.Show();

        Application.Run();
        w.Dispose();
    }
}

Expected behavior:
The behavior should be the same as if the w.MainMenu = null; line was commented out.
Additionally, if there already was a menu previously set, I'd expect w.MainMenu to remove it.
If this was by design, ArgumentNullException would be a better exception to throw. However, I think there are legitimate reasons to want to remove the main menu.

Stack Trace:

Unhandled Exception: System.NullReferenceException: Object reference not set to an instance of an object
  at Xwt.GtkBackend.WindowBackend.SetMainMenu (IMenuBackend menu) [0x00023] in /home/luis/Documents/xwt/Xwt.Gtk/Xwt.GtkBackend/WindowBackend.cs:97 
  at Xwt.Window.set_MainMenu (Xwt.Menu value) [0x00007] in /home/luis/Documents/xwt/Xwt/Xwt/Window.cs:164 
  at (wrapper remoting-invoke-with-check) Xwt.Window:set_MainMenu (Xwt.Menu)
  at MainClass.Main (System.String[] args) [0x00010] in /home/luis/Documents/xwt/QuickTest/Main.cs:10 
[ERROR] FATAL UNHANDLED EXCEPTION: System.NullReferenceException: Object reference not set to an instance of an object
  at Xwt.GtkBackend.WindowBackend.SetMainMenu (IMenuBackend menu) [0x00023] in /home/luis/Documents/xwt/Xwt.Gtk/Xwt.GtkBackend/WindowBackend.cs:97 
  at Xwt.Window.set_MainMenu (Xwt.Menu value) [0x00007] in /home/luis/Documents/xwt/Xwt/Xwt/Window.cs:164 
  at (wrapper remoting-invoke-with-check) Xwt.Window:set_MainMenu (Xwt.Menu)
  at MainClass.Main (System.String[] args) [0x00010] in /home/luis/Documents/xwt/QuickTest/Main.cs:10 

The Widget base class should support receiving mouse scrolling events. This is helpful for example when creating custom widgets, for example based on Canvas.

In the GtkTest project the list of tests starts with only a few pixels witdth.
It is not the minimal, maybe 5 pixels. I can drag it to be both smaller and larger.

Looking in MainWindow.cs in the Sample project there is the line

box.Position = 160;

But it does not seem to be respected.
I'm running on 64bit Ubuntu 12.04

Hi

I updated my Mac to Mountain Lion, and my own project utilizing Xwt can't run anymore. So I pulled and compiled the latest Xwt source code on my Mac with MonoDevelop, and all compiles fine (except from a few warnings).

But when I'm running the MacTest project it fails with the following debug (the same as my own project does):

Unhandled Exception: System.Exception: Failed to exchange implementations
at Xwt.Mac.ObjcHelper.MethodExchange (MonoMac.ObjCRuntime.Class cls, IntPtr sel1, IntPtr sel2) [0x00000] in :0
at Xwt.Mac.MacEngine.Hijack () [0x00000] in :0
at Xwt.Mac.MacEngine.InitializeApplication () [0x00000] in :0
at Xwt.Application.Initialize (System.String backendType) [0x00000] in :0
at Samples.App.Run (System.String engineType) [0x00000] in :0
at MacTest.MainClass.Main (System.String[] args) [0x00000] in :0
[ERROR] FATAL UNHANDLED EXCEPTION: System.Exception: Failed to exchange implementations
at Xwt.Mac.ObjcHelper.MethodExchange (MonoMac.ObjCRuntime.Class cls, IntPtr sel1, IntPtr sel2) [0x00000] in :0
at Xwt.Mac.MacEngine.Hijack () [0x00000] in :0
at Xwt.Mac.MacEngine.InitializeApplication () [0x00000] in :0
at Xwt.Application.Initialize (System.String backendType) [0x00000] in :0
at Samples.App.Run (System.String engineType) [0x00000] in :0
at MacTest.MainClass.Main (System.String[] args) [0x00000] in :0