This project is read-only.

Bugs and steps forward

Oct 18, 2010 at 10:50 AM

Hi again, Jose,

It seems I'm stick with your framework, however now I'm facing a number of bugs/not implemented parts.

Do you have any plans/time on moving forward with this? The reason I'm asking is that some bugs are in conceptual areas and I may not know or just have wrong understanding of how better to fix them. For me its abit difficult to move with them. For example tap area detection is not working in scaled DPI (and using a scaling is one of my major requirements).

May be you already have something fixed/not published - for me not to duplicate the efforts...

Oct 19, 2010 at 12:55 PM

Hi Cail,

I'll continue working in Fleux. The issue with the tap detection you mentioned is already fixed in my local code. I'll try to push the fixes as soon as I can.

My second son was born one week ago, and that filled up all my 'free time' in the last weeks.

Please let me know what are the other bugs or not implemented parts you are facing, so I can let you know how aligned with my priorities they are, and I can also give you some tips if you want to implement something by yourself.





Oct 20, 2010 at 12:38 PM

Hi Jose! Congrats for your son!

I probably will sync with your push and give you my existing changes on my fork.

In short, I basically need to extend fleux in more 'interactive UI' oriented way - my app requires this. So at most not bugs, but adoptation/addition of flexibility. Will be glad to work further on this.

Oct 26, 2010 at 9:30 PM

Hi again, Jose!

Thanks for your push, I've already merged my branch with it.

However, the tap fix is not enough and I've applied other patches in order to make it work with scaled DPI (this is other my major requirement I'm tracking).

Also, I've started to work with ListControl - it also has problems with scaled DPIs. I've made a trivial fix in

It fixes scrolling scale fine, however now I'm facing strange inertia behavior which is not 'physical' so to say. may be you may have an idea on where the problem is - but anyway I'm trying to find this by myself too..

You may want to checkout other commits on my branch - may be some of them are worth to pull back.

Oct 26, 2010 at 10:25 PM

Hi Cail,

I still working in a better approach for some of the controls or UI Elements. In fact, the ListControl will mostly be totally changed.

Another thing I'm currently thinking on is in using just only one Windows control, something like the HostControl, and all the other UI Elements will be placed on that host, like i.e. the Panorama, which is currently a control itself.

I didn't get further progress on the ListControl, because I want to create an scrollable viewer that would make possible a different implementation of the list.

I don't know what's the project you're working on, but please, send me an email to, and tell me what devices are you targeting to, and what's the use case so I can give you a better guidance and focus the efforts in something that benefits everybody.





Oct 27, 2010 at 6:20 AM

Hi Jose,

You've just sounded all the thoughts I've found myself thinking when looking into your code of listcontrol.

The concept of common Host is also good since now f.e. list and panorama are just totally different implementation without any way of common handling. Do you think it possible to use such a HostControl to implement multiple control transitions within a single "physical" form (meaning that currently a separate Windows.Forms.Form needs to be created for each fleux control)? There is a possibility of such a requirement for my project..

Regarding my project - it'll most probably be an opensourced but maybe with a alternative commercial version. Its a carpc related project and I'll for sure give you a reference as soon as it'll have some stable look acceptable for 'public'.

The main hardware I'm targeting is the lowend WinCE PNA (gps navigator devices). However the requirement is also to run it on Desktop windows hosts (for usage in pc based carputers) and of course any kind of winmobile smartphones. Therefore the important usecases are seamless resolution scaling (via DPI change), the main usage is of panorama control, however I need lists and may be some other ui elements for configuration dialogs. All this should be user-interacted per UIElement with gestures support.

So, in short, where I'm planning to work on fleux in near time:

- fixes/improvements in DPI scaling everywhere, abstraction from 'real' pixels.

- Desktop Windows full support.

- UIElement user interactions: not only HandleClick, but basically handle tap/doubletap.

- Adding some interactivity: f.e. UIElement to highlight itself even "before tap" - to give user better UI experience and responsiveness

Oct 27, 2010 at 1:28 PM

@josegallardo : The first i want say thanks for your efforts , super UI u're creating and Congrats for your son !

I'm testing your UI in my project , look like we can not add ListControl to Panorama page ? Or if it possible , pls teacher me how to do that

Other thing, if i creat many grid rows , it can not scroll as list ?

I'll keep a look everydays in this project and hoping you'll have update soon

p/s : I don't see your paypal donate link , i'm a poor student but will be very happy if can donate some moneys  for your hard works


Best Regards !





Oct 28, 2010 at 2:52 AM


I will work this week following a new approach that would simplify the fleux code and make it more scalable and flexible.

I want to validate as soon as possible if this approach would pay any performance fee, as one of my main goals is to keep fleux as fluid as possible. I think it will keep the performance it has now. Currently the panorama control animations are drawing every visible element for each frame, and it stills very fluent, and the new approach should have that same performance in animations with the additional advantage of creating an opportunity for future improvements.

This approach is basically the one I described in my previous post, but it's clearer now:

- There will be only one Win Forms control ( the one I called 'the host' but which would be renamed to FleuxControl )

- Panorama, Grid, List, a future pivot, Image Element, Test Element, etc. will be all UI Elements. They will share the hooks for handling User interactions like native mouse events (mouse down, move, up) and fleux touch gestures (tap, double tap, flick, pan), and the ability to graphically update the control in real time or as part of an animation (this would be the trickiest part here). My implementation will start with a panorama control functional enough to implement the same panorama from the sample app.

About your points:

- DPI scaling: apps using fleux should already be abstracted from 'real pixels', in terms of detect what is the dot density of the device they are running on. Basically fleux tries to provide a programming model where you just choose a given dot density, and develop everything for that case, and it's scaled in run time according to the dot density of the device the app is running on. There would be some bugs, so feel free to fix them and let me know where did you find them. Also, if you think there is a better way to handle that anywhere, don't hesitate in make your suggestion.

- Desktop Windows Full Support is out of scope at this time. However, if you're running that path, I'll be glad to help you where I can.

- UI Elements user interactions: Yup, they will support all the touch gestures and also the native mouse events like down, up and move. In a future, they will also support keyboard events, which are not in the immediate plans.

- Adding some interactivity: Here what I guess is that you want to provide a "pressed" feedback, which is something different than the tap handling. Agree with you on the need of this kind of feedback. My former idea for this "pressed" feedback is to "scale down" the element. Yes, I said "scale". There are no signs of scaling support in the current code, but I have the intention of adding scaling support at DrawingGraphics level. This would probably be implemented at API level as part of the UI Element, but not sure yet. Once I have tested the new approach, I will have a better landscape on this, but potentially, it would be a great addition to fleux.



Thanks for be interested in fleux, and of course for the congrats :)

As you can see from my comments before, there are some changes coming, changes that will address the issues you're having. As this is a very early version of fleux, the list box control is mostly legacy code from the world cup app, and it doesn't have the design changes included in the panorama control, and the concept of UI Elements. That's the reason it cannot be embedded in the panorama control yet. In fact, if I turn all the controls into a UI Element, then anything would be included in any panorama section.

Also, there will be a Scroll Viewer element (similar to what WPF has) that will allow you to place any other UI element inside, and scroll it. This will let you place a grid, and this will make a new List approach feasible.

This will be my next step, after implementing the approach change for the controls infrastructure, I'll work on the scroll element.

I wanted to share this early fleux code to get this kind of feedback, which is great, thank you.

This really helps me moving it to a more stable stage before making it officially public.

About the donate link, I'll probably add one when fleux got a more mature state.










Oct 28, 2010 at 8:39 AM

@Jose : Thanks for answer and i'll stick in project , support as i can. Looking for update soon

Best Regards !


Nov 5, 2010 at 3:14 PM

Hi guys,

It was more than one week, and I wanna give you a quick update on how things are going on.

I'm in the middle of this refactoring, so currently my code is in a mixed status with all the old controls and IUIElements working, but with all the new stuff I'm adding and with a new Sample app that is using the new stuff.

I'm waiting until I can remove the old stuff to do the push.

Now, what really matters, what is the new stuff I have?

1. A new FleuxControl, which is what I used to talk about as the Host Control. It can contain several UIElements and manages how to render them, and pass touch gestures to them.

2. An abstract UIElement base class, that is something totally different than the old IUIElement interface. All the new UIElements will inherit from this class. 

2.1. It has a Children collection of UIElements.

2.2. Concrete classes should implement Draw to define how to render itself.

2.3. It can handle touch gestures first looking for a child element handling it, and if no one has already handle it, it can implement its own handle logic.

2.4. It also exposes Funcs for externally set the touch gestures handlers

2.5. It has an Update() method that can be called anytime to force a redraw in real time. (This is useful i.e. for animations)

2.6. It has an EntranceAnimation property, where you can set how this element should behave when the FleuxControl appears for first time.

2.7. It has an ExitAnimation property, but I didn't implemented yet.

2.8. It doesn't receive Mouse Events. It's only gestures aware.

3. I made some changes to the Animation/StoryBoard architecture. The idea is to keep only one thread alive for animations.

4. I have implemented some UIElements:

4.1. Canvas: A UIElement where you can place more UIElements and it knows how to render them following the given position.

4.2. NewImageElement: same as the old ImageElement but following the new approach. This will be renamed when I can remove the old stuff.

4.3. NewTextElement: same as the old TextElement.....

4.4. ScrollViewer: I have a first implementation of the scroll viewer, and it's working fine. Probably it would need some optimizations later but it's looking good. You can place anything within the scrollviewer (i.e. a canvas element with several elements) and it will let you scroll to see all the methods with inertia scrolling ( a new one ).

4.5. Panorama: It's in progress, but an early hardcoded implementation (hardcoded title, background, and section titles) is working and it looks smooth as the previous one. The code is also much simpler than the old panorama as it's totally UIElement based, so the Background, Title, Sections are all UIElements, and can be easilly replaced / animated / extended / etc. This way we can have a ScrollViewer as part of a Panorama Section, something that was tricky with the previous approach.

5. There is a new GestureInertiaBehavior, which is a different inertia behavior that looks better and it reacts to touch gestures instead of Mouse Events based (Start, Update, and End).

6. A new Sample project: WindowsPhone7Sample. My original idea was to make the changes targeting a panorama control, but it was too complex for a start. So I switched to a simple canvas with two image elements for testing entrance animations, and then scrolling. But it was such an ugly screen that it wasn't enjoyable enough. So I decided to create a new Sample app that mimics the Windows Phone 7 home screen. It was useful for testing entrance animations, scrolling, touch gestures routing, and no UI driven updates, i.e. Live Tiles or a Clock. I'm not trying to create a WinMo theme or skin, but it looks a good sample for showing what can be done using fleux.

I'll continue working on this and I hope I can push the changes really soon.

Don't hesitate in sharing your thoughts.





Nov 8, 2010 at 12:56 AM

Dear J !

It's just super news for us, i can not believe in one week you can do that much as in your list

Hope new code and example coming soon , i just can't wait more :D


Thanks again !



Nov 11, 2010 at 8:07 PM

Hi Jose,

Is there any chance you can review my branch commits and apply some/any/all of them?

Most commits are just exposing more functionality from framework into the end application - I need these for my app. Some of them are related to performance problems I've recently faced with (big number of text elements/grids are practically unscrollable on panorama on my hardware).

The reason I'm asking is that my app depends on these API extensions/changes. Since it looks like you are doing a good redesign now it probably easy for you to alter your APIs abit (according to real app requirements ;-). Otherwise it may happen that my app will be too deeply dependent on old code and it'll be abit difficult for me to upmerge it again with your new refactored code.

Anyway, this is just a willing, I'll be anyway wait for updates from you.


Nov 12, 2010 at 7:20 PM

Hi Cail,

The changes I'm working on will definitely need some updates on your code. I'm afraid that I didn't have the time to review your branch commits b/c I'm heavily focused on having a solid design and code to push soon, but please hold on for one or two more days.

What's missing for pushing my code is:

- A quick port of the previous Grid, even if it doesn't work, just to have it on board, and don't loose it.

- Remove all the old elements that were replaced.

- Review the source code organization, I would probably need to move some of the new stuff to different namespaces.

- Clean up the code. 

I can say that refactoring-wise, the work is done. There are some bugs and missing features, but I can continue working on them after pushing the code.

Some of the changes you did probably won't make sense with the updates. Having UIElements all over the UI can make easy to hook your logic where needed, so please hold on until looking the new update.

Regarding performance, this new approach has some advantages over the previous one, but it also has some disadvantages. It would create a complex object graph, which is great for handling gestures and composing elements around, but that would be hard to handling for some devices, in those cases you should simplify as much as possible your implementation. I plan to add some samples or how to's showing how can you boost your app performance, particularly in some complex controls like the panorama. I'm testing the sample apps in an HTC HD2 (where the app is looking really smooth) and in a Samsung Epix, where the smoothness is not the ideal.

For slower devices there are some performance optimizations that can be done, paying a flexibility and/or eye candy cost, but even in those cases, Fleux can help to build a great UI.

I hope to have news really soon, and *maybe* a video preview.



Nov 13, 2010 at 3:47 PM
Edited Nov 13, 2010 at 5:46 PM

Dear J !

Thanks for update code , first look it had a lot improvement in animated code , and now animated really smooth in hd2 .

Other thing , how i can use method SelectedIndex in ListPage ? Or it not availabe right now ? And how to enable auto Wrap text , multi line text ?

Can't wait for Pivot control coming out

Thanks !



Nov 14, 2010 at 10:31 PM

Hi Tom,

Multi-line / Auto-wrap text is something that is not implemented yet. That's some of the features that still pending in DrawingGraphics. I have code from my previous spikes that implements that functionality but I didn't have the chance to port them to Fleux yet, but it'll definitely be ported.

There are some missing features in the current List element. One missing feature is that It's currently not reacting to SourceItems changes. However, I'm not planning any implementation of SelectedIndex or the selected item concept. It's conceptually against a touch-friendly implementation, your list items should just react to touch gestures, and they should have the required context. You can see how the image items in the "small" panorama section from the "Fleux demo" sample handle the tap event.

However, in some scenarios there is the need for "multi-selection", like in an Item selector where you need to implement some behavior with a set of elements. In those cases you can add a selection item as part of your Item element, that can add it to a collection that your code can handle as a "selected items" collection.

A CheckBox element can be useful in this case, and we can implement it inheriting from ImageElement. You can do it yourself, or just wait until I implement one (it's part of my plans but not high priority yet).

I'm currently working on providing a faster feedback for touch events. I have a first approach scaling down pressed elements, and exposing a PressFeedbackSupported property in the Elements. The gesture engine is also raising Pressed and Released events, and that will be committed very soon.

Another big missing feature is "relayout" along the whole elements graph.

There still lots of stuff to be done. I'll publish a list of features done and TBD soon.