Coder Social home page Coder Social logo

xwt's Introduction

This document is an introduction to XWT, a cross-platform UI toolkit for creating desktop applications.

If you have any question about XWT or do you want to contribute a discussion group for XWT is available here:

http://groups.google.com/group/xwt-list

Introduction

Xwt is a new .NET framework for creating desktop applications that run on multiple platforms from the same codebase. Xwt works by exposing one unified API across all environments that is mapped to a set of native controls on each platform.

This means that Xwt tends to focus on providing controls that will work across all platforms. However, that doesn't mean that the functionality available is a common denominator of all platforms. If a specific feature or widget is not available in the native framework of a platform, it will be emulated or implemented as a set of native widgets.

Xwt can be used as a standalone framework to power the entire application or it can be embedded into an existing host. This allows developers to develop their "shell" using native components (for example a Ribbon on Windows, toolbars on Linux) and use Xwt for specific bits of the application, like dialog boxes or cross platform surfaces.

Xwt works by creating an engine at runtime that will map to the underlying platform. These are the engines that are supported on each platform:

  • Windows: WPF engine, Gtk engine (using Gtk#)
  • MacOS X: Cocoa engine (using Xamarin.Mac) and Gtk engine (using Gtk#)
  • Linux: Gtk engine (using Gtk#)

This means for example that you can write code for Xwt on Windows that can be hosted on an existing WPF application (like Visual Studio) or an existing Gtk# application (like MonoDevelop). Or on Mac, you can host Xwt on an existing Cocoa/Xamarin.Mac application or you can host it in our own MonoDevelop IDE.

Getting Started

Open the Xwt.sln with MonoDevelop (or VisualStudio on Windows) and build the solution. You should end up with the libraries that you can use in your project and a couple of sample applications.

Using Xwt in your app

Based on your platform and the backend that you want to use, you need to pick the libraries that you want to use in your project.

  • Windows+WPF: Xwt.dll + Xwt.WPF.dll (requires WPF)
  • Windows+Gtk: Xwt.dll + Xwt.Gtk.dll (requires Gtk#)
  • Linux+Gtk: Xwt.dll + Xwt.Gtk.dll (requires Gtk#)
  • Mac+Gtk: Xwt.dll + Xwt.Gtk.dll (requires Gtk#)
  • Mac+Cocoa: Xwt.dll + Xwt.XamMac.dll (requires Xamarin.Mac.dll)

Hello World

To write your first application, create an empty .NET project in your favorite language in MonoDevelop or Visual Studio and reference the Xwt.dll library. This is the only library that you need to reference at compile time.

This is the simplest Xwt program you can write:

using System;
using Xwt;

class XwtDemo
{
    [STAThread]
    static void Main()
    {
        Application.Initialize(ToolkitType.Gtk);
        var mainWindow = new Window()
        {
            Title = "Xwt Demo Application",
            Width = 500,
            Height = 400
        };
        mainWindow.Show();
        Application.Run();
        mainWindow.Dispose();
    }
}

You use the Application.Initialize() method to get the backend initialized. In this example we are using the Gtk backend. If you want to use another backend, just change the parameter provided to the Initialize() method. Also make sure the appropiate backend DLL is available in the application directory.

Then we create an instance of the Window class, this class exposes two interesting properties, MainMenu which can be used to set the Window's main menu and "Content" which is of type "Widget" and allows you to add some content to the window.

Finally, the Application.Run method is called to get the UI events processing going.

Widget Class Hierarchy

You will be using widgets to create the contents for your application. Xwt.Widget is the abstract base class from which all the other components are created.

Some Widgets can contain other widgets, these are container widgets, and in Xwt those are Canvas, Paned, HBox, VBox and Table. The first two implement a box layout system, while the last one implements a Table layout that allows widgets to be attached to different anchor-points in a grid.

The layout system uses an auto-sizing system similar to what is availble in Gtk and HTML allowing the user interface to grow or shrink based on the contents of the childrens on it.

  • XwtComponent
    • Menu
    • MenuItem
    • Widget
      • Box (Container)
        • HBox (Container)
        • VBox (Container)
      • Button
        • MenuButton
        • ToggleButton
      • Calendar
      • Canvas (Container)
      • Checkbox
      • ComboBox
      • Frame
      • ImageView
      • Label
      • ListView
      • NoteBook
      • Paned (Container)
        • HPaned (Container)
        • VPaned (Container)
      • ProgressBar
      • ScrollView
      • Separator
        • VSeparator
        • HSeparator
      • Table (Container)
      • TextEntry
      • TreeView
    • WindowFrame
      • Window
        • Dialog

For example, the following attaches various labels and data entries to a Table:

var table = new Table();
table.Attach(new Label ("One:"), 0, 1, 0, 1);
table.Attach(new TextEntry (), 1, 2, 0, 1);
table.Attach(new Label ("Two:"), 0, 1, 1, 2);
table.Attach(new TextEntry (), 1, 2, 1, 2);
table.Attach(new Label ("Three:"), 0, 1, 2, 3);
table.Attach(new TextEntry (), 1, 2, 2, 3);

The Application Class

The Application class is a static class that provides services to run your application.

Initialization

The Application.Initialize API will instruct Xwt to initialize its binding to the native toolkit. You can pass an optional parameter to this method that specifies the full type name to load as the backend.

For example, you can force the initialization of the backend to be specifically Gtk+ or specifically Xamarin.Mac based on MacOS. This is currently done like this:

Application.Initialize("Xwt.GtkBackend.GtkEngine, Xwt.Gtk, Version=1.0.0.0");

or:

Application.Initialize("Xwt.Mac.MacEngine, Xwt.XamMac, Version=1.0.0.0");

As you saw from the Hello World sample, toplevel windows are created by creating an instance of the "Xwt.Window" class. This class exposes a couple of properties that you can use to spice it up. The MainMenu property is used to control the contents of the application menus while the "Content" property is used to hold a Widget.

Timers

The Application.TimeoutInvoke method takes a timespan and a Func action method and invokes that method in the main user interface loop.

If the provided function returns true, then the timer is restarted, otherwise the timer ends.

Background Threads

It is very common to perform tasks in the background and for those tasks in the background to later update the user interface. The Xwt API is not thread safe, which means that calls to the Xwt API must only be done from the main user interface thread.

This is a trait from the underlying toolkits used by Xwt.

If you want a background thread to run some code on the main loop, you use the Application.Invoke (Action action) method. The provided "action" method is guaranteed to run on the main loop.

xwt's People

Contributors

alanmcgovern avatar bratsche avatar bretjohnson avatar carlosalberto avatar chkn avatar davidkarlas avatar dlech avatar dmitriykirakosyan avatar ermau avatar garuma avatar grendello avatar hwthomas avatar jstedfast avatar knocte avatar luiscubal avatar lytico avatar marshall-lerner avatar mcumming avatar mhutch avatar mkrueger avatar mrward avatar netonjm avatar residuum avatar rodrigopereyradiaz avatar sandyarmstrong avatar sevoku avatar skrysmanski avatar slluis avatar therzok avatar viniciusjarina avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

xwt's Issues

Assign widgets a Menu as a ContextMenu

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.

ButtonBackend flat style looks disabled

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

GTK takes on a fairly different look on Windows:
GTK Flat button
GTK flat button hovering

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

Improve project documentation

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)

[Mac] Sample stopped working

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

[WPF] Custom icons

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

WPF Backend - layout bug

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".

initial
bug

Missing "as" in README.markdown

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] Bug: Label sample expands to overwrite Sample selection tree

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).

Window.MainMenu = null results in NullReferenceException [GTK backend]

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 

IClipboardBackend.SetData is a leaky abstraction

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
  • ???

Xwt.Size: Point conversion operator would be nice

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

Xwt TransformPoint(s) proposal

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.

[WPF] MTAThread/InvalidOperationBackend in WPFTest

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.

Wpf.ContextBackendhandler: Arc, LineTo after MoveTo, CurveTo issues

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

Layout specs

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.

MacTest don't run on Max OSX Mountain Lion

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

[WPF] No longer compiles with MD on Windows

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

Mouse scrolling for Widget

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

[Wishlist] Give Canvas.OnDraw a way to find out what portion of the widget should be redrawn

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.

Xwt.Context.DrawImage prevents further painting (GTK backend)

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.

Default sizes

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.

Native Backends and User Widget fallbacks

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.

Xwt TransformPoint(s) proposal

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.

Add support for file dialogs

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".

Xwt GTK Backend - Unable to use ScrollViews with custom widgets

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.

[Gtk] Image Sample fails on Windows

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)

Gtk demo list starts with too small width

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

[Gtk] DialogButtons don't close dialog when they are clicked

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");
    }
}

Xwt.Rectangle: refactor to pass System.Drawing.RectangleF-Tests

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).

[Wishlist] Drawing only a portion of an image

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:

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.